Writing a DOS Clone in 2019(medium.com)
medium.com
Writing a DOS Clone in 2019
https://medium.com/@andrewimm/writing-a-dos-clone-in-2019-70eac97ec3e1
30 comments
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
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.
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.
There's also the fact that a modern emulator (assuming you're running as an emulator, instead of real/raw) is that you aren't constrained by memory the way real hardware implementations were either.
I keep thinking it would be cool to emulate enough of DOS and earlier x86 to just run BBS Doors directly and connections over ws(s) to make authentication and program selection a bit easier. Even if no classic BBS terminals (currently) support connecting over WebSockets, which are easy enough to bridge.
I keep thinking it would be cool to emulate enough of DOS and earlier x86 to just run BBS Doors directly and connections over ws(s) to make authentication and program selection a bit easier. Even if no classic BBS terminals (currently) support connecting over WebSockets, which are easy enough to bridge.
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 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...
There were loadlin and grub4dos back in the day. A more recent development is doslinux (https://github.com/lpsantil/doslinux) but it is far less complete. But more hackable if you just want to see something work.
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
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
You've got all the BIOS calls you need to actually shunt sectors on and off disk, read keystrokes, and display characters, right?
So with some code simple enough to hand-assemble you could write the bare bones of a Forth "inner interpreter", and from there the Forth compiler, which necessarily has a command line interpreter (or at least, a thing that breaks a text buffer down into words).
Then a simple "DOS" would have a command like "dir" which would read the directory sector into a block, format it, and print it, and so on.
Using a normal Forth-style "block editor" on a system with files wouldn't have to be complicated, you'd just be working on a 1kB (two sectors) block at a time, starting from the first block referenced by the filename.
You'd get to a point where you could read, edit, and compile Forth definitions or even just cope with text files in MS-DOS formatted disks pretty quickly.
So with some code simple enough to hand-assemble you could write the bare bones of a Forth "inner interpreter", and from there the Forth compiler, which necessarily has a command line interpreter (or at least, a thing that breaks a text buffer down into words).
Then a simple "DOS" would have a command like "dir" which would read the directory sector into a block, format it, and print it, and so on.
Using a normal Forth-style "block editor" on a system with files wouldn't have to be complicated, you'd just be working on a 1kB (two sectors) block at a time, starting from the first block referenced by the filename.
You'd get to a point where you could read, edit, and compile Forth definitions or even just cope with text files in MS-DOS formatted disks pretty quickly.
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'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
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/
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 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.
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
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
See: Dissecting DOS
https://www.amazon.com/Dissecting-DOS-Code-Level-Operating-S...
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.
And i've seen it 1998/1999 as i remember.
A disk-operating system is a system for operating disks, and doesn't concern itself too much with other hardware - that came later.
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.
> Concurrent DOS
This is the real deal here.
CDOS was a multitasking, eventually x86-32 native, OS that could multitask DOS apps even on a 286.
Back in the 20th century the limitations on a multitasking DOS were largely around hardware compatibility: could it talk to your network card, sound card, CD drive, and let multiple DOS apps access them?
But now, DOS networking is largely irrelevant: it didn't natively talk TCP/IP and nobody cares about IPX/SPX or NetBEUI. Few have a CD-ROM any more. You probably need a driver shim to emulate a Soundblaster anyway.
However all those 10s of thousands of DOS apps are still there and still work.
For DOS there's FreeDOS, SvarDOS, PDOS, and others, including this project.
A modern FOSS CDOS clone would be great fun.
This is the real deal here.
CDOS was a multitasking, eventually x86-32 native, OS that could multitask DOS apps even on a 286.
Back in the 20th century the limitations on a multitasking DOS were largely around hardware compatibility: could it talk to your network card, sound card, CD drive, and let multiple DOS apps access them?
But now, DOS networking is largely irrelevant: it didn't natively talk TCP/IP and nobody cares about IPX/SPX or NetBEUI. Few have a CD-ROM any more. You probably need a driver shim to emulate a Soundblaster anyway.
However all those 10s of thousands of DOS apps are still there and still work.
For DOS there's FreeDOS, SvarDOS, PDOS, and others, including this project.
A modern FOSS CDOS clone would be great fun.
I feel like the article is just too short for the given topic. So much more detail could have been added.
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?
>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.
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...
[0]: https://archive.org/details/The_MS-DOS_Encyclopedia_Ray_Dunc...
Yep, I thought so too! It’s a very interesting and fun topic.
So… I cannot resist redirecting you to a set of articles I wrote about two years ago on DOS and memory management, which I think covers some of the basic parts. The first one is https://open.substack.com/pub/blogsystem5/p/from-0-to-1-mb-i...
So… I cannot resist redirecting you to a set of articles I wrote about two years ago on DOS and memory management, which I think covers some of the basic parts. The first one is https://open.substack.com/pub/blogsystem5/p/from-0-to-1-mb-i...
I knew y'all techies we're fancy but just, what ?!?!
>Recently I was lucky enough to take a one-month sabbatical away from work. While I spent much of that (sabbatical period) time traveling and staying away from a computer,
I had no idea it was now en vogue to take a nice one month sabbatical from your big tech FAANG job to go time traveling. It raises so many questions. First of all, why the one month period. If he has a time machine couldn't the sabbatical be forever? Second, which tech company has, it seems, secretly developed time travel and time displacement science, produced a time machine, and offered it only to employees going on sabbatical? It seems like a google kind of thing but maybe it's a move from amazon's business, long shot netflix or valve out of left field with a new entertainment tech.
In any case I for one welcome our new time traveling tech overlords and look forward to the time wars as the natural evolution to the space rocket wars
>Recently I was lucky enough to take a one-month sabbatical away from work. While I spent much of that (sabbatical period) time traveling and staying away from a computer,
I had no idea it was now en vogue to take a nice one month sabbatical from your big tech FAANG job to go time traveling. It raises so many questions. First of all, why the one month period. If he has a time machine couldn't the sabbatical be forever? Second, which tech company has, it seems, secretly developed time travel and time displacement science, produced a time machine, and offered it only to employees going on sabbatical? It seems like a google kind of thing but maybe it's a move from amazon's business, long shot netflix or valve out of left field with a new entertainment tech.
In any case I for one welcome our new time traveling tech overlords and look forward to the time wars as the natural evolution to the space rocket wars
I remember playing with Caldara OpenDOS and Concurrent DOS years ago, and it always seemed like it might be fun to make my own.