top | item 44318588

Show HN: A DOS-like hobby OS written in Rust and x86 assembly

207 points| krustowski | 8 months ago |github.com

To try it out, simply build the project yourself from source, or use attached bootable ISO image of the system (in Releases on Github) and run it in QEMU.

https://blog.vxn.dev/rou2exos-rusted-edition

60 comments

order

rollcat|8 months ago

Memory-safe language. x86_64, with Arm on the roadmap. Networking stack. Boots from a CD and via multiboot. Your hobby project wipes the floor with DOS.

pvg|8 months ago

Whoa there. Gotta run Doom and BASIC to compete with DOS. That is the officially recognized DOS-Kármán line.

MoonGhost|8 months ago

> Rust and x86 assembly

then

> Memory-safe language.

What's the point? Looks like today Rust is like 3D printing was. As if it makes something better. Printing was hyped and advertised by printers sellers and manufacturers. Finally they run out of money.

As for project, it's cool if compatible with old soft. Otherwise suitable mostly for education and masochism. Long way to become practical anyway even if it gets traction.

mct|8 months ago

I love that the networking stack uses SLIP and slattach(1)!

I was playing with a toy TCP/IP stack, and decided using SLIP over a pty on Linux was a great way to interface with the kernel. Unfortunately it looks like macOS previously shipped with slattach(1) a very long time ago, but no longer does.

I'm curios if other people have used SLIP on macOS to get a dead-simple, cross-platform API to the networking stack?

The alternative would be to use tun/tap on Linux and utun on macOS, but SLIP would be so much nicer.

OhNotAPaper|8 months ago

Out of curiosity, why x86? Is it the preponderance of resources? The weird instruction format? The complexity of the boot sequence? Are you specifically trying to mimic DOS?

> A support for the ARM architecture (aarch) is coming soon too.

Wow! How do you support a DOS-like OS across multiple architectures when DOS itself is tightly tied to interactions among the program, the system code, and the architecture?

anyfoo|8 months ago

I have not looked at this project, but my guess would be: x86 is a widely available platform that, because of its history and relentless compatibility, contains a lot of legacy interfaces that make implement a very simple, thin-layer and “DOS-like OS” without the need to parse device trees, set up MMUs, deal with complex busses like PCI(e) and so on.

It is much harder to bootstrap a simple OS in ARM, and it won’t stay very simple unless you accept significantly more limitations than you would under x86. (For example, you can’t do very much with the MMU off on ARM, and you also don’t have convenient BIOS interfaces that allow you to, say, read a sector, or wait for a keypress, with just a few lines of assembly).

krustowski|8 months ago

The x86 arch is used because this system iteration derives from the first one, which relies on BIOS interrupts and inline assembly in Turbo C. I am not trying to mimic (MS-)DOS exclusively, but both systems are highly inspired by it.

IMO multiple archs could be supported as Rust compiler allows the target arch specification, so one would build a specific target before the build itself.

mixmastamyk|8 months ago

I would have preferred something like this to the current UEFI environment and shell, a FLOSS 64-bit DOS-like. A cool retro boot manager and diagnostic env perhaps.

Could this run from an efi system partition? Seems to support fat12, what about gpt?

Does it poke video hardware like DOS, or have a terminal like output?

krustowski|8 months ago

Booting from an EFI system partition has not been tested yet. FAT12 is the only filesystem (ok, there is a memdisk implementation, but it won't work now) supported, so GPT is not supported at the moment too (yet). Kinda aiming for FAT32 implementation to be the very next implemented (flash disks are usually FAT32 iirc). Not sure about the last question: the OS utilizes/directly writes to the VGA buffer in memory, the provided resolution is 80x25 by GRUB.

Toritori12|8 months ago

Good job OP, what a missed opportunity to say: "just a hobby, won't be big and professional like Linux" (:

pndy|8 months ago

Are you planning adding support for Czech diacritics?

krustowski|8 months ago

I am not at the moment. The goal is to keep this iteration in English for now. The first iteration was in Czech in the beginning though.

DrNosferatu|8 months ago

DOS-like but not DOS-compatible, correct?

krustowski|8 months ago

You are right. The first iteration however is 16bit and is very close to MS-DOS in terms of compatibility. Moreover, any OS that can handle simple disk I/O ops could be considered a DOS system too, innit?

DrNosferatu|8 months ago

...meaning MS-DOS compatible :)

I.e.: runs Alley Cat and Dune 2 - and Doom.

m00dy|8 months ago

it needs event queue to support async runtimes.

krustowski|8 months ago

How about the event loop in its completeness?

jmmv|8 months ago

I don’t understand: what makes this “DOS-like”? Not even the command names match DOS, except for dir and cls, and the architecture and feature set are completely different.

klank|8 months ago

The original blog post has more details: https://krusty.space/projects/rourexos/

Ultimately, it's an eye of the beholder type thing, but it seems very fair to call it DOS-like to me. The DOS inspiration is pretty blatant all throughout it from its aesthetic, commands (more than just dir and cls is shared), booting from a 1.44 floppy, etc. And if you are coming from a primarily windows computing background, then "DOS-like" is entirely appropriate to me.

It looks like a fun project.