From: commodorejohn@gmail.com   
      
   On Tue, 11 Mar 2025 17:28:44 -0000 (UTC)   
   cross@spitfire.i.gajendra.net (Dan Cross) wrote:   
      
   > 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.   
      
   I mean, asynchronous I/O is certainly a nicety, but why does not having   
   it make an OS not "real?"   
      
   > 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.   
   >   
   > 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.   
      
   So an OS that is specifically tied to a particular architecture and   
   uses specific sequences of instructions is "not a real OS?" Funny, you   
   never hear that against ITS.   
      
   > 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.   
      
   Absent any means of hardware protection, "segmentation" on the part of   
   the OS is a gentle suggestion at best; it cannot even protect against   
   an *errant* process, let alone a malicious one. DOS also uses the   
   segmented model to allocate space to applications/drivers/etc., but   
   pretending that this actually impedes hazardous behavior is just empty   
   security theater.   
      
   > Not true.  It supported segmentation.  It's harder to corrupt   
   > RAM if it's not in a segment that's currently addressible.   
      
   Again *there is no protection.* None whatsoever. Altering the segment   
   registers is a non-privileged operation on the 8086, and the address-   
   translation mechanism is a simple shift-and-add; it is trivial for any   
   process to write to any part of memory, whatever its initial segment-   
   register values were.   
      
   > 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.   
      
   MS and IBM did in fact try to extend DOS using the capabilities of 286   
   protected mode, under both Windows/286 and OS/1 v.1. Neither worked   
   well or saw wide adoption, because the 286 was terrible. By the time   
   the 386 was gaining significant acceptance, MS was already moving on to   
   Windows NT, which eventually did offer protected (if limited) DOS   
   support via NTVDM.   
      
   > Now my question to you: why do you care what specific label   
   > people apply to MS-DOS?   
      
   Primarily because Certain Types insist on parroting the same pithy   
   dismissals over and over again, year after year after year, for no   
   readily apparent reason and despite their arguments being predicated on   
   nonintuitive definitions of common terms, which are in the best case   
   overly narrow and, in the least charitable interpretation, pretty   
   clearly constructed to support the argument they wanted to make.   
      
   Now, in fairness to yourself, Scott is the one who's really been   
   tossing cherry bombs in the toilet here, and I think you're catching   
   some flak that really ought to go his way; but you *also* are insistent   
   on defining common terms in such a way as to exclude things that pretty   
   much anybody without a partisan stake wouldn't hesitate to count in   
   with the group - it's not enough, apparently, to say that MS-DOS is a   
   *simplistic* OS, or even *not a particularly good one,* but that it's   
   somehow not *really* an OS at all, even though you yourself admit that   
   it does fundamentally fill the role of one:   
      
   > So it's hard to see how DOS really qualifies as an OS, despite   
   > the OS-like abstractions it provides.   
      
   So why the semantic games? What is the actual *point* to this argument?   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)