• A diamond mark appears against the name of the target application in the Application menu.

  This mark is intended to prompt the user to switch the marked application to the foreground. The diamond mark only appears while the application posting the notification remains in the background. It is replaced by the familiar check mark when that application is brought to the foreground.

• The Application menu title begins alternating between the target application's icon and the foreground application's icon, or the Apple menu title begins alternating between the target application's icon and the Apple icon.

  The location of the icon alternation in the menu bar is determined by the posting application's mark (if any). If the application posting the notification is marked by either a diamond mark or a check mark in the Application menu, the Application menu title alternates; otherwise the Apple menu title alternates. Note that several applications might post notifications, so there might be a series of alternating icons.

• The Sound Manager plays a sound.

  The application posting the notification can request that the system alert sound be used or it can specify its own sound by passing the Notification Manager a handle to a 'snd ' resource.

• In Mac OS 8.6 and earlier, a modal alert box appears, and the user dismisses it (by clicking on the Cancel button). In Mac OS 9.x, a floating window appears, allowing the current application's event loop to continue running while the notification alert is on the screen.

  The application posting the notification specifies the text for the modal alert box.

• A response function, if specified, executes.

  A response function can be used to remove the notification request from the notification queue (see below) or to perform other processing. For example, it can be used to set a global variable to record that the notification was received.

• Level 1. Display the diamond mark next to the name of the application in the Application menu.

  Note that displaying the diamond mark is only possible if the requesting software is listed in the Application Menu (and thus represents a process which is loaded into memory). The requesting software may not be an application. In addition to applications, other software that is largely invisible to the user can use the Notification Manager. Such software includes device drivers, vertical blanking (VBL) tasks, Time Manager tasks, and code which executes during the system startup sequence, such as code contained in extensions.

• Level 2. Display the diamond mark next to the name of the application in the Application menu and alternate the icons. (This is the suggested default setting.)

• Level 3. Display the diamond mark next to the name of the application in the Application menu, alternate the icons and invoke an alert box to notify the user that something needs to be done.

That said, Apple accepts that this suggested strategy might not be appropriate for your application. (Indeed, notifications provided by the system software itself do not follow these guidelines.)

Notifications in Action

To issue a notification to the user, you need to create a notification request and install it into the notification queue, which is a standard Macintosh queue. The Notification Manager interprets the request and presents the notification to the user at the earliest possible time.

Eventually, you will need to remove the notification request from the notification queue. You can do this in the response function or when your application returns to the foreground.

Creating a Notification Request

     struct NMRec
     {
       QElemPtr  qLink;       // Address of next element in queue. (Used internally.)
       short     qType;       // Type of data. (8 = nmType).
       short     nmFlags;     // (Reserved.)
       long      nmPrivate;   // (Reserved.)
       short     nmReserved;  // (Reserved.)
       short     nmMark;      // Application to identify with _ mark.
       Handle    nmIcon;      // Handle to small icon.
       Handle    nmSound;     // Handle to sound structure.
       StringPtr nmStr;       // Pointer to string to appear in alert.
       NMUPP     nmResp;      // Pointer to response function.
       long      nmRefCon;    // Available for application use.
     };
     typedef struct NMRec NMRec;
     typedef NMRec *NMRecPtr;

