Moxnox 1.0: NT-Inspired Hobby OS Combines POSIX and Btrfs, but Cannot Run Windows Apps

What Moxnox actually is​

The project's README calls it an NT-like, POSIX-compatible hobby OS that runs on Btrfs and can build itself. Harmstone says its system calls are modelled after Windows NT. It is also meant to run Unix-style software once that software has been recompiled for it. The 1.0 codebase is about 130,000 lines of C++ and targets amd64 and AArch64.

Linuxiac stresses that it is an independent OS. It is not a Linux distribution or a Windows clone. It is not ReactOS either, because ReactOS tries to recreate Windows compatibility and Moxnox has its own kernel architecture.

The odd mix of Windows and Unix​

Linuxiac reports that Moxnox uses Windows' Portable Executable format instead of Linux's ELF. Programs and libraries carry .exe and .dll names. Meanwhile the filesystem layout follows Unix conventions, with Unix-style paths and fork, which the traditional Windows API doesn't have.

The repository layout fits this. It has directories named ntdll, kernelbase, ucrtbase and ws2_32, alongside mnposix.

This does not mean Windows software will run. Phoronix says that, despite the NT-modelled syscalls, it's also not yet able to handle Windows EXE programs. Linuxiac adds that the developer has floated porting Wine's Win32 libraries someday, but nothing like that exists now.

Software and self-hosting​

The ported software list includes:

• Bash and GNU Coreutils
• GCC (x86-64 only, per Linuxiac)
• LLVM, Git, Python, Perl and Rust
• OpenSSH, OpenSSL, Vim and Nano

The README says Moxnox is mature enough to build Moxnox on Moxnox. That is a real milestone, but Linuxiac notes it has limits. GCC, Rust and a few other applications can't yet be compiled natively on the system.

Phoronix also reports that Harmstone says none of the "substantive code" was written by AI. He says AI only helped with mechanical work such as porting and translating.

Btrfs: the safety warning​

Btrfs is central to the project, which is unsurprising given Harmstone's WinBtrfs background. His experience on Windows is not a guarantee of reliability here, though. The README says the Btrfs code works for basic purposes but hasn't been battle-hardened, and it adds: "Please don't try to mount anything but throwaway filesystems."

Treat that as a firm rule. Don't point Moxnox at a disk that holds data you care about.

Hardware support​

Per Linuxiac, the supported hardware is:

• Storage: NVMe, SATA, SD cards, USB mass storage and VirtIO block devices.
• Networking: VirtIO adapters and selected Realtek controllers.
• Input: USB HID and PS/2 keyboards and mice.
• Graphics: framebuffer and text console only (VirtIO GPU, GOP framebuffer, VBE and VGA text). There is no graphical desktop.

x86-64 builds target x86-64-v3, and ARM64 needs ARMv8.1 or later. Linuxiac says that makes Raspberry Pi 5 workable with suitable UEFI firmware. That range is a rough guide, not a promise for every machine. Phoronix says QEMU is the easiest way to test it, due to the limited hardware/driver support.

How to try it safely​

The project provides prebuilt x86-64 and ARM64 disk images and EFI kernels. Its README documents QEMU testing. The example x86-64 setup uses these settings:

1. The q35 machine type, with host CPU and four cores.
2. 1,024 MB of RAM. The README says to raise this for heavy work such as self-hosting.
3. An AHCI-backed disk, VirtIO networking, a USB keyboard and tablet, and serial output.

The README warns that QEMU's default pc machine is too old because it lacks PCI Express. microvm also works. The ARM example uses QEMU's virt machine with a Cortex-A76 CPU. These are examples from the project, not minimum requirements.

Installing on real hardware is documented too, but treat it as an advanced experiment. The README's procedure is roughly this:

1. Create a new partition (32 GB is described as enough) and format it as Btrfs.
2. Extract the Moxnox archive onto it.
3. Copy the EFI kernel to the EFI boot partition.
4. Create a boot entry with efibootmgr.

efibootmgr can change your boot order, and picking the wrong target device can be destructive. The instructions also recommend a recent btrfs-progs, because older versions may use defaults Moxnox doesn't support. A virtual machine is the safer first step.

Known limitations​

Version 1.0 is still experimental. Linuxiac lists these gaps:

• No multiuser support and no proper security mechanisms.
• A single keyboard layout, with no time zone support and little locale handling.
• Slow memory allocation and networking.

What it means for Windows readers​

Moxnox is not a Windows replacement, a ReactOS rival or something to run on a production machine. It matters as an engineering experiment. It shows that NT's system-call design can sit under a POSIX userland, with PE binaries and Btrfs on top. Windows developers and OS enthusiasts may find that worth studying.

A cautious reading is that "1.0" here marks the author's own milestone, not production readiness. The self-hosting claim and the software list come from the project and press coverage, not independent testing. I haven't run it myself.