Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!usc!cs.utexas.edu!uwm.edu!rpi!uupsi!sunic!kth.se!news
From: d88-jwa@nada.kth.se (Jon W{tte)
Newsgroups: comp.sys.mac.misc
Subject: Re: New MS Windows (?)
Message-ID: <1990Jun3.113433.18234@kth.se>
Date: 3 Jun 90 11:34:33 GMT
References: <15006@dime.cs.umass.edu>
Sender: news@kth.se  (News Administrator)
Reply-To: d88-jwa@nada.kth.se (Jon W{tte)
Organization: Royal Institute of Technology, Stockholm, Sweden
Lines: 44

In article <15006@dime.cs.umass.edu>, roskill@cs.umass.edu writes:
> In article <1990May31.072828.2220@portia.Stanford.EDU>,
aaron@jessica.stanford.edu (Aaron Wallace) writes...

> >does this with Win 2.xx.  I guess I'm unclear whether or not System 6 or 7
> >will support memory protection. I understood they didn't, but have
been lead to

> >others' bugs.  If System 6/7 do have this, is a PMMU needed?

> If I'm thinking of what you're thinking of...then no PMMU is needed.  But I
> hardly qualify as a mac memory expert.

Okay, let's get this straight:

System 7 gives us VIRTUAL memory. If we have a PMMU (the 68030 has it
built-in.) Virtual memory means you can set aside part of your hard disk
for paging, and the machine pretends this part of the disk is in-core
memory. Inactive parts of memory are stored on disk, while parts requested
by applications are loaded back into RAM. This is done in hardware and
completely transparent to the applications (but paging takes a little time
- you'll probably notice this when you switch apps in MultiFinder)

The RUMORED System 8 MAY have protected memory. Protected memory ALSO
requires a PMMU. This PMMU can be told that certain applications only
has write-access to certain parts of memory. If an application tries to
write outside these parts (due to a bug in the software, for instance)
this is caught, and the offending app is kicked out. This is so that
MS WORD doesn't stomp your ZTerm when it reads a corrupted file.

Protected memory on the mac is hard, though - the Window List, for one,
spans applicatino heaps, and some applicatinos tend to be awfully fond
of accessing the System Heap.

What I would do, if I were Apple, is to map all memory as readable, but
only your heap as writable. Then, if a write outside of this occured,
the trap function could check if this was reasonable, and grant/deny
access appropriately. Also, I would put in a status bit (much like
MF Aware) that enabled these features. Old apps would get write access
to their own heap AND the system heap - but not other applications heaps.
Yes, a compromise, but something to work from.


	Jon W{tte, Stockholm, Sweden, h+@nada.kth.se