qType	Indicates the type of operating system queue. Set to nmType (8).
nmMark	Indicates whether to place a diamond mark next to the name of the application in the Application menu. If nmMark is 0, no mark appears. If nmMark is 1, the mark appears next to the name of the calling application. If nmMark is neither 0 nor 1, it is interpreted as the reference number of a desk accessory. An application should set nmMark to 1 and a driver or detached background task (such as a VBL task or Time Manager task) should set nmMark to 0.
nmIcon	A handle to an icon family containing a small colour icon, that is to alternate periodically in the menu bar. If nmIcon is set to NULL, no icon appears in the menu bar. This handle must be valid at the time the notification occurs. It does not need to be locked, but it must be non-purgeable.
nmSound	A handle to a sound resource to be played with SndPlay. If nmSound is set to NULL, no sound is produced. If nmSound is set to -1, the system alert sound is played. This handle does not need to be locked, but it must be non-purgeable.
nmStr	Points to a string which appears in the alert box. If nmStr is set to NULL, no alert box appears. Note that the Notification Manager does not make a copy of this string, so your application should not dispose of this storage until it removes the notification request.
nmResp	A universal procedure pointer to a response function. If nmResp is set to NULL, no response function executes when the notification is posted. If nmResp is set to -1, then a pre-defined function removes the notification request immediately after it has completed. If you do not need to do any processing in response to the notification, you should set nmResp to NULL. If you supply the universal procedure pointer to your own response function, the Notification Manager passes it one parameter: a universal procedure pointer to your notification structure. For example, this is how you would declare a response function having the name theResponse: pascal void theResponse(NMUPP nmStructurePtr); You can use response functions to remove notification requests from the notification queue, free any memory, or set a global variable in your application to record that the notification was posted. Note that an nmResp value of -1 does not free the memory block containing the queue element; it merely removes that element from the notification queue. When the Notification Manager calls your response function, it does not set up A5 or low-memory globals for you. If you need to access your application's global variables, you should save its A5 in the nmRefCon field. If you are setting a global variable to enable you to determine that the user actually received the notification, you need to request an alert notification. This is because the response function executes only after the user has clicked the OK button in the alert box. If you choose audible or alert notifications, you should probably set nmResp to -1 so that the notification structure is removed from the queue as soon as the sound has finished or the user has dismissed the alert box. However, if either nmMark or nmIcon is non-zero, do not set nmResp to -1, because the Notification Manager will remove the diamond mark or the icon before the user sees it.
nmRefCon	A long integer available for your application's own use.

Installing a Notification Request

     osErr = NMInstall(¬ificationStructure);

     osErr = NMRemove(¬ificationStructure);

As previously stated, in Mac OS 9.x, notifications are non-blocking, meaning that the user can activate the posting application without dismissing the alert. For this reason, when your application is running on Mac OS 9.x, may wish to have it explicitly cancel an alert notification using NMRemove when the application becomes active.

Progress Bars and Scanning for Command-Period Key-Down Events and Mouse-Down Events

The progress indicator control was described at Chapter 14 - More On Controls. A progress indicator created using this control may be determinate or indeterminate. Determinate progress indicators show how much of the operation has been completed. Indeterminate progress indicators show that an operation is occurring but does not indicate its duration. Ordinarily, progress indicators should be displayed within a dialog box.

As stated at Chapter 2 - Low and Operating System Events, your application should allow the user to cancel a lengthy operation using the Command-period key combination. You might also include a Stop push button in the dialog box in which the progress indicator is located.

Scanning for Command-Period Key-Down Events and Mouse-Down Events in a Stop Button

• A Command-period keyboard event is found.

• A mouse-down event is found and the mouse-down was within the Stop button's rectangle.

If a key-down event is found, the next step is to determine whether the Command key was down at the time of the key press. If it was, a check should be made as to whether the key pressed was the period key. If these checks reveal that a Command-period keyboard event has occurred, the function should return immediately, returning true to the calling function.

If a mouse-down event is found, the next step is to determine whether the mouse-down was within the Stop push button's rectangle and, if so, briefly highlight the push button before returning true to the calling function.

If true is returned to the calling function, that function should terminate the lengthy operation and close the progress indicator dialog box.

Soliciting a Colour Choice From the User - The Color Picker

• A standard dialog box, called the Color Picker, for soliciting a colour choice from the user.

• Functions for converting colour specifications from one colour model to another.

Cyan, magenta, and yellow are the complements of red, green, and blue.

HLS and HSV Models

The HSL/HLV model may be represented diagrammatically by the HSL/HLV colour cone shown at Fig 1. In this colour cone, hue is represented by an angle between 0 degrees and 360 degrees.

The Color Picker

Using the Color Picker in HLS Mode

To relate Fig 3 to Fig 1, the coloured disc at Fig 3 may be considered as the HSL/HSV cone as viewed from above. The lightness slider control can then be conceived of as moving the disc up or down the axis of the cone from the apex (black) to the base (white).

Invoking the Color Picker

     Boolean GetColor(Point where,ConstStr255Param prompt,const RGBColor *inColor,
                      RGBColor *outColor);

If the user clicks the OK button in the Color Picker dialog, your application should adopt the outColor value as the colour chosen by the user. If the user clicks the Cancel button, your application should assume that the user has decided to make no colour change, that is, the colour should remain as that represented by the inColor parameter.

Coping With Multiple Monitors

