If you are a Windows developer, the QuickTime Software Development Kit (SDK) for Windows allows you to incorporate QuickTime capabilities into your applications developed directly for the Windows platform. If you are a Macintosh developer, the SDK provides you with the tools you need to port the QuickTime-based functionality of your application to Windows. This chapter discusses some of the fundamental concepts you need to understand in order to work with both QuickTime and Windows.
Overview
Mac OS and Windows Differences
The core of the QuickTime SDK for Windows is a Windows dynamic link library (DLL) that implements the behavior of QuickTime and a few Macintosh Toolbox routines on the Windows platform. This DLL is intended only for QuickTime cross-platform support, not as a general tool for porting Macintosh code to Windows.
Because the QuickTime routines were originally designed for the Mac OS, they operate on Mac OS data structures and assume certain features of the Mac OS operating environment. For example, QuickTime routines are driven by Mac OS-style events rather than Windows-style messages, and do their drawing in a Mac OS graphics port instead of a Windows device context. To use them in the Windows environment, you have to do a little extra work to mediate between the two platforms.
Table 1-1 lists the basic QuickTime Media Layer (QTML) concepts and their Windows counterparts.
Windows concept |
QTML equivalent |
---|---|
Message ( |
Event ( |
Graphics Device Interface (GDI) |
QuickDraw |
Device context (DC) |
Graphics port ( |
Window handle ( |
Window pointer ( |
Common Dialog Box Library |
Standard File Package |
The goal here is simply to show how QuickTime fits into the structure of a typical Windows application and to provide Windows developers with the minimum conceptual foundation needed to read and understand the existing QuickTime documentation.
With those objectives in mind, the programming examples in this document have deliberately been kept simple and straightforward. The code samples are limited to the most basic QuickTime functionality: presenting a movie and allowing the user to manipulate and control its presentation through a standard QuickTime movie controller.
The event-loop structure of Windows programming is remarkably similar to that of the Macintosh. The differences lie in the implementation details, not in the basic approach. The major differences that affect QuickTime are as follows:
Graphics environments. QuickTime draws to the user’s screen by using Mac OS QuickDraw, and QuickDraw depends on a data structure called a graphics port to define such characteristics as pen width, background color, clipping boundaries, and current text font. Windows uses the device context for similar purposes, but a device context is specific to a particular device (such as a window or printer), whereas the Mac OS graphics port is global to all drawing operations at a given time.
Data containers. Mac OS resources are items of structured data that are stored in files and can be loaded on demand to help determine a program’s behavior. Resources in application files usually contain descriptions of such user interface items as menus and dialog boxes, but even the executable code of an application is stored as a resource in the application’s file. Although Windows uses the concept of resources as well, they’re far less important to the system’s software architecture.
Data type codes. QuickTime uses four-character codes to identify such items as track types, media types, and component types. Internally, such codes are simply 32-bit integers; in source code, they are typically represented by four-character strings in single quotation marks, such as 'abcd'
.
File forks. Every Macintosh file consists of two separate sections, logically joined under a single file name. The data fork consists of a single stream of data bytes intended to be read sequentially; it corresponds to what DOS and Windows generally treat as a file. The Macintosh resource fork contains a heap of individual resources that are accessed by means of four-character resource types and integer resource IDs. Because DOS/Windows files aren’t forked, information that would normally go into Macintosh files must be restructured to fit them.
Messaging. Mac OS events are similar in concept to Windows messages and carry essentially the same information. But a Windows message is directed to a specific window, whereas a Mac OS event is addressed globally to the currently running program.
Window registration. QuickTime designates a window by a pointer to a Mac OS window record, which contains its own graphics port. On the Windows platform, however, a window is normally designated by an HWND
handle. Before QuickTime for Windows can draw in a window, your code must register the window with QuickTime by calling CreatePortAssociation
. This function creates a graphics port and associates it with the window in a data structure that is internal to QuickTime.
File typing. Every Macintosh file is stamped with a four-character file type and a four-character creator signature, which identifies the application program to which the file belongs. This technique achieves many of the same goals as that of three-character file name extensions in DOS/Windows.
String formats. DOS/Windows uses C-style strings (terminated by a null character), whereas QuickTime routines use strings in Pascal form (preceded by a 1-byte length count). The QuickTime utility functions c2pstr
and p2cstr
convert strings from one format to the other.
File structures. DOS/Windows files don’t have a counterpart to the Macintosh resource fork; they have only the equivalent of the data fork. This leads to problems when you store QuickTime movies or applications using the Windows file system.
Movie files. To store a QuickTime movie in a Windows file, you need some way to store the media that the movie will present separately from the movie structure.
Application files. When porting existing QuickTime applications from Macintosh to Windows, the problem arises of how to transport resources belonging to the application program itself. Such resources are typically stored in a separate 'qtr
' file while they are being developed in the Macintosh environment; they ultimately wind up in the resource fork of the Mac application ('APPL')
file.
A utility named RezWack, available in the QuickTime Windows SDK at http://developer.apple.com/sdk/index.html, moves these resources into an executable (.exe) or dynamic-link library (
.dll) file in the Windows environment. QuickTime’s resource management routines will correctly locate and load movie resources when they are stored this way in a Windows application.
© 2005, 2006 Apple Computer, Inc. All Rights Reserved. (Last updated: 2006-01-10)