Very easy indeed, especially if you're not concerned with 100% compatibility with existing MS-DOS API. It's closer to a library of routines that serve as a thin layer on top of the BIOS that just provides a filesystem and program loader. No (preemptive) multitasking (although TSRs are still possible), dynamic linking, virtual memory, etc.

If you want nothing more than a filesystem and program loader, you can fit everything in 512 bytes: https://news.ycombinator.com/item?id=20569438

I'd start by writing a simple Disk Operating System, and forget MS-DOS compatibility (which isn't exactly necessary today).

The basic idea (which I think originated from FLEX[1]?) is that you have something that accepts typed commands, like "DIR A:", splits on spaces, takes the first part and loads the disk program called "DIR" (or "DIR.COM" etc) into memory and runs it, passing the rest of the parameters on the stack.

From that you can see you'll need a very basic filesystem (to load the command from), and a few system calls (eg. print a character, input a character, open a file, list the directory). The earlier DOSes like CP/M didn't have subdirectories, and only had a handful of system calls, so it was all very simple - by necessity because the hardware was limited.

You can expand on the idea endlessly, eg. writing lots of utilities, your own compiler and assembler, editor, etc.

Presto, you've got your own Disk Operating System!

There's a guy on YouTube you runs all these early proto-DOSes[2] on original hardware so you can get a sense of the extreme limitations of these early home computers.

[1] https://en.wikipedia.org/wiki/FLEX_(operating_system)

[2] https://www.youtube.com/user/deramp5113/videos

If I were to write an OS for a system of that era, I think I would target a game console. Compatibility is a rabbit hole (as I discovered when writing a JIT for Ruby). If you don't have to worry about whether other software runs, there is a lot of room for creativity.

I suspect it’s 80% straightforward and 20% bug compatibility

See: Dissecting DOS

https://www.amazon.com/Dissecting-DOS-Code-Level-Operating-S...

Russians built their own clone of DOS https://en.wikipedia.org/wiki/PTS-DOS

And i've seen it 1998/1999 as i remember.

I mean DOS is essentially just the frame work between the software and the BIOS/hardware. Once code is running the OS isn't doing too much.

In that sense DOS programs run without any guard rails. Video memory is just a memory address where you can throw data in and it shows up on screen, but it also means that any kind of memory pointer issue can write over almost anything in RAM. It was trial and error to ensure everything worked and seeing as machines were not always online, there was a much smaller risk of security issues being leveraged.

See also: PDOS (Public Domain Operating System) https://www.pdos.org/ -- a single-person project with a remarkably stream-of-concsiousness-style webpage. Not sure how well 'geniuine' DOS software works on this system, though.

There's a follow up post and there was supposed to be another one too but apparently was never written. Regarding code:

>Once I return to work and get approval to open up the source code, I’ll make the repo public as well.

Guess approval wasn't given?

If you want more detail, may I suggest "The MS-DOS Encyclopedia" by Ray Duncan [0].

[0]: https://archive.org/details/The_MS-DOS_Encyclopedia_Ray_Dunc...