The maximum number of colours capable of being displayed by a given Macintosh at the one time is determined by the video capability of that particular Macintosh. The maximum number of colours capable of being displayed on a given screen at the one time depends on settings made by the user using the Monitors and Sound control panel. In a multi-monitor environment, therefore, it is possible for each screen to be set to a different pixel depth.

In more technical terms, a Monitors control panel colours/grays setting sets the pixel depth of a particular video device. A brief review of the subject of video devices is therefore appropriate at this point.

Video Devices Revisited

• A graphics device is anything into which QuickDraw can draw, a video device (such as a plug-in video card or a built-in video interface) is a graphics device that controls screens, Color QuickDraw stores information about video devices in GDevice structures, the system creates and initialises a GDevice structure for each video device found during start-up, all structures are linked together in a list called the device list, and the global variable DeviceList holds a handle to the first structure in the list.

  The Monitors and Sound control panel stores the pixel depth and other configuration information in a resource of type 'scrn' (resource ID 0). This resource contains an array of data structures which are analogous to GDevice records. Each element of this array contains information about a different video device. When InitGraf is called to initialize QuickDraw, it checks the System file for the 'scrn' resource. If the resource is found, and if it matches the hardware, InitGraf organises the video devices according to the resource's contents. If the resource is not found, QuickDraw uses only the video device of the startup screen.

• At any given time, one, and only one, graphics device is the current device, that is, the one in which the drawing is taking place. A handle to the current device's GDevice structure is placed in the global variable TheGDevice.

  The current device is sometimes referred to as the active device.

Also recall from Chapter 11 - QuickDraw Preliminaries that two of the fields in a GDevice structure are:

• gdMap, which contains a handle to a pixel map which, in turn, contains a field (pixelSize) containing the device's pixel depth (that is, the number of bits per pixel).

• gdRect, which contains the device's global boundaries.

• Image Optimisation. To draw a particular graphic, your application may have to call different drawing functions for that graphic depending on the characteristics of the video device intersecting your window's drawing region, the aim being to optimise the appearance of the image regardless of whether it is being displayed on, say, a grayscale device or a colour device. Recall from Chapter 11 - QuickDraw Preliminaries that when QuickDraw displays a colour on a grayscale screen, it computes the luminance, or intensity of light, of the desired colour and uses that value to determine the appropriate gray value to draw. It is thus possible that, for example, two overlapping objects drawn in two quite different colours on a colour screen may appear in the same shade of gray on a grayscale screen. In order for the user to differentiate between these two objects on a grayscale screen, you would need to provide an alternative drawing function which draws the two objects in different shades of gray on grayscale screens.

• Window Zooming. The second issue is window zooming. For example, if the user drags a window currently zoomed to the user state so that it spans two screens, and then clicks the zoom box to zoom the window to the standard state, your application will need to determine which screen contains the largest area of the window, calculate the standard state for that screen (which will depend, amongst other things, on whether that screen contains the menu bar), and finally zoom the window out to the standard state for that particular screen.

• Window Dragging and Sizing. In window dragging operations in a single-monitor environment, &qd.screenBits.bounds is typically passed in the limitRect parameter of DragWindow. (bounds is a rectangle which encloses the main screen.) Similarly, in window sizing operations in a single-monitor environment, the values in the bottom and right fields of bounds are typically assigned to the bottom and right fields of the rectangle passed in the sizeRect parameter of GrowWindow. For a multi-monitor environment, you should use the rectangle in the rgnBBox field of the Region structure filled in by a call to LMGetGrayRgn. This rectangle bounds the current desktop region, which spans multiple monitors.

DeviceLoop's second parameter is a pointer to an application-defined function. That function must be defined like this:

     pascal void myDrawingFunction(short depth,short deviceFlags,GDHandle targetDevice,
                                   long userData)

Window Zooming

See Chapter 4 - Windows for a description of standard state, user state, and the state data record.

The screen on which the zoomed window should appear should be the screen on which the window is currently displayed or, if the window spans screens, the screen containing the largest area of the window. The appropriate standard state will depend on:

• The device's global boundaries, as contained in the gdRect field of the gDevice structure.

• The requirements of the application. (As stated at Chapter 4 - Windows, the standard state on the main screen is typically the gray area of the screen minus three pixels all round.)

• Whether the screen on which the zoomed window is to appear contains the menu bar.

Vertical Blanking (VBL) Tasks

The Vertical Retrace Manager schedules tasks, known as VBL tasks, for execution during the vertical retrace interrupt. The Operating System itself uses the Vertical Retrace Manager to perform certain housekeeping operations, such as updating the global variable Ticks and the position of the cursor (every interrupt) and checking whether a disk has been inserted (every 30 interrupts).

