Volume Number: 13 (1997)
Issue Number: 6
Column Tag: From The Factory Floor

David Hempling and the Latitude Porting Libraries

by Dave Mark, ©1997 by Metrowerks, Inc., all rights

This month's interview is with David Hempling, founder of the Latitude Group and Quorum Software Systems before that. If you have not yet heard about the Latitude porting libraries, you owe it to yourself to read this interview. The current version of Latitude makes it easy to port your Macintosh applications so they run under Unix. Recently, Metrowerks purchased the Latitude Group with an easy port from Mac to Rhapsody in mind. Read on to learn more...

Dave M: Can you tell me a bit about the history of The Latitude Group?

Dave H: The Latitude Group was founded in August of 1994 to continue development and support of the Latitude Technology which was originally developed by Quorum Software Systems, Inc.

Back in 1989 Sheldon Breiner, an entrepreneur with several companies under his belt, wanted to create a Macintosh hardware clone. As you can imagine, he found no one who would join him in such a venture. He eventually meet up with R. Martin Chavez, a Computer Science PhD and medical student, who had ideas about enabling Macintosh applications to run on other platforms. Marty's idea was very unique: under some special process, the shrink-wrapped Macintosh application would take on the native look and feel of the non-Mac platform on which it was running. Sheldon and Marty, with myself and another software engineer, Joel Kehle, founded Quorum Software Systems and began development.

Our first objective was to implement key Macintosh Toolbox functions in our own portable library -- the beginnings of Latitude. We would then couple this library with a 680x0 interpreter which would interpret the Macintosh binary executable and defer to our portable library when the interpreter encountered an A-Line trap exception. Mac programmers from the old days will remember that this is how Mac programs worked. Application machine code contained 0xAXXX instructions which triggered a 68000 exception. The lower 24 bits of the 0xAXXX instruction were used as an offset into the Mac's Trap Table and execution would jump to a function inside the Mac ROMs.

We did our initial portable Mac Toolbox library development on the 68030 NeXT Cube while another engineer, Robert Brown, developed a portable 680x0 and Microsoft P-Code interpreter. With the interpreter working, we moved our development to RISC based UNIX platforms like Sun Solaris, SGI IRIX, and HP HP-UX and released Equal, the Application Adapter which brought Microsoft Word 5.1a and Excel 4.0 to UNIX. Under Equal, Macintosh Word and Excel binaries ran on those non-Mac platforms with great performance and a native look and feel.

Because our portable Mac Toolbox library was being used to support two world-class applications, it was imperative that our Toolbox implementation behave as accurately as possible. We didn't have the Word or Excel source code to refer to -- only the sequence of Toolbox calls these applications were making. This black-box method of development, and adherence to strict clean-room engineering with regards to Apple's closely guarded Mac ROMs, led us to establish coding practices and design guidelines that we've continued to follow through our development of the portable Mac Toolbox library:

1. With regards to application reliance on Mac Toolbox function input and output, our library's implementation must match the Mac and use published Mac data structures and paradigms internally whenever possible.
2. Map native system facilities to Mac Toolbox functionality so the resulting application has the look and feel of the native platform.
3. Require as little modification to the application as possible. Under Equal, there was really no practical way to alter the application's instructions. We had to implement Toolbox functionality correctly in our library so that no application modification would be needed.

Quorum also begin to license the portable library used by Equal to Mac developers who wanted to bring their applications to UNIX without the added overhead of the 680x0 interpreter. Developers also wanted the option to break out of their application's Mac source base and take advantage of features available in the new UNIX/RISC machines coming into the market. Quorum called the portable library "Latitude" and signed up developers like Adobe, Micro Planning International, and Sonic Solutions.

Early in 1994, Quorum's sales did not meet with its investors expectations and Quorum closed its doors that July. However, there were still developers using Latitude. Adobe, for example, was preparing to release Photoshop 2.5 at that time and needed Latitude support. Joel Kehle, myself, and three other Quorum engineers founded The Latitude Group, Inc., licensed Latitude from Quorum, and supplied Quorum's Latitude clients with support. We later purchased Quorum's assets from the fire sale.

Over the next two and a half years, we continued to develop Latitude, upgrading and expanding the technology as well as our client base. Adobe continued to use Latitude to bring Illustrator 5.5 and Photoshop 3.0 to Sun Solaris and SGI IRIX. Other more vertically minded developers like Vibro-Acoustic Sciences used Latitude to bring their highly specialized tools to UNIX/RISC platforms.

Dave M: How does Latitude work today (before Rhapsody)? How do I get my existing Mac application ported over to Unix? How much work is involved?

Dave H: At the heart of Latitude is our own Portable Toolbox Implementation Layer. This layer is completely platform independent. It presents the Mac Toolbox API to the application, answers these calls through a trap table mechanism, and relies on other toolbox calls within the layer whenever possible. When a native system facility is needed, such as the display of a window or control, or some graphical rendering, this layer calls out to one of Latitude's platform dependent modules through an internal, well defined API. The toolbox layer doesn't know what kind of system lies underneath, only that calling this function will display a window or that function will draw a line, etc.

