Why DOS was (and is) a thing (2020) [video]
youtube.com
youtube.com
In my opinion, it was amazing. Prior to graphical user interface, various DOS were the only interface in non-*nix world. Beating it up because it was not up to 2021 standards, is like beating a horse because it is not as fast as a car, does not have a blinking turn signal, and of course the suspension is too rough. I was delighted moving from writing things down in paper first to be able to do command line in DOS. Sure, it was not Unix, but was getting closer.
TSRs and various memory tricks demonstrates its flexibility at that time, despite hardware and firmware limitations. We wrote myriad of tiny programs, that often functioned like *nix programs, and became part of the users' ecosystem, albeit lost as soon as the user or programmer gave up.
Yes, I am going to be counter argumentative. :)
I still want a Gray Planer (a huge old obsolete machine tool) taking up a huge chunk of my garage, for zero practical reason. Though I'd settle for a benchtop shaper.
A lot of programs were written back in the days of MS-DOS that people got used to using, and they still work. You can't directly run MS-DOS programs anymore. You used to be able to right up to Windows 7, 32bit.
If you've got an old program that still does a job, you're used to it, why change anything?
There are programs that talk to hardware that run on MS-DOS, those programs and hardware represent a huge investment of time and effort, writing the program, building the hardware, and especially debugging the system. If you have those systems in production, you're going to do every single thing you can just to keep them running. You are certainly not going to risk any changes to a working system in the name of efficiency, especially if your business, or job, depends on it.
In many, many cases the original people, documentation, and decisions that went into the design are all unavailable, and all you have left is the artifact that works reliably if you maintain it and feed it proper inputs.
Museums and Archivists need to run old software to be able to retrieve old documents. For most cases, you could use DOSbox, or QEMU , but sometimes you need the old programs on the old hardware.
Finally, and likely most importantly, is nostalgia. For many of us our first real computer was an IBM compatible running MS-DOS. Because you can't buy DOS any more, FreeDOS does the job.
One common use case was control/monitoring software for some specialized piece of external hardware such as test/measurement equipment, security, HVAC etc. Much of this has modern substitutes available on current platforms, but it requires replacing the hardware as well as the software. Given that people paid 5+ figures for this stuff back in the day and if it still works, might as well keep using it until the wheels come off.
Microsoft was late to the GUI party. Other platforms like Apple, Atari, Acorn, etc had proper GUI operating systems long before Microsoft did.
Also DOS wasn't even the only non-GUI outside of UNIX. Micro computers had BASIC (which was a lot more powerful than DOS in some ways) plus support for Pascal, LOGO, and other languages on ROM too. They could also run other operating systems such as GeOS, CP/M and others many wouldn't have heard of. There were also LISP machines, dumb terminals which would access "green screen" TUIs, and a whole slew of other niche systems out there.
DOS won because IBM-clones took over the world. DOS won because the hardware was cheap to clone not because the OS was the best of the era. Albeit it's fair to say once the momentum got behind IBM-clones DOS then continued to dominate due to people getting locked into MS-DOS applications. But DOS was never a particularly interesting operating system. If anything, CP/M was more interesting because it came several years before DOS, solved the hard problems that people took for granted with DOS, and ran on systems with far lower system memory (it was also the operating system that IBM PCs were originally intended to run -- but I'm sure you all know the conflicting stories behind that piece of history)
In a large number of cases, that BASIC was Microsoft's, as well. So they were already dominating the non-GUI realm of personal computing.
For a one-user, one-task computer, you didn't need much of a proper OS anyway.
That was standard across all the major dialects of BASIC in that era.
Personally I was less impressed with Microsoft BASIC compared to the European counterparts.
What I never understood was in the early 80s the UK had a real lead on the computer industry with Amstrad, Acorn and Sinclair all doing some really interesting stuff. But by the late 80s / early 90s all the UK systems had disappeared and replaced with Japanese consoles and American home computers. Don't get me wrong, I have nothing against Japanese nor American corporations -- it just feels like a real loss for the UK to go from world leaders to just another consumer.
And not so tiny, too - DOS extenders made memory constraints practically nonexistent.
it was not up to 1982 standards
DOS development was done on unix; microsoft developers used unix, so microsoft doesn't even agree with you.
The original Microsoft C for the 386 was a Xenix product although the OS/2 1632 cross compiler was certainly around in 1991 when everything was going the way of Windows NT.
The original 1991 NT pre-release could even make OS/2 2.0 32bit OMF objects.
However, if low-energy x86 compatible SBCs (with compatible BIOS-a-like) ever become more than a niche thing, then having fast DOS booting into single purpose apps would be a nice addition to the space currently dominated by Linux and all those ARM boards.
I can't see it happening though.
Works pretty well.
8086, to be specific.
Indeed - looks like the older the software, the more efficient it is.
- Older software might run less efficiently on newer hardware because they don't support newer hardware (eg CPU opcodes) and thus perform the same calculations in software. This is most visibly true with games that are software rendered in DOS rather than hardware rendered.
- Older software might not take advantage of smarter algorithms that have been discovered more recently. This is best observed in the modern demo scene
- Older software might run faster but that might simply because they don't support modern requirements (eg cryptography, memory protection, or even error / crash handling). This is probably the closest to the "efficient" argument but I'd counter by saying the code isn't "more efficient", it's "less functional". Sometimes less functional is exactly what you want (eg why spin up Microsoft Word if all you want to edit is a plain text file) but it's still not the same as saying "more efficient".
As to solving old hardware in software, I'm starting to see HDL as a solution to dealing with this. I've been watching the MiSTer project for a while now as a way to capture old hardware on a fairly large FPGA.
I've read on here about people running such hardware in DOSbox but it's not a problem I've needed to solve personally. However since DOSbox is an emulator (as opposed to FreeDOS which is a "just" an OS), I wouldn't be surprised if DOSbox handled those situations fine.
In a game, all that would happen is a little glitch that may or may not be noticeable.
If it's the latter than I see your and the GP's point about RT. :)
Someone with an inclination could probably make a python controller or something but it's probably cheaper and safer to just buy new machines.
The whole system is closer to an appliance than a general-purpose computer. You start the data acquisition software (literally one keystroke--we have it aliased to "t"), set some options with the keyboard, and the data is streamed out over ethernet or a DAC.
The fact that nothing else is running in the background makes it pretty easy to keep real-time guarantees and the fact that it's DOS keeps people from messing with it. I have no doubt that you could probably get a modern Windows/nix system to run the tracker AND do other stuff, but I really doubt it would be worth the effort--it works surprisingly well.
I'm sure there's some sort of "microcontroller" that can do this, but an Arduino isn't it. If they had massive volume, I'm sure an ASIC could do it too, but since it's a niche application, an COTS x86 might be near the sweet spot of price/hassle.
That said it wasn’t a great OS for it’s time and isn’t for most purposes today.
Yeeeep seems canon.
You're also forgetting just how painful it was setting up a working autoexec.bat file in the first place. Never mind having dedicated chunks of code for some games and not others (eg do I need a mouse in this game? that driver is incompatible with this other bit of software, etc), just discovering what precise string of characters in your autoexec.bat was required to load the damn driver could be downright cryptic at times.
DOS wasn't that great. We remember it with rose tinted glasses because that's what humans do. But DOS wasn't a particularly good operating system, even for its era.
Gaming on DOS, now that was fun. But I'd argue it was fun in spite of DOS rather than because of it
Also there were plenty of text-based office apps that required their own dedicated autoexec.bat config too.
It sucked.
Ah, Wikipedia says it's since MS-DOS 6.
Then when networking started to be more common, choosing between loading an IP stack or pretty much anything else :)
You're describing the same thing I was :)
> Imagine having to choose between loading mouse drivers, or loading sound drivers.
Indeed. This is why I don't get when people look back to DOS and say "wasn't it great".
Also the hell of having to configure sound card drivers. The commands that needed to be entered precisely with no clue about why things don't work if they don't. You'd often end up spending hours, days or weeks just getting something simple working. And most people didn't have internet access then so you couldn't just look up the problem on Stack Overflow. People moan about Bash scripts being hard to parse, autoexec.bat was a thousand times worse to work with.
Modern UEFI is probably the best parallel, both in that it only really deals with text and some graphics (bitmaps only) and doesn't have any standardized interface for sound/3d.
And to make a point, I started coding in 1986 and my first UNIX was Xenix.
We are not going to do another dos game. No amount of flaming hate
mail is going to change my mind on this (PLEASE don’t!). The advantages
of good TCP/IP support, dynamic linking, powerfull virtual memory, device
drivers, etc, are just too much to overcome. Yes, all of those can be
provided under dos in various ways, but it just isn’t worth it.Sometimes those updates cause printers or other peripherals to stop functioning. Sometimes they brick your computer.
Once you have a computer working properly, running MS-DOS, Windows, Linux, etc... for the most part it stays running, forever... unless you change something.
MS-DOS 6.21 with all the drivers, SideKick loaded as a TSR, and my 26th line clock program, with a 40 megabyte hard drive was a heck of a productive environment. The only thing that sucked was that we didn't have GIT, so you had to back up your source code to .zip files on floppy disks.
I had a 300 megabyte backpack hard drive to allow me to make backups of my system, and customers. Plug that drive into the parallel port (that all computers had back then), and a book floppy, and all my stuff was right there.
In order for personal computers to be feasible they had to be cheap enough for people to afford, which meant they had to be downright primitive by today's standards. The OS as well, by extension. As mentioned in the video, early DOS is basically a boot loader, a few utilities, and a program loader written in assembler. That's it. Everything else is done by applications that have full access to the hardware. It even dumped the shell out of RAM while a large application ran, which is why it would run the floppy on exit looking for it.
More substantial OSs already existed of course, Unix and VMS for example, but they came with million dollar price tags. Xenix was ported to the PC with the 286 I believe, but it wasn't cheap or practical for a while, and worse is better as the saying goes.
The 386, Windows, and Linux weren't feasible until a decade later.
it even resembles DOS (much more than it does any other os, at least)
https://en.wikipedia.org/wiki/Loadlin
(I love the idea of a bootloader I could play Doom on!)
I know what you mean, but what about GRUB and UEFI? I think both of those could be supplemented to be able to do a lot of the same things, don't you think?
Sure you can also get a different embedded solution but you're going to be writing bare metal. DOS is a nice step up for these very low level use cases and very easy to develop for.