MACINTOSH Q & A

MACINTOSH DEVELOPER TECHNICAL SUPPORT

Q When a request for information is passed to me through an Apple event, the direct object parameter of my reply event is a descriptor list that includes an AERecord of my information. When I use AEPutPtr and the AEPutParamDesc, is the data copied or merely referenced? Should I be disposing of the AERecord and/or the descriptor list, or should I expect AEProcessAppleEvent to dispose of them?

A Whenever you make one of the AEPutXXXX calls, the Apple Event Manager copies the data you put into the list, event, or record, so as soon as you make the call you can dispose of the data you put. Thus, the following is correct:

AEPutParamDesc(&theEvent, keyDirectObject, &theSpec);
AEDisposeDesc(&theSpec);

And so is this:

HLock(myTextHandle);
AEPutParamPtr(&theEvent, keyDirectObject, typeText,
    (Ptr)*myTextHandle, GetHandleSize(myTextHandle));
DisposeHandle(myTextHandle);

The only two descriptors disposed of by the Apple Event Manager itself (at the conclusion of AEProcessAppleEvent) are the original Apple event and the reply Apple event. So, anything that you create and manipulate yourself should be disposed of by you when you add it to another Apple event record or when you're done with it. The two that you don't dispose of yourself are theEvent and reply, which are passed to you, as in:

pascal OSErr AEXXXHandler(AppleEvent *theEvent, AppleEvent *reply,
    long refIn)

This even holds true for AESend. When you send an event, you can immediately dispose of your copy of the event, as follows:

AESend(&myEvent, nil, kAENoReply, kAENormalPriority, 
    kAEDefaultTimeout, nil, nil);
AEDisposeDesc(&myEvent);

Q The System 7.1 Digest has a disturbing comment about GetMHandle -- namely that it was never supported and will no longer work. Is this true?

A This warning is misleading and is being corrected in future release notes. It applies only to pop- up menus created with the pop-up menu control. Before System 7.1, after a control was created GetMHandle would return the menu handle for the control, although it was never documented as doing so. In System 7.1 it was changed so that the menu would be inserted into the menu list only when the control was getting ready to pop up the menu and deleted as soon as the control was done with it, so you could no longer use GetMHandle to retrieve the menu handle. The proper way to get the menu handle is from the mHandle field of the popupPrivateData structure. The handle to this structure is in the contrlData field of the pop-up menu's control record.

A corollary is that the pop-up control has always checked to see if the menu is already in the menu list. If it is, the control doesn't get the menu from the menu resource and doesn't delete the menu when it's done. You can use this feature, for example, if you want to create a menu with NewMenu rather than getting it from a resource. In this case, and all other cases where the application inserts and deletes the pop-up menu in the menu list itself, GetMHandle can be used to retrieve the menu handle because it's under the control of the application.

Q I read that Photo CD discs can be read by the AppleCD SC Plus and the AppleCD 150. Does this mean a plain vanilla AppleCD SC can't read them? Is this a hardware limitation, or will there be a software fix?

A Apple erroneously reported that the original AppleCD SC could not read single-session Photo CD discs. This turns out not to be the case; all of Apple's CD-ROM drives can read single- session Photo CD discs.

Two levels of support are available for Kodak Photo CDs: the ability to read the first session on the Photo CD itself, and the ability to deal with more than just the initial session of a multisession CD. The AppleCD 300i is the first CD-ROM player from Apple to support multisession Photo CDs. For details about both support levels, check the Tech Info Library on AppleLink.

Q Inside Macintosh Volume V, page 103, says that when a PICT pattern opcode (for instance, 0x0012) comes along, and the pattern isn't a dither pattern, the full pixMap data follows the old-style 8-byte pattern. The pixMap data structure shown on page 104 starts with an unused long (baseAddr placeholder), followed by the rowBytes, bounds, and so on. However, looking at the Pict.r file on the October 1992 Developer CD, at the same opcode (BkPixPat == 0x0012), the first data field after the old-style pattern (hex string[8]) is the rowBytes field (broken down into three bitstrings). The baseAddr placeholder field isn't there. Which is correct?

A The Inside Macintosh Volume V documentation on pages 103-104 is wrong. The Pict.r file correctly describes the format of the PnPixPat and BkPixPat opcodes. So there shouldn't be a baseAddr field in the pixMap record of a pattern as stored in the PnPixPat of a PICT. However, the baseAddr does occur in a 'ppat' resource as described on page 79. Thanks for pointing out this discrepancy.