You can also use the Vertical Retrace Manager to install your own recurrent tasks which, for some reason, you do not want to execute in your main event loop. Be aware, however, that:

• The Vertical Retrace Manager is useful only for small, repetitive tasks which do not allocate or release memory.

• The Vertical Retrace Manager is not an absolute timing device. Its operations are always relative to the VBL interrupt, which is sometimes disabled - for example, during disk access. (This latter explains the jerky cursor movement experienced during disk operations.)

• Slot-Based VBL Tasks. Slot-based VBL tasks are linked to an external video monitor. Because different monitors have different refresh rates, and hence execute VBL tasks at different intervals, a separate task queue is maintained for each attached video device. When a VBL interrupt occurs for one of these devices, the tasks in the queue relating to the slot holding that device's video card are executed. A slot-based VBL task is installed using SlotVInstall.

• System-Based VBL Tasks. System-based VBL tasks apply to Macintoshes which have only a built-in monitor. On such machines, there is no need to isolate VBL tasks into separate queues. System-based VBL tasks are installed using VInstall.

• A VBL task must not allocate, move, or purge memory, or call any Toolbox functions which may do so.

• Applicable to 680x0 code only, a VBL task cannot call a function from any other code segment (see Code Segmentation, below) unless it sets up the application's A5 world properly. In addition, that segment must already be loaded in memory.

• A VBL task cannot access your application's global variables unless it sets up the application's A5 world properly.

• A VBL task's code, and any data accessed during the execution of the task, must be locked into physical memory if virtual memory is in operation.

You load a system-based task's VBL task record into the system partition when you want the task to be a persistent VBL task, that is, a task that continues to be executed even when the application which installed it is no longer in control of the CPU. (Note that slot-based VBLs are always persistent no matter where you put the task record.)

Note that, in the case of the address of the system-based task being in the application's partition, the task is re-enabled when the application receives processing time, which can occur without the application necessarily returning to foreground. For that reason, you may want to disable a system-based VBL task manually. This can be done using the same procedure as that applying to the disabling of a slot-based VBL task (see below).

Slot-Based VBL Tasks

     struct VBLTask
     {
       QElemPtr qLink;
       short    qType;
       VBLUPP   vblAddr;
       short    vblCount;
       short    vblPhase;
     };
     typedef struct VBLTask VBLTask;
     typedef VBLTask *VBLTaskPtr;

Installing a VBL Task

• Slot-Based VBL Tasks. You need to install a task as a slot-based VBL task only if the execution of the task needs to be synchronised with the retrace rate of a particular external monitor. This will be the case, for example, if you want the repetitive re-drawing of a moving image to occur only during that particular monitor's vertical blanking period.

• System-Based VBL Tasks. If the task performs no processing likely to affect the appearance of the screen, and no processing that depends on the state of an external monitor, you can install it as a system-based VBL task.

When the Vertical Retrace Manager executes the VBL task in a 680x0 environment, it places the address of the VBL task into the A0 register. The following defines an in-line function which moves that value onto the stack:

     pascal SInt32  GetVBLRec(void) = 0x2E88;

Because VBL tasks are interrupt functions, they could well execute when the value in the A5 register does not point to your application's A5 world. As a result, if you need to access your application's global variables in a VBL task, you need to set the A5 register to its correct value when your VBL task begins executing and restore the previous value upon exit.

To achieve this, your 680x0 application should save its A5 using SetCurrentA5. Then, at interrupt time, the VBL task can begin by calling SetA5 to, firstly, set the A5 register to this saved value and, secondly, save the value that was in the A5 register immediately prior to the call. The VBL task should end with another call to SetA5, this time to restore the initial value.

The only memory location that a VBL task has access to is the address of the VBL task structure. Accordingly, if your application stores its A5 directly following the VBL task structure, it can locate this value by first locating the VBL task structure. To store the A5 value directly following the VBL task structure, define a new data type whose first field contains the VBL task structure and whose second field will hold the value in the A5 register retrieved by a call to SetCurrentA5:

     typedef struct
     {
       VBLTask vblTaskStruc;  // The VBL task structure.
       long    vblA5          // Saved value of A5.
     } VBLStructure, *VBLStructurePtr;

