Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!claris!apple!lsr From: lsr@apple.UUCP (Larry Rosenstein) Newsgroups: comp.sys.mac Subject: Re: Question about WDEF routines. Message-ID: <7132@apple.UUCP> Date: 5 Jan 88 18:45:32 GMT References: <7595@sunybcs.UUCP> <7126@apple.UUCP> <3709@husc6.harvard.edu> Reply-To: lsr@apple.UUCP (Larry Rosenstein) Distribution: na Organization: Advanced Technology Group, Apple Computer Lines: 37 In article <3709@husc6.harvard.edu> olson@endor.UUCP (Eric K. Olson) writes: > >If you have a compiler that can specify code segments (LSC, for example), >move the WDEF code into a segment of its own and do a GetResource('CODE',id) >and a DetachResource of the returned handle. This gives you a private >copy of the code, referenced as a handle. Detaching it ensures that it will >not be mucked with by the segment loader or resource manager. You may also >need to HNoPurge the handle, depending on how it is flagged in the resource >file. There is supposed to be a 4 byte segment header in each CODE segment (indicating the location and number of jump table entries). Do you do something special to get around this? It is possible that for your programs, these 4 bytes ended up being 68000 instructions that don't do anything harmful. (For example, small 2-byte numbers are OR.B instructions.) As long as you don't have too many jump table entries, it should be benign. Ignoring this problem, you should not have to detach the segment. The Window Manager calls LoadResource to ensure that the WDEF is loaded into memory before calling it, so even if the segment is purged everything will work. If you DO detach it, then you will have to call HNOPurge, because it won't be a resource and LoadResource won't do anything with it. In MPW, it would be better to read the resource in by name, since then you don't have to depend on the ID remaining constant. The MPW linker, by default, names the resource the same as the segment. -- Larry Rosenstein Object Specialist Apple Computer AppleLink: Rosenstein1 UUCP: {sun, voder, nsc, mtxinu, dual}!apple!lsr CSNET: lsr@Apple.com