I have thought about doing this. I have no idea what would be involved, but given how many DOS-compatible OS’s were around in the 1980’s it must be comparatively easy to build than other operating systems.
I remember playing with Caldara OpenDOS and Concurrent DOS years ago, and it always seemed like it might be fun to make my own.
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.
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.
Very much so. If programs are well-behaved, and call "int 21", etc all is well. But a lot of programs would use undocumented things, such as the list-of-lists and they'd directly peek and poke into the operating systems code.
I've had fun updating the shell, and code, of CP/M, in assembly, and writing emulators of it. But as always there is no shortage of programs making specific assumptions that make everything more complex than they should be.
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.
I have thought about doing this. I have no idea what would be involved, but given how many DOS-compatible OS’s were around in the 1980’s it must be comparatively easy to build than other operating systems.
I remember playing with Caldara OpenDOS and Concurrent DOS years ago, and it always seemed like it might be fun to make my own.
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
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 suspect it’s 80% straightforward and 20% bug compatibility
Very much so. If programs are well-behaved, and call "int 21", etc all is well. But a lot of programs would use undocumented things, such as the list-of-lists and they'd directly peek and poke into the operating systems code.
I've had fun updating the shell, and code, of CP/M, in assembly, and writing emulators of it. But as always there is no shortage of programs making specific assumptions that make everything more complex than they should be.
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.
I feel like the article is just too short for the given topic. So much more detail could have been added.
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...
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?
Crazy his job allegedly owned his hobby project code