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:
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:
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":
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.*