LETTERS

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. Thanks!
-- 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 content.

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.
--Charlie Reading

Um, oops. (Imagine, if you will, me standing gaping and red-faced, astonished at my own carelessness and idiocy.)

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.
--Dave Johnson

BABBLING ON
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!
--Kevin Killion

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. But power 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.
--Dave Johnson

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?
--Tony Amaretto

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. Have fun!
--Dave Johnson

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 -- such 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 responding.

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 the chain.

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 routine.

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