Viewpoint

By Scott T Boyd, Editor Emeritus, http://www.montara.com/

Way back in 1984 Apple did something fundamentally different with the Macintosh that few people talk about when singing Apple’s praises for changing computing’s paradigm.

We came to know it as the A-trap mechanism. For those who haven’t delved into this before, it’s a little oddity made possible by Motorola’s chip designers. Many people might not have even noticed a feature which captured the imagination of a few special people at Apple. 68xxx processors have a number of instructions or conditions which generate exceptions. Each of these causes an exception handler to get called. One entire class of exceptions is triggered by any instruction whose hex value begins with an $A (e.g. $ABCD, $AAFA, etc ). Those wise guys at Apple figured out that they could have the A-line exception code use the instruction’s value as something of an index to figure out which function to further dispatch to. This we now know as the A-trap dispatcher.

The greatest disadvantage of this approach was execution time. It takes time to “throw” an exception. The processor has to put a fair amount of its state onto the stack before it can jump to the exception vector (and restore it later). Then the dispatcher has to do some fancy footwork to figure out who to call, and sometimes it saves and restores even more registers.

Now for the upside. First, a two byte trap word is smaller than any jump you could hope to make into a library of functions. On a 128K machine, that kind of savings really added up. Second, it made it easy to conceive of a vast library of functions that any code could call. While A-traps weren’t necessary for things like the Macintosh Toolbox, they sure didn’t hurt. They provided a consistent mechanism to dispatch to code anywhere on the machine, be it in the ROM, in RAM, or even on the disk, using a standard lookup key (the trap word). Third, it created a mechanism whereby Apple engineers and third parties could correct, modify, and extend the vast library of code (we know this as patching and/or implementing traps).

For years Macintosh programmers felt special. A-traps offered a rich breeding ground for unusual software. We customized our machines in ways not even imaginable on other (lesser?) machines. We had more fun and productivity to show for it, as well as a thriving utility software market.

Alas, the A-trap mechanism might very well have been too useful. You see, there came a time with other operating systems started to face some of the problems that Macintosh had already confronted. Only by this time these machines were already an order of magnitude larger. Perhaps their OS engineers weren’t as clever as Apple’s, but they didn’t seem particularly interested in paying the price of exception handling to do a late-binding method dispatch (which is, after all, essentially what we’ve been talking about). While Apple was busily guarding and carefully managing the growth of the trap tables, other OS vendors were coming up with these things called DLLs - Dynamically Linked Libraries.

DLLs are like object code libraries, but aren’t linked directly into an application, and can generally be shared. In that sense, they can become like system software, with just one copy of a library per machine. If you put some system functionality into a DLL, you can often ship it by itself rather than wait for an entire system release. Apple has long achieved this effect by shipping extensions which, when installed, add new functionality at boot time. DLLs have the benefit, though, of not needing to load at boot time, and not having to live in a special place on disk. DLLs also have the benefit of freedom from the space constraints that trap code typically tries to live by. With the addition of file mapping and a good virtual memory system, they can even execute directly off of disk. Have a good night programming and speed up a DLL by 50%? Ship the new DLL and watch all of the apps which use it simply go faster! Other operating systems mastered this before Apple even realized that having a DLL mechanism would be a good thing to have.

Apple dabbled with ASLM, the Component Manager, and others. Fortunately, the PowerPC effort brought forth the Code Fragment Manager, the one we’ve been waiting for, and now 68K CFM is ready, too. I’ve recently been involved in an effort to build some fat code fragments for use by a dynamic language environment, and I’ve got to tell you that I am pumped!

But now I find that I want lots more fragments to play with. Wouldn’t you like to have a DLL that converted PICTs to GIF, told your Web browser to resolve a URL, or went a ftp’d a file, all with the ease of a couple of function calls? Here’s where you come in. You know that really clever or useful library you wrote and linked in to your latest application? How about that slick little shareware utility? How about releasing it as a DLL? That and a header file, and you can have thousands of grateful developers treat you like their own system software engineer. CFM is cool. If you learn just one new thing today, learn what CFM can do for you. One starting point is :

http://dev.info.apple.com/evangelism/DLLDirectional.html

I also recommend looking at Apple’s latest Developer CDs.

Food for Thought

Presenting his keynote to the Microsoft Professional Developers Conference, Bill Gates noted that he believes that the #1 reason to develop for Windows is “Volume!” That’s 60 million copies of Windows each year. As an aside, he mentioned, “30 million copies wouldn’t pay Microsoft’s bills.”