Glonce

Moxnox 1.0 released: hobby OS with NT syscalls, POSIX and btrfs

infrastructureThe Glonce editorsHacker News🔥50Glonce rating50Impact30Novelty45Relevance70Surprise35Players5Credibility75
Moxnox 1.0 released: hobby OS with NT syscalls, POSIX and btrfs

Moxnox is a hobby operating system that has reached version 1.0 on GitHub. Its README, written in the first person by the author, describes it as NT-like, POSIX-compatible, running on btrfs and capable of self-hosting. In practice that means the design, including the choice of syscalls, is modelled on Windows NT, while the system should be able to run software written for Unix-like systems once it is recompiled for Moxnox, and it ships with a full GNU base system. It is mature enough that Moxnox can be built on Moxnox. Version 1.0 is around 130,000 lines of C++ and runs on amd64 and aarch64.

The author is precise about what "NT-like" means. The contract is that the syscalls and low-level interfaces match those of NT, but not the daemons or how the kernel itself is structured. The author contrasts this with ReactOS, which aims at an exact recreation of Windows. Binaries are PE files rather than ELF, with .exe or .dll extensions. C++ exceptions go through SEH, POSIX signals are done through Asynchronous Procedure Calls, and the non-kernel kernel-like work happens in ntdll.dll. The rcx, rdx, r8, r9 calling convention and Windows' C quirks (a 32-bit long, a 16-bit wchar_t, a long double the size of double) match Windows as well. Among NT features, the author calls out tokens, the Registry and I/O completion ports as the interesting ones that are missing. NT's hidden device-path scheme was not copied: paths are POSIX-like, with forward slashes and / as the root. Transactions and paged kernel memory were left out on purpose. The author also says the system borrows from Linux's best ideas: the dentry cache, large folios, mapping the whole of physical memory, and evdev.

On the POSIX side, 642 of the roughly 1,200 functions in POSIX 2024 are implemented, which the author says is the vast majority of what is used in practice, with gnulib papering over some gaps. Unlike on Windows, fork is available. musl supplies the maths and cryptographic functions, mingw supplies printf and some other pieces, and tre supplies regexes. The POSIX functions are split over ucrtbase, iphlpapi and ws2_32 as on Windows, with anything Windows lacks placed in mnposix. The list of ports is long: bash, binutils, coreutils, cmake, git, llvm, mesa, openssh, openssl, perl, python, vim and many more, with gcc on amd64 only. gcc, rust, hexyl and ripgrep cannot yet be compiled inside Moxnox, but everything else can, eventually, and building may take a lot of RAM and even more patience.

To try it, the author offers a disk image and an EFI kernel file for qemu, with example command lines for amd64 and aarch64. The qemu example uses 1024 MB of memory, which must be raised for anything strenuous such as self-hosting. Installing on real hardware means making a roughly 32 GB btrfs partition (the author says that should be plenty), unpacking a release tarball onto it, copying the kernel to the EFI partition and adding a boot entry with efibootmgr. A recent btrfs-progs is needed. The kernel EFI file is also a polyglot that follows the Linux boot protocol, so it should work on non-EFI GRUB, though the author has not tested this. The amd64 build targets x86-64-v3, which the author says covers more or less anything manufactured since 2015 or so, and AVX512 is enabled automatically if detected. The aarch64 build needs ARMv8.1 because of LSE atomics, which means the Raspberry Pi 5 but no earlier model; Moxnox supports ACPI only, not Device Tree, so the Pi also needs the rpi5-uefi firmware project. Supported devices include NVMe, SATA, SD card (SDHCI), virtio-block and USB mass storage; virtio-net, RTL8168 and RTL8125 network cards; USB HID, PS/2 and virtio-input; virtio-gpu, GOP framebuffer, VBE and VGA text console graphics; and XHCI USB. To build, the author recommends the Docker containers maharmstone/moxnox-ci-amd64 or maharmstone/moxnox-ci-aarch64, then CMake with Ninja, which is required because the code uses C++ modules.

The README is candid about what is missing. Version 1.0 has no GUI, no timezone support, no keyboard layouts, no locales or non-UTF-8 character sets, no security of any kind, and no multiple users or groups. There are no passwords yet, so logging in over ssh means adding a /root/.ssh/authorized_keys file, and daemons must be started by hand (for example /bin/sshd.exe after generating host keys). Performance problems include a slow userspace heap allocator, which is the bottleneck when self-hosting; slow TCP, because no MSS is negotiated and the default 64KB window is kept; no early writeback under memory pressure; no LRU system to drop clean pages from the page cache; and a dentry cache that never gets pruned, so inodes stay open until deleted. AF_UNIX is half-complete: socketpair works (including SCM_RIGHTS, which ssh uses) but normal client-server code does not. mkfifo creates an inode but I/O to it is not redirected to a buffer. APCs, meaning signals, are delivered only when a thread returns from a syscall, so a program running while (true) { } is currently unkillable.

