[shantnutiwari]

Interesting.

I've often wondered-- if you want to learn low level C and/or hacking techniques, would it make sense to start by hacking Ms-Dos? It's easy, there is little to no protection, even for system calls, and you can do a lot with little code.

Of course, there is no "practical" use, but it would be really interesting as a learning excercise.

I often thought of creating a few tutorials about this, but not sure if anyone cares... (or if anyone else has done so).

[pjc50]

There's precisely zero protection; it behaves a lot more like an embedded system. It might be nice to reuse some of the old tutorials for this, but I'm not sure if that wouldn't be too specific.

[buescher]

Most of it would cross-apply to embedded. Some of it would directly apply to whatever legacy SBC-level embedded applications out there are still running on DOS. Most people don't want to be in embedded, and even fewer want to do maintenance programming in embedded.

[shantnutiwari]

yeah, but embedded is another beast. Lots of different boards/architectures, plus not all embedded devices use an OS, it's mostly (usually?) bare metal programming

[buescher]

DOS programming could be caricatured as "bare metal with a file system".

[LocalH]

It wasn’t intended that way originally, it was the developers of the time who started hitting the hardware directly. Software written to use the BIOS and DOS interfaces could run on other non-IBM-compatible MS-DOS computers that existed. But that didn’t offer the performance that demanding tasks like gaming required, and that’s the genesis of the difference between “IBM-compatible” and “MS-DOS compatible”.

[marcodiego]

Complementing sibling answer, the architecture used in CP/M, and somewhat mimicked by MS-DOS, allowed very high portability of the system.

Ideally, no user space program should access the hardware directly. All its interactions should be through int 21h. The kernel implemented filesystem access and other system routines, occasionally making bios calls. Bios calls were very simple calls to a jump table in a predefined location that implemented lower level hardware accesses. So, when a program wanted to, for example, access a file, it called the BDOS with specified register values and the kernel, if required, made bios calls to satisfy the request.

This, of course, incurred some latency. For performance critical applications like games this approach was just too costly. Since IBM-PC was just very very common, apps started accessing the hardware directly. It was more performant but non-portable.

For classic CP/M apps, that never accessed the hardware directly, if you could build a machine with a compatible bios, you instantly had access to all CP/M software library available.

[mycall]

QDOS was originally a clone of CP/M, but for legal reasons was changed just enough to become 86-DOS (then became MS-DOS)

https://en.wikipedia.org/wiki/86-DOS

[pjmlp]

Just get an Arduino or ESP32 and you can do exactly the same.