Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!munnari!murtoa.cs.mu.oz.au!munnari.oz!jkjl
From: jkjl@munnari.oz (John Lim)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking executable resources
Keywords: lock init executable patch
Message-ID: <1476@murtoa.cs.mu.oz.au>
Date: 8 May 89 08:36:07 GMT
References: <4170@druco.ATT.COM> <1591@hub.ucsb.edu>
Sender: news@cs.mu.oz.au
Reply-To: jkjl@munmurra.UUCP (John Lim)
Distribution: comp
Organization: University of Melbourne, Comp Sci Dept
Lines: 30

In article <1591@hub.ucsb.edu> doner@hub.UUCP (John Doner) writes:
>like a bug to me.  I would think that *any* executed block should
                                       ^^^^^^
                                       Not strictly true.
>be locked before being jumped to.
>
>John Doner
>doner@hub.ucsb.edu

You do not have to lock any executable resource if you are
not calling code that will move handles in the *same* system heap.

I.e.
	INIT that is unlocked is launched into appl heap.
	Allocates block in system heap and BlockMoves patches
	into block.
	SetTrapAddress to block in system heap.
	RTS to INIT 31.

Note that the above code should work provided you do not call
any Traps that move mem (read IM 3,4,5 appendices !). All inits
should never install patches that move mem on traps that arent 
supposed to move mem.

I have seen several articles in MacTutor that are fairly
laughable concerning VBL tasks. The idiots use GetCursor()
and GetIcon() in the VBL tasks which move memory during interrupts 
(a no-no).

	John Lim