Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!zaphod.mps.ohio-state.edu!samsung!munnari.oz.au!uhccux!waikato.ac.nz!ldo
From: ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University)
Newsgroups: comp.arch
Subject: Re: How wrong is MS-DOS?
Message-ID: <1991Jan9.185521.2649@waikato.ac.nz>
Date: 9 Jan 91 05:55:21 GMT
References: <1991Jan02.035501.9457@iecc.cambridge.ma.us> <14900021@hpdmd48.boi.hp.com> <1991Jan6.183213.27136@msuinfo.cl.msu.edu> <1779@mwca.UUCP>
Organization: University of Waikato, Hamilton, New Zealand
Lines: 139

I'd like to butt in and suggest that this discussion about merits
of PC operating systems is on completely the wrong track.

First I should make it clear that my interest is specifically in
*personal computer* operating systems--that is, ones oriented
towards a single-user environment. You can have as many tasks/
threads/processes as you want, running on as many processors as
you want, connected as loosely or as tightly as you want, but the
whole mess is still cooperating on solving the problems of a single
user. That's my scenario.

[Note from Poster's Conscience: the rest of this message is
pretty long, and more than a little rambling, so if you don't feel
as strongly about the importance of single-user systems as I do,
you may as well skip the rest of it.]

As soon as you accept this, it becomes obvious that MS-DOS was
badly designed from day 1. Microsoft *should* have done a
better job, even allowing for the fact that they couldn't have
foreseen most of the technical developments that have happened
in the last ten years.

Consider what an operating system is supposed to do. Different
people have lots of different ideas on this, but among the most
important design principles that I can think of are:

     1) Shield the application program from hardware dependencies,
	and variations in system configurations.
     2) Provide a standard interface to services that allow
	transfer of information between applications.
     3) Implement other useful services that application programmers
	find themselves reinventing.

Principle 1 leads to such ideas as "device drivers" to hide the
differences between floppy disks, SCSI hard disks, disks on
network servers etc (broadly speaking). Principle 2 leads to the
conclusion that, if two or more applications are going to be able to
access common data on those same disks, then you must have a common format
for storing that data, and hence (to guarantee consistency) the
operating system must provide the interface for accessing the
data. This leads to the concept of file systems, and their
extension into ISAM managers, database servers and the like.

Note the important difference between Principles 2 and 3: a certain
feature may be needed in a lot of programs, so it would be handy
if it were a standard part of the OS, but as soon as that feature
becomes a basis for communication *between* programs, its inclusion
in the OS becomes pretty much mandatory. Another example of this is
networking protocols (a combination of Principles 1 and 2).

Just for fun, consider the problem of conversion of dates and times:
formatting them in a human-readable text representation, as well as
converting such a text representation into an internal form more suited
to calculations. You might think that a package to do this falls under
Principle 3: useful to a lot of programs, but not an *essential* part
of the OS. But in today's increasingly international software market,
you may be selling your application in countries where they speak
different languages, even use different calendars. You could either
say that a) every application will need to have support for every
country's conventions (language, alphabet, calendar etc) built into it, and
the user will have to make the appropriate choice when installing
the application, or b) the operating system should worry about it,
so that the choice is made once when installing the OS (and may
even be changed later while the OS is running), and all the applications
automatically adapt.

So really, date/time conversion (and other issues of text manipulation
and formatting) fall under Principle 1, not 3, and they are
an important part of the functionality of the OS after all.

I really brought that up as an example of how consideration of
the principles of OS design can lead you to conclusions which obviously
don't agree with those that have been reached yet by the designers of
most current OSes. So who's wrong...?

Getting back to MS-DOS, my assertion is that its design was based
more on how contemporary OSes did things, rather than on *why* they
did them. It was an adaptation of features to be found in multi-user
minicomputer operating systems, without regard for the fact that those
systems ran in a rather different environment, under different constraints,
from a PC.

"Hindsight!" I hear you cry. Nobody could have foreseen the directions
that the PC industry took, or the sorts of applications that PCs would
be put to. Almost entirely true. Almost.

At the time the first version of MS-DOS was being developed, there
was already at least one wildly successful PC application, which was
obviously a pointer as to what many future applications would be like.
I'm talking about Visicalc.

If MS-DOS had been designed to make applications like Visicalc easier
to implement, it would have been a much better PC operating system.

What made Visicalc different from anything that had been seen in
the multiuser mini/mainframe world? It was _interactive_. It responded
instantly to every keystroke, and it achieved this by writing directly
to video RAM.

"Horrors!" cried the OS Designers of the Old School: "So much for
hardware independence (Principle 1)." It's true, Visicalc could never
have run on a paper-printing teletype. But then, no one would have
wanted to use it on one, anyway.

The downside to the way Visicalc worked, is that it needed to be
specially ported to every different hardware platform, since each
brand of PC mapped its video RAM in a different way.

Eventually Visicalc made it onto the IBM PC, and was joined by a
flood of new applications that all made assumptions about the way
the video system worked. And IBM came out with new video systems,
and the _entire_ history of these, from MDA and CGA thru EGA, PGC,
VGA, 8514/A, XGA and beyond, has been one of adding new kludges,
while making sure that the old kludges keep working.

Imagine how different things would have been if MS-DOS had provided
display-handling routines (even text-only ones--never mind graphics!) of
a decent quality to begin with: there would have been very little
need to maintain compatibility at the hardware register level, and
applications could interrogate the system to discover the dimensions
of the screen (number of lines and columns) and other such information.
Who knows, one could have had a word-processing application written
in 1981, working on a 25-line CGA display, and started it up on a
1990-vintage super VGA system to watch it automatically adapt to a
50-line display with zillions of colours!

The point is that hardware and configuration independence is still
important, but you have to interpret the concept (and all the other
principles of good OS design) in terms of the needs of contemporary
real-world applications, not the way things worked on systems dating
from 20 years ago.

Lawrence D'Oliveiro                       fone: +64-71-562-889
Computer Services Dept                     fax: +64-71-384-066
University of Waikato            electric mail: ldo@waikato.ac.nz
Hamilton, New Zealand    37^ 47' 26" S, 175^ 19' 7" E, GMT+13:00
Climber Rob Hall on why he climbed the seven highest mountains on
seven continents in seven months: "No one would give me a good
office job."