rick@ut-emx.UUCP (Rick Watson) (04/05/88)
1. I'm using LightSpeed C to produce a CODE resource. I don't want the glue that the linker sticks on the front of the resource. Is there any way to prevent the glue from getting stuck on in the first place? I'd rather not have to write a routine to strip it back off. Or, is there anyway to get the linker to use my glue instead of theirs? 2. Failing the above, is the source to their glue anywhere? 3. Actually, what I'm doing is converting a SCSI disk driver written in Megamax C to LSC. I need the structure of the code to be something like: JMP INSTALLER DRIVER HEADER (0X4F00, ETC) DRIVER CODE INSTALLER CODE without any LSC glue at the front. Any ideas? Many thanks, Rick Watson University of Texas Computation Center arpa: ccaw001@utadnx.cc.utexas.edu uucp: ...seismo!ut-sally!ut-emx!rick bitnet: ccaw001@utadnx span: utspan::watson phone: 512/471-3241
leonardr@uxe.cso.uiuc.edu (04/05/88)
rick@ut-emx.UUCP(Rick Watson) writes in comp.sys.mac.programmer >1. I'm using LightSpeed C to produce a CODE resource. I don't want the >glue that the linker sticks on the front of the resource. Is there >any way to prevent the glue from getting stuck on in the first place? >I'd rather not have to write a routine to strip it back off. Or, is there >anyway to get the linker to use my glue instead of theirs? > As of version 2.15 of Lightspeed C there was no way to either leave their header (glue) off, or use your own insted. However, version 3.0 (whebn it arrives) will allow you to do this. So you can always wait. the other option is to read Earle Horton's article in MacTutor where he describes all the fun he went through to solve this problem for his Printer Driver. >2. Failing the above, is the source to their glue anywhere? > Somewhere in Mass. at the offices of Think Technologies/Symantic Corp. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + + + Delphi: MACgician + + + + + +---------------------------------+-----------------------------------+
dplatt@coherent.com (Dave Platt) (04/09/88)
In article <1569@ut-emx.UUCP> rick@ut-emx.UUCP (Rick Watson) writes: > 1. I'm using LightSpeed C to produce a CODE resource. I don't want the > glue that the linker sticks on the front of the resource. Is there > any way to prevent the glue from getting stuck on in the first place? > I'd rather not have to write a routine to strip it back off. Or, is there > anyway to get the linker to use my glue instead of theirs? According to an article in the April issue of MacTutor, the glue for code resources is stored in the LightSpeed C application in CODE resource number 11; it can be patched (according to Mike Kahl, the author of LsC). You could try hacking this resource as needed in a !COPY! of your LightSpeed C application, and then recompiling and relinking the CODE resource. -- Dave Platt VOICE: (415) 493-8805 USNAIL: Coherent Thought Inc. 3350 West Bayshore #205 Palo Alto CA 94303 UUCP: ...!{ames,sun,uunet}!coherent!dplatt DOMAIN: dplatt@coherent.com INTERNET: coherent!dplatt@ames.arpa, ...@sun.com, ...@uunet.uu.net
rs4u+@andrew.cmu.edu (Richard Siegel) (04/09/88)
I believe that in the next version of Lightspeed (and please don't ask me when!) there will be an option to not stick on the header at the beginning. The source isn't available - it's stuck in automatically; the description 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. If this really bothers you, you can ResEdit the header out, otherwise, don't let it worry you. --Rich
lsr@Apple.COM (Larry Rosenstein) (04/12/88)
In article <wWLMm1y00XM3444l1k@andrew.cmu.edu> 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
singer@endor.harvard.edu (Jon Hueras) (04/12/88)
In article <7950@apple.Apple.Com> lsr@apple.UUCP (Larry Rosenstein) writes: >In article <wWLMm1y00XM3444l1k@andrew.cmu.edu> 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