Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!wuarchive!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!sol.UVic.CA!marykuca From: marykuca@sol.UVic.CA (Brent Marykuca) Newsgroups: comp.sys.mac.programmer Subject: Re: Why do application partitions exist? Message-ID: <1991Feb6.085236.15677@sol.UVic.CA> Date: 6 Feb 91 08:52:36 GMT References: <1991Feb5.182501.4325@wam.umd.edu> Sender: marykuca@sol.uvic.ca (Brent Marykuca) Organization: University of Victoria, Victoria B.C. CANADA Lines: 40 In article <1991Feb5.182501.4325@wam.umd.edu> nebel@wam.umd.edu (Chris D. Nebel) writes: [ Some stuff about a late-night thought concerning putting all applications into one big heap zone ] >The only problem I could think of was that the system has to know who created >which blocks, so it can know what to throw away when a program quits >("unexpectedly" or otherwise). It seems to me, though, that this would be >fairly easy to do, and it wouldn't break anything that didn't use fake handles >or rely on the format of block headers, which they shouldn't have been doing >anyway. > >Since this scheme is obviously :) so much better and is trivial :) :) to >implement, why wasn't it done? Am I missing something obvious? > >Chris Nebel >nebel@wam.umd.edu Wow, Chris, you got me thinking there. Here's a problem: The stack. Where would you put them all (one for each application)? I suppose you could allocate some arbitrary maximum stack space in a nonrelocatable block somewhere, but then you run into the situation where a stack overflow could write into another application's (or the OS's) memory. At least with a multifinder partition you only destroy your own data :) Still, there doesn't seem to be any compelling reason why your scheme is absolutely going to fail. My guess is that the true answer to the question "why wasn't it done" probably boils down to something like "Because that's the way Switcher did it." Cheers, Brent -- Brent Marykuca (marykuca@sol.UVic.CA) Apple Research Partnership Program Computing User Services