deniz.in

Markets

Weather

Loading weather

· via Hacker News – Front Page (native)

UnoDOS: one source tree spans the 8088 IBM PC/XT to modern x86-64

A from-scratch graphical OS family built from one contract-driven source tree runs on 22 machines, from an 8088 IBM PC/XT to bare-metal modern x86-64 PCs with their own browser, office suite and hypervisor.

UnoDOS: one source tree spans the 8088 IBM PC/XT to modern x86-64

UnoDOS is a from-scratch family of graphical operating systems that spans twenty-two machines from a single source tree, from an IBM PC/XT with an 8088 to the modern 64-bit laptop. According to the project's GitHub repository, which surfaced on the Hacker News front page, it began as a GUI-first, 16-bit real-mode OS written entirely in x86 assembly, fitting a kernel, window manager, two filesystems, cooperative multitasking and a full application set on one 1.44 MB floppy. It has since grown into a contract-driven family of ports covering home computers, consoles, handhelds, single-board computers and a phone.

pc64, the modern flagship

pc64 boots bare-metal on essentially any x86-64 PC made since around 2007. UEFI plays the role the BIOS played for the classic OS: the firmware hands over a framebuffer, a keyboard and the boot volume, then UnoDOS calls ExitBootServices and the firmware leaves. From that point the system runs entirely on its own drivers, and a hybrid disk image also boots the same OS on legacy-BIOS machines.

The desktop is built on unoui, the family's cross-platform widget toolkit: a taskbar, virtual desktops, window snapping, an animated Alt-Tab switcher and ten live-switchable themes, from a modern flat default to retro looks modelled on Mac OS 7, Windows 3.1, Amiga Workbench and NeXTSTEP. Text is kerned, anti-aliased TrueType using bundled open fonts.

The application set is unusually complete for a from-scratch system. UnoWord, UnoCalc and UnoShow form an Office 97-class suite that reads and writes real Microsoft .doc, .xls and .ppt binaries through the in-tree unodoc library. The browser handles HTML and CSS with cookies, HTTP and CA-validated TLS 1.2, and offers two switchable JavaScript engines: the in-tree unojs bytecode VM and vendored quickjs-ng. Studio is an IDE running on the OS itself, shipping UnoC, a built-in C compiler that produces native UnoDOS applications. MicroPython is a first-class runtime, media support includes from-scratch WAV, MIDI, MP3 and AAC-LC decoders, a Winamp 2 clone loads classic skins, and a native SSH client uses in-tree ed25519 crypto. Applications are loadable .UNO modules — dropping one into the APPS directory lets the shell discover it, with no rebuild or reboot.

Everything below the firmware line is native to the tree: AHCI, NVMe, SDHCI/eMMC and USB mass storage under a common block layer with FAT16/FAT32 support; a polled xHCI USB stack; wired NIC drivers for Intel and Realtek parts plus Wi-Fi with WPA2; a from-scratch TCP/IP stack from ARP through DHCP, DNS and TLS; PS/2, I2C-HID and USB HID input; Intel HDA audio; and an in-tree ACPI AML interpreter.

There is also a hypervisor: unovirt enters VMX operation on Intel hardware and runs guests behind EPT with virtio devices, and the README reports a real Ubuntu kernel booting under UnoDOS, reaching userspace and mounting an ext4 disk served from a file. An AMD/SVM backend is written but awaits hardware proof. Around the core sit a non-destructive installer, local accounts with RBAC and an audit trail, a remote-control channel for driving physical machines headlessly, and debug builds that run a behavioral spec as an on-metal conformance test. The port is validated on a Lenovo ThinkPad X1 Carbon Gen 8 and an always-on ZimaBlade box, with QEMU-based harnesses booting the real image on every change.

One contract, many machines

The unifying idea is UnoDOS 3.1's contract-driven architecture. A single machine-readable Contract under unodef/ defines screen geometry, the window and event layout and the shared enums, and every world is generated from it or checked against it. The README states that the assembly ports and the x86 reference consume the contract byte-identically, and that eleven ports were built fresh on the 3.1 architecture rather than migrated — evidence, the project argues, that a new target costs only a small generated surface.

The port list reads like a computing museum: an Amiga port with copper and bitplane graphics and Paula audio, a Commodore 64 bitmap desktop with SID sound, fresh worlds for the VIC-20 and Apple II, an Apple IIGS port, a hosted Mac System 1–7 Toolbox port, a standalone MacPlus OS verified on a real Mac SE, the first big-endian PowerPC world for G3/G4 Macs, and consoles including a Sega Genesis port that boots on real hardware. Every port runs a desktop with a shared app set scaled to what the machine can hold, down to a launcher profile on 2 KB of RAM.

The repository is candid about the gap between what builds and what works: PLATFORMS.md records, per platform, what has booted on real hardware, what is emulator-verified only, and every known gap. Prebuilt images exist for every platform, and most run in an emulator within a minute.

Why it matters

Most OS projects pick one era of hardware. UnoDOS bets that a shared, machine-readable contract can keep a single design alive from an 8088 to a UEFI laptop, with the same shell and applications on both — and the eleven ports built fresh on that architecture are the evidence. The pc64 line also shows how far an in-house tree can go without an existing kernel underneath: browser, office suite, compiler and hypervisor are all native. Just as notable is the verification discipline, a public ledger separating real-hardware proof from emulator confidence. For anyone designing portable software, the contract-first approach — where the platform surface is generated rather than hand-ported — is the idea worth watching.

  • #operating-systems
  • #x86
  • #retro-computing
  • #open-source
  • #assembly

Related posts