The main other open application that an application needs to work with is the Finder, which is responsible for keeping track of files and managing the user`s desktop. The Finder is not really part of the system software, although it is sometimes difficult to tell where the Finder ends and the system software begins.

• Toolbox functions have to do with mediating your application with the user. They relate, in general, to the management of elements of the user interface.

• Operating System functions have to do with mediating your application with the Macintosh hardware, performing such basic low-level tasks as file input and output, memory management and process and device control.

For historical reasons, some collections of system software functions are referred to as packages. In general, the distinction between managers and packages is unimportant. Packages are nowadays generally referred to as managers.

Operating System

Additional System Software

• Text Handling. Text handling on the Macintosh is fundamentally graphic in that text is drawn as a sequence of graphic elements, and is designed to support more than one script (writing system). In addition to QuickDraw (see above), the components of the Macintosh script management system (that is, the essential text handling managers) include:
  

• Interapplication Communication. The interapplication communications architecture (IAC) provides a mechanism for communication between Macintosh applications. It includes:
  

• QuickTime. QuickTime is a collection of managers and other system software components which allow an application to control time-based data such as video clips, animation sequences and sound sequences. It includes:
  

• Communications Toolbox. The Communications Toolbox is a collection of system software managers which provide an application with basic networking and communications services. It includes:
  

The mechanism of the Operating System intercepting the call to the ROM-based code provides a simple way for the Operating System to substitute the code that is executed in response to a call to a particular trap.

All traps are numbered, and a trap dispatch table in RAM (random-access memory) matches each trap's number to its address. One advantage of this arrangement is that it makes it easy to correct bugs in the ROM-based code without replacing the ROM.

The other key advantage of this arrangement is that it overcomes the unavoidable difficulty of maintaining the same address for a particular trap as newer versions of the system software are developed. (It is easy to keep the trap number the same over time but difficult to ensure that its address remains forever unchanged.)

The Appearance Manager, a system software component introduced with Mac OS 8, is unique as a manager in that it is actually delivered as an extension.

Glue Functions

Memory

A run-time environment is a set of conventions which determine how code is to be loaded into memory, where it is to be stored, how it is to be addressed, and how functions call other functions and system software routines.

The System Partition

Patches are stored as code resources of type 'INIT'. Device drivers are stored as code resources of type 'DRVR'. (See Resources, below.)

• Ticks, which contains the number of ticks since system startup. (A tick is 1/60th of a second.)

• MBarHeight, which contains the height of the menu bar.

• Pointers to the heads of various operating system queues.

• ApplZone, which contains the address of the first byte of the active application's memory partition (see Fig 1).

• ApplLimit, which contains the address of the last byte the active application's heap can expand to include (see Fig 1).

• CurrentA5, which contains the address of the boundary between the active application's global variables and its application parameters (see Fig 1 and Fig 2).

The C compiler generates the code that creates and deletes stack frames for each function call.

However, every sixtieth of a second an Operating System task checks whether the stack has moved into the heap. If it has, the task, known as the stack sniffer, generates a system error (System Error 28), which is useful during de-bugging.

By default, the stack can grow to 24KB. Accordingly, unless your application uses heavy recursion (one function repeatedly calling itself), you almost certainly will never need to worry about the possibility of stack overflow.

The reason that recursion increases the risk is that, each time the function calls itself, a new copy of that function's parameters and variables is pushed onto the stack.

• The application's executable code segments.

• Those of the application's resources (see below) that are currently loaded into memory.

• Other dynamically allocated items such as window structures, dialog structures, document data, etc.

• The application's jump table, which contains an entry for each of those of the application's functions that are called by code in another code segment, and which is used by the Segment Manager to determine the address of any externally referenced functions called by a code segment.

• Application parameters, which are 32 bytes of memory reserved for use by the Operating System, and of which the first long word is a pointer to the application's QuickDraw global variables (see below).

• The application global variables.

• Application QuickDraw global variables, which contain information about the application's drawing environment (for example, a pointer to the current graphics port).

Fig 2 shows the organisation of this data. Note that the system global variable CurrentA5 points to the boundary between the current application's global variables and its application parameters. The jump table, application parameters, application global variables and QuickDraw global variables are known collectively as the A5 World because the Operating System uses the microprocessor's A5 register to point to that boundary.

Virtual Memory

• The system partition occupies the lowest memory address and most of the remaining space is allocated to the Process Manager, which creates a partition for each open application.

• The organisation of an application partition is somewhat the same as that for an application partition in the 680x0 run-time environment. In each application partition, there is a stack and a heap, as well as space for the application's global variables.

A PowerPC application's executable code and global data are typically stored in a fragment container in the application's data fork (see Resources, below). When the application is launched, its code section and data section are loaded into memory. The data section is loaded into the application's heap. However, the location of the code section varies, depending on whether or not virtual memory is enabled.

Code Section Location - Virtual Memory Off

Application partitions (including the application's stack, heap, and global variables) are loaded into the Process Manager heap. Code sections of applications and import libraries are loaded either into the Process Manager partition or (less commonly) into the system heap. Fig 3 illustrates the general organisation of memory when virtual memory is not enabled.

Code Section Location - Virtual Memory On

An advantage of this file mapping methodology is that, when it is time to remove some of your application's code from memory (to page other code and data in), the Virtual Memory Manager does not need to write the pages back to a paging file. Instead, it simply purges the code from the needed pages, because it can always read the file-mapped code back from the paging file (your application's data fork).

In the 680x0 environment, all unused pages of memory are written into a single system-wide backing-store file and re-read from there when needed. This often results in prolonged application launch, because an application's code is loaded into memory and sometimes immediately written out to the backing-store file.

Application partitions (including the application's heap, stack, and global variables) are loaded into the Process Manager heap, which is paged to and from the system-wide backing store file. Code sections and import libraries are paged directly from the data fork of the application or import library.

Structure of the System Partition

Demise of the A5 World

Recall that the A5 world of a 680x0 application contains four kinds of data. The four kinds of data and their fate in the PowerPC environment, are as follows.

• Jump Table. A 680x0 application's jump table contains an entry for each of the application's routines called by code in another segment. Because the executable code in a PowerPC application is not segmented, there is no need for a jump table in a PowerPC application.

• Application Global Variables. In PowerPC applications, the application's global variables are part of the fragment's data section, which the Code Fragment Manager loads into the application's heap (see Fig 5). The application's global variables are always located in a single nonrelocatable block.

• Application Parameters. The application parameters in a 680x0 application occupy 32 bytes, the first four bytes of which are a pointer to the application's QuickDraw global variables. In PowerPC applications, the application parameters are maintained privately by the Operating System.

• QuickDraw Global Variables. The QuickDraw global variables in a PowerPC application are stored as part of the application's global variables.

     typedef char *Ptr;  // A pointer to a signed char.
     

     Ptr myPointer;
     myPointer = NewPtr(sizeof(WindowRecord));
     

Many system software functions can be accessed using more than one spelling of the function's name, depending on the header files supported by the development environment. For example, several years ago, the name for this function was DisposPtr.

The Memory Manager allocates one master pointer block, which contains 64 master pointers, for the application at launch time. This block is located at the very bottom of the application heap. MoreMasters may be called by the application to allocate additional master pointer blocks. To ensure that these additional (nonrelocatable) blocks are allocated as low in the heap as possible, the calls to MoreMasters should be made at the beginning of the program.

If these calls are not made, the Memory Manager will nonetheless automatically allocate additional blocks during application execution if required. However, since master pointer blocks are nonrelocatable, such allocation, which will not be at the bottom of the heap, is a possible cause of heap fragmentation. MoreMasters should thus be called enough times at the beginning of the program to ensure that the Memory Manager never needs to call it for you. For example, if your application never allocates more than 300 relocatable blocks in its heap, then five calls to MoreMasters should be enough. (You can empirically determine how many times to call MoreMasters by using a low-level debugger.)

     typedef Ptr *Handle;  // A pointer to a master pointer.
     

     Handle myHandle;
     myHandle = NewHandle(sizeof(myDataStructure));
     

A relocatable block can be disposed of by a call to DisposeHandle. Note, however, that the Memory Manager does not change the value of any handle variables that previously referenced that deallocated block. Instead, those variables still hold the address of what was once the relocatable block's master pointer. If you accidentally use a handle to a block you have already disposed of, your application could crash or you could get garbled data. You can avoid these problems by assigning the value NULL to the handle variable after you dispose of the relocatable block.

Heap Fragmentation, Compaction, and Purging

The Memory Manager continuously attempts to create more contiguous free memory space through an operation known as heap compaction, which involves moving all relocatable blocks as low in the heap as possible. However, because the Memory Manager cannot move relocatable blocks "around" nonrelocatable blocks and locked relocatable blocks, such blocks act like log-jams if there is free space below them. In this situation, the Memory Manager may not be able to satisfy a new memory allocation request because, although there may be enough total free memory space, that space is broken up into small non-contiguous blocks.

Heap fragmentation would not occur if all memory blocks allocated by the application were free to move during heap compaction. However, there are two types of memory block which are not free to move: nonrelocatable blocks and relocatable blocks which have been temporarily locked in place.

Locking and Unlocking Relocatable Blocks

For example, suppose you dereference a handle to obtain a pointer (that is, a copy of the master pointer) to a relocatable block and, for the sake of increased speed, use that pointer within a loop to read or write data to or from the block.

Accessing a relocatable block by double indirection (that is, through its handle) instead of by single indirection (ie, through its master pointer) requires an extra memory reference.

The documentation for system software functions indicates whether a particular function has the potential to move memory. Generally, any function that allocates space from the application heap has this potential. If such a function is not called in a section of code, you can safely assume that all blocks will remain stationary while that code executes.

Relocatable blocks may be locked and unlocked using HLock and HUnlock. The following example illustrates the use of these functions.

     typedef struct
     {
       short  intArray[1000];
       char   ch;
     } Structure, *StructurePointer, **StructureHandle;

     void  myFunction(void)
     {
       StructureHandle  theHdl;
       StructurePointer thePtr;
       short            count;

       theHdl = (StructureHandle) NewHandle(sizeof(Structure));
       HLock(theHdl);                    // Lock the relocatable block ...
       thePtr = *theHdl;                 // because the handle has been dereferenced ...

       for(count=0;count<1000;count++)
       {
         (*thePtr).intArray[count] = 0;  // and used in this loop ...
         DrawChar((char)'A');            // which calls a function which could cause
       }                                 // the relocatable block to be moved.

       HUnlock(theHdl);                  // On loop exit, unlock the relocatable block.
     }
     

MoveHHi is used to move relocatable blocks to the top of the heap. HLockHi is used to move relocatable blocks to the top of the heap and then lock them. Be aware, however, that MoveHHi and HLockHi cannot move a block to the top of the heap if a nonrelocatable block or locked relocatable block is located between its current location and the top of the heap. In this situation, the block will be moved to a location immediately below the nonrelocatable block or locked relocatable block.

Purging and Reallocating Relocatable Blocks

HPurge and HNoPurge change a relocatable block from unpurgeable to purgeable and vice versa. When you make a relocatable block purgeable, your program should subsequently check the handle to that block before using it if calls are made to functions which could move or purge memory.

If the handle's master pointer is set to NULL, then the Operating System has purged its block. To use the information formerly in the block, space must then be reallocated for it and its contents must be reconstructed.

Effect of a Relocatable Block's Attributes

The tag byte is the high byte of a master pointer. If Bit 5 of the tag byte is set, the block is a resource block (see below). If Bit 6 is set, the block is purgeable. If Bit 7 is set, the block is locked.

Avoiding Heap Fragmentation

• At the beginning of the program, call MaxApplZone to expand the heap immediately to ApplLimit. (If MaxApplZone is not called, the Memory Manager gradually expands the heap towards ApplLimit as memory needs dictate. This gradual expansion can result in significant heap fragmentation if relocatable blocks have previously been moved to the previous top of the heap and locked.)

  Another reason for calling MaxApplZone at the beginning of the program is that the number of purgeable memory blocks that may need to be purged by the Memory Manager to satisfy a new memory request is reduced. (The Memory Manager expands the heap to fulfill a memory request only after it has exhausted other methods of obtaining the required amount of space, including compacting the heap and purging blocks marked as purgeable.) Also, since calling MaxApplZone means that the heap is expanded only once during the application's execution, memory allocation operations can be significantly faster.

• At the beginning of the program, call MoreMasters enough times to allocate all of the (nonrelocatable) master pointer blocks required during execution.

• Allocate all other required nonrelocatable blocks at the beginning of the application's execution.

• Avoid disposing of, and then reallocating, nonrelocatable blocks during the application's execution.

• When allocating relocatable blocks that will need to be locked for long periods of time, use ReserveMem at the beginning of the program to reserve memory for them as close to the bottom of the heap as possible, and lock the blocks immediately after allocating them.

• If a relocatable block is to be locked for a short period of time and nonrelocatable blocks are to be allocated while it is locked, call MoveHHi to move the block to the top of the heap and then lock it. When the block no longer needs to be locked, unlock it.

• Function A creates a relocatable block. For reasons of its own, Function A locks the block before executing a few lines of code. Function A then calls Function C, passing the handle to that function as a formal parameter.

• Function B also calls Function C at some point, passing the relocatable block's handle to it as a formal parameter. The difference in this instance is that, due to certain machinations in other areas of the application, the block is unlocked when the call to Function C is made.

• Function C, for reasons of its own, needs to ensure that the block is locked before executing a few lines of code, so it makes a call to HLock. Those lines executed, Function C then unlocks the block before returning to the calling function. This will not be of great concern if the return is to Function B, which expects the block to be still unlocked. However, if the return is to Function A, and if Function A now executes some lines of code which assume that the block is still locked, disaster could strike.

     SInt8 theTagByte;
     ...
     theTagByte = HGetState(myHandle); // Whatever the current state is, save it.
     HLock(myHandle);                  // Redundant if Function A is calling, but no harm.

     (Bulk of the Function C code, which requires handle to be locked.)

     HSetState(myHandle,theTagByte)    // Leave it the way it was found.  (It could have 
                                       // been locked.  It could have been unlocked.)
     return;
     

Of course, this save/restore precaution will not really be necessary if you are absolutely certain that the block in question will be in a particular state (locked or unlocked) every time Function C is called. But there is nothing wrong with a little coding overkill to protect yourself from, for example, some future source code modifications which may add other functions which call Function C, and which may assume that the block's attributes will be handed back in the condition in which Function C found them.

On suitably equipped Macintosh computers (that is, those with a 32-bit Memory Manager), the Operating System supports 32-bit addressing, under which the maximum program address space is 1GB.

For compatibility reasons, systems with a 32-bit Memory Manager also contain a 24-bit Memory Manager. In order for an application to work when the machine is using 32-bit addressing, it must be 32-bit clean. Some applications are not 32-bit clean because they use flag bits in master pointers and manipulate those bits directly (for example, to mark the associated memory blocks as locked or purgeable) instead of using Memory Manager functions to achieve the same results. You must avoid such practices if your application is to be 32-bit clean.

Memory Leaks

Memory leaks can have unfortunate consequences for your application. For example, consider the following function:

     void  theFunction(void)
     {
       Ptr    thePointer;
       OSErr  osError;

       thePointer = NewPtr(10000);
       if(MemError() == memFullErr)
         doErrorAlert(eOutOfMemory);

      // The nonrelocatable block is used for some temporary purpose here, 
      // but is not disposed of before the function returns.

     }
     

The dynamic memory inspection tool ZoneRanger, which is included with Metrowerks CodeWarrior, can be used to check your application for memory leaks.

Resources

The concept of resources reflects the fact that, in the Macintosh environment, inter-mixing code and data in a program is not encouraged. For example, it is usual practise to separate changeable data, such as message strings which may need to be changed in a foreign-language version of the application, from the application's code. All that is required in such a case is to create a resource containing the foreign language version of the message strings. There is thus no necessity to change and recompile the source code in order to produce a foreign-language version of the application.

The subject of resources is closely related to the subject of files. A brief digression into the world of files is thus necessary.

About Files - The Data Fork and the Resource Fork

• The Data Fork. The data fork typically contains data created by the user.

• The Resource Fork. The resource fork of a file contains resources, which are collections of data of a defined structure and type.

The resource fork of a document file contains any document-specific resources, such as the size and location of the document's window when the document was last closed. The resource fork of an application file includes the application's executable 680x0 code and, typically, resources which describe the application's windows, menus, controls, dialog boxes, icons, etc. Fig 8 illustrates the typical contents of the data and resource forks of an application file and a document file.

The data fork can contain any kind of data organised in any fashion. Your application can store data in the data fork of a document file in whatever way it deems appropriate, but it needs to keep track of the exact byte location of each particular piece of saved data in order to be able to access that data when required. The resource fork, on the other hand, is highly structured. As will be seen, all resource forks contain a map which, amongst other things, lists the location of all resources in the resource fork. This greatly simplifies the task of accessing those resources.

Resources and the Application

• The application's resource file, which is opened automatically when the application is launched.

• The System file, which is opened by the Operating System at startup and which contains resources which are shared by all applications (for example, fonts, icons, sounds, etc.) and resources which applications may use to help present the standard user interface.

• Other resource files, such as a preferences file in the Preferences folder holding the user's application-specific preferences, or the resource fork of a document file, which might define certain document-specific preferences.

• Resource Type. A resource type is specified by any sequence of four alphanumeric characters, including the space character, which uniquely identifies a specific type of resource. Both uppercase and lowercase characters are used. Some of the standard resource types defined by the system software are as follows:

  Type	Description
  'ALRT'	Alert box template
  'CODE'	Application code segment
  'DITL'	Item list in dialog or alert box
  'DLOG'	Dialog box template
  'FONT'	Bitmapped font
  'ICON'	Large black-and-white icon
  'MBAR'	Menu bar
  'PAT '	Pattern (Space character is required)
  'PICT'	QuickDraw picture
  'SIZE'	Size of application's partition and other info
  'STR#'	String list
  'WIND'	Window template
  'sfnt'	Outline font
  'snd '	Sound (Space character is required)

  
  You can also create your own custom resource types if your application needs resources other than the standard types. An example would be a custom resource type for application-specific preferences stored in a preferences file.

  When choosing the characters to identify your custom resource types, note that Apple reserves for its own use resource types consisting entirely of lowercase characters and special symbols. Your custom resource types should therefore contain at least one uppercase character.

• Resource ID. A resource ID identifies a specific resource of a given type by number. System resource IDs range from -32768 to 127. In general, resource IDs from 128 to 32767 are available for resources that you create yourself, although the numbers you can use for some types of resources (for example, font families) are more restricted. An application's definition functions (see below) should use IDs between 128 and 4095.

You can create resource descriptions using a resource editor such as Resorcerer (which uses the familiar point-and-click approach), or you can provide a textual, formal description of resources in a file and then use a resource compiler, such as Rez, to compile the description into a resource.

Macintosh C assumes the use of Resorcerer, and all demonstration program reources were created using Resorcerer.

     resource 'WIND' (128, preload, purgeable)
     {
       {64,60,314,460},      /* Window rectangle. (Initial window size and location.) */
       zoomDocProc,          /* Window definition ID. */
       invisible,            /* Window is initially invisible. */
       goAway,               /* Window has a close box. */
       0x0,                  /* Reference constant. */
       "untitled",           /* Window title. */
       staggerParentWindowScreen  /* Optional positioning specification. */
     };
     

Resource Attributes

Note that, if both the resPreload and the resLocked attributes are set, the Resource Manager loads the resource as low as possible in the heap.

Resources Which Must Be Unpurgeable. Some resources must not be made purgeable. For example, the Menu Manager expects menu resources to remain in memory at all times.

Resources Which May Be Purgeable. Other resources, such as those relating to windows, controls, and dialog boxes, do not have to remain in memory once the corresponding user interface element has been created. You may therefore set the purgeable attribute for those kinds of resources if you so desire. The following considerations apply to the decision as to whether to make a resource purgeable or unpurgeable:

• The concept of purgeable resources dates back to the time when RAM was limited and programmers had to be very careful about allowing resources which were not in use to continue to occupy precious memory. Nowadays, however, RAM is not so limited, and programmers need not be overly concerned about, say, a few 'DLOG' resources (24 bytes each) remaining in memory when they are not required.

• Some resources (for example, large 'PICT' resources and 'snd ' resources) do require a lot of memory, even by today's standards. Accordingly, such resources should generally be made purgeable.

• As will be seen, there are certain hazards associated with the use of purgeable resources. These hazards must be negated by careful programming involving additional lines of code.

The definition function specified by the constant zoomDocProc is contained within the 'WDEF' resource with ID 0 in the System file. Note that it is possible to write your own custom window definition function (and, indeed, custom definition functions for other desktop objects such as menus), store it in a 'WDEF' resource in you application file, and specify it in the relevant field of your 'WIND' resource definitions.

Resources in Action

When your application is launched, the system first gets the Memory Manager to create the application heap and allocate a block of master pointers at the bottom of the heap. The Resource Manager then opens your application file's resource fork and reads in the resource map, followed by those resources which have the resPreload attribute set.

The handles to the resources which have been loaded are stored in the resource map in memory. The following is a diagrammatic representation of a simple resource map in memory immediately after the resource map, together with those resources with the preload attribute set, have been loaded.

Note that the handle entry in the resource map contains NULL for those resources which have not yet been loaded. Note also that this handle entry is filled in only when a resource is loaded for the first time, and that that entry remains even if a purgeable resource is later purged by the Memory Manager.

Reading in Non-Preloaded Resources

Other resources are read in by direct calls to the Resource Manager. For example, the 'PICT' resources listed in the above example resource map would be read in by calling another of the Get... family of resource-getting functions directly, for example:

     #define rPicture1 128
     #define rPicture2 129
     ...
     PicHandle pic1Hdl;
     PicHandle pic2Hdl;
     ...
     pic1Hdl = GetPicture(rPicture1);
     pic2Hdl = GetPicture(rPicture2);
     

If the application subsequently calls up the resource, the Resource Manager first checks the resource map handle entry to determine whether the resource has ever been loaded (and thus whether a master pointer exists for the resource). If the resource map indicates that the resource has never been loaded, the Resource Manager loads the resource, returns its handle to the calling function, and copies the handle to the resource map.

If, on the other hand, the resource map indicates that the resource has previously been loaded (that is, the handle entry in the resource map contains the address of a master pointer), the Resource Manager checks the master pointer. If the master pointer contains NULL, the Resource Manager knows that the resource has been purged, so it reloads the resource and updates the master pointer. Having satisfied itself that the resource is in memory, the Resource Manager returns the resource's handle to the application.

Problems with Purgeable Resources

     pic1Hdl = GetPicture(rPicture1); // Load first 'PICT' resource.
     pic2Hdl = GetPicture(rPicture2);  // Load second 'PICT' resource.
     if(pic1Hdl)                       // If the handle to first resource is not NULL ...
       DrawPicture(pic1Hdl,&destRect); // ... draw the second picture.
     if(pic2Hdl)                       // If the handle to second resource is not NULL 
       DrawPicture(pic2Hdl,destRect);  // ... draw the second picture.
     

There is a second problem with this code. Like GetPicture, DrawPicture also has the potential to move memory blocks. If the second call to GetPicture did not result in the first resource being purged, the possibility remains that it will be purged while it is being used (that is, during the execution of the DrawPicture function).

To avoid such problems when using purgeable resources, you should observe these steps:

• Get (that is, load) the resource only when it is needed.

• Immediately make the resource unpurgeable.

• Use the resource immediately after making it unpurgeable.

• Immediately after using the resource, make it purgeable.

     pic1Hdl = GetPicture(rPicture1);    // Load first 'PICT' resource.
     if(pic1Hdl)                         // If the resource was successfully loaded ...
     {
       HNoPurge((Handle) pic1Hdl);       // make the resource unpurgeable ...
       DrawPicture(pic1Hdl,destRect);    // draw the first picture ...
       HPurge((Handle) pic1Hdl);         // and make the resource purgeable again.
     }

     pic2Hdl = GetResource(rPicture2);   // Repeat for the second 'PICT' resource.
     if(pic2Hdl)
     {
       HNoPurge((Handle) pic2Hdl );
       DrawPicture(pic2Hdl,destRect);
       HPurge((Handle) pic2Hdl );
     }
     

Note also that LoadResource may be used to ensure that a previously loaded, but purgeable, resource is in memory before an attempt is made to use it. If the specified resource is not in memory, LoadResource will load it. The essential difference between LoadResource and the Get... family of resource-getting functions is that the latter return a handle to the resource (loading the resource if necessary), whereas LoadResource takes a handle to a resource as a parameter and loads the resource if necessary.

Releasing Resources

You do not need to be concerned with explicitly releasing resources loaded indirectly (for example, by a call to GetNewCWindow). Using the case of a window resource template as an example, the sequence of events following a call to GetNewCWindow is as follows:

• GetNewCWindow calls GetResource to read in the window resource template whose ID is specified in the GetNewCWindow call.

• A relocatable block is created for the template resource and marked as purgeable, as specified by the resource's attributes. (You should always specify window template resources as purgeable.)

• The window template's block is then temporarily marked as unpurgeable while:

• A nonrelocatable block is created for a data structure known as a window structure.

• Data is copied from the resource template into certain fields in the window structure.

• The window template's block is then marked as purgeable.

Main Memory Manager Data Types and Functions

typedef char  *Ptr;     // Pointer to nonrelocatable block.
typedef Ptr   *Handle;  // Handle to relocatable block.
typedef long  Size;     // Size of a block in bytes.
     

void   MaxApplZone(void);
void   MoreMasters(void);
Ptr    GetApplLimit(void);
void   SetApplLimit(void *zoneLimit);
     

Ptr    NewPtr(Size byteCount);
Ptr    NewPtrClear(Size byteCount);
Ptr    NewPtrSys(Size byteCount);
Ptr    NewPtrSysClear(Size byteCount);
void   DisposePtr(Ptr p);
     

Handle NewHandle(Size byteCount);
Handle NewHandleClear(Size byteCount);
Handle NewHandleSys(Size byteCount);
Handle NewHandleSysClear(Size byteCount);
Handle NewEmptyHandle(void);
Handle NewEmptyHandleSys(void);
void   DisposeHandle(Handle h);
     

Size   GetPtrSize(Ptr p);
void   SetPtrSize(Ptr p,Size newSize);
Size   GetHandleSize(Handle h);
void   SetHandleSize(Handle h,Size newSize);
     

void   HLock(Handle h);
void   HUnlock(Handle h);
void   HPurge(Handle h);
void   HNoPurge(Handle h);
SInt8  HGetState(Handle h);
void   HSetState(Handle h,SInt8 flags);
     

void   EmptyHandle(Handle h);
void   ReallocateHandle(Handle h,Size byteCount);
Handle RecoverHandle(Ptr p);
void   ReserveMem(Size cbNeeded);
void   ReserveMemSys(Size cbNeeded);
void   MoveHHi(Handle h);
void   HLockHi(Handle h);
     

void   BlockMove(const void *srcPtr,void *destPtr,Size byteCount);
void   BlockMoveData(const void *srcPtr,void *destPtr,Size byteCount);
OSErr  PtrToHand(const void *srcPtr,Handle *dstHndl,long size);
OSErr  PtrToXHand(const void *srcPtr,Handle dstHndl,long size);
OSErr  HandToHand(Handle *theHndl);
OSErr  HandAndHand(Handle hand1,Handle hand2);
OSErr  PtrAndHand(const void *ptr1,Handle hand2,long size);
     

long   FreeMem(void);
long   FreeMemSys(void);
long   MaxBlock(void);
long   MaxBlockSys(void);
void   PurgeSpace(long *total,long *contig);
long   StackSpace(void);
     

Size   CompactMem(Size cbNeeded);
Size   CompactMemSys(Size cbNeeded);
void   PurgeMem(Size cbNeeded);
void   PurgeMemSys(Size cbNeeded);
Size   MaxMem(size *grow);
Size   MaxMemSys(size *grow);
     

Handle TempNewHandle(Size logicalSize,OSErr *resultCode);
long   TempFreeMem(void);
Size   TempMaxMem(Size *grow);
     

OSErr   MemError(void);
     

resSysHeap   = 64   System or application heap?
resPurgeable = 32   Purgeable resource?
resLocked    = 16   Load it in locked?
resProtected = 8    Protected?
resPreload   = 4    Load in on OpenResFile?
resChanged   = 2    Resource changed?
     

typedef unsigned long  FourCharCode;
typedef FourCharCode   ResType;
     

Handle GetResource(ResType theType,short theID);
Handle Get1Resource(ResType theType,short theID);
void   LoadResource(Handle theResource);
     

void   ReleaseResource(Handle theResource);
     

short  ResError(void);