🚀 go-pugleaf

>In article <1990Aug6.115552.14352@sisd.kodak.com> jeh@athena.sisd.kodak.com (Ed Hanway) writes:
>valentin@cbmvax (Valentin Pepelea) writes:
>>In article <2489@clinet.FI> dix@clinet.FI (Risto Kaivola) writes:
>>>
>>> 1)If the OS2.0 does not support the MMU upto the extent where all
>>>   application programs could run independently, i.e not corrupting other
>>>   programs' data, can you tell me what is the reason?
>>
>>Backward compatibility.
>
>As an intermediate step to full memory protection, why not just forbid read
>and write access to free memory?  This won't do a thing to stop programs
>from corrupting each other, but it might help catch the bugs that cause
>these problems.

   I believe the MMU is designed to handle fairly large chunks of memory at
at time, so on a system with badly fragmented memory, this might not work
very well?

   I've been considering that the system could provide us with some new
memory allocation calls, so that applications can ask for memory that is
protected _and_ virtual (and tracked?), though non-interchangeable with other
tasks.
   As the typical use of large amounts of memory is for uses within one task
rather than for intertask communications, this could provide an easy way for
DTP, Gfx, and other memory intensive programs to have unlimited, protected
memory in an easy way, and could hardly break anyone.

   Correct me if I'm letting my mind go wild.

                                 Have a nice day        -Henrik


--
|            Henrik Clausen, Graffiti Data (Fido: 2:230/22.33)           |
|           ...{pyramid|rutgers}!cbmvax!cbmehq!adspdk!hclausen           |
\__"Do not accept the heart that is the slave to reason" - Qawwali trad__/