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