HN Theater @HNTheaterMonth

⬐ mattowen_uk

The thing about DOS is that it leverages the IBM style BIOS heavily. Unlike Linux, it's not just a case of recompiling DOS so that it works on different architecture. having DOS boot natively on a Pi sounds attractive but isn't feasible.

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.

⬐ marcodiego

On the other hand, wherever you had a compatible bios and processor it was easy to run DOS and CP/M on it. This made both systems very popular until ibm-compatible became the standard and apps wouldn’t run on anything else.

⬐ hnlmorg

DOSbox already flies on a Raspberry Pi. I think this is one of those instances where the technology in question (DOS) is so old that it makes more sense to solve it in software than it does in hardware.

⬐ milesvp

DOSbox is great for games, and other Non real-time uses. I'm not sure that you get the same timing precision and variance in DOSBox as you do with DOS on hardware. I'd be curious if older CNC machines have had luck replacing their aging hardware with newer machines running DOSbox.

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.

⬐ hnlmorg

Games are probably more real time than CNC machines since you're dealing with short feedback loops between user interfaces the frame buffer. It's more the esoteric drivers that are going to be an issue with those CNC machines.

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.

⬐ userbinator

CNC is definitely more "real time" in the sense that if the timing isn't right, a tool crashes into the work.

In a game, all that would happen is a little glitch that may or may not be noticeable.

⬐ hnlmorg

It's been a looooong time since I've worked with CNC machines but doesn't the machine itself cache the instructions? Or is the PC the controller?

If it's the latter than I see your and the GP's point about RT. :)

⬐ genewitch

The old machines wouldn't buffer that much, and newer cheaper machines (including every 3d printer I've used) still expect a stream of data in real time.

Someone with an inclination could probably make a python controller or something but it's probably cheaper and safer to just buy new machines.

⬐ Koshkin

> is so old

Indeed - looks like the older the software, the more efficient it is.

⬐ hnlmorg

That's a fun comment people like to quote but as someone who's been writing software since the DOS days, I can tell you it's not really true.

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

⬐ csnover

These are all great points. Something else I would add to the list is that older software would often run using a busy loop[0]. This was ‘fine’ on contemporaneous CPUs that didn’t have any low-power modes, but on a modern CPU it means that older software will use 100% of one CPU core and force it to stay running at its maximum frequency while doing no work at all.

[0] https://en.wikipedia.org/wiki/Busy_waiting

⬐ hnlmorg

I'd say that's covered under the first point since it's a newer added hardware instruction (`HLT` I believe). But it's definitely another very good example of the first point.

⬐ Rerarom

yeah the x86 is a DOS machine the way Lisp machines are Lisp machines (or something like that, I admit I cannot find a properly slick way to express it)

⬐ Koshkin

> x86

8086, to be specific.

⬐ zozbot234

The modern equivalent to DOS is just the UEFI shell. No reason why it couldn't be supported on the Pi too - AIUI, there's a free implementation of UEFI that can be loaded from uboot.

⬐ rwmj

I'm using UEFI on my Raspberry Pi 4: https://github.com/pftf/RPi4

Works pretty well.

⬐ mattkrause

My lab has some modern equipment (high-speed eye trackers) uses DOS host computers.

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.

⬐ zozbot234

You'd probably reimplement this stuff on a microcontroller, rather. Perhaps interfacing with a general purpose system for configuration and data output.

⬐ tenebrisalietum

Wouldn't an implementation of the DOS API basically fit on any modern microcontroller these days?

⬐ anthk

You mean the X86 BIOS? No.

⬐ tadfisher

There is already a working PC emulator for ESP32, and the 86duino is a thing.

⬐ anthk

Unusable for near real time tasks DOS did.

⬐ quietbritishjim

"Real time" does not mean fast. It just means with guaranteed (or at least predictable) performance.

⬐ Koshkin

How so? The 8086 emulated on ESP32 is faster than the real one.

⬐ mattkrause

The equipment I have is doing some real-time image processing on a 2000 Hz video stream (it extracts head/eye positions for vision research).

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.

⬐ MichaelMoser123

