Letters

Update Events - Who Does them?

Clifford Story

I was very pleased to receive the first issue of my subscription today, within three weeks of sending you my check. Great service -something not common in the Mac world!

I'm sticking my neck out here but I believe Peter McInerney misunderstands the event manager's handling of update events. His letter in the November issue is a comment on an article, "Pop-Up Window Scroller" by Scott Boyd, in the September issue (I have not read the article). Mr. Boyd, in his program, called BeginUpdate and EndUpdate to "steal" update events. Mr. McInerney protests that these calls have no effect whatever on the event queue. I believe Mr. McInerney is correct but his observation is irrelevant.

The point I want to make is that update events have nothing to do with the event queue either. They do not come from the event queue. Rather, GetNextEvent generates an update event if some window needs to be redrawn (and there are no pending events of higher priority). See Inside Macintosh, "Toolbox Event Manager", page I-245.

How does the event manager determine that a window needs to be redrawn? It examines the update region; if it is nonempty, then the window needs to be redrawn, and an update event is generated. See "Window Manager" in IM I-278.

One of the effects of BeginUpdate is to zero the window's update region. Thus, if Mr. Boyd calls BeginUpdate, he indeed "steals" an update event, since with an empty update region, no update event will be generated for the window. (Mr. Boyd must follow this call with one to EndUpdate to reset the visrgn, which is altered by BeginUpdate.) So there are wheels within wheels within the Macintosh, and all is not as it seems

Update on Update Events

Stephen Hanna

