Mac OS 8 Checklist

Ensuring your software will work properly

By Steve Kiene

Copland (now officially restyled “Mac OS 8”) represents the greatest evolutionary step in the operating system that the Macintosh has seen in its twelve-year history. It is unrealistic to expect that all software will work with it unmodified. Although Apple’s engineers have striven to provide as much backward compatibility as possible, there are several areas which can cause problems for your software. This article will outline what you can do to your software now to ensure that it will run unmodified under Mac OS 8. First, we’ll discuss the common types of products and how they will transition to Mac OS 8. Next, we’ll talk about the changes you’ll need to make to your products to make sure they are compatible with Mac OS 8. Third, we’ll list some things you can do to make your product run better under Mac OS 8.

Common Product Types

The most common types of products fall under the following categories:

Applications with a user interface

This accounts for most Macintosh software. Most applications will run unmodified in Mac OS 8. There are, of course, many changes you can make to your application to get better performance in Mac OS 8 (this will probably furnish material for a future article!).

Faceless background applications

These are many types of application which lack a user interface, including applications which provide services but do not directly interact with the user. These can be migrated to Mac OS 8 either as a server program or as a Mac OS 8 application. (A server program is a new application type in Mac OS 8; still more material for a future article?)

Control panels and desk accessories

These are typically small pieces of code with a single window and a simple user interface. These are not supported under Mac OS 8. You should rewrite them to be applications or, if applicable, perhaps as OpenDoc Part Editors.

Extensions (INITs)

Extensions are typically used to modify or extend the functionality of the operating system. This type of code is ignored in Mac OS 8. Your transition options are to accomplish the same functionality either as a server program or as a regular application. There is a different way to patch Mac OS 8 to extend its functionality - by using the Patch Manager (wait, don’t tell me; a possible future article!).

Drivers (DRVRs)

Drivers are typically used to communicate with peripheral devices. They fall into two categories: code that touches hardware, and code that doesn’t. If your driver touches hardware, you will need to rewrite it as one of the following:

1. A specific Mac OS 8 family plug-in. For example, an ethernet driver such as .ENET must be rewritten as an Open Transport networking plug-in.

2. A Device Manager plug-in. This type of driver is known as an NDRV, or Native Driver. You can find more information about writing Native Drivers in the document entitled “Designing PCI Cards and Drivers for the Power Macintosh Computer”, available from Apple.

For drivers which do not touch hardware, the requirements are less stringent. Your driver can be modified to be one of
the following:

1. A specific Mac OS 8 family plug-in. For example, an AppleTalk protocol module such as .ADSP can be rewritten as an Open Transport network plug-in. Drivers written in this way are available for use by both cooperative and re-entrant clients.

2. A Device Manager family plug-in. This option applies to drivers that do not become Mac OS 8 family plug-ins.

3. A DRVR using only backward-compatible APIs. This option is not available to any drivers which are part of the page fault path. Any driver which may be called in the path of a page fault must be rewritten to be a Mac OS 8 I/O plug-in.

Steps To Mac OS 8 Compatibility

To make sure your application at least works under Mac OS 8, you may need to make some changes to your source code. Most of these changes are minor, and Apple has warned about their use before; some of them are a surprise, but at least we’re getting some advance warning so we can change our applications now.

1. Don’t use ASLM. ASLM is not supported under Mac OS 8. You will need to use the Code Fragment Manager or SOM to handle shared library functionality.

2. Don’t access the trap table directly. Don’t make assumptions about the structure of the trap table. Its location, size, and structure are all private. Execution of entries is supported only through A-Traps or through NGetTrapAddress. Modification of entries is supported only via NSetTrapAddress.

3. Don’t use jGNEFilter to intercepts events globally. Mac OS 8 has limited support for jGNEFilter. The filter will be called only for events intended for the application which installed the filter.

4. Don’t call PPostEvent. Events put into the event queue with PPostEvent will be available only to the application which posted the events.

5. Don’t call GetEvQHdr. It points to an empty list. Events are maintained on a per-application basis.

6. Don’t access private traps or private LowMem. All pri-vate traps have been removed from the Mac OS 8 trap table.

7. Don’t use PrivateInterfaceLib. On all current PowerMac machines there exists a code fragment called PrivateInterfaceLib. This contains private routines used by the Operating System. This library does not exist in Mac OS 8.

