Q Here's a tidbit I stumbled across in Inside Macintosh Volume VI, page 3-10: the four
Dialog Manager procedures CouldDialog, CouldAlert, FreeDialog, and FreeAlert are no
longer supported. I use CouldDialog, and I happened to notice that it didn't work right
when I tested it under System 7, but I reported it as a bug. Now you tell us that it's not
guaranteed to work in System 7. I can't recall a trap ever becoming suddenly
unsupported like this. What's the story?
A The system software engineers felt that CouldDialog, CouldAlert, FreeDialog, and
FreeAlert didn't do much good under System 6, since the Could calls never completely
guaranteed that all dialog items were loaded in. These calls also caused problems in the
beta versions of System 7. Relatively little software uses those traps anymore; like
many things in Inside Macintosh Volume I, they're relics of the days when Macintosh
programmers had to deal with desk accessory and floppy disk support issues. So these
calls were simply patched out. In the final System 7, the traps return without doing
anything.
Q I can't get the black-and-white version of my lasso-type tool to work correctly with
CalcMask and CopyMask. With CalcCMask it seems to work fine. What could I be doing
wrong?
A CalcMask and CalcCMask are similar in that they both generate a one-bit mask
given a source bitmap. With CalcCMask, though, a pixMap can be used in place of the
source bitmap; the seedRGB determines which color sets the bits in the mask image. An
easy mistake to make is to forget that CalcCMask expects a pointer to a BitMap data
structure while CalcMask expects a pointer to the actual bit image. And unlike
CalcCMask, which uses bounding rectangles for the image's dimensions, CalcMask uses
the bitmap's rowBytes and pixel image offsets to determine the bounding Rects for the
image. A typical call to these routines is as follows:
BitMap source, mask;
CalcMask (source.baseAddr, mask.baseAddr, source.rowBytes,
mask.rowBytes, source.bounds.bottom-source.bounds.top,
source.rowBytes>>1);
CalcCMask (&source, &mask, &(*source).bounds, &(*mask).bounds,
&seedRGB, nil, 0);
One last thing to note when using CalcMask is that the width of the image is in words
and not bytes. To learn more about these routines, see page 24 of Inside Macintosh
Volume IV and page 72 of Inside Macintosh Volume V. Also, the Developer CD Series
disc contains a sample, CalcCMask&CalcMask, that shows how to use these routines.
Q How do I update the color table of my off-screen graphics world without destroying
the picture?
A The recommended approach for changing the color table of an existing GWorld
involves calling UpdateGWorld, passing either clipPix or stretchPix for gWorldFlags.
When passed either of these constants, QuickDraw knows to update the pixels of the
pixMap image. Even though the actual image isn't changed, the flags are still needed to
remap the pixels to their new colors.
Q Are there any C++ or C compilation flags that will optimize performance of the
Macintosh Quadra computers? Even when I use the "-NeedsMC68030" flag in MacApp,
an investigation of the MABuild source files reveals that it sets compiler flags only for
the 68020 optimization. If Quadra-specific compilation flags don't exist, do you have
any Quadra performance optimization suggestions?
A The current MPW compilers don't have a 68040 performance optimization flag,
though Apple's future compilers will optimize code for the best possible '040
performance. In the meantime, here are some tips on '040 performance tuning:
Q In the past we had heard of a problem using calloc and NewPtr in the same program.
Is this true?
A There are a few difficulties, which you can deal with if you need to. The primary
problem is that calloc and all the other malloc routines weren't designed for the
Macintosh platform. Macintosh memory management is designed around trying to
squeeze as much as possible out of a limited memory area, which is why handles are
the primary storage scheme in a Macintosh; they can move, and so greatly reduce
memory fragmentation. Because the malloc tools return a pointer, they have to be
located in a locked block, so they tend to lead to fragmentation if used with any other
memory allocation calls (such as NewPtr). For this reason, any use of the malloc suite
of allocation calls isn't recommended for Macintosh programs. The only good reason to
use them is if you're porting a large body of code from other platforms; in this case, it
may be a reasonable tradeoff to keep the old allocation code.
You should also be aware that most of the Macintosh malloc routines never free up
memory. When you malloc some space, the routine must first allocate it from the
Memory Manager. It allocates a large block of space using NewPtr and divides it
internally for distribution in response to malloc calls. If, however, you eventually
free all the blocks you allocated from this NewPtr block, the block won't be released to
the Memory Manager with the DisposPtr call. This means that once you allocate some
memory with malloc, you won't be able to free it and then use that memory from a
Macintosh allocation call. Thus, if you had two phases to your program, one of which
used the malloc calls extensively and the second which used Toolbox calls, the second
phase wouldn't be able to use memory freed by the first phase. That memory is still
available in the malloc pool, of course; it simply can't be used by NewPtr or
NewHandle. The malloc routines supplied by THINK C work similarly, as described in
their Standard Libraries Reference . Thus, mixing the C and Macintosh allocation
routines requires special care.
Q Why do I get error -903 (a PPC Toolbox noPortErr) when I send an Apple event to a
running application with AESend?
A The isHighLevelEventAware bit of the sending application's SIZE -1 resource (and
SIZE 0 resource, if any) must be set.
Q Sometimes the Alias Manager mistakes one volume for another. In particular, we're
experiencing problems getting aliases to volumes to work correctly with our
AppleTalk Filing Protocol (AFP) server volumes. Here's how I can duplicate the
problem:
Is this a bug in the Alias Manager or did we implement something the wrong way in
our server?
A As noted in the Alias Manager chapter of Inside Macintosh Volume VI, the Alias
Manager uses three criteria to identify a volume: the volume's name, the volume's
creation date, and the volume's type. If the Alias Manager can't find a mounted volume
that matches all three criteria, it tries again with just the volume's creation date and
the volume's type. This second attempt finds volumes that have been renamed. If that
attempt fails, the Alias Manager tries one last time on mounted volumes with the
volume's name and the volume's type. If it can't find a mounted volume with those three
attempts and the alias is to an AFP volume (a file server), the Alias Manager assumes
the volume is unmounted and attempts to mount it.
The problem you're having is probably happening because both volumes have the same
creation date and type. That will cause the Alias Manager to mistake VolA for VolB and
VolB for VolA when it attempts to match by volume creation date and volume type. You
can prevent the Alias Manager from making this mistake by making sure your server
volumes all have unique volume creation dates.
This same behavior can be observed when partitioned hard disks use the same volume
creation date for all partitions. If one partition isn't mounted, the Alias Manager can
mistake one disk partition for another.
Q I'm looking for a Macintosh Toolbox routine that will allow me to turn down the
backlight on a Macintosh PowerBook from within a screen saver to prevent screen
burn and save battery life. Is there such a thing?
A Turning down the backlight won't prevent screen burn. Screen burn can be
prevented only by either shutting the system off or letting the PowerBook enter its
native sleep mode.
In an RGB monitor the phosphor that illuminates each pixel is what causes screen
burn. By setting the pixels to black (the phosphor isn't active) or rapidly changing the
colors of an RGB screen (as with a screen saver), you can prevent screen burn. While
effective on an RGB display, setting the pixels to black may actually cause screen
burn on a PowerBook. The reason is that all the PowerBooks have a liquid crystal
display (LCD), which can be burned by white pixels, black pixels, or repeating
patterns on the screen over a period of time. For this type of display the only good way
to save the screen is to power it off.
Only the Power Manager has access to the chip that shuts the screen off. After a
certain amount of time, the Power Manager makes the function calls to put the system
to sleep. (These calls are documented in Chapter 31 of Inside Macintosh Volume VI.) At
this time the Power Manager signals the chip to turn the screen off. There's no direct
interface between the user and the chip to achieve this. It's best to let the PowerBook's
native screen-saving mechanism (sleep mode, which shuts off the screen) work as is.
This also has the benefit of saving the precious battery power that would be used by the
screen saver.
By the way, if your PowerBook screen has ghost images because you've left it on too
long without going into sleep mode, letting the screen sleep or shutting down your
computer for at least 24 hours will probably make the ghost images go away. Although
there's no hard and fast rule, usually ghost images caused by your system being on for
less than 24 hours won't be permanent if the screen is rested for an equal amount of
time. Any ghost images caused by the system being on for greater than 24 hours may
be permanent.
Q How can I call Connect in AppleTalk Remote Access without an existing ARA
connection file created by the Remote Access application?
A This isn't directly possible, because without the ARA connection file your program
becomes tied to the underlying link tool. The file was implemented so that in the
future, when there are different link tools for the different link types, the program
will know the link type and tool, plus associated link-specific data to use. To connect
without the ARA connection file requires knowledge of the link tool data structures
used by each individual link tool. Because these may change, your code may break.
However, there's a roundabout way of calling Connect. It requires that you first
establish a connection using a document created by the ARA application. Next, make the
IsRemote call, setting the optionFlags to ctlir_getConnectInfo (see page 11 of the
AppleTalk Remote Access Application Programming Interface Guide). This will cause
the information necessary to create the remote connection (connectInfoPtr) to be
returned. You would then save this connectInfo data in your application, and when you
want to connect sometime later, you would pass this data to the Connect call (in the
connectInfo field).
Q When we allocate space for a new file using AllocContig with an argument in
multiples of clump size, we should be grabbing whole clumps at a time so that file
length (and physical EOF) will be a multiple of clump size. What happens if we
truncate a file by moving the logical EOF somewhere inside a clump? Inside Macintosh
says disk sectors are freed at the allocation block level, so we could have a file whose
physical EOF isn't a multiple of clump size, right? Does AllocContig guarantee that the
new bytes added are contiguous with the end of the existing file, or only that the newly
added bytes are contiguous among themselves? If the logical and physical EOFs aren't
the same, does AllocContig subtract the difference before grabbing the new bytes, or do
we get the extra bytes (between EOFs) as a bonus?
A You can create a file whose physical size isn't a multiple of the clump size, if you
try. When the file shrinks, the blocks are freed at the allocation level, without regard
for the clump size. Therefore, if you set the logical EOF to a smaller value, you can
create a file of any physical length.
There's no guarantee that the allocated bytes will be contiguous with the current end
of the file. The decisions that file allocation makes are as follows:
So these are the actions that file allocation will take:
You don't get "extra" space with AllocContig. It just does a basic allocation but makes
sure any added blocks are contiguous. PBAllocContig does not guarantee that the space
requested will be allocated contiguously. Instead, it first grabs all the room remaining
in the current extent, and then guarantees that the remaining space will be contiguous.
For example, if you have a 1-byte file with a chunk size of 10K and you try to allocate
20K, 10K-1 bytes will be added to the current file; the remaining 10K+1 bytes are
guaranteed to be contiguous.
Q Inside Macintosh says that ROM drivers opened with OpenDriver shouldn't be closed.
However, it seems that any driver opened with OpenDriver should be closed when the
application is done. Should our application close the serial port after using it?
A As a general rule, applications that open the serial driver with OpenDriver should
do so only when they're actually going to use it, and they should close it when they're
done. (Note that it's important to do a KillIO on all I/O before closing the serial port!)
There are a couple of reasons for closing the port when you're finished using it. First,
it conserves power on the Macintosh portable models; while the serial port is open the
SCC drains the battery. Second, closing the serial port avoids conflicts with other
applications that use it. Inside Macintosh is incorrect in stating that you shouldn't
close the port after issuing an OpenDriver call.
Most network drivers shouldn't be closed when an application quits, on the other hand,
since other applications may still be accessing the driver.
Q We've tried to put old CDs to productive use. We use them for coasters, but you can
only drink so many Mountain Dews at once. We've even resorted to using them for
skeet-shooting practice. Can you suggest other good uses for my old CDs?
A It's not well known that stunning special effects in some films, such as Terminator
2, were produced with the aid of compact disc technology. For example, the "liquid
metal" effect used for the evil terminator was nothing more than 5000 remaindered
Madonna CDs, carefully sculpted into the shape of an attacking android. And did you
know that dropping a CD into a microwave oven for five seconds or so produces an
incredible "lightning storm" effect? (Kids, don't try this at home; we're trained
professionals.) For ideas of what you can do with old CDs, see the letter on page 5.
Q I need to launch an application remotely. How do I do this? The Process Manager
doesn't seem to be able to launch an application on another machine and the Finder
Suite doesn't have a Launch Apple event.
A What you need to do is use the OpenSelection Finder event. Send an OpenSelection to
the Finder that's running on the machine you want to launch the other application on,
and the Finder will resolve the OpenSelection into a launch of the application.
As you can see if you glance at the OpenSelection event in the Apple Event Registry,
there's one difficulty with using it for remote launching: You have to pass an alias to
the application you want to launch. If the machine you want to launch the application on
is already mounted as a file server, this isn't important, since you can create an alias
to that application right at that moment. Or, if you've connected in the past (using that
machine as a server) you can send a previously created alias and it will be resolved
properly by the Finder on the remote machine.
However, if you want to launch a file without logging on to the other machine as a
server, you'll need to use the NewAliasMinimalFromFullPath routine in the Alias
Manager. With this, you'll pass the full pathname of the application on the machine you
want to launch on, and the Alias Manager will make an alias to it in the same way it
does for unmounted volumes. The obvious drawback here is that you'll need to know the
full pathname of the application -- but there's a price to pay for everything. The
FinderOpenSel sample code on the Developer CD Series disc illustrates this use of the
NewAliasMinimalFromFullPath routine.
Q When I try to link my driver in MPW 3.2, it tells me
### Link: Error : Output must go to exactly one segment when using "-rt" (Error 98) ### Link: Errors prevented normal completion.
In all my source files I have #pragma segment Main {C} and SEG 'Main' {Asm}
directives. Why is it doing this? What factors determine how segments are assigned
(besides the #pragma stuff)? How can I get it to work?
A The problem is probably that you're including modules from the libraries that are
marked for another segment. Usually the culprit here is that some of the routines in
StdCLib or some other library are marked for the StdIO segment. You can generally fix
this by using the -sg option to merge segments, either explicitly by naming all the
segments you want to merge, or implicitly by just putting everything into one
segment. You probably want to do the latter, because you only want one segment
anyway. Thus, what you should do is add the option "-sg Main" to your link line in
place of the "-sn Main=segment" option. This will merge all segments into the Main
segment, making it possible to link.
Q How do I count the number of items in a dialog without System 7's CountDITL? My
solutions are either messy or dangerous: (1) Fiddle with the dialog's item list, (2)
Try to find out which DITL the dialog used and read the count from the DITL resource,
or (3) Repeatedly call GetDItem until garbage is returned. :-(
A It's possible to use the CountDITL function with system software version 6.0.4 or
later if the Macintosh Communications Toolbox is installed, because it's included as a
part of the Toolbox. It's also possible, as you've found, to use the first two bytes of the
DITL resource to get the number of items in the item list (see Inside Macintosh
Volume I, page 427). If the handle to your DITL resource is defined as ditlHandl, for
example, you can get at the number of items as follows:
short **ditlHandl; ditlHandl = (short **)ditlRez; itemcount = (**ditlHandl) + 1;
Q How does Simple Player determine whether a movie is set to loop or not? Movie files
that are set to loop seem to have a string of 'LOOP' at the end of the 'moov' resource.
Does Simple Player check 'LOOP'?
A Simple Player identifies whether movies are set to loop by looking within the user
data atoms for the 'LOOP' atom, as you've noticed. It's a 4-byte Boolean in which a
value of 1 means standard looping and a value of 0 means palindrome looping. Your
applications should add the user data 'LOOP' atom to the end of the movie when a user
chooses to loop. We recommend this method as a standard mechanism for determining
the looping status of a movie. If the 'LOOP' atom doesn't exist, there's no looping. The
calls you need to access this information are GetMovieUserData, GetUserData,
AddUserData, and RemoveUserData, as defined in the Movie Toolbox chapter of the
QuickTime documentation. For more information see the Macintosh Technical Note
"Movies 'LOOP' Atom."
Q Calling SetFractEnable seems to force the width tables to be recalculated regardless
of the setting of the low-memory global FractEnable. We're calling this routine at a
central entry point for any document, as it's a document-by-document attribute. We
then unconditionally call SetFractEnable(false) on exit back to the event loop, to be
nice to other applications. Calling SetFractEnable(false) seems to trigger the
recalculation even though FractEnable is false. What's the best way to get around this?
A Your observation is correct. The SetFractEnable call stuffs the Boolean parameter
(as a single byte) into the low-memory global $BF4 and indiscriminately invalidates
the cached width table by setting the 4-byte value at $B4C (LastSpExtra, a Fixed
value) to -1. Obviously, it wasn't anticipated that SetFractEnable could be called
regularly with a parameter that often doesn't change the previous setting. (By the
way, the same observation applies to SetFScaleDisable.)
In your case, you may want to keep track of the fractEnable setting in your application
and avoid redundant SetFractEnable calls. (Note that it's not a good idea to use the above
insider information and poke at $BF4 and $B4C on your own!)
You don't need to think of other applications when resetting fractEnable; it belongs to
those low-memory globals that are swapped in and out during context switches to other
applications.
Q It looks as though the Event Manager routine PostHighLevelEvent could be (ab)used
to send low-level messages, like phony mouse clicks and keystrokes. Would this work?
A No; unfortunately, this won't work. A few reasons why:
So the answer is that you can't send user-level events to an HLE-aware application. If
you want to drive the interface of an old application in System 7, you have to use the
same hacky method you used under all previous systems. This, by the way, is one of the
main reasons why MacroMaker wasn't revised for System 7. Apple decided that it
wasn't supportable and that we would wait for applications to update to System 7 and
take advantage of third-party Apple event scripting systems.
Q What's the recommended method for allowing an AppleTalk node to send packets to
itself using AppleTalk's self-send mode (intranode delivery), assuming customers are
running various versions of AppleTalk? There used to be a control panel called
SetSelfSend that would turn on AppleTalk self-send mode at startup time. Should we
use that control panel or should we use the PSetSelfSend function in our program to set
the self-send flag ourselves?
A AppleTalk self-send mode requires AppleTalk version 48 or greater. You can check
the AppleTalk version with Gestalt or SysEnvirons. All Macintosh models except for
the Macintosh XL, 128, 512, and Plus have AppleTalk version 48 or greater in ROM.
The SetSelfSend control panel is still available on the Developer CD Series disc
(Tools & Apps:Intriguing Inits/cdevs/DAs:Pete's hacks-Moof!:SetSelfSend). However,
we don't recommend it as a solution if you need to use self-send mode in your program.
Instead, you should use the PSetSelfSend function to turn self-send mode on with your
program.
AppleTalk's self-send mode presents a problem. Any changes made to the state of
self-send will affect all other programs that use AppleTalk. That is, self-send mode is
global to the system. Because of this, programs using self-send should follow these
guidelines:
Q In a version 2 picture, the picFrame is the rectangular bounding box of the picture,
at 72 dpi. I would like to determine the bounding rectangle at the stored resolution or
the resolution itself. Is there a way to do this without reading the raw data of the PICT
resource itself?
A With regular version 2 PICTs (or any pictures), figuring out the real resolution of
the PICT is pretty tough. Applications use different techniques to save the information.
But if you make a picture with OpenCPicture, the resolution information is stored in
the headerOp data, and you can get at this by searching for the headerOp opcode in the
picture data (it's always the second opcode in the picture data, but you still have to
search for it in case there are any zero opcodes before it). Or you can use the Picture
Utilities Package to extract this information.
With older picture formats, the resolution and original bounds information is
sometimes not as obvious or easily derived. In fact, in some applications, the PICT's
resolution and original bounds aren't stored in the header, but rather in the pixel map
structure(s) contained within the PICT.
To examine these pixMaps, you'll first need to install your own bitsProc, and then
manually check the bounds, hRes, and vRes fields of any pixMap being passed. In most
cases the hRes and vRes fields will be set to the Fixed value 0x00480000 (72 dpi);
however, some applications will set these fields to the PICT's actual resolution, as
shown in the code below.
Rect gPictBounds;
Fixed gPictHRes, gPictVRes;
pascal void ColorBitsProc (srcBits, srcRect, dstRect, mode, maskRgn)
BitMap *srcBits;
Rect *srcRect, *dstRect;
short mode;
RgnHandle maskRgn;
{
PixMapPtr pm;
pm = (PixMapPtr)srcBits;
gPictBounds = (*pm).bounds;
gPictHRes = (*pm).hRes; /* Fixed value */
gPictVRes = (*pm).vRes; /* Fixed value */
}
void FindPictInfo(picture)
PicHandle picture;
{
CQDProcs bottlenecks;
SetStdCProcs (&bottlenecks);
bottlenecks.bitsProc = (Ptr)ColorBitsProc;
(*(qd.thePort)).grafProcs = (QDProcs *)&bottlenecks;
DrawPicture (picture, &((**picture).picFrame));
(*(qd.thePort)).grafProcs = 0L;
}
Q The code I added to my application's MDEF to plot a small icon in color works except
when I hold the cursor over an item with color. The color of the small icon is wrong
because it's just doing an InvertRect. When I drag over the Apple menu, the menu
inverts behind the icon but the icon is untouched. Is this done by brute force,
redrawing the small icon after every InvertRect?
A The Macintosh system draws color icons, such as the Apple icon in the menu bar,
every time the title has to be inverted. First InvertRect is called to invert the menu
title, and then PlotIconID is called to draw the icon in its place. The advantage of using
PlotIconID is that you don't have to worry about the depth and size of the icon being
used. The system picks the best match from the family whose ID is being passed, taking
into consideration the target rectangle and the depth of the device(s) that will contain
the icon's image.
The Icon Utilities call PlotIconID is documented in the Macintosh Technical Note
"Drawing Icons the System 7 Way" (formerly #306); see this Note for details on
using the Icon Utilities calls.
Q The cursor flashes when the user types in TextEdit fields in my Macintosh
application. This is done in TEKey. I notice that most programs hide the cursor once a
key is pressed. I don't care for this because then I have to move the mouse to see where
I am. Is this a typical fix for this problem and an accepted practice?
A There's very little you can do to avoid this. The problem is that every time you draw
anything to the screen, if the cursor's position intersects the rectangle of the drawing
being done, QuickDraw hides the cursor while it does the drawing, and then shows it
again to keep it from affecting the image being drawn beneath it. Every time you enter
a character in TextEdit, the nearby characters are redrawn. Usually this is invisible
because the characters just line up on top of their old images, but if the cursor is
nearby and visible, it will flicker while it's hidden to draw the text. This is why
virtually all programs call ObscureCursor when the user types. Also, most users don't
want the image of the cursor obscuring text they might be referring to, yet they don't
want to have to move it away and then move it back to make selections. Because it's so
commonplace, hiding the cursor probably won't bother your users; in fact, they might
very well prefer the cursor hidden. This, combined with the fact that there's very
little you can do to help the flickering, suggests that you should obscure the cursor
while the user types.
Q We're using Apple events with the PPC Toolbox. We call StartSecureSession after
PPCBrowser to authenticate the user's identity. The user identity dialog box is
displayed and everything looks good. However, in the first AESend call we make, the
user identity dialog is displayed again. (It isn't displayed after that.) Why is this
dialog being displayed from AESend when I've already authenticated the user identity
with StartSecureSession?
A First, a few PPC facts: * When a PPC session is started, StartSecureSession lets the
user authenticate the session (if the session is with a program on another Macintosh)
and returns a user reference number for that connection in the userRefNum field of
the PPCStartPBRec. That user reference number can be used to start another
connection (using PPCStart instead of StartSecureSession) with the same remote
Macintosh, bypassing the authentication dialogs. * User reference numbers are valid
until either they're deleted with the DeleteUserIdentity function or one of the
Macintosh systems is restarted. * If the name and password combination used to start a
session is the same as that of the owner of the Macintosh being used, the user reference
number returned refers to the default user. The default user reference number
normally is never deleted and is valid for connections to the other Macintosh until it's
deleted with DeleteUserIdentity or one of the Macintosh systems is restarted.
With that out of the way, here's how user reference numbers are used when sending
high-level events and Apple events: When you first send a high-level event or an Apple
event to another Macintosh, the code that starts the session with the other system
doesn't attempt to use the default user reference number or any other user reference
number to start the session, and it doesn't keep the user reference number returned to
it by StartSecureSession. The session is kept open for the life of the application, or
until the other side of the session or a network failure breaks the connection. When
you started your PPC session, StartSecureSession created a user reference number
that could be used to start another PPC session without authentication. However, the
Event Manager knows nothing of that user reference number, so when you send your
first Apple event, the Event Manager calls StartSecureSession again to authenticate the
new session. Since there isn't any way for you to pass the user reference number from
the PPC session to the Event Manager to start its session, there's nothing you can do
about this behavior.
Q How can I make my ImageWriter go faster?
A To make your ImageWriter go blazingly fast, securely tie one end of a 12-foot nylon
cord around the printer and the other end around your car's rear axle. If your car has
a manual transmission, hold the clutch in and race your car's engine until the
tachometer is well into the red zone. Slip the clutch and off you go! If your car has an
automatic transmission, you can approach the same results by leaving plenty of slack
in the rope before peeling out.
Kudos to our readers who care enough to ask us terrific and well thought-out
questions. The answers are supplied by our teams of technical gurus; our thanks to all.
Special thanks to Chris Berarducci, Tim Dierks, Steve Falkenburg, Marcie "M. G."
Griffin, Charles Grosjean, Bill Guschwan, C. K. Haun, Dave Hersey, Dennis Hescox,
Rich Kubota, Scott Kuechle, Edgar Lee, Jim Luther, Joseph Maurer, Kevin Mellander,
Guillermo Ortiz, Dave Radcliffe, Greg Robbins, Kent Sandvik, Eric Soldan, Brigham
Stevens, Dan Strnad, Forrest Tanaka, and John Wang for the material in this Q & A
column. *
Have more questions? Need more answers? Take a look at the Q & A Technical
Notes on the Developer CD Series disc and the Dev Tech Answers library on
AppleLink.*