Ensuring Compatibility with the Operating Environment

     OSErr  Gestalt(OSType selector,long *response);

     selector   Selector code.

     response   4-byte return result which provides the requested information.  When all
                four bytes are not needed, the result is expressed in the low-order byte.

     Returns:    Error code.  (0 = no error.)

• The type of machine.

• The version of the System file currently running.

• The type of CPU.

• The type of keyboard attached to the machine.

• The type of floating-point unit (FPU) installed, if any.

• The type of memory management unit (MMU).

• The size of the available RAM.

• The amount of available virtual memory.

• The versions and features of various drivers and managers.

• Environmental Selectors. Environmental selectors are those which return information about the existence, or otherwise, of a feature. This information can be used by your application to guide its actions. Some examples of the many available environmental selectors, and the information returned in the reponse parameter, are as follows:

  Selector	Information Returned
  gestaltFPUType	FPU type.
  gestaltKeyboardType	Keyboard type.
  gestaltLogicalRAMSize	Logical RAM size.
  gestaltPhysicalRAMSize	Physical RAM size.
  gestaltQuickdrawVersion	QuickDraw version.
  gestaltTextEditVersion	TextEdit version.

• Informational Selectors. Informational selectors are those which provide information which should be used for the user's enlightenment only. This information should never be used as proof positive of some feature's existence, nor should it be used to guide your application's actions. Some example of informational selectors, and the information they return, are as follows:

  Selector	Information Returned
  gestaltMachineType	Machine type.
  gestaltROMVersion	ROM version.
  gestaltSystemVersion	System file version.

Using Gestalt - Examples

     OSErr    osErr
     SInt32   response;
     Boolean  colorQuickDrawVers13Present = true;

     osErr = Gestalt(gestaltQuickdrawVersion,&response);
     if(osErr == noErr)
     {
       if(response < gestalt32BitQD13)
         colorQuickDrawVers13Present = false;
     }

     OSErr   osErr;
     SInt32  response;
     Boolean hasSoundInputDevice = false;

     osErr = Gestalt(gestaltSoundAttr,&response);
     if(osErr == noErr)
       gHasSoundInputDevice = BitTst(&response,31 - gestaltHasSoundInputDevice);

  Bit numbering as used in BitTst
  ...  7  8  9  10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
  Bit as numbered in MC69000 CPU operations, and used by Gestalt
  ...  8  7  6  5  4  3  2  1  0  15 14 13 12 11 10 9  8  7  6  5  4  3  2  1  0

  gestaltHasSoundInputDevice = 5
  31 - 5 = 26

Code Segmentation and Heap Space Optimisation - 680x0 Code

Observing the 32K limit is, however, not the only reason for segmenting your 680x0 code. Segments equate, in the built application, to units of executable code which are stored in resources of type 'CODE' and which are loaded into your application's heap as relocatable blocks. Because these resources are loaded into memory only when required, and because your application can cause them to be marked as purgeable when no longer needed, segmentation allows you to optimise your 680x0 application's heap space. Put another way, segmentation allows you to provide the user with the maximum possible heap space to accommodate the windows and user data, etc., created while the 680x0 application is running.

The main segment (that is, the segment containing the main function) is loaded and locked by the system when the application is launched. Thereafter, when the application makes a call to a function in one of the remaining segments, the Segment Loader, with no help from the application, automatically loads that segment, moves it high in the application's heap, locks it, and passes control to the called function.

Ultimately, of course, all code segments will be brought into memory and locked, creating the same memory-hogging situation as would obtain if the application had not been segmented. To prevent that situation, your application should, at the appropriate time, unlock these blocks and make them purgeable. Note that this applies to all but the main code segment, which must never be unlocked or made purgeable. The following describes an appropriate methodology for unlocking and marking as purgeable the other code segments of your application:

• Create a new stub, or "do nothing" function, for each of the code segments you want to unload. For example, this is a stub for a code segment called updateSegment:

       void  updateSegment(void) {}
  
  

• Include each stub in its associated code segment.

• Write a function called, say, doUnloadSegments which calls the Segment Loader function UnloadSeg for each of the stubs. The following is an example:

       void  doUnloadSegments(void)
       {
         UnloadSeg(updateSegment);
         UnloadSeg(activateSegment);
         // Other UnloadSeg calls here as required.
       }
  
  

  Note that each UnloadSeg call looks up the code segment that contains the stub function in its input parameter, unlocks that segment, and makes it purgeable. Note also that you could pass any of the segment's functions as the parameter to the UnloadSeg call; however, it is preferable to use stubs dedicated to this purpose because the other functions in the segment could well be moved to another segment during future updating of the code.

