mwm@eris.BERKELEY.EDU (Mike Meyer) (01/24/87)
In article <5283@ism780c.UUCP> tim@ism780c.UUCP (Tim Smith) writes: >If someone can come up with a good definition of "operating system", >then it would be possible to decide which computers have them. One >OS textbook I saw defined an operating system as the software that >takes control when a user program makes an error, but that definition >seems kind of worthless. >-- >Tim Smith USENET: sdcrdcf!ism780c!tim Compuserve: 72257,3706 > Delphi or GEnie: mnementh I answered Tim's questions about AmigaDOS by mail. I suggest that others move MCIBTYC discussions to private mail also. 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. 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. 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. AmigaDOS is somewhere in between, as it doesn't protect things, but does try to allocate them (your program is considered buggy if you don't tell the OS everything you're playing with). [Oh, yeah - just for AmigaDOS bashers: notice that Tripos has full memory and device protection in its original environment. I expect it got lost on the original port to the 68K, not in the port to the Amiga.] Ok, so I defined a spectrum that takes you from non-OS's (like CP/M) to "real" OS/s (like Unix (cough, cough)). Where does *your* operating system fit? And be sure to include "protecting and allocating" the CPU as part of that. Single-tasking systems just give the CPU to a program until they're through. Multitasking systems treat it as just another serially reusable resource, and try and schedule things so that everybody get some (with multi-processor boxes - like my current monkey - this is even more so). Waxing sillyphosical, <mike
radford@calgary.UUCP (01/26/87)
This discussion of whether the Mac, Atari, Amiga, etc. has a real
operating system is silly. Virtually every computer has an operating
system; some have better operating systems than others.
An operating system is just what it says: the system that lets the
computer be operated. It consists of all the software required for
basic operation of the computer in its intended environment.
Those people who say that the Atari, say, doesn't have an operating
system really mean they don't like its operating system. Usually,
they mean they don't like its lack of multi-tasking. OK, that's fine.
Don't use it. But don't make silly definitions of "operating system" that
just show how narrow your view of computers is.
Radford Nealjpm@bnl.UUCP (01/26/87)
> 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. Good definition, but somewhat limiting for most microcomputers because the hardware just isn't there to protect resources. I would expand the definition to include those systems that allocate and protect resources to the best ability of the underlying hardware. For example, MSDOS is about as good an an OS as you can get on a 8088 (ever try 8088 UNIX? I'd call it a bad joke rather than an OS). -- John McNamee jpm@BNL.ARPA decvax!philabs!sbcs!bnl!jpm "Timesharing is the use of many people by a computer"
ciaraldi@rochester.UUCP (01/28/87)
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
chapman@eris.UUCP (01/31/87)
In article <46@bnl.UUCP> jpm@bnl.UUCP (John McNamee) 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. > >Good definition, but somewhat limiting for most microcomputers because the >hardware just isn't there to protect resources. I would expand the >definition to include those systems that allocate and protect resources to >the best ability of the underlying hardware. For example, MSDOS is about as >good an an OS as you can get on a 8088 (ever try 8088 UNIX? I'd call it a >bad joke rather than an OS). I think y'all are missing Mike's point: Most of these (so-called) microcomputer "operating systems" _AREN'T_ !! Most microcomputer operating systems (including just about everything but AmigaDOS, OS9, and UNIX/XENIX) are little more than overgrown subroutine libraries... Brent -- Brent Chapman chapman@eris.berkeley.edu or ucbvax!eris!chapman
tim@hoptoad.UUCP (02/03/87)
When faced with a non-computer-type who wants to know what I meant when I
let the words "operating system" slip out, I say that it's the main program
that's always running and that controls how all the other programs run.
This seems to satisfy them, and as far as I can tell it seems to be
accurate, though non-jargonistic.
For a computer type, I would probably say that it is software which helps
other (client) software deal with the files, processes, and devices of the
computer system. This would mean that standard software libraries and
standard applications which are not in the kernel should be considered part
of the OS, but I don't have any problem with that.
By the way, I think user-space file servers are undesirable because there is
likely to be context switching overhead in the processing of remote file
requests. This creates scheduling latency in a non-real-time system - that
is, the process scheduler has to be invoked before any packet can be fully
processed - and this tends to slow down protocols enormously. File servers
should be put in the kernel where possible, like all other network
protocols. It is regrettable that UNIX requires a static linking and
rebooting to do so; perhaps someday someone will come up with a
dynamic-linking version of UNIX to help with protocol (and driver, and file
system, etc.) development and maintenance.
--
Tim Maroney, Electronic Village Idiot
{ihnp4,sun,well,ptsfa,lll-crg,frog}!hoptoad!tim (uucp)
hoptoad!tim@lll-crg (arpa)
Second Coming Still Vaporware After 2,000 Years