rou2exOS - DOS-ähnliches Hobby-OS, geschrieben in Rust und x86-Assembly

• Ein 64-Bit-Betriebssystem im DOS-Stil, entwickelt in Rust; etwas x86-Assembly wird ebenfalls zum Laden des Kernels verwendet
• Implementiert VGA-Textmodus (80x25), das FAT12-Dateisystem und einen IPv4-Netzwerk-Stack über SLIP (ICMP/UDP/TCP/HTTP)
• Läuft und wird entwickelt in einer auf QEMU basierenden virtuellen Maschine; unterstützt teilweise auch echte Diskettenmedien
• Enthält einfache Basis-Utilities wie einen Texteditor, TAB-Datei-/Verzeichnis-Autovervollständigung und das Snake-Spiel

Architektur und Bootloader

• Ziel-CPU ist x86_64; Unterstützung für die ARM-Architektur (aarch) ist künftig geplant
• Frühere Versionen luden und starteten den Kernel mit einem selbst geschriebenen Bootloader direkt in den Speicher
• Im 64-Bit-Kernel wird der GRUB2-Bootloader genutzt, um den Eintritt in den Long Mode und den Wechsel in den Protected Mode zu handhaben
• Der stage2-Bootloader übernimmt unter anderem das Einrichten von GDT, IDT und Paging sowie die Zuweisung des Multiboot2-Zeigers
• Der Kernel besteht aus einem Shell-Befehlsprozessor und verschiedenen benutzerdefinierten Komponenten

Emulation und Images in QEMU

• Entwicklung und Tests erfolgen in einer virtuellen Maschinenumgebung mit QEMU
• Erzeugung von ISO-Images: mit grub2-mkrescue und xorriso
• Unterstützung für das Erstellen und Einhängen von FAT12-Disketten-Images, nutzbar auf echter Hardware oder mit dem QEMU-Flag -fda fat.img

Initialisierungsablauf

• Beim Einstieg in den Kernel werden Long Mode, Multiboot2-Tags, das FAT12-Dateisystem und der VGA-Status geprüft
• Nach Ausgabe eines ASCII-Art-Logos wird die Steuerung an die Shell-Schleife übergeben

Dateisystem

• FAT12-Dateisystem-Unterstützung: Lesen/Schreiben/Suchen/Löschen von Dateien sowie Erstellen/Löschen von Verzeichnissen
• Unterstützt das Erstellen und Überschreiben von Textdateien sowie Unterverzeichnisse
• Enthält ein fsck-Tool zur Prüfung der Dateisystemkonsistenz
• FAT32-Unterstützung ist ebenfalls für die Zukunft geplant

Netzwerk-Stack

• Senden und Empfangen von IPv4-Paketen auf Basis des SLIP-Protokolls
• Unterstützung für die Verarbeitung von Ethernet-Frames (Tests noch nicht abgeschlossen)
• Unterstützt ICMP Echo (Request/Reply), UDP und TCP (SYN/SYNACK-Zustandsmaschine)
• Einfacher HTTP-Server: liefert statische HTML-Seiten aus

Snake-Spiel

• Snake-Spiel integriert; eine künftige Multiplayer-Version (P2P TCP) ist ebenfalls geplant
• Spieldaten (Level, Punktestand) können als Textdateien gespeichert und geladen werden
• Spielende mit ESC; High Score wird abhängig vom Punktestand gespeichert

Projektwert und Einsatzpunkte

• Als Beispiel für ein in Rust geschriebenes Betriebssystem vermittelt es anschaulich die Vorteile von Sicherheit und Produktivität bei der Entwicklung systemnaher Software
• Mit SLIP/ICMP-Tests, einfacher Bereitstellung und Unterstützung für echte Hardware eignet es sich gut für OS-Experimente und das Lernen benutzerdefinierter Implementierungen
• Bietet die Möglichkeit, eine DOS-ähnliche Systemstruktur aus Rust und x86-Assembly direkt kennenzulernen

[GN⁺]

Hacker-News-Kommentare

• Verwendung einer Sprache mit garantierter Speichersicherheit, basiert auf x86_64, Unterstützung für Arm ist ebenfalls geplant, eigener Networking-Stack vorhanden, Boot über CD und Multiboot möglich, mein Hobbyprojekt bietet ein Erlebnis, das DOS übertrifft
  • Um mit DOS konkurrieren zu können, ist Unterstützung zum Ausführen von Doom und BASIC unverzichtbar; das fungiert praktisch als offizielle Basislinie für den DOS-Stil
  • Die Kombination aus Rust und x86-Assembler lässt mich daran zweifeln, ob das praktisch wirklich einen Wert hat, wenn man Speichersicherheit anstrebt; heute wirkt Rust auf mich ein wenig so übervermarktet wie früher einmal 3D-Druck, die realen Vorteile bei der Verbreitung sind begrenzt, und das Projekt wäre schön, wenn es mit alter Software kompatibel wäre, sonst bleibt es eher ein Bildungs- oder Enthusiastenprojekt und scheint bis zur echten Praxistauglichkeit noch einen weiten Weg vor sich zu haben
