Q The TrapAvailable function listed in the "Compatibility Guidelines" chapter of Inside
Macintosh Volume VI contains code that checks the size of the trap table. Do I have to do
this if my application doesn't support the old 64K ROMs?
A Yes, you do. With the introduction of the Macintosh Plus and 128K ROMs, the trap
table was divided into the OS trap table and Toolbox trap table. The number of trap
table entries was increased and the format of those entries was expanded. For
additional information on this expansion see the "Using Assembly Language" chapter of
Inside Macintosh Volume IV. However, the 64K to 128K ROM trap table expansion is
not what the code in the TrapAvailable function is checking for. The Toolbox trap table
was expanded yet again when the Macintosh II was introduced. The Macintosh Plus and
SE use the smaller Toolbox trap table on pre-7.0 systems. To be sure your application
is compatible with these machines on pre- 7.0 systems, check the size of the Toolbox
trap table.
Q What are the guidelines for determining how much of an image CopyBits can copy to a
Macintosh pixel map at one time, given a particular set of characteristics for the
source map and the destination map and given how much stack space is available? For
example, say that we have an 8-bit-deep pixMap to be copied to a 32-bit-deep pixMap
using the ditherCopy mode and expanded by a factor of 4, and we have 45K of stack
space.
A CopyBits' stack requirement depends on the width of each scan line (rowBytes). The
rule of thumb is that you need at least as much stack as the rowBytes value in your
image (which can be huge with 32-Bit QuickDraw), with the following additional
modifiers: add an additional rowBytes for dithering; add an additional rowBytes for any
stretching (source rect != dest rect); add an additional rowBytes for any color map
changing; add an additional rowBytes for any color aliasing. The stack space you need is
roughly five times the rowBytes of your image. In general, you're better off
processing narrower scan lines. Reducing the vertical size will not affect stack
requirements. Narrow, tall bands (if you can use them) will reduce the stack
requirements.
Q Where can I find documentation on how to write a Macintosh printer driver
equivalent to the ImageWriter® or LaserWriter driver? In particular, how are
Printing Manager and QuickDraw commands translated into calls to the printer
driver?
A DTS's "Learning to Drive" document and "SampleWriter" source code, available in
AppleLink's Developer Support folder and on the latest Developer Essentials CD, are
helpful references.
Q How can I determine what hardware device is driven by a particular Macintosh
gDevice? I can call GetDeviceList and GetNextDevice to get the driver reference
number of each gDevice but not the hardware ID. The system 'scrn' resource for the
hardware ID of each device doesn't give me the driver reference number. The device
list produced by calling GetDeviceList and GetNextDevice isn't always in the same
order as the 'scrn' resource slot information.
A The following code shows how to obtain the slot number:
DCEHand = (AuxDCEHandle) GetDCtlEntry(DevInfoList[index].gdRefNum);
DevInfoList[devCount].gdSlot = (*DCEHand) -> dCtlSlot;
/* Get slot number. */
Once you have the slot number, you can call the Slot Manager to get the board name and
other information you may need to identify the device, as in the following code:
/* Get the board name from the Slot Manager's board sResource. */
spB.spSlot = DevInfoList[devCount].gdSlot;
spB.spID = 0;
spB.spExtDev = 0;
spB.spCategory = 1; /* board sResource sRsrcType value */
spB.spCType = 0;
spB.spDrvrSW = 0;
spB.spDrvrHW = 0;
if (! SNextTypesRsrc(&spB) ) {
spB.spID = 2; /* Found board sRsrc now, get the sRsrcName. */
if ( ! SGetCString(&spB) ) {
/* Let C unravel its own strings. */
for (count = 0;
DevInfoList[devCount].bdName[count+1]
= *((char *)(spB.spResult)+count);
count++);
DevInfoList[devCount].bdName[0] = count;
}
}
Q When I draw a 32-bit Macintosh 'PICT' image from a file to an 8-bit port via an
off-screen GWorld, I use dithered mode in the CopyBits call and the results are quite
impressive. If there's not enough memory to allocate the GWorld, I draw the image
directly to the port. But since there doesn't seem to be any way to tell QuickDraw to
use dithered drawing mode, the image looks horrible. Should I use dithered mode
instead of source mode? I don't want to try to parse the 'PICT' myself, but I thought
that maybe a QuickDraw global could be modified in my StdBits proc to force dithered
drawing for that operation only.
A You can install a bitsProc bottleneck procedure to get all the CopyBits calls when
the picture is being played back. One of the parameters to the bitsProc call is the mode.
You can install a procedure that passes ditherMode to the original StdBits proc.
Q Why does a call to gestaltNuBusConnectors return zero slots when there actually is
a NuBusTM card or a PDS (Processor Direct Slot) card in the Macintosh IIsi slot?
A A call to gestaltNuBusConnectors returns zero slots because there's no way to
determine if there's a NuBus card or a PDS card in the Macintosh IIsi slot. Gestalt can't
assume that there's always a NuBus or PDS slot, so it just says there's no slot.
However, Apple recommends that you always use the Slot Manager instead of Gestalt to
search for cards, after first checking to see that the Slot Manager trap is implemented.
The Slot Manager will safely do all the necessary work for you whether a card with a
valid declaration ROM is installed or not, and you can search for the card using a
variety of criteria. This technique will allow you to locate NuBus cards, but has the
added benefit of being able to find PDS cards that contain declaration ROMs.
The Macintosh SE/30, IIfx, and LC have the Slot Manager and PDS slots. It's safe to
assume the Slot Manager will be resident in all future machines that have either
NuBus or PDS slot capability.
Q Do you have any available tools or test programs for testing how well our Macintosh
application responds to core Apple events? We need a test application that will, for
example, send events to open a document and print it within our application.
A One of the best tools to test Apple events like 'odoc' and 'pdoc' is the Finder®. The
System 7.0 beta CD version of the Finder provides excellent 'odoc' and 'pdoc' testing
capabilities. That's what most of DTS uses to test sample applications.
There are no tools designed specifically to send Apple events to an application as a
test. Try using some of the DTS sample applications on the Developer Essentials disc to
test your application. One of the easiest to use and adapt is the TrafficLight 3.0
sample. It already will send its own MoveWindow Apple event to any application,
allowing you to see how your application is handling "foreign" events.
Also, you can adapt the CreateAndSendAppleEvent function in AppleEvents.c to send
any type of event you'd like, which allows you to test events that may be specific to
your application.Q Why do I get a bomb when I create a Macintosh filename starting
with a period (.)?
A Macintosh filenames are not allowed to begin with a period, to avoid possible
confusion with driver names, which must begin with a period. (This restriction does
not apply to folder names.) Ideally, the Finder should catch this possible error and
require the file to be renamed, but it doesn't. Future versions of the Finder should
catch this potential problem, but until then users must remember not to begin a
filename with a period. See Macintosh Technical Note #102, HFS Elucidations, for
details.
Q Can the refNum returned by FSOpen ever be 1? What is the range or format of legal
refNums?
A Macintosh file reference numbers (refNums) are currently positive and that means
any positive number, including 1. This doesn't mean that they won't change in the
future, however. To maintain system compatibility, use refNums only as they're
intended to be used.
Q Calling Create from an INIT causes the INIT to be called twice if it alphabetically
follows the file it creates. Is there a workaround?
A This particular limitation of the startup process occurs when you create files in the
same folder as the INIT that alphabetically precede your INIT file. HFS orders files
alphabetically, and the startup process does its thing by incrementing the ioFDirIndex
field of a PBGetFileInfo call. Your INIT file (for example, file #5) is getting opened,
your INIT is called, and it creates a file. The file it creates, for example, is file
#3--that is, it's alphabetically before your INIT file. Now your INIT file is file #6,
and when you return, it increments the ioFDirIndex value from 5 to-- you guessed
it--6, opens that file, and runs your INIT again.
The workaround is to avoid creating files in the same folder as the INIT that
alphabetically precede your INIT file. Also, the file you create should be placed in the
Preferences folder within the System Folder, for both System 6 and System 7. Check
for a Preferences folder within the System Folder using FindFolder, and create one if
it doesn't exist.
Q During a Macintosh application's life, does the value of A5 change? Why does
SetCurrentA5 have to set A5 to CurrentA5? Aren't A5 and CurrentA5 the same while
an application is executing non-interrupt- time code?
A A5 is not necessarily always equal to CurrentA5. Because the Macintosh operating
system and Toolbox don't need to access your application's jump table or global
variables (which A5 points to), they often use A5 for other purposes, except for the
parts of the Toolbox that need to perform graphics operations and use the QuickDraw
globals defined by your application.
Because the operating system or Toolbox can change A5, you must make sure it's set
correctly if the operating system or Toolbox ever calls your code in the form of a
callback. For example, if you make an asynchronous File Manager call, your I/O
completion routine must call SetCurrentA5 for your I/O completion routine. Other
places where you may want to call SetCurrentA5 are in trap patches, your
GrowZoneProc, custom MDEFs, WDEFs, or CDEFs, or control action procedures.
Please note that even SetCurrentA5 is not sufficient when writing code that's executed
at interrupt time, such as VBL and Time Manager tasks. When an interrupt occurs that
your application wants to handle, there is no guarantee that the low-memory global
CurrentA5 belongs to your application. The interrupt could occur while some other
application is running under MultiFinder®. In this case, you should use other
approaches to setting A5. Please see Technical Note #180, MultiFinder Miscellanea,
for further information.
Q My Macintosh application receives information from the serial port, keeping as
much information in memory as possible. However, if I do run out of memory, my
GrowZone routine is allowed to delete older information. Does the operating system
allow the GrowZone routine to be called recursively? That is, if in handling a
GrowZone call, my code does something that requires memory, such as bringing in a
font that isn't there, can I call the GrowZone routine again or would doing so cause an
error? Am I allowed to update things on the screen, such as windows and text in
windows, while in my GrowZone routine?
A Neither the GrowZone routine nor the Macintosh system is reentrant. There is very
little that you can safely do in a GrowZone routine. The system expects that the typical
extent of a GrowZone routine is to check a table or some other predesignated criteria
and then to release or not to release any memory blocks it can. Any sort of user
interface is well beyond the reasonable scope of this level of routine.
Keep a list of handles to blocks of text that you're willing to purge, so that your
GrowZone routine can look through them when called and then release one or more
blocks. Any more than that is really stretching GrowZone too far. By the way,
SetGrowZone should not be assumed to return a result. Inside Macintosh is incorrect
in saying that D0 contains a result code on exit.
Q Do I need to call StripAddress when using SwapMMUMode to switch to 32-bit mode?
I would like to assume that all my pointers are valid 32-bit quantities when in 32-bit
mode.
A Yes, though it would be nice to be able to assume that all your master pointers are
valid 32-bit quantities when in 32-bit mode, the assumption would only be true of
master pointers that were created in a zone created while you were in 32-bit mode,
and even this would only be true on systems that have a 32-bit Memory Manager (the
Macintosh IIci, IIfx, LC, and IIsi).
You need to call StripAddress on any master pointers that were created in a 24-bit
world that you expect to use while in 32-bit mode. You also need to call StripAddress
on distinct master pointers that were created in 24-bit mode if you want to compare
them, regardless of whether you're currently in 32-bit mode.
Q When building a standalone code resource (such as an 'XCMD', 'INIT', 'CDEV', or
'CDEF') with the MPW Linker, the main entry point is specified with the "-m" option.
So why does one also need to make sure that the main routine is the first one in its
object file, and that that object file is the first one linked? Why isn't "-m" enough for
the Linker to figure this out?
A The MPW® Linker generally places modules in the output file in the order that they
appear in the sequence of files to be linked. When building an application, the Linker
builds the jump table after building all the code resources; thus, it doesn't need to have
"seen" the main procedure first in order to place the main procedure's entry first in
the jump table. For standalone code resources (which have no jump table), the main
procedure must be first in the code resource. The simplest way to make sure this
happens is, as you say, to make sure that the main procedure is the first one the
Linker sees.
Q Why does MPW Pascal convert SINGLE numbers to extended, create a temporary area
for them, and then pass a pointer to those extended numbers on the stack?
A The conversion of single-precision values to extended is being done to maintain
accuracy. It's entirely possible to generate values of extended precision while doing the
intermediate math with single-precision values, and the MPW compilers do this
conversion to preserve accuracy. If your application doesn't need the accuracy, you
can declare the parameters to be of type LONGINT, and typecast them as necessary
within your procedure or function. There's no way to tell the MPW compilers not to do
the conversion if the parameters are declared as SINGLE.
Q What is the difference between RelString and EqualString? What should Macintosh
developers use when sorting? Do you suggest having an option for the international
sort?
A RelString and EqualString are mainly intended for the File Manager. The File
Manager uses them for quick-and-dirty string comparison so that it knows how to
return files ordered alphabetically when you use indexed File Manager routines, and so
that it can detect file name collisions. Beyond that, RelString and EqualString aren't
localizable or extensible.
The International Utilities string comparison routines are localizable and extensible.
They use information in the active 'itl2' resource to determine how the characters are
sorted. Most localized systems come with their own 'itl2' resource, so string
comparisons are done correctly for the region for which the system is localized.
Because RelString and EqualString stay the same for all these regions, you'll probably
find some cases in which strings are compared incorrectly by these routines.
One important place where RelString and EqualString don't work very well is with the
new characters in the extended Macintosh character set. When the LaserWriter was
introduced, the LaserWriter fonts used the extended Macintosh character set, which
added many new characters, including several new uppercase characters with
diacriticals. In system software version 6.0.4, the International Utilities were
updated to take advantage of these new characters. For example, the uppercase "E" with
a grave accent first appeared in the extended Macintosh character set. With 6.0.4, the
lowercase and uppercase "E" with a grave accent were considered to be equal in
primary ordering, and unequal in secondary ordering, which is correct. Even today,
RelString and EqualString think in the old Macintosh character set, erroneously
believing that lowercase and uppercase "E" with a grave accent have nothing to do with
each other.
Q The Macintosh IIsi and LC computers don't come with programmer's switches. How do
I get reset and NMI on these machines?
A Both machines have an ADB (Apple Desktop Bus) I/O processor which incorporates
the reset and NMI functions through the keyboard. The functions are accessed as
follows:
Under some circumstances you may have to hold the reset and NMI key combinations
down for a little while (but no more than a second) to make sure the ADB processor
sees them.
You'll find the latest MacsBug on the Developer Essentials disc and in AppleLink's
Developer Support folder. The MacsBug reference manual is very helpful. A package
containing both MacsBug 6.2 and the manual is available from APDA for $35.00
(#M7034/B).
Q What's wrong with having VBL (Vertical Blanking) tasks make calls to the Macintosh
Memory Manager, either directly or indirectly?
A The problem is that the Memory Manager could be moving memory around when an
interrupt occurs. If the VBL task also moves memory, the heap could be destroyed. VBL
tasks are intended to provide a method of time-syncing to the video beam of the
display. (On slotted Macintosh models you'd use SlotVInstall.) They're also used to get
periodic time for short tasks, although the Time Manager is better for this. VBL tasks
should minimize execution time. The best use of a VBL task is to do a short condition
check and set a flag for the main process to indicate that it's now a good time to do
something.
Q Can I still write to James Brown at his work release address?
A The Godfather of Soul was released from prison on parole last March. His new
address is
Universal Attractions
218 West 57 Street
New York, NY 10019
Kudos to our readers who care enough to ask us terrific and well thought-out
questions. The answers are supplied by our teams of technical gurus; our thanks to all.
Special thanks to Pete "Luke" Alexander, Mark Baumwell, Rich Collyer, Marcie "MG"
Griffin, C. K. Haun, Dennis Hescox, Kevin Mellander, Guillermo Ortiz, Keith Rollin,
Kent Sandvik, Gordon Sheridan, Paul Snively, Bryan Stearns, Forrest Tanaka, Vince
Tapia, and Scott "Zz" Zimmerman for the material in this Q & A column.*
Have more questions? Need more answers? Take a look at the developer technical
library on AppleLink (updated weekly) or the Q & A stack on the Developer Essentials
disc.*