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.
It's easy now because plenty of documentation exists of how to do it and there are plenty of open source examples, and there widely available, inexpensive or free, easy-to-use development environments and emulators and debuggers.
The original DOS boot sector was also a "filesystem and program loader", albeit one that wasn't able to do much other than find IO.SYS, load it, and run it.
What I wanted to do is make a "DOS" that's actually just a bootloader for a UNIX-like OS, but it's actually structured and works like DOS, just for launching kernels and minimal file management.
I think the real hard thing would be writing a full BIOS for an 8086 from scratch, capable of running a real DOS. I also wanted to do that, but...
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.
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.
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.
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 remember that book! I wanted to get a copy but made do with the DOS Programmer's Reference, 3rd ed., which was also very good since beej's interrupt list wasn't available yet or I didn't know about it.
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.
Risk was minimized with the use of segmented memory. A bad pointer would generally only clobber something in the same (data) segment of memory. But there were no segfaults; a program crash means a reboot, which is why so many people optimized config.sys abs autoexec.bat for fast boot.
Come to think of it, maybe things aren't so different today -- if something goes wrong in your container/vm, many teams just wipe it and start from a clean snapshot
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
It's easy now because plenty of documentation exists of how to do it and there are plenty of open source examples, and there widely available, inexpensive or free, easy-to-use development environments and emulators and debuggers.
The original DOS boot sector was also a "filesystem and program loader", albeit one that wasn't able to do much other than find IO.SYS, load it, and run it.
What I wanted to do is make a "DOS" that's actually just a bootloader for a UNIX-like OS, but it's actually structured and works like DOS, just for launching kernels and minimal file management.
I think the real hard thing would be writing a full BIOS for an 8086 from scratch, capable of running a real DOS. I also wanted to do that, but...
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.
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.
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 remember the books on undocumented functionality like
https://archive.org/details/Undocumented_DOS
I remember that book! I wanted to get a copy but made do with the DOS Programmer's Reference, 3rd ed., which was also very good since beej's interrupt list wasn't available yet or I didn't know about it.
Was it Ralf Brown? beej has C and networking tutorials: https://beej.us/guide/
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.
Risk was minimized with the use of segmented memory. A bad pointer would generally only clobber something in the same (data) segment of memory. But there were no segfaults; a program crash means a reboot, which is why so many people optimized config.sys abs autoexec.bat for fast boot.
Come to think of it, maybe things aren't so different today -- if something goes wrong in your container/vm, many teams just wipe it and start from a clean snapshot
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
Unfortunately, this is not uncommon. Check the agreements you signed with your current employer. You might be surprised.