The sources for MS-DOS have been floating around the net basically forever. The original first few releases are even on Microsoft's github. It largely is already in ASM. Some of the user programs are written in C.

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

Personally for me it would be an interesting experience to see what and why they chose to do things they did with MS-DOS. One thing to try is to see if it's possible to write a 64 bit DOS extender.

There’s a couple attempts at running 64-bit in DOS. It usually has no benefits for old code and very little new 64-bit is being written and there are no libraries for common compilers.

https://github.com/Baron-von-Riedesel/Dos64-stub

https://www.bttr-software.de/forum/board_entry.php?id=15853

Nice one, thanks.

What would writing DOS programs and extenders with modern tooling accomplish? Trying to understand the goal.

Making easy to understand and maintain programs in C++, with compilers that can that can do aggressive optimizations and inlining that compilers of the day could not do.

The STL didn't exist until the late 90s, and before C++98 it was a wild-west.

> with compilers that can that can do aggressive optimizations

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

But what is the goal in having maintainable ms-dos software?

The OS is still ancient and lacks most every possible security measure.

Every program can r/w any memory and so on…

The fact that it gets out of your way is a feature. Why does security matter on a single user, non-multitasked environment with no networking?

The netsec industrial complex has really set back computing.

MSDOS did have MMU support since 80386, IIRC. So I think GPs claim might be inaccurate. But it wasn't a security feature, it was a productivity feature. It protected your programs from defects in other programs and vice versa. This helps programmers find defects during design and helps users for defects that escape testing.

[citation required] for the MMU support of MS-DOS.

DR and MS DOS 5 and later have a 386 memory manager which can put an x86-32 CPU into Virtual 86 mode, remap RAM over any unused blocks in the I/O and ROM area (between 641kB-1024kB) to make Upper Memory Blocks, and load small resident parts of the OS into those blocks in order to keep as much base memory (0kb-640kB) free.

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.

Just replying with a web page showing the 80386 has having control registers doesn't imply that MS-DOS used them in any meaningful way.

The MMU is inside the processor. Any operating system running on an 80386 or higher has set registers/tables and gets hardware provided memory management.

If it uses it. Later versions of DOS did very little with the features the 386 offered, which is why there were MS-DOS extenders.

https://en.m.wikipedia.org/wiki/DOS_extender

You can make your own minimal DOS Extender just by setting those registers. This is what some games did.

I agree with the sentiment but note there were still viruses being circulated through floppy disks. So, 3rd party code may still be executed on a non-networked machine.

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.

Stuxnet is the modern variant.

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 took the time a few years ago to learn a bit about how to use Autodesk Animator (it was released with a BSD license some ~10 years ago and can be downloaded legally for free these days). Was really impressed with the GUI. Just press a single key to open the menu that begins with that letter, then the first letter of the menu-item you want to use. They managed to use only words that begin with unique letters while still making a lot of sense. Plus some other single-key shortcuts. And many, to me, unusual design choices everywhere, but it all makes sense and is consistent in a way that after a few hours I was not bothered at all by the fact that nothing was like a modern GUI, and there was definitely nothing about using more modern GUI conventions I can think of that would make it more pleasant to work with.

https://github.com/AnimatorPro/Animator-Pro

Stuxnet happened even with all of those protection mechanisms in place.

To my knowledge the targeted PLC lacked any form of protection when infected.

It spread first as windows worm that exploited several 0-days. If the host didn't have the Siemens PLC device drivers with a configuration that matched the exact configuration of what they were expecting for the centrifuges, they payload was dormant and it just replicated. Only if it matched would it patch the PLC's programming upon re-connection to fake reporting that the speed was normal while it was actually spinning out of control.

Thus the security model of DOS is still a problem even without internet connection.

Thus window's security theater did nothing.

You made a claim that it was unnecessary to have any security features on a non-network computer.

I have not made any claims about security features on a network computer.

My computer was 'Stoned.' Yes. I got a boot sector virus.

Why did you invent the constraint "no networking"?

I had coax network on MS-DOS even back then.

DR DOS 7 did have built-in peer-to-peer networking: Netware Lite.

MS DOS did not, because that was the main selling point of Windows for Workgroups.

Yea, there was alot of features that one is used to in modern OS that was missing in MS-DOS. It does not mean those features didnt exist or wasnt being used.

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

Some of these things were included later on.

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

> lacks most every possible security measure

So do calculators and typewriters. (Some people use computers to, gasp, perform computations, and low or no overhead is nice.)

DOS serves as a good bootloader for an embedded system.

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

I think the parent may be thinking more of "demoscening" the DOS kernel and basically optimising it to its limits. Yes, the original was written in Asm, but it's definitely not that highly optimised.

Taken into account how the modern compilers evolved, i don't have big hopes. They seem to become more bloated with every release.

gcc-ia16 and OpenWatcom are both modern compilers that generate as good a set of code as any compiler ever did for Pentium and older processors. But using a higher level language like C means there’s more than one compiler that can compile your DOS. That’s a reason to be hopeful if you’re a DOS developer.

The compilers have probably got better but the C language has definitely bloated since the 80s

constexpr code and move semantics didn't exist until relatively recently. These are steps towards less bloat and more aggressive optimization. They also can elide gratuitous copy construction.

There are a lot of these little optimizations that are found in modern compilers that you could only dream about in 1991.

It was written in assembly code: https://github.com/microsoft/MS-DOS/tree/master/v2.0/source

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?

Why not contribute to FreeDOS?

> lean and mean