• Place the doUnloadSegments function in the main code segment and call it at the bottom of the main event loop (which should also be located in the main code segment) so that all code segments specified in the function will be unlocked and marked as purgeable after a received event has been handled to completion. The following is an example:

       void  main(void)
       {
         ...
         while(!gDone)
         {
           if(WaitNextEvent(everyEvent,&eventRec,MAXLONG,NULL))
             doEvents(&eventRec);
       
           doUnloadSegments();
         }
       }
  
  

Main Notification Manager Data Types and Functions

struct NMRec
{
  QElemPtr   qLink;       // Next queue entry. 
  short      qType;       // Queue type. 
  short      nmFlags;     // (Reserved.) 
  long       nmPrivate;   // (Reserved.) 
  short      nmReserved;  // (Reserved.) 
  short      nmMark;      // Item to mark in Apple menu. 
  Handle     nmIcon;      // Handle to small icon. 
  Handle     nmSound;     // Handle to sound structure. 
  StringPtr  nmStr;       // String to appear in alert. 
  NMUPP      nmResp;      // Pointer to response function. 
  long       nmRefCon;    // For application use. 
};
typedef struct NMRec NMRec;
typedef NMRec *NMRecPtr;

OSErr  NMInstall(NMRecPtr nmReqPtr);

OSErr  NMRemove(NMRecPtr nmReqPtr); 

struct ProcessSerialNumber
{
  unsigned long  highLongOfPSN;
  unsigned long  lowLongOfPSN;
};

OSErr  GetCurrentProcess(ProcessSerialNumber *PSN);

OSErr  GetFrontProcess(ProcessSerialNumber *PSN);

OSErr  SameProcess(const ProcessSerialNumber *PSN1,const ProcessSerialNumber *PSN2,
       Boolean *result);

struct QHdr
{
  short     qFlags;
  QElemPtr  qHead;
  QElemPtr  qTail;
};
typedef struct QHdr QHdr;
typedef QHdr *QHdrPtr;

struct QElem
{
  QElemPtr  qLink;
  short     qType;
  short     qData[1];
};
typedef struct QElem QElem;
typedef QElem *QElemPtr;

struct EvQEl 
{
  QElemPtr       qLink;
  short          qType;
  EventKind      evtQWhat;
  Uint32         evtQMessage;
  Uint32         evtQWhen;
  Point          evtQWhere;
  EventModifiers evtQModifiers;
};
typedef struct EvQEl EvQEl;
typedef EvQEl *EvQElPtr;

QHdrPtr  LMGetEventQueue(void);

Boolean  GetColor(Point where,ConstStr255Param prompt,const RGBColor *inColor,
         RGBColor *outColor)

mainScreen    = 11  // Graphics device is main screen.
screenDevice  = 13  // Graphics device is a screen device.
screenActive  = 15  // Graphics device is current device.

GDHandle  LMGetDeviceList(void);
GDHandle  LMGetMainDevice(void);
GDHandle  GetNextDevice(void);

Determining the Characteristics of a Video Device

void     DeviceLoop(RgnHandle drawingRgn,DeviceLoopDrawingUP drawingProc,
         long userData,DeviceLoopFlags flags);
Boolean  TestDeviceAttribute(GDHandle gdh,short attribute);

Boolean  SectRect(Rect rect1,Rect rect2,Rect resultRect);
Vertical Retrace Manager Data Types and Functions

struct VBLTask
{
  QElemPtr  qLink;
  short     qType;
  VBLUPP    vblAddr;
  short     vblCount;
  short     vblPhase;
};
typedef struct VBLTask VBLTask,*VBLTaskPtr;

OSErr  SlotVInstall(QElemPtr vblBlockPtr,short theSlot);
OSErr  SlotVRemove(QElemPtr vblBlockPtr,short theSlot);

OSErr  VInstall(QElemPtr vblTaskPtr);
OSErr  VRemove(QElemPtr vblTaskPtr);

OSErr    AttachVBL(short theSlot);
OSErr    DoVBLTask(short theSlot);
QHdrPtr  GetVBLQHdr(void);

OSErr  Gestalt(OSType selector,long *response);

void  UnloadSeg(void * routineAddr);

void ExitToShell(void);