There was lots of uninformed, false equivalence, rubbish like this put about during the time of the "Operating System Wars" in the 1990s. I saw lots of it go by. This is just more utter rubbish in the same vein, to be blunt. From the turn of the 21st century, going by its mention of Windows XP. So tail-end rubbish, too.
The idea that MS-DOS is small and "perfect" is belied by so many things, from the existence of DR-DOS (Clearly one could improve on "perfect", spurring "perfect" to catch up.) and PC-DOS (Clearly "perfect" lacked the E editor.) to all of the many complaints that MS-DOS users had based upon what they saw in other operating systems, and wished MS-DOS could do.
Like stopping buggy programs from "poking values into memory" (to use the words of this very article) and thereby breaking other programs, for starters. Anyone who thinks that this article going on at length about the beauty of real mode at the turn of the 21st century reflects mainstream thought, wasn't there in the 1980s when protected mode came along and everyone wanted the sort of resilience against rogue code that the multi-user mainframe world had been enjoying for decades. We got lots of attempts at it, from Multiuser DOS to QEMM.
In fact, the author is writing at a time when people were anticipating an era when there was no real mode involved anywhere on PCs. With EFI and no compatibility support, and the demise of boot managers that sit in the virus areas of hard discs, we are pretty much there nowadays for some people.
The "CPU opcodes natively" explanation reveals the author's lack of knowledge here, which shows how little credence should be given to the rest of the piece, but was so typical of the technically illiterate drivel that was circulated during the OS Wars. Knowledge of MS-DOS, that is. MS-DOS files had a non-trivial executable format. In fact, in later years they had several. There was the MZ file format, and "Family API" dual OS/2 and MS/PC-DOS programs had the NE file format. Some "DOS extenders" such as Phar Lap's employed the PE format. Of course, it is non-technical gibberish to assert that this means that programs are "not sending basic commands to the CPU" when their program image files use a non-trivial executable file format. (Talking of programs sending commands, rather than processors fetching instructions, reveals the ignorance here.)
As the author of a clone of Microsoft's/IBM's CMD, I can tell you outright that the "commands without spaces" point is more ignorant crap. In reality, as Rex Conn also could attest, the command-line parsing that allowed "CD.." and "DIR/P" was an awful irregular ad-hoc mess. After all, it only allowed that for some commands, and some punctuation (there was a table), and only at that specific point in the command line. Whether one could, say, combine options like /P/A:D was up to each individual command to implement. Then there was SWITCHAR. More at https://news.ycombinator.com/item?id=39187762 .
Also in reality, people never complained when we command interpreter authors said in no uncertain terms to separate commands from arguments with spaces, because this wasn't CP/M or DCL, and pointed to the the fact that the railway diagrams in the IBM Command Reference allowed no such syntax. And of course, back in the 1980s people actually wanted the MS-DOS command line to work more rationally, and more like Unix. MS-DOS version 1 was not actually "perfect", either, and needed subdirectories and file handles and other Unix-like stuff.
Other people I am sure are going to demolish the twaddle that is the other points. I shall just point out that (for 1 example) OpenBSD can boot with only one file, if that file is /bsd.rd , and bootstrap times was another point fatuously argued over and over during the OS Wars, with little regard to inconvenient facts like the spec requiring that any operating system allow up to 30 seconds for ATA hard discs to initialize at power on. (In modern systems like the RaspberryPi there are still similar inherent insurmountable delays that no operating system can overcome. Only home computers with BASIC in ROM really achieved this instant-on ideal.)
The idea that MS-DOS is small and "perfect" is belied by so many things, from the existence of DR-DOS (Clearly one could improve on "perfect", spurring "perfect" to catch up.) and PC-DOS (Clearly "perfect" lacked the E editor.) to all of the many complaints that MS-DOS users had based upon what they saw in other operating systems, and wished MS-DOS could do.
Like stopping buggy programs from "poking values into memory" (to use the words of this very article) and thereby breaking other programs, for starters. Anyone who thinks that this article going on at length about the beauty of real mode at the turn of the 21st century reflects mainstream thought, wasn't there in the 1980s when protected mode came along and everyone wanted the sort of resilience against rogue code that the multi-user mainframe world had been enjoying for decades. We got lots of attempts at it, from Multiuser DOS to QEMM.
In fact, the author is writing at a time when people were anticipating an era when there was no real mode involved anywhere on PCs. With EFI and no compatibility support, and the demise of boot managers that sit in the virus areas of hard discs, we are pretty much there nowadays for some people.
The "CPU opcodes natively" explanation reveals the author's lack of knowledge here, which shows how little credence should be given to the rest of the piece, but was so typical of the technically illiterate drivel that was circulated during the OS Wars. Knowledge of MS-DOS, that is. MS-DOS files had a non-trivial executable format. In fact, in later years they had several. There was the MZ file format, and "Family API" dual OS/2 and MS/PC-DOS programs had the NE file format. Some "DOS extenders" such as Phar Lap's employed the PE format. Of course, it is non-technical gibberish to assert that this means that programs are "not sending basic commands to the CPU" when their program image files use a non-trivial executable file format. (Talking of programs sending commands, rather than processors fetching instructions, reveals the ignorance here.)
As the author of a clone of Microsoft's/IBM's CMD, I can tell you outright that the "commands without spaces" point is more ignorant crap. In reality, as Rex Conn also could attest, the command-line parsing that allowed "CD.." and "DIR/P" was an awful irregular ad-hoc mess. After all, it only allowed that for some commands, and some punctuation (there was a table), and only at that specific point in the command line. Whether one could, say, combine options like /P/A:D was up to each individual command to implement. Then there was SWITCHAR. More at https://news.ycombinator.com/item?id=39187762 .
Also in reality, people never complained when we command interpreter authors said in no uncertain terms to separate commands from arguments with spaces, because this wasn't CP/M or DCL, and pointed to the the fact that the railway diagrams in the IBM Command Reference allowed no such syntax. And of course, back in the 1980s people actually wanted the MS-DOS command line to work more rationally, and more like Unix. MS-DOS version 1 was not actually "perfect", either, and needed subdirectories and file handles and other Unix-like stuff.
Other people I am sure are going to demolish the twaddle that is the other points. I shall just point out that (for 1 example) OpenBSD can boot with only one file, if that file is /bsd.rd , and bootstrap times was another point fatuously argued over and over during the OS Wars, with little regard to inconvenient facts like the spec requiring that any operating system allow up to 30 seconds for ATA hard discs to initialize at power on. (In modern systems like the RaspberryPi there are still similar inherent insurmountable delays that no operating system can overcome. Only home computers with BASIC in ROM really achieved this instant-on ideal.)