Path: utzoo!censor!geac!torsqnt!lethe!yunexus!ists!helios.physics.utoronto.ca!news-server.csri.toronto.edu!cs.utexas.edu!uunet!zaphod!julius.cs.uiuc.edu!apple!applelink.apple.com!Jens
From: Jens@applelink.apple.com (Jens Peter Alfke)
Newsgroups: comp.sys.mac.programmer
Subject: Re: New memory allocation trap
Message-ID: <11729@goofy.Apple.COM>
Date: 15 Jan 91 20:20:47 GMT
References: <1991Jan15.010658.26241@watdragon.waterloo.edu>
Sender: usenet@Apple.COM
Organization: Apple Computer, Inc.
Lines: 25

In article <1991Jan15.010658.26241@watdragon.waterloo.edu> 
rnpantos@watdragon.waterloo.edu (Roger Pantos) writes:
>     How about creating a new trap that would allow applications to 
> allocate handle-based memory from the (dynamically-resizeable) 
> system heap? This would allow many programs to run with a minimal 
> "Multifinder partition", yet be able to get memory when they needed it. 

The problem with having an app deal with blocks in several different heaps 
is that many traps that operate on handles (or ptrs) require that the 
handle's heap be the current zone, so you have to do SetZone() before and 
after the call or take the chance of bombing. This scheme would also make 
it even easier for one application to corrupt another app's data. It would 
also reduce performance since the System heap would have so many blocks in 
it.
  No, the real solution is to give every app its own address space, using 
virtual memory. The app thinks it has gigabytes of space (or however 
much/little the user wants to restrict it to) but only the memory it 
allocates actually exists in RAM or on disk. No app can access memory 
belonging to the system or to any other app.
  This is the way real operating systems like Unix do it, and it works 
very well. It definitely will require some modifications to the way Mac 
applications work, though...

--Jens Peter Alfke
  Apple Computer