Hacker News Reader

Comment by fuzzfactor | Hacker News Reader

Actively maintained is a handicap for something that's supposed to be a fixed long-term "standard".

MS-DOS is that immutable standard of the past which reached maximum maturity in 2001.

FreeDOS was originally an alternative, but is for the future now.

I like FreeDOS but when companies started to distribute their device drivers or software on floppies or CDROMs that were formatted using FreeDOS, it was not pretty.

Often there was no successful access or booting to the FAT volume, but all you needed to do was SYS the writable floppy with MS-DOS, or go through the ordeal of "ripping" the CD to correctly SYS its contents.

Regardless of the '90's or today I would recommend very strong familiarity with MS-DOS for some time, there is really nothing new there, before moving forward to include FreeDOS in your toolbox.

This is how it happened organically when FreeDOS was first emerging.

View on HN

I think of MS-DOS mostly as the ultimate fantasy console. It is sad that the only way to write something once and not have to maintain it to keep up with breaking dependencies all the time is to target a dead platform.

But I never had any compatibility issues with FreeDOS? It seems like a good implementation of DOS. I mostly use DOSBox-X, but I use FreeDOS now and then as well. It is the only DOS I would consider running on hardware.

BTW did anyone else notice that Microsoft included almost a complete 1988 vintage 16-bit DOS toolchain in their MIT-licensed MS-DOS repo? It has Microsoft C 5.1, MASM 5.1, Make, and several other tools, plus libraries and include-files. All of it in less than 3 MB.

https://github.com/microsoft/MS-DOS/tree/main/v4.0/src/TOOLS

I've taken to saying, much to the chagrin of my techy friends, that "the best language is a dead language". Usually speaking about C which isn't even dead but maybe should be, just stick with C89 and pretend that was the end (though for more modern targets C11 with atomics is tempting).

Along the same lines, maybe the best platform is a dead platform. And there is a mature emulator, or many, for pretty much every modern platform. I've definitely been exploring DOS as a way forward (lol) out of the madness of modern computers.

Radically simple, single tasking, and local first with a stable platform that is close to the metal. What is not to love? I mean maybe it doesn't hurt it was on my first computers so a nostalgia factor I'm sure is at play as well.

DOS can also be a nice, predictable runtime for embedded or low-level systems, as long as you're running x86. Some implementations are even 64-bit clean, such as this one: https://github.com/dosemu2/fdpp.

I remember this project (https://jimhall.itch.io/toy-cpu), where the author shipped his emulator as a DOS binary instead of a web-based JavaScript version that would eventually break over time.

DOS can serve as a lightweight, efficient, and predictable runtime with extremely low system requirements and no need for updates. It can run on bare metal or as a WASM binary.

The development tools are small, free, and reproducible (e.g., Turbo C), ensuring that the code will still compile and run just fine even 10 years from now. Oh, and it also has some cool TUI libraries a la QuickBASIC. I’d argue it’s still a worthy option, if it’s not user-facing.

> Actively maintained is a handicap for something that's supposed to be a fixed long-term "standard".

Not if the static version is buggy.

MS-DOS 6.22 from 1994 isn't stable enough?

The reason I suggested FreeDOS was because the root comment was essentially a laundry list of bugs in MS-DOS. If there's a readily-available MS-DOS that does the job and doesn't have (material) bugs then sure by all means use that, but then what are we even talking about here?

These bugs in ver 3.3 are lingering from when very many individuals could not yet afford a HDD.

>MS-DOS 6.22 from 1994 isn't stable enough?

you're reading a discussion of a bug in that code...

I am? The article mentions MS-DOS 3.3 which is about 7 years older

> Often there was no successful access or booting to the FAT volume

I can't work out what you're trying to say here.

Lots of companies sell FreeDOS laptops. The config is often very weird, c.f.

https://blog.tmm.cx/2022/05/15/the-very-weird-hewlett-packar...

It's a complex setup of an elderly Debian with no desktop, a QEMU VM and a PDF viewer. It's not really DOS at all.

Is that what you mean?

Not really,

With plain Windows, one year you would get an app that's supposed to be installed from bootable floppies, they had been formatted using MSDOS/Windows and everthing went as expected. Same basic workflow as installing Windows from floppies at the time.

Then there was a trend to shipping floppies that had been formatted and/or contained non-MS DOS instead, if a new version came out like that it sometimes failed to boot on far more machines.

SYS the bootable one to MS-DOS and it worked.

I still do not understand.

I ran and worked with MS-DOS in production use for years. I am that old. I have deployed hundreds of DOS machines and I was an expert in DOS memory management.

I installed lots of apps from floppies as well.

No, usually installation floppies were _not_ bootable, in my extensive experience. If they were, I can't see how or why that would affect the app so long as the app wasn't tied to one specific version of DOS.

At the time when DOS ruled business PC computing, there were not very many alternative versions. Even DR-DOS came along quite late. Aside from DR's own multitasking TASKMGR.EXE I don't think I ever saw anything else that was specific to DR-DOS. GEM and ViewMax ran fine on MS-DOS.

There was no practical difference between IBM's PC DOS and MS-DOS except for BASICA. Only when MS dicontinued MS-DOS did IBM PC DOS start to diverge, dropping BASIC for Rexx, dropping EDIT.EXE for IBM E, and so on.

I cannot work out what you could mean.

Perhaps specific examples would help.

Reply on news.ycombinator.com