Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue
Roy McDonald's article on software acceleration spawned numerous interesting comments, and other bits of note include changes in three Internet gateways, AOL, Prodigy, and GEnie. We also have a look at Claris's new strategy, some notes on handwriting recognition and communication on the first Newton, and finally, an article detailing how to make MacsBug automatically reboot your server when the server crashes.
Topics:
Copyright 1993 TidBITS Electronic Publishing. All rights reserved.
Information: <info@tidbits.com> Comments: <editors@tidbits.com>
This issue of TidBITS sponsored in part by:
I'll be making the semi-annual pilgrimage to Macworld Boston as you read this. Although I will be ably accompanied by Sally, our PowerBook 100, I won't read email except on CompuServe until 11-Aug-93. Tonya will check my email for important messages, but please refrain from sending unnecessary mail until I return. Truly important email should go to the CompuServe address at <72511.306@compuserve.com> until then. I'll try to check in every day.
I'll release the next issue of TidBITS while on the road, but since I will be using different connection methods, it may not work, at which point it may be a day or two late.
Header Quibble - I've noticed a bunch of failures from the fileserver recently, and in most cases, the failure stems from a strange header, most commonly the information in the From: line. Many people put their names in the From: line along with the email address. That's fine, but if you include your full name, department, organization, and telephone number the email address ends up wrapped down to the second line where the fileserver software can't find it. Try putting extended contact information in a signature instead. Also, try to avoid commas or quotes in your name since email programs tend to spit up over them. In an ideal world, your email would have a single From: line looking something like this:
From: Ferdinand The Bull <bull@cork.com>
Some people use QuickMail gateways that like to duplicate the internal From: line in a pseudo-header below the Internet header. These requests fail because the pseudo-header does not contain the correct Internet address. If you can prevent that pseudo-header from appearing, the fileserver will work better for you.
I realize that you may not know how to change your name in the From: line in your mailer, but if you have trouble receiving files from the fileserver, fixing your From: line will increase your chances of success, and I'll see fewer bounces. Everyone wins.
Subscribing to TidBITS -- Recently more personal subscription requests have come in as well, so I guess it's time to publish the instructions for subscribing automatically again. This information is also always available from <info@tidbits.com>.
To subscribe to the TidBITS mailing list, send email to:
LISTSERV@RICEVM1.RICE.EDU
with this line in the body of the mailfile:
SUBSCRIBE TIDBITS your full name
Legal Queries -- TidBITS is in the process of researching an article on software licensing with a view toward the actual law, standard agreements, nonstandard agreements, what happens if you break the agreement, and how it all applies to shareware/freeware. We also hope to look at the details in terms of upgrades, selling software, donating software to non-profits, and otherwise transferring the license.
With that in mind, we could use some help. If you could send Brady Johnson information on the following, we'd appreciate it (there's no need to send the stuff to me as well). Brady's address is:
wizard36@aol.com
We're looking for strange licensing clauses, how different companies allow you to transfer the license (or not), if you as a individual have had any experiences with enforcement of the law, and any other brief comments you might have. Thanks!
And yes, Brady actually is a lawyer, he doesn't just play one on the nets.
We received a number of well thought-out comments abut Roy McDonald's article on software acceleration in TidBITS #186. Although we don't have room for all of them, here are a few notes:
Larry Rosenstein <lsr@taligent.com> and several others disagreed with Roy's statement that "OOP is an obvious formula for inefficient code." Larry felt that this is a myth, pointing at the fact that the System 7 Finder is a new program that hasn't been optimized, in contrast to the System 6 Finder, which had gone through several iterations that would help speed it up. Larry also noted that many commercial Macintosh applications have been written with object oriented techniques, including popular programs like Photoshop (and incidentally, Akif Eyler's Easy View), and that it's impossible to tell which were written with object oriented techniques based solely on performance.
Jeffrey A. Porten <jporten@sas.upenn.edu> wonders if hardware advances are not often the reason for software inefficiencies. He remembered discussions circa 1985, when programmers would code their software for the Apple //e and then spend months picking over their code paring out five bytes of code here and ten bytes of code there, simply because they had to - they were programming for machines with only 64K of RAM, and disks only stored 143K of information. Today's higher expectations require larger programs, but Jeffrey can't believe that the 1985 philosophy produced his 8 MB word processing folder or his 3 MB System Folder.
Tom Lane <tgl@netcom.com> passed on an old item of computer science wisdom about there being multiple levels of system design, with independent speedups possible at each level. For example, you can describe a system independently at the levels of:
If we imagine that sufficient work can produce a speed increase of 10 times at each of these levels, then we see how to solve our problem one million times faster.
Michael Crawford <crawford@na47sun05.cern.ch>, author of Working Watermarker, the Word Services Apple Event Suite, Webster's Electronic Dictionary and Thesaurus for the Macintosh, and others, writes:
I greatly enjoyed Roy McDonald's article on software speed that appeared in TidBITS #186. I've been contemplating the same issues for the last several years and have some comments. I think Roy's ideas on the lack of good algorithms in commercial software can be summarized as follows:
Productive software engineers often don't know computer science.
Computer scientists can't ship a commercial product.
Many software engineers can't program either.
It has been my experience everywhere I have worked that few, if any, of the production engineers follow any of the academic literature on algorithm or operating system design. For this reason, good ideas from academia either never show up on the market, or only show up after many years when a developer comes up with it independently, claiming it as an innovation.
Few commercial publishers really use "computer science" in their products. Connectix is a notable exception to this sad fact.
There is another issue that Roy didn't address - software quality. I think that the crux of the speed problem lies in quality. The fastest software is useless if it crashes frequently.
I've spent most of my career on the Mac, on the PC, and on Unix fixing someone else's broken code. I have been astonished at the awful quality of the software rats' nests I've debugged. Commercial developers often avoid tricky algorithms, not just to get to market quickly, but to get to market at all. With the poorly structured code often found in commercial products, attempting an n^2 algorithm to nlog(n) would often result in failure because the code would never work at all.
I believe this occurs either because programmers have no formal training - I got my start in programming as an astronomy student - or because the traditional teaching of computer programming over-emphasizes the teaching of algorithms by coding simple homework problems that take a few days to a week to do.
A software engineering curriculum, as opposed to a computer science curriculum, would teach project management, team programming, and version control, and engage an entire class of students in the coding of a single program that would take from one semester to one year to complete. [Sounds like a great way to produce incredibly useful software for the community as well. -Adam]
Much of the industry's problems in software quality could be fixed, not by doing object-oriented programming, but by learning proper structured programming, and having the discipline to program in a structured manner. OOP has gained in popularity, not so much because it is inherently superior, but because it is impossible to make a program work unless one has the discipline to design the class structure of the program in an intelligent manner to begin with.
I've read much spaghetti code written by (pardon my tirade) imbeciles who claimed they wrote structured code. I have three tests for good structure that work well in practice and have helped me repair many a broken program:
Well-structured code can be easily modified for a purpose different than that for which it was originally intended.
Pieces of well-structured code can be understood fairly well without understanding the program as a whole.
Modules of code that perform general utility functions can be easily removed from a project and incorporated into a completely different project without changing header files, or bringing along a bunch of other utility functions.
Object oriented code usually does not pass the third test, whereas structured code often does. It is my experience that any code which can satisfy the above criteria is easily fixed when a bug is found, and can be easily modified to use faster algorithms.
This information will end up in my book, but it's worth mentioning, since it may be of use to you now.
AOL now splits long Internet email messages. In the past the America Online gateway software truncated incoming files at 27K, which put a damper on receiving long text files like TidBITS and BinHexed programs. I tested the splitting by sending myself a test issue of TidBITS and found that it came out broken into three chunks, the first two about 15K long and the third only 1K long. This isn't quite ideal, but we can't argue with progress, I suppose, and with this new feature, AOL's Internet gateway becomes significantly more useful.
Prodigy's Internet gateway won't come cheaply. Jeff Needleman <needje@msen.com> clarified the terms of the current gateway - 15 cents for each 3,000 character block received. No word on the cost to send email through the gateway yet. Jeff said the gateway is in alpha testing, so only a few authorized users can receive mail through it now. I think the cost will have to come down for the gateway to be of serious utility to Prodigy users. If you assume an issue of TidBITS is 30,000 characters, it would cost $1.50 to receive an issue on Prodigy from our Internet mailing list. That's expensive. The Prodigy gateway will have a 60K limit on incoming messages, which will prevent users from requesting large programs from mailservers, even if the cost doesn't.
GEnie opened up its Internet email gateway to all of its users as of 01-Jul-93. Previously, GEnie users had to sign up and pay more to receive Internet email. If you wish to send someone on GEnie email from the Internet, address it to:
username@genie.geis.com
where the username is the person's GEnie username. To send email from GEnie to the Internet, the GEnie user must, much like AppleLink, append @inet# to the Internet address. So my address from GEnie would be <ace@tidbits.com@inet#>. The only cost is for the connect time, and GEnie recently revamped its rates to be more like America Online's rate structure (OK, I don't know who started it, but they're similar now). GEnie costs $8.95 per month with four free hours each month. After those four free hours, users pay $3 per hour in connect time, except in a few free administrative areas. Thanks to <van@cup.portal.com> for the details.
We've come across an intriguing rumor. It might or might not be true, as with all rumors, and I'm sure Claris reserves the right to deny everything or to change its mind, but it appears that all of Claris's major products are doomed in favor of ClarisWorks.
That sounds radical and rash, since even the slick ClarisWorks 2.0 doesn't boast anywhere near the stand-alone power of MacWrite Pro, FileMaker Pro, Resolve, or MacDraw Pro. Those products will continue to exist in name, but their current code will be based on the newer and theoretically better code in the ClarisWorks.
If you think about it, this strategy makes sense. MacDraw and FileMaker have been around a long time, possibly with the same code base, Resolve has never competed seriously with Excel, and MacWrite Pro shipped two years late to mixed reviews. In contrast, ClarisWorks is a recent arrival and has proven immensely popular with its method of contextual editing where simply clicking on a spreadsheet object, for instance, makes spreadsheet menus appear. The only major fault in ClarisWorks is its lack of power and expandability for high-end users.
Consider what would happen if you could have the tight, contextual interface of ClarisWorks and the power of MacDraw Pro, MacWrite Pro, FileMaker Pro, and Resolve. At that point you could complain only about specific features not being what you personally wanted, or perhaps about the cost of purchasing all four programs.
ClarisImpact & ClarisDraw -- Although we may have to wait a while to see the benefits of Claris's decision in this respect, the company is hard at work on new technologies, and just announced two new cross-platform applications that use a new graphics engine. ClarisImpact is aimed at business users working on projects such as flow-charts and diagrams, whereas ClarisDraw replaces MacDraw for general purpose graphics. Both programs sport the same basic ideas embodied in Aldus IntelliDraw - features like automatic sizing, aligning, and connection of objects. Claris's propaganda implies that the Mac versions of these programs are available now - presumably slated for a splash at Macworld, and the Windows versions should appear in the first half of 1994. Suggested retail will be $399 all around, and upgrades from MacDraw go for $99, unless you bought MacDraw Pro after 01-Jun-93, in which case the cost is $29 for ClarisDraw or $49 for ClarisImpact. Finally (I hope you're keeping track of this), registered users of other graphics applications, MacDraw II, or ClarisWorks can buy either ClarisImpact or ClarisDraw for $149.
OpenDoc -- As long as we're rethinking Claris's application code base, why not consider the addition of Apple events and Apple's OpenDoc compound document technology to the mix. OpenDoc is Apple's answer to Microsoft's OLE 2.0 (Object Linking and Embedding), and apparently when Bill Gates found out about the project (code named Amber) he had a fit over the phone at David Nagel, who was in charge of the project at Apple. Could Bill be worried about competition? There might be some, since IBM, Lotus, WordPerfect, and Borland have all announced their support for OpenDoc, a cross-platform, open standard.
OpenDoc allows you to do in any compatible application what you can do today within ClarisWorks. Eventually you should be able to create a document without worrying what type of document it is, and then create the data that you want within your generic document. If you added a picture using a graphics application and then needed to edit it, you would be switched right into the graphics package. However, it wouldn't be like the clumsy linking we have now, but like in-context editing that would provide the appropriate tools and menus when you selected an object.
Although OpenDoc isn't out yet, it in theory bests OLE in two ways. First, the OpenDoc alliance has set up a certification program to ensure that all OpenDoc applications will work together, and second, OpenDoc will work over a broader range of platforms, including DOS, Windows, OS/2, and of course System 7. Unix is slated for later support. The certification program seems to be the most important aspect, because there's no sense in having applications that theoretically work together under OLE if they don't work reliably.
-- Information from:
Pythaeus
Anyone who runs an unattended server Mac will appreciate a little-known feature of MacsBug 6.2.2. You can define a FirstTime/EveryTime macro that automatically restarts the Mac if it crashes into MacsBug, rather than sitting with an error message on its screen. You need ResEdit to do this, and all standard warnings about ResEdit corrupting the moral fiber of today's youth apply.
But first, some background. MacsBug is a free low-level debugger from Apple that normally only programmers use. However, MacsBug has a few commands useful to non-programmers, and I find that MacsBug sometimes helps me identify guilty applications when I have strange crashes. Here are the basic MacsBug commands for non-programmers:
? -- Gets help from MacsBug. Issue the command ? g for help on the g command, for instance.
g -- Tells MacsBug to start executing the program at the point where MacsBug was entered. This is normally not too useful because you enter MacsBug primarily in a crash situation, and you can't generally continue from that point. You use the g command when you accidentally enter MacsBug (such as by pressing the interrupt switch).
es -- Tells MacsBug to "exit to shell." On the Mac, the Finder is the shell, so you're telling MacsBug to quit the current application and go to the Finder. Try this first after crashing into MacsBug. There is a related command, ea, which stands for "exit to application," which tells MacsBug to quit the current application and restart it. I find that this almost never works, so I don't even bother trying it.
rs -- Tells MacsBug to unmount all volumes other than servers and then reboot the Mac. This is generally what you do when es doesn't work and you want to reboot. There is a related command, rb, which unmounts the boot volume only and then reboots the Mac. I have multiple volumes, so I generally use rs. I haven't noticed any real difference.
As I said, you can define a macro that will run automatically when MacsBug is entered. Note that this by no means solves any problems - it's like replacing a fuse immediately after it blows without checking why the fuse blew. It's useful for keeping a Mac that crashes occasionally running most of the time. A MacsBug wizard might be able to modify the macro to open a log file, do a few things (like a stack crawl, or at least log the reason MacsBug was called), close the log, and then restart. The user would then have a record of what happened and why, which could be shared with the developer. However, that's beyond my MacsBug skills, although I'm willing to accept clarifications or modifications. On to the hack!
In ResEdit 2.1.2, open a copy of the file Debugger Prefs.
Open the mxbm resource.
From the Resource menu, choose Create New Resource.
Click on the first entry, 1) *****, and then go to the Resource menu and choose Insert New Field(s).
In the Macro name box, type "FirstTime", and in the Expansion box, type "g" (both without the quotes).
Click on the second entry, 2) *****, and then from the Resource menu select Insert New Field(s).
In the Macro name box, type "EveryTime", and in the Expansion box, type "rs" (again, both without the quotes).
Close the "mxbm ID = 128 from Debugger Prefs" window, make sure that resource is still selected (it should be), and from the Resource menu choose Get Resource Info.
In the Name: box, type "Works FirstTime/EveryTime", close the Info window, save the file, and quit ResEdit.
Make sure that both MacsBug and the modified Debugger Prefs file are loose in the System Folder (not in any special System 7 folders), and reboot. The next time the Mac crashes and enters MacsBug (this won't help when the Mac just freezes), the macro will restart the Mac. Test it by hitting the interrupt switch.
MacsBug is available on <ftp.apple.com> as:
/dts/mac/tools/macsbug/macsbug-6-2-2.hqx
If you use the Centris 610 and low-end 650 with the 68LC040 chip, you need a special version of MacsBug, which is available as:
/dts/mac/tools/macsbug/macsbug-68040lc.hqx
Unfortunately, this special version doesn't include the Debugger Prefs file, so you'll have to get both versions of MacsBug if you have one of the affected Centris models. Rumor has it that you need a new version of MacsBug for the most recent PowerBooks as well, but that might best be a question for APDA, your dealer, or 800/SOS-APPL.
AutoBoot -- Those who want more functionality at the risk of patching a few traps should check out the shareware AutoBoot utility from Karl Pottie. AutoBoot is a Control Panel/Extension that reboots your Mac if a certain amount of time has passed after a System Error or freeze. I haven't used the latest version of AutoBoot, but since it can reboot the Mac after a freeze, it is potentially more useful than my MacsBug hack. However, as an extension, there's always a chance that AutoBoot could conflict with something. If you want to try AutoBoot, it's available for anonymous FTP on sumex-aim.stanford.edu as:
info-mac/cfg/auto-boot-122.hqx
-- Information from:
Karl Pottie -- karl@uz.kuleuven.ac.be
By the time you read this, Apple will have released the Newton, in the form of the MessagePad, which we talked about in TidBITS #185. Several thousand units will be for sale at the Macworld Expo in Boston, although unless the price to the press is lower than for normal folks, I'm not coming home with one. I do hope to try one out, although no guarantees. In the meantime, Pythaeus has played with one and has these comments about handwriting recognition and communication:
The MessagePad has a preferences area, called Extras, that lets you vary the speed of recognition, trading accuracy for speed. I don't know how accurate the recognition could have been ultimately, since you must work with the MessagePad for a few days before it completely adjusts to your handwriting, and I had only one day. But I achieved satisfactory results for entering appointments and similar simple tasks if I waited for about a second every five words. Not bad!
You meet the Newton halfway on recognition. It has a number of different versions of each letter and symbol it recognizes. So, in another part of Extras you get to go through each letter and symbol and choose which forms you use most often and least often (your rendering of the letter "E" will change according to whether it's cursive or not, capital or not, and what letters are on either side of it).
You cannot train the MessagePad to recognize unsupported characters; you must fit one of the characters supplied, or learn to use it. This may prove a handicap for people with truly abysmal handwriting. No shorthand yet, although there's room there for a third party to step in and make some money fast.
Once you and MessagePad agree on what characters you'll be using, you can practice in another area. It flashes words up from the dictionary to let you write them, and it tells you how sure it is that it will recognize the word later. Pretty soon I'm sure we'll have a game that helps you practice handwriting recognition. Should help while away commuting time if you have a MessagePad as well.
I believe I could be up to 100 percent accuracy in a month or so. Like any new device, it takes adjusting to, although far less adjusting than is necessary with a computer.
Beaming Etiquette -- Apple has anticipated the social gaffes that might be committed in a room full of people beaming information around with Newton-based products (the beaming is done via infrared). The MessagePad lets you temporarily hold all incoming "beams" ("beam" is Apple's way of describing both the act and the information itself). Future models will include a polite message in reply to hopeful beams, like "Sorry, but Adam prefers not to receive your beam right now." You also get confirmation that your beam was received by the correct person at the end of transmission. Can you imagine the fun that people could have using MessagePads to send each other love letters, cheat on tests in school, and otherwise perform acts that could be thoroughly embarrassing if made public?
I'd like to see this functionality used more seriously in the future to limit the unnecessary paper waste at trade shows and the like. Instead of picking up a glossy brochure that you're going to later lose or throw out, why not just point your MessagePad at a special transmitter to pick up contact and product information automatically? I'm sure it won't happen soon, even if everyone does have a MessagePad, because it would require marketing departments to adapt to the way people absorb information, something they have trouble doing.
-- Information from:
Pythaeus
Non-profit, non-commercial publications and Web sites may reprint or link to articles if full credit is given. Others please contact us. We do not guarantee accuracy of articles. Caveat lector. Publication, product, and company names may be registered trademarks of their companies. TidBITS ISSN 1090-7017.
Previous Issue | Search TidBITS | TidBITS Home Page | Next Issue