Q How do I find the correct time values to pass to GetMoviePict, to get all the sequential frames of a QuickTime movie?

A The best way to find the correct time to pass to get movie frames is to call the GetMovieNextInterestingTime routine repeatedly. Note that the first time you call GetMovieNextInterestingTime its flags parameter should have a value of nextTimeMediaSample + nextTimeEdgeOK to get the first frame. For subsequent calls the value of flags should be nextTimeMediaSample. Also, the whichMediaTypes parameter should include only tracks with visual information, 'vide' and 'text'. Check the Movie Toolbox chapter of the QuickTime documentation for details about the GetMovieNextInterestingTime call. For a code example, see the revised SimpleInMovie on this issue's CD. The routine to look at is called DoGetMoviePicts in the file SimpleInPicts.c.

Q My routine uses a dialog hook to set and retrieve certain values in new items added to the default box. Previously, with SFPPutFile, I was able to use a hit on the Save item to retrieve and save the values. This also works with CustomPutFile unless the Replace/Cancel dialog box appears, because the dialog hook routines are also called for it! With the dialog pointer now pointing at the small alert, any reference to expected items leads to disaster, since they don't exist. Isn't calling the dialog hook routine to respond to hits in the alert box wrong and therefore a bug?

A Both Standard File and the Edition Manager in System 7 allow you to have control in your filter when one of the subdialog boxes comes up. You can differentiate between the main dialog and the subdialogs by looking in the refCon field of the dialog record passed to you. In Standard File's case, if the dialog is the main dialog, the refCon will be:

/* From StandardFile.h */
/* The refCon field of the dialog record during a modalfilter 
or dialoghook contains one of the following: */
#define sfMainDialogRefCon      'stdf'
#define sfNewFolderDialogRefCon 'nfdr'
#define sfReplaceDialogRefCon   'rplc'
#define sfStatWarnDialogRefCon  'stat'
#define sfLockWarnDialogRefCon  'lock'
#define sfErrorDialogRefCon     'err '

This is described in detail on page 26-18 of Inside Macintosh Volume VI, in the middle of the section that describes all the callbacks and pseudo items for Standard File under System 7. The main purpose of this is to allow your additional dialog items to react properly when another dialog box is brought up in front of them, not to allow you access to the subdialogs. Also, since Standard File has no idea what types of items you've added to the dialogs, giving you control during subdialogs allows you to change the look of your subitems, or to keep them active if they need periodic time for any reason.

Q How do I find the current KCHR resource?

A Here's a method for getting a copy of the KCHR resource currently being used by the system. This method works for both System 6 and System 7.

{
    long        keyScript, KCHRID;
    Handle      KCHRHdl;
    /* First get the current keyboard script. */
    keyScript = GetEnvirons(smKeyScript);
    /* Now get the KCHR resource ID for that script. */
    KCHRID = GetScript((short)keyScript, smScriptKeys);
    /* Finally, get your own copy of this KCHR. Now you can pass 
       a proper KCHR pointer to KeyTrans. */
    KCHRHdl = GetResource('KCHR', KCHRID);
}

Q When I use CopyBits to move a cGrafPort's portPixMap to another cGrafPort (my printing port), it works like a charm when background printing is turned on, but when CopyBits gets called with background printing turned off, the image that prints isn't the image at all. Why is this happening?

A You should be aware that since you're copying the pixels directly from the screen, the baseAddr pointer for the screen's pixMap may be 32-bit addressed. In fact, with 32-Bit QuickDraw, this is the case. This in itself isn't a problem, since CopyBits knows enough to access the baseAddr of the port's pixMap in 32-bit mode, as follows:

mode = true32b;
SwapMMUMode(&mode);// Make sure we're in 32-bit addressing mode.
// Access pixels directly; make no other system calls.
SwapMMUMode(&mode);// Restore the current mode.

That's how you'd normally handle things if you were accessing the pixels directly yourself. Unfortunately, the LaserWriter driver doesn't know enough to do the SwapMMUMode and instead ends up copying garbage (from a 32-bit pointer stripped to a 24-bit pointer).

So why does background printing work? Because when you print in the background, everything is rolled into a PICT, which the driver saves off for PrintMonitor. Since the driver is using the standard QuickDraw picture bottlenecks to do this, and CopyBits knows to swap the MMU mode before copying the data into the picture, everything works great. Later, at PrintMonitor time, the picture is played back. Since the data is no longer 32-bit addressed, the LaserWriter driver doesn't have to call SwapMMUMode to do the right thing; it can just play the picture back. The solution we propose for you is something similar. At print time (before your PrOpenPage call), call OpenPicture, copy the data from the screen with CopyBits, call ClosePicture, and then call DrawPicture within your PrOpenPage/PrClosePage loop. That should do the trick.

