[net.arch] 16+ bit Op-systems: where to?

cdshaw@watmum.UUCP (Chris Shaw) (08/05/85)

In article <12200013@orstcs.UUCP> richardt@orstcs.UUCP (richardt) writes:
>UNIX^tm  has been ported onto 680xx's, Z800x's, 80xxx's, 
>and a number of people are working on porting it to 32xxx's.  There's only one
>problem with UNIX on a micro:  portability.  UNIX is not designed for you to
>pull out a disk, walk to the machine 20 ft. away from you, and boot up.  Even
>the micro implementations don't handle the problem politely.  
>
> what do we want?
>
>for starters:
>	1)  processes
>	2)  multi-tasking.  
>	3)  pipelining + redirection.  
>	4)  windows 
>	5)  a logical or semi-logical command structure 
>	6)  tree-structured directories make life FAR easier.
>
>And now for a truly revolutionary idea, if it can be pulled off:  an OS
>which will run on all of the common 16-bit or wider processors.
  .
  .
  .

Well yeah, but.....
Your concept of portability is funny. Why do you need it ? And (much more 
importantly) what level of portability is wanted ? Trivial stuff, or
portability to the degree that any program will port with absolutely no
changes ?

The crux of the problem isn't the features that you might want on your system,
but the portability that you obviously require to do this kind of thing.

Several projects come to mind as trying to do this:

Waterloo Port: -- an outgrowth of work done to create the Thoth Operating System
	is currently taking place on a newer OS called PORT. Current experience
	is that stuff (the OS) ports fairly easily. I don't recall that it
	runs on a lot of different machines, though. Runs on PC's, etc.

V System, developed at Stanford: -- runs on Suns.

Anyway, the big problem of taking program "a" on machine "x" & moving it to
machine "y" is that system dependencies inevitably show up, no matter what.

>So, the system disk would contain:  9 boot systems, and a 4 each of Pascal,
>C, and Basic Compilers/Interpreters.  Four of each because only one is
>needed for each processor family.
 . . .
>This leaves one major question:  Is it worth the effort to achieve a system
>which makes today's concept of portability look silly?
>
>						orstcs!richardt

My gut feel is to call this concept of portability "silly", simply because it
isn't obvious why one would want it. You essentially get to the point where
you program at the lowest common denominator. Using an automotive analogy, this
is like asking that all cars be able to use that same tires or something.

Chris Shaw    watmath!watmum!cdshaw  or  cdshaw@watmath
University of Waterloo
In doubt?  Eat hot high-speed death -- the experts' choice in gastric vileness !