Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!shebanow
From: shebanow@Apple.COM (Andrew Shebanow)
Newsgroups: comp.sys.mac.programmer
Subject: Re: ROM Unlocks handles (was Re: How to Argue Technical Points)
Message-ID: <5640@internal.Apple.COM>
Date: 6 Dec 89 21:02:53 GMT
References: <2744@dogie.macc.wisc.edu> <3838@atr-la.atr.co.jp> <32977@ucbvax.BERKELEY.EDU>
Organization: Apple Computer Inc, Cupertino, CA
Lines: 30

In article <32977@ucbvax.BERKELEY.EDU> oster@dewey.soe.berkeley.edu.UUCP (David Phillip Oster) writes:
>Alain, you have to understand "The Way od the Macintosh."  The ROM
>expects you to only lock down what you absolutely have to, and that for as
>short a time as possible.  To do otherwise is to risk running out of
>usable memory because of fragmentation.  if you use a style like:
>	HLock(handle);
>	OneSystemCall();
>	HUnlock(handle);
>or even better:
>	temp = (**hand).field;
>	SystemCall(&temp);
>	(**hand).field = temp;
>you'll never have to worry about the ROM unlocking things.


Ack! Please, please don't do this! If the system call expects a
Handle, you should never, ever pass it a fake handle. While your
technique will work on current Mac System Software, it will break
under System 7.0 if you are running in 32 Bit Mode. The new Memory
Manager doesn't store the handle flags in the high byte of the
Master Ptr anymore, so you will end up trashing your memory.

As far as it goes, there is (should be) very little code left in
the system which goes around unlocking things on you. Almost
everything has been fixed to use HGetState/HSetState.

For more info on this subject, see Tech Note 212 on 32 Bit Cleanliness.

Andrew Shebanow
MacDTS