NEW TECH NOTE NUMBERS
In develop Issue 14 Peter Fink complains about the loss of Tech Note numbering. In your answer
you write: "We're always open to suggestion, but so far you're the only one to mention this. If
others reading this reply have similar feedback, I hope they'll let us know."
Actually, I and others have complained about the loss of Tech Note numbers for quite some time,
but sometimes talking about these things is like complaining about the weather. I suspect most
people just grumble along and don't complain in writing.
-- Johan G. E. Strandberg
Good news: Numbers are back; see the editorial on page 2 and the Tech Notes on this issue's CD. It's too bad
when people grumble without writing; the latter is much more effective, and we really appreciate the effort.
-- Caroline Rose
DEBUGGING LESSON FLUB
There seems to be a problem with the point made in the "Debugging Lesson" letter in the Letters
section of develop Issue 14. According to the source listed, there would be no problem even if
memory moved when FillWithData was called. Since the handle is being passed as a handle (that is,
not dereferenced), and handles are 4-byte pointers (which get pushed onto the stack as is),
FillWithData would always get a valid handle, which it can dereference internally to its heart's
Unfortunately, there seems to be a lot of confusion (and a great deal of paranoia)
over the usage of handles. As long as you pass handles as handles (and watch your dereferencing),
you'll be OK.
Um, oops. (Imagine, if you will, me standing gaping and red-faced, astonished at my own carelessness and
You're right, of course; the danger is only in passing dereferenced handles to routines in other segments, and
the code in the letter passes the handle itself. I guess I just read the text and didn't really look closely at the code
before replying. Obviously, it was only intended as an example, and the writer's point is still valid: passing
dereferenced handles to routines in other segments is dangerous. You should either pass the handle itself (as the
example code did!) or lock the handle first.
Sorry about the confusion.
I enjoyed reading Dave Johnson's column in develop Issue 13 ("Tower of Babble"). While reading his
discussion of natural versus programming languages, I think I was able to put my finger on what has
bugged me about HyperTalk® for years. Natural languages imply a fluidity of meaning, giving its
users great flexibility for nuances, emphasis, and brevity. HyperTalk looks like a natural language,
but it possesses none of that fluidity of meaning. In HyperCard ®, SET has but one meaning. But in
my Oxford dictionary, "set" has 194 definitions! In other words, HyperCard looks so much like
English, one winds up assuming that all kinds of structures could be used as long as they make sense
in English (for example, "set me to true").
Allow me to submit a suggestion, which you may wish to pass along to the software gods. Since
Apple has now all but declared that C and C++ are the only computer languages the human race will
ever need, maybe it would be great to have a HyperTalk-to-C translator. Why? Well, C is a write-
only language (no one ever can figure out what's happening in someone else's C listing) and
HyperTalk is a read-only language (it's a cinch to understand, but impossible to code in). With a translator, we could write code that still could be understood, just
like when we used to code in Pascal. (Yes, this is a joke, from a die-hard Pascal enthusiast.)
Thanks again for a nifty column!
I'm glad you liked the column. Your comment about HyperTalk is very well taken! I think that's what always
bothered me about it, too, though it was just a sort of vague unease. Unfortunately, I think people who didn't
learn "regular" programming languages first may have a distinct disadvantage: we "real" programmers know
up front how limited and terse and strict programming languages are, and we don't expect anything more.
users who learn HyperTalk (or, more likely now, AppleScript) as their very first programming language may
be in for a struggle if they don't keep reminding themselves that it's not a natural language.
As a die-hard C enthusiast, I'll graciously ignore your slams against my favorite language, and assume that
since you're obviously an intelligent person, sooner or later you'll realize the error of your ways and come
around to the truth, bemoaning the years you've spent in bondage to an uptight compiler.
ASYNCH SUPPORT ON A/UX
After reading through Jim Luther's Asynchronous Routines article in develop Issue 13, I spiffed up
my application to make all my file handling asynchronous, anticipating the glorious day when all the
drivers on my Macintosh support asynchronous calls. But since the SCSI Manager isn't
asynchronous yet, there's no apparent difference to the user of my code (or to me, the hard-working
programmer who wants payoff for my labors).
Is there any platform or configuration I can test my application on and see the results of my effort?
Try your code on A/UX 3.0.1 (the operating system for the Apple Workgroup Server 95); it features an
enhanced File Manager that supports asynchronous calls to UNIX ® file systems simply by using the techniques
in Jim Luther's article. AppleShare Pro takes advantage of this capability on AWS 95 to get performance up
to four times better than AppleShare 3.0's under System 7 (your mileage, as always, will vary).
For more information related to the Asynchronus Routines article, see the box on the next page.
MORE ON ASYNCHRONOUS ROUTINES IN ISSUE 13
For developers interested in the "Asynchronous Routines on the Macintosh" article in develop Issue 13, here's
some new information that has surfaced since then.
StackSpace. Contrary to the advice on page 28 of the article, you should not call StackSpace at interrupt
time, because the Memory Manager might not be in a consistent state. Furthermore, StackSpace clears
MemErr, which may have an adverse effect on the current process's handling of Memory Manager errors.
PPC polling. Unlike the Device Manager and File Manager, the PPC Toolbox stuffs the result of an
asynchronous routine into ioResult before it's really done with the parameter block. If your interrupt code --
as a VBL task -- polls ioResult periodically to check for completion and reuses the parameter block to make
another call, the system can crash because one or more system queues will be corrupted.
Context switching. The System 7 Process Manager (and MultiFinder under System 6) will wait until all
currently active asynchronous requests to the File Manager have completed before performing a context
switch. This check was added for compatibility reasons to prevent system crashes caused by a few
applications that accessed program globals within File Manager completion routines without restoring their
A5 world. What this means to you is that if your application makes an asynchronous File Manager call and
then calls WaitNextEvent or GetNextEvent, the system may wait for your call to complete. If the
asynchronous File Manager call takes a long time to complete, it will appear to the user that the system isn't
Synchronous drivers. Although you can execute low-level file access routines asynchronously, a volume's
underlying device driver may not support asynchronous operations. Once the File Manager passes a request
to a synchronous driver, that driver doesn't give up control until it has completed the task. Synchronous
drivers (such as those using the current SCSI Manager) affect programs using asynchronous File Manager
calls in two ways: unexpected pauses and unsightly stack frame buildup.
- When calling the File Manager asynchronously, your program passes control to the File Manager and the
request is placed in a queue or, if the queue is empty, the request is handled immediately. Either way,
once a synchronous driver gets the request, it retains control until it has responded to the request. If the
request takes a long time to complete, the user may think the system isn't responding. If your program is a
background task, these pauses will affect the performance of the current foreground application. To keep
this to a minimum, avoid time-consuming asynchronous File Manager requests.
- Chaining asynchronous File Manager calls will work on volumes controlled by synchronous drivers, but
watch out: When the driver is synchronous, the stack frames from the system and your completion routines
will keep building up on the current stack until the last asynchronous call in the chain completes, or until
the stack overwrites the current heap. You'll need to break the asynchronous File Manager call chain
every few completion routines. A simple way to do this is to start a Time Manager or VBL task from your
File Manager call's completion routine, and let the task start the next asynchronous File Manager call in
File Sharing and AppleShare. Chained asynchronous File Manager calls can fail when either the Macintosh
File Sharing or AppleShare 3.0 (not 3.0.1) file server is running. The file server software intercepts almost all
calls made to the File Manager. Due to how the file server keeps track of what requests it has or hasn't seen,
there are a few situations where the file server can do the wrong thing with chained asynchronous File
Manager calls. To make sure the file server sees and handles all chained asynchronous File Manager calls
correctly, use two parameter blocks for the chained calls and switch parameter blocks at every completion
WE HATE IT WHEN YOU DON'T WRITE We welcome timely letters to the editors, especially from readers reacting to articles that we publish in develop. Letters
should be addressed to Caroline Rose (or, if technical develop-related questions, to Dave Johnson) at Apple Computer,
Inc., 20525 Mariani Avenue, M/S 303-4DP, Cupertino, CA 95014 (AppleLink CROSE or JOHNSON.DK). All letters
should include your name and company name as well as your address and phone number. Letters may be excerpted or
edited for clarity (or to make them say what we wish they did). *
SUBSCRIPTION INFORMATIONSubscriptions to develop are available through APDA (see inside back cover for APDA information), or you can use the
subscription card in the back of this issue. Please address all subscription-related inquiries to develop, Apple Computer,
Inc., P.O. Box 531, Mt. Morris, IL 61054 (or AppleLink DEV.SUBS). *
BACK ISSUES For information about back issues of develop and how to obtain them, see the last page of this issue. Back issues are also
on the develop Bookmark CD and the Developer CD Series disc (Reference Library edition).*
Thanks to François Grieu and Lawrence D'Oliveiro for providing some of this information. *