On Sat, 30 Mar 1996, Allen Briggs wrote:

> Largely because the miniroot and the kernel both have to be loaded into
> memory before booting.  That's in addition to the system, finder,
> application, extensions, etc...  You could probably kick the hard limit
> up, but I don't want to distribute a miniroot larger than 1MB because a
> lot of macs only have 4-5MB of RAM...

Well, what about an adjustment in the setup menu on booter 1.9.1?  Ask
the system for the largest free block, subtract the memory for the kernel,
and add one of those up/down arrow things like the memory control panel
uses for virtual memory, with the max end set to the nearest meg less than
whatever's remaining.

Would that be possible, rather than a hard limit?  Or does it
try to load the miniroot while MacOS is still running and needs to
have the memory preallocated?

If the latter is the case, what about a second program that requests the
contiguous block, loads the miniroot into memory, passes the information
back to the main booter, and then quits when the operating system shutdown
(is it OSSD like under GS/OS?) is called.  That way it would still be
guranteed to be there unless the system software does something
excessively stupid when it gets uprooted... or would MacOS clear the
memory partition for the running program after it quit or something?

Thoughts?

 /---------------------------------------------------------------------\
|David A. Gatwood             And Richard Cory, one calm summer night,  |
|davagatw@mars              Went home and put a bullet through his head.|
|dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
|http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
 \---------------------------------------------------------------------/

BTW, I know about the date, but I'm not root on this system and can't set it.
Sorry.  Maybe I'll compile a patched pine to get its time & date somewhere
else....