Apple's New Operating System

System 8.0 offers up-to-date OS services, such as limited preemptive multitasking, concurrent I/O, and memory protection

Tom Thompson
Byte

June 1995

Next year, Apple will release System 8.0, a major revision of its Macintosh OS. Code-named Copland, it supports two diametrically opposed goals: to deliver sophisticated OS services with a growth path to future features, yet run existing Mac software.

It was the Mac's extensive software base that forced Apple's engineers to limit Copland's capabilities in the areas of memory protection and task scheduling. But they were still able to build in sophisticated OS services, such as threads, task and I/O synchronization, hardware abstraction, and virtual memory support.

Copland is a complete redesign of the Mac OS. Like all modern OSes, Copland consolidates all its core OS services into a compact microkernel. This microkernel, along with a completely revamped I/O subsystem, provides powerful OS services without impacting performance. (For an overview, see "Copland OS Features at a Glance".)

Copland's microkernel, native OS software, and native applications are packaged as code fragments. Thus, Copland will be released first on Power Macs, CHRP (Common Hardware Reference Platform) systems, and PowerPC-based clones. Apple is still deciding whether to release a 680x0 version. Copland is expected to require 8 MB of RAM and 40 MB of disk space (20 MB for the actual code and 20 MB for a swap file).

Not all of Copland's improvements originate in the microkernel. Other parts of the OS, such as the Finder and portions of the Toolbox, have been enhanced to provide better performance or to improve the UI (user interface). For example, Copland has a scalable UI that can accommodate a user's expertise level. For the programmer, object-oriented interface element s make an application's UI much easier to build.

Safeguarding Memory

Copland's 32-bit memory architecture manages a maximum address space of 4 GB. Unlike System 7, Copland partitions this space so that 1 GB is allocated for the OS code, OS tasks, and I/O buffers. The remaining 3 GB is for applications.

Copland sets up a variable-size Cooperative Toolbox Environment space (henceforth referred to as simply the Cooperative space) where existing Mac applications and portions of the Mac Toolbox execute. The microkernel can create other, independent spaces as required for specialized applications. The PowerPC uses information from its MMU's (memory management unit's) PTEs (page-table entries) to manage memory accesses. Copland programs the PTEs to establish several types of controlled access, each of which is then enforced by the MMU. These controls include write protection, address-space isolation, and execution-mode protection.

All program code and invariant data (e. g., an interface object, such as an error dialogue string) are marked as write-protected. This feature prevents an errant memory access from corrupting key data or program code. Any such attempt creates a write-protection exception, which is fielded by an exception handler. Copland has a number of default handlers that attempt to make a graceful recovery from such exceptions as addressing errors, illegal instructions, and arithmetic overflows. Special-purpose applications can install their own handlers.

Portions of the OS reside in separate address spaces established by the MMU. This arrangement effectively walls off these parts of the OS from applications. Current System 7 Mac applications must run in the Cooperative space. Certain types of programs, such as extension code and background-only applications that don't make use of the GUI, can be placed in separate address spaces for additional memory protection. In the future, when the Toolbox code is revised for Gershwin (the code name for the next maj or Mac OS release), Mac applications will reside in their own distinct address spaces, protected from each other.

But not all the OS code and system data can be isolated. Certain information must be shared globally with applications and other OS tasks. Such code and data are protected by the execution-mode mechanism (see the figure "Copland Memory Map" ). Unlike previous versions of the Mac OS, Copland distinguishes among instructions executing in the processor's user or supervisor mode. (System 7 also made this distinction when running virtual memory, but it was only to support the page-faulting mechanism.)

The microkernel, I/O services, and device drivers operate in supervisor mode (which is also known as privileged mode), while applications run in user mode. This arrangement restricts memory accesses so that only privileged code, such as the microkernel, has the ability to modify system data structures.

Applications can access this data, but only indirectly by inv oking a kernel service through an API call. These calls, which use the PowerPC's exception mechanism, are fast and efficient. In combination with write protection, this arrangement lets applications have read-only access to globally shared data structures.

The most vulnerable section of memory is the Cooperative space, where applications reside. It offers no memory-space isolation or execution-mode protection. Apple's engineers made it this way so that this area would resemble the current System 7 run-time model and thus provide an environment where existing applications can run.

