Jun 97 Factory Floor
Volume Number: 13
Issue Number: 6
Column Tag: From The Factory Floor
David Hempling and the Latitude Porting
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.