Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!seismo!rochester!ciaraldi
From: ciaraldi@rochester.UUCP
Newsgroups: comp.sys.amiga,comp.sys.mac,comp.sys.m68k,comp.sys.misc
Subject: Re: What is an OS?
Message-ID: <24270@rochester.ARPA>
Date: Wed, 28-Jan-87 15:58:25 EST
Article-I.D.: rocheste.24270
Posted: Wed Jan 28 15:58:25 1987
Date-Received: Tue, 3-Feb-87 20:15:02 EST
References: <8520@topaz.RUTGERS.EDU> <1270@cbmvax.cbmvax.cbm.UUCP>
Reply-To: ciaraldi@rochester.UUCP (Mike Ciaraldi)
Organization: U of Rochester, CS Dept, Rochester, NY
Lines: 103
Xref: watmath comp.sys.amiga:1869 comp.sys.mac:1113 comp.sys.m68k:222 comp.sys.misc:284

In article <2331@jade.BERKELEY.EDU> mwm@eris.BERKELEY.EDU (Mike Meyer) writes:
>Meanwhile, I wanna talk about what an operating system is. The
>definition I've been using for the past few years is simple:
>
>	An operating system allocates and protects the resources
>	of the computer.
>
>If it doesn't do at least those two things, then it hardly qualifies
>as an OS. On the other hand, anything and everything outside of that
>can theoretically be handled by user code. 

I'm afraid I must disagree with your definition and examples.
First let me say where I'm coming from.  I started working with
computers about 20 years ago, when operating systems were generally
much more primitive than they are today.  I have worked with machines
from micro to mainframe, with a variety of OS's.  I think Meyer's
problem comes from not taking a broad enough view, i.e. assuming
that the only "real" operating systems are those with the features
of today's OS's.

For me, the main purpose of an OS has always been to hide the details 
of the hardware from the user software.  Remember that not all machines
have things like "user space", "reserved instructions", and other
things that try to keep the user from getting at the shared
resources.  Rather, they could tickle the hardware if they wanted
to; the point of the OS is so they don't have to!

So, the OS contains code for the file system, as well as the drivers
for the disk, printer, terminals, etc. (of course, many micros
now have the drivers in ROM, and the OS just calls them).
Still, the point is that the user can just ask the OS to give
him/her the next keystroke, or send this character to the
printer, and doesn't care about the device address, status signals,
and so on.

If you programmed micros (in assembly language) in the mid-1970's
(or minis ten years before), you know what a pain it was
writing programs before operating systems like CP/M, RDOS,
VORTEX, or RT-11 came along.  The program had to have the
drivers hard-coded into it, which made it very non-portable between
different machines.  With CP/M you could write a program that
would run on ANY 8080 or Z-80 machine regardless of whether it
had floppies, hard disk, separate terminal, built-in video and keyboard,
serial or parallel printer, etc.  CP/M hid all the differences.
An OS such as MP/M (the multi-tasking version of CP/M) also let
you address your own terminal as if it were the only one, and then
each user who ran the program would have I/O directed to the
appropriate terminal.

>That's now the default for
>command processors, even though they used to be hardwired into the OS.
>File servers are moving into user space now, and I expect user-space
>file servers to become as standard as user-space command processors.

In that case they won't be very standard.  User-changeable command processors
are still very much the exception rather than the rule.  Unix was the
first widely-used OS to offer this feature, and it was considered
quite a breakthrough in the mid-1970's.  Now you can get them for
IBM PC-DOS (MS-DOS), AmigaDos, and a few others, but no way can you
get them (to the best of my knowledge) on MVS, DOS/370, VM/370,
Primos, VMS, RSTS, or any of the other major mainframe or mini  OS's.

>The program loader type "operating systems"s don't really qualify;
>they take a program and say: "Here, do what you want with the whole
>machine." Unix is at the other end of the spectrum, and you have to
>ask it for EVERYTHING. Memory, access to disk space, whatever.

As I mentioned, you do have to ask CP/M for disk space (unless you
want to risk corrupting the disk, which the hardware physically can't
prevent you from doing).  On the other hand, until very
recently Unix didn't even have file locking to prevent
simultaneous access to files.  It had to be handled by user code!
MP/M had it on the 8080 microprocessor 8 years ago.

On a single-tasking system, especially one without memory-mapping
hardware, there are a lot fewer resources to manage.
The processor, memory, the printer, etc. are not "shared".
On a multi-tasking system, it is appropriate to have this
resource allocation handled by a central authority, i.e. the OS.
Just because the simple system didn't need these features
doesn't mean it is not an operating system.

Also, the utilities that come with an OS (assembler, debugger,
linker, command line interpreter, file copier, disk formatter, etc.)
are traditionally considered part of the OS, just not part of
the Kernel.  The Kernel includes the resource allocator, dispatcher,
program loader, file system, and so on, i.e. the stuff that stays in
memory.

In conclusion, an OS provides many functions, including:
     Shared resource allocation.
     Hiding the hardware details.
     Processing user commands.
     Loading programs.

Not having all of these does not automatically make something
not an operating system.

I welcome comments on this.

Mike Ciaraldi
uucp: seismo!rochester!ciaraldi
ARPA: ciaraldi@rochester