From: cross@spitfire.i.gajendra.net   
      
   In article <20250311083745.000076a4@gmail.com>,   
   John Ames   wrote:   
   >On Mon, 10 Mar 2025 23:11:49 -0000 (UTC)   
   >cross@spitfire.i.gajendra.net (Dan Cross) wrote:   
   >   
   >> 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)   
   >   
   >You surely did; however, that does not mean that anybody else is   
   >obligated to accept it.   
      
   Sure.  That's why I prefaced this entire subthread by saying,   
   "it depends on your definition."  I gave the definition that I   
   like, and explained how DOS does not meet those criteria.  Is   
   that unfair?  Perhaps, but the question was, "why do you say   
   this?" and that's the answer of why I say it.   
      
   >Specifically, let me ask:   
   >   
   >1. Why must it multiplex anything, in a single-user system? Multi-   
   >   tasking is certainly a nicety, but why should it be considered   
   >   a necessary criterion for "real" status?   
      
   Note, I said multiplexing, not multitasking.  CPU is just one   
   hardware resource that can be multiplexed, often via   
   multiprogramming but sometimes via spatial allocation (e.g., in   
   a multiprocessor system).   
      
   But others include storage devices, memory, peripherals like   
   timers and other IO devices such as serial/parallel ports,   
   maybe a real-time clock, and so on.  You like having a file   
   abstraction?  Well, that's something that the OS often provides   
   for you, and is _a_ way that e.g. a storage device can be   
   logically multiplexed between multiple programs, even if they   
   do not run concurrently.  Similarly with a memory allocator.   
      
   Getting back to the specific example of MS-DOS, it does provide   
   both, but does Not provide a way to e.g., multiplex IO and   
   computation temporally; so performing a disk operation will   
   just block the program until the operation completes.  Don't   
   want that?  Go touch the hardware yourself.  The control program   
   doesn't really help me here.   
      
   >2. What is the minimum level of hardware abstraction, and why? MS-DOS   
   >   does in fact abstract the details of, e.g., filesystem access, pipes,   
   >   and to a lesser extent serial/parallel communications. You seem to be   
   >   fixated on the fact that its ABI uses x86 interrupts rather than an   
   >   alternative method; why is this important?   
      
   I would hardly say I'm "fixated" on it.  It's simply a fact.   
      
   Generally, we draw a distinction between an API and ABI; the   
   former is often somewhat abstract, while the latter is the   
   concrete implementation of that abstraction.   
      
   In a lot of ways, the ABI is irrelevant for workaday   
   programming: you leave it up to a tool, or a system library, or   
   something like that, but you rarely have to think about it.  The   
   issue with the DOS API is that it is defined _solely_ in terms   
   of the hardware interface, and moreover it is highly specific to   
   that hardware.   
      
   Consider the memory allocation API, for example.  According to,   
   "Advanced MS-DOS Programming, 2nd Ed", by Ray Duncan, if a user   
   program wants to use expanded memory, the program must do work   
   to a) first determine whether expanded memory is even available,   
   and b) use a different, special, interrupt to delegate to the   
   "expanded memory manager" to actually allocate it.   
      
   Now, one might argue that this doesn't matter that much.  "Who   
   cares?  What's the difference between saying that there's a   
   thing called `malloc` and poking a hex constant into %ah and   
   then doing `int 0x67`?"  And that's a valid question; one could   
   imagine an interface that has both `malloc` and `expandedmalloc`   
   or something like that to have an API divorced from the specific   
   ABI, but those are _leaky abstractions_: they exist solely to   
   represent hardware artifacts.   
      
   So while you could "name" those things and not just number them,   
   the things themselves are still very tightly coupled to the   
   hardware.  Those aren't great abstractions.   
      
   >3. Again, in an 8086 environment this is *literally impossible.* There   
   >   is no operating system for the IBM PC or XT that *can* implement any   
   >   kind of protection. Additionally, in a single-user system, why is   
   >   this a requirement rather than a nicety?   
      
   Yup.  An 6802 microcontroller with 128 bytes of RAM doesn't have   
   an operating system, either.  That doesn't mean it isn't useful.   
      
   It's interesting that there was a port of Unix to the XT that   
   was, of course, subject to the same limitations.  Sometimes you   
   are just constrained, so you make due with what you have.  But   
   Unix at least used the segmentation facilities in the processor   
   to _attempt_ to shield the kernel from errant user processes;   
   DOS made no such attempt.   
      
   >> >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?   
   >   
   >It doesn't, because it cannot. The 8086 offers absolutely no facility   
   >for protection,   
      
   Not true.  It supported segmentation.  It's harder to corrupt   
   RAM if it's not in a segment that's currently addressible.   
      
   >nor does the PC hardware implement any kind of bolt-on   
   >mechanism for this. That did not even become *possible* until the   
   >introduction of the PC/AT in 1984, three years after DOS was released,   
   >and that was limited by the infamously "brain-damaged" protected mode of   
   >the 286.   
      
   And when the 286 came out, MS-DOS didn't grow to use it, even   
   though it was there.  Nor did they try to incorporate larger   
   segments or virtual memory when the 386 came out.  But the 386   
   was designed for the Unix market, not the PC, so maybe MSFT gets   
   a pass on that one.   
      
   >> 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"?   
   >   
   >In the strict sense, I don't see why not. A primitive one, granted, but   
   >if ROM BASIC counts as an operating system, OpenBoot certainly would.   
      
   I wouldn't count ROM BASIC as an operating system, sorry.   
   Similarly, the people I know who worked on OpenBoot did not   
   consider it a real operating system in the way they thought of   
   SunOS.   
      
   Now my question to you: why do you care what specific label   
   people apply to MS-DOS?   
      
   	- Dan C.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)