Hacker News Reader

Comment by userbinator | Hacker News Reader

It's a tiny OS that provides little more than a filesystem and program loader on top of the BIOS, and otherwise stays out of the way. Any large complex MS-DOS application itself contains functionality that would be in the OS otherwise.

View on HN

Also, it was popular to use smaller, 3rd party programs that would provide what is now part of a typical OS; e.g. Norton Commander[1].

[1]: https://en.m.wikipedia.org/wiki/Norton_Commander

I still use Midnight Commander in Linux, as it reminds me of the DOS times with Volkov and Norton.

Volkov was much faster on older machines...

Yes

For today's applications? It sucks. A lot

Thread/Process control in MSDOS? In your dreams

Network? Are you running Netware? Otherwise you're SOL

Sound output? Sure, just set up DMA and IRQ yourself for your Soundblaster card. I mean, you have one of those right?

> Sound output? Sure, just set up DMA and IRQ yourself for your Soundblaster card. I mean, you have one of those right?

What has OS got to do with possession of some hardware?

If the OS doesn't provide an actual sound API developers will only write support for the most popular sound cards.

I remember games which had extra features if you had a Gravis UltraSound.

The knowledge gap of the modern js devs is funny, thinking MS-DOS has any concept of what a soundcard is.

Though even first Unixes "it's a file, just write to it" were better but just above the bare minimum

I kind of figured that, just based on the fact that there seems to be a ton of DOS-compatible clones out there, even when DOS was relevant, like Concurrent DOS. If the OS were too complex there probably wouldn’t be a lot of clones.

Yeah. Basically, for most intents and purposes, any high-end MSDOS application is basically running bare-metal, as if no OS was installed in the system at all.

As close to the embedded world as possible.

I don't understand why is there so little documentation about MSDOS as a real-time operating system. I'd bet it would work beautifully for any piece of software that was developed with such use-case in mind.

You’d have to write your own scheduler.

With no memory protection a wayward process could easily overwrite the schedulers data structures, and probably hang the system.

(ms)dos has just a file system (it's the D in the name). It has no protected memory or scheduling, or any ability to "talk" between processes. It can load executable images .exe(MZ) or sub 64KB .com. ANd yes, it's possible to reserve memory and stay resident (TSR)

I have some experience repurposing 8259 (the interrupt controller), and if you hook on the timer (8), there is nothing else to return the execution back to the 'OS'. In short I'd disagree about the real-time.

FAT is not well suited to embedded use. The TFAT hack was patent encumbered and not widely supported outside of MS products.

Reply on news.ycombinator.com