🚀 go-pugleaf

I've had several thoughts on this subject and here are mine...

There is a big difference between virtual memory and process
protection.  In a lot of ways, virtual memory is easier since much
fewer things will have problems with it.  Well, heres some thoughts on
some topics.

MEMF_PUBLIC:

This has to be the most misused and abused flag on the Amiga system.
Many programs use it to say give me CHIP or FAST, even though 0L does
that.  Many programs dont use it at all.  Many programs (as mentioned
before) do things like use static structures, auto variables, etc. for
public things.  I think the best thing is to give a some new flags so
programmers can start using them and then provide a manager to turn on
and off default behavior (preferably for individual programs) to catch
bugs and make existing things work.  Have a combination of things like
PUBLIC/PRIVATE/SYSTEM where public is ANY task, system in OS tasks
only, and private is forced private (to override defaults).  Also have
flags for READ/WRITE/READWRITE etc.

System calls:

Remember that many calls that deal with shared messages like
Do/Send/BeginIO(), Get/PutMsg(), etc, execute in the callers context,
so they can be patched to set up privleges/access correctly in a
protected environment.  The message structure itself can be patched
for R/W access by the system.  Based on the system calls, it can be
known whether buffers are read only or read/write, etc.

Address Space:

I strongly belive that a shared address space is best for the Amiga.
Just about EVERYTHING on the Amiga is some form of pointer linked
structures.  Using independant memory spaces makes this difficult to
nearly impossible.  Unix programmers know this problem having to deal
with things like forcing data structures into arrays, etc.

Implementation:

Set the standards NOW.  Provide the hooks to support it NOW.  Provide
the tools to control it to users NOW.  Enforce the behavior LATER.
This way developers can began to fix software to support it using
known standards, developers and advanced users can try it, find
problem software, and make existing software work with temporary
fixes.  Most programs will require only small changes make things
work.  Update compilers to provide support for the new features.  Add
keywords like private, public, etc to suppplement chip.

Lots of the previous suggestions make sense.  Patch LoadSeg() to fix
up hunks in memory.  Make code Read only, data can be set to default
to read only or read write, or private to catch problems.  Giving
system routines full read/write access will solve most problems for
now.

Leave current behavior as the default, so users will continue to have
the machine work the same way.  
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mark Gooderum			Only...		\    Good Cheer !!!
Academic Computing Services	       ///	  \___________________________
University of Kansas		     ///  /|         __    _
Bix:	  markgood	      \\\  ///  /__| |\/| | | _   /_\  makes it
Bitnet:   MARKV@UKANVAX		\/\/  /    | |  | | |__| /   \ possible...
Internet: markv@kuhub.cc.ukans.edu
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~