I've wanted to re-implement DOS in pure assembler for years to have that lean and mean that uses less memory than MS-DOS but never had the time.
To me, it would be far more interesting to see what modern compilers and development tooling could do towards producing DOS programs and operating system extensions. The tooling from back in the day was very baroque. You had to rely on different mutually incomparable dos extenders to get around all the limitations. (Just try to find the documentation to Phar Lap 386 in 2022.)
The STL didn't exist until the late 90s, and before C++98 it was a wild-west.
The OS is still ancient and lacks most every possible security measure.
Every program can r/w any memory and so on…
The netsec industrial complex has really set back computing.
These memory managers could also turn the extended memory (above 1024kB) into managed XMS or EMS memory. LIM EMS was accessible to DOS apps and XMS to DOS-extender apps.
These were killer features in 1990 or so, and I made good money from optimising DOS memory for clients around that time.
Indeed, it would be awesome to see how much a machine can do without all the layers. Even the Intel CPU security fixes could be bypassed and gain some extra speed.
Regardless of the qualities of DOS, the user interfaces of the graphical programs was in many cases superior compared to today, everything keyboard controlled, clearly labeled shortcut keys, views that usually only did one thing, distinctive coloring.
I have not made any claims about security features on a network computer.
I had coax network on MS-DOS even back then.
MS DOS did not, because that was the main selling point of Windows for Workgroups.
We used 3rd party TSR drivers for it.
Examples:
- MOUSE.COM driver https://www.vogons.org/viewtopic.php?t=58777
- CDROM driver http://manmrk.net/tutorials/DOS/cdrom.htm
- Network stack https://en.wikipedia.org/wiki/IPX/SPX
- Graphics driver https://dosdriver.de/graph.php
- Sound card drivers https://dosdriver.de/sound.php
For instance:
DR DOS 6 had Netware Lite; DR DOS 7 had Personal Netware.
https://en.wikipedia.org/wiki/Personal_NetWare
I think several versions of DOS included MSCDEX.EXE (or DR's equivalent), but not the device driver, because back then there were lots of different CD interfaces: Mitusmi, Panasonic and Sony on sound cards, some early EIDE ones, and SCSI on higher-end kit.
Mouse drivers came with your mouse. ;-)
MS did have a network stack bundled for free on the NT Server installation CD, and some versions of it support server mode for peer-to-peer operation.
DOS could do all this stuff, but you had to assemble the bits from different sources, and this was sometimes for good reasons, sometimes technical (a profusion of incompatible CD-ROM interfaces) and sometimes commercial (P2P LAN support).
So do calculators and typewriters. (Some people use computers to, gasp, perform computations, and low or no overhead is nice.)
we're still talking about real-mode DOS here. Most of those optimizations aren't going to work.
Regardless, you can target DOS just fine today. You'll need some code to bootstrap your program into protected/long mode and then your app has full freedom. You'll need to figure out the correct switches to pass to gcc to get it output a freestanding binary, and possibly a special linker script, etc.
Freedom but, let's be honest, no real utility today. You can't access the network because you'll need to write the entire network stack from scratch. You'll need to write a driver for your network hardware. Can't touch video without writing a driver for your Nvidia hardware. Or sound card.
I suspect what most people want from a "modern" DOS would be something like this: a very thin API layer that contains OpenGL (or Vulkan), audio, and networking capability. As well as drivers for common USB devices and something that can read/write FAT/exFAT. But once you add all of that you realize it's nowhere near as lightweight as old DOS was and your app now has a thousand more responsibilities that something like the Linux kernel is currently handling for you.
I think people may be looking for something like a unikernel framework. Something like Linux is a lot of overhead if all you want to do is run a single program on a machine (virtual or physical).
There are a lot of these little optimizations that are found in modern compilers that you could only dream about in 1991.
This is a very old version, but I've seen bits and pieces of the last one they shipped and things like command.com and the "kernel" were nearly the same as this, except for maybe some memory management changes. What part did you want to reimplement?