2001 A Space Odyssey
Volume Number: 17
Issue Number: 1
Column Tag: QuickTime Toolkit
2001: A Space Odyssey
By Tim Monroe
Writing Cross-Platform QuickTime Code
As you know, QuickTime was originally developed to run on Macintosh computers. In
the mid 1990's, Apple released a version of QuickTime (called "QuickTime for
Windows") that provided support for playing QuickTime movies on Windows
computers. While it was a significant step forward, this version had some severe
limitations. Most importantly, it provided a playback engine only; there was no API
for creating QuickTime movies on the Windows platform. Also, many of the APIs for
playing movies back differed from their Macintosh counterparts. For instance, on the
Mac, NewMovieController is declared essentially like this:
MovieController NewMovieController (Movie theMovie,
const Rect *movieRect,
long someFlags);
But under QuickTime for Windows, it had this declaration:
MovieController NewMovieController (Movie theMovie,
const LPRECT
lprcMovieRect, long someFlags,
HWND hWndParent);
You'll notice that the Windows version took an additional parameter (hWndParent) and
that the type of the second parameter was a pointer to the standard Windows rectangle
type (RECT), not the Macintosh rectangle type (Rect).
Personally, I never wrote any code using the original QuickTime for Windows APIs,
but I can imagine that it was something of a headache for experienced Macintosh
programmers. Just flipping casually through the documentation is enough to convince
me that it was probably impossible to develop any very interesting QuickTime code
that would compile and link on both platforms. My guess is that anyone developing a
QuickTime-savvy application for both Mac and Windows platforms probably had to
maintain two separate source code bases.
QuickTime 3.0 changed all that. It provided, for the first time, a set of APIs that were
virtually identical - in both parameter lists and feature completeness - on Macintosh
and Windows platforms. In other words, it is now possible to write Mac and Windows
applications that use the same source code, at least for the QuickTime-specific
portions of the application. If you've been following this series of articles for the past
year, then you know that I've placed a great deal of emphasis on developing code that is
completely cross-platform. In this article, we'll take a more in-depth look at some of
the platform-specific issues that we've considered only in passing up to now (such as
working with multi-byte data and resources).
The magic provided by the Windows version of QuickTime 3.0 was accomplished
principally by a library called the QuickTime Media Layer (or, more briefly, QTML).
The QuickTime Media Layer provides an implementation of a number of the parts of the
Macintosh Operating System (including the Memory Manager and the File Manager)
and the Macintosh User Interface Toolbox (including the Dialog Manager, the Control
Manager, and the Menu Manager). QuickTime, of course, also runs on Mac OS X, which
is a UNIX-based operating system. In this case, the implementation of the Macintosh
Operating System and Toolbox managers is provided by a library called Carbon. It
should come as no surprise to learn that Carbon originally grew out of the existing
work on QTML.
We're going to approach this article in this way: let's suppose that we've got a
QuickTime-savvy application that runs under the "classic" Macintosh operating
systems (that is, MacOS 8.x and 9.x). We want to see what we need to do to get it to run
also under the various flavors of Windows (namely, Windows 95/98/ME and Windows
NT/2000) and under Mac OS X.
Endian Issues
Let's begin this odyssey at the lowest (and sometimes most vexing) level, by
considering the memory storage of multi-byte data. Motorola processors in the 680x0
family expect multi-byte data to be stored with the most significant byte lowest in