On whether Windows programs will run, the README answers: no, or at least not yet. Win32 DLLs are deliberately not implemented, apart from a few kernelbase functions the mingw runtime wants. A possible future step is to strip those out and port across Wine's versions of the Win32 DLLs.

The author also addresses AI use. None of the substantive code was written by AI. It helped with mechanical porting work, such as translating autotools to CMake, replacing ioctl calls with tcgetwinsize and translating C structs into Rust, and with some smoke tests such as cairo-test and mesa-test. Where Claude "really shines", the author says, is reviewing your own commits: give it a hash and it finds the memory leak or deadlock you left in. As for motivation, the author cites fun and the view that the only way to learn how something works is to write it. The NT kernel, the author argues, is criminally underrated and little known to hobbyists, and had features, such as eventfd and pidfd equivalents, that Linux took years to design. The author regrets that Windows keeps shying away from full POSIX compatibility, pointing to the early half-complete subsystem, WSL1 and Nano Server, all abandoned. Moxnox is, in the author's words, a take on what Windows could have been. Licensing: the kernel and first-party programs are GPL, first-party DLLs are LGPL, and the modules directory is MIT; ports carry their own licences.

Key facts

  • Moxnox 1.0 is a hobby OS of around 130,000 lines of C++ for amd64 and aarch64, modelled on Windows NT syscalls, POSIX-compatible, running on btrfs and able to build itself.
  • Only NT's syscalls and low-level interfaces are matched; binaries are PE rather than ELF, signals use Asynchronous Procedure Calls, and paths are POSIX-style. Tokens, the Registry and I/O completion ports are missing.
  • 642 of roughly 1,200 POSIX 2024 functions are implemented, and fork is available. Many GNU ports work, but gcc, rust, hexyl and ripgrep cannot yet be compiled inside Moxnox.
  • Version 1.0 has no GUI, no security, no multiple users or groups, and a busy-loop program cannot be killed; the author asks users to mount only throwaway btrfs filesystems.
  • The author says none of the substantive code was written by AI; AI helped with mechanical porting and some smoke tests, and Claude was useful for reviewing the author's own commits.

Why it matters

Moxnox is an unusual design point: it takes the NT kernel's syscall interface and pairs it with a Unix userland, rather than copying Windows wholesale as ReactOS aims to do. The author argues the NT kernel is underrated and that Windows has repeatedly backed away from full POSIX compatibility (an early half-complete subsystem, WSL1 and Nano Server were all abandoned). Moxnox is the author's answer to what Windows could have been. It is also a notable solo-scale effort: around 130,000 lines of C++ that can compile itself.

Who it affects

Mainly OS hobbyists, kernel developers and people curious about NT internals, who can read and build the code or boot it in qemu. Raspberry Pi 5 owners and people with a spare partition on x86-64-v3 hardware (roughly anything made since 2015 or so, per the README) can try it on real machines. It is not aimed at everyday users: there is no GUI, no security and no multi-user support yet.

How to use it

The simplest route is qemu. Download the 1.0 disk image and EFI kernel from the GitHub releases, decompress the image with gunzip and run the qemu command from the README, raising memory above 1024 MB for heavy work. For real hardware, create a partition of about 32 GB, format it with a recent btrfs-progs, unpack the release tarball, copy the kernel EFI file to the EFI partition and add a boot entry with efibootmgr. Raspberry Pi 5 users also need the rpi5-uefi firmware. To build, use the author's Docker CI containers and CMake with Ninja (the Makefile generator does not work because of C++ modules). Daemons are not started automatically; for ssh, generate host keys, add an authorized_keys file for root and run /bin/sshd.exe. Licences: GPL for the kernel and first-party programs, LGPL for first-party DLLs, MIT for the modules directory.

How solid is it

The facts here come from the project's own README, written by the author, so the claims are self-reported. The README is specific and open about its limits: 642 of about 1,200 POSIX 2024 functions, a list of missing features, and known performance and correctness problems. The author says the btrfs code works for basic purposes but is not battle-hardened. The README gives no benchmarks and no release date for version 1.0.

Risks and caveats

The author asks users to mount only throwaway filesystems with the btrfs code, and the install steps say to double-check the partition name. There is no security of any kind and no passwords yet. A program stuck in a loop cannot be killed because signals are only delivered on return from a syscall, AF_UNIX and mkfifo are incomplete, and TCP is slow. Windows programs are not supported: Win32 DLLs are deliberately not implemented. Non-EFI GRUB booting is untested, and gcc, rust, hexyl and ripgrep cannot yet be compiled within Moxnox itself.

“So this is my take on what I wish Windows had been like.”

— Moxnox README, written in the first person by the project author