Path: utzoo!mnetor!uunet!husc6!endor!singer From: singer@endor.harvard.edu (Jon Hueras) Newsgroups: comp.sys.mac.programmer Subject: Re: LSC and CODE resources Message-ID: <4357@husc6.harvard.edu> Date: 12 Apr 88 03:16:19 GMT References: <1569@ut-emx.UUCP> <7950@apple.Apple.Com> Sender: news@husc6.harvard.edu Reply-To: singer@endor.UUCP (Jon Hueras) Organization: Symantec/THINK Technologies, Bedford, MA Lines: 65 In article <7950@apple.Apple.Com> lsr@apple.UUCP (Larry Rosenstein) writes: >In article rs4u+@andrew.cmu.edu (Richard Siegel) writes: >> >>is on pages 9-13 to 9-15 of the user's guide. All the glue does is >>place the handle to the code resource in ToolScratch and then jump >>to the beginning of the real code. > >By the way, the article in the April MacTutor on floating windows talks about >the use of ToolScratch by the Menu Manager and LSC. It was wrong when it >blames the Menu Manager for using the location. ToolScratch is reserved for >use by the Toolbox; its value is not preserved across calls to the ROM. > >-- > Larry Rosenstein, Object Specialist > Apple Computer, Inc. 20525 Mariani Ave, MS 27-AJ Cupertino, CA 95014 > AppleLink:Rosenstein1 domain:lsr@Apple.COM > UUCP:{sun,voder,nsc,decwrl}!apple!lsr I'd like to take exception to this line of reasoning. NOWHERE does it say that ToolScratch is reserved for ROM use only. ALL it says is exactly what you said: "its [sic] value is not preserved across calls to the ROM." If you use the value the LSC code resource header puts in ToolScratch as it is intended, you fetch the value immediately upon entry into 'main' and pass it to 'RecoverHandle' to get a handle to the resource so you can lock it. By the time you call RecoverHandle, you are no longer depending upon the value of ToolScratch. No ROM calls intervene, and so the value is unchanged when you get it. The problem is that the Menu Manager, in using ToolScratch as parameter storage (I forget for which one), is violating this rule to the hilt. Who's to say what ROM calls a Menu DefProc may make before it ever gets around to referencing this parameter. It just so happens that the STANDARD Menu DefProc never calls a routine that affects ToolScratch; but why should Apple, who has made it possible for OTHERS to write Menu DefProcs of their own, then leave a gaping hole for them to fall into! This is not the first time I have encountered this sort of thing. I once discovered, inadvertantly, that the Finder uses Scratch20 as a EventRecord in calling GetNextEvent. Scratch20 is another low-mem area that falls into the same category as ToolScratch - it's not expected to remain the same across ROM calls, but it is NOWHERE declared as reserved for Apple use only. Although the Finder's usage conflicted with what I wanted to do with Scratch20, my usage was in kind of a gray area and so I backed off and did something else. But I did not fail to note that the Finder's use of Scratch20 in this way potentially conflicted with the legitimate use of it by other software, namely DAs! Any call to GetNextEvent may result in the invocation of DA code if GetNextEvent (via SystemEvent) determines that a particular event belongs to a DA. If the DA tries to use Scratch20 in a legitimate way (i.e., for temporary storage while doing something that doesn't involve ROM calls), it's going to be awfully upset when it finally tries to get at that EventRecord, which it has just munged when it wrote to Scratch20. However farfetched this particular example may seem, the moral remains: in software, rules are NOT made to be broken. As a historical note, the use of ToolScratch by LSC code resources is strictly a vestigial feature from the days prior to the introduction of inline assembly, which makes it totally unnecessary. We hesititate, however, to take it out for fear of breaking other people's software that may depend on it. We, at least, take our documentation seriously. Jon Hueras Symantec/THINK Technologies