Nope, and here's the simple reason why: currently, an application
communicates with the system via the use of system calls and the Exec
Message interface.  An Exec Message consists of a header, and a data
section (simplified explanation, here).  That data section can be
anything the application (or the system library) desires.  In fact,
many of the current Messages pass pointers to memory as part of the
expected data section - and those pointers can point to memory the
*calling* task owns, and which the system can subsequently modify.
Or, for that matter, any other task - and *that's* the problem.

There has been no commonly-accepted way of specifying that a given
block of memory is private to the task.  MEMF_PUBLIC *might* have
been a way to do that, but because the definition of MEMF_PUBLIC has
always been ambiguous, many apps are *not* using it to indicate
"publicly accessible" memory.  And because there is no consistency
there, the possiblity (indeed, the certainty) that otherwise normal
Amiga operations will cross task-owned memory boundries utterly
prevents any reasonable memory protection scheme for applications
up to the present point.

Not only that, but with the current design, it's entirely possible
for a user application to modify *system* memory - and some hacks
depend on that ability, and protecting system memory is, perhaps,
the most important thing MP will give you.

--
Michael J. Farren                       far...@netcom.com

"Remember that good diction reflects so well on you, so practice all
 your vowel sounds by saying "AAAEEEEIIIIOOOOUUUUU!" - Animaniacs