8. Don’t rely on file system hooks or patches. ExtFSHook and FSQueueHook are not supported in Mac OS 8. In addition, patching any of the file system will affect only the application which installs the patches.

9. Don’t use compressed resources. Resources which are decompressed with the undocumented “dcmp” mechanism in System 7 will not be compatible with Mac OS 8. Resources which are compressed with other third-party mechanisms such as Application VISE will continue to work.

10. Don’t call InitResources, RsrcZoneInit, or RsrcMapEntry. Both InitResources and RsrcZoneInit are obsolete and not implemented in Mac OS 8. In System 7, RsrcMapEntry was used to read Resource Manager data directly from the resource map. In Mac OS 8, the in-memory resource map is private, and this call is not supported.

11. Don’t use resource file refNums with File Manager calls. In the past, the Resource Manager used the File Manager to open, close, read, and write the resource fork. Because of this, the refNum returned from OpenResFile could be used by an application and passed to File Manager calls to read and write data. In Mac OS 8, the Resource Manager no longer uses the File Manager to read and write the resource fork, so a refNum returned from OpenResFile has no relation to a File Manager refNum. You cannot use a File Manager refNum with the Resource Manager, and vice versa.

12. Don’t call SetApplLimit. In the past you could resize your application stack by calling SetApplLimit. Because the stack was directly above the heap, this would shrink the application heap so that the stack could be enlarged. In Mac OS 8, the stack is no longer directly above the heap, so this call is not supported. Use the code fragment resource instead.

13.Don’t use virtual memory calls. With the microkernel architecture introduced in Mac OS 8, the System 7 virtual memory calls are no longer supported.

14.Don’t assume relationships between the application stack and heap. As mentioned above, the application stack is no longer located directly above the application heap.

15.Don’t allocate all of temporary memory. Mac OS 8 implements a demand-paging virtual memory scheme. Because of this, temporary memory is limited only by disk space. Allocate only the amount of memory you need, not all that is available.

16.Don’t allocate all hard drive space. Because of the demand-paging virtual memory system, disk space is used dynamically as temporary memory. If the disk is full, the system will run out of memory.

17.Don’t share data structures between applications. Although applications still run in the same address space, system services such as the Window Manager and Event Manager maintain their lists and queues on a per-application basis. You cannot create a data structure such as a WindowRecord in one application and pass it to another application.

18.Don’t hard-code font usage. In Mac OS 8, users can customize the interface including application and system fonts. Use GetSysFont and GetAppFont instead of hard-coding fonts.

19.Don’t write to your application’s data fork. In Mac OS 8, your application’s data fork is file-mapped into memory, and the operating system has exclusive read-only access to the file. Any attempts to access the file will result in a permission error. If you need to store data, store it in a resource or in a preferences file.

20.Don’t access hardware directly. Under Mac OS 8, the hardware will be mapped into an address space which is not accessible by applications. Use drivers to access the hardware.

21.Don’t assume the system state in Notification Manager routines. The times when Notification Manager completion routines are called in Mac OS 8 differ from when they are called in System 7. Specifically, don’t rely on being in the context of the frontmost application.

22.Don’t change the window list directly. In Mac OS 8, the system maintains the window list in a private manner. Don’t assume that you can change the nextWindow field of a WindowRecord to change the window list. Use calls like SendBehind and BringToFront instead.

23.Don’t set the global-share bit in a CFM library that contains code. Linking against per-context libraries in a globally shared library that contains code will not work in a per-context fashion. If you need to maintain system-wide global data, you should use a separate library which contains only data and doesn’t link against other libraries.

24.Don’t rely on the structure of system memory. In Mac OS 8, the relationships between the locations of application stacks, application heaps, code, and static data are private and should not be relied on. For example, don’t assume your application code is in your application heap.

25.Don’t require AOCE interfaces. Not all AOCE interfaces may be available in Mac OS 8. If your application uses AOCE, use Gestalt to check for the availability of AOCE features, and weak-link against the AOCE library.

26.Don’t require an INIT, control panel or desk accessory. These code types are not supported in Mac OS 8; therefore you cannot rely on functionality provided by them.

27.Don’t use the Dictionary Manager. The Dictionary Manager is not supported in Mac OS 8.