Note that copying bits directly from the screen is not something we recommend. Unless you have no alternative, you should always copy from the original source of the data instead.

Q Is there a way to read Greenwich Mean Time offsets from the Map control panel?

A There's actually a system-level call to find out where you are. It's a Script Manager call named ReadLocation (used by the Map control panel), which returns a structure giving you all the information you need. Here's a description of the call, copied from MPW 411:

pascal void ReadLocation(MachineLocation *loc)
    = {0x205F,0x203C,0x000C,0x00E4,0xA051};
File {CIncludes}script.h

In C:

pascal void ReadLocation(MachineLocation *loc);
pascal void WriteLocation(const MachineLocation *loc);

These routines access the stored geographic location and time zone information for the Macintosh from parameter RAM. For example, the time zone information can be used to derive the absolute time (GMT) that a document or mail message was created. With this information, when the document is received across time zones, the creation date and time are correct. Otherwise, documents can appear to be created after they're read. (For example, someone could create a message in Tokyo on Tuesday and send it to San Francisco, where it's received and read on Monday.) Geographic information can also be used by applications that require it.

If the MachineLocation has never been set, it should be <0,0,0>. The top byte of the gmtDelta should be masked off and preserved when writing: it's reserved for future extension. The gmtDelta is in seconds east of GMT; for example, San Francisco is at minus 28,800 seconds (8 hours * 3600 seconds per hour). The latitude and longitude are in fractions of a great circle, giving them accuracy to within less than a foot, which should be sufficient for most purposes. For example, Fract values of 1.0 = 90º, -1.0 = -90º, and -2.0 = -180º. In C:

struct MachineLocation {
    Fract   latitude;
    Fract   longitude;
    union {
        char    dlsDelta;  /* signed byte; daylight savings delta */
        long    gmtDelta;  /* must mask - see documentation */
    } gmtFlags;
};

The gmtDelta is really a 3-byte value, so you must take care to get and set it properly, as in the following C code examples:

long GetGmtDelta(MachineLocation myLocation)
{
    long internalGMTDelta;
    internalGMTDelta = myLocation.gmtDelta & 0x00ffffff;
       // need to sign extend
        if ( (internalGMTDelta >> 23) & 1 )
            internalGmtDelta = internalGmtDelta | 0xff000000;
        return (internalGmtDelta);
}

void SetGmtDelta(MachineLocation *myLocation, long myGmtDelta)
{
    char tempSignedByte;
    tempSignedByte = myLocation->dlsDelta;
    myLocation->gmtDelta = myGmtDelta;
    myLocation->dlsDelta = tempSignedByte;
}

Q Did you hear that they had computer music at Clinton's inauguration?

A Yes, they danced to Al Gore Rhythms.

Q What (if at all) is the limitation on the number of files in a folder? In other words, is there a number N, such that if I have N files in a folder, and I try to Create file number N+1, I'll get some error?

A In general, the number of files that can be put in an HFS directory is unlimited; there isn't any point at which you'll receive an error from Create, because new file description records can almost always be created. The only way you can get a disk full error back from Create is if the catalog file needs to grow to add your new record and the disk is full, but this should be extremely rare; even when the disk is full, there's generally room to create dozens of files or folders before the catalog file will need to be enlarged, as it's grown in relatively large chunks.

There are, however, a couple of related limits on large numbers of files. Because HFS allocates space in "allocation blocks," and there can be at most 65,536 allocation blocks on a volume, there's a limit of 65,536 files that contain data on a volume. If your disk is full with 65,536 one- block files, you'll probably be able to create more files (Create will succeed), but no data will be able to be written to them. In reality, the limit on the number of files is somewhat smaller; the catalog and extents files will each occupy space. Also, because the allocation block size needs to be an even multiple of 512 bytes, most volumes won't have a full 65,536 allocation blocks; they'll have as many as they can, somewhere between 32,767 and 65,536 (except for small volumes, which may have less). In addition, each fork (either the data fork or the resource fork) of a file needs to be separately allocated, so each counts as a file for this calculation.

