Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: System 7.0 Q & A
Keywords: Low Memory Globals
Message-ID: <7371@hoptoad.uucp>
Date: 19 May 89 19:31:37 GMT
References: <30353@apple.Apple.COM> <4666@okstate.UUCP> <1787@internal.Apple.COM> <7266@hoptoad.uucp> <13472@dartvax.Dartmouth.EDU> <7321@hoptoad.uucp> <30935@apple.Apple.COM> <811@key.COM>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 43

In article <811@key.COM> perry@arkon.key.COM (Perry The Cynic) writes:
>After watching this line of discussion for a while, I can't keep still
>any longer. Could somebody please explain to me WHY all the applications
>in a Mac with PMMU have to share their low-memory globals? Why not give
>each one a copy? (That's what the 2nd 'M' in PMMU is for, right? 'Mapping'?)

I believe that's what myself and others have been proposing.  The only
problem with it is that, if you'll look at the old Apple pages on low
memory globals by location (don't ask me for copies, I only have it on
paper) you'll see that system-invariant and application-switched
globals are mixed up on the same pages of memory.  Either all the
low-memory globals need to be made "unreal" (that is, they are filled
in for software by a special page fault handler), which is ugly, or
some of them will have to be decommissioned, causing some compatibility
problems.  I support the latter.

>As for the system heap now, that's a more difficult problem. A possible
>solution would be to split it into a 'clean' and a 'dirty' part; then share
>the 'clean' (i.e., readonly) part and copy the 'dirty' part for each
>application. Wastes some memory, but it's VIRTUAL memory now! Besides, even if
>the entire system heap needs to be copied for each application, I'd be quite
>willing to pay that price for protecting my applications from each other
>(and from my own stupidity :-).

There's very little reason for most applications to mess about with the
system heap except in read-only mode.  Those others can be given some
special flag to allow them to do it.  An updater utility to set the
flag would be under 20K, could readily be distributed over networks and
by hand, and would not count as a real upgrade cycle.  (However, I'm
about as sure as sure can be that most applications will have to do a
real upgrade with 7.0, just as they did with 6.0.)

>That leaves thingies like drivers that must muck around with the system's
>data. But those critters can trash any operating system (ask any UNIX victim).

Yeah, too bad.  Maybe some future Mac OS will figure out a way to
prevent this, at least in RAM.  Of course, any software that can diddle
hardware registers and take over at interrupt time has incredible
powers of destruction, so it'll never be really safe.
-- 
Tim Maroney, Consultant, Eclectic Software, sun!hoptoad!tim
These are not my opinions, those of my ex-employers, my old schools, my
relatives, my friends, or really any rational person whatsoever.