Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!rutgers!mcnc!rti!bcw
From: bcw@rti.UUCP (Bruce Wright)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Why unix doesn't catch on
Summary: Multitasking and the 386
Keywords: multitasking
Message-ID: <2890@rti.UUCP>
Date: 16 Apr 89 04:00:21 GMT
References: <1922@dataio.Data-IO.COM> <101000047@hpcvlx.HP.COM> <199@isctsse.UUCP> <4937@tekgvs.LABS.TEK.COM>
Distribution: usa
Organization: Research Triangle Institute, RTP, NC
Lines: 67

In article <4937@tekgvs.LABS.TEK.COM>, toma@tekgvs.LABS.TEK.COM (Tom Almy) writes:
> In article <199@isctsse.UUCP> pajerek@isctsse.UUCP (Donald Pajerek) writes:
> >Previous multitasking approaches have failed in many ways. For example,
> >Windows will only multitask Windows applications; OS/2 will only multitask
> >OS/2 applications.  Besides, any multitasking at all on less than a 386
> >processor is impractical for performance reasons.
> 
> Rediculous!   There have been commercial multitasking/multiuer systems
> around for years on machines less powerful.  PDP-8s had TSE which supported
> 16 users on a machine certainly less than 1/10th the speed.

The old multitasking operating systems for things like the PDP-8
and so forth required application programs which cooperated with the
operating system.  The problem with multitasking on the IBM-PC is not
that you need any kind of great engine to run some sort of multitasking
(there are a number of multitasking operating systems for a stock IBM-PC),
it's that in order to run MS-DOS software under such a system you need a
fairly powerful engine.

The reason for this is simply that the typical applications availble for
MS-DOS spend a fair amount of energy to subvert the operating system.
This unfortunate state of affairs exists because of the abominable
performance that MS-DOS has for certain operations (screen operations
generally, also to a somewhat lesser extent for disk and keyboard
operations), and also because it lacks useful functions (many devices
are very poorly supported, especially the communications devices).
The upshot is that the writer of a multitasking operating system is
left with three unappetizing choices:

	o Ignore the possibility that the application will do any of
	  the ill-behaved things that MS-DOS applications programs
	  always seem to want to do.  This will almost guarantee that
	  either the application task or the operating system will
	  crash when the application attempts the operation (depending
	  on the nature of the operation and the design of the operating
	  system).  This will make most existing MS-DOS applications
	  unusable on the system, or at least will require disabling
	  multitasking while the application is running.

	o Write an O/S for a processor which allows a full virtual MS-DOS
	  machine to be created, with appropriate emulation when attempts
	  are made to reference video memory or other devices.  This
	  requires at least a 386 - the 286 does not allow the creation
	  of a complete virtual machine environment.

	o Complete emulation of the processor instruction set (in other
	  words, interpretively execute the entire image).  This will
	  work, but at an enormous (and generally unacceptable) hit in 
	  performance.

In a real way, the problem is NOT the 8086 or the 286, it's MessyDos.

> If you need at least a 386 for multitasking, your tasks are too big!

Reminds me of a comment attributed to John von Neumann to the effect that
if you couldn't write it in 4K, it wasn't worth writing (of course he
was talking about 4K of 36-bit words, but even so ...).  (I don't remember
the exact size or the exact wording and the attribution itself may be 
apocryphal - anyone know?).  Certainly there are some computationally-
intensive problems which would not run very effectively on anything less 
than a 386, but you're certainly right that for basic multitasking, you
really don't need a 386 or even a 286.

Unfortunately what the market wants isn't just multitasking on a 80*86
machine, it's a multitasking MessyDos environment.  Sigh.

						Bruce C. Wright