Romper Room Refugee

By Mac Developer Tech Support

Ask Apple Technical Support

by Max ApplZone

Welcome to the Macintosh Developer Tech Support column. We at Mac DTS will use this column each month to answer your questions, report on the events at Apple, and pass along new Mac programming information. This is your chance to raise issues and questions just because you’re interested in programming the Mac; you don’t have to be a certified developer working on the next Mac database.

The Mac Developer Tech Support group at Apple is a part of Developer Services, the organization whose job it is to promote and support third part developers. Tech Support’s job includes writing TechNotes, creating sample code, generally helping to improve the quality of your code, and answering programming questions via electronic mail (either MCI Mail or our own AppleLink). This column is part of an effort to make our services more visible and available to the right people (you).

If you have a programming question or a topic that you’d like to see addressed in this column, send a note (letter, postcard, letterbomb) to MacTutor Magazine, at PO Box 400, Placentia, CA 92670, c/o Romper Room. We’ll do our best to publish and answer your question.

If you are developing (or thinking about developing) a full-blown Mac application (commercial or otherwise), then you should think about joining our Certified Developer Program. Certified developers get put on our mailing list and have access to MacDTS to help answer their questions on a personal level. To inquire about becoming a Mac Certified Developer, contact the Developer Programs group at Apple Computer at (408) 973-4897.

Since we don’t have your questions yet, this month’s column contains information that was presented at the January MacWorld Expo in San Francisco. The first is Chris Derossi’s presentation on MultiFinder compatibility, and the second is from the handout from Fred Huxham’s presentation on writing code to be compatible with Apple’s AU/X, both given at the MacTutor session at the San Francisco MacWorld Expo last January.

MultiFinder Programming Tips

by Chris Derossi

Be MultiFinder Aware

Generally, being compatible with MultiFinder is easy, and mainly involves following the guidelines outlined in Inside Macintosh and the TechNotes. Being MultiFinder aware is another issue. MultiFinder awareness is actually not that difficult, and requires just a few things: a SIZE resource that describes your application’s knowledge of MultiFinder (see below), code to handle Suspend/Resume events, and sharing time with other applications by using WaitNextEvent.

With Suspend/Resume events, your application can determine when it is running in the foreground or the background. In the background, your application should run as normal, but it shouldn’t expect any events other than update events, and it shouldn’t do anything that would pull the rug out from under the foreground application (like changing its cursor).

To do background processing, your application should divide its background tasks into small chunks. Each time that your application gets background time, it should do one piece of its task, and then relinquish the processor again by calling GetNextEvent or WaitNextEvent.

When your application is in the foreground and it is waiting for a user event, it should call WaitNextEvent. This gives processor time to the background applications.

Handle ALL Events

Under MultiFinder, your application cannot prevent itself from being switched out by masking Suspend/Resume events (App4Events). If you mask out Suspend events, you will still be switched out; you just won’t know that it happened.

Be prepared to handle Update events at all times. While suspended, your windows may need updating when other windows are moved. MultiFinder will pass Update events to your suspended application until the update is performed (or until MultiFinder has tried so many times that it decides you’re never going to handle the event).

Share The File System

Now that the Finder and other applications use the File System during the execution of your program, you have to pay particular attention to your use of files. The best tip is to always use the file’s refNum, and never rely on the file name or the pathname of the file after it has been opened. Other applications, or even the user with the Finder, may rename and move the file after you have opened it, but the refNum will stay valid.

If you need to get the name or directory of an open file, call GetFCBInfo (not available on 64K ROMs) each time that you need it.

Since files that are not open can be deleted or changed, if you need a file to remain undeleted and unmodified, keep it open. If you open a file, read from it, then close it, the next time that you try to access that file, it may have been deleted, renamed, moved, modified, or opened by someone else.

And above all, CHECK ERRORS! Because you’re sharing the File System, you may not have exclusive use of it. This means that, even though you have only a few files open, for example, you may get a tmfoErr (Too Many Files Open Error). Similarly, you could get a tmwdoErr (Too Many Working Directories Open Error). And even if you’ve closed all of your files on a volume, UnmountVol will now return an error if other files are open.

Use The Right A5

In general, register A5, which points to your QuickDraw world and to your application’s global variables, is only valid when your application’s main code is running. Auxiliary pieces of code that are separate from the application (like MDEFs, VBL tasks, Time Manager routines, completion routines, etc) are not guaranteed to have your application’s A5; they may be executed while A5 points to some other application’s globals.

