DIFFERENCES FROM LVSIDE MACINTOSH

The last section explained the differences between the UCSD Pascal Toolbox interface and the Lisa Pascal interface with regard to data representation. This section deals with the differences from Inside Macintosh with regard to which Toolbox routines may be called.

The differences explained here stem from three causes. First, UCSD Pascal uses memory in a slightly different way than Lisa Pascal does. Second, the UCSD Pascal implementation performs many of the necessary initialization steps described in Inside Macintosh. Finally, the implementation of procedure pointers (ProcPtrs) imposes some restrictions.

Memory Restrictions

This section explains briefly how UCSD Pascal uses Macintosh memory, and how this affects application programs. For a more detailed description of memory usage see the chapter MEMORY MANAGEMENT.

The important points about UCSD Pascal memory usage are as follows:

• UCSD Pascal uses the Macintosh stack for its stack.

• The UCSD Pascal heap is implemented as a nonrelocatable Macintosh block within the Application Heap Zone. This block expands and contracts according to heap usage. All data allocated with new or varnew is allocated here.

5-20 1200301:05B

DIFFERENCES FROM INSIDE MACINTOSH

• The boundary between the end of the Application Heap and the stack (AppILimit) moves to accomodate the growth of the stack.

The rule to remember when making Memory Manager calls from UCSD Pascal is:

• DON'T allocate a nonrelocatable block immediately above the UCSD Pacal heap if you plan to make use of the Pascal heap.

The nonrelocatable block you allocate will most likely be positioned immediately above the heap by the Macintosh Memory Manager. This will prevent expansion of the Pascal heap. When you need to create a nonrelocatable memory area, you should use the UCSD Pascal intrinsics ~ or varnew. You can then convert the 16-bit pointer returned by these intrinsics into a 32-bit address by using the function absadr.

For reference, here is a list of the ways that a nonrelocatable block can be created.

• A call to NewPtr creates a nonrelocatable block.

• A call to HLock makes a relocatable block nonrelocatable.

• A call to New Handle can cause a new block of master pointers to be allocated. These are put in a nonrelocatable block. The UCSD Pascal runtime software pre allocates a block of 64 master pointers. In order to increase this number you need to define a new resource file for your program. The example RMaker input below will allocate 2 master pointer blocks for a total of 128 master pointers. The GNRL type MSTR defines the number of master pointer blocks that should be prellocated.

WY.RSRC

APPLPROG ;; Output fi Ie name

;; Type = APPL, Creator PROG INCLUDE UCSD Pa.cal l:Empty Program

;; Required re.ource.

TYPE MSTR = GNRL ,0 (32)

.H

0002 ;; Allocate. 2 ma.ter pointer blocks

MACINTOSH INTERFACE Chapter 5

Here is a list of which routines from the memory manager must be used differently from what is described in Inside Macintosh.

SetGrowZone. You must not install your own grow zone function for the Application Heap Zone. The Pascal runtime system already has one. You may, however, use your own grow zone function in a heap zone of your own creation.

InitApplZone. This routine is not supported, because calling it will corrupt the UCSD Pascal code and data structures that are kept in the Application Heap Zone.

SetApplBase. This routine is not supported, because it will interfere with Pascal's use of the Application Heap Zone.

SetApplLimit. This routine is not supported, because the UCSD Pascal runtime support software automatically adjusts the Macintosh's ApplLimit variable for you. Calling this routine will interfere with Pascal's use of the Application Heap Zone.

There are two general strategies of memory use that an application can employ. An application could make use of the Pascal heap. If so, the program must be especially careful about use of the Macintosh memory management routines.

Alternatively, an application could avoid use of the Pascal heap altogether. In this case, the program may use the Macintosh memory management routines with a little less care than if the Pascal heap were being used.

There are some special considerations regarding dereferencing a handle under UCSD Pascal. In particular, there are more ways that the Memory Manager can be called Ifbehind your back"

when UCSD Pascal code is running. Here is a list of ways that the memory manager may be called.

5-22 1200301:05B

DIFFERENCES FROM INSIDE MACINTOSH

• Calling a procedure (especially one with local data) can cause a stack fault, which will result in some memory management functions being performed. A stack fault can also occur when using long in tegers an d sets in U CSD Pascal.

• Calling an external procedure or a system intrinsic can cause a segment fault, which causes a code segment to be read into memory. This action will result in some memory management functions being performed.

• Allocating data on the Pascal heap with ~ or mark can cause a heap fault, which can result in memory management functions being performed.

NOTE: Calling a Macintosh ROM routine that is declared as an in-line procedure or is an external procedure implemented in assembly language will never cause a stack fault. Thus, it is safe to pass a dereferenced handle to most ROM routines.

Initialization

This section describes some initialization routines described in Inside Macintosh that do not need to be called from a UCSD Pascal program. Some of these routines are not available at all.

InitGraf. InitGraf is not available in the UCSD Pascal interface to QuickDraw. The operations performed by InitGraf are done automatically.

FlushEvents. FlushEvents(everyEvent,O) is done by the UCSD Pascal runtime support initialization code. There is no need to call FlushEvents in the initialization of your program.

InitDialogs. InitDialogs is done by the UCSD Pascal runtime support initialization code. You may call InitDialogs yourself if you want to install a restart procedure in the system.

MACINTOSH I:"JTERF ACE Chapter 5

InitFonts. InitFonts is done by the UCSD Pascal runtime su pport initialization code. There is no need for your application to call1nitFonts.

Init Windows. Init Windows is done by the UCSD Pascal runtime support initialization code. You should not call lnit Windows yourself, since it allocates a nonrelocatable block on the Application Heap Zone.

TEInit. TElnit is done by the UCSD Pascal runtime support initialization code. You must not call TEInit yourself.

The following calls are made for your program when the "Create Default Window" option described by Runtime Parameters in GENERAL OPERATIONS is enabled. In that case, you do not need to call them.

SetPort. If the "Create Default Window" option (which can be enabled or disabled by using the utility Set Options) is disabled, you must call SetPort yourself before using any QuickDraw routines.

NewWindow. If the "Create Default Window" option is disabled, you must open a window yourself before you do any writing to the screen.

InitCursor. If the "Create Default Window" option is turned off you will need to call InitCursor from your application in order to reset the cursor to be an arrow.

HideCursor. In order to make the cursor visible, call ShowCursor.

5-24 1200301 :05B

DIFFERENCES FROM INSIDE MACINTOSH

Procedure Parameter Restrictions

Due to the implementation of procedure parameters to the Macintosh Toolbox, there are some restrictions on their use beyond what is described in Inside Macintosh. These restrictions are as follows.

• You may not supply an I/O completion routine to an asynchronous I/O call. Instead, you must poll the parameter block to determine I/O completion.

• You may not implement a vertical retrace procedure.

These restrictions are due to the fact that the implementation of ProcPtrs will not handle asynchronous calls to an action procedure.