June 93 - BE OUR GUEST
BE OUR GUEST
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
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
- 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.
BY CHRIS DEROSSI
When system enablers were being designed, it was clear they were going to be a mechanism for extending
the system. Engineers began calling them INITs, since they served much the same purpose. This caused some
confusion with people who thought we really were talking about INITs, and issues were raised about
possible conflicts with other INITs, loading order, and so on. (These issues don't apply to system enablers at
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
Thanks to Chris Derossi, Greg Marriott, and Dean Yu for reviewing this column. *