What MS-DOS Can Do That Linux Can't

> Work with only 3 files [...] Boot in under 5 seconds [...] Use commands without spaces [...] Run CPU opcodes natively [...] Be real

I have a little PCB here on my desk that runs linux with 2 files: vmlinux and busybox. It boots in about two seconds and yes, it runs CPU opcodes natively.

I'm not sure how being able to use commands without spaces or running in real mode is considered better or worse than the alternatives.

> MS-DOS requires only 3 files to boot: IO.SYS, MSDOS.SYS, and COMMAND.COM.

Yes, although it is helpful to have other files, such as DEBUG. These are still smaller and faster files than a lot of modern ones, though.

> Run CPU opcodes natively

Other operating systems do too; most systems use native code. They mention the executable file format, which has to do with the operating system rather than how the CPU executes the program.

DOS has COM and EXE format. COM format is just the plain program code that runs, although there is still how the operating system is setting up the memory and stuff for running the program; it still isn't quite directly. EXE format is a more complicated format.

> Not to mention the fact that Linux is hard to fit in real mode because the kernel is so large. Getting it into 1 MB of memory is a trick. The MS-DOS kernel fits into a fraction of that space, with room to spare.

This is a benefit of DOS (it doesn't need a too large kernel), although there is also unreal mode, in case you want to be like real mode with more memory.

Of course it would be nice to also see that kind of stability in modern systems, but since that seems to be impossible for no good reasons the next best thing is to run applications in a dead OS like DOS that has good emulators.

you can add those commands (as functions) to linux, but it would be a boneheaded thing to do.

  cd.. () { 
    cd ..
  }

A real mode that provides a sane 32 or 64 bit address space, with the MMU disabled, would be totally cool.

That little detail is what I find most annoying when switching from Windows to Linux while having a life time of windows muscle memory in your fingers.

Quick search on google using site search (site:http://webarchive.me) produces only this site (that is - google is not indexing the site... sigh).

One thing that I would add is that you fully configure MS-DOS using just a few lines of text in AUTOEXEC.BAT and CONFIG.SYS. And that includes setting up many applications and the user's shell.

There was also no mention of FreeDOS. That would be a better OS to bring up if we are comparing to Linux. It has been around since 1994, but maybe that article is old enough that FreeDOS had not yet became the de-facto standard DOS yet.

  A220 D5 I1

(Btw. it's utterly strange that the English Wikipedia doesn't seem to mention anything about "multi-user". One of Linux's /key functionalities/.)

dir/s filename

I know there are many ways to do the same thing in Linux, but they are all more complicated and because I am getting old and don't use the command line much anyway, none of them have stuck in my mind.

In general I can use dir more effectively than ls. I know this means I'm a bad person.

Perhaps there would be advantages to having DOS got re-written in Rust? No more hand-crafted machine language or c/C++... I wonder if the world is ready for DOS everywhere :)

I still loved to read it because it seems to represent people from a old time. The usual "no no no, new thing bad because old thing can do brrrr" without really going into any specifics at all. But from probably 25 years ago. I liked it.

> Windows XP is not real Non-NT-based versions of Windows can be booted in real mode, which is the opposite of what Windows used to call 386 enhanced mode. In real mode, programs actually run in your computer's real memory space, instead of having virtual memory spaces (or "virtual machines" as Java programmers like to call them) allocated for them. While virtual mode, protected mode, or whatever you want to call it is useful for everyday multitasking, it's simply absurd to create a commercial operating system that doesn't allow software to directly interface with hardware. Try changing your interrupt vectors or PIT timing in Windows XP. Simple tasks like these, which could be easily done in real mode, become impossible with Windows XP. [0]

In this article:

> Protected mode is a kludge to prevent people from hurting themselves when they don't know what their software is doing.

It seems the author doesn't have a firm grasp of what are real and protected modes and even what an operating system does.

[0] http://webarchive.me/geocities/SiliconValley/2072/whyxpbad.h...

> MS-DOS requires only 3 files to boot

You can do it in two for Linux. The kernel image itself (packaged as a bootable EFI program if you want to keep it simple and avoid a bootloader), and then an initramfs (built into the kernel image) that has busybox in it. Ok, I guess the 'sh' symlink you'll need to boot into is technically a third file. So it's a tie.

Yes, this Linux setup will be very limited and annoying to use, but so will a DOS setup that only has the three DOS boot files mentioned.

> Boot in under 5 seconds

The setup I describe above will boot in much less than 5 seconds. DOS may still boot faster, but the difference will likely be imperceptible, especially if you compile a Linux kernel that has hardware support capabilities similar to the bare-minimum three-file DOS setup.

> Use commands without spaces [...] This is a big deal, even if it might not seem like it.

I don't see this as a big deal, and I'm not sure why this is all that useful or important. If someone really wanted to, they could write a shell or a shell wrapper that could allow you to do stuff like this, but it's telling that no one has bothered.

> Run CPU opcodes natively

I'm again not sure why this is useful enough to be necessary, but sure, let's just say I lack imagination here and give this point to DOS.

I'm sure if I wanted I could write a kernel module or maybe even a binfmt_misc setup that would make this work, though presumably at the expense of the default behavior, which treats non-ELF (or otherwise unsupported) files as shell scripts. Again, it's telling that no one has bothered.

I'll also note that, while yes, DOS will run .COM files, which are basically just a list of machine instructions, most software distributed for DOS, at least in its later years, used the MZ/.EXE format. Certainly that doesn't make it so DOS can't run machine code directly anymore, but, again, it's telling that the more "complicated" format ended up being used more commonly. Maybe that means there's something useful about it. Like its ability to be larger thank 64KiB.

> Linux generally doesn't run in real mode.

Which is fine, and good. The author's justification for why it's better/useful that DOS allows this sounds like the usual elitist "programmers should just be perfect and make sure they never write programs that have any memory-safety bugs" nonsense that I hear some people use to justify writing C code when there are suitable alternatives that are safer.

Regarding getting the Linux kernel to fit in real mode, I imagine if you are setting up a Linux computer so it can do a similar level of things that DOS can do, you can probably disable a lot of kernel options and get it down far enough in size.

DOS was a great OS. I used it a ton in the '80s, and even when we were able to get a copy of Windows 3.0, I still mostly used DOS. It had its place in history, but trying to compare it to Linux is about as apples-and-oranges as it gets.

DOS has no User Login like Linux and is insecure as a result.

DOS is still being used by NASA and other places.

I want to write books on DOS programming using PowerBASIC 3.5 and other languages to help the newbies learn DOS programming.

This is not correct. The difference between the examples is not whether the computer runs machine language, it's how the code is wrapped for delivery. The above hyperbolic claim will mislead people unfamiliar with computer programming and add to an unwarranted atmosphere of mystery.

> In MS-DOS, you can type a command like "cd.." to move up a level, and it will work fine. In Linux, it will not; you need to type "cd ..". The different [sic] is the space in between.

No, grammar issues aside, the difference is that Linux rejects special cases that shouldn't exist. Command-line commands should be consistent and the parser should reject operator errors in a robust and repeatable way. Were this not true, a command-line parser would take:

    # rm-rf/*

The above example, were it to exist, would mix commands and arguments in a way that would make black-hat hackers' lives very easy.

That is its beauty and its pain.

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.)