The prototype that reached the desktop.
NullaOS v0.4.1.0 was the culmination of the original MiniOS codebase: a from-scratch x86-64 operating system that booted from its own UEFI loader all the way to a Windows 95-inspired desktop, with real drivers and real applications running in user space.
NullaOS v0.4.1.0 booting under QEMU, from the kernel's console log through to the Windows 95-inspired desktop, running entirely on its own drivers, compositor and user-space services.
From power-on to desktop
The best record of what v0.4.1.0 achieved is its own boot log. Captured under QEMU, it runs to more than 1,400 lines, and it tells the story of a complete operating system bringing itself up in stages, each one handing off to the next.
Custom UEFI bootloader
Sets a 1920×1080 32-bit graphics mode through the firmware, loads the kernel, locates the ACPI tables, builds the initial page tables and exits boot services.
Platform discovery
Parses ACPI to find every CPU core, the interrupt controllers and the PCIe configuration space, finds the power-off and reset paths, and calibrates a nanosecond timer from the processor clock.
Memory and processes
A physical page allocator and virtual memory manager move the kernel into the higher half, then process management and the system-call interface come online.
Hardware enumeration
A bridge-aware PCIe scanner builds a master device tree: graphics, Ethernet, audio, AHCI SATA, NVMe and the USB 3 controller, each recognised and handed to its driver.
Interrupts and devices
The I/O APIC routes keyboard, mouse and storage interrupts; the USB stack brings up keyboard and mouse over xHCI; storage drivers discover every disk and partition.
Filesystems
Four FAT32 volumes with long-filename support are mounted into a single tree through the VFS, with the OS root on one disk and every other volume visible beneath it.
User space
The kernel loads init.mnx from disk and drops to Ring 3. From there a user-space orchestrator starts the sound server, network daemon, splash screen and desktop compositor, and waits for each to report ready over IPC.
The desktop
A multithreaded compositor paints a Windows 95-inspired desktop in 32-bit ARGB. Applications launch from disk, the network daemon obtains a DHCP lease and pings the internet, and a clean shutdown flushes every drive, parks the disk heads and powers off through ACPI.
What was working
In QEMU every one of these subsystems ran together, and most of them also ran on real hardware.
Desktop and compositor
A Windows 95-inspired desktop with 32-bit ARGB window compositing over the UEFI framebuffer, running as a user-space process with its own background IPC router thread.
Storage and filesystems
AHCI and NVMe drivers that worked on every test machine, feeding a FAT32 implementation with long filenames through a POSIX-style virtual filesystem.
Processes and threads
Isolated Ring 3 applications in the custom MNX executable format, multiple threads per process, system calls and a user-space init system that orchestrated the rest of boot.
Networking
A user-space network daemon built on lwIP, with Intel and Realtek Ethernet drivers, DHCP, DNS resolution and ICMP, serving other applications over an IPC socket.
USB input and audio
An xHCI USB 3 host driver with HID keyboard and mouse support, PS/2 input as a fallback, and a user-space sound server driving AC’97 audio.
Power management
ACPI-driven shutdown and reset, with an orderly storage shutdown sequence that flushes every cache and parks mechanical drives before the power goes.
On real hardware
QEMU was the reference, but the goal was always bare metal. v0.4.1.0 was tested across four physical machines, and the results were honest: genuinely impressive on some, stubborn on others.
| Machine | Result |
|---|---|
| QEMU (x86-64) | Everything working: desktop, USB and PS/2 input, AHCI and NVMe storage, networking and audio. |
| GMKTec NucBox M5 Ultra AMD Ryzen 7 7730U | Booted straight to the desktop with working NVMe storage and USB keyboard and mouse. The Realtek 2.5GbE driver loaded, but DHCP picked the wrong interface. |
| Intel NUC11ATKC4 Celeron N5105 | Kernel and storage worked, but the Intel USB controller never delivered input, and later builds stalled during video initialisation. |
| Intel NUC11PAHi5 Core i5-1135G7 | Not recently tested; expected to share the Intel USB problem. |
| Custom desktop B550 · Ryzen 7 5700X · RX 7900 XTX | Completed the kernel boot, then faulted the moment the first user-space program started. Graphics did not come up on the discrete card. |
Why it was retired
v0.4.1.0 was a genuine achievement, and it was also a prototype. It grew fast, and it grew by fixing symptoms: a workaround for this machine, a delay for that controller, a special case for one device. Each fix made one computer happy and quietly changed the timing on another.
A full architectural review made the pattern clear. The deepest problems were not untidy code but missing contracts at the boundaries between subsystems: how the bootloader hands over to the kernel, how memory is mapped and protected, how user programs are allowed to talk to the kernel, and which part of the USB driver owns which event. Those cannot be patched into shape. They have to be designed.
So the prototype was frozen. It is kept as a working reference for what NullaOS should do and how it should feel, while the rewrite rebuilds how it does it.
Same destination. A much cleaner road.