Volume Number: 14 (1998)
Issue Number: 2
Column Tag: From The Factory Floor

CodeWarrior Latitude: Porting Custom Definition Functions and More

by David Hempling, Bob McBeth, and Dave Mark, ©1998 by Metrowerks, Inc., all rights reserved.

This month, we'll continue our ongoing look at CodeWarrior Latitude. We'll start off with a look at the issues that crop up when porting custom definition functions from the Mac to Unix systems such as Rhapsody.

CodeWarrior Latitude is a porting library that greatly simplifies the process of porting Mac OS applications to Rhapsody. Latitude is an implementation of the Macintosh System 7 application programming interfaces (APIs) that allows source code for a Macintosh application to be compiled with little modification on a Rhapsody platform, resulting in a native Rhapsody application. Latitude maps the Mac API requests to native Unix system calls. An application built with Latitude attains the look and feel of the new native platform.

Custom Definition Functions

Customized definition functions provided to the Mac Toolbox API as function pointers require no changes for porting from the Mac OS platform using CodeWarrior Latitude. The function pointer you provide to ModalDialog(), for example, does not need to be changed. However, you may want to add functionality to your modal definition function to handle events that weren't expected on the Mac.

On platforms supported by Latitude, modal dialog windows are moveable at all times. If the user moves a modal dialog window, the mouseDown inDrag event will go undetected in your own modal definition function ported from the Mac since on the Mac your app didn't have to deal with this possibility. Therefore, you will need to add a case for the mouseDown inDrag event, which calls DragWindow() to handle that event's processing. You will know if you neglected to handle the mouseDown inDrag event if your dialog window contains a popup menu. If DragWindow() has not been called in a moved window and the user clicks on the popup menu button, the menu will appear on screen were the popup button was on the screen before the window was moved. The DragWindow() call updates the window's port bounds which are used by PopUpMenuSelect() to display the popup menu.

Because this new possibility of unforeseen events arises on non Mac OS platforms, your own application's windows may become obscured or uncovered at times when they couldn't have been on the Mac. For example, say the user causes a system dialog to appear, such as one of Latitude's "Apple" menu desktop services like Copy Files or other system level alerts which are movable, and then the user moves one of these alerts causing a portion of your own app's windows to require updating. You now have a blank area of your application windows that you want to refresh. But, you don't have control since Latitude is servicing some other request.

Latitude provides a means for applications to register a special modal filter function whose job is to receive update events for all application windows when Latitude is in control of a presently displayed modal dialog. The filter function prototype is simply:

void my_app_modal_update_hook(EventRecord *theEvent)

You provide this function at lg_latitude_init() time as one of the field settings in the LG_APP_INFO_BLOCK:

