Macintosh Toolbox

The Macintosh Toolbox is a set of application programming interfaces with a particular access mechanism. They implement many of the high-level features of the Mac OS. The Toolbox is comprised of a number of "managers," software components such as QuickDraw, responsible for drawing onscreen graphics, and the Menu Manager, which maintain data structures describing the menu bar. As the Macintosh was designed without virtual memory or memory protection, it was important to classify code according to when it should be loaded into memory or kept on disk, and how it should be accessed. The Toolbox consists of subroutines essential enough to be permanently kept in memory and accessible by a two-byte machine instruction; however it excludes core "kernel" functionality such as memory management and the file system. Note that the Toolbox does not "draw" the menu onscreen: menus were designed to have a customizable appearance, so the drawing code was stored in a resource, which could be on a disk.

Advent and implementation

The original, Motorola 68000 family, implementation of the Macintosh operating system implements system calls using that processor's illegal opcode exception handling mechanism. Motorola specified that instructions beginning with "1111" and "1010" would never be used in future 68000 family processors, thus freeing them for use such as by an operating system. As "1111" was reserved for use by "co"-processors such as the 68881 FPU, Apple chose "1010", or the number ten, as the prefix for operating system calls. Ten is represented in hexadecimal as "A", and handling illegal instructions is known as "trapping", so these special instructions were called "A-traps". [cite web|url=http://developer.apple.com/documentation/mac/OSUtilities/OSUtilities-170.html#HEADING170-48|title=A-Line Instructions|author=Apple Inc.] When the processor encounters such an instruction, it transfers control to the operating system, which looks up and performs the appropriate task. There were two advantages to this mechanism:

* It results in compact programs. Only two bytes are taken by every operating system access, in contrast to four or six when using regular jump instructions.
* The table used to look up the appropriate function is stored in RAM. Then, even if the underlying code was stored in ROM, it could still be overridden ("patched") by replacing the ROM memory address with a RAM address.

The system was further optimized by allotting some bits of the A-trap instruction to store parameters to the most common functions. For example, memory allocation is a very common task, so it should be expressed in as few bytes of code as possible. Sometimes the programmer wants to clear the memory block to zeros, so either the allocation function should take a binary parameter, or there should be two allocation functions. To pass a parameter would require an additional two-byte instruction, which would be inefficient. Having two functions would require at least an extra four bytes of RAM used for the address in the function look-up table. The most efficient solution is to map multiple A-traps to the same subroutine, which then uses the A-trap as a parameter. This is true of the most commonly used subroutines. However, the Toolbox was composed of the "less" commonly used subroutines. The Toolbox was defined as the set of subroutines which took no parameters within the A-trap, and were indexed from a 1024-entry, 4-kilobyte dispatch table. [cite web|url=http://developer.apple.com/documentation/mac/OSUtilities/OSUtilities-170.html|title=About the Trap Manager|author=Apple Inc.] (Machines with 64 and 128 KiB ROMs had only 512 entry tables. [http://www.mac.linux-m68k.org/devel/macalmanac.php Linux/m68k for Macintosh - Mac Alamanac II ] ] )

On PowerPC systems

In 1994, Apple released Macintoshes using the PowerPC architecture, which lacked hardware support for the A-trap mechanism. Because of their use in applying software patches, however, the dispatch tables were retained. The API library code underlying any Toolbox routine then does nothing except reference the dispatch table. The dispatch table linked only to emulated 68000 family code. Toolbox functions implemented in native PowerPC code have to first disable the emulator using the Mixed Mode Manager. For the sake of uniformity and extensibility, new function entries even continued to be added to the Toolbox after the PowerPC transition.

An alternative mechanism did exist, however, in the Code Fragment Manager, which was used to load and dynamically link native PowerPC programs. The PowerPC system call facility, analogous to the A-trap mechanism, was used to interface with the Mac OS nanokernel, which offered few services directly useful to applications.

Functionality

The Toolbox is composed of commonly used functions, but not the "most" commonly used functions. As a result, it grew into a hodgepodge of different API libraries. The Toolbox encompasses most of the basic functionality which distinguished the Classic Mac OS. Apple's references [http://developer.apple.com/documentation/mac/Toolbox/Toolbox-2.html Inside Macintosh: Macintosh Toolbox Essentials] and [http://developer.apple.com/documentation/mac/MoreToolbox/MoreToolbox-2.html Inside Macintosh: More Macintosh Toolbox] , similarly vague in scope, also document most of the Toolbox.

As a BIOS

Because much of the Toolbox is implemented in ROM, alongside the computer's firmware, it was convenient to use as a bootloader environment. In conjunction with resources stored on the ROM chip, the Toolbox could turn the screen gray, show a dialog box with the signature "Welcome to Macintosh" greeting, and display the mouse cursor. The capability to interact with the user without loading an operating system is best known as a Basic Input/Output System, although Toolbox facilities were not used to provide the interactive diagnostic utilities familiar in IBM PC compatibles. Indeed, in using the Toolbox to help boot the machine, a rudimentary Macintosh environment was initialized before loading the System suitcase from disk.

The similarity between the boot-up environment and the actual operating system should not be confused with being identical, however. Although the "Classic Mac OS" boot process is convoluted and largely undocumented, it is not more limited than a PC BIOS. Like a PC's master boot record, a ROM-based Mac reads and executes code from the first blocks ("boot blocks") of the disk partition selected as the boot device. The boot blocks then verify that a suitable rudimentary environment exists, and use it to load the System suitcase. A different operating system with a different file system can boot by simply using its own code in the boot blocks. [cite web|url=http://developer.apple.com/documentation/mac/OSUtilities/OSUtilities-189.html#HEADING189-31|title=Boot Blocks|author=Apple Inc.] This system was not used for PowerPC Linux, however, because Open Firmware in New World ROM machines requires a bootloader within an HFS filesystem—a reason having nothing to do with the Toolbox or "old-fashioned" Macs in general. More narrowly, the Startup Disk control panel in Mac OS and Mac OS X only allows the user to select a mounted filesystem with very particular constraints.

Legacy

In Mac OS X, the Toolbox is not used at all, though the Classic environment loads the Toolbox ROM file into its virtual machine. Much of the Toolbox was restructured and implemented as part of Apple's Carbon programming API, allowing programmers familiar with the Toolbox to port their program code more easily to Mac OS X.

ee also

*Mac OS memory management

References

External links

* [http://developer.apple.com/documentation/mac/Toolbox/Toolbox-2.html Apple's "Inside Macintosh: Macintosh Toolbox Essentials" developer's guide]