Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!dewey.soe.berkeley.edu!oster
From: oster@dewey.soe.berkeley.edu (David Phillip Oster)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking executable resources
Keywords: lock init executable patch
Message-ID: <29022@ucbvax.BERKELEY.EDU>
Date: 3 May 89 01:57:57 GMT
References: <4170@druco.ATT.COM>
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster)
Distribution: comp
Organization: School of Education, UC-Berkeley
Lines: 18

In article <4170@druco.ATT.COM> jon@druco.ATT.COM (GotowJK) writes:
_>This is because these inits show their 
_>icons, calling InitGraf in the process, and do not have the "locked" 
_>bit set on the INIT resources.  When my patch gets called, the INIT 
_>code gets moved (or purged) because I have a long beep sound installed, 
_>and the return address from the trap call is no longer valid.  Bingo - 
_>it executes an empty memory location after it hits the rts.  
_>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?  

It is simply incorrect to call system calls without locking your init. The
guys who try it are wrong. Write to the authors and complain.

YOu could always turn off the smashed stack checker, allocate memory above
BufPtr, configure it as a heap zone, make it the current zone, and run out
of it. That way, unlocked resources in the application heap wouldn't get
smashed.