While the Cooperative space cannot provide memory-space isolation or execution-mode protection, it offers limited memory protection. Recall that all native program code, regardless of its address space, is write protected. A wild access into a native application's code--or into the Toolbox code residing in this space--causes an address exception. In such a case, Copland's exception handler terminates the offending appli cation.

An errant application can trash another application by altering its data structures, since such information can't be marked as read-only. A misbehaving application can also corrupt data used by the Toolbox code residing in the Cooperative space. In the latter situation, the Cooperative space terminates and you lose all your work inside the applications. But you can restart the Cooperative space, and--because of the memory protection--the OS itself, any network sessions, and the state of the file system are still intact. Any special-purpose background applications living in separate address spaces, such as a database engine, are also safe in such a situation.

This design compromise shields the Copland OS and native applications from most malfunctioning programs. A program would have to precisely hammer a small range of key data addresses to damage another application. In the worst possible scenario, it could only bring down the Cooperative space. This a major improvement over the current situation, where all of System 7's code and all applications are wide open and vulnerable to a stray memory access.

A New Run-Time Model

Copland sports a threaded run-time architecture for the microkernel and various parts of the OS. A thread , an independent course of execution, has its own stack and registers. It relies on resources obtained by the parent process, such as memory or access to an I/O device. Copland threads are similar to Unix Mach threads, but they are called tasks in Apple parlance. (The remainder of this article will use the Apple term.) Copland's task scheduler schedules tasks preemptively according to priority and time intervals.

Copland tasks are typically part of a team, which makes them similar to Unix Mach processes. A team is composed of one or more tasks and other kernel resources. Only the tasks within a team execute, while the resources supply the data required by the tasks. An address spac e can be occupied by multiple teams, such as the Cooperative space. However, to help implement Copland's memory-protection strategy, tasks within a team can't migrate to other teams, nor can teams move between address spaces.

A Copland process , as in System 7, is a thread of execution that represents an application started by the Process Manager. However, while a System 7 process has only a single thread of execution, a Copland process uses a team, which consists of a main task, resources, and any other tasks started by the main task.

An application's main task can create secondary tasks, which can be scheduled preemptively as long as the secondary tasks don't make use of the GUI or the Event Manager. The restriction for not using such calls is that these Managers, especially QuickDraw, still have nonreentrant code and thus can't be used in a preemptively scheduled task. These secondary tasks can manage network, disk-I/O, or computationally intensive tasks while the main task handles th e main event loop that processes user events.

The cornerstone to the new memory-protection and reentrant-code capabilities discussed thus far is the Power Mac's run-time architecture. It's based on shared libraries of code fragments that are functionally similar to DLLs. This is radically different from how System 7 resides in memory: a monolithic code block that must stay RAM-resident. Because each of Copland's services is resident only while in use, applications can use more of the 8 MB of RAM that Copland occupies.

When you create a code-fragment shared library, you can specify how its global data is to be shared. The Code Fragment Manager, the part of the OS responsible for managing code fragments, calls the microkernel to program the PowerPC's PTEs as it loads and unloads code fragments. A shared library's data can be per-context (i.e., each team has its own instantiation of the global data), privileged-only (i.e., the data is readable by all teams but can be altered only by privileged-mode code), or made up of systemwide globals, which are accessible and writable by all tasks.

On Schedule

The nerve center that coordinates all of Copland's activities is its preemptive task scheduler. Only those tasks that are written in reentrant code and that make use of reentrant Toolbox Managers can be scheduled preemptively. The reentrant Managers include any kernel services, the new File Manager, the Device Manager, the Apple Event Manager, all network protocols, and a new memory Manager called the Pool Manager (just to name a few).

Therefore, a task that makes use of I/O or networking services, or one that performs background processing, such as a database search or floating-point computations, can be preemptively scheduled. However, any task that makes use of the System 7 Memory Manager, the Event Manager, or QuickDraw can't. The scheduler arranges these tasks to execute just one at a time to satisfy the nonreentrant nature of these APIs, as shown in the figure "Cop land's Architecture" above.