There's also a practical limit on how many files can be placed in a folder. HFS can maintain as many files as required in a directory; however, because the index field is a short, if there are more than 32,767 files in a folder, they can't be enumerated. Thus, while they can be identified and opened by name, there's no way to index through them to determine what's in the directory without deleting or moving some of the files.

These limit descriptions apply to HFS only; other file systems may be available on the Macintosh, such as MFS, MS-DOS, ISO 9660, or virtually any file system via an AppleTalk Filing Protocol (AFP) translator. These descriptions also don't include limitations of the Finder, the Standard File Package, or any other intermediaries. The Finder and Standard File are likely to become quite unusable long before you run into the limits of HFS. Also, while HFS will continue to function, it wasn't designed for optimum performance with extremely large numbers of files; for more dire warnings on this subject, see the Macintosh (Overview) Technical Note "Don't Abuse the Managers" (formerly #203).

Q In the two-byte script version of our application, we need to insert certain characters such as "-" and "%" into some of our strings. How can we do this, since these are obviously only one character long in C?

A All 7-bit ASCII characters (codes less than 127) are maintained as such in all two-byte scripts. If your routines just concatenate existing (localized) strings and characters, you don't have to worry about anything. Otherwise, you'll need to call CharByte ( Inside Macintosh Volume V, page 306, and Volume VI, pages 14-45, 14-114, and 14-124) while walking the bytes in the string.

In the Macintosh (Text) Technical Note "Fond of FONDs," the part about OutlineMetrics was updated recently to be "two-byte aware." The code fragment there should help you with strings containing text for two-byte scripts. See also the article "Writing Localizable Applicatio n s" in this issue.

Q The Icon Utilities routine GetIconCacheData leaves two bytes of garbage on the stack. This surfaced as a problem for me because it prevented a saved register from getting restored properly. SetIconCacheData probably has the same problem, since it calls the same trap internally. I solved the problem by encapsulating GetIconCacheData within my own static function, like so:

static OSErr _GetIconCacheData( Handle theCache, void **theData )
{
returnGetIconCacheData( theCache, theData );
}
#define GetIconCacheData_GetIconCacheData

I then call GetIconCacheData normally. The #define redirects my call to my static wrapper function. The extra two bytes on the stack are recovered when the wrapper function UNLKs and returns. This method has the advantage that the calling code will still work even after the trap is fixed. Am I correct?

A You're quite correct; this is a bug. Here's the offending code from the source:

EXIT    MOVEA.L (SP)+, A0   ; Pop return address into A0
        ADDQ.L  #6, SP      ; Point stack at return value
        MOVE.W  D0, (SP)    ; Put return value on the stack
        JMP (A0)            ; Return

As you can see, the exit routine is adding 6 to the stack to clear up the input parameters instead of 8 (handle and handle), so an extra word of garbage is being left on the stack. Thanks for letting us know about the problem.

Q When I double-click a document that launches my application, the current directory for the Standard File Package (at location $398 in memory) is set to the directory of my application and not my document. This seems to be a bug according to the text on page 3-31 of the new Inside Macintosh: Files manual. Is there anything special I have to do?

A You're right. The behavior described in Inside Macintosh: Files isn't entirely correct. It should say that the first time your application calls one of the Standard File Package routines, the default current directory (that is, the directory whose contents are listed in the dialog box) is determined by the way your application was launched.

• f the user launched your application directly (perhaps by double-clicking its icon in the Finder), the default directory is the directory in which your application is located.
• If the user launched your application indirectly (perhaps by double-clicking one of your application's document icons) and your application is passed Finder information, the default directory is the directory of the last document listed in the Finder information. The Finder information is the data referenced by AppParmHandle and accessed by the Segment Loader routines CountAppFiles, GetAppFiles, ClrAppFiles, and GetAppParms.

Note that applications that are high-level event aware are passed the list of documents to open or print in a kAEOpenDocument or kAEPrintDocument Apple event. There's no Finder information (AppParmHandle will be NIL) and the default directory is the directory in which your application is located.

Q Sometimes, at the beginning of a PBRead on a serial port, I get back a result code of -90 in the completion routine. I don't quite know how to handle this error, because I can't find a -90 result code anywhere. Any idea what -90 means?

A According to the MPW Errors.h interface file, -90 is a BreakRecd result. (The interface files are always a good place to look for error codes and calls that you can't find.) The serial driver returns that error to a pending Read if the SCC chip detects a break condition.

Q Why does MacApp use the Initialize and Free methods instead of the normal C++ constructor and destructor methods?

A MacApp doesn't use constructors for historical reasons. Object Pascal was used in MacApp 2.0.1, which doesn't have constructors and destructors as part of the language, and as a result these facilities had to be provided as part of MacApp instead of the language.

MacApp 3.0 designers tried to achieve backward compatibility with applications written with older versions of MacApp based on Object Pascal. Because of this, the designers decided to stay with the Initialize and Free functions rather than just have an instance of the object declared and destroyed with new and free.

Q Can I use the CompressPicture routine to spool in a source picture from disk by overriding the QuickDraw proc getPicProc as documented in Inside Macintosh Volume V, pages 88-89? I'm trying to save the contents of an off-screen GWorld as a compressed PICT resource. Unfortunately there's no direct way to compress the GWorld's pixel map to a resource.

A We definitely don't recommend trying to spool in or out the results of CompressPicture or CompressImage. We recommend doing one of the following instead:

• You can compress the GWorld using CompressImage and then call OpenPicture, DecompressImage, and ClosePicture using a data-unloading picture proc. The drawback here is that you need to have a copy of the compressed image in memory.
• If it's unacceptable to have an entire compressed image in memory, you can consider banding along with data unloading: Call OpenPicture, then CompressImage and DecompressImage on a band, CompressImage and DecompressImage on another band, and so on. When all bands are done, call ClosePicture. The drawback for this is that the compressed picture will have bands of image data that won't display well dithered. This could be an issue, but the best way to find out is to try it.

The second suggestion is probably the best idea if you want to keep your memory footprint small. But much of the decision depends on your application.

Q Our product's sound/video synchronization is way off with QuickTime 1.5; it worked perfectly with QuickTime 1.0. The video can't keep up with the sound, especially on the full-screen movies. The movies are playing much slower with 1.5. Isn't QuickTime 1.5 supposed to make movies play faster?

A Your movies probably aren't properly interleaved. When you add sound to a movie with SoundToMovie, the sound is added to the end of the video data. We recommend that sound and video be interleaved so that the hard drive doesn't have to spend extra time seeking between media that store video and media that store audio on a hard drive. The data handler prefers to be able to sequentially read through a movie file. This is especially important for slower Macintosh models that don't have the extra CPU and SCSI access speed to spare.

QuickTime can accommodate for some noninterleaved data by caching an entire sound track of a movie if small enough. However, the size of a cache is internal to QuickTime and can't be depended on. It's possible that different QuickTime versions could have different cache sizes since we've been recommending that video and sound movies be interleaved. The result could be that the extra disk-seeking time has caused sound and video to be out of sync for slower machines such as the Macintosh LC.

One way to check interleaving is to resave the movie using Movie Converter (or some other program that flattens movies) in a flattened format. Movie Converter uses QuickTime's FlattenMovie call to do this. The steps Movie Converter takes are: choose Save As, select "Make movie self-contained," and save to a new movie file. This new movie should play back with correct video and sound sync.

You can actually see the problem if you examine the movie with MovieShop, a program that lets you deal with QuickTime movies at a movie data level. For example, if you select the Play information button that's in the window after you open a movie, the program will display a time graph showing you where the video and sound data are saved in the continuous data stream. If the movie is interleaved, the green (for video) and red (for sound) indicators are interleaved. If the movie isn't interleaved, the green indicators are clumped together in the beginning of the file, and the red indicators (for sound) are at the end.

The latest version of MovieShop and documentation is available on this issue's CD. MovieShop and related information are discussed in the article "Making Better QuickTime Movies" in this issue.

Q How long can a Macintosh filename be on an international system? Our program currently assumes a maximum filename length of 31. What does the length byte of a Pascal string signify on an international system -- the actual length in bytes of the string, the logical length (the number of international characters), or neither?

A The Macintosh file systems -- the flat (MFS) and the hierarchical (HFS) -- have (reasonable) limitations on the length of filenames. The limits on the lengths refer to the number of bytes required for the strings. Usually, filenames are represented as Pascal strings. The first byte of a Pascal string indicates the number of bytes occupied by the string. In the worst case in a two- byte script, only 15 two-byte characters fit into a Str31. Compared to one-byte scripts, this isn't so bad, however: two-byte characters tend to carry much more meaning than two of our familiar one-byte characters!

Q What is QuickTime for Windows and what hardware do you need to run it?

A QuickTime for Windows makes QuickTime a cross-platform technology that you can use in both the Macintosh and the Microsoft Windows programs that you're developing. With it, you can create multimedia programs on the Macintosh and be able to add the playback of QuickTime movies to any PC application running Microsoft Windows 3.1.

The minimum hardware configuration required for QuickTime for Windows is the following:

• A personal computer with an 80386SX or greater CPU
• A CPU speed of 20 MHz or higher
• 4 MB of conventional and extended memory
• A hard disk with at least 4 MB free for the basic QuickTime for Windows software
• A graphics adapter and mouse (or other pointing device) supported by Microsoft Windows

Optional hardware:

• A CD-ROM drive supported by Microsoft Windows (if installing from a CD)
• A sound card supported by Microsoft Windows
• Additional free disk space if you want to keep movies and pictures on your hard disk

The software requirement for running QuickTime for Windows is Microsoft Windows 3.1. To write QuickTime for Windows programs, you must have (in addition to the QuickTime for Windows Developer's Kit) a development package such as Borland C++ 3.1 or Microsoft C/C++ 7.0. The sample QuickTime for Windows executables may be played under Windows 3.1 immediately following QuickTime for Windows installation and configuration, without C or C++ being present.

Q I tried to unmount a volume shared with Macintosh File Sharing from my program as follows: I shut down the file service with the SCShutDown server control call; I call SCPollServer to make sure the file service is really off (scServerState = SCPSJustDisabled); then I call PBUnmountVol to attempt to unmount the volume. It didn't work because PBUnmountVol fails with fBsyErr (-47). I broke on the _UnmountVol trap because the AppleShare PDS file, where the file server keeps the access privilege and share-point information for the shared volume, was open. Why is AppleShare PDS still open when I've turned the file service off? How can I close it and unmount the volume?

A SCPollServer returns the state of the file service, not the file server application (in this case, File Sharing Extension is the file server application). When SCPollServer returns a server state of SCPSJustDisabled, the file service is off; however, the file server application may or may not still be running. The AppleShare PDS file will eventually get closed before the file server application quits.

There's an easy way to determine when the File Sharing Extension application has quit (and thus when the AppleShare PDS file is closed): just use the Process Manager GetNextProcess and GetProcessInformation calls to find out when File Sharing Extension is no longer running. The File Sharing Extension application has a processType of 'INIT' and a processSignature of 'hhgg'. Here's a function you can use to see if File Sharing Extension is running:

FUNCTION FileSharingAppIsRunning: Boolean;
    CONST
        FileSharingSignature = 'hhgg';  {Macintosh File Sharing}
    VAR
        err:            OSErr;
        myPSN:          ProcessSerialNumber;
        myPInfoRec:     ProcessInfoRec;
    
    BEGIN
    myPSN.highLongOfPSN := 0;   {Start at beginning of process list}
    myPSN.lowLongOfPSN := kNoProcess;
    myPInfoRec.processInfoLength := sizeOf(ProcessInfoRec);
    myPInfoRec.processName := NIL;      {Don't need process name}
    myPInfoRec.processAppSpec := NIL;   {Don't need process location}
    FileSharingAppIsRunning := FALSE;   {Haven't found it yet}
    WHILE (GetNextProcess(myPSN) = noErr) DO
        IF GetProcessInformation(myPSN, myPInfoRec) = noErr THEN
            IF (myPInfoRec.processSignature =
                     FileSharingSignature) THEN
                FileSharingAppIsRunning := TRUE;    {Found it}
END;

After shutting down the file service, your event loop will need to poll with FileSharingAppIsRunning because you must give the file server application processing time to close files, dispose of memory, and perform other shutdown operations. If you poll with FileSharingAppIsRunning without giving other processes time, File Sharing Extension will never shut down.

Q I'm having trouble understanding the problems of dealing with potentially infinite loops in interconnected, distributed applications. Can you help me?

A Please see the next message. Q I'm having trouble understanding the problems of dealing with potentially infinite loops in interconnected, distributed applications. Can you help me?

A Please see the previous message.

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 in Apple's Developer Support Center; our thanks to all. Special thanks to Pete ("Luke") Alexander, Mark Baumwell, Brian Bechtel, Cameron Birse, Joel Cannon, Matt Deatherage, Tim Dierks, Steve Falkenburg, Nitin Ganatra, Bill Guschwan, C. K. Haun, Dave Hersey, Scott Kuechle, Edgar Lee, Jim Luther, Joseph Maurer, Kevin Mellander, Martin Minow, Ed Navarrete, Guillermo Ortiz, Dave Radcliffe, 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 Macintosh Q&A Technical Notes on this issue's CD and in the Dev Tech Answers library on AppleLink.*