Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!thunder.mcrcim.mcgill.edu!snorkelwacker.mit.edu!mintaka!think.com!spool2.mu.edu!uunet!comp.vuw.ac.nz!actrix!templar!jbickers
From: jbickers@templar.actrix.gen.nz (John Bickers)
Newsgroups: comp.sys.amiga.advocacy
Subject: Re: How do we change the scheduler? (Was Re: Multitasking at home...)
Message-ID: <10851.tnews@templar.actrix.gen.nz>
Date: 30 Jan 91 23:43:09 GMT
References: <1991Jan18.231330.16290@Neon.Stanford.EDU> <7553@sugar.hackercorp.com>     
 <1991Jan21.004720.25985@ncsuvx.ncsu.edu> <12880@life.ai.mit.edu>     
 <1991Jan21.072642.23587@Neon.Stanford.EDU> <10620.tnews@templar.actrix.gen.nz>  <1991Jan22.215801.4557@Neon
Organization: TAP, NZAmigaUG.
Lines: 34

Quoted from <1991Jan27.214435.15976@Neon.Stanford.EDU> by torrie@cs.stanford.edu (Evan J Torrie):
>   Just as a matter of interest, it seems to me that this design would
> be somewhat difficult to graft virtual memory/memory protection onto
> without some serious backward compatibility problems...  
>   Has anyone thought about adding VM/protection onto AmigaDos??  Is it
> going to be a problem?  

    I think VM is quite feasible, since it should be transparent to the
    system at quite a low level. Memory protection is quite different.

    Discussions on this have been held before, and I believe at least
    one person was working on adding VM.

>   Perhaps that may be best.  My question was whether there have been
> any studies done in this area.  If you read all the classic OS design

    No idea. I've heard that people are looking harder at running
    distributed OSs, in which case the power available would make
    questions of interface speed moot.

>   For example, I believe the Amiga OS was derived from Tripos? by
> Metacomco?.  What was the original design decision behind the Amiga OS
> ancestors?

    AmigaDOS was apparently based on Tripos. This is the bit that does
    things like normal file management, loading programs, etc.

    There is another level to the OS that does the multitasking and
    inter-process stuff, called Exec. This is not related to Tripos.

> Evan Torrie.  Stanford University, Class of 199?       torrie@cs.stanford.edu   
--
*** John Bickers, TAP, NZAmigaUG.        jbickers@templar.actrix.gen.nz ***
***         "Patterns multiplying, re-direct our view" - Devo.          ***