I remember playing with Caldara OpenDOS and Concurrent DOS years ago, and it always seemed like it might be fun to make my own.
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.
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'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.
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.
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.
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
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.
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 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...
And i've seen it 1998/1999 as i remember.
https://www.amazon.com/Dissecting-DOS-Code-Level-Operating-S...
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.
>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
lloydatkinson•2mo ago
forgotpwd16•2mo ago
>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?
lloydatkinson•2mo ago
btrettel•2mo ago
skywal_l•2mo ago
[0]: https://archive.org/details/The_MS-DOS_Encyclopedia_Ray_Dunc...
jmmv•2mo ago
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...