At 11:05 AM 4/7/96, Ken Nakata wrote:
>> > _NewPtr(SysClear) and _DisposPtr are already supported by MRG.  I
>> > figured _HLock isn't a problem since nobody messes around anybody
>> > else's memory under NetBSD.
>>
>> Yeah, well it may be important.
>
>No, nobody moves anybody else's memory blocks under NetBSD, so
>basically any block is always "locked".

Danger, Will Robinson!!  Paradigm shift ahead!

The Mac is a single-user machine so there *never* *was* anyone else to mess
with memory (unless you were in an interrupt routine, in which case messing
with memory was prohibited).  The issue is that some toolbox calls changed
memory on you as a side effect.  Simply allocating some memory might do
this because the memory manager would move things to avoid encroaching on
possible stack expansion space.  Simply doing a subroutine call might do it
because the routine might be in a different code resource which would have
to be read in (and space would have to be allocated to read it into. . .).

IMNSHO the old memory manager was a major reason for porting problems
to/from other platforms.  Improper use/understanding of it was also a major
source of bugs in Mac software.  (I understand the Modern Memory Manager on
the PowerMac is more rational.)

Anyway, my point is that some care should be taken in reimplimenting the
*Handle routines.  They would go to excessive lengths to avoid memory
fragmentation and driver code that allocated space in a
fragmentation-inducing order could possibly stop working, or at least waste
a lot of space, if we don't implement all the "features."

I assume the code we are talking about writing is going to be wired down so
space is at a premium.

>> > It seems to me that _ResrvMem could be just a stub routine, too, since
>                       ^*emulated* (I left this out... sorry)
>> > it doesn't seem to really allocate anything.
>>
>> But it moves around memory in preparation...
>
>Under MacOS, okay.  But under NetBSD, since nobody moves any allocated
>memory blocks, do you need it?  I think not.

See above.

>> Basically, handles are pointers to pointers, but those first pointers are
>> located in the master pointer records (see MoreMasters...) and contain
>
>Yeah, because MacOS moves blocks around?  Which isn't the case for
>NetBSD...

Yet.

I shouldn't overstate the problem.  We only have a few driver routines
doing stuff, not the full System 7 Finder.  By all means try a simple
approach to replacing the *Handle routines first, but keep an eye on memory
use and fragmentation as possible sources of problems.

If any developer wants a copy of the memory manager chapter from Inside Mac
I, let me know.  (I think that would be covered by the Fair Use doctrine.)
It's pretty fundamental to how the old Mac stuff worked.

Signature failed Preliminary Design Review.
Feasibility of a new signature is currently being evaluated.
hotz@binky.jpl.nasa.gov, or hbhotz@oxy.edu