Volume Number: 13 (1997)
Issue Number: 4
Column Tag: Dialog Box
Dear Editor,
I was pleased to see the article in MacTech December 1996 encouraging programmers to use asynchronous I/O, but unfortunately some of the details in the article were not correct. Richard Clark wrote "The completion routine for PBRead is especially poor, as it receives no parameters... This routine appears to have A5 set up for it..."
Firstly, the PBRead completion routine does get passed a parameter (a pointer to the parameter block that has just completed) and secondly, A5 is not guaranteed to be set up to point at your globals. A5 will be pointing to the globals of whichever application was interrupted to execute the completion routine (which might even be your own application, which is why A5 may sometimes appear to be set up correctly). If your completion routine tries to access your program's globals without first making sure to set up A5 correctly, the Mac will crash.
Fortunately, there's no problem as long as you know how to deal with it: Because the PBRead completion routine gets passed a pointer to the parameter block, you can use this to pass it as many extra parameters as you like.
1. Define a new "extended" PBRead parameter block like this
typedef struct
{
ioParam io;
void *regA5;
short my_parameter;
// ... and, so on, as many as you like
} ex_ioParam;
2. Before you call PBRead, fill in the parameters that you want the completion routine to get (especially the Register A5 value).
static ex_ioParam pb; pb.io.ioCompletion = CompletionRoutine; pb.io.ioRefNum = refnum; // ... and so on pb.regA5 = GetGlobalsRegister(); PBRead((ParmBlkPtr)&pb,TRUE);
3. In the completion routine, set up the correct A5 value and access other parameters as necessary:
static void CompletionRoutine(void)
{
register ex_ioParam *pb = GetRegisterA0(); register void* oldGlobalsReg
= SetGlobalsRegister(pb->regA5);
// ... Do your stuff
SetGlobalsRegister(oldGlobalsReg);
}
If you don't already have the 68K register accessor functions defined, they are:
#pragma parameter __D0 GetRegisterD0() // MOVEA.L D0,D0 local void* GetRegisterD0(void)
= { 0x2000 };
#pragma parameter __A0 GetRegisterA4() // MOVEA.L A4,A0 local void* GetRegisterA4(void)
= { 0x204C };
#pragma parameter __A0 GetRegisterA5() // MOVEA.L A5,A0 local void* GetRegisterA5(void)
= { 0x204D };
#pragma parameter __A0 SetRegisterA4(__A0) // EXG A0,A4 local
void* SetRegisterA4(void*) = { 0xC14C };
#pragma parameter __A0 SetRegisterA5(__A0) // EXG A0,A5 local
void* SetRegisterA5(void*) = { 0xC14D };
#ifdef THINK_C
#if __option(a4_globals)
#define A4GLOBALS
#endif
#endif
#ifdef __MWERKS__
#if !__A5__
#define A4GLOBALS
#endif
#endif
#ifdef A4GLOBALS
#define GetGlobalsRegister GetRegisterA4
#define SetGlobalsRegister SetRegisterA4
#else
#define GetGlobalsRegister GetRegisterA5
#define SetGlobalsRegister SetRegisterA5
#endif
You can do a hell of a lot with completion routines, as long as you don't try to call QuickDraw, the Memory Manager, or make synchronous calls. The entire game of Bolo is basically one huge completion routine, which is why you can switch to Microsoft Word, pull down a menu, and sit there holding the mouse button down, without affecting the game of Bolo at all. That's why I've never really understood all the people who continuously complain that the Mac needs preemptive multi-tasking. Sure, preemptive multi-tasking makes the programming easier, but it doesn't fundamentally change what you can do. In fact it makes some things worse - with asynchronous I/O your completion routine gets called immediately when the operation is complete, where as with preemptive multi-tasking you're at the mercy of some scheduler that decides when your code next deserves to get a slice of CPU time.
Stuart Cheshire, cheshire@cs.stanford.edu
Not sure if I'm the first to point this out to you, but... I'm just looking at the "MacTech Now" ad on page 77 of the February issue. I see shadows behind the logo text at the top. And... The shadows don't match up! The ones behind the letters of the word "MacTech" indicate a light source above and to the left, but the ones behind the word "Now!" indicates a light source that's above and to the right!
Lawrence D'Oliveiro
Actually, Lawrence, the MacTechNOW logo was developed using an as yet unreleased QuickDraw3D derivative technology called QuickDrawMPV. This technology allows the simultaneous use of multiple points of view, resulting in shadows going in more than one direction. We chose to use QuickDrawMPV because it best represents how the MacTechNOW site provides information from more than one source.
We hope to offer more information about QuickDrawMPV in a future issue, assuming Apple doesn't see this technology as the joke it really is and refuse to acknowledge its existance.
Thanks for your note; I really wanted something like this for April, and you provided it. :-)
Eric Gundrum, Editor-in-Chief
Dear Editor,
I wanted to take a moment to respond to the Viewpoint article by Eric Gundrum in the December ‘96 issue.
I'm a subscriber that appreciates seeing articles targeted toward the beginning programmer. I can recall two recent articles that were of this category: Peter N. Lewis on memory issues and Mark Aldritt (I think) on tips for making AppleScripts run faster. It would be nice if each issue had one article targeted to beginners (a regular column?). My guess is that there is room for it, but most writers are less interested in the beginners audience. I don't know how many people (non-participants) read the programmer's challenge, but it seems to be one of the best opportunities for experienced programmers to learn new tricks and approaches. It's good that this department will be enhanced in future articles.
Mr. Gundrum also noted that more code examples would be given. Please stress that your authors should heavily comment their code. Also, wouldn't it be possible to archive the more detailed code on your website? That way you don't have to fill up your magazine pages with code, and the readers could retrieve it in digital form to avoid re-typing it. You could print a URL for that month's issue.
The vast majority of the magazine is over my head, but that's my own problem. I currently only have time to dabble - I'm working on trying to change that. The subscription is worth it to me just to stay abreast of what's happening.
Here are some suggestions for beginner's topics:
1) An article that addresses the upcoming changes to the MacOS and how a true beginner should prepare. (Admittedly, Apple is making it harder for you to anticipate the new OS.) I have purchased several beginners books that cover the current OS. However, I occasionally read about how the Event loop paradigm will change in MacOS 8. Then there's the scrapping of CDEVs and INITs. I worry that I'm learning things that will no longer be in use after another year or two. Are things going to change so much that it would be better to just wait, especially if the BeOS is adopted?
2) Surprisingly, I have not encountered a review of the binary foundation of programming in the Mac programming books. My ideal review would cover all the "lowest level" representations and their manipulation, such as octal, hexadecimal, setting bits, bit-wise shifts, etc. For example, while it's quite obvious to me why computers speak binary, I don't know what the value of hexadecimal is. I'm sure that seems like a very ignorant question to an experienced programmer. It may be typical from someone who was not a math or computer science major in college.
3) An article that addresses approaches to information storage (struct design): what are the best ways to store numbers, text, pictures, etc. Sample databases seem to be the best vehicle for illustrating these points. What should one think about in the design stage to ensure later speed and flexibility?
4) An article that focuses on GUI design: when I use Mac programs I often wonder how the programmers implement certain design features. Usually this entails linking underlying data to some element of the GUI - dragging list selections from a "source" to a "target", double-clicking a certain region to invoke an action. Another good example: in a full-featured word processing program that permits styling and coloring of text, how are these attributes stored when TextEdit is not being used? How does one calculate the physical dimensions of text data, ie. how do you implement a print preview function that gives a "to scale" WYSIWIG representation of the data? I realize that these are pretty advanced issues.
5) Manipulation of strings: sorting, searching, pattern matching, connection to the GUI (ie. double-clicking selects a word).
I'm sure I'll think of a few more...
Michael Myers
Michael, your point is well taken. The MacTech readership is a very diverse group, including nearly equal numbers of readers at all levels of programming expertise. I agree that every issue should include at least one more article for beginning programmers, and I am working with authors to get those articles written.
The complete project files for all of our articles are posted to the MacTech ftp site, available through MacTechNOW, when the issue ships. When asking an author to include code for an article, I ask that only enough of the code be included so the article can be read without your having to print pages of code from the ftp site. This leaves more space for explanations of the relevant points.
The articles you suggest are an excellent starting point. Keep those suggestions coming.
Eric Gundrum, Editor-in-Chief
