HN Show: Mein selbst geschriebenes Hobby-OS läuft endlich auf einem Vintage-IBM-ThinkPad

 (github.com/joexbayer)
4 Punkte von GN⁺ 2025-04-27 | 1 Kommentare | Auf WhatsApp teilen
  • RetrOS-32 ist ein vollständig eigenes 32-Bit-Hobby-Betriebssystem mit Fokus auf die i386-Architektur und umfasst Grafik, Multitasking und Networking
  • Kernel, Utilities und Build-System sind in C und Assembly geschrieben; User-Space-Anwendungen werden in C++ geschrieben, für den Build werden Make und Docker verwendet
  • Zu den getesteten realen Hardware-Systemen zählen Lenovo x240, Asus Eee PC Series, Dell Optiplex 780, Samsung N150 Plus, Samsung NP-NC10 und IBM Thinkpad a21p
  • Unterstützt werden die Ausführung in QEMU, in v86 von copy.sh sowie das Booten auf echter Hardware; auf realen Geräten wird eine GRUB-ISO verwendet, indem die .iso-Datei auf USB oder CD gebrannt wird
  • In der Roadmap sind Bootloader, präemptives Multithread-Scheduling, Dateisystem, grafischer Window Manager, Netzwerk-Stack, User-Space-Threads, ein entfernter virtueller TCP-Terminalzugang und weitere Punkte als implementiert aufgeführt

Überblick über RetrOS-32

  • RetrOS-32 ist ein 32-Bit-Hobby-Betriebssystemprojekt mit Fokus auf die i386-Architektur
  • Die Projektbeschreibung bezeichnet es als 32-Bit-Hobby-Betriebssystem mit Grafik, Multitasking und Networking
  • Als Startdatum ist der 12. Mai 2022 angegeben
  • Die Projektseite verweist auf die Project OSHub page

Login und Benutzer

  • Es gibt drei Standardbenutzer: system, admin und guest
  • Das Admin-Passwort lautet admin, guest hat kein Passwort
  • Derzeit gibt es keinen Unterschied zwischen admin und guest
  • Benutzer können mit dem Befehl admin create <username> <password> erstellt werden

Implementierungssprachen und Build-Konfiguration

  • Kernel, Utilities und Build-System sind in C und Assembly geschrieben
  • User-Space-Anwendungen sind in C++ geschrieben
  • Für die Kompilierung wird Make verwendet
  • Für plattformübergreifende Builds wird Docker verwendet

Getestete Hardware

  • Die Liste der getesteten realen Hardware lautet wie folgt
    • Lenovo x240
    • Asus Eee PC series
    • Dell Optiplex 780
    • Samsung N150 Plus
    • Samsung NP-NC10
    • IBM Thinkpad a21p

Build- und Ausführungsmethoden

  • In plattformübergreifenden Umgebungen werden Docker zum Kompilieren der Image-Datei und QEMU für die Emulation benötigt
  • Die Abhängigkeiten für natives Kompilieren unterscheiden sich je nach Plattform
    • MacOS: i386-elf-gcc, i386-elf-ld, i386-elf-g++
    • Linux / WSL Ubuntu: build-essential, gcc-multilib
    • Wenn GRUB als Bootloader verwendet werden soll, werden außerdem grub2, xorriso und xxd benötigt
  • Unter Linux erfolgt Build und Ausführung in der Reihenfolge Repository klonen, ./debian.sh, Git-Submodule initialisieren, make compile, make img, make qemu
  • Unter MacOS ist natives Kompilieren derzeit nicht möglich, da die Build-Tools von 32-Bit-x86-Code abhängen; Docker ist der einfachste Weg
  • Unter Windows werden Docker oder WSL verwendet
  • Es gibt drei Ausführungsarten
    • Die .img-Datei in copy.sh v86 als Festplatten-Image hochladen
    • In QEMU make qemu oder qemu-system-i386 <image name> ausführen
    • Auf echter Hardware die .iso-Datei auf USB oder CD brennen und die GRUB-ISO verwenden

