Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!samsung!noose.ecn.purdue.edu!dirac!gibbs.physics.purdue.edu!sho
From: sho@gibbs.physics.purdue.edu (Sho Kuwamoto)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: re^4:what to buy??(numbercruncher)
Message-ID: <5333@dirac.physics.purdue.edu>
Date: 21 Jun 91 18:50:22 GMT
References: <76@ryptyde.UUCP> <1991Jun20.160839.28053@mintaka.lcs.mit.edu> <82@ryptyde.UUCP>
Sender: news@dirac.physics.purdue.edu
Organization: Purdue Univ. Physics Dept, W.Lafayette, IN
Lines: 34

In article <82@ryptyde.UUCP> dant@ryptyde.UUCP (Daniel Tracy) writes:
>>  Question: Why do you have to specify a size to the Mac OS? What's
>>the point?"
>
>I believe I understand the difference now. Amiga applications take memory
>dynamically as they need it. Macintosh applications, having been bred in
>a single-tasking environment, instead check how much memory is available
>and use it all. Under Mac Multitasking, you tell the OS how large a 
>contiguous chunk to give the application. Then when the application checks
>to see how much memory it has, it gets returned a value proportional to how
>much you specified. Interesting. Am I right?

Sort of.  Applications don't assume they hog the whole machine, but
the memory manager has a hard time with non-contiguous space.  This is
because the mac uses relocatable chunks of memory.  I don't see why
that *must* be so.  I can see that using non-contiguous space would be
inefficient as hell, but I don't see why it would be impossible.  If
all blocks stayed put, that's a different story.

Ok.  Now for the flip side.  If you need more memory than you have,
you can make a call to the OS to allocate memory outside your
application zone.  This area should only be used for temporary
storage, but it helps out a lot.  For example, the Finder uses
temporary memory to buffer while copying files.  Once the file copying
is done, it lets go of the memory.

It's not transparent to the programmer, but it's not horrible, either.
All you need to do is to call TempNewHandle() instead of NewHandle().
In addition, you can afford to give applications more space with
virtual memory.  It's not ideal, but it is a step in the right direction.

-Sho
-- 
sho@physics.purdue.edu