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

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
all.)

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. *