Likewise, regarding the platform dependent modules. Event feedback from the GUI platform dependent module comes in the form of special calls back to Latitude's Event and Window Manager implementations. These calls in turn place event records in Latitude's Event queue. Latitude's architecture also strives to reconcile the difference between the Mac event and rendering systems and those on the platform Latitude is delivering. For example, client/server systems like Motif or OPENStep use callback mechanisms to report events to applications. A button's callback is called when the user clicks on the button. Latitude's GUI layer button callback function places a mouse down and mouse up event in Latitude's event queue. A window's update callback in the GUI calls down to the toolbox Window Manager to invalidate some or all of the window's update region, which is then picked up by CheckUpdate() from the app's call to GetNextEvent() or WaitNextEvent().

Because we've mapped native system facilities to Mac calls, the running application is an equal citizen on the desktop. The application's windows, menus, and control items are native system objects. Cutting and pasting between apps is facilitated by the native system's clipboard mechanism. Fonts come from the system font server -- including the default system font, which means the dialogs come up in something other than Chicago! Application windows are native windows -- not some rendering of a window inside of another. The performance hit is minimal. Latitude is merely mapping the Mac calls to the native system. There is very little processing going on in between.

To bring a Mac application to UNIX using Latitude, you first bring the source code to the UNIX platform and compile it. Tools included with Latitude perform some of the more mundane tasks like generating Make files and replacing '\p' Pascal string delimiters with special macros. Any changes made by these utilities can be taken back to the Mac without any ill effects. The goal is to generate both your Mac and UNIX applications from the same source code tree.

The bare minimum modification you will need to make to your application is a call to initialize Latitude. This call is equivalent to booting a Mac and double clicking your application's icon, sets up Latitude's internals, and prepares it for your application.

If your application contains compiled CDEF, MDEF, LDEF, MBDF, or WDEF resources, you will have to register these functions with Latitude and compile the definition function with the rest of your application. If your application contains any 680x0 or PPC assembler code, you will have to write equivalent code in your application's programming language.

Assuming your application is System 7 compliant (no nil pointer de-references, no low memory global accesses by address, etc.) there is little more for you to do than to compile the source code and link with Latitude's library. By specifying the location of support files in system environment variables, your Latitude ported application should find what it needs and begin running. The rest is testing and tweaking.

Of course, there are many ways to tailor your application's appearance and behavior by adding some additional Latitude auxiliary calls. For example, Latitude supports floating palettes and windows for applications that provide custom WDEFs and/or patch Window Manager functions like FrontWindow() and SendBehind(). But there are so many different ways applications achieve floating windows that we can't ensure that Latitude supports them all. Instead, we provide special auxiliary calls which help your application tell Latitude which windows should float and when. Other auxiliary calls help tailor window behavior, adornments, and appearance. Still others help to solve the different structural alignment padding rules that differ between the Mac and other platforms.

Dave M: How much of the System 7 API does Latitude currently support? Is Quickdraw supported, for example?

Dave H: Over 1,200 Macintosh Toolbox functions are implemented in Latitude. These include all of System 6 and a majority of functions introduced in System 7 except some of the newer System 7 calls. All of the user interface (windows, controls, menus, cursors, lists, events, etc.) calls are implemented as well as calls for resources, file i/o, text and script managers for Roman character sets, scrap, printing, drag-n-drop, and various utilities like SANE, OSUtils, the Time Manager, etc.

Latitude's Quickdraw implementation is one of its crowning achievements! Pictures, icons, color patterns, and off-screen graphics are automatically transformed onto native canvases. High quality dithering of 24-bit pictures for 8-bit buffers is automatic. Latitude's drawing occurs through its own set of the standard QDProcs. All pen functionality, including pixmap patterns, are supported. Latitude passes rendering operations to the native platform when ever possible to obtain top performance. But we also can render drawing operations completely in memory before being transferred to the native rendering system. This lets us support arithmetic modes in CopyBits that systems like X or DPS can't provide. Besides supporting CopyBits, CopyMask, and CopyDeepMask, Latitude's Quickdraw handles pixmaps from devices with different color byte orderings.

Latitude's picture recording and playback mechanism is completely integrated in the Quickdraw system. It reads Version 1, Version 2, and Version 2 Extended PICT formats and writes Version 2 PICTS. Latitude's PICT Interpreter has the ability to perform translation between Mac Regions and Latitude's own region implementation.

Latitude also supports GDevices of varying depths and color byte orderings. It's also possible to create GDevices with drawing area memory which is shared with the native platform image memory. This allows for extremely fast drawing performance.

For printing, Latitude has a set of QDProcs that generate PostScript that is written to a file and then sent off to the local or networked PostScript Printer. We are using some of this code to build our DPS rendering module for Rhapsody.

