Xref: utzoo comp.sys.mac:43395 comp.sys.mac.programmer:10854
Path: utzoo!attcan!uunet!samsung!shadooby!netnews.engin.umich.edu!news
From: billkatt@mondo.engin.umich.edu (billkatt)
Newsgroups: comp.sys.mac,comp.sys.mac.programmer
Subject: System Heap tirade (was Re: Resizing the System Heap)
Message-ID: <1989Dec3.181013.8659@caen.engin.umich.edu>
Date: 3 Dec 89 18:10:13 GMT
References: <1195@kl-cs.UUCP> <24663@cup.portal.com>
Sender: news@caen.engin.umich.edu (USENET News System)
Reply-To: billkatt@mondo.engin.umich.edu (billkatt)
Organization: Computer Aided Engineering Network (CAEN), University of Michigan
Lines: 24

Its that heap size time of year again...
Strictly speaking, system heap resizing is not necessary.  However, some INITs
done properly use the heap size reserving stuff.  There are three solutions
to this problem:
1.  Resize the heap by editing the boot blocks (this includes heap fixer, etc.)
    This is the worst idea.  It just eats RAM, and doesn't contract when you
    throw some of your INITs out.
2.  Throw the offending INITs out.  If an INIT is neato-keen, but buggy, you
    are probably better off without it.  It would also be handy to mail the
    person who wrote it and tell them to read IM-V5, startup manager and fix
    his/her code.
3.  Run under MultiFinder.  this is my personal favorite.  This system heap
    will resize larger and smaller to fit under MF.  This is necessary with
    some programs such as Timbuktu.

For the adventurous out there, you can try adding sysz resources to the INITs
that you are having trouble with.

It is possible to live with stupid INITs.  I currently have about a row and
a quarter on my Mac II, and I have no stability problems, whatsoever.

Lets all band together and boycott INITs which are obviously not up-to-spec.
INITs which are unstable reflect poorly on the Mac.
-Steve