Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!comp.vuw.ac.nz!waikato.ac.nz!ldo
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.sys.mac.hypercard
Subject: Re: HyperCard application memry requirements.
Message-ID: <1991Jan30.192213.2863@waikato.ac.nz>
Date: 30 Jan 91 06:22:13 GMT
References: <11910@goofy.Apple.COM>
Organization: University of Waikato, Hamilton, New Zealand
Lines: 32

In article <11910@goofy.Apple.COM>, gandalf@apple.com (Martin Gannholm)
responds to my suggestion about using the system heap for dynamically-
varying storage requirements under MultiFinder:

"Aaaargh! Sorry, no can do. There are enough things that use the system
heap but shouldn't. The solution under System 7.0 is to use MultiFinder
temp memory to hold document-specific information. HyperCard 2.0 even uses
temp memory if it is available, but before 7.0 the support for temp memory
isn't flexible enough to use it for a wider range of things. In 6.0.x
systems you should only use MF temp memory (that's temp as in "temporary")
for a very short time."
      ^^^^ ^^^^^ ^^^^

In that case, it's not a heckuva lot of use, is it? What do you suggest an
application do if it has ongoing (i e not transitory) memory requirements
that can vary *extremely* widely, depending on the data that it is called
on to handle?

Sorry, but I can only see two alternatives:
    a) have the user keep reconfiguring the memory partition and
       relaunching the program, or
    b) start putting things in the system heap.

By the way, under 7.0, is MultiFinder temporary memory automatically
deallocated for the application when it quits? If it isn't, then I
can't see much difference between the MultiFinder temporary heap
and the system heap.

Lawrence D'Oliveiro                       fone: +64-71-562-889
Computer Services Dept                     fax: +64-71-384-066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00