First, let me compliment you on the finest technical magazine around. Each issue provides at least one thought-provoking topic. Unfortunately, each issue also provides at least one misled technical comment. [If we knew it all, we wouldn't need MacTutor! -Ed]

Mr. McInerney's letter in the November issue impels me to write and clear things up. Using the Operating System Event Manager routine FlushEvents to get rid of update events is useless since these events are never placed in the queue in the first place, but generated whenever GetNextEvent or EventAvail is called and there is no higher priority event pending. I look forward to more letters from people living on the edge of what the Mac can do. Let's show those pinstripes with their PC's the meaning of "hot code".

This Time The Author Speaks on Update Events!

Scott Boyd

Every time GetNextEvent occurs, the window manager checks the updateRgn of every visible window and if it finds a non-empty updateRgn, it posts an update event for that window. Thus, it is essential that updateRgn's are no different than before when I bring up the OverView window. My workaround to eliminate any update regions for the front window does this. Much of the feel of OverView is that it is fast and free of side effects, just like a menu. Thus, update events are unacceptable. If you can see footprints in the butter, we haven't done our job. Not worrying about update events is not the answer either, since what generates a non-empty update region for the front window is that I put another window in front of it: the OverView window! A good friend of mine, Greg Marriott, is writing an article on a much better way to implement fast pop-ups which eleminates the restriction that the pop-up not overlap windows other than the front window. OverView looks even better than before, and it has yet to cause the generation of a single update event.

Help! MassTech Killed Me!

Gary Mason

I upgraded my Mac to a 512K, and then to 2MB with the late great MassTech Corp. of Groton, Mass. I have recently attempted the Mac+ Rom/Disk upgrade, and was greeted with abject failure. On power up, not even video appeared. I have since chased around trying to find someone, anyone, who can provide answers to these two questions: Can the MassTech 2MB system be upgraded to a Mac + status, and if yes, how?? I'm including my address in hopes some talented MacTutor reader will write me with an answer. Moral: Watch out for disappearing computer companies.

Likes VIP

Rod Paine

A comment about your "Random System Crashes" you mentioned in the November issue. From what I've experienced, you are correct in suspecting the Cmd-Shift-3 fix for menu snap shots; it raised havoc with the fonts within my dialog boxes, after printing also. I've gone back to Camera DA. [I haven't had any trouble with the "official" Apple installer script fix so far. -Ed]

Also, on my two serial port MacBottoms and a new SCSI MacBottom, I'm running System Files of 510K, but I've discovered that keeping the DA file at 13 DA's and the font file at 17 fonts, my random system crashes are now a thing of the past. I'm not suggesting that these are "magic" numbers, but this info might help somebody identify whey these crashes are a fact, when more DA's and Fonts are brought into play, on either type of hard drive. [Yes, we've had several calls on this subject and while no particular failure mode is observed, the majority opinion seems to be that large system files, many DA's and Fonts, make the system file unreliable and crash prone. Apparently there are still "funnies" lurking in Apple's system software. Several have suggested however, that once you "construct" a stable system file, it tends to remain stable. -Ed]

I also noted, that these random crashes, while within MacWrite, tended to occur more frequently when changing fonts or text size and saving a file. I was never able to get a sequence to repeat a crash, but it's happened enough times to cause me to grit my teeth, as I do a save. [MacWrite does crash when changing fonts in the entire document from time to time. -Ed]

Lastly, great article on VIP by Bill Luckie! I've been working with the Mainstay folks for some time and they've got to be proud of this one! This may well be the application that lifts this heavy user out of his rut and finally gets me going down the road of programming. I've had a pre-release copy of VIP for some weeks now and it sure has started me on my way. With a translator for LightSpeed C coming, I think I just might be able to enter the Mac programming community some day and make some meaningful contributions. I look forward to the future columns on VIP and thanks again David, for all the effort that you've put into MacTutor, as it nears the beginning of it's third year! You've got a lot to be proud of too. [Thanks for the nice comments! -Ed]

Calling Super Kelly to the Rescue!

Jose Merhi

After all I apologize for my bad english. I read with enthusiasm your column on Basic, which is the reason of this letter, to make a question for you. I see in a previous issue of MacTutor a program called window scroll bars in Basic using the CLR libraries. My problem is: I want to make a similar program but in ZBasic Compiler language, but I don't know how to make it. I write Zedcor and I implore to answer me this question, but I never receive any answer to my four letters!

Another question: I have the last ZBasic manual and he explain how to save text in the clipboard, but the example on the manual only save 1 line of text. I wish to make change to this example to save more than one line but my results never is good. How do I do this? [Your letter has been forwared to Dave Kelly, who will probably get a column on it in an upcoming issue for you. -Ed]

Sue the Radio Station

John Mancino

A rare but serious SCSI warning: This will only effect a few people, but if it does, it will drive you stark raving mad trying to figure it out. I was having problems at a beta site with totally random file corruption. I tried every possible combination / replacement of software and hardware on the system to isolate the problem all to no avail. Finally, while making my umpteenth apology to the user over the phone, I happened to ask about the music that was always in the background on the phone but seemed particulary loud that day. It turns out that it wasn't a Musak Service at all, but a local AM radio station whose broadcasting tower was so close that anything electronic (they have electronic, not carbon receivers in their phones) picked up the transmissions. You got it! Apple confirms that the VLSI SCSI chips are extremely sensitive to AM transmissions because of their basic construction and the fact that the Mac case is relatively poorly shielded. The only fix that was suggested was a faraday cage surrounding the Mac and drive, or for either you or the radio station to move.

Regarding system crashes, I had the same problem and could not resolve it until I replaced my downloaded 3.2 system from an official software supplement disk. Perhaps there are some bad 3.2 systems floating around. I'm using a Mac Plus with 2meg MacMemory, LoDown drives and tapes. My system file is running 600-800K. I noticed that at seemingly random times after a system crash, the system file will be modified as much as 500 bytes during reboot. I check the system file carefully after those rare times that I do have a crash and replace it if it has modified itself.

Two final points. Has anyone noticed random disappearances of files while using SFGetFile dialog? Sometimes when I try to access a file in a folder on the SCSI drive, the file, which I know is there, does not appear. If I simply copy that same folder to a floppy, the file is magically there when I call SFGetFile again. I am convinced there is a bug in the OS or packages somewhere. Also, has anyone had problems trying to throw away a folder that contains other folders and getting a message that in one of those inner folders is a file which is "locked or in use"? You then proceed to work your way to the offending file only to find out that it is neither locked nor in use. At this point you then throw it in the trash can (it may or may not let you do this) and go to empty the trash only to be told that it can't empty the trash! The final fix is to reboot the system, at which point you are allowed to trash the file. This happens more on SCSI drives, but I have not noticed it on floppys. [I have had this problem, but it appears to be legit. Checking such a file with ResEdit does show the busy bit set, which you can't reset without re-booting for some reason. Some programs create files and leave them damaged or open or something, that leaves that busy bit set. -Ed]

TEScroll Bug - Tech Note

Tom Saxton

Your article "Extending TextEdit for Tabs" in the November issue documented much of the inner workings of TextEdit and gave the courage to try it. In doing so, I found out that a bug I was having with the Chernicoff Text Editor's caret disappearing was from calling TEScroll with dh and dv both equal to zero, which apparently clears the low byte of the caretState field in the TERecord. This tells TEIdle not to flash the caret. This only happens with the new ROMS. I tracked this down with Macsbug and Lightspeed C, which makes symbols for Macsbug tracing. [Yes, as noted in our Text Edit article this month, this is a recent tech note update from Apple. -Ed]

Debugging INIT Resources With TMON

by

