From: cross@spitfire.i.gajendra.net   
      
   In article <20250310151114.000023e9@gmail.com>,   
   John Ames   wrote:   
   >On Mon, 10 Mar 2025 20:20:02 -0000 (UTC)   
   >cross@spitfire.i.gajendra.net (Dan Cross) wrote:   
   >   
   >> But I do know a lot about operating systems, and the objections   
   >> to categorizing things like MS-DOS as "a *real* OS" are not mere   
   >> handwaving that boils down to "Because Reasons"; there are   
   >> actual definitions in use across the field one can look to, and   
   >> MS-DOS et al simply do not meet them.  It's great that control   
   >> software in the early PC era let people do useful work with   
   >> those machines; that doesn't mean that software was good or fit   
   >> reasonable definitions of what an "Operating System" is.   
   >   
   >So let's dig into that a bit. Merriam-Webster defines an "operating   
   >system" thusly:   
   >   
   >> software that controls the operation of a computer and directs the   
   >> processing of programs (as by assigning storage space in memory and   
   >> controlling input and output functions)   
      
   Msrs. Merriam and Webster were not, to my knowledge, computer   
   scientists.   
      
   >Wikipedia, being edited by Wikipedians, is a little more weird and   
   >obtuse, but more or less in accord:   
   >   
   >> Software that is designed for controlling the allocation and the use   
   >> of various hardware resources to tasks and remote terminals.   
      
   Indeed obtuse.  What about a system that does not use "remote   
   terminals"?   
      
   I already posted the definition I like to use, which came to me   
   via Mothy Roscoe, at ETH, but I'll post it again:   
      
   He defines the operating system as,   
   That body of software that,   
   1. Multiplexes the machine's hardware resources   
   2. Abstracts the hardware platform   
   3. Protects software principles from each other   
      (using the hardware)   
      
   I further posted how I feel that MS-DOS dos not meet these   
   criteria, and why.   
      
   So arguing about a definiton from a mass-market English langauge   
   dictionary and/or wikipedia is not, frankly, very compelling in   
   comparison.   
      
   >MS-DOS very definitely takes control of the computer - it does not   
   >*hold onto it* very tightly, but there's no particular reason it should   
   >have to.   
      
   Given the above definition, there's a very good reason: how does   
   it otherwise protect _itself_, as a software principle, from an   
   errant, let alone malicious, program?   
      
   Also, a boot loader takes control of the computer, albeit   
   temporarily: is that also an operating system?  Merely taking   
   control of the computer is insufficient.  The OpenBoot PROM   
   monitor on a SPARCstation could be entered via a keyboard   
   shortcut, suspending Unix and the SPARC processor; was that an   
   "operating system"?  I don't think anyone working on it thought   
   of it that way.   
      
   >In a single-tasking, single-user environment any operation the   
   >user invokes can be Considered Legitimate, and this loose approach to   
   >protection makes it possible for third-party or user-written software to   
   >hook into interrupts/API calls and extend the system easily (although   
   >DOS users generally made less use of this than classic MacOS users did.)   
      
   While an operation a *user* invokes, such as running a command   
   or invoking a program, can be "Considered Legitimate" in that   
   context, it does not follow every operation performed by a   
   program is legitimate.  Programs have bugs; those bugs can   
   corrupt the state of the system; at best this may simply crash   
   the system.  At worst it can lead to data corruption or loss.   
      
   DOS can't protect against that.  So it fails criteria (3) of   
   Roscoe's definition.   
      
   >It also manages memory allocation (enabling applications, drivers, and   
   >TSRs to co-exist safely, provided they behave themselves) and handles   
      
   Actually, it did not allow TSRs to "co-exist" safely, because   
   the set of things required to do so goes far beyond mere memory   
   allocation.  Since you brought up Wikipedia, the article on TSRs   
   that Scott linked to earlier went into this in detail, and is   
   well worth reading.   
      
   >input and output to/from screen/keyboard, disk, and parallel and serial   
   >ports. Again, it does not *prevent* programs from taking control of   
   >these things themselves, but that's a trade-off - yes, you lose some   
   >security,* assuming you even care about that, but you gain flexibility.   
   >(Supporting new hardware is generally as simple as writing a program to   
   >frob the appropriate ports, unless the OS needs to be able to treat it   
   >as a standard storage/communications channel. Even then, hooking into   
   >the necessary interrupts is fairly straightforward.)   
   >   
   >* (And it's worth noting that, in the original PC architecture pre-286,   
   >  it's functionally impossible to do protection anyway. There's not a   
   >  damn thing *any* OS running on an 8086 can do to prevent an errant   
   >  program from scribbling over the OS/another process or frobbing an   
   >  I/O port something else is trying to manage.)   
      
   See above.   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)