28.Don’t depend on Script Manager internals. The Script Manager has been completely rewritten in Mac OS 8, and the internal data structures and low-memory usages have changed dramatically.

29.Don’t poll for Open Transport asynchronous events. Endpoint providers should not use polling for asynchronous events. Use a notifier function in responding to asynchronous events.

30.Don’t pass open file reference numbers between processes. In Mac OS 8, the FCB list is a per-process list, and the refNums cannot be shared among processes. Use file specifications or aliases instead.

31.Don’t assume that all FCB and VCB fields are valid. The File Manager has been completely rewritten in Mac OS 8, and data structures like FCBs and VCBs are maintained for compatibility only. Only the absolutely required fields of these structures are maintained. The following FCB fields are maintained: fcbFlNum, fcbFlags, fcbEOF, fcbPhLen, fcbCrPs, fcbVPtr, fcbClmpSize, fcbFType, fcbDirID, and FCBCName. The following VCB fields are valid: vcbSigWord, vcbVRefNum, vcbCrDate, vcbLsMod, vcbVolBkUp, vcbAtrb, vcbClpSiz, vcbNmAlBlks, vcbAlBlkSiz, vcbFreeBks, vcbVN, vcbDrvNum, vcbDRefNum, vcbNmFls, vcbNmRtDirs, vcbFilCnt, vcbDirCnt, and vcbFndrInfo. Even though these fields are maintained in Mac OS 8, you should try to find alternate ways of gathering information provided by these fields.

32.Don’t modify FCB or VCB data structures. As mentioned above, the FCBs and VCBs are maintained for compatibility only. The File Manager does not use these structures any more, so they need to be considered read-only.

33.Don’t call GetDrvQHdr or AddDrive. In Mac OS 8, GetDrvQHdr points to a list which is always empty, and consequently AddDrive has no effect. Use specific File Manager calls to determine information about volumes.

Steps to Being Well-Behaved in Mac OS 8

Once you have identified and addressed all applicable items discussed above, the next step is to start making some changes to your code to make it easier to build a Mac OS 8-savvy application.

1. Use the latest Universal Headers. All modern code bases should be using the Universal Headers instead of the old C includes or Pascal includes. Make sure you keep current with the latest releases of the Universal Headers. Products like MPW Pro, CodeWarrior, Symantec C++ all ship with the latest versions. By using the Universal Headers, you can help spot all the illegal references to low memory, use of unsupported traps, and reliance on unsupported system data structures - plus, you’ll have the added benefit of using the same header files that will contain all the new Mac OS 8 functionality as conditionalized compiler switches.

2. Make your code PowerPC-native. While 68K applications are still fully supported in Mac OS 8, all new functionality is implemented through CFM and SOM, which means that your 68K code will not be able to take advantage of all the new features of Mac OS 8. Furthermore, performance tradeoffs in the design of Mac OS 8 all favor native PowerPC code rather than 68K code.

3. Minimize patching. In System 7, it was quite common for applications to patch traps to get a custom behavior with some part of the system, or to work around old bugs in the system. Many of these patches will not function correctly under Mac OS 8, and are not needed anyway. Check to see why you are patching any traps, and see if there is a better way to solve the problem.

4. Support only System 7 and later. Many applications contain old code which is still around for compatibility with System 6. It’s time to remove that old code, and to set a new minimum system for your application. (Besides, it’s easier on your QA department!)

5. Use standard definition procedures. In Mac OS 8, the user interface is greatly changed. Users can customize nearly all aspects of the appearance to their liking. These appearances are changed by using different window definitions, menu definitions, and control definitions. If you are using your own custom defprocs, the system cannot override them with the user-selected appearance, and your application will not have the same consistent look as other applications.

6. Use Open Transport. The networking implementation for Mac OS 8 is PowerPC-native Open Transport. The traditional AppleTalk and TCP APIs are still supported for backward compatibility, but performance is not optimal. For maximum networking performance, use native Open Transport calls.

7. Use low-memory accessors. When the first PowerMac models were introduced, new calls were added to provide access to supported low-memory locations. By using the LMGet/LMSet functions today, you can be assured that you aren’t using any undocumented low-memory globals. In the future, low memory as we know it will go away completely, and the only way to access these locations will be through the LMGet/LMSet calls.