Projektstruktur

  • Die Repository-Struktur ist in Verzeichnisse für Kernel, Treiber, Grafik, Netzwerk, Dateisystem, Bibliotheken, User-Space-Apps, Tests und Tools gegliedert
  • boot enthält den Custom-Bootloader und multiboot.ld
  • kernel enthält die wichtigsten Kernel-Quellen, architekturspezifischen Code und Kernel-Thread-Code
  • apps enthält User-Space-Anwendungen sowie libcore.a, libgraphic.a und libnet.a
  • net enthält Networking-Code, fs enthält Code zum Dateisystem
  • tools enthält Build-Tools und Skripte

Implementierte Punkte und verbleibende Aufgaben

  • Bei den bootbezogenen Punkten sind Custom-Bootloader, GRUB-Kompatibilität und Stage-2-Bootloader abgeschlossen
  • Kernel- und Systemfunktionen umfassen Folgendes
    • präemptives Multithread-Scheduling
    • Trennung von Kernel- und User-Space auf Basis von GDT und TSS
    • Interrupt-Verarbeitung
    • IPC
    • System Calls
    • User-Space-Threads
  • Treiber- und hardwarebezogene Funktionen umfassen PS/2-Tastatur und -Maus, PIT, VESA 640x480x8, RTC, Serial, E1000 und PCI
  • Bei Dateisystem und Storage sind ATA-IDE-Treiber, ein Ext2-ähnliches Dateisystem, FAT16 sowie Lesen und Schreiben abgeschlossen
    • FAT16 unterstützt Dateien bis zu 32 MB
    • Atapi ist noch nicht abgeschlossen
  • Speicherfunktionen umfassen 32-Bit-virtuellen Speicher, Kernel-kalloc/kfree sowie User-Space-malloc/free
  • Grafikfunktionen umfassen Window Manager, GFXLib, Double-Framebuffer-Rendering, Maus-Events, dynamisches Resizing, Vollbild und eine Widget-Bibliothek
    • Custom HTML to Widgets ist noch nicht abgeschlossen
  • Im Netzwerk-Stack sind Ethernet, IP, ARP, UDP, Socket API, Loopback-Interface, DHCP, DNS, TCP und ein netcat-artiger Befehl abgeschlossen
    • Webserver, FTP, IRC, SSH, Telnet, HTTP und HTML sind noch nicht abgeschlossen
  • Anwendungen und Tools umfassen Terminal, Window Server, Prozessinformationen, Finder, C-Compiler/Bytecode-Interpreter, eine Custom-VM zur Bytecode-Ausführung, Editor mit Syntax-Highlighting, Rechner, 3D-Spiel, Snake-Spiel im Textmodus, entfernten virtuellen TCP-Terminalzugang und eine LZ-Kompressionsbibliothek
  • Die vollständige Liste vorgeschlagener Funktionen und bekannter Issues findet sich unter open issues