Typically, an application's main task contains the calls to WaitNextEvent()and--by way of the Window or Dialog Manager--to QuickDraw, and thus has a limited execution schedule. WaitNextEvent() calls kernel services, which synchronizes the team's data with the main task.

A main task can create other, secondary tasks that have the ability to execute preemptively as long as they avoid use of nonreentrant Toolbox code. In addition, it's up to the programmer to use the main task to enforce data synchronization among other tasks. But the new File Manager and Device Manager API calls provide a completion notification mechanism--either by posting a new type of event or setting a semaphore--that notifies the main task when an I/O operation concludes. The kernel provides a variety of synchronization services, ranging from semaphores to a sophisticated message system that can pass blocks of data between tasks that have different privileges and reside in differ ent address spaces.

The task scheduler has 31 priority levels. Priorities deal with such details as real-time data handling (e.g., video and sound), responding to an application's user interface, network activity, and background tasks. The scheduler is smart enough to resolve scheduling conflicts brought about by lower-priority tasks having exclusive access to kernel resources.

While this design has its limits, the major win here is that it allows System 7 applications to continue to run. While these applications execute cooperatively, the kernel and most OS services execute preemptively. As a result, no longer does the system halt while an application tracks your mouse position in a menu, as is the case with cooperative multitasking under System 7. Instead, menu tracking continues, and so does kernel, networking, disk I/O, and other tasks.

Performance Improvements

It's a tribute to the might of the PowerPC processor that Power Macs deliver ample performance, even though more than half of System 7's OS and Toolbox code is 680x0 code running in an emulator. Copland, despite the overhead that the kernel services exact, should run faster, because 95 percent of it is native code.

For example, Copland integrates native versions of QuickDraw GX and PowerTalk, its collaboration software. The remaining 5 percent of the OS uses 680x0-processor-specific code, such as the Segment Loader. It doesn't make much sense to do a native implementation of these parts of the OS. A faster 680x0 emulator uses dynamic recompilation rather than static execution to boost the speed of this code, as well as any 680x0 application running on the system.

To improve memory performance, a new pointer-based Pool Manager provides faster allocation and access to memory blocks. The Pool Manager is also reentrant, so it can be called by the kernel and various secondary tasks.

The new File Manager employs improved algorithms and native code to deliver increased throughput. It continues to support the old API, but it provides a new API that's simpler to use while offering more capabilities. For example, the Copland File Manager has only 70 entry points, while the old File Manager had more than 150. The new API calls don't use parameter blocks; instead, they use smaller logical data structures that carry shared data between file-system calls for better efficiency. The File Manager also uses reentrant code, so tasks can have concurrent file I/O operations in progress.

Copland's virtual memory subsystem is faster, more robust, and always active. It doesn't interfere with overall system performance because it's smarter and more flexible about memory paging. Under System 7, a swap file representing a fixed memory partition had to be built at boot time. Under Copland, a swap file is built only when the Process Manager launches a new application. This way, the swap space can be disjointed files on the hard drive, and it need only be as large as the combined memory demands of the OS and any running applications. This arrangement also reduces memory fragmentation. As in the native version of System 7, file mapping is used to reduce I/O to and from the swap files.

Hardware Independence

Copland's ship date was delayed by at least six months so that a HAL (hardware abstraction layer) could be added. The HAL hides the hardware details from the kernel code so that the code can be written without any dependencies on a particular machine configuration. To this end, Copland no longer requires Mac ROMs to function. Instead, a set of bootstrap ROMs use the Open FirmWare boot process to locate the start-up drive, load Copland into memory from a disk file, and transfer control to it.

This design departure was necessary to support CHRP and clone systems that sport a diverse array of hardware. Adding a new type of device to Copland means simply adding a new device driver rather than a modification to the OS. For example, to add a low-cost PC keyboard to its design, a Mac- clone vendor provides a keyboard-driver file. Inside this file is driver code that consists of two parts: one that's hardware-specific, and one that hooks into Copland's abstraction layer. The latter portion mediates communications between the Mac OS and the hardware-specific part of the driver.

