🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.sys.amiga.tech
Article #3112

Re: Amiga Resource tracking & Protection.

#3112
From: markv
Date: Wed, 28 Mar 1990 17:57
58 lines
3803 bytes
Some thoughts I had on this a long time ago...

Why not take a similar route to Protected mode applications that OS/2
and AIX use to run DOS appls.  (Hold the groans...)

Implement protected mode programs as being protected by virtue of
their assumption that all memory is not theirs.  All the calls like
PutMsg(), GetMsg(), and other things could be written using a new exec
library that understands memory protection (and virtual memory).  So
you would have some new memory flags like:

MEMF_VIRTUAL	-VM, the default for 'new' applications
MEMF_PRIVATE	-Memory private to your task.
MEMF_SYSTEM	-Memory shared with the system, but not other tasks.
MEMF_SHARED	-(MEMF_PUBLIC is taken and abused) open memory.
MEMF_NOSWAP	-Things like interuppt handlers, no VM swapping

etc.  You get the idea.  You could also expand the model to
distinguish read and write access (for instance GfxBase, etc).  A
"protected mode" program would get all its segments loaded in private
ram (or whatever ram the hunk is flagged for assuming the compliers,
linkers, and loaders support the new flags).  Functions would be used
for all message passing and other interactions with the system and
other tasks.  On MMU amigas there would be an exec.library that
supported and used VM and protection.  On non-MMU Amigas the functions
would still work, they would just be implemented non-protected.  So
most protected programs would still run on normal Amigas (assuming
they don't need to malloc 6 megs or similar things).

On MMU Amigas, the system and protected applications would each run in
their own protected space.  For non-protected applications, you could
use the concept of a 'virtual machine'.  Exec would hang out enough of
the operating system to pretend to be an old style amiga and un
protected applications would run togather in a shared protected space.
So a crashing non-protected program would crash other non-protected
programs running in this "compatibility box" but the 'real' Exec and
protected applications would continue on.  You could have several
options for the "compatibility box" to control its behavior like
wether AllocMems() default to MEMF_VIRTUAL, handing over certain
register address spaces to the compatibility box (and protecting the
rest) and assume they need to be re-initialized when they're returned,
etc.

"Most" Amiga programs would continue to run because most Amiga
programs DONT scribble all over registers.  Their only problem is the
assumption that they run in a shared address space and can access
certain system structures for information (like IntuitionBase,
GfxBase, and ExecBase being the most common).  The real hacks would
break, but they tend to break every new OS release or hardware change anyways.
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Technical Details
Message-ID: <22629.2610a690@kuhub.cc.ukans.edu>
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!wuarchive!kuhub.cc.ukans.edu!markv
References: <208.25f3c82b@waikato.ac.nz> <1410044@hpcvca.CV.HP.COM> <19460@grebyn.com> <492e3b6e.1a5bf@moth.engin.umich.edu> <CIMSHOP!DAVIDM.90Mar14103110@uunet.UU.NET>

Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!utzoo!attcan!uunet!cs.utexas.edu!wuarchive!kuhub.cc.ukans.edu!markv
From: markv@kuhub.cc.ukans.edu
Newsgroups: comp.sys.amiga.tech
Subject: Re: Amiga Resource tracking & Protection.
Message-ID: <22629.2610a690@kuhub.cc.ukans.edu>
Date: 28 Mar 90 17:57:04 GMT
References: <208.25f3c82b@waikato.ac.nz> <1410044@hpcvca.CV.HP.COM> <19460@grebyn.com> <492e3b6e.1a5bf@moth.engin.umich.edu> <CIMSHOP!DAVIDM.90Mar14103110@uunet.UU.NET>
Organization: University of Kansas Academic Computing Services
Lines: 58