Dave M: How do I get to traps that Latitude doesn't support? Can I access the native APIs with a project that uses Latitude?

Dave H: There's nothing in Latitude that keeps apps from calling the native system directly. In fact, this kind of design is encouraged. Many times there are system facilities that have no equivalent in Mac Toolbox land. Latitude can be used then as a transitional tool. Developers can use it to make the first jump, put out a dot release, and then write more and more native code to take advantage of the new and evolving platform.

Latitude does have auxiliary calls to help apps access Mac Toolbox windows through their native counterparts. For example, given a WindowPtr, a special Latitude call will return the native object for that window. The app can then address the window directly. There are also calls to intercept events before Latitude processes them so that apps can manage their own windows outside of Latitude.

Dave M: I know that Latitude is written in ANSI C. Can I access the Latitude library from any language, including C++ and Objective C?

Dave H: Once Latitude is integrated into CodeWarrior and included in the CodeWarrior library set, you should be able to use it with any language supported by CodeWarrior. Latitude is currently built with GNU gcc but can also be built with the native Solaris SPARCWorks compiler and SGI's native compiler.

Dave M: If I use Latitude today to do a Unix port of my Macintosh application, will I get a free ride to Rhapsody once the Rhapsody version of Latitude is ready? Any idea of when that will be?

Dave H: As I said, one of the main goals of Latitude is to allow developers to get to many platforms with one code base. The idiosyncrasies of the platform are handled by Latitude's platform dependent modules. The API to the application remains the same. There are already Latitude clients who build their apps on SGI, SUN, and HP platforms without modifying their Mac code base. Of course, if platform specific work has been done inside the application, then this code will have to be swapped out when moving to the new platform.

Work on bringing Latitude to Rhapsody has already begun. We're also keeping close tabs on how Apple plans to shape Rhaposdy so that Latitude will be in line with what eventually comes out of Infinite Loop.

Dave M: Does Latitude hide the specifics of the file system -- i.e., will Macintosh HFS calls like StandardGetFile() or the various PB calls port?

Dave H: All of the PB and FSSpec calls to access files have been implemented in Latitude. Files in the native file system are accessible as well as Mac HFS floppies. For native files, Finder and catalog information is picked up if the files are in one of the various formats developed to represent Macintosh files under UNIX. Typically, the data and resource forks are in separate files and the file's Finder information is either included in the resource fork or kept in another separate file. Latitude understands many of these formats including AppleDouble, AppleSingle, Helios EtherShare, IPT uShare, and Xinet K-AShare. Files without resource forks or Finder information appear as plain text files.

Latitude supports all of the Standard File Package, both System 6 and System 7 calls. It supports all of the customizations applications typically make to that package's dialogs and also makes a few customizations of its own to allow the user to access files through the native file system. These Latitude customizations are done behind the scenes of the file dialog and do not interfere with any application customizations. There's even a special callback scheme in place so that apps can provide their own code to call the native get/put dialog and return a native path to the Standard File Package which in turn will fill in the appropriate reply record and return it to the app.

Again, auxiliary calls are available in Latitude to give access to the native file system by the app. There are calls, for example, to translate FSSpec formatted input into native file paths and vice versa.

Dave M: What won't port?

Dave H: Usually, not well behaved apps have the most problems. Apps that draw directly to the frame buffer or access private Mac structures, like RgnHandle data or low memory globals by address. Crawling up the stack frame using the A5 global obviously doesn't work. Basically all of the things that the Inside Macintosh books say not to do are no-nos in Latitude.

Memory Manager work-arounds don't port over well either. Some apps have the habit of seeing how much memory is available and then allocating all of it for themselves. On UNIX based systems, this kind of practice really doesn't make much sense. By disabling this kind of mechanism and simply relying on Latitude's Memory Manager calls to allocate memory, apps are assured of efficient memory usage.

Dave M: Are there any big-name apps that are currently using Latitude?

Dave H: As I mentioned earlier, Adobe has used Latitude to bring Illustrator 5.5 and Photoshop 3.0 to Sun and SGI. The Latitude Group's close work with Adobe on these projects helped us fortify Latitude a great deal. We've found that other folks using Latitude benefited enormously from the work we did on Photoshop -- the app Greg Galanos likes to call "the Mother of all apps".

Later this year, Adobe plans to begin shipping their non-linear video editing software, Premiere, on SGI's new O2 platform. From the looks of Premiere on the O2 today, this is going to be one hot product! Latitude enabled Adobe's engineers to skip past all of the user interface support and go straight to tuning Premiere's audio and video technology to SGI's amazing O2 and add a few video features that the Mac simply can't handle as well.

Other Latitude clients include more vertical market apps by developers who wanted to get to the graphics power of the SGI or the server power of the Sun or HP platform line. These apps include video and audio processing for the film industry, audio and sensitive vibration measurement and analysis for the automobile industry, and advanced photographic processing technologies used for film development and film products.