The past month or so has been pretty busy testing some things for some people and writing a desk accessory/INIT resource combo. The desk accessory is called "Set Paths," and the INIT resource is in a file called "Boot Paths." Together they make a way to tell HFS to search up to five paths whenever it looks for an existing file. That way you don't have to worry about using pathnames in your programs. This is particularly nice for we TML Pascal programmers, who can say USES MemTypes, QuickDraw, OSIntf, etc. without worrying about pathnames! Set Paths/Boot Paths is shareware and should be on most major information services by the time you read this!

However, what I really wanted to talk to you about, programmer to programmer, is how I finally figured out how to debug INIT resources using TMON.

You TMON users out there probably know what I'm talking about when I say that TMON showed a definite design deficiency in not being installable at boot time. Since TMON can only be used like any other application, its startup mechanism is simply the "Set Startup" function of the Finder, i.e. it gets launched AFTER any INIT resources (internal AND external) have already executed. It's a drag, to say the least.

Since I was dealing with an external INIT resource (one that's in its own file, rather than being installed into the System File) it occurred to me that I could try to reconstruct essentially what happens when external INIT's are executed.

In case you don't know, in any System 3.0 or later there is an INIT with an ID of 31. INIT 31 has been documented in an Apple Tech Note, the gist of which is this: INIT 31 exists in order to allow programmers to modify the behavior of the system at a low level without directly modifying the System File. It does this by looking in the System Folder for any files of type INIT or RDEV. If it finds any files of that type it opens them and looks for INIT resources. If it finds any INIT resources, it executes them. Simple, huh?

So the first step of my journey was to use MacNosy to disassemble INIT 31. I already had some idea as to how INIT 31 had to work, and Nosy confirmed those suspicions. I was then able to conceptualize a VERY small piece of code that I could execute that would execute my INIT under debugger control!

The question was: where do I put it? I'm really not that familiar with the Mac's memory map, and besides it'll be different from machine to machine. What I finally settled on was to use the largest free block in the application heap, and to put the code way up there in the middle of the block. This is an admittedly dangerous technique: it assumes that the INIT in question doesn't allocate much memory (most don't).

So, with TMON in hand (or in 512e, I should say), I opened the heap window on the application heap. Scrolling to the end of the heap revealed that under the Finder I had a HUGE free block (the last block displayed). It started at 1Cxxx or thereabouts, so I decided to put my patch at 20000. Here's what I came up with (using TMON's interactive assembler):

CLR.W        -(A7)
PEA          FileName     ;*
_OpenResFile
CLR.L       -(A7)
MOVE.L     #'INIT',-(A7)
MOVE.W     #ID,-(A7)    ;*
_GetResource
MOVEA.L    (A7)+,A0
MOVEM.L    D0-A6,-(A7)
MOVEA.L    (A0),A0
JSR        (A0)
MOVEM.L    (A7)+,D0-A6
_CloseResFile
_Debugger

Needless to say, a few comments about the code are in order. First of all, the asterisk comments mark instructions that you must supply values for. In the case of ID, the value should be whatever the ID of your INIT is. For a single external INIT, an ID of 0 works just fine.

FileName, on the other hand, must be the address of the filename of your INIT file (a full pathname, too, for HFS' sake). Assuming that this patch is at 20000, I usually put the filename at 20100. To do this, open a TMON dump window and anchor it to 20100. Click on the second byte in the ASCII side of the window. Type away! You can only enter one line at a time, so when you get to the end of the line, press RETURN and continue on the next line(s) as needed. When you are done (don't forget to press RETURN) count the number of characters in the pathname (count in hex). Click on the first byte of the first line in the HEX side of the window, enter the length byte, and press RETURN. Congratulations! You have just manually entered a Pascal STR255-style string!

You can tell I'm an EUA user by the _Debugger at the end of my code. Standard TMON doesn't support the use of _Debugger (oops) so Darin Adler added that support in EUA. I just use it as a convenient way to get back into the debugger.

Now, is the patch in place? Is the filename in place? If they are, there is one more important step you must take. Check the current value of the PC. Write it down. Now you can open the TMON registers window and set the PC to 20000.

You are about to debug your INIT resource! Isn't that a GREAT feeling? Ok, now you can click on execute if you're feeling like a daredevil, or you can trace or single-step your way through it. Being a coward by nature, I chose to single-step. Boy, did I get an education!

My patch worked fine. The CLR.W made room on the stack for the refNum returned by _OpenResFile. _OpenResFile did its thing (but only because it wasn't in a resource other than CODE and DRVR. More on this later). The CLR.L, MOVE.L, MOVE.W and _GetResource got my INIT for me. The registers were saved, the INIT's handle dereferenced (MOVEA.L (A0),A0) and finally - the moment of truth - the JSR (A0) passed control to my INIT.

So far, so good. I was staring my INIT code in the face in TMON! The labels to the left of the code all said: "INIT0000+xxx," and the code was what I had written, all right!

I continued single-stepping. I had just gotten to a PEA FileName, _OpenResFile pair of instructions (yes, Boot Paths has occasion to open a resource file). When I stepped the _OpenResFile, the system bombed with the ID = 2 (which, of course, TMON trapped).

Here's a funny thing: the odd address was encountered in _RecoverHandle. What on earth was I doing in _RecoverHandle??? Back to Nosy

Rebooting the system, bringing up Nosy, and looking at _OpenResFile revealed something interesting: _OpenResFile checks the memory manager bits in the high-order byte of the address of the filename in order to see if the filename is from a resource (i.e. to see if the pointer to the filename is a master pointer from a dereferenced handle). Why? I still don't understand the purpose of this, even though I have since read the Tech Note that documents this _OpenResFile bug. At any rate, I went back to my source and instead of saying:

PEA FileName, _OpenResFile

I said

PEA FileName, CLR.B (SP), _OpenResFile.

The CLR.B (SP) clears the memory manager bits of the top byte of the stack so that _OpenResFile no longer tries to _RecoverHandle a nonexistent handle! That took care of my ID = 2 bomb, and from that point on my INIT worked like a charm. Next time, I'll share some notes on what I call "not so standard file dialogs"!

New Logo

Andrew Shalit

Coral Software, in Cambridge, should soon be releasing Coral Object Logo. Coral's work has been mentioned in most of the places that Mac object-oriented programming has been discussed. Also, MacScheme+Toolsmith should soon be available (finally!). Both of these will be complete development systems. Let me know if you'd be interested in articles in either of these languages. [Yes, we would! -Ed]

MacTutor Does Foreigns Best!

Dr. Christian Stratowa

I am sending this letter to MacWorld, MacUser, MacTutor and Macazine because from the premier issue on of each journal I have all volumes and I hope this will be the case in the future too. I am subscribing to all four journals but it seems only MacTutor is able to handle subscriptions and renewals from a foreign country efficiently. Here is a summary of my results:

MacWorld: I renewed on June 26 for a subscription due to lapse in August 86. By the end of October, I still had not received my September 86 issue although you can already buy the Oct issue in local bookstores.

MacUser: Everything seems to work fine although sometimes I have to wait rather long to get the different issues. The August 86 issue came with the September issue.

MacTutor: I can congratulate MacTutor for the efficient handling of my subscription. Until now I received ALL issues IN TIME, and the issue I received after my renewal contained already the mailing label with the new expiration date. Congratulations MacTutor, I am looking forward to the next issue.

Macazine: I must say this is the worse case. I never got a renewal form. Although the expiration date was Aug 86, my last issue was the July issue. Besides the Aug 86 issue, I have also never received the Feb 86 issue. Because you cannot buy Macazine in Austria, this means my collection is incomplete. I hope to receive a renewal and get my missing issues because I would not like to miss one issue of your journal.

Likes Aztec C

Nestor Murayama

Every month I wait for my MacTutor, the best information source in programming on the Mac, to find all those new things that make it so great. There's a very little world of programmers here in Perú, and we appreciate so much your efforts. What about more Aztec C help on ABC's of C column? I'm very excited about C as a language. Thanks.

Will Apple Finish Appletalk?

William May

I am very interested in AppleTalk and have enjoyed reading (and re-reading) your series on the subject in MacTutor. However, I have some questions that are not addressed in your articles or in the AppleTalk documentation. For the most part, these questions revolve around the business objectives of AppleTalk (vs the technical objectives). People in my company were recently looking at buying Mac Pluses for desktop publishing. We were disappointed to find that AppleTalk seems to serve mainly (only) as a method of sharing the LaserWriter printer. It does not seem to support file servers and other useful capabilities. There are third party alternatives, which raise questions of current and future compatibility problems.

These then are my questions: where (conceptually did AppleTalk come from? From the user's point of view, what is it intended to achieve? Why not implement an existing standard, such as Ethernet? What are the design objectives behind some of the unconventional aspects of AppleTalk? Finally, where do you think Apple will go with AppleTalk; what can users expect to see developed? As Apple must know, there is a lot of potential for a fully functional AppleTalk. My question basically is why isn't it fully functional and when will it be?

[You ask some good questions. Maybe some of the fifty or so Apple employees who read MacTutor will respond. Your letter is being passed to Bob Denny, our Editorial Board member who is our resident AppleTalk expert. Take a look at Tops and MacServe as server products. -Ed]