Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!apple.com!cep
From: cep@apple.com (Christopher Pettus)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking executable resources
Message-ID: <1631@internal.Apple.COM>
Date: 2 May 89 17:45:26 GMT
References: <4170@druco.ATT.COM>
Sender: usenet@Apple.COM
Distribution: comp
Organization: Apple Computer, Inc.
Lines: 27

In article <4170@druco.ATT.COM> jon@druco.ATT.COM (GotowJK) writes:
> The segment loader locks CODE resources into memory before it jumps to 
> them.  Why are other executable resources (particularly INIT & cdev) 
> not automatically locked?

I know this sounds like begging the question, but it's because the segment 
manager doesn't load resources of type 'CODE'.  INITs, cdevs, etc. are 
loaded with plain, old, everyday resource manager calls that do not know 
they are loading code.  Its the responsibility of the code doing the 
loading to lock the code being loaded, a responsibility (judging from the 
rest of the post) that some code takes lightly.

> The dilemma is that this occurs because _somebody else's_ INIT resource 
> is not locked, and I can't control that.  This seems to be major 
> problem - or am I missing something?

I'm surprised that INITs are locking themselves down in memory; taking the 
chance that any trap calls they make won't compact memory seems pretty 
dicey.  The only thing you can do to help is make sure that you're patch 
won't compact memory if the trap being patched doesn't.  This will help 
guard against people playing "close to the edge" with unlocked handles.

-- Christopher Pettus                   | "Brahma said: Well, after hearing
   Network Systems Development          | ten thousand explanations, a fool
   Apple Computer, Inc.                 | is no wiser.  But an intelligent
   cep@apple.com   {nsc, sun}!apple!cep | man needs only two thousand five
   AppleLink: PETTUS.C                  | hundred."  -- The Mahabharata