8. Be virtual memory-friendly. Virtual memory is always turned on in Mac OS 8, but the performance is improved as compared to System 7 VM. If you have been telling your users to turn off virtual memory when running your application, you should work to get your application running acceptably with System 7 VM. Make sure you are not making any System 7 VM calls like LockMem because they are not available in Mac OS 8.

9. Locate special folders using the Folder Manager. Use FindFolder, which has been implemented since System 7, to find the System Folder, Extensions folder, and other system-created folders. Store all user-defined preference data in the Preferences folder. Mac OS 8 implements a feature called “workspaces” which allows multiple users to define their own set of preferences for the same Macintosh. By storing your user preferences in the Preferences folder, your application will automatically take advantage of the workspaces in Mac OS 8.

10.Factor your application. Break your application into two distinct parts: the user interface part, and the computation part. If you can, create a third part which contains any disk-access and networking code. The benefits of this are many. (1) You will have an easier time producing a cross-platform version of your product. (2) It will be easier to add scriptability and recordability to your product. With Mac OS 8, the event model has changed from a polling model to a delivery model. [Instead of having to ask over and over “Is there an event for me?”, your designated routine is called if an event occurs; the event loop is dead in Mac OS 8. - man] The changes you will want to make to your application to support this new event model will be very similar to the changes necessary to support AppleScript. (3) It will be easier to maintain both a System 7-specific and a Mac OS 8-specific version of your application. You can change only your interface code to take advantage of the new functionality in Mac OS 8, plus you can execute your disk-access and networking code as pre-emptive processes to achieve better throughput.

11.Support QuickDraw GX printing. Even though traditional printing calls are supported for compatibility in Mac OS 8, the preferred printing implementation is PowerPC-native QuickDraw GX. If you support the QuickDraw GX printing API, your application will print faster and more reliably. Support for both traditional and QuickDraw GX printing calls can be maintained by runtime Gestalt checks.

12.Specify your stack size in the code fragment resource. If your application needs stack space in excess of the standard allocated space, you should set the application stack size field provided in the code fragment resource. In Mac OS 8, calls to GetApplLimit and SetApplLimit have no effect on PowerPC-native applications.

13.Prepare for Mac OS 8 memory management. Don’t rely on any fields of the application heap data structures. Don’t rely on any special knowledge of the behavior of the Memory Manager. Block headers, zone headers, and the size overhead of blocks are all private to the Memory Manager, and will change in Mac OS 8. Don’t make assumptions about where and how memory blocks will move in the heap. Don’t dispose of pointers and handles that are allocated indirectly by the system. (For example, don’t dispose of the content region of a WindowRecord.) Don’t access memory blocks outside your application heap.

14.Use a supported framework. Considering all the changes coming in Mac OS 8, now may be a good time to examine the application frameworks available. Using a supported framework will make it easier for you to take advantage of new functionality in Mac OS 8 by leveraging off the work the framework providers are doing to make their products Mac OS 8-savvy. Contact your compiler vendor to find out their plans for supporting Mac OS 8 with their frameworks.

15.Be WorldScript-savvy. Don’t assume all text is in a single script. Don’t assume a one-to-one relationship between characters displayed and glyphs; always use text-measuring routines on entire runs of text instead of character-by-character. Use PixelToChar and CharToPixel for hit-testing and highlighting. Use GetFormatOrder to properly reorder mixed-direction text.

16.Be inline input-aware. Follow the guidelines in Inside Macintosh: Text, Chapter 7, on what to do to become inline input-aware. This allows input methods to work directly in your document window without having to put up a separate window for text input. In Mac OS 8, inline input-aware applications will have access to a wide range of services besides input methods, such as spelling checkers and hyphenators.

Summary

Mac OS 8 introduces some radical changes to Macintosh. Even so, Apple engineers have made backward compatibility a top priority. They have put a lot of work into making our lives easier; now it’s time for us to return the favor. Make sure all your code follows the guidelines described above, and perhaps Mac OS 8 will ship a bit sooner than it would otherwise. So many times, we are faced with putting out a new version of a product without time to go back and clean up old code. By doing your cleaning now, you will not only be making your product better and more compatible with System 7, you’ll be getting a head start in making your product work well with Mac OS 8.