Path: utzoo!attcan!uunet!samsung!umich!sharkey!msuinfo!convex.cl.msu.edu!jap
From: jap@convex.cl.msu.edu (Joe Porkka)
Newsgroups: comp.arch
Subject: Re: Single user OSs (How wrong is MS-DOS?)
Message-ID: <1991Jan9.172528.29100@msuinfo.cl.msu.edu>
Date: 9 Jan 91 17:25:28 GMT
References: <1991Jan02.035501.9457@iecc.cambridge.ma.us> <14900021@hpdmd48.boi.hp.com> <1991Jan6.183213.27136@msuinfo.cl.msu.edu> <1779@mwca.UUCP> <1991Jan9.185521.2649@waikato.ac.nz>
Sender: news@msuinfo.cl.msu.edu
Organization: Michigan State University
Lines: 61

ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes:

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

>[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
No kidding!!

>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

Boy, you would LOVE the Amiga Operating System
Device drivers with a consistent standardized interface.
Each one supports things like Read, Write, Open, Close, plus
any device specific commands. For example, the serial.device
has a command to set parameters, like baud.

>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

it has a good filesystem interface. Allows third parties to make new filesystems
This is being done in the public domain (messyfilesystem to read MSDOS disks)
and commercially.
It has also from the start supported a standard file format, which is extendable
CBM keeps a registry of file formats. CBM publishes this info so others
can (and usually do) use the same format as similar programs.

It also has good IPC. In fact, all device calls, DOS calls, and inputevent
are handled by IPC, rather than procedure calls. This means that you
inherently can do all IO async.
Then theres AREXX for talking to other programs with.

>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

Shared libraries. Shared Fonts. Shared drivers.device. Shared
execuatbles (ie, if you run 'dir' twice, it needs only one copy of the code
in memory)


I could go on and on but I wont.