Appendix B - The Operating-System Managers



In order to reduce the programming load, the operating system provides numerous services for the programmer, grouped together to form Managers. There are a number of different managers, and as the operating system has evolved from the first Macintosh in 1984, the number of services, and the number of managers, has increased. Some routines which may be used on similar types of data are grouped together into packages. The following managers and packages which are incorporated into the operating system as of the current version of the system software (version 7), are used by the package that this thesis documents:

B.1 The Memory Manager

This part of the operating system arranges the dynamic use of memory by programs and the operating system. Macintosh programs utilise resources (see the item on the Resource manager in this section), and these resources allow a program to consist of separate pieces, which usually do not need to be in memory all at once. Some resources may be purged from memory if the need arises, and reloaded later only when they are needed. The program source is compiled into one or more "code" resources.

B.2 QuickDraw and Colour QuickDraw

QuickDraw provides all the standard graphical primitives used by all Macintosh programs. It defines a coordinate system in which to work, and ways in which to create objects that are drawn there. Only Macintoshes with 68020 processors, or above (currently 68030 and 68040) are able to handle colour information, and it is these systems which have Colour QuickDraw. One important primitive in QuickDraw is the region. A region is an arbitrary set of spatially coherent points held together in a single structure. Regions can be created from all the QuickDraw primitives, including bitmaps. The use of regions allows the Macintosh to have windows with round corners, or windows partially obscured by other items. The region is such an important and fundamental part of the Macintosh that the mathematical concept behind it has been copyrighted by Apple.

B.3 The Event Manager

The Macintosh programming paradigm also differs from the programming model used by conventional computer systems. In conventional programs, the control flow is from the start to the end, usually proceeding in a linear fashion. The course of program flow is usually plotted out when the program is written. 
 Initialise.
 Do this.
 Do that.
 Do this.
 etc.
 Exit from program.
Macintosh programs are event-driven. Although there are fixed start and end points, the exact course through the program cannot usually be determined at the time the program is written.

 Initialise.
 Repeat
   Get next event from queue and deal with it.
 Until time to quit from program.
 Exit from program.
A number of different types of events are specified by the Event Manager part of the Macintosh Operating system, some examples of which are:

All events are passed to the program in a structure which holds the time and location where the event occurred, and also the state of the keyboard modifier keys (Shift, Command and Option) at the time of the event. Since the event queue is finite in length with normally slots for only twenty events, it is possible for the queue to fill up. If this happens then old events are discarded. For this reason is it necessary to check the event queue regularly for incoming events and it is a good idea to check the queue when lengthy operations are being performed - in case an important event is lost when the queue fills up. It would be possible, for example, to have a program which performs a lengthy calculation, and which is able to simultaneously process keyboard input by interleaving the calculation with checks on the contents of the event queue for key events.

B.4 The Font Manager

Another aspect of the Macintosh when it was first introduced which was different from text-based computer systems was its font handling. The font manager is used whenever a piece of text is drawn by QuickDraw. The Macintosh provides routines for manipulating fonts and hence character strings. Fonts are identified by a name (e.g. "New York"), and a font number.
There is provision for handling both Roman and non-Roman text systems, including systems which write from right to left. The package documented in this thesis can utilise any text system in order to target it correctly for a particular language and for a particular user, since this facility is a standard part of the operating system, and can be employed with very little extra programming effort.

B.5 The File Manager

Every Macintosh file is split into two parts, or forks, either of which may be empty. These two forks are known as the data fork and the resource fork. The data fork corresponds to the sort of file found on other systems, and operating system routines exist to permit reading and writing of bytes. The resource fork holds a program's resources (see section B.6). The standard routines for accessing the data fork are usually not applied to the resource fork. Most access to the resource fork is via routines in the resource manager. Although a file has two forks they are conceptually one file, and copying and deleting of a file via the desktop interface affects both parts.

B.6 The Resource Manager

