|Column Tag:||News from the
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 youre interested in programming the Mac; you dont 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 Supports 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 youd 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. Well 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 dont have your questions yet, this months column contains information that was presented at the January MacWorld Expo in San Francisco. The first is Chris Derossis presentation on MultiFinder compatibility, and the second is from the handout from Fred Huxhams presentation on writing code to be compatible with Apples 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 applications 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 shouldnt expect any events other than update events, and it shouldnt 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 wont 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 youre 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 files 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 youre 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 youve 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 applications global variables, is only valid when your applications 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 applications A5; they may be executed while A5 points to some other applications 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 applications 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 users 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:
68000 Registers (Including A5 and A7 for globals and the stack)
The Applications Layer--All of the applications 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 applications layer to the front.
This full context switch wont 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 windows proc ID to determine if its 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 dont 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 Apples 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 Users application. The purpose of the Mac interface is to provide an environment that will run the following:
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
Differences in C Compilers
Differences in Language Conventions
Here are some more notes on the remaining slides.
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, youre 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 SCCs 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.
Make sure call InitDialogs and TEInit.
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
There is no distinction between the system heap zone and the application heap zone. The routines SystemZone and ApplicZone return the same pointer.
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
Applications running under A/UX must follow the A/UX filename conventions:
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.
Under A/UX, all Macintosh files exist on a single, emulated Mac volume.
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.
Only the following File Manager low-memory globals are supported:
Slide # 8
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.
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.
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.