A Name Registry provides a certain level of hardware abstraction and driver-design consistency while providing device control. The Name Registry is an object database that stores information about the various devices that register themselves with Copland. It also provides for dynamic driver loading and unloading, which is necessary for devices that can be hot-swapped, such as PCMCIA cards and PowerBooks intended for docking.

Last but not least, Copland uses Open Transport to implement network services. Open Transport is based on network standards from the X/Open Group, including the XTI (Transport Interface) and the DLPI (Data Link Provider Interface). Apple's engineers used the Streams standard from Uni x System V for the protocol environment.

Open Transport thus provides network services through a single set of APIs that let applications transparently access network services using multiple protocols. Open Transport implementations of the AppleTalk and TCP/IP protocols have been completed, and IPX and serial communications protocols are currently in the works. Open Transport uses native drivers for maximum performance.

Easily Extendable

To allow Apple and third parties to extend Copland's features in the future, a new, well-documented, patching API is available. The functions of this new patching API shift from the 680x0-processor-specific, A-trap table to the processor-neutral, transition-vector mechanism used by the Code Fragment Manager. Transition vectors consist of pointers that aim at the entry points of a shared library's functions.

This mechanism shift confers two advantages. First, patch code won't incur the overhead of a context shift between p rocessor-instruction sets when a switch occurs into the emulated 680x0 environment and back. This overhead wasn't significant when the bulk of the OS was still 680x0 code, but it becomes substantial with Copland, which is chiefly native code.

Second, the transition vectors provide finer granularity over what's patched and can supply bookkeeping information. For example, many A-trap entries actually dispatch to several Toolbox functions. To patch the file Open() function, with the old patch API you had to patch the file system's entry point ( FSDispatch()) in the trap table and then filter all uses of this call until you received an Open() request. This method was prone to failure and could introduce unwanted side effects in all the functions called through that entry point. With the new patch API, you patch only the Open() function. The bookkeeping information can be used by a developer to order or disable patches for debugging purposes.

Finally, parts of Copla nd offer hooks to facilitate patching. The virtual memory subsystem uses backing objects , which are abstract entities that make up part of the page-fault mechanism. Normally, backing objects are registered with the OS and simply map sections of physical memory to swap files. However, a third-party vendor might modify a backing object's behavior so that a page fault referenced by it becomes an I/O request. This I/O request then compresses the data and writes it into a memory cache, mimicking the operation of Connectix's RAM Doubler utility.

The new File Manager allows extensions, so it can be enhanced and new foreign volume formats can be supported. It also provides notification events so that when a change occurs in the file system (e.g., a Type III drive card is removed from a slot), the OS and applications can respond to the change.

A New Look

So far this article has concentrated on Copland's infrastructure. However, there are visible changes to the UI as well . Some of these changes assist the user, while others make the programmer's job simpler.