When such code gets executed, you should first save register A5, and then load A5 with the one from your application. This will let you get to your application’s variables, routines, and QuickDraw world. When your code has completed, be sure to restore A5 to the value it had when your routine was called.

Use The Clipboard For Cut, Copy, and Paste

Since many applications may be running, your application should not use the scrap for private data storage. If your application changes the scrap on its own, not in response to a user’s Cut or Copy, the user may see the Clipboard change unexpectedly in other applications.

On the other hand, by fully supporting Cut, Copy, and Paste with the scrap, your users will be able to easily move data among applications.

Understand When and What Happens When Switching

When MultiFinder does a context switch from one application to another, it swaps out the following things:

• Low-Memory--System-Wide Globals

• 68000 Registers (Including A5 and A7 for globals and the stack)

• The Application’s Layer--All of the application’s windows

• Trap Patches that were made from within the application

• VBL Tasks in the application heap

• Drivers in the application heap

• Time Manager tasks in the application heap

There are three cases where MultiFinder will do a context switch. The first, and most obvious case occurs when the user clicks on a suspended layer, chooses a suspended application from the Apple menu, or clicks on the small icon in the right side of the menu bar. This causes a full context switch, bringing the resuming application’s layer to the front.

This full context switch won’t occur under two conditions: when the front window of the foreground application is a dBoxProc (standard modal dialog window), and when there are pending file system calls. (When the file system calls complete, the switch will happen.)

MultiFinder checks the front window’s proc ID to determine if it’s a modal dialog. So dBoxProc windows should only be used for modal dialogs. Using this window type for other purposes will block the switching mechanism. (If you like the look of the dBoxProc, you can use a plainDBox, and draw the additional thick line yourself.)

The second two context switches can happen ANY time that GetNextEvent, WaitNextEvent, or EventAvail is called, even from a modal dialog. Neither of these switches changes the ordering of the layers, or generates Suspend/Resume events. One switch is for giving time to background applications, and the other is for passing update events to suspended applications. MultiFinder will only give background time to those applications that have the CanBackground bit set in their SIZE resource. ALL applications get background update events as needed.

The SIZE Resource

Even if your application is not going to do background processing, it should have a SIZE resource. In addition to telling MultiFinder what MF features your application supports, the SIZE resource also specifies how much memory your application needs. If you don’t have a SIZE resource, MultiFinder gives it a default partition size of 384K, which may be way too much or way too little for your app.

The SIZE resource must have an ID of -1 and contain the following data:

Flags Integer (16 bits)

Preferred size LongInt

Minimum size LongInt

The flags word is a series of 5 boolean values and 11 unused bits. All unused bits MUST be set to zero for future compatibility. The bits are assigned as follows:

Bit 15 dontSaveScreen/saveScreen

This is included for Switcher compatibility only

Bit 14 ignoreSuspendResumeEvents/acceptSuspendResumeEvents

Set this bit if your application understands Suspend and Resume events.

Bit 13 enableOptionSwitch/disableOptionSwitch

This is included for Switcher compatibility only

Bit 12 cannotBackGround/canBackGround

Without setting canBackground, your application will not get nullEvents while it is suspended.

Bit 11 dontDoOwnActivate/doOwnActivate

If this bit is set, then your application accepts the responsibility for deactivating and activating its own windows when the application is suspended and resumed. This field may also be called notMultiFinderAware/MultiFinderAware. This bit should only be set if bit 14 is also set.

The preferred and minimum sizes are the number of bytes that your application needs. So if your application runs best with 512K of RAM, but will survive with only 128K of RAM, then the preferred and minimum sizes would be 524288 (512K) and 131072 (128K).

How to be A/UX Friendly

by Fred Huxham

In figure 1 we see how applications running under Apple’s version of Unix, called A/UX, can use the Macintosh toolbox to implement the Macintosh User Interface Guidelines. The Unix program makes a toolbox call, which is routed to a A/UX toolbox ROM interface routine, which in turn calls the trap in the Macintosh ROM. A subset of the Macintosh OS traps are also provided with an interface, so that OS traps get routed to standard A/UX libraries, to perform the expected Unix function, both for OS calls from the toolbox, and from the User’s application. The purpose of the Mac interface is to provide an environment that will run the following:

• Macintosh Binaries

