Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!comp.vuw.ac.nz!virtue!ccc_ldo
From: ccc_ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Why does the System not lock my INITs ?
Message-ID: <1195.26c1b5c3@waikato.ac.nz>
Date: 9 Aug 90 07:13:07 GMT
References: <157@neptune.inf.ethz.ch> <43741@apple.Apple.COM>
Organization: University of Waikato, Hamilton, New Zealand
Lines: 22

As to why the system doesn't lock INITs before executing them:

What happens if the INIT wants to stay in memory after execution?
Some people may load resident code by creating a new non-resource block
and copying the code to there, but others could just do a DetachResource
on the INIT, and leave it locked. There's no good way that I can think
of that the system can allow for the possibility of a DetachResource
call while handling the locking/unlocking of the INIT code itself.
You could do a Resource Manager call (for example, a dummy LoadResource)
to check if the handle is still a resource handle, but the time
overhead to do this with every INIT is probably too much.

The code that executes FKEYs, just as a contrasting example, does
lock the resource down before execution, and unlocks it after.
Nobody expects an FKEY to install itself permanently in memory
after execution...

Lawrence D'Oliveiro                       fone: +64-71-562-889
Computer Services Dept                     fax: +64-71-384-066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00
If God's handiwork is so good, why doesn't she give a warranty?