Technical: QuickTime
Advanced Search
Apple Developer Connection
Member Login Log In | Not a Member? Contact ADC

title


Previous Section Table of Contents Next Section


Cross-Platform Development

Contents

Implementation

Cross-Platform Issues

Endian Issues

References


Implementation

QuickTime is truly multiplatform; its application-programming interface is essentially the same on Macintosh and Windows. Code written using QuickTime APIs will compile and run correctly on both platforms. Additionally, QuickTime for Java lets you write Java code and access QuickTime on both Macintosh and Windows.

On Macintosh, QuickTime is implemented as a set of system extensions that will run under System 7.5.5 or later on Power Macintosh computers.

QuickTime on Windows 95, 98 and NT is implemented as a dynamic-link library supporting PC compatibles with a 66MHz 80486 or better processor. It also supports Microsoft DirectDraw and DirectSound for improved performance.

QuickTime for Java is implemented as a set of classes and methods that give you access to QuickTime's functionality. QuickTime for Java requires a Java Virtual Machine Version 1.1 or greater and requires QuickTime itself.

Cross-Platform Issues

Although Macintosh developers working with QuickTime on Windows will feel surprisingly at home, there are a number of issues Windows developers new to QuickTime should be aware of.

Graphics Environments - QuickTime draws to the screen by using QuickDraw. QuickDraw depends on a graphics structure called a graphics port. Windows uses the device context (DC) for similar purposes, but a DC is specific to a particular device such as a window or printer while a graphics port is global to all drawing operations at a given time.

Data Containers - Although Windows uses the concept of resources, they are less important to the system's software architecture than their Macintosh counterparts. These structured items of data can be loaded on demand to help determine a program's behavior.

Data Type Codes - QuickTime uses four-character codes to identify items such as track types, media types and component types. Internally these are simply 32-bit integers. In source code a four-character string in single quotes, such as 'abcd' represents them.

File Forks - Macintosh files consist of two separate sections logically joined under a single file name. The first section is called the data fork and consists of a single stream of bytes intended to be read sequentially; this corresponds to what Windows generally treats as a file. The second section is known as the resource fork and contains individual resources that are accessed by means of a four-character resource type and integer resource IDs.

Messaging - Macintosh events are similar in concept to Windows messages and carry essentially the same information. However, a Windows message is directed to a specific window while Macintosh OS events are addressed globally to the currently running application.

Windows Registration - QuickTime designates a window by a pointer to a Macintosh window record. This window record contains its own graphics port. On the Windows platform a window is normally designated by an HWND handle. Before QuickTime for Windows can draw in a window, the window must be registered with the QuickTime Medial Layer using the CreatePortAssociation API.

File Typing - Every Macintosh file is stamped with a four-character file type and a four-character creator signature. The type and creator signatures identify the application program the file belongs to. Windows uses the three-character DOS file extensions.

String Formats - While Windows uses C-style strings (terminated by a null character), QuickTime uses strings in Pascal form (preceded by a 1-byte length count). QuickTime provides conversion utilities for these two formats, CopyPascalStringToC and CopyCStringToPascal.

Endian Issues

Multibyte data fields can be referenced a couple of ways in memory. One known as big-endian consists of field addresses pointing to the most significant byte while the second, known as little-endian contain field addresses pointing to the least significant byte.

Native QuickTime software uses big-endian (MSB) addressing (because of its origins on Mac OS) while Windows uses little-endian (LSB).

For the most part QuickTime takes care of the endian conversions for you automatically. You may need to use conversion utility APIs only when you add private multibyte data to a structure QuickTime will not know about, or when you interpret media data yourself.

Utility functions for byte flipping can be found in the Endian.h header file that comes with the QuickTime Interfaces and Libraries.

References

QuickTime For Windows Programmers

Mac OS For QuickTime Programmers

QuickTime For Java

 



Previous Section Table of Contents Next Section