The only operating system support for this fork is reading, writing and the positioning of the file-pointer. The resource fork holds structured data called resources. The concept of the resource is important since it allows the customisation and modification of programs without the need to modify the source code of the program at all. This facility permits changing textual resources so as to change the language (for example from English to French). Each resource has a 4-letter type (each particular type has a well defined structure), an ID which is an integer between -32767 and +32768, and a name, which may be blank. The resource file is composed of a resource map, containing handles to all the resources (see Appendix C for further information about handles), and the resources themselves, which follow the map directly. Adding, modifying and deleting resources is made easy since consolidation of the resource file is done only when it is finally written or closed. There is no need to move large amounts of resource data around whenever a new resource is inserted. There are a large number of operating system-supported operations on this fork. Resources are referred to by their 4-letter type, and then either their name, or else their ID.
In order to produce resources for a program it is necessary to construct them using a program on the Macintosh. The standard program for the construction of resources is Apple's ResEdit. It gives a graphical view of resources, and contains tools which permit the graphical modification of resources, where this is appropriate - e.g. it contains a graphical editor for modifying "ICON" resources. ResEdit displays an icon for each type of resource present within the currently opened resource file. In this way it is possible to tell at a glance if a particular type of resource is used by a program. A more detailed discussion of the use of ResEdit, and details of typical resource structures, are given later in appendix E and appendix F.

B.7 TextEdit

This part of the Macintosh Operating System provides all the core services for simple text-editing operations (such as the entry of small amounts of text into dialog boxes etc.). The services provided are used by most Macintosh programs and so provide consistency across applications. The amount of text handled must be less than 32,767 characters, since TextEdit has this limit built in. Cutting and pasting of text is fully supported by TextEdit routines. EditText items in dialog boxes (see section B.8) are handled by TextEdit.

B.8 The Dialog Manager

This handles all aspects of the display and update and control of dialog boxes. Dialogs are an often-seen aspect of typical Macintosh programs (see figure B.1 for an example dialog box). They are usually used to request information, or to display results. Dialog boxes can contain a number of different items:


fig. B.1 Dialog box with examples of most major dialog item types.


B.9 The Sound Manager

This set of routines has undergone considerable changes from the implementation found in the earliest Macintoshes. The idea behind the sound manager is that it handles all the details of sound production independent of the underlying hardware. Different models of Macintosh have different sound capabilities (for example stereo is available from a special Apple Sound Chip on some models and not on others), and the sound manager provides routines to tell the programmer whether a particular feature is available. This depends on the sound hardware, and also on how busy the processor in that particular model of Macintosh is. For example, a fully-loaded processor cannot handle another channel of sound, whereas an idling processor can. In the latest Macintoshes sound is handled by a digital signal processor, giving access to much higher quality sound, and taking the processing overhead required for sound production away from the cpu.

B.10 The Alias Manager

An alias is a system by which an item can appear to be available from many places, without the need to have multiple copies of the item. The alias manager is responsible for handling access to all aliases. A new feature of the file manager under operating system version 7 is the concept of the file alias. This permits the same file to appear to exist in more than one place simultaneously. After creating an alias to a file, any normal attempt to access the alias leads to accessing the real file instead. Aliases can also be created for other types of item. They are used extensively in QuickTime (see section B.11). Rather than have multiple copies of movie segments, aliases to the segments are used. In this way it is possible to have presentations that reference movies in multiple places without the need for multiple copies of the actual movies.

B.11 QuickTime

QuickTime is really a combination of two Macintosh managers - the Movie Toolbox, and the Image Compression manager. QuickTime brings the ability to record sequences of images, termed a movie, and play them back in real time. Without image compression this would require not only a vast amount of storage space for the movie, but also the bandwidth of the device on which the movie is stored would need to be large. Typically the bandwidth of a CDROM drive would not be large enough for this task, and so this would preclude a CDROM from being used as a storage device for real-time image sequences. However, since QuickTime includes compression, a CDROM drive is able to handle the throughput of a QuickTime movie, and the decompression task does not require a very powerful CPU. This means that many QuickTime movies can play from CDROM even on the lowest CPU-power colour-capable Macintosh. Currently QuickTime requires at least a 68020-based Macintosh. Some of the compression/decompression schemes offered by QuickTime are extremely non-symmetric (e.g. it takes approximately eight seconds on a Macintosh Duo 230 to compress a single frame of a movie, which will play back - uncompress - at fifteen frames per second), so compression is often performed by high-power systems, though the target system for playback may be very much less powerful. QuickTime makes use of the alias manager (see section B.10) to help reduce movie storage requirements. If one movie needs to include a section of another movie it is possible to make it include an alias as a reference to the other movie, rather than holding a copy of the movie data itself.

QuickTime has a several algorithms available, only some of which are suitable for moving images.


QuickTime is one of Apple's modular extensions to the Operating System, and is supplied in a separate file, called an extension, which is dropped into the System Folder of the host Macintosh. Many of Apple's operating system enhancements are installed in this manner.
back to Appendix A. forward to Appendix C