[comp.arch] MS-DOS OS "architecture"

mike@bria (01/20/91)

In article <1991Jan18.140350.11175@cbnewsl.att.com> cbnewsl.att.com!wkk (wesley.k.kaplow) writes:
>What's wrong with MS-DOS, well lets examine what people expect an operating
>system to do for them
>
>1) Act as a program loader
>2) Manage various Input and Output devices
>3) Manage the use of the processor
>4) Manage the use of memory
>5) Free a user from having to understand all of the details about 1-4.
>   (this probably asks too much from any operating system)
>6) Don't jump on me, I probably forgot something.
>
>How does MS-DOS perform on the above?

What I expect from an operating system is the following capabilities:

1. A uniform and reliable way of communicating with devices
2. A flexible, reliable and efficient filesystem
3. A predictable program scheduler and efficient image loader
4. True resource management
5. A comprehensive set of tools to facilitate management of the system
6. A flexible and powerful user interface (shell)

IMHO, the MS-DOS "operating system" stumbles or outright falls down in all
of these catagories.

1. This is DOS' strongest point; character device drivers are relatively
   uniform, and actually have something that vanilla UNIX doesn't: the 
   ability to add devices without relinking the kernel (although you *do*
   have to reboot the machine).  Unfortunately, there are no drivers for
   floppies as "raw" character devices, forcing DOS diskettes to have a
   filesystem, and there is no resource management on any device (see #4).

2. The DOS filesystem, although somewhat reliable, is not flexible at all.
   It is a rigid, archaic structure that is imposed upon the programmer.
   Although recent versions of DOS support locking and sharing of files
   on networks, the implementation is kludgy.

3. Since DOS doesn't have any scheduling capability, all that can be
   discussed is the "program loader" portion.  The fact that DOS supports
   two completely different image types shows it's hacked-upon nature.
   A builtin memory restriction of 640K and the plethora of hacks to get
   around this limitation are volumnous, with every vendor building
   a better mousetrap (and please, no choirs singing "LIM, LIM", it's a joke.)

4. DOS provides no resource management whatsoever.  Any program can use
   any memory, directly address any device, and demand any resource (including
   the operating system) without restriction.  Since the stupidity of this
   approach is obvious, I'll leave it alone.

5. DOS has a handful of tools, and none of them any good.  Is it any wonder
   that DOS programmers have "imported" so many UNIX tools into the DOS
   environment?  Anything of value has to be bought from a third party at
   additional cost.

6. The shell could be (and should be) considered a part of #5, but it also
   deserves it's own place.  The DOS shell is a joke; a crude tool that
   that can only be used to build cruder tools still.  While some may argue
   that the UNIX shell is too complex, it is far easier to make a complex
   thing simpler to use, than a simple thing more complex and powerful.
-- 
Michael Stefanik, Systems Engineer (JOAT), Briareus Corporation
UUCP: ...!uunet!bria!mike
--
technoignorami (tek'no-ig'no-ram`i) a group of individuals that are constantly
found to be saying things like "Well, it works on my DOS machine ..."

dana@locus.com (Dana H. Myers) (01/22/91)

In article <366@bria> mike@bria.UUCP (Michael Stefanik) writes:

>What I expect from an operating system is the following capabilities:
>
>1. A uniform and reliable way of communicating with devices

>1. This is DOS' strongest point; character device drivers are relatively
>   uniform, and actually have something that vanilla UNIX doesn't: the 
>   ability to add devices without relinking the kernel (although you *do*
>   have to reboot the machine).

  Well, it isn't true that device drivers MUST be loaded in at reboot.
Config.sys is read and interpreted directly after the boot, before the
shell is executed, but there is nothing preventing one from writing a
utility to load device drivers well after boot, from a user program.
Merge 386, for instance (a commercial DOS under Unix product from Locus)
uses such a technique.

-- 
 * Dana H. Myers KK6JQ 		| Views expressed here are	*
 * (213) 337-5136 		| mine and do not necessarily	*
 * dana@locus.com		| reflect those of my employer	*