Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!hc!lll-winken!uunet!munnari!jkjl
From: jkjl@munnari.oz (John Lim)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Locking executable resources
Keywords: lock init executable patch
Message-ID: <2758@munnari.oz>
Date: 10 May 89 04:22:57 GMT
References: <4170@druco.ATT.COM> <1591@hub.ucsb.edu> <1476@murtoa.cs.mu.oz.au> <21859@santra.UUCP>
Reply-To: jkjl@munnari.UUCP (John Lim)
Distribution: comp
Organization: Comp Sci, Melbourne Uni, Australia
Lines: 43

In article <21859@santra.UUCP> jmunkki@kampi.hut.fi (Juri Munkki) writes:
-In article <1476@murtoa.cs.mu.oz.au> jkjl@munmurra.UUCP (John Lim) writes:
->You do not have to lock any executable resource if you are
->not calling code that will move handles in the *same* system heap.
-						^^^^^^^
-						Not strictly true. :-)
-
-How do you know that allocating a block from the system heap will not
-cause changes in the application heap? You think it doesn't happen,
-but how can you be sure? I'm pretty sure you are correct in assuming
-this, but since Apple doesn't say anything about the affected zones,
-it might change in the future! Never assume anything.
-

I agree it might change in the future, but the point i'm making
is that you dont have to lock code resources down today. Of course
defensive programming means you should lock down such resources even
if you're confident nothing will change in the future.

->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 
-
-It was relatively easy to predict what would happen to MacTutor
-after a few years. It was a very good magazine for the first two
-or three years, but after that the technical quality of most of
-the articles has declined. However: I don't think that calling
-the authours "idiots" will help the magazine. Simply point out
-the bugs and leave out the insults. Insulting people is a very
-good way of making enemies.
-

Point taken. Apologies to everyone insulted by my previous remarks.

-
-As to the question of locking or not locking: It doesn't take any
-extra code to lock down your INITs. Why not do it?
-

I do lock my INITs. But if you dont call any memory moving traps,
i dont think you should have to lock code resourcse.

	john