Lizenz und Projektlinks

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-04-27
Meinungen auf Hacker News

  • Solche Projekte sind viel schöner anzusehen als öde KI. Verkaufen lässt sich das wohl nicht, aber man sieht, wie ein Techniker seine Fähigkeiten kreativ auslebt.
    In meinen späten Teenagerjahren habe ich mich viel mit Hobby-OS-Entwicklung beschäftigt; das war wirklich großartig, und auch heute baue ich gelegentlich kleine Kernel. Das Letzte, was ich gebaut habe, war ein kleiner RISC-V-Kernel, der meiner Partnerin eine Nachricht ausgab.

    • Es ist wirklich befreiend, sich keine Gedanken über Verkauf oder Marketing machen zu müssen. Man kann einfach das Rad neu erfinden, bis eine neue Idee auftaucht.
    • KI pauschal als „öde“ zu bezeichnen, ist merkwürdig. Bevor sie als clevere User Experience verpackt wurde, war sie eher eine akademische Erkundung, mit der sich kaum Geld verdienen ließ – also fast schon handwerkliche Arbeit.
    • Das klingt so, als wäre ein kleines Hobbygerät viel interessanter als die absurdeste Technologie der Menschheitsgeschichte.

  • Ich fände es gut, wenn die Standardsystemschrift eine schmalere Variante wäre. Dann würde das System deutlich eleganter wirken, und an einigen Stellen sieht man auch, dass die Buchstaben mehr horizontalen Platz brauchen.
    Man sollte die Breite jedes Zeichens reduzieren und auch den Abstand zwischen den Zeichen so weit wie möglich verringern. Bei der aktuellen Schriftgröße und Auflösung scheint mir 1 Pixel Abstand ausreichend.
    Ich kenne mich mit Schriftsystemen nicht gut aus, bin aber von einer monospaced Bitmap-Schrift ausgegangen. Wenn das in der Codebasis zu schwer zu ändern ist, dann ignorier es ruhig.
    Ich baue selbst seit einiger Zeit eine Web-OS-Seite von Grund auf und habe kürzlich die gesamte Schriftklasse neu geschrieben, daher fällt mir dieser Punkt besonders auf.

    • Ich stimme zu, dass die aktuelle Schrift ziemlich suboptimal ist. Im Grunde benutze ich noch fast unverändert die anfängliche Schrift, die ich zu Beginn zum Laufen gebracht habe.
      Ich habe mir auch richtiges Font-Rendering angesehen, und es steht auf der To-do-Liste, aber ich habe es immer wieder aufgeschoben.
    • Harte Stimmung hier.
      „Ich habe ein Betriebssystem gebaut!“
      „Hm, die Schrift ist nicht so toll.“
      Das wirkt wie der Gipfel von HN.

  • Cool. Ich frage mich, was du anders machen würdest, wenn du heute noch einmal anfangen würdest.
    Mich interessiert auch, welche Sprache du für die Low-Level-Teile für geeignet hältst: ob du bei C bleiben, eine einfache C++-Teilmenge verwenden oder eine neuere Sprache in Betracht ziehen würdest.
    Es gibt so viel Material dazu; mich würde auch interessieren, wie du das Projekt spannend gehalten hast, statt einfach Code anderer Leute zu kopieren.

    • Das Größte, was ich anders machen würde, wäre Planung. Am Anfang hatte ich nur das Ziel, ein grundlegendes Hello-World-OS zu bauen, aber dann habe ich ständig neue Funktionen hinzugefügt und parallel an mehreren Dingen gearbeitet, wodurch technische Schulden entstanden sind, die ich bis heute abbezahle.
      Ich hätte vermutlich auch versucht, die UNIX-Abhängigkeiten zu reduzieren.
      Bei Sprachen mag ich C wegen der grundlegenden Syntax und des direkten Wegs zum Kern der Sache. Für User-Space-Anwendungen könnte ich auch andere Sprachen in Betracht ziehen.
      Ich wollte von Anfang an alles selbst schreiben, und keine Software zu portieren war ein Kernpunkt des Projekts. Im Großen und Ganzen habe ich mich an die Regel gehalten: „Kopiere Ideen, nicht Code.“

  • Aus der Perspektive von jemandem, der 1977 einen Commodore PET 2001 benutzt hat, ist das wirklich großartig. Ich hatte mit KolibriOS und MenuetOSx64 herumgespielt, und jetzt bekomme ich Lust, selbst ein OS zu bauen. Beeindruckend, dass du es geschafft hast.

  • Das Projekt ist wirklich beeindruckend, und ich möchte gratulieren. Seit meiner Teenagerzeit mag ich OS-Entwicklung, und es ist schön zu sehen, dass so etwas tatsächlich umgesetzt wurde.
    Ich bin auch ein wenig neugierig, wie das Grafik-Subsystem initialisiert wird. Viel Erfolg.

  • Ich wünschte, ich könnte mir Zeit für solche Leidenschaftsprojekte nehmen.
    Praktikabilität vergessen, Go-to-Market-Strategie vergessen, Product-Market-Fit vergessen – einfach bauen und lernen.

    • Es ist wirklich erfrischend, nicht darüber nachdenken zu müssen, ob es tatsächlich „genutzt“ wird oder ob es einen Markt gibt. Es ist reine Arbeit aus Spaß und zum Lernen.
    • Ich frage mich, warum du dir die Zeit nicht nehmen kannst. Seit meiner Kindheit hätte ich mich ohne Hobbyprojekte ziemlich verloren gefühlt.
      Eines davon war ein Spielzeug-OS, aber als Low-Level-OS-Entwicklung zu meinem eigentlichen Beruf wurde, kam dieses Projekt zum Stillstand.

  • Ich bin seit Jahrzehnten in diesem Bereich und versuche, OS-Entwicklung zu lernen. FASM, NASM und FASM-G kenne ich einigermaßen.
    Aber ich möchte die Ausgabe von Assembler-Programmen studieren, um zu verstehen, wie ein OS auf Binärebene tatsächlich funktioniert.
    Mich würde interessieren, ob du die Instruction Codes einer bestimmten Architektur gelernt hast, wie du Gerätetreiberprogramme angegangen bist und ob du die Schritte zur Entwicklung eines eigenen OS zusammenfassen kannst.

    • Die besten Anlaufstellen zum Lernen sind meiner Meinung nach das osdev-Forum und das osdev-Wiki. Dort gibt es wirklich viele nützliche Ressourcen für den Einstieg.
      Es gibt auch einige Tutorials, aber sie enthalten oft Bugs, und am Ende baut man faktisch eher deren OS nach.
      In die Instruction Codes bin ich nicht so tief eingestiegen; ich habe sie nur beim Bau eines C-Compilers nachgeschlagen und kenne daher nur die gängigsten Grundbefehle.
      https://forum.osdev.org/
      https://wiki.osdev.org/Expanded_Main_Page

  • Wirklich großartig. Ich wünschte, mehr vom Geist der frühen Computerzeit käme zurück, als man mehr am Computer selbst als nur auf Anwendungsebene herumgebastelt hat.
    Ich habe darüber nachgedacht, als langfristiges Hobbyprojekt einen Personal Computer zu bauen: einen Computer, bei dem ich den gesamten Software-Stack selbst erstelle und weiß, woher jedes einzelne Bit im System stammt.
    Bei der Hardware wäre es schwer, denselben Grad an Kontrolle zu erreichen, außer vielleicht, wenn ein FPGA genug Leistung bietet, um alles auszuführen; aber zumindest bei der Software scheint es möglich.
    Bisher wirkte das unrealistisch, aber das hier zeigt, dass es machbar ist. Offenbar wird auch ein Hobby-C-Compiler implementiert: https://github.com/joexbayer/C-Compiler

    • Es ist wirklich ein gutes Gefühl zu wissen, dass man alles selbst geschrieben hat, vom oberen Ende des User Space bis zu den Treibern. Gleichzeitig ist es aber auch Debugging-Hölle.
      Den C-Compiler habe ich für dieses OS gebaut, und er läuft innerhalb des OS. Das Projekt wurde zu groß, deshalb wollte ich es aus dem OS-Repository herauslösen, insbesondere weil es auch unter Linux läuft.

  • Es wäre interessant, wenn du genauer erklären könntest, wie dieser Compiler mit dem Betriebssystem interagiert. Besonders interessiert mich, wie er Funktionen wie Structs behandelt und welche aktuellen Grenzen und geplanten Verbesserungen es in diesem Bereich gibt.

    • Zwischen Compiler und OS gibt es keine magische Interaktion. Er kompiliert einfach in dieselbe Maschinensprache (i386) und verwendet Interrupts für Systemaufrufe.
      Structs werden als Speicherbereiche behandelt, deren Größe sich aus ihren Membern ergibt, und Member-Zugriffe erfolgen über Offsets innerhalb dieses Bereichs.
      Aktuell gibt es viele Einschränkungen, etwa nur int und char und keine switch-Anweisung. Der größte Unterschied zu Standard-C ist, dass Funktionen innerhalb von Structs erlaubt sind und dass bei Struct-Funktionen das Struct implizit an die Funktion übergeben wird. Mehr Details gibt es hier:
      https://github.com/joexbayer/C-Compiler

  • Eines der beeindruckendsten Leidenschaftsprojekte, die ich hier seit ziemlich langer Zeit gesehen habe. Ich frage mich, warum du dich für einen eigenen C-Compiler entschieden hast.

    • Ich hatte die Regel, dass ich alles selbst schreiben wollte, und einen Compiler zu bauen war schon immer eines meiner „Ziele“. Deshalb passte das ganz natürlich zusammen.