Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!rochester!cornell!uw-beaver!ubc-vision!alberta!calgary!radford
From: radford@calgary.UUCP (Radford Neal)
Newsgroups: comp.os.minix
Subject: Re: MAC and Minix
Message-ID: <990@vaxb.calgary.UUCP>
Date: Wed, 1-Jul-87 16:02:44 EDT
Article-I.D.: vaxb.990
Posted: Wed Jul  1 16:02:44 1987
Date-Received: Sat, 4-Jul-87 05:18:53 EDT
References: <1756@pbhye.UUCP>
Organization: U. of Calgary, Calgary, Ab.
Lines: 23
Keywords: C icons port
Summary: Do it as a desk accessory

In article <1756@pbhye.UUCP>, josh@pbhye.UUCP (Joshua Stein) writes:

> Has anyone thought of porting Minix to the Mac or is that to wierd? ...


I think it would be nifty to port MINIX to the Mac as a desk accessory.
You'd have to modify MINIX a bit to take the bits of time a desk 
accessory gets when the Mac application calls SystemTask and distribute
it to the MINIX processes. IO would be done to a pseudo-disk that was
actually a Mac file - you could put in an interface to the Mac's file 
system later. When the desk accessory is closed, you would write the
memory image of all processes to disk, ready to restart when the
desk accessory is opened again.

The main problem would be the C compiler for MINIX, which would have to 
generate code that offsets all memory references from an address register.
If you did this right, however, you could be secure against wild MINIX 
processes.

This method would allow MINIX to be run concurrently with all your favorite
Mac applications, at the drop of a mouse button.

     Radford Neal