🚀 go-pugleaf

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