MACINTOSH Q & A

MACINTOSH DEVELOPER TECHNICAL SUPPORT

Q Our program has a problem with filenames that start with a period. During an Open call, if the filename starts with a period, the Open code calls the Device Manager (for drivers and DAs) instead of the File Manager. However, we've seen other applications that can successfully open these files. What's the secret? How do we open files that otherwise look (from the name) like drivers?

A The Open trap is shared between the Device Manager and the File Manager. When Open is called, it checks first to see whether you're trying to open a driver. Driver names always start with a period. If you can, avoid using filenames that begin with a period. Macintosh Technical Note "HFS Elucidations" (formerly #102) discusses this conflict. The secret to opening those files is using the new Open Data Fork functions available with System 7 -- FSpOpenDF, HOpenDF, and PBHOpenDF. These functions bypass the driver name check and go right to the File Manager. Here's the code we use to open a file:

err := HOpenDF(vRefNum, dirID, fileName, permission, refNum);
IF (err = paramErr) THEN        {HOpenDF call isn't available}
    err := HOpen(vRefNum, dirID, fileName, permission, refNum);
                                {try again with old HOpen call}

Try this and your problem should go away under System 7. The code retries with the regular Open call (which uses the same input parameters), so this code can be used in programs that run under both System 6 and System 7.

Q In System 7, the memory allocated for INITs by the 'sysz' resource mechanism seems to be limited to about 16 MB on our 32 MB Macintosh IIfx. For 'sysz' values up to 15 MB it works great, but it seems the system heap can't grow beyond 16 MB. Is there some reason for this?

A The system heap size at startup is limited to approximately half the size of total RAM. This is because the early startup code places the stack and some globals in the middle of RAM so that the system heap can grow up from below while BufPtr is lowered from above. This is basically the situation until an application is launched. Things are eventually rearranged so that the system heap will have more room to grow, but this doesn't happen until the Process Manager is launched, after INIT time. This limitation would mean that you could size your heap until it reached nearly (but not quite) half the size of RAM. We suggest that you attempt to allocate some of your RAM later, after the Process Manager starts up; at that point, the system heap should be somewhat less limited.

Q The Macintosh Technical Note "Setting ioNamePtr in File Manager Calls" (formerly #179) says that ioNamePtr needs to point either to nil or to storage for a Str255. This contradicts the Technical Note "Searching Volumes -- Solutions and Problems" (formerly #68), which gives an example of a recursive indexed search using PBGetCatInfo. The example uses a Str63. Which Technical Note is correct?

A To be generically correct, ioNamePtr should point to a Str255. However, in the case of PBGetCatInfo and other calls that return a filename (or a directory name), a Str63 is sufficient. The reasons are tied to the history of the Macintosh file system.

MFS, the original Macintosh file system, supported filename lengths of up to 255 characters. However, the Finder on those systems supported filename lengths up to only 63 characters and, in fact, developers were warned to limit filename lengths to fewer than 64 characters (see page II-81 of Inside Macintosh Volume II).

HFS, the hierarchical file system (in every Macintosh ROM since the Macintosh Plus), further limited filename lengths to 31 characters. If you mount an MFS disk while running HFS, the old MFS code is called to handle the operation. So, the file system can still create and use files with long filenames on MFS volumes. When the System 7 file system was being designed, Engineering had to decide what size string to use in FSSpec records. The decision was to use a Str63 instead of a Str31 to be able to support long MFS filenames, and to use a Str63 instead of a Str255 because there were probably very few filenames with over 63 characters (remember, the old Finder limited filenames to 63 characters). Using a Str63 instead of a Str255 saves 192 bytes per FSSpec record.

So, we recommend that you use at least a Str63 for filenames, as in "Searching Volumes -- Solutions and Problems." If you need to manipulate the filename in any way after you've gotten the name -- for example, to concatenate it with another string -- you might want to use a Str255.

Note: Even though the System 7 file system supports filenames longer than 31 characters on MFS volumes, the System 7 Finder does not. In fact, the System 7 Finder currently crashes if you try to open an MFS volume (that is, open the volume window) that has files with names longer than 31 characters.

Q I'm trying to use the Macintosh Time Manager to calculate elapsed times, but when I increase the delay time from $4FFFFFF to $5FFFFFF I get incorrect results. Why is this happening?

A There seems to be an undocumented limitation of the Time Manager: it can't keep track of times longer than about a day, so it replaces them with the maximum time it supports. For Time Manager tasks, this isn't crippling; the task simply executes earlier than expected. When used for elapsed-time calculations, however, it's a bad thing; the Time Manager installs the task with the smaller time, and when you remove it, you see a smaller than expected remaining time. This makes it appear as if a large period of time has passed.

The value at which the Time Manager trims is approximately $53A8FE5. The reason for this strange value is somewhat complex. The Time Manager uses a VIA timer to do its measurement. This timer runs at 783360 Hz, giving it a resolution of about 1.276 microseconds. However, the Macintosh could never actually provide this kind of accuracy, given its latencies and overhead. Also, this frequency would have given a 32-bit counter a range of only about 91 minutes. Therefore, the Time Manager actually throws away the low four bits of this counter, keeping a 32-bit counter with a resolution of 20.425 microseconds and a range of 24 hours, 22 minutes. This time is a lot larger than the maximum number of microseconds that can be measured, but is equal to 87,724,005 milliseconds, which is (ta-dahh!) $53A8FE5. This is why you were overflowing the Time Manager's internal counter, causing your task to be clipped.

All should work well if you use times less than 24 hours. If you need to measure durations for times exceeding the Time Manager's limits, you can use a fixed-frequency task that executes every hour and increments an hour counter. To determine the fractional hours component of the time, you'd remove the task to determine how much longer till the next hour.

Q When a picture that contains a pixMap is spooled into a window, how and when is the depth of the pixMap in the picture converted to the depth of the screens the window is on?

A When a picture is spooled in, if QuickDraw encounters any bitmap opcode, it allocates a pixMap of the same depth as the data associated with the bitmap opcode, expands the data into the temporary pixMap, and then calls StdBits. StdBits is what triggers the depth and color conversions as demanded by the color environment (depth, color table, B&W settings) of the devices the target port may span (as when a window crosses two or more screens).

If there's not enough memory in the application heap or in the temporary memory pool, QuickDraw bands the image down to one scan line and calls StdBits for each of these bands. Note that if you're providing your own bitsProc, QuickDraw will call it instead of StdBits. This process is the same when the picture is in memory, with the obvious exception that all the picture data is present; the color mapping occurs when StdBits does its stuff.

Q How do I get the pixel depth of the QuickTime video media for a given track?

A To find the video media pixel depth, you'll need to retrieve the media's image description handle. You can use GetMediaSampleDescription to get it, but this routine needs both the video media and the track's index number. It's not obvious, but a media's type is identified by its media handler's type. Thus, you can walk through a movie's tracks by using its indexes until you find video media, at which point you have both the track index and video media.

The following sample code does the trick:

#include <QuickDraw.h>
#include <Movies.h>
#include <ImageCompression.h>

Media GetFirstVideoMedia(Movie coolMovie, long *trackIndex)
{
    Track   coolTrack = nil;
    Media   coolMedia = nil;
    long    numTracks;
    OSType  mediaType;
    numTracks = GetMovieTrackCount(coolMovie);
    for (*trackIndex=1; *trackIndex<=numTracks; (*trackIndex)++) {
        coolTrack = GetMovieIndTrack(coolMovie, *trackIndex);
        if (coolTrack) coolMedia = GetTrackMedia(coolTrack);
        if (coolMedia) GetMediaHandlerDescription(coolMedia,
                &mediaType, nil, nil);
        if (mediaType = VideoMediaType) return coolMedia;
    }
    *trackIndex = 0;    // trackIndex can't be 0
    return nil;         // went through all tracks and no video
}

short GetFirstVideoTrackPixelDepth(Movie coolMovie)
{ 
    SampleDescriptionHandle imageDescH = 
            (SampleDescriptionHandle)NewHandle(sizeof(Handle));
    long trackIndex = 0;
    Media coolMedia = nil;
    coolMedia = GetFirstVideoMedia(coolMovie, &trackIndex);
    if (!trackIndex || !coolMedia) return -1; // we need both
    GetMediaSampleDescription(coolMedia, trackIndex, imageDescH);
    return (*(ImageDescriptionHandle)imageDescH)->depth;
}

Q What's the difference between ignorance and apathy?

A We don't know and we don't care.

Q Could you tell me what the "printer driver is MultiFinder compatible" bit is used for?

A The "printer driver is MultiFinder compatible" bit provides two features. First, it allows the printer driver resource file to be opened by multiple clients. This was obviously needed to support multiple applications printing simultaneously under MultiFinder. The other feature provided by the flag is the loading of PDEFs into the system heap rather than the application heap (which is where they go under the Finder). The MultiFinder-compatible bit has a major limitation: if your driver has this flag set, you aren't allowed to add or resize resources, or do anything else that would cause the RAM- resident resource map to change. Although MultiFinder lets multiple applications open the printer resource file at the same time, it has no control over the resource map that gets loaded by the Resource Manager when the file is opened. Because of this, each client gets its own personal copy of the resource map. When these clients get done with the file, they write the resource map back to the file (via UpdateResFile). Obviously, if the resources have changed in any way, the last client to call UpdateResFile is the only one whose changes will be recorded. This is a "thrill seeker" method of handling the printer driver resource files, but since none of the Apple printer drivers currently add or resize resources, it made sense.

So the bottom line here is that if you want your drivers to be compatible under MultiFinder, you'll have to implement a scheme that doesn't require adding or resizing resources. It's OK to change the data in a resource, as long as you don't change its size. Changing the data won't cause changes to the resource map, so each client will still have accurate copies of the map.

Here's what would happen to your printer driver's resources under the Finder and MultiFinder when the MultiFinder-compatible bit is set:

• Under the Finder in system software version 6.0.x: All resources are loaded into the application heap -- regardless of the resource attribute's bit setting. If the resource has the "load into the system heap" bit set, it will still be loaded into the application heap under the Finder. This makes sense in the Finder world because the application heap will usually have more room than the system heap.
• Under MultiFinder in System 6 or System 7: All the printer driver's resources will be loaded into the system heap. This is true whether the "load into the system heap" bit is set or not.

Why does the resource loading occur this way, even when the resource's "load into the system heap" bit is set? Patches to the GetResource trap load all your printer driver's resources into the system heap when the MultiFinder-compatible bit is set under MultiFinder, and into the application heap under the Finder (as described above), which is why you can't override this behavior.

By the way, you should be aware of the SetPDiMC MPW tool, which is available on the Developer CD Series disc. It will automatically set the MultiFinder-compatible bit for you when you build your printer driver.

Q If I call FSWrite and attempt to write more than space allows, what happens? Of course I get a Disk Full error, but does FSWrite write as much as possible before quitting, and then return the number of bytes written in the count parameter?

A In the current implementation of the file system, writes to local volumes owned by the file system are an all-or-nothing deal. If the space for a write can't be allocated, the write call fails and no bytes are written.

However, do not depend on that, because the Macintosh file system doesn't control all volumes that might be mounted. Today, Apple ships four external file systems: CD-ROM, AppleShare, ProDOS File System (for Apple II ProDOS volumes), and PC Exchange (for MS-DOS volumes). Various third parties have written other external file systems. The way they react to error conditions may not be the same as local volumes controlled entirely by the file system.

To make your application always work correctly, you should check for errors and handle them appropriately. If you get a dskFulErr, you should assume that if any information was written to the file, it wasn't written correctly. You should either reset the file's EOF to its previous position (if you're appending to an existing file) or delete the file (if you had just created the file and were writing to it for the first time).

Q How can I mount a volume without using aliases? I get the mounting information, then attempt to mount the volume. However, the PBVolumeMount call returns an error code.

A The PBGetVolMountInfo, PBGetVolMountInfoSize, and PBVolumeMount functions are currently handled by only the AppleShare external file system (part of the AppleShare Chooser extension). Those functions are available on AppleShare volumes when the AppleShare Chooser extension is version 7.0 (system software versions 7.0 and 7.0.1), version 3.0 (AppleShare 3.0), or version 7.1 (System 7.1). The AppleShare Chooser extension version 3.0 can be installed on System 6 systems, and then the PBGetVolMountInfo, PBGetVolMountInfoSize, and PBVolumeMount functions can be used in System 6. Other file systems may support these functions in the future. The paramErr error code is returned when these functions aren't available on a particular volume.

Q I need to prevent users from copying my application off a volume. Is there a new equivalent of the old Bozo bit?

A The Bozo or NoCopy bit was bit 11 in the fdFlags word of the FInfo record. As noted in the Macintosh Technical Note "Finder Flags" (formerly #40), this bit hasn't been used for that purpose since System 5. In fact, System 7 reused bit 11 for the isStationery bit. (See Inside Macintosh Volume VI, pages 9-36 and 9-37, for the current list of Finder flag bits.)

There isn't an equivalent of the Bozo bit. However, the System 7 Finder won't copy files that have the copy-protect bit (bit 6) set in the ioFlAttrib field returned by the PBGetCatInfo function. However, the bits in the ioFlAttrib field can't be changed with the PBSetCatInfo function. Instead, they're used to report the state of things set by other parts of the file system.

The copy-protect bit is set by the AppleShare external file system when it finds that a file's copy-protect bit is returned by an AppleTalk Filing Protocol file server. The AppleShare external file system is the only file system we know of that sets the copy-protect bit. There's no way to make the local file system set the copy-protect bit for volumes it controls.

Q Are there any tricks that might speed up reading and writing large files to disk? We're using standard C calls (fread and fwrite) for this purpose since our file I/O calls need to be platform-independent. Are there any low-level File Manager calls that might speed up the file I/O?

A The C fread and fwrite functions are slower than File Manager calls because the standard C library adds another layer of overhead to file I/O. In addition, unless you turn buffering off, all file I/O is double-buffered when you use the standard C library functions. That is, fread reads from a RAM buffer in which the lower-level C library code has buffered data read from a disk file; fwrite writes data into a RAM buffer and the lower-level C library code writes from that buffer into a disk file.

For the highest file I/O throughput, and for maximum flexibility and functionality on the Macintosh, you should use the File Manager for all file access. The low-level File Manager calls (the PBxxx or PBHxxx calls) have the least overhead and give you the most control. If you use the File Manager's Read (FSRead or PBRead) and Write (FSWrite or PBWrite) calls, you'll achieve maximum throughput by reading or writing your data in the largest size possible (for example, if you need to write 10,000 bytes, you can write them with one Write call).

If you must use the standard C library, you may want to adjust the size of the file I/O buffer used by the library for your particular purposes. You can adjust the size of the file I/O buffer using MPW C's setvbuf function. If you do nothing, you'll get a default buffer with a size of 1024 (1K).

MPW C's setvbuf size parameter is treated internally as an unsigned short. This means that the largest value acceptable to setvbuf for its size parameter is 65535. Larger values will be treated modulo this number. If you set the buffer size to 0, I/O is unbuffered. You can turn off buffering like this:

setbuf(stream, NULL); // turn off buffering

or like this:

setvbuf(stream, NULL, _IONBF, 0); // turn off buffering

Here are some general rules to follow to determine the size of the file I/O buffer you should use:

• If the file is small (less than 10K), you should probably use the default buffer.
• If the file is large (greater than 10K) but you write to it from your program in small pieces, buffering may help cut down the number of disk accesses. You may want to change the buffer size to around 10K. You can experiment to see whether other values provide better results for you. You'll probably find some point where the overhead of double-buffering is more than the overhead of disk accesses -- that's when you should turn buffering off.
• If the file is large (greater than 10K) and you write to it in large pieces or write to it with one Write call, you should turn buffering off.

Q If you were omnipotent and you had a round knob that controls the value of ¹, what would happen to the knob as you turned it?

A Although unsure, we believe that the number of fingers on your hand would change.

Q I'm porting C code from a UNIX® platform to the Macintosh. The code uses stdlib and stdio calls such as calloc, realloc, malloc, free, memcmp, memcpy, memset, strtod, strcat, strchr, strcpy, strlen, strncat, strncpy, strrchr, fopen, fclose, fwrite, and fread. For the most part, I've always avoided these calls on the Macintosh since the Toolbox has equivalents. However, I'd like to know whether there are any ramifications if I use these calls for porting compatibility. The only issues I can identify are (1) StdCLib.o, which defines these calls, uses globals and therefore will prevent me from using the code in standalone code segments, and (2) I'll lose some file information such as type and creator. Are there any other issues that I should be aware of?

A There are various difficulties or "gotchas" associated with use of these calls on the Macintosh, which generally keep them from being used in commercial development. However, being able to cross-compile code is very useful, so people like to use the calls for portability reasons despite their drawbacks.

The memory allocation calls (such as malloc, calloc, and realloc) all allocate pointer-based blocks. This works but can cause memory fragmentation and inefficient usage compared to the handle-based system usually used on the Macintosh. Also, MPW's implementation of these calls doesn't return memory to the Macintosh pool; when you allocate a block with malloc, the routine gets a larger block from the Macintosh with NewPtr, which it then subdivides into several smaller blocks to satisfy allocation requests. However, if the program then frees all the allocations made from this Macintosh pointer block, the library routine won't notice and dispose of it. Although the memory remains available for reuse by the standard C allocation routines, it has been lost to the Macintosh. For details, see the Q&A about using calloc and NewPtr in the same program in develop Issue 12 and the Macintosh Technical Note "A/UX Q&As."

The file manipulation calls suffer somewhat merely because they don't fit well into the Macintosh file system. For example, if you want to select files with the Macintosh StandardGet dialog, you'll find that fopen doesn't accept the volume reference or directory ID returned; it accepts a pathname, making it difficult to specify files in various folders. Also, as you noted, you have no control over types or creators; you also can't easily associate resource forks with data forks or use a number of the more expressive Macintosh file system calls.

You can use all of the string-manipulation calls (such as strcpy and strlen) and simple memory- access calls (such as memcpy and memcmp) with impunity; fortunately, bytes is bytes. Note, however, that a large number of seemingly innocuous calls (such as atoi and many others) use globals, making them inappropriate for use in cases where globals wouldn't be available, such as in code resources.

Basically, the standard C calls do work but suffer from faults, primarily because they've been kind of wedged into a system in which they don't fit. While most are functional and compatible enough to be used in software safely, be aware of their drawbacks and limitations; the basic decision is whether you can provide the functionality you need with these calls and whether the extra work required to deal with them is more or less than the effort saved by avoiding wholesale modifications to the source being ported.

Q How can I detect whether a font suitcase is corrupted when it's opened and whether any of the fonts in it are corrupted before any of the fonts are used? I know that the Finder is able to do this, and I was wondering whether Apple gives out this information. My program will run only under System 7, if that helps.

A The Finder and font architecture on the Macintosh are living things; the definition of what is and isn't a damaged suitcase can change from release to release of system software. However, any of the following conditions makes System 7 report the suitcase as "damaged":

• More than eight FONDs reference the same font.
• The Finder can't create a new standalone icon object for each font in the suitcase. The usual cause of this is that two FONDs have the same name for the first 31 characters, and the Finder thinks there's already an icon in that window with the same name. (Two icons in the same directory with the same name is a sign of damage.)
• There isn't at least one font association table entry, or the table goes past the logical end of the resource.
• The first resource name in the map is zero-length. (This is a test for some older third-party corrupted suitcases.)
• The FOND has no name.
• The FOND doesn't have a valid character range; ffFirstChar has to be less than ffLastChar, unless it's a "dummy" FOND (created on the fly for old standalone FONTs, in which case ffLastChar is 0).
• All the font association table entries aren't in ascending point size order.
• Two font association table entries reference exactly the same point size and style.
• The offsets to the width table, kerning table, and style mapping table are invalid and nonzero.
• The font ID is 0 and it's not the system font.

We can't promise that this list is complete, but it does contain most conditions for which the Finder would report a suitcase as damaged.

Q We'd like to maintain only one version of our globally distributed application, which would adapt to the language in use by changing DITL resource text items and menu titles and items. Does the Macintosh Operating System support this?

A Currently the Macintosh Operating System doesn't inherently support localized resources for several languages, or choose the right language according to the localized version of the system. However, your approach of including all localized text items in the same application is absolutely feasible. Just include an option to let the user select the language -- somewhere in Preferences, if not in a dedicated "Languages" menu -- and design a numbering scheme for the resource IDs such that the resources to be loaded can be determined from the language code.

It's better to let the user choose the language, rather than derive it from the system. This provides for a choice in case the user lives in a multilingual region, or in case your application doesn't include translations for the language of the user's system.

Because menus, windows, and dialogs are displayed with the system font, this approach works only for languages supported by the system script.

Q My installer creates a folder on a user's hard disk and copies the necessary files into it. My final action atom moves the folder onto the desktop and sets its size and location. I'd also like to be able to open the folder. I call PBGetCatInfoSync to get the data into a CInfoPBRec record. Where is the state of a folder (open/closed) stored, and can I set one of the parameters in the CInfoPBRec and then call PBSetCatInfoSync to solidify the change? Using the installer to copy an open folder to the user's drive is unacceptable because of the size and nature of the program I'm installing.

A There's no solution for System 6; the Finder data structures are private, and there's no call to open a folder. In System 7, you can send the Finder an Open Selection Apple event. This is described in a HyperCard stack called FinderEvents on the Developer CD Series disc. The stack also contains the source code for the XCMD used to demonstrate the Finder events. There's another sample that you should see as well: SendFinderOpen in the Snippets folder.

Q We're having problems with color patterns using the LaserWriter driver version 7.1.2. If we create a 'ppat' resource in ResEdit (32 x 32 bits, in this case) and then do a FillCRect to the port returned by PrOpenDoc (with color set so that it's a cGrafPort) with the pattern loaded by GetPixPat, we get a weird pattern. Doing the same to an off-screen GWorld and using CopyBits to copy to the printer port works fine, if a little slowly. Are we missing something here?

A You need to use the FillCRect call off-screen rather than directly into the printer port, for at least two reasons. First, the LaserWriter driver doesn't support filling objects with anything but black-and-white patterns because it uses the PostScript halftone screen functions to draw patterns. Second, the LaserWriter driver doesn't understand (or handle) pixPats. Therefore, your only recourse is the one you discovered -- to copy to and from GWorlds. Unfortunately, FillCRect doesn't work with the LaserWriter drivers through version 7.2. After version 7.2 this probably won't be a problem.

Q Do NumToString and StringToNum work correctly regardless of the script chosen as the system script? When I attempt to use SANE to convert non-Roman digits from a dialog box editText item, SANE doesn't seem to like it.

A SANE expects all digits to be in the range ASCII $30-$39, with $2D as a negative indicator. These ASCII values can be generated from any international script by using the Macintosh numeric keypad. The symbols 0 through 9 are internationally recognized as numeric values.

There are many additional ways to represent numbers on the Macintosh, including words (one, two, uno, dos), notations (dozen, hundred, million), ordinals (first, second, third), Roman numerals (I, II, III), symbols (¹, e, i), and hexadecimal ($FF). Many languages have alternative numbering systems and special characters that represent numbers. In Symbol and double-byte fonts, there are special characters representing fractions (1/2, 1/4), superscripts, subscripts, numbers within circles, and so on.

While it would be nice to have routines that convert between ASCII numbers and alternatives such as longhand numbers (used when writing checks), Roman numerals (used for copyright year in movie credits), or local number systems (for formal documents), no such routines exist in the Macintosh Toolbox today. It would be possible but difficult for an application to custom- process numbers for each language and script. The Unicode Standard Reference, Volume 1, lists hundreds of different kinds of numbers -- and they're not all base 10.

Scripts that have alternative number character sets always support the universal single-byte ASCII digits as well. When a script has alternative numeric characters, the user generally types script-dependent numeric characters from the top row of the keyboard and the single-byte ASCII digits from the numeric keypad.

Although it doesn't translate the digits themselves, the Script Manager offers support for formatting a number into a local form. For example, Europeans often use a comma as a decimal point and a period as a thousands marker. Most countries have unique currency symbols. There are many different ways to represent numerical values for things such as date, time, and money. This kind of formatting information is in the international resources.

One way to do data validation is to use CharType and check for numeric characters. We can't guarantee that this has been implemented for all scripts, but it is correct for Roman and Japanese.

NumToString and StringToNum don't deal with international formats. Use the Script Manager routines Str2Format and Format2Str to get the text into a numerical form that SANE can deal with. See Inside Macintosh Volume VI, page 14-49, for details.

Q I'm attempting to determine whether a debugger is installed, and if so, to find a THz pointer to its heap zone. Is this possible?

A The MacsBug debugger is loaded into high memory above the value found in the global variable BufPtr ($10C). Since it's loaded into the memory that's not managed by the Memory Manager, it's not in a heap. The global variable MacJmp ($120) points to the debugger's entry point.

There's also a flags byte in low memory that contains the following information:

Bit 7       Set if debugger is running.
Bit 6       Set if debugger can handle system errors.
Bit 5       Set if debugger is installed.
Bit 4       Set if debugger can support the Discipline utility.

The flags byte may be in one of two places: the high-order byte of the long word at MacJmp, or the address $BFF. When MacsBug is loaded, it examines the value at address $BFF. If the value at $BFF is $FF, the system is using the 24-bit Memory Manager and the flags byte will be the high-order byte of the long word at MacJmp. If the value at $BFF isn't $FF, the system is using the 32-bit Memory Manager and the flags byte will be at address $BFF.

For information on debuggers other than MacsBug, you'll need to contact the publishers of those products.

Q We need to localize our application for several international markets. Do you have any special tools or recommendations for us?

A You can use a System 7.1 tool called AppleGlot (on the Developer CD Series disc) to localize text in your application. Once a file has been localized the first time, the tool can compare versions and copy over everything that has stayed the same (usually 99%) so that it can focus on the text that's different. It also creates a nice audit trail and is pretty easy to use. It should save you a lot of time. To take full advantage of this tool, you need common code for all localized versions, which is what you're planning to do to avoid the mess of having multiple sources. Occasionally, your application might have features that make sense only on a particular script system; in that case, you can check for that configuration and enable those routines when appropriate. Once you have common source and tools that help localize your application, you can add auxiliary resources for various languages.

If you have only a small amount of text in your application, it makes sense to bundle everything together in one worldwide product. Apple's TrueType fonts, for example, have internal name tables with names and information such as copyright strings in about a dozen languages. Each string is tagged with a platform, script, and language. But if you have a fair amount of textual resources, it might make more sense to have optional files and resources that can be installed as needed.

Unless you intend to support every script and language, you'll probably want to have a set of resources for unavailable languages. You can pick whatever language you want for this other set (English is popular), but the trick is to use only 7-bit ASCII characters. All script systems use the same character codes for the range $00-$7F, which match ASCII. It's the 8-bit characters that differ radically. This means that text that includes characters like ..., ^TM, ©, and * will not display properly on non-Roman script systems. Just substitute text such as . . ., tm, (c), and * for them. You can decide what's appropriate and necessary.

Another thing to consider is checking for and supporting secondary script systems in your application. The Macintosh Toolbox doesn't fully support secondary scripts such as Japanese menus on an English system, but your application can support secondary script data even with the current Toolbox limitations, by using styled text commands.

Q We would like to use the "dogcow" icon in our Page Setup dialog. Is the dogcow trademarked, and are there any restrictions on using this icon in our software?

A Yes, the dogcow logo (along with its call, "Moof!") is a trademark of Apple and is proprietary. The dogcow appears on Apple's Developer CD Series disc and in other material. Apple has a pending U.S. registration on it. Accordingly, it's not available to third-party developers as an icon or file symbol.

Q Where in the world does the dogcow come from?

A Some people say that the dogcow hails from the sunny shores of the Middle of Nowhere. This location in the south Atlantic can be found in the Map control panel; simply type "Middle of Nowhere" and click Find. (For a small fee, these same people will tell you where they last saw Elvis.)

Kudos to our readers who care enough to ask us terrific and well thought-out questions. The answers are supplied by our technical gurus in Apple's Developer Support Center; our thanks to all. Special thanks to Pete ("Luke") Alexander, Mark Baumwell, Joel Cannon, Matt Deatherage, Tim Dierks, Marcie ("M. G.") Griffin, Bill Guschwan, C. K. Haun, Dave Hersey, Dennis Hescox, Rich Kubota, Jim Luther, Joseph Maurer, Guillermo Ortiz, Kent Sandvik, Brigham Stevens, and Dan Strnad 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.*