• Unix Applications with toolbox enhancements

• Macintosh / A/UX Applications

Fig. 1 Apple's A/UX environment

Here are some things to keep in mind when designing for A/UX compatibility:

• Differences in execution environments

• Memory Manager

• File Manager

• Differences in C Compilers

• Differences in Language Conventions

Here are some more notes on the remaining slides.

Slide #5

• 32-bit Address Violations

Directly accessing the flag bits on relocatable blocks is a fate worse than death. The Macintosh OS only uses the low-order 24 bits of an address. The high-order 8 bits are used as flag bits (Lock, Purge, Resource). A/UX however, uses full 32-bit virtual addressing. If an application directly manipulates one of the upper 8 bits of an address under A/UX, it invalidates the address.

• CPU Privileged Instructions

The A/UX Toolbox is run by an A/UX process in User Mode. Because of this, applications cannot make privileged instructions. Some MacOS applications move to and from the status register. If the motivation is to access the condition code bits, it is possible to do this by using the MOVE CCR,<ea> instruction. Because this is only available on a 68020, you must check to see that is what you are running on. If you are accessing the SR to turn interrupts on or off, you’re out of luck, only the kernel can do that.

• Direct Hardware Access

Under A/UX only the kernel is allowed direct access to the hardware. This means applications cannot:

• Access the serial port by talking to the SCC’s registers.

• Access the disk drive by talking to the disk controller chip.

• Access any of the low-memory CPU exception vectors.

In addition, not all the low-memory globals are valid under A/UX. Most that are not related to hardware are supported.

• Initialization Routines

Make sure call InitDialogs and TEInit.

•Newline Character

In the Macintosh environment, lines are terminated with a return (0x0D). In the A/UX environment, lines are terminated with a linefeed (0x0A).

Slide # 6

• Heap Zones

There is no distinction between the system heap zone and the application heap zone. The routines SystemZone and ApplicZone return the same pointer.

• Master Pointers

Under the A/UX OS, master pointers are 8 bytes long, rather than the 4 bytes used by the Macintosh OS.

• Internal Data Structures

The internal data structures of the Memory Manager are different from those in the MacOS. The heap zone header record is the same, but not all fields are used. An application should not attempt to traverse the blocks in a heap zone.

• Memory Query Routines

A/UX supports virtual memory, but the Mac memory manager routines are designed for a system that has a known amount of physical memory. At the current time, memory query routines such as FreeMem return the amount of memory that would be available if your application had started with 1 MB of free memory.

Slide # 7

• Filename Conventions

Applications running under A/UX must follow the A/UX filename conventions:

• 14-character names.

• The character / instead of : to separate directories.

• A smaller range of legal characters.

• Case sensitive filenames.

• Resource and Data Files

In the MacOS, both resources and data appear in separate forks of the same file. In A/UX, resources appear in a separate file, with the filename extension “.res”.

• Volumes

Under A/UX, all Macintosh files exist on a single, emulated Mac volume.

• Search Paths

Unlike the MacOS, under A/UX a file must be in the specified directory or it will not be found. No alternative paths are searched.

•Global Variables

Only the following File Manager low-memory globals are supported:

BootDrive

VCBQHdr

DefVCBPtr

DrvQHdr

FSFCBLen

Slide # 8

• Multicharacter Constants

The two C compilers evaluate character constants in opposite order. For example, the A/UX C compiler converts ‘ABCD’ to 0x44434241, and the MPW C compiler converts it to 0x41424344. Multicharacter constants are used commonly to define resource types.

• Spurious Warnings

The A/UX compiler generates warnings when it sees zero-length arrays, which appear frequently in the include files.

• Pascal Function Types

MPW C has an extern pascal function type used for calling most of the ROM routines. To use these same functions, an A/UX C program must use assembly glue.

• Enumerated Types

In MPW C, enumerated types can be 8, 16, or 32 bits long, depending on the range of possible values. In A/UX C, enumerated types are 32 bits long (unless packed in structures using bitfields).

Slide # 9

• Pascal vs. C Strings

Many of the ROM routines follow Pascal conventions for storing strings, pushing parameters on the stack, and returning function results. the conventions differ from standard C conventions. The A/UX Toolbox includes conversion code that takes care of most of these incompatibilities as long as you use A/UX Toolbox routines for storing and retrieving data. However, strings in resource files and in A/UX Toolbox data structures are all stored as Pascal strings.