BE OUR GUEST

SYSTEM ENABLERS

C. K. HAUN

System 7.1 introducedsystem enablersto Macintosh system software architecture. Since their introduction on some of Apple's new machines, there's been some confusion about what system enablers are for, and developers have expressed interest in writing and using them. This column will shed some light on the subject.

THE BAD NEWS
Even before beginning to describe them, we have to emphasize that system enablers aresystem software,designed and intended solely for the use of Apple Computer. Detailed descriptions of their design and use will not be released. Their functionality and implementationwillchange; any developers who try to decipher enablers and implement their own are warned that they will fail in future system releases. Donot write your own enabler or modify a current one!

Kinda harsh, huh? But we really mean it: the functionality of system enablers makes sense only for system software. Also, modifying or creating an enabler without fully understanding how one works could cause the enabler mechanism to fail silently. This could result in a machine that appears to be working correctly but does not have the full enabler functionality active, causing very hard-to-isolate crashes or other problems.

OK, SO WHAT ARE THEY?
System enablers (which were called "gibblies" in early documentation and system development releases) replace the release strategy that Apple used in the past for minor system changes needed for new hardware. The old strategy was to release a new version of the system software, such as version 6.0.8 or 7.0.1. With enablers, the differences in hardware no longer require a new system release, but instead each new machine has its own enabler (if necessary) to make the system work for that hardware.

This change was made for two reasons:

• Creating an enabler instead of a whole new system release reduces Apple's quality assurance and testing time. By creating an enabler, we're testing new code only on new machines; past machines aren't affected since the new enabler won't run on those machines. This also reduces your testing time as a third party, since you no longer have to install a new system release on all your older machines and test for compatibility; you know the system changes will affect only the newly released machines.
• Enablers reduce user confusion and unnecessary upgrades. In the past, every time a machine was released, with its corresponding new software release, users of older machines were unsure whether they needed to upgrade to the new system. Many assumed that since it was newer, it was better. While this has been true occasionally, it usually isn't (upgrading from 7.0 to 7.0.1 on a Macintosh IIcx, for example, gives the user nothing new).

Apple will continue to use system extensions or components when new functionality is being added across the product line, as with QuickTime and Macintosh Easy Open. Enablers just broaden the range of options for enhancing the user's environment.

HOW DO THEY WORK?
Nope, no cheating -- we really won't be describing the internals of enablers. But here are some general rules about their behavior.

An enabler is essentially an extension to the System file; from a programmatic standpoint itis the System file. The Resource Manager was changed slightly to recognize references to the System file (CurResFile(0), for example) as being references to the System fileandthe current enabler. The code or other resources included in the enabler file appear to actually reside in the System file.

Any new machine may have a system enabler. The enabler will contain the system-level code necessary to implement changes required for that machine. A single enabler may be used for a family of machines, or a separate enabler may be created for each new machine.

If there are multiple enablers in a machine's System Folder, the system will use onlyoneof them. The system software (System file plus enabler) is responsible for arbitrating which enabler is used on a specific machine. It looks at the machine type it's currently running on, the machines that the enabler supports, and some enabler-internal applicability flags. Note that this is how the decision is currently made; as enablers are used for more machines and in different situations, more variables may be added to the decision process.

ENABLERS AND REFERENCE RELEASES
A specific enabler may not stay around forever. Apple has announced its intention to have "reference releases" every year to 18 months; these are the system upgrades that all users will be encouraged to install. Some enablers may be rolled into a reference release, so a machine that needed an enabler for System 7.1 may not need one for System 8. This is not a hard and fast rule; some enablers may stay around forever, depending on the functionality they enable.

THE BOTTOM LINE
System enablers make everyone's life easier by encapsulating system changes for new machines in one place. But they are not for non-Apple use, and developers cannot implement them with any hope of long-term success. The safest path to take is not to think of enablers as separate files. An enableristhe system; when you encounter one on a machine, you're looking at the System file. The traditional methods (INITs, cdevs, components, and so on) are still the only supported ways for developers to extend system functionality.

GIBBLY HISTORY

It was obvious to me that we needed to change the name to differentiate system enablers from other types of system extension mechanisms. We couldn't use the term extension because that was the public name for INITs. We couldn't use addition because that term already referred to things like QuickDraw GX and AOCE.

So, I decided to use a made-up word. I wanted a word that would be memorable and one that would sound funny when used in all seriousness by executives and upper management. Hence the name "gibblies."

The engineering documentation for gibblies states that the singular is "gibbly" and the plural is "gibblies." It also states that the "g" may be pronounced hard or soft depending on the speaker's preference. In practice, the hard form (as in "give") became the one used by those in the know.

There you have it. And, yes, it was very amusing to hear the made-up word being used all over the company in serious conversation.

K. HAUN works in Apple Developer Technical Support, where he is the perennial winner of the coveted "Most Documentation Heaped on the Floor" award. Before coming to Apple he was a commercial developer, writing educational, game, and utility software on Macintosh, IBM, and Apple II platforms. His main focus in DTS is interapplication communication and application toolbox support. He's also single again; please see ad #298700 in the personal ads section of this issue.

We welcome guest columns from readers who have something interesting or useful to say. Send your column idea or draft to AppleLink DEVELOP or to Caroline Rose at Apple Computer, Inc., 20525 Mariani Avenue, M/S 75-2B, Cupertino, CA 95014.*

Thanks to Chris Derossi, Greg Marriott, and Dean Yu for reviewing this column. *