Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!ll-xn!ames!amdahl!apple!darin
From: darin@Apple.COM (Darin Adler)
Newsgroups: comp.sys.mac.programmer
Subject: Re: StartUpScreens Eats Memory!?
Message-ID: <9543@apple.Apple.Com>
Date: 11 May 88 22:16:05 GMT
References: <22188@tis.llnl.gov> <9488@apple.Apple.Com> <1419@claris.UUCP> <3243@saturn.ucsc.edu>
Reply-To: darin@apple.UUCP (Darin Adler)
Organization: Apple
Lines: 20

In article <3243@saturn.ucsc.edu> alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg) writes:
> ... Since the boot blocks on disks have the filename to
> load in them, we must assume that the startupscreen loader is contained in
> the boot blocks of the startup drive. ...

This is not true. The file name from the boot blocks is used, but the boot code
in the Mac does not execute the boot code in the boot blocks UNLESS the version
field is new enough. The boot code that is currently used (including the part
that loads/displays the picture) is in the Mac II ROMs.

Note that the bug is doesn't have to do with reclaiming space in the system
heap. The problem is that the system heap grows to a size big enough to contain
the picture, and it can only grow, not shrink. Thus, the space is reused by any
other code that uses the system heap, but will never be used as part of the
application heap. This is all without MultiFinder...I don't know exactly what
the differences are with MultiFinder, although I seem to recall that it does
have a mechanism for shrinking (as well as growing) the system heap on the fly.
-- 
Darin Adler						AppleLink:Adler4
UUCP: {sun,voder,nsc,mtxinu,dual}!apple!darin	  CSNET: darin@Apple.com