![[IMAGE Guschwan_rev1.GIF]](guschwan_rev1.gif)
Intercepting the processing of a QuickTime routine enables you to debug the routine, use the routine in new ways, and better understand QuickTime architecture. To intercept the routine, you need to know something about its low-level implementation. This article discusses the low-level implementation of QuickTime routines, and also describes tools and programming techniques that can be used to debug, modify, and analyze QuickTime routines. Some of these techniques take advantage of the Component Manager, and their usefulness will extend beyond QuickTime as future managers capitalize on components.
As QuickTime routines pass through some common locations, they're accessible to your application
or to a debugger. A QuickTime routine begins with its function name, as used in your application
and defined in the interface files. It usually compiles as an A-trap and maybe some assembly glue.
The routine may call other Macintosh routines, be affected by global data structures, pass through a
grafPort's bottleneck, or pass through a component's main function. Because you have access to these
locations, you can intercept the processing of the routine, perform your own special processing, and
then allow the normal execution of the routine to continue.
This article's examples use MacsBug and TMON Pro (TMON Professional v. 3.0.1 from Icom Simulations, Inc.) to intercept and analyze routines. The tools discussed create resources for both debuggers, though in some situations you'll want to use one debugger over the other. For example, the language extensibility of TMON Pro's built-in assembler provides capabilities that other debuggers don't provide. Now let's get into the practical aspects of analyzing and debugging QuickTime routines.
In the early days of the Macintosh, there was one routine name per A-trap, but the number of routines increased so dramatically that a second mechanism was introduced to avoid exhausting all the A-traps. This mechanism uses the normal A-trap mechanism to identify a grouping of routines(usually defined by a specific manager) and uses selectors located on the stack or in a register to identify the specific routines within the grouping. QuickTime uses only four A-traps:
Using four A-traps for over 500 routines is possible because the interface glue can push routine selectors into registers or onto the stack. QuickTime picks the routine it needs to execute from the value of the selector. For example, with the Movie Toolbox, QuickTime uses a word in the D0 register. So 0x303C and xxxx (the two-byte selector) appear before the A-trap in the Movies.h file. This disassembles into MOVE.W #$xxxx, D0. If you want to find out what other opcodes mean, try using the TMON Pro assembler as described in "TMON Pro Assembler Demo."
On a separate note, components implement routines through selectors as well. In some ways, a component is not unlike an A-trap. The ramifications of this are discussed later in the section "Bottlenecks."
Let's see what happens when we take the simple QuickTime debugging approach of breaking on the four A-traps. For example, start with the 0xAAAA trap. If you perform an " atb _AAAA" and run MoviePlayer, MacsBug is continually invoked. You can use the debugger to see the selector value that identifies the routine, but unless you have the interface files in front of you or you memorize the selector values, you won't be able to tell which QuickTime routine is being called. You can probably memorize a few routines like EnterMovies, which has a selector value of 1. You could even record all the A-trap routines (using theatr command), print to a file, and compare the traps against the interface files. However, these methods leave a lot to be desired.
Because there's no one-to-one correspondence between A-traps and routines, you need some tools to facilitate trapping QuickTime applications. To take advantage of trapping compiled applications, you'd like to be able to do the following:
USING 'MXBM' RESOURCESYou can set A-trap breaks on QuickTime routine names by creating MacsBug macros in the form of 'mxbm' resources. Unfortunately, MacsBug doesn't ship with the 'mxbm' resources for QuickTime, and creating those resources by hand would be tedious at best. So I wrote debugit, an MPW tool that converts standard Macintosh C headers into the resources. The tool and the 'mxbm' resources that are needed to set QuickTime A-trap breaks are on theDeveloper CD Seriesdisc and theQuickTime Version 1.5 for Developersdisc. (Also supplied are the 'mxbm' resources for several other managers that use A-traps with routine selectors.) You simply place the resources in your Debugger Prefs file using a resource editor and reboot.
Using MacsBug in this way is still limited because even though you can break on a routine name, the names of the QuickTime routines aren't displayed when you're in MacsBug -- only the assembly code is displayed.
TMON Pro sets aside an area of memory for you to play with, identified by the variable PlayMem. Here's a useful alias that you can install in your TMON script (it assumes you use the script provided with TMON Pro):
alias PlayTime, "TopWind .10 ðn New Memory HereHP, :Ćplaymem ð BottomWind .6 ðn New Assembly HereHP,Ćplaymem ð Open Registers #1=#0"
Now you can type "PlayTime" at the command line and have a safe area in memory for exploring the
TMON Pro assembler. The PlayTime alias anchors the two windows to the same place in memory and swaps
out the registers so that you don't harm them while you play (see Figure 1).
![[IMAGE Guschwan_rev2.GIF]](guschwan_rev2.gif)
Figure 1 TMON Pro Windows
USING A TMON PRO USER AREA
You saw (in "TMON Pro Assembler Demo") how you can type machine code in TMON Pro and
watch it disassemble. While this is fun, its practical use for developers is limited. The real power of
the TMON Pro assembler comes from the extensibility of its language. With a little work, you canuse TMON Pro to both break on routine names and display routine names instead of assembly code
in the debugger.
To extend the vocabulary of TMON Pro's interactive assembler, you need to create TMON Pro assembler macros for the A-traps and glue, which TMON Pro disassembles into the QuickTime function name. TMON Pro looks many instructions ahead to disassemble the A-trap and glue into the routine name. If you create the requisite 'Asm ' resources, the TMON Pro Assembly window can display code like
MOVE.W #1,D0 _AAAA
as follows:
_EnterMovies
If you create the proper aliases ('mxbm' resource equivalents), you can set A-trap breaks on QuickTime routine names as well.
Creating the 'Asm ' resources manually is impractical, so I modified debugit to create both the assembler macros and the aliases for setting breaks on the QuickTime routine names from a Macintosh C interface file. To load the 'Asm ' resources into TMON Pro, you also need to create a TMON Pro user area to hold the 'Asm ' resources (see "Creating Debugging Tools"). To keep the resources and aliases in one location, you place the aliases in the data fork of the TMON Pro user area. TMON Pro looks there when it's loading scripts. To use the QuickTime Angus User Area (which is on theDeveloper Series CDdisc), just drop it in your TMON folder and reboot. Remember, this user area is large and contains an alias for every QuickTime routine. But it's easy to pull it out if you want to run stealthily.
With the QuickTime Angus User Area you can set breaks as you do with 'mxbm' resources in MacsBug. Just type the routine name without the underscore at the command line (type Command- space to invoke the command line). By default, typing the name of the QuickTime routine sets an intercept action, or break, for the A-trap. You can also specify the other four trap actions by using the trap action keywords after the QuickTime routine name. For example, to turn on a heap trap action every time EnterMovies is called, type
entermovies heap
You can also turn off trap actions from the command line. So, for example, if you type "findnextcomponent," you can cancel it with "findnextcomponent nointercept." You can shorten your commands by creating a macro such as
macro ni,"nointercept"
Several useful macros are included as a separate script on theDeveloper Series CDdisc. See the TMON Pro reference manual for more information on using macros.
When you break into the debugger and look in the Memory window, TMON Pro's interactive assembler uses the 'Asm ' resources from the resource fork of the user area to interpret the assembly code and display routine names. Now you have the tools you need to easily watch the flow of QuickTime routines in a compiled application (see Figure 2).
BREAKING ON COMMON RESOURCE MANAGER ROUTINES
It may seem too obvious to mention that Macintosh routines use other Macintosh routines, but it's a
crucial debugging concept. Given a routine and its functionality, good Macintosh programmers can
make excellent guesses as to which other routines it uses. For example, FlattenMovie calls an internal
version of FlattenMovieData.
Because a movie is the significant data structure introduced with QuickTime, let's look at new movie calls (NewMovie, NewMovieFromFile, NewMovieFromHandle, NewMovieFromDataFork, and NewMovieFromScrap). Setting A-trap breaks on Macintosh routines is best done with a small speedy debugger -- like MacsBug. So let's use MacsBug to find out how QuickTime loads its data. As you probably know, the data structure for a movie is undocumented. While any type of manipulation with the movie can be done with the Movie Toolbox, leaving the movie data structure undocumented can cause some confusion as to how a movie actually works. In fact, the movie on the disk is different in structure from the movie in memory. While the movie on disk is documented, the movie in memory is not, which lets the QuickTime team change the loaded movie without affecting your application. Keep that in mind as you begin investigating the exact nature of the movie in memory.
The target application for this investigation is MoviePlayer because it calls the various new movie routines. MoviePlayer was created by the QuickTime team, and it's widely distributed. If you launch the application and choose Open from the File menu, you're presented with the CustomGetFilePreview dialog box.
![[IMAGE Guschwan_rev3.GIF]](guschwan_rev3.gif)
Figure 2 The Flow of QuickTime Routines in TMON Pro
To look at the internals of an individual routine, you need to drop into the debugger before executing the routine. Simply set your traditional A-trap break and go:
atb newmoviefromfile; g
Next, open a movie that uses a 'moov' resource. Now you're ready to investigate NewMovieFromFile's use of internal routines. Since QuickTime uses the Resource Manager, you'll set a break on GetResource and expect NewMovieFromFile to load the 'moov' resource from a file. In MacsBug, set a break on the condition:
atb getresource (sp+2)^='moov'; br pc+2
This command lets you check for all the calls that NewMovieFromFile makes to GetResource that load a 'moov' resource. Watch for one of the following messages in the debugger:
Breakpoint at address routinename
A-Trap break at address routinename
If you see the first message before the second, you know that NewMovieFromFile doesn't use GetResource. As you'll see, GetResource is not called.
But you don't need to give up on the GetResource idea. Some A-traps have variations, which makes it difficult to guess which routine is called. Two obvious variations of GetResource are Get1Resource and Get1IndResource. NewMovieFromFile can be passed nil for the resource ID, which means it probably loads the first 'moov' resource. With this theory in mind, break into NewMovieFromFile again, and this time set the break on Get1xResource instead of GetResource (Get1xResource is the MacsBug equivalent of Get1IndResource):
atb get1xresource (sp+2)^='moov'; br pc+2
When you leave MacsBug, you'll get an A-trap break and thus know how NewMovieFromFile loads the movie.
Unfortunately, breaking on GetResource works for only one of the five new movie calls. You don't get a break with NewMovie, because the call is similar to a NewWindow call and doesn't bring in a resource. You may get a break with a NewMovieFromFile call, since it does bring in the 'moov' resource from the file. It's similar to a GetNewWindow call, but it may break on Get1IndResource or Get1Resource, depending on whether you supplied a resource ID to the call. NewMovieFromHandle and NewMovieFromDataFork will not break, because a movie doesn't have to be stored in a resource. You don't get a break for NewMovieFromScrap, because it loads the movie directly from the scrap.
As you've seen, although breaking on GetResource can provide some insight, it's limited in what it can tell you about the general class of new movie calls. Breaking on GetResource showed you how the new movie calls differ in their methods of loading the data. However, it didn't show how they implement their common behavior. Their similar names indicate that the calls exhibit similar behavior in loading a movie into memory. While it's true you can break on the loading of code resources, and even code resources of different types (WDEF, CDEF, INIT), you have limited information to differentiate one code resource from another (other than by the resource type). Thus, we turn to techniques for breaking on component routines.
BREAKING ON COMMON COMPONENT MANAGER ROUTINES
Components consist of a set of routines that implement a specific type of functionality. To identify
the exact nature of the functionality, a component has an associated 'thng' resource. (At one point in
their evolution, components were called "things.") The 'thng' resource stores a reference to the
component code, a ComponentDescription record, string resources, and an icon resource. TheComponentDescription record identifies the type of functionality that the component's set of
routines implements; for example, a media handler component is identified by the OSType 'mhlr' in
the type field of the ComponentDescription record. Thus, components make it possible to break on
the loading of functionality.
Components are identical to code resources, except that a component uses an extended resource specification in the form of the 'thng' resource. Normal resources use a resource type and ID for their resource specification. Because a component consists of a typed code resource and a 'thng' resource, you can use the traditional GetResource techniques on components, but in newer and better ways.
So let's exploit QuickTime's use of components. QuickTime depends on over 50 components. The best call to break on is FindNextComponent, which queries the Component Manager for components and returns a reference to a component. It's consistently called by applications that need a component, and its parameters contain extra information about the component. Breaking on OpenComponent isn't as useful because you have no simple way of identifying the component type. You break on FindNextComponent just as you do with GetResource:
atb findnextcomponent
The first field of a ComponentDescription record is the component type. Since it's the last parameter pushed on the stack, you can anchor a dereferenced stack pointer to the upper left corner of MacsBug:
show 'sp^' a
By watching the status region, you can see which components QuickTime loads and when they're loaded. This helps you understand the internal behavior of a routine. Alternatively, in TMON Pro, you could anchor a Memory window to a dereferenced stack pointer, as shown in Figure 3.
Unfortunately, QuickTime doesn't always call the A-trap mechanism for some internal routines. A notable example is OpenDefaultComponent, which may not call FindNextComponent via the A-trap mechanism. It can use a direct dispatch mechanism, which helps speed up QuickTime. One solution to this problem is to set an A-trap break on OpenDefaultComponent as well as FindNextComponent. Another solution is to use thethingdcmd and an A-trap break on OpenComponent. Even though with OpenComponent you have no simple method of identifying the type of component, at least OpenComponent must always be called for any component that's opened. Thethingdcmd lets you find out what type of component is loaded. It lists all components registered with the Component Manager and, in the far left column, lists the number of instances.
Let's consider the NewMovieFromFile example again. You break on NewMovieFromFile, and then execute thethingdcmd to see what components are loaded, remembering particularly the number of instances. Next, you break on OpenComponent, step over it, and invokethingagain. You can easily notice the change in instances for the 'clok' component. This technique may be a little more cumbersome, but because QuickTime sometimes bypasses the trap dispatch mechanism, it's more accurate.
As more Macintosh Toolbox managers rely on components, you'll find trapping on typed functionality to be invaluable to your understanding of that manager. Debugging techniques that you've used with the Resource Manager can be used successfully with the Component Manager.
![[IMAGE Guschwan_rev4.GIF]](guschwan_rev4.gif)
Figure 3 Breaking on Component Routines With TMON Pro Debugging Tools
With that in mind, let's continue our investigation of QuickTime routines. Go back to MoviePlayer and set the breaks again on NewMovieFromFile. Then use the technique described in the previous section to find out which components are loaded. NewMovieFromFile first loads a 'clok' component. This is probably part of a NewTimeBase call. Testing this guess by breaking on NewTimeBase shows that the TimeBase is created dynamically -- it's not a static part of a movie file format. What does it mean that all NewMovieFromFile calls load a TimeBase?
QuickTime adds its own context in the form of dynamic state information. By default, a movie generates a TimeBase. Just as GrafPort supplies a data structure for graphical state information, TimeBase provides a data structure for time information. Any time can be autonomously specified by a time base, time scale, and time value, which are grouped in a convenient data structure called TimeRecord.
If you work with QuickTime a lot, you'll notice that you seldom use TimeRecord. It seems odd until you realize that if you use a movie, you already have a default TimeBase supplied. There's no point to filling out a TimeRecord structure. There are easy calls to get the movie time scale (such as GetMovieTimeScale), and you usually specify a time value. Developers often forget the time context and make redundant calls. For example, developers forget that StartMovie calls SetMovieRate with the movie's preferred rate, and call both StartMovie and SetMovieRate. For movies, don't forget the time context. (This is not to say that TimeRecord is useless; when you don't have a movie and need to specify a specific time, TimeRecord comes in handy.)If you continue breaking on component routines, you'll see that after loading a 'clok' component, NewMovieFromFile dynamically loads its media handlers. The Movie Toolbox doesn't know how to interpret media: it leaves that task to the media handlers. (Media handlers are discussed later under "Component Bottlenecks.") A movie is a dynamically loaded series of components. As a further exercise for breaking on component routines, try looking at the components that CustomGetFilePreview uses.
GRAFPORT BOTTLENECKS
QuickDraw provides some familiar examples of using bottlenecks. A grafPort contains pointers to all
the low-level routines that it uses to implement its higher-level calls. By default the bottlenecks
contain routines for drawing to the screen. When you create a grafPort, it's possible to swap out
those ProcPtrs and put in
your own. The default QuickDraw bottlenecks are usually swapped out in two circumstances:
printing and getting information. Since all of QuickDraw must route through bottlenecks in the
grafPort, and there are only 20 bottlenecks, a savvy Macintosh programmer will know which high-
level routines call which low-level routine.
QuickTime introduces a new bottleneck -- StdPix -- to handle compressed image data. StdPix replaces the newProc1 bottleneck (see Chapter 4, "Color QuickDraw," ofInside MacintoshVolume V for details). You can sit in this bottleneck (that is, replace it with one of your own) and look at compressed data before it's decompressed.
Let's look at a situation where you may want to do this. The Picture Utilities Package is useful for getting information about pictures; however, it wasn't designed to support QuickTime. For example, GetPictInfo returns an inaccurate depth for QuickTime compressed images. The following code shows how to work around this problem. You replace all a grafPort's bottlenecks with dummy routines (so that nothing is actually drawn), except you can call GetCompressedPixMapInfo in the StdPix bottleneck. GetCompressedPixMapInfo returns the ImageDescriptionHandle for the picture, from which you can get the depth. DrawPicture eventually calls StdPix, among other bottleneck routines. Because the other bottlenecks were replaced with dummy routines, DrawPicture's behavior is reduced to just a StdPix call. The parameters passed to the StdPix routine fill out the parameters of the GetCompressedPixMapInfo routine, which in turn retrieves the pixel depth via the ImageDescription structure. The sample code on the CD creates a window for this function to "draw" in.
short gDepth = -1;
pascal void myStdPix(PixMapPtr src, Rect *srcRect,
MatrixRecordPtr matrix, short mode, RgnHandle mask,
PixMapPtr matte, Rect *matteRect, short flags)
{
ImageDescriptionHandle desc;
Ptr data;
long bufferSize;
GetCompressedPixMapInfo(src, &desc, &data, &bufferSize,
nil, nil);
gDepth = (**desc).depth;
}
pascal void myTextProc(short byteCount, Ptr textBuf, Point numer,
Point denom){}
pascal void myLineProc(Point newPt){}
pascal void myRectProc(GrafVerb verb, Rect *r){}
pascal void myRRectProc(GrafVerb verb, Rect *r, short ovalWidth,
short ovalHeight){}
pascal void myOvalProc(GrafVerb verb, Rect *r){}
pascal void myArcProc(GrafVerb verb, Rect *r, short startAngle,
short arcAngle){}
pascal void myPolyProc(GrafVerb verb, PolyHandle poly){}
pascal void myRgnProc(GrafVerb verb, RgnHandle rgn){}
pascal void myBitsProc(BitMap *bitPtr, Rect *srcRect, Rect *dstRect,
short mode, RgnHandle maskRgn){}
void GetQTImagePixelDepth(PicHandle picture)
{
CQDProcs bottlenecks;
SetStdCProcs(&bottlenecks); // Define our own bottlenecks.
bottlenecks.textProc = (Ptr)myTextProc;
bottlenecks.lineProc = (Ptr)myLineProc;
bottlenecks.rectProc = (Ptr)myRectProc;
bottlenecks.rRectProc = (Ptr)myRRectProc;
bottlenecks.ovalProc = (Ptr)myOvalProc;
bottlenecks.arcProc = (Ptr)myArcProc;
bottlenecks.polyProc = (Ptr)myPolyProc;
bottlenecks.rgnProc = (Ptr)myRgnProc;
bottlenecks.bitsProc = (Ptr)myBitsProc;
bottlenecks.newProc1 = (Ptr)myStdPix; // pixProc.
// Install our custom bottlenecks to intercept any compressed
// images.
(*(qd.thePort)).grafProcs = (QDProcs *)&bottlenecks;
DrawPicture(picture, &((**picture).picFrame));
(*(qd.thePort)).grafProcs = 0L;
// Switch back to the default procs.
}
COMPONENT BOTTLENECKS
A QuickTime routine may be implemented by a component. In this case, the concept of sitting in
bottlenecks applies in a useful way to QuickTime components. As you know, the Component
Manager sends the routine selector to the component, and the component parses the selector in its
main function. Since all the selectors flow through the main function, it would be extremely valuable
to replace the component with your own delegating component in order to watch the selectors flow
by. Just as you can sit in a bottleneck and capture routines, you can capture a component, perform an
operation, and delegate the rest to the captured component. Then you could identify the sequence of
routines needed to implement specific functionality.
Fortunately, some components have standardized interfaces as defined by Apple. These public APIs make it easy to match up the selector to the routine name, as defined in the interface files. With the introduction of QuickTime 1.5, the API for the base media handler has been made available as defined in the file MediaHandlers.h.
With a delegating component, you could theoretically modify the behavior of any component. But whether you can modify a given component depends on whether it implements the target request. Many components in QuickTime don't implement this functionality, which is unfortunate. However,with the introduction of QuickTime 1.5, the media handlers support the target request. By allowing media handlers to be delegated, QuickTime 1.5 greatly opens its architecture, giving enhanced meaning tomultimedia. For example, the text media handler delegates the generic media handler and uses its media scheduling and editing functions to do all the hard work. If you want to write your own media handler, delegating the generic media handler is just what you need.
To create a generic delegating component, I'll use a sample supplied with the article "Techniques for Writing and Debugging Components" indevelopIssue 12. The sample is called NuMathComponent. It's a simple matter to convert it into a generic delegating component.
PrivateGlobals**globals = (PrivateGlobals**)storage;This declaration gives you access to the fields in your global storage.
if (globals)
DelegateComponentCall(params,
(**globals).delegateComponentInstance);
else
result = paramErr;
Your main function should look like the following sample code. Focus on the call to DelegateComponentCall, as it's the major change needed to make the generic delegating component. To use the delegating component, either put it in the System Folder and reboot or drag and drop it on Reinstaller II.
pascal ComponentResult main(ComponentParameters *params,
Handle storage)
{
// This routine is the main dispatcher for the NuMath component.
ComponentResult result = noErr;
PrivateGlobals** globals = (PrivateGlobals**)storage;
// Did we get a Component Manager request code (< 0)?
if (params->what < 0)
{
switch (params->what)
{
case kComponentOpenSelect: // Open request.
result = CallComponentFunctionWithStorage(storage,
params, (ComponentFunction) _NuMathOpen);
break;
case kComponentCloseSelect: // Close request.
result = CallComponentFunctionWithStorage(storage,
params, (ComponentFunction) _NuMathClose);
break;
case kComponentCanDoSelect: // Can Do request.
result = CallComponentFunction (params,
(ComponentFunction) _NuMathCanDo);
break;
case kComponentVersionSelect: // Version request.
result = CallComponentFunction (params,
(ComponentFunction) _NuMathVersion);
break;
case kComponentRegisterSelect: // Register request.
result = CallComponentFunction (params,
(ComponentFunction) _NuMathRegister);
break;
case kComponentTargetSelect:
// Target request unsupported. Unknown request.
result = paramErr;
break;
}
}
else // Was it one of our request codes?
{
if (globals)
DelegateComponentCall(params,
(**globals).delegateComponentInstance);
else
result = paramErr;
}
return (result);
}
Now let's go back to the old example: Open MoviePlayer, set the break on DelegateComponentCall, and anchor a Memory window at "Ć(sp+4)^+2" for TMON Pro or "show '(sp+4)^+2' l" for MacsBug. This displays the selector from the ComponentParameters data structure passed into DelegateComponentCall. You'll be able to read the selectors for the routines as they're passed into the main function of the component. Remember, you can compare these numbers with the interface files (there are no interface files for the video media handler because it doesn't have a public API). In TMON Pro, you can open a View window of the interface file and look at the selectors without leaving the debugger.
You can try other situations and other traps to see whether they call the video media handler. Or set breaks in the open, close, version, and register routines -- to find out how Things! works, for example. If you bring up the Things! control panel and select your media handler, you'll see Things! calls a trio of routines -- open, version, and close. Also, you can see what calls are made to the component on startup.
A simpler technique can be used if you just want to analyze the selectors. Enter MacsBug and executething, which will list the entry point for each component. Set a breakpoint on an entry point. You can now use the same "show" instruction to display the selector. If it uses a fast dispatch mechanism, the selector will be in the low-order word of register D0. To modify this sample to be a media handler, you need to keep the same basic structure but support some or all of the selectors defined in the MediaHandlers.h file. For a description of those routines, refer to theQuickTime Version 1.5 for DevelopersCD.
MAKING AN ANGUS USER AREA
To create a debugging user area for TMON Pro you need to have TMON Pro installed, because the script
will automatically place the user area in your TMON Folder. In addition, you need to do the following:
With the tools properly stored, you can create the QuickTime Angus User Area with the following command:
makeuserarea {CIncludes}"Movies.h" ð
{CIncludes}"ImageCompression.h" ð
{CIncludes}"Components.h" ð
{CIncludes}"QuickTimeComponents.h" ð
{CIncludes}"MediaHandlers.h"
MakeUserArea is a script that uses the Rez, C, and debugit tools, so you can alter its behavior fairly easily. Be sure to use the script with the managers of your choice!
MAKING 'MXBM' RESOURCES
To make 'mxbm' resources, you need to place the debugit tool in your MPW Tools folder, Macsbug.r in your
MPW RIncludes folder, the MakeMxbm script in your MPW Scripts folder, and a Debugger Prefs file in your
System Folder. Here's how to make the 'mxbm' resources for Movies.h:
makemxbm {CIncludes}Movies.h MoovDispatch 128
BILL ("ANGUS") GUSCHWAN describes Angus as an identity cocktail in the sky. If his favorite philosophers, character, and
author were alive today, we can imagine what they might say about the young man and the sky. Gottlieb Frege: "Asetting sun indicates the object, sun. But the sun also rises. Just as a night in the forest, mountains in springtime, and a
walk in the rain convey solitude, each sense adds knowledge to the meaning of the sun. Thus, Angus does not singularly
denote Bill Guschwan, but rather indicates a sense of him." Ludwig Wittgenstein: "Bullfighting is an analogy for life.
Angus represents the bull, whereas language represents the toreador's red cape. Thus, Angus perishes if he trusts it, and
destroys if he ignores it." Andromache: "As a young Indian identifies with soaring hawks, young Angus identifies with the
lost generation of somnambulating dogcows. As an Indian peasant links with god via the farm tools in the hands of a
Buddhist statue, Angus links with god via the TMON Pro manual in the hands of a Zimmerman statue." Ernest
Hemingway: "OK. Sure, Angus. Anyone for a martini cocktail? With a twist." *
To easily read the type of resource in the upper left corner of MacsBug, try executing the command "show 'sp+2' a". Thea parameter lets you view the information in ASCII, and the single quotation marks tell MacsBug to anchor the status region to the changing location of the stack pointer. In TMON Pro, use the command "Ć(sp+2)" in a Memory window. *
Breaking on internal A-traps assumes that QuickTime uses the A-trap mechanism. A later example illustrates how this assumption can affect your investigations.*
For more information on components, see the QuickTime or System 7.1 documentation on the Component Manager, and see Gary Woodcock and Casey King's article, "Techniques for Writing and Debugging Components," in develop Issue 12.*Time bases are discussed in "Time Bases: The Heartbeat of QuickTime" by Guillermo Ortiz in develop Issue 12.*
QuickTime components that implement the target request include Apple generic media handler, Apple standard media handler, Apple video media handler, Apple sound media handler, Apple text media handler, movie controller, movie grabber video channel, and movie grabber sound channel. *
When you're exploring, it's useful to use the dx command to turn the Debugger and DebugStr traps on and off. In TMON Pro, you can use the Options window to achieve the same result. If you set debugger traps in all the component requests, you'll inevitably be annoyed by the constant breaking. *
THANKS TO OUR TECHNICAL REVIEWERS Jim Batson, Peter Hoddie, Guillermo Ortiz, John Wang, Gary Woodcock *