DOS was a terrible user experience; there was this constant fight to keep all the drivers and TSR programs working, deal with high memory, extended memory and other goodies, when the system was running out of low memory. Thanks goodness we are past that. No nostalgy for DOS on my part...

⬐ ghaff

DOS was OK so long as you stayed comfortably within 640K and avoided all the pseudo multitasking hacks like TSR. The things you describe are all about pushing DOS beyond it’s rather limited fundamental design.

That said it wasn’t a great OS for it’s time and isn’t for most purposes today.

⬐ hnlmorg

It was pretty common for people to need different autoexec.bat configurations even just amongst gamers.

⬐ ghaff

Yes, mostly because you were screwing around right at memory and other limits of the system. (And it was mostly games--at least for typical consumers.)

⬐ hnlmorg

You're vastly understating just how commonly people would butt head with those limits though.

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

⬐ ghaff

Once you get into games, especially beyond monochrome text-based or maybe CGA, you were already pushing the limits. DOS was an OS for essentially text-based office apps in the early 80s and it just got pushed well-beyond that over time. And, yes, it made getting it set up for anything that wasn't a lowest common denominator setup very challenging.

⬐ hnlmorg

In which case you've basically described the vast majority of DOS's common use cases. So why even argue against my point?

Also there were plenty of text-based office apps that required their own dedicated autoexec.bat config too.

⬐ leeter

Pulls up a recent LGR Video... watches griping about various expanded vs. extended vs. whatever memory issues games have

Yeeeep seems canon.

⬐ brk

Or sometimes more commonly, an AUTOEXEC.BAT that provided the user a menu for which "mode" they wanted to boot into. Imagine having to choose between loading mouse drivers, or loading sound drivers.

Then when networking started to be more common, choosing between loading an IP stack or pretty much anything else :)

⬐ hnlmorg

> Or sometimes more commonly

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.

⬐ DarknessFalls

I had a batch file just to swap autoexec.bat and config.sys with *.bak counterparts depending on the game.

⬐ ZetaZero

The best thing was, a reboot took 10-15 seconds, IIRC.

⬐ MichaelMoser123

on a 486 or a pentium, i think it used to take longer before that.

⬐ rhacker

Yep, for me it was those damn mouse drivers that took up so much of my ems memory.

⬐ ubermonkey

I had an elaborate batch-file based scheme for swapping in different versions of both autoexec.bat and config.sys, depending on what I needed/wanted to do.

It sucked.

⬐ beervirus

Ha, me too. And although I do look back on those days with rose-colored glasses… it did kind of suck having to futz with that stuff just to get a game to load.

⬐ mixmastamyk

The hardware sucked too! IRQ conflicts and changing jumpers! And better not close the case before you verified the new settings. :-D

⬐ mook

I think newer versions of config.sys (relatively speaking) had a menu system that greatly simplified that. It would set some environment variable to let autoexec.bat jump to the correct section too, I believe.

Ah, Wikipedia says it's since MS-DOS 6.

⬐ ubermonkey

I don't even remember that -- but I suspect it's because by the time Win 3 was a Thing, I was working in it almost exclusively and had little need for DOS-based things. I'm not sure I ever ran DOS > about v 5.

⬐ Koshkin

DOS extenders solved the 640K limit problem.

⬐ MichaelMoser123

don't know who said that 640K is enough, but it was very common to hit this limit in my time, around 1992-1993.

⬐ leeter

DOS seems to have been the minimal effort choice of "It's like CP/M enough our users will be familiar with it" without actually considering those users. Now to be fair in 1981 that was "state of the art". The Xerox Alto was something that was way beyond reach for most people and GEOS (8 or 16bit) wasn't going to exist for another 5 years. But it was a marginal improvement over CP/M, which is about as much as one can say about it.

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.

⬐ p_l

Interestingly enough, UEFI ships with UI toolkit. This can be partially customized by vendor, but essentially the idea is that for many simpler utilities and config panels, you can don't have to worry about details and just use a basic UI framework which will be handled into VT-UTF8 or GUI as needed.

⬐ ghaff