void  main( long argc, char **argv )
{
#ifdef _LATITUDE_
    LG_APP_INFO_BLOCK lblock;

    lblock.flags =   LG_APP_INFO_SIGNATURE |
                           LG_APP_INFO_CLASSNAME |
                           LG_APP_INFO_MODAL_EVENT_HOOK;
    lblock.signature = QUADCONST('C','T','T','R');
    lblock.classname = "Latitude";
    lblock.modal_event_hook = my_app_modal_update_hook;
    lg_latitude_init(argc,argv, &lblock);
#endif

Another type of custom definition function are those that define custom controls, menus, lists, and windows. Mac applications provide these functions to the Mac toolbox in one of two ways. They either compile these functions separately into special code resources -- CDEF for controls, MDEF for menus, LDEF for lists, and WDEF for windows -- or they compile these functions with their application and patch special CDEF, MDEF, LDEF, or WDEF resources that contain assembly instructions. These patch resources typically contain twelve byte structures defined like this:

typedef struct {
  short jmp_inst;
  ProcPtr long def_func;
} DEF_STRUCT;

And are set up at init time like this:

DEF_STRUCT **my_cdef;
extern long my_cdef(short varCode, ControlHandle theControl,
        short message, long param);

my_cdef = (DEF_STRUCT **) GetResoure('CDEF', 128);

(**my_cdef).jmp_inst = 0x4EF9; 
                /* 680x0 for JMP (i.e. Jump) */
(**my_cdef).def_func = (ProcPtr) my_cdef;

There are two problems with this practice that come up for porting. The first problem is the 680x0 assembly code in the handle. Since CodeWarrior Latitude contains no machine code interpreter, the 680x0 JMP instruction is meaningless. The second problem is a little less obvious and far more hazardous. Since we're probably porting to a RISC based platform where long words are aligned on long word boundaries, the size of the DEF_STRUCT structure above is not 12 bytes, it's 16! (The compiler will insert 4 bytes of padding after the jmp_inst member so that def_func falls on a long word boundary.) The size of the CDEF 128 handle is 12 bytes. The assignment of the structure's def_func member writes passed the end of the 12 byte handle, thus corrupting memory.

CodeWarrior Latitude provides a means to register your definition functions so as to avoid these types of problems:

Handle lg_latitude_code_resource(ResType type, short id, 
          StringPtr name, ProcPtr defproc);

Latitude creates a special handle and places it in the ROM Resource Map (ROMMapHndl). When CW Latitude's toolbox requires a CDEF, LDEF, MDEF, or WDEF, it searches the ROM Map for the registered code resource first.

If your app needs to get at the handle, you can use the one returned by lg_latitude_code_resource(), or if that one isn't readily available, you can use regular Resource Manager calls to retrieve it. The standard way to get a ROM map resource is:

  short cur_map;
  Handle h;

  cur_map = CurResFile();
  UseResFile(1);
  h = Get1Resource(QUADCONST('C','D','E','F'), 128);
  UseResFile(cur_map);

To get the function pointer out of a CW Latitude created code resource handle, use the call

ProcPtr lg_latitude_code_address(Handle h);

CDEFs, LDEFs and MDEFs for popup menus are completely handled by CW Latitude. MDEFs for menus off of the menubar need to be handled differently since CW Latitude is not drawing those menus itself but rather sending the appropriate instructions to the native system to display the menus.

If your app has a custom MDEF for menubar menus solely for the purpose of displaying multiple key combination menu item key equivalents (such as shift-control-option-F), then you can use a special MDEF provided by CW Latitude, called lg_latitude_custom_mdef, specifically designed for such menus.

WDEFs are also a little tricky. Again, CodeWarrior Latitude is not drawing the window itself, so you have no way of drawing a window's adornments under Latitude. However, by using some of Latitude's special window functions like lg_latitude_next_window (discussed in last month's article) and lg_latitude_register_window, you can provide Latitude with a description of the functionality of your WDEF, including floating attributes, and let Latitude handle communicating those details to the native system.

Games with A5

Macintosh applications have all kinds of games they play with the A5 register to save and restore contexts. Sometimes this is done when the application is in the background but wants to communicate something to the user. Since the native Unix systems supported by CodeWarrior Latitude do their own context switching, your application doesn't have to provide its own context management. If your application is awoken from suspension, you can be assured that the system will restore the proper stack and processor register context before executing more of your application's code.

Some applications use A5 as a sort of stack jump maneuver to recover from an error. The equivalent in Unix systems is the setjmp and longjmp pair of functions. You use setjmp to save the stack environment in a given buffer for later use by longjmp. A call to longjmp zaps execution and context back to the place were the setjmp call was made.

Games with the Memory Manager

Some Macintosh applications play interesting games with the Mac Memory Manager. They try to gobble up all of the memory available, tickling a grow zone proc in the process, to determine how much memory is really available. Others allocate a large block of memory and proceed to parse off parts of it themselves, acting as their own Memory Manager. CodeWarrior Latitude's Memory Manager provides handles and pointers the way Mac applications expect, even simulating a System Zone and an Application Zone. However there are no large, specially zoned pools of memory that Latitude allocates from. Each handle and pointer allocation done by CW Latitude's Memory Manager is mapped directly to Unix system malloc() and realloc() calls. Since we're operating in true virtual memory systems, these common games applications play with the Memory Manager are completely meaningless. If your app is using these tricks, you should disable them and just let Latitude's Memory Manager do its thing.

Precompiled Headers

On Latitude supported systems where the available compilers do not support precompiled headers, you will have to explicitly add inclusion of your desired include files to your source code. It will probably be helpful to create one include file that sites the set of files included in the precompiled header you used on the Mac. CodeWarrior Latitude includes an include file like this for the often used MacHeaders file. It is located in the $LATITUDE_ROOT/utilities directory. You can copy it to your application's development environment for your use.

At the time of this article's writing, Metrowerks has not yet released our own C/C++/ObjC compiler for Rhapsody. However, by the time this article hits the stands, this issue of precompiled headers will be moot for Rhapsody. However, until we bring the IDE to Rhapsody, you will still have to explicitly add any includes that were implicitly added by the IDE's prefix file feature.