[HN Gopher] Writing a DOS Clone in 2019
___________________________________________________________________
Writing a DOS Clone in 2019
Author : shakna
Score : 60 points
Date : 2025-11-03 04:07 UTC (13 days ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| lloydatkinson wrote:
| I feel like the article is just too short for the given topic. So
| much more detail could have been added.
| forgotpwd16 wrote:
| 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?
| lloydatkinson wrote:
| Crazy his job allegedly owned his hobby project code
| btrettel wrote:
| Unfortunately, this is not uncommon. Check the agreements
| you signed with your current employer. You might be
| surprised.
| skywal_l wrote:
| 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...
| jmmv wrote:
| 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...
| tombert wrote:
| 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.
| PeaceTed wrote:
| 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.
| cout wrote:
| 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
| pimlottc wrote:
| I suspect it's 80% straightforward and 20% bug compatibility
| stevekemp wrote:
| 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.
| ssrc wrote:
| I remember the books on undocumented functionality like
|
| https://archive.org/details/Undocumented_DOS
| cout wrote:
| 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.
| rzzzt wrote:
| Was it Ralf Brown? beej has C and networking tutorials:
| https://beej.us/guide/
| rwmj wrote:
| 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
| ErroneousBosh wrote:
| 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.
| userbinator wrote:
| 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
| trollbridge wrote:
| 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.
| guerrilla wrote:
| 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...
| mobilio wrote:
| Russians built their own clone of DOS
| https://en.wikipedia.org/wiki/PTS-DOS
|
| And i've seen it 1998/1999 as i remember.
| cout wrote:
| 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.
| BirAdam wrote:
| See: Dissecting DOS
|
| https://www.amazon.com/Dissecting-DOS-Code-Level-Operating-S...
| marttt wrote:
| 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.
___________________________________________________________________
(page generated 2025-11-16 23:01 UTC)