Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!husc6!think!ames!ptsfa!ihnp4!homxb!houxm!mtuxo!mtune!mtunb!dmt
From: dmt@mtunb.UUCP
Newsgroups: comp.sys.ibm.pc
Subject: Re: IBM new 'standard'
Message-ID: <882@mtunb.UUCP>
Date: Thu, 26-Mar-87 09:49:12 EST
Article-I.D.: mtunb.882
Posted: Thu Mar 26 09:49:12 1987
Date-Received: Sat, 28-Mar-87 07:44:42 EST
References: <701@imsvax.UUCP> <855@bucsb.bu.edu.UUCP>
Reply-To: dmt@mtunb.UUCP (Dave Tutelman)
Organization: AT&T Information Systems - Lincroft, NJ
Lines: 89

There's been A LOT to comment on in this discussion, but I've seen more
heat than light through most of it.  But "Jack" tweaked a pet peeve of
mine, so here goes....

In article <855@bucsb.bu.edu.UUCP> madd@bucsb.bu.edu.UUCP (Jim "Jack" Frost) writes:
>
>OK.  Now run something on your supersystem.  You have described a
>$20,000 system (a couple of grand for the machine, a couple of grand
>for the graphics, 8 grand for the coprocessor, and of course you need
>a good hard disk).  Now is it PC compatible?  Bet not.  Not 1/100th of
>the software available will run on it at anything better than normal
>performance.  Your system is no longer in conformance with PC
>standards.  Notice that an enhanced UNIX machine will generally take
>advantage of enhancements.  

So true, but WHY?  It isn't inherent in ALL of MSDOS, or even in its
lack of multitasking.  I maintain that it boils down to two things:

   1.	MSDOS depends for its I/O on a BIOS whose primitives are
	insufficiently powerful.

   2.	Ironically, the very popularity of one hardware implementation
	(the IBM "standard") doomed MSDOS to be "forever" single-tasking,
	non-portable, and all those other things we dislike.

Here's the reasoning.  Because the BIOS primitive are REALLY primitive,
there was no way to get performance on an MSDOS machine.  Prime examples
live in the video portion of the BIOS; it requires a separate call for
each character OR EACH PIXEL you want to touch.  Each call requires
(1) an interrupt with all its overhead, (2) determining the type of
display and its current mode, (3) computing the address in the display
map FROM SCRATCH, and (4) finally doing what the call is supposed to do.
Can you imagine how your machine crawls when it has to go through this
for each pixel?

This presents application developers with a problem.  
They could write directly to the display map, and be non-portable;
or they could use the DOS and/or BIOS calls and have rotten performance.
If they had to sell 10 different non-portable versions to bypass the
BIOS, this would have been a tough choice.  But by 1983 or so, it
became clear that one hardware implementation represented 95% of all MSDOS
instances, and the percentage would only rise from there.  This got
the developers off the hook; THERE WAS NO MARKET NEED FOR PORTABILITY
among MSDOS implementations -- they could ignore the <5% of
not-quite-compatibles out there and go for speed.

The result has been that many of the popular programs for DOS machines
are "ill-behaved" in the sense that they go around the BIOS and use
the hardware directly.  (Examples: for performance [almost everybody's
video], for copy protection, for "hot-key" multitasking.)  This not
only prevents portability, IT PREVENTS CLEAN MULTITASKING!  I've written
lots of low-level software for DOS machines (including a multitasker),
and every one had its biggest problems running with applications that
bypassed the BIOS.  No, I'll go further -- there would have been no need
for cleverness on my part to do ANY of those fun hacks if all
applications had used the BIOS.  They could have been homework problems
for an undergraduate course in operating systems.

Can what I'm saying be true?  Isn't MSDOS about to get multitasking? 
Well, if you read the fine print from Microsoft, the new multitasking products
will require recompiling and usually rewriting applications.
They will not, in general, run .EXEs that ran under DOS 2.x or 3.x.
They certainly won't run ill-behaved pre-existing applications
(well, maybe one, given certain hardware aids).

Why hasn't UNIX succumbed to this problem?  In my opinion, its saving
grace so far has been the failure of a single hardware implementation
to take over the UNIX market.  For UNIX, portability isn't so much a
virtue as a necessity.  Now my employer has announced the intent
of setting a "binary standard" for 386-based UNIX.  To the extent
that we succeed, we MAY give application developers motivation
to use the implementation rather than the
interface (exactly the DOS problem, if my theory is right).  We had
better look to our interfaces, and make sure they're both powerful enough
and sufficiently easy to use that application developers won't be too
tempted.  My personal view of where we may be vulnerable is in the
display interface; I hope that curses for character screens and
something (X-Windows? Something else?) for graphics screens do the trick.

----------------------
DISCLAIMER - These opinions are my own.  I am not in a position to
know my employer's opinion in this matter.

+---------------------------------------------------------------+
|    Dave Tutelman						|
|    Physical - AT&T  -  Lincroft, NJ				|
|    Logical -  ...ihnp4!mtuxo!mtunb!dmt			|
|    Audible -  (201) 576 2442					|
+---------------------------------------------------------------+