There were better 16-bit OSs in the minicomputer world at the time but they were all priced and developed for a very different world. It would have been interesting if something like RDOS (Data General) had taken off in the PC world but that world was just so price-conscious in comparison. Heck, the 8088 was chosen over the 8086 mostly just to have a smaller data bus.

⬐ mikewarot

Windows is still a terrible user experience, you never know when it's going to stop working for half an hour or longer in order to run an update.

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.

⬐ pjmlp

Given the amount of stuff people keep publishing for UNIX terminals, I would say plenty love to live in the past.

⬐ adwn

You think the DOS shell is in any way equivalent to a modern Unix-style terminal? Why, because they're both text-based?

⬐ pjmlp

From the point of view of TUI fetishism, yes.

And to make a point, I started coding in 1986 and my first UNIX was Xenix.

⬐ icedchai

Plus consider that "modern" Unix terminals have barely evolved over the past 30 years. My circa-1990 NeXTStation is an incredibly slow version of what we have today. I even compiled bash for it!

⬐ theodric

For some things, e.g. mass-rename, or glob select file management operations, CLIs are much faster than click-click-click GUI operations. I use both, and I don't consider it to be living in the past to use the best tool for the job rather than using the newest thing because it's new.

⬐ pjmlp

That is a big difference between that and living in a VT100, using VI directly from there, with a Window manager that has feature parity with twm, assuming one is used at all.

⬐ chakkepolja

Why do you bash* them so much? In almost every thread.

⬐ pjmlp

Maybe because luddites slow down progress.

⬐ anthk

A pencil and rubber still work and often a modern pen is not better. FM radio "degrades" better than DAB. And so on.

⬐ pjmlp

They do, yet seldom do people go over the edge to keep doing 100% of their work with pencil and rubber.

⬐ pjmlp

I don't know, because they are responsible for the success of GNU/Linux desktop?

⬐ hulitu

TWM is quiet nice. And if we look at Windows 10 i would say it is also modern.

⬐ AnIdiotOnTheNet

But the 70s era byte-stream oriented command line tools that are still in common use are riddled with footguns and present all sorts of difficulty for more complex tasks that something like PowerShell handles with relative ease. Yet the mere fact that I've mentioned PowerShell now virtually guarantees that someone will complain about it because it isn't exactly bash.

⬐ Rerarom

Imagine how much you'd be valued for that sort of knowledge!

⬐ sixothree

Most of those things are a limitation of the hardware.

⬐ bluedino

Carmack:

    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.

⬐ mixmastamyk

DOS was a thing because computers were so expensive in the early 80s. Like incredibly expensive for paltry specs and performance that you wouldn't even take for free today. Thousands of 1980 dollars.

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.

⬐ hdjjhhvvhga

In another video[0], the author demonstrates writing programs for FreeDOS using conio.h. I believe it would be more useful to use PDCurses instead - just in case your program turns out more popular than you had anticipated.

[0] https://www.youtube.com/watch?v=OGeLIWAkncQ

⬐ marcodiego

One thing I like about DOS is that it is an useful OS and bootloader. In the win9x days it allowed me to use the computer even when windows broke. I see no replacement for it in the free world, freedos has no support to linux file systems and it is becoming increasingly hard to run it on modern hardware. I really would like a modern replacement for it.

⬐ Koshkin

> bootloader

https://en.wikipedia.org/wiki/Loadlin

(I love the idea of a bootloader I could play Doom on!)

⬐ leeter

I'll do you one better, DOOM without an OS at all (sort of) https://github.com/Cacodemon345/uefidoom

⬐ mixmastamyk

The Linux console has more functionality than DOS ever did, sans GUI.

⬐ guerrilla

> I see no replacement for it in the free world

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?

⬐ marcodiego

Grub is great but has no write access and doesn’t allows me run eg. run a full compiler.

⬐ AshamedCaptain

Well, the UEFI shell does.

⬐ AshamedCaptain

what about the bog-standard efi shell that comes in the firmware with practically every PC these days?

it even resembles DOS (much more than it does any other os, at least)

⬐ hnlmorg

There's plenty of live CD / USB OS's out there (albeit most being based on Linux). I've found they've more than covered my DOS use case of "I need to boot something in order to examine this busted computer".

