From: bruce@ais.com (Bruce C. Wright)
Newsgroups: comp.os.os2.advocacy
Subject: Re: MS's misconduct!
Date: 10 Oct 92 23:39:44 GMT
Organization: Applied Information Systems, Chapel Hill, NC

In article <1992Oct10.083453.11011@leland.Stanford.EDU>, yiupun@leland.Stanford.EDU (Yiupun Michael Kwong) writes:
> In article <1992Oct08.100600.17202@microsoft.com> petesk@microsoft.com (Pete Skelly) writes:
>>In article <dlcogswe.718464451@vela> dlcogswe@vela.acs.oakland.edu wrote:
>>> petesk@microsoft.com (Pete Skelly) writes:
>>> 
>>> >> But other than being easier to write and code for (maybe),
>>> >> what advantage does non-preemptive multitasking have?  I say none.
>>> 
>>> >Runs on smaller hardware (see the bottom part of my last post).  Allows your
>>> >core system to be smaller.
>>> 
>>> Wrong.  Look at the Amiga.  It runs preemptively fine with 512k.  It's
>>> kernel is what?  1k?  Of course, AmigaOS doesn't have all the nice
>>> features of Windows like... uhhh...  well..  whatever...
>>
>>Oh, great, yet another "Amiga does x that other os's don't post".
>>Okay, here's my response.  Amiga doesn't sell as well as DOS/NT/OS/2/MAC/UNIX.
> 
> Look, the original thread is, somebody claimed that preemptive multitasking
> is going to be larger than non-preemptive multitasking systems.
> This has nothing to do with sales.

The amount of code required to support preemptive multitasking _in the
abstract_ is really not all that great.  What takes up the space is when
you consider _what_ you're multitasking:  Besides the "native" apps
(Windows or OS/2), you're multitasking DOS applications, which as a 
class are notoriously ill-behaved even when running on standard DOS.
A lot of them do all kinds of nasty things to the system, hooking
interrupts, writing to hardware registers, etc ... this may be OK in
standard DOS, but if you're trying to multitask several DOS sessions
it means that you need to create a virtual machine environment, complete
with a 640K memory slot so that the app can play with memory that it
hasn't bothered to allocate legally and still give the results that the
user expects.  And you have to do it so that you don't mess up other
apps in the system (say by corrupting the file system, which might
happen in some crude multitasking algorithms if you did a task switch
while your virtual MS-DOS OS code was updating the disk).  A real mess.

In addition, as others have mentioned, Windows and OS/2 both provide
a level of graphics device abstraction that significantly increases
the code in the baseline software;  plus various utilities, printer
(and other) drivers, etc.

So there are other things you're getting (in effect) from the software
besides multitasking.  The low-level multitasking code proper is
probably not really taking up much code;  what's taking up space is
all the other stuff.  You could cut it down quite a bit by cutting
out DOS compatibility -- supporting the DOS virtual machine imposes
a fair amount of extra code.  Would this be worth the trade?  A lot of
people might think so, but the concensus of the marketplace has been
that this is NOT worth the trade.

In this context it makes some sense to talk about the space penalty
"imposed" by multitasking, since even though the scheduler itself
may not take much code, you need a lot of extra code to multitask the
kinds of things that people _want_ to multitask.

I don't mind saying that multitasking requires a lot of memory as long
as people realize that this is just a shorthand way of saying that multi-
tasking _DOS_ applications takes a lot of memory.  But trying to
use the shorthand to say that _ANY_ multitasking requires a lot of code
is just plain wrong.

Bruce C. Wright
Newsgroups: comp.os.os2.advocacy