🚀 go-pugleaf

In article <17134@cbmvax.commodore.com> jesup@cbmvax.commodore.com (Randell Jesup) writes:
>In article <1991Jan5.200226.19718@msuinfo.cl.msu.edu> dailey@frith.uucp (Chris Dailey) writes:
>>Even fake memory protection would due for many of us.  How about a
>>command like "run such and such a program so it doesn't touch anything
>>other than the OS".  It gets its own space, tucked away from the rest of
>>the system?
>
>	The problem is defining "it's own space".  What is part of the OS,
>and what is part of an App?  What if an "application" (let's say Mount)
>allocates a data structure and adds it to a system list?

One thought I had for a sort of compromise is a PD library of MMU routines
that programs could use to protect themselves, especially during the devel-
opment stage, but optionally as commercial products as well.  The MMU library
would provide replacements or patches for various AmigaDOS calls to allow
programs to specifically decide what areas of memory they have access to as
well as what areas of their memory they want to protect.  Programs that are
written without the MMU libraries would function normally, with full permission
to trash one another's memory.  This would be considerably easier to implement
than "real" memory protection, since applications that use the MMU functions
could be considered trustworthy.  Its purpose would be to provide a reliable
means to debug programs and prevent or contain crashes.  If the library 
defaulted to standard non-MMU system calls on machines that don't have an MMU,
developers would have to reason to remove the code once development finishes,
so eventually there would be many programs available with MMU support.

Of course, this would still be a substantial project, but I think the benefits
would be great.

-brett


-- 
|Brett Coon           |  uunet!smosjc!brett                       |
|S-MOS Systems, Inc.  |  "Very exciting... as a luggage problem." |
|San Jose, CA         |            -Joe Vs. The Volcano           |