Path: utzoo!attcan!uunet!seismo!sundc!pitstop!sun!decwrl!ucbvax!agate!saturn!ucscb.UCSC.EDU!alibaba
From: alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg)
Newsgroups: comp.sys.mac.programmer
Subject: Re: StartUpScreens Eats Memory!?
Message-ID: <3269@saturn.ucsc.edu>
Date: 12 May 88 02:51:33 GMT
References: <22188@tis.llnl.gov> <9488@apple.Apple.Com> <1419@claris.UUCP> <3243@saturn.ucsc.edu> <9543@apple.Apple.Com>
Sender: usenet@saturn.ucsc.edu
Reply-To: alibaba@ucscb.UCSC.EDU (Alexander M. Rosenberg)
Organization: Univ. of California at Santa Cruz Hacker's Anonymous
Lines: 51

In article <9543@apple.Apple.Com> darin@apple.UUCP (Darin Adler) writes:
>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

Ok, so if a newer set of boot blocks are produced, will they take over and
load the picture? If this is true, then the bug can be fixed in the next release
right?

As for the actual nature of the bug, doesn't this all happen before any INITs
are loaded? If that is so, then it can be loaded, displayed, and then the
heap can be compacted. I don't see why this problem ever occured. It is clear
that this is a bug. Leaving the heap with an arbitrarily large size forces
the stack to be smaller. Bomb ID 28's must be more common. We all know that
many of our favorite applications do not manage their heap and stack spaces
properly. The system heap is supposted to be small. If it is stuck at a
larger than normal (i.e. after a SUS loadup) size, then the application
heap and the stack must be smaller. This is not good. Programs like PixelPaint
chew up memory, and memory is getting more expensive now. These programs
do not tolerate a large system heap very well, and they are important to Apple's
market penetration. Is somebody at Apple working on a fix for this? Is this
fixed in the B ROMs (Are they called B or what?)?

Inqiring minds wanna know. Can a quick fix INIT solve this problem by
recognizing that a certain quantity of the sys heap was used by a SUS, and
somehow order a compaction. (What is legit as for compaction on the sys heap?
Is there any _safe_ way?)

-------------------------------------------------------------------------------
-  Alexander M. Rosenberg  - INTERNET: alibaba@ucscb.ucsc.edu   - Yoyodyne    -
-  Crown College, UCSC     - UUCP:...!ucbvax!ucscc!ucscb!alibaba- Propulsion  -
-  Santa Cruz, CA 95064    - BITNET:alibaba%ucscb@ucscc.BITNET  - Systems     -
-  (408) 426-8869          - Disclaimer: Nobody is my employer  - :-)         -
-                          - so nobody cares what I say.        -             -