Apple rewrites the Mac OS to help support clone systems
Tom Thompson
Late last year, Microsoft announced that the release of its latest revision of Windows, now known as Windows 95, was going to be delayed until August of this year. Microsoft wanted to fine-tune Windows 95 to operate on the widest possible range of PCs. With a remarkable knack for timing, Apple also happened to announce that the next revision of its Mac OS, code-named Copland, was going to be delayed until early 1996 (see "Apple's New Operating System," June BYTE). Apple needed the extra time to structure its new OS around a HAL (Hardware Abstraction Layer). The irony is that these delays came about because both companies were grappling with the same basic p
roblem: how to support the hardware diversity present in desktop computers.
Apple had originally planned to add the HAL in a Mac OS revision due out after Copland. However, the woes Microsoft experienced attempting to support today's numerous hardware configurations had major implications for anyone trying to sustain a nascent Mac clone market. Because Copland is a complete revamp of the Mac OS architecture, it made sense to incorporate hardware abstraction while the system software was still under construction. This decision delayed Copland's release date, but hopefully the future payoff is that Apple has minimum support headaches when the droves of Mac clones and PowerPC-based CHRP (Common Hardware Reference Platform) systems appear.
Fundamental Changes
In previous Mac OSes, the system code relied on the numerous custom ASICs that are the hallmark of the Mac hardware. With Copland, the HAL hides the hardware from the system software so that it can be written without an
y explicit or implicit dependencies on a particular hardware configuration.
It should be noted that efforts to decouple the Mac OS from the hardware were under way with the release of the first Power Macs: The PowerPC version of System 7.1 was built around a nanokernel. This nanokernel operated in the supervisor mode and provided low-level interfaces for interrupts, exception handling, and MMU (memory management unit) operations. Only System 7 and debuggers had access to these interfaces.
Also, the basic building blocks of any PowerPC Mac program, called code fragments, use a pointer-based, processor-neutral access mechanism. The access mechanism is the basis of the dynamically loaded shared libraries that Copland uses to reduce its footprint in memory.
One consequence of this redesign is that Copland is no longer a ROM-centric OS, but a disk-based one. Put another way, Copland doesn't need the massive 4-MB ROMs that house the OS code in existing Macs. Instead, a bootstrap ROM uses the Op
en Firmware (IEEE standard P1275) boot process to configure expansion boards and locate a start-up hard drive. When the system finds the boot drive, it reads files containing the code fragments that make up the Copland OS into memory. Once this is done, execution jumps to the microkernel, and Copland takes control.
New Driver Design
Hardware abstraction required a major change in how the Copland device drivers were written. Formerly, devices were operated through the Mac API. First you obtained device-specific information through calls to managers such as the Slot Manager for NuBus boards and the SCSI Manager for SCSI peripherals. Then you controlled these devices using Device Manager calls.
The preliminary Copland driver design bifurcates between a device-specific code module and OS interface modules that use the API calls. This division resolves certain compatibility problems. Specifically, device-specific code must be reentrant to support the preemptive scheduling exp
loited by the new concurrent Device Manager, and some Mac API code isn't reentrant.
The split design also enables the driver to operate in privileged mode, within a separate memory space. This provides memory protection while allowing the main driver to exercise fine control over system services, such as interrupt handling or memory paging. That wasn't possible when all calls went through the Mac API.
Applications make the usual calls to these APIs, such as to the File Manager for file I/O and the Sound Manager for sound I/O. These managers in turn call a device-specific interface, the FPI (Family Programming Interface), which is designed for the needs of that device category (e.g., sampling rates for sound playback). The FPI accesses a specific device via its driver. The FPI abstracts the class of device, while the driver abstracts a specific device in the class (see the figure
"Anatomy of a Copland Driver"
).
Consequently, a Copland device driver is a plug-in m
odule that consists of three parts: the main driver, a configuration section, and a control section. The main driver operates in privileged mode and uses device-level programming interfaces to operate the hardware. The main driver makes no assumptions about the hardware's settings or configuration. It makes no API calls. Instead, the main driver obtains setup information through data sent to it via the configuration section.
The configuration section obtains system information for the main driver and manages other high-level functions for it, such as reading device settings from a resource file. It also manages a user interface that lets users adjust the device's settings and lets the main driver notify users of certain conditions (perhaps displaying a dialog box that warns of an invalid baud rate).
The control section is that part of the driver that mediates transactions between the OS and the main driver. It uses standard services exported by the family to accomplish this. Astute readers will
notice that this driver design parallels Open Firmware's device definition, which consists of a device interface (which manages low-level device initialization and control), a client interface (which communicates with the driver), and a user interface (which handles user interaction with the device settings).
What's in a Name?
A Name Registry helps provide a certain level of hardware abstraction and driver-design consistency while providing device control. The Name Registry is an object database that manages the creation of device entries (either at boot time or on the fly). It also stores information about the various devices in the system. For example, a second SCSI port on a clone system would register itself and its characteristics with the Name Registry, which makes Copland aware of its existence. Applications or the File Manager can readily access a peripheral on this port by using its name and associated information from the Registry.
The Name Registry enables a c
onsistent set of rules for device access, which simplifies the writing of Mac drivers. Formerly, you had to use different driver designs to access devices on NuBus boards, PCMCIA cards, or the main logic board. Because device entries are created dynamically, the Registry supports driver loading and unloading. This lets Copland manage hot-swappable devices, such as PCMCIA cards, or identify the peripherals in a docking station when a notebook computer gets plugged into it. The Registry also provides the means to update expansion boards: It can be instructed to load an updated driver from a disk file rather than from the board's firmware.
Opaque Data
Copland also conceals other dependencies. Currently, both the OS and applications access certain information (e.g., the height of the menu bar, the reference number for the boot drive, and the graphics device handling the main screen) stored in global variables located in low memory. Under Copland, you should no longer directly acces
s these variables, but instead use accessor functions to obtain this information. Accessor functions were first implemented in System 7.1, but anyone cruising through the SDK header files could see these function calls were simply macros that touched the low-memory globals. This won't be the case with future OS releases, so if you need to use low-memory globals, start using the accessor functions.
Speaking of header files, all those system-data structures in them that you know and love disappear. As with the global variables, you'll use accessor functions that reference them. Concealing the data this way, often called
data hiding
or
data opacity
, provides needed flexibility in the OS design. This allows data structures to be revised without impact to the application software. It also lets them be placed elsewhere in memory, even separate address spaces, in the future. Data hiding under Copland is limited because the OS must support existing application binaries.
Copland handles
text as an abstract object called--not surprisingly--text objects. Text objects don't suffer the limitations of C or Pascal strings. They also extend string data by allowing you to add annotations to the text. Such annotations might provide pronunciation hints for the PlainTalk text-to-speech engine. Text objects are opaque; you needn't worry about their contents. This lets them manage multibyte text encodings, such as kanji and Arabic, and they will provide a smooth migration to Unicode. Under Copland, a Unicode converter transparently manages translations from one text encoding to another.
All these mechanisms help free Copland from the bonds of a particular set of hardware. Thus, Mac-clone vendors can differentiate their systems by adding unique devices. The new driver design enables vendors to quickly write drivers for new peripherals. The Name Registry allows Copland to both understand and exploit features in a particular peripheral, such as a SCSI drive that supports Fast SCSI transfers. Finally
, through data opacity, Copland readies the Mac OS for future enhancements.
illustration_link (12 Kbytes)
An FPI (Family Programming Interface) hides details about a class of device (e.g., video). The Name Registry manages information about the device's characteristics and its name. Each device in the class is managed by a plug-in driver module that controls the hardware.
Tom Thompson is a BYTE senior technical editor at large with a B.S.E.E. from the University of Memphis. He is an Associate Apple Developer and author of Power Macintosh Programming Starter Kit (Hayden Books, 1994). You can
reach him on AppleLink as T.THOMPSON or on the Internet or BIX at
tom_thompson@bix.com
.
Copland: The Abstract Mac OS
