Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!att!mtuxo!mtgzz!drutx!druco!jon From: jon@druco.ATT.COM (GotowJK) Newsgroups: comp.sys.mac.programmer Subject: Locking executable resources Keywords: lock init executable patch Message-ID: <4170@druco.ATT.COM> Date: 1 May 89 19:29:05 GMT Distribution: comp Organization: AT&T, Denver, CO Lines: 34 The segment loader locks CODE resources into memory before it jumps to them. Why are other executable resources (particularly INIT & cdev) not automatically locked? Sure, you can set the "locked" bit on the resource so it loads as a locked handle, but should that really be necessary? Why not make it automatic? Here's why this concern arose: I wrote a quick patch to _InitGraf that simply beeps and then calls the real ROM code. Simple, right? Except that it crashes on startup when other inits load afterwards. 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? I really would like to do much more that just beep in my patch code, obviously. This simple example is good enough to illustrate the point, however. Any comments will be much appreciated. ------------------------------------------------------------------------ Jon Gotow - Physical Designer AT&T Bell Labs General Business Systems Group 200 Laurel Avenue ARPA: jon@druco.att.com Middletown, NJ 07748 UUCP: att!druco!jon Disclaimer: As always, the opinions stated here have nothing whatsoever to do with my employer.