For instance, some existing Toolbox Managers have been enhanced to make it easier to use certain interface elements. For example, the Menu Manager now has built-in support for tear-off menus and sticky menus, which formerly required extensive patching to implement. The Menu Manager also lets the user hide the menu bar or add a permanent menu (i.e., one that's present in all applications).

The Window Manager now provides floating and modal windows as standard fare. It also introduces new features, such as multidirectional window sizing and background patterns within the window's content area.

The Dialog Manager and Control Manager now offer active feedback during mouse tracking (which is essential for live document scrolling). It now also lets the user chose dialog box items via keyboard input.

In System 7, the interface elements used by these Managers (e.g., a window or a menu) consisted of sta nd-alone resources known as definition functions, or defProcs , with only one entry point. To implement a custom control or window, you had to write your own defProc resource.

For compatibility, Copland supports existing custom WDEF, CDEF, MDEF, and MBDF defProc resources. But Copland improves the situation with an object-oriented interface architecture based on the SOM (System Object Model). Instead of using defProcs, SOM helps implement Mac OS interface elements as IDOs (Interface Definition Objects). An IDO has multiple entry points, one per method. A programmer can write a custom IDO by subclassing it from a base IDO, thereby causing it to inherit all its desired behaviors. The programmer then quickly adds custom behavior by writing code to override certain methods.

Important here is the fact that, while QuickDraw is not reentrant, IDOs are. These new interface objects thus pave the way toward a future OS based on a reentrant imaging engine.

Also important, text is handled by an abstract data type known as a text object . Text objects remove the limitations of C or Pascal text strings and provide the means for manipulating multibyte foreign languages. Text objects use a Unicode converter to handle conversions between different-language text encodings. They also provide for a smooth migration to complete Unicode text encoding in a future OS release.

Copland provides several new Managers to handle the system from the user's perspective. An Appearance Manager provides new human-interface components--such as sliders, a progress indicator, and an expansion triangle--that formerly required extensive programming to implement. It also provides new APIs that draw interface elements, such as bevels, for these components.

A Navigation Services Manager supplies new standard file dialog boxes that expedite the selection of files, applications, folders, and volumes. Its behavior can be easily extended so that this window can act as a file viewer or be used to browse other data containers (e.g., a mailbox or archive) rather the file system ( see the screen ).

From the user's point of view, some of these interface benefits are obvious. Others aren't so obvious but are just as useful. For instance, the Finder is now multithreaded, so you can handle several different file operations, such as copying several files simultaneously, launching other applications, and emptying the trash, all at once.

Copland's UI is now scalable, which means that its appearance and behavior can be tailored to the user's expertise level. While details are still sketchy, Copland should closely resemble At Ease to a novice user, where items such as hard drives and the Trashcan are hidden from view. An expert user can have the familiar Finder Desktop layout, with all its hard drives, remote servers, and PowerTalk mailbox.

Copland's scalable UI means that as a user gains experience with the Mac, he or she can apply skills learned at the novice level toward the more a dvanced UI environment. This isn't the case with Microsoft's Bob, where the interface skills gained by a user don't translate to using Windows.

The Best Gets Better

Copland provides a much-needed revision of the Mac OS. It offers speed, reliability, and modern OS services through its native code, preemptive multitasking, I/O concurrency, and memory protection. The compromises made in task scheduling and memory protection are reasonable ones, particularly since they protect your software investment by allowing existing software to run. Reliability shouldn't be a concern, because parts of Copland, such as the emulator and PCI (Peripheral Component Interconnect) expansion-board drivers, will be field-tested in staged phases of the Mac OS releases.

In the inevitable comparison to Windows 95, we have to say that Copland is better. It offers Windows 95 services while still providing better features. Some of these features, such as network support through Open Transport and the use of Open Firmware to implement plug and play for expansion cards, are based on industry standards.

Furthermore, Copland offers hardware abstraction, a feature currently found only in Windows NT. This capability will help foster a growing clone market without incurring the compatibility nightmare of supporting diverse hardware--a problem that delays the release of Windows 95.

While these are important technical issues, there's also the issue of the user who'll be sitting in front of the machine. Copland's scalable UI ensures that experts and novices alike can use a Mac to their best advantage.

Copland Memory Map

The Copland microkernel uses a variety of ways to control access to the memory space. Separate address spaces provide isolation protection for certain kernel services and special-purpose applications. The microkern el code must be globally shared, but write protection safeguards it. Global data can be protected from inadvertent modification by excution protection. But 680x0 applications have no protection, because the Copland emulator treats them as data.

Copland's Architecture

Copland schedules I/O, file-system, network, and other kernel service tasks preemptively. Existing applications have a main task (or thread) that must be scheduled separately, because certain Managers use nonreentrant code. Applications can spawn other threads that can execute preemptively as long as they make use of certain kernel services.

The New Standard File Dialog Box

The new Standard File dialog box, presented by Navigation services. Notice the nested folder hierarchy in the window.

Copland OS Features at a Glance

BETTER PERFORMANCE. The first Power Macs achieved their well-known stability and compatibility by simply executing large amounts of the time-proven 680x0 Toolbox code in an emulator. With Copland, this situation is reversed: It's comprised mostly of native PowerPC code, so calls to the microkernel services benefit directly from the PowerPC's processing speed.

It's important that Copland's device drivers are reentrant native code. Thus, they provide better raw throughput over what's possible using emulated drivers, and concurrent I/O operations are supported. A native file system boosts file I/O rates, especially for virtual memory. It also offers new capabilities, such as the ability to handle hard drives up to 256 TB in size and individual files up to 2 GB in size. Finally, an improved 680x0 emulator executes the remaining portions of the 680x0 Toolbox code, and any 680x0 applications, significantly faster.

The microkernel also has a preemptive task scheduler that helps overall performance. As with other OSes, this task scheduler juggles task activity so that when one task gets blocked--perhaps while waiting on pending I/O or for access to an exclusively owned resource--other tasks still execute.

This keeps the overall system running efficiently rather than stalling when a program waits for an I/O function to complete, as is often the case with System 7. While the kernel, I/O services, and server programs created by Copland-savvy applications execute preemptively, for reasons of compatibility, existing Mac applications still have to execute cooperatively.

A MORE STABLE OS. The microkernel improves reliability through the use of memory protection, separate address spaces, and user/supervisor execution modes. Again, for compatibility purposes, this memory-protection mechanism has limitations: Applications and nonreentrant Toolbox code reside in a single Cooperative space and can trash one another, but not the entire OS.

Because of the microkernel's modular design, Apple can release portions of the OS for shakedown before Copland ships next year. For example, drivers, network services based on Open Transport, and a faster 680x0 emulator will be released with the PCI-bus (Peripheral Component Interconnect) Macs that are due out this summer. Users can depend on these services' being reliable in Copland because they will sport any bug fixes and performance-tuning accomplished during the interval.

AN EXTENSIBLE ARCHITECTURE. This is an outgrowth of Copland's modular design. Portions of the OS can readily be replaced to, say, support a new volume format or an imaging engine without having an impact on other OS services.

In recognitio n of the fact that third-party vendors often extend the Mac OS in new and useful ways, Copland's microkernel offers a well-documented native patching mechanism. For example, both the new File Manager and the high-level Toolbox supply hooks so that these portions of the OS can be readily extended.

HARDWARE ABSTRACTION. Copland's ship date was delayed so that hardware dependencies could be eliminated from every part of the OS but the drivers. Unlike previous versions of the Mac OS, Copland is not ROM-based: Instead, all the OS and Toolbox code resides in disk files.

Open Firmware, an evolving IEEE standard, is used to bootstrap the computer. This prepares Copland for the new PowerPC system hardware standard, CHRP (Common Hardware Reference Platform), which was jointly proposed by Apple, IBM, and Motorola. (For details, see "New PowerPC Standard Supports Macs," March BYTE.) This hardware abstraction also assists Mac clone vendors: They can readily add custom hardware to their system designs to add value or cut costs without requiring a drastic revision of Copland.

Copland Hot Spots

It's normal to expect some software-compatibility problems due to subtle changes that are introduced in a new OS release. Since the application run-time architecture has undergone sweeping changes under Copland, you might anticipate major compatibility problems. However, Copland supports the old run-time environment and APIs along with the new ones, so such problems might be minimal--at least on paper. The matter won't be settled until Copland ships, but we can identify the potential problem areas. Possible culprits are listed below and are arranged in order from best-behaved to worst-behaved.

-- Applications that make heavy use of network communications, such as
   mailers, group schedulers, and software-control packages. That's because
   Copland uses Open Transport to implement protocol stacks and network
   services. Also at risk are telecommunications applications, since Open
   Transport manages serial communications protocols. But because Open
   Transport will be released this summer, software vendors will have an
   opportunity to revise their programs. The bottom line: Expect to use
   the most recent version of these applicatons with Copland.

-- Drivers. The revised driver architecture is bound to create some problems
   for vendors and users alike. The PCI-bus Power Macs to be introduced this
   summer will be a proving ground for the native implementation of PCI
   drivers. However, Copland's memory-protection scheme and the need for
   reentrant code could create new problems. The bottom line: Make sure
   the PCI card or new driver extension is Copland-compatible.

-- Extensions and Control Panels with initialization code. Since Copland uses
   a native patching mechanism, an initialization-code resource that patches
   the old A-trap table simply breaks. Also, there will be many problems
   arising out of such code being loaded into disparate address spaces.
   The bottom line: Prepare to pony up the cash to upgrade all your favorite
   Extensions and Control Panels.

Tom Thompson is a BYTE senior technical editor at large with a B.S.E.E. degree 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 .