• Mir gefällt wirklich, dass im Networking-Stack SLIP und slattach(1) verwendet werden; als ich selbst einmal einen einfachen TCP/IP-Stack gebaut habe, habe ich unter Linux ebenfalls per pty eine SLIP-Verbindung hergestellt und sie an den Kernel angebunden, auf macOS gab es früher wohl auch slattach(1), aber es scheint inzwischen entfernt worden zu sein, ich frage mich, ob jemand auf macOS mit SLIP eine plattformübergreifende Networking-API gebaut hat, als Alternativen gibt es unter Linux tun/tap und unter macOS utun, aber SLIP ist viel einfacher
• Ich frage mich, warum x86 gewählt wurde: wegen der vielen Ressourcen, wegen des ungewöhnlichen Instruktionsformats, wegen der Komplexität der Boot-Sequenz oder vielleicht als Strategie, DOS direkt nachzuahmen; es wurde gesagt, dass auch ARM bald unterstützt werden soll, und ich frage mich, wie Unterstützung für mehrere Architekturen funktionieren soll, obwohl DOS selbst Hardware und Software eng miteinander verknüpft
  • Ich habe mir dieses Projekt nicht direkt angesehen, aber meine Vermutung ist: Die x86-Plattform hat historisch dank Legacy-Kompatibilität wirklich viele Schnittstellen eingebaut, sodass sich ein sehr schlankes und simples „DOS-artiges OS“ leicht umsetzen lässt, ohne Device Trees zu parsen, die MMU einzurichten oder komplexe Busse wie PCI(e) zu behandeln; bei ARM ist schon das Bootstrapping schwierig, wenn man die Einfachheit beibehalten will, man muss mehr Einschränkungen in Kauf nehmen, ohne MMU ist nur begrenzt etwas möglich, und da es keine BIOS-Schnittstelle gibt, ist es nicht so einfach wie bei x86, Sektoren zu lesen oder auf Tastatureingaben zu warten
  • Der Grund für die Wahl von x86 ist, dass dieses System aus der ersten Version hervorgegangen ist, die in Turbo C auf Basis von BIOS-Interrupts und Inline-Assembler erstellt wurde; es geht nicht nur darum, MS-DOS zu imitieren, aber es war eine starke Inspiration; Unterstützung für mehrere Architekturen ist dank der Zielarchitektur-Auswahl im Rust-Compiler grundsätzlich möglich, man legt vor dem Build einfach das Ziel fest und es wird im Build-Prozess direkt berücksichtigt
• In der heutigen UEFI-Umgebung wäre so eine FLOSS-basierte 64-Bit-DOS-artige Lösung vielleicht besser gewesen als die aktuelle Umgebung samt Shell, das könnte als Retro-Boot-Manager oder Systemdiagnose-Tool großartig sein, ich frage mich, ob das von der EFI-Systempartition aus laufen kann, FAT12-Unterstützung ist bestätigt, aber wie es mit GPT aussieht, und ob die Video-Hardware direkt gesteuert wird oder die Ausgabe eher terminalartig ist
  • Das Booten von der EFI-Systempartition wurde noch nicht getestet, offiziell unterstützt wird derzeit nur das FAT12-Dateisystem (es gibt eine Memory-Disk-Funktion, aber sie funktioniert aktuell nicht), GPT wird derzeit nicht unterstützt, FAT32-Unterstützung wird als Priorität erwogen (Flash-Datenträger nutzen normalerweise FAT32), und zur letzten Frage: Das OS schreibt direkt in den VGA-Speicherpuffer, GRUB stellt eine Auflösung von 80x25 bereit
• Ich finde das Projekt großartig; schade, dass das berühmte Zitat fehlt: „Es ist nur ein Hobby, es wird nie groß und professionell wie Linux werden.“
• Ich frage mich, ob Unterstützung für tschechische diakritische Zeichen geplant ist
  • In dieser Version ist nur Englisch geplant, die erste Version wurde anfangs auf Tschechisch erstellt
• Ich frage mich, ob ein komplett neu in Rust geschriebener VGA-Treiber verwendet wird
  • Dieses Modul enthält den VGA-bezogenen Quellcode
  • Bis zu einem gewissen Grad ja, aber eigentlich ist es eher ein Wrapper-Modul für den Zugriff auf den Videospeicherpuffer
• Nachfrage, ob es zwar im DOS-Stil gehalten ist, aber keine DOS-Kompatibilität besitzt
  • Das ist eine zutreffende Einschätzung, die erste Version war 16-Bit und wurde so entworfen, dass sie nahezu mit MS-DOS kompatibel ist, und ich denke, wenn sie zumindest einfache Festplatten-I/O verarbeiten kann, kann man sie im weiteren Sinn zu den DOS-Systemen zählen
  • Gemeint ist also ein Niveau von MS-DOS-Kompatibilität, bei dem Alley Cat, Dune 2 und Doom laufen würden
• Meinung, dass für die Unterstützung einer asynchronen Runtime eine Event-Queue nötig wäre
  • Frage, wie es mit der Implementierung einer ausgereiften Event Loop aussieht
• scherzhafte Frage, ob Crysis darauf laufen kann