Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!apple!rpd
From: rpd@Apple.COM (Rick Daley)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking executable resources
Message-ID: <1635@internal.Apple.COM>
Date: 2 May 89 19:32:58 GMT
Organization: Apple Computer Inc., Cupertino, CA
Lines: 27

In article <4170@druco.ATT.COM> jon@druco.ATT.COM (GotowJK) writes:
> > 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?  

lsr@Apple.com (Larry Rosenstein) writes:
> An important rule in patching traps is that your patch code has to be at 
> least as careful as the trap being patched with respect to allocating 
> memory and saving registers.
> ...
> In your case, InitGraf doesn't allocate memory, but SysBeep does.  So 
> technically, you are "in the wrong."  (On the other hand, those INIT 
> should be locking themselves down.)

Actually, InitGraf is now on the list of routines that may compact
memory.  This is documented in Inside Mac V, as the change was part
of Color QuickDraw.  It's possible that the INITs that are crashing
are old, and didn't expect that InitGraf would cause compaction.
But, it's more likely that the authors just didn't realize that INITs
aren't locked when they get run.  The system is pretty inconsistent about
locking executable resources when they are getting run.  So, folks should
keep this in mind when writing executable resources.  As for the original
problem, jon@druco.ATT.COM is just out of luck.  He's not doing anything
wrong, but he can't patch InitGraf with something that causes memory
allocation without risking breaking these INITs.
					Rick Daley
					rpd@apple.com