⬐ 1970-01-01

DOS did alright. It was never meant to be anything more than a basic CLI OS, and when everyone pushed it beyond that primary role, quirks and problems would appear, just like any other complex program.

⬐ Koshkin

This doesn't sound right to me - there was plenty of GUI-based applications, and having DOS at the base was usually not a problem (as long as you have the right device drivers - a problem not exclusive to DOS).

⬐ 1970-01-01

There really weren't device drivers in DOS. Programs would include drivers for running peripheral devices, and then YOU had to configure each one to work with DOS. This was the biggest problem with DOS. These programs talked directly to the hardware. Once TSR drivers were combined with CD-ROM and sound drivers, things would be very quirky during a GUI install. I remember Peter Norton put out some very good DOS books, and he wrote a few chapters about common issues with "Multimedia PCs".

⬐ p_l

I recall that Peter Norton was also considered responsible for why many DOS applications required pretty much error-for-error IBM compatibles - because he advocated for directly dealing with hardware and disregarding DOS APIs (which, admittedly, were bad)

⬐ prewett

The only reason I can think of to still be using DOS is that you can do hard real-time processing with it. Although that seems fairly niche, and there are other options for that.

⬐ AnotherGoodName

DOS on 386ex is still used on old style taxi meters and eftpos terminals that are still being made today. The near real-time support means that even the cheapest processor can read things like the pulses from the odometer without any misses, the version of DOS used is kilobytes in size so the components needed cost next to nothing and it boots up instantly (partly because the bios for the 386ex jumps straight into DOS without the memory and drive checks that a full blown x86 bios has).

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.

⬐ iamtheworstdev

this video is almost hnsearchable on youtube because they're adamant that "dos" really means "does" or "do"

⬐ mixmastamyk

What about "DOS" ?

⬐ WaitWaitWha

It is fascinating to read others' comments how DOS was bad.

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

⬐ Timwi

I feel that the video didn't answer the question in its own title: why is it still a thing. People are “beating a horse” because it is a legitimate question why something slower than a car with no blinking turn signal and rough suspension is still a thing.

⬐ blihp

There was a fair amount of software written for DOS that never made the jump to Windows (or any other OS) and some combination of hasn't been economically viable to redevelop and/or people just really liked the way the DOS app worked.

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.

⬐ mikewarot

Why do people still ride horses? We don't need them, yet some people own and care for horses. Some people still drive Model T Fords, and other old things.

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.

⬐ Koshkin

Some manufacturers can ship computers with FreeDOS preinstalled.

⬐ fsckboy

> Beating it up because it was not up to 2021 standards

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.

⬐ hfjfkkgkd

Source? Never heard DOS was made on Unix.

⬐ scruffyherder

Xenix dev tools can produce x86 real mode objects. Some dev kits even have the full linker and libraries.

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.

⬐ Koshkin

> myriad of tiny programs

And not so tiny, too - DOS extenders made memory constraints practically nonexistent.

⬐ hnlmorg

> In my opinion, it was amazing. Prior to graphical user interface, various DOS were the only interface in non-*nix world.

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)

⬐ LocalH

> Micro computers had BASIC

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.

⬐ nine_k

Yes, AFAICT, many computers of the widely popular MSX standard used Basic made by Microsoft. Frankly, it was pretty nice, and had powerful extensions / special commands to make use of the hardware (graphics, sounds, networking).

For a one-user, one-task computer, you didn't need much of a proper OS anyway.

⬐ hnlmorg

> Frankly, it was pretty nice, and had powerful extensions / special commands to make use of the hardware (graphics, sounds, networking).

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.

⬐ hnlmorg

Thankfully here in Europe we had more variety. Commodore was still hugely popular but so was Acorn (BBC Basic was one of the best of the era) and Amstrad (Locomotive BASIC was loosely based on BBC Basic, so also pretty awesome). Sinclair machines (eg Spectrum) were also popular but that's one of the few machines of that era I didn't do any development on (played plenty of games but man are their keyboards annoying for any prolonged typing!) so cannot comment on how Sinclair BASIC performed against Microsoft BASIC.