MyTechDailyNews Software Guide: Moxnox v1.0, a Self-Hosting NT-Like POSIX OS on btrfs

For MyTechDailyNews Software readers, the practical takeaway from Moxnox v1.0 is that it is an experimental self-hosting target, not a drop-in workstation replacement. The release presents a hobby operating system with an NT-like, POSIX-compatible surface: syscall selection follows Windows NT, Unix-like code is expected to run after being recompiled, and a full GNU base system is included. The implementation uses btrfs, a widely familiar Linux filesystem, and the code base is roughly 130,000 lines of C++. It supports amd64 and aarch64. Its btrfs code is functional for basic purposes, but not battle-hardened, so only throwaway filesystems should be mounted.

Software selection checklist

Use a throwaway filesystem: btrfs code is functional for basic purposes, but not battle-hardened.
Confirm architecture: amd64 builds target x86-64-v3, roughly anything manufactured since 2015; Moxnox enables AVX512 when detected.
Use qemu carefully: q35 is needed for amd64 because the old pc machine lacks PCI Express; microvm also works.
Check ARM devices: aarch64 uses LSE atomics and requires ARMv8.1, which means Raspberry Pi 5 but not earlier models.
For Raspberry Pi 5, Moxnox supports ACPI, not Device Tree, so you also need worproject rpi5-uefi; qemu has no raspi5 machine, but virt and sbsa-ref have been usable.
Expect no GUI, no timezone variety, no keyboard layout variety, no locales or non-UTF-8 character sets, no real security, and no multiple users and groups.

Key data from the release

Field	Value
Version	v1.0, also referenced as 1.0
Implementation size	roughly 130,000 lines of C++
Architectures	amd64 and aarch64
Filesystem	btrfs
qemu baseline memory	1024 MB
Suggested partition	32 GB
POSIX function coverage	642 of about 1,200 functions in POSIX 2024
TCP note	TCP is slow because no MSS is negotiated and the default 64KB window is kept

Running a first qemu test

For a first look at the software rather than a hardware evaluation, download moxnox-amd64-1.0.img.gz and moxnox-kernel-amd64-1.0.efi, then decompress the image with gunzip moxnox-amd64-1.0.img.gz. Use the following amd64 qemu command as a baseline:

qemu-system-x86_64 -M q35 -enable-kvm -cpu host -m 1024 -smp cores=4,threads=1 -kernel moxnox-kernel-amd64-1.0.efi -append root=/dev/sda -device ich9-ahci,id=ahci -drive id=disk,file=moxnox-amd64-1.0.img,if=none -device ide-hd,drive=disk,bus=ahci.0 -nic user,model=virtio-net-pci -device qemu-xhci -device usb-kbd,id=kbd -device usb-tablet,id=tablet -serial stdio

If the session will do anything strenuous, such as self-hosting, raise the memory from 1024 MB. For ARM, the following qemu-system-aarch64 style command is the shape to use:

qemu-system-aarch64 -M virt -cpu cortex-a76 -m 1024 -smp cores=4,threads=1 -kernel moxnox-kernel-aarch64-1.0.efi -append root=/dev/sda -device ich9-ahci,id=ahci -drive id=disk,file=moxnox-aarch64-1.0.img,if=none -device ide-hd,drive=disk,bus=ahci.0 -nic user,model=virtio-net-pci -drive if=pflash,unit=0,file=/usr/share/qemu/edk2-aarch64-code.fd,readonly=on -device qemu-xhci -device usb-kbd,id=kbd -device usb-tablet,id=tablet -serial stdio

Installing to a test volume

The install flow is intentionally low-level. Begin by creating a new partition with gparted or a similar tool; 32 GB should be plenty. The examples call the partition /dev/nvme0n1p99, and that name must not be wrong. Make sure a recent version of btrfs-progs is available, because older default settings are not supported.

# mkfs.btrfs /dev/nvme0n1p99
# mkdir /mnt/moxnox
# mount /dev/nvme0n1p99 /mnt/moxnox
# cd /mnt/moxnox
# wget https://github.com/maharmstone/moxnox/releases/download/v1.0/moxnox-amd64-1.0.tar.gz
# tar -xvzf moxnox-amd64-1.0.tar.gz
# rm moxnox-amd64-1.0.tar.gz
# cd
# umount /mnt/moxnox

Then copy the kernel file:

# mount /boot/efi
# cd /boot/efi
# wget https://github.com/maharmstone/moxnox/releases/download/v1.0/moxnox-kernel-amd64-1.0.efi

To create the boot entry, run something like:

# efibootmgr -c -d /dev/nvme0n1 -p 1 -L Moxnox -l moxnox-kernel-amd64-1.0.efi -u root=/dev/nvme0n1p99

efibootmgr may change the boot order afterwards, which usually is not desired. Block device names should be broadly similar on Linux and Moxnox. The EFI file is also a polyglot file that conforms to the Linux boot protocol, so it may work under non-EFI GRUB, although this has not been tested.

Device support

Area	Supported or required items
Block devices	NVMe, SATA, SDHCI (that is, SD cards), virtio-block, USB mass storage
Network cards	virtio-net, RTL8168, RTL8125
Input devices	USB HID, PS/2 keyboard, PS/2 mouse, virtio-input
Graphics	virtio-gpu, GOP framebuffer, VBE, VGA text console; pass text=80x25 on non-UEFI boots
Serial ports	virtio-console, x86 serial port, PL011 ARM serial port
USB	XHCI

Building the project

The most convenient build path is Docker: pull maharmstone/moxnox-ci-amd64 or maharmstone/moxnox-ci-aarch64, which contain cross-compilers for x86_64-pc-moxnox or aarch64-pc-moxnox. Inside the container, start with:

$ git clone https://github.com/maharmstone/moxnox
$ cd moxnox

CMake compiles whichever submodules are checked out. For a minimal system, initialize only the needed ports:

$ git submodule update --init --depth 1 ports/acpica/repo ports/freetype/repo ports/gnu-efi/repo ports/harfbuzz/repo ports/libpng/repo ports/mingw-w64/repo ports/zlib/repo ports/musl/repo ports/tre/repo

For all ports, which may take a while:

$ git submodule update --init --recursive

Then configure and build:

$ mkdir build
$ cd build
$ cmake -DCMAKE_TOOLCHAIN_FILE=amd64.cmake -GNinja ..

$ cmake -DCMAKE_TOOLCHAIN_FILE=clang-aarch64-native.cmake -GNinja ..

Use Ninja because C++ modules require it; the default Unix Makefiles path does not work. Finish with:

$ ninja

Because of their size, gcc, llvm, and rust are not compiled unless explicitly requested. hexyl and ripgrep also need explicit selection because they depend on rust.

To build on Moxnox, follow the same steps, but omit the toolchain file: cmake -GNinja ... gcc, rust, hexyl, and ripgrep cannot yet be compiled in Moxnox, but everything else works eventually. If CMake complains about rust-libc, make sure that Rust submodules are not checked out.

License snapshot

GPL covers the kernel and first-party programs. LGPL covers first-party DLLs. MIT covers the contents of the modules directory. The ports submodules carry their own licences.

Ported tools list

bash
binutils
bison
bzip2
cairo
cmake
coreutils
curl
diffutils
expat
file
findutils
flex
freetype
gawk
gcc (amd64 only)
git
gmp
gperf
grep
gzip
harfbuzz
hexyl
jsoncpp
less
libarchive
libiconv
libpng
librhash
libuv
llvm
m4
make
mako
markupsafe
mesa
mpc
mpfr
nano
ncurses
netcat
ninja
openssh
openssl
patch
perl
pixman
python
pyyaml
readline
ripgrep
rust
sed
tar
vim
wget
xz
zlib
zstd

FAQ for software evaluators

What is missing?

A lot is missing, but this is version 1.0. In particular:

A GUI
Different timezone support
Different keyboard layout support
Locales and non-UTF-8 character sets
Any sort of security
Multiple users and groups

For performance issues and similar concerns:

The userspace heap allocator could be much quicker, and it is the bottleneck when self-hosting.
TCP is slow because no MSS is negotiated and the default 64KB window is kept.
Early writeback on memory pressure should be done.
An LRU system should exist to drop clean pages from the page cache, and the problem is worsened because the dentry cache never prunes, so inodes stay open until deleted.

Obviously, more ports and more hardware support are needed.

How NT-like is it?

The contract is that syscalls and low-level interfaces match those of NT, while daemons and kernel structure do not. This contrasts with ReactOS, which aims to recreate Windows exactly.

Binaries use PE format instead of ELF and have a .exe or .dll extension.
C++ exceptions use SEH.
POSIX signals are handled through Asynchronous Procedure Calls.
All non-kernel kernel-like work is done in ntdll.dll.
The rcx, rdx, r8, r9 calling convention matches Windows.
Its C eccentricities also match Windows: sizeof(long) == sizeof(int32_t), sizeof(wchar_t) == sizeof(char16_t), sizeof(long double) == sizeof(double).

NT contains a lot, but the interesting missing parts are tokens, the Registry, and I/O completion ports.

NT has a complex system where there is a virtual filesystem but it is hidden unless you use winobj, with the true path of a file hanging off the name of its block device, so C:\Windows\System32 might actually correspond to a longer device path. Moxnox does not replicate any of that. Paths are POSIX-like: slashes rather than backslashes, / as the root filesystem, and mounted directories. Unlike real Windows, NtCreateFile resolves . and .., to work better with the dentry cache.

Other things deliberately not copied are the various forms of transactions, which were a product of their time, and the idea of paged kernel memory, which causes more problems than it solves.

How POSIX is it?

We have implemented 642 of the about 1,200 functions in POSIX 2024. This is the vast majority of what is used in practice, with gnulib covering some gaps. Unlike Windows, fork is present. musl is used for mathematical and cryptographic functions, mingw for printf and some other things, and tre for regexes.

POSIX functions are split over ucrtbase, iphlpapi, and ws2_32, as on Windows, while anything Windows does not implement is put in mnposix.

Linux best ideas are borrowed liberally: the dentry cache, large folios, mapping the whole of physical memory, and evdev.

AF_UNIX is half-complete. socketpair works, including for SCM_RIGHTS, and ssh uses this, but normal client-server code does not work.
mkfifo creates an inode, but I/O to it is not redirected to a buffer as it should be.
APCs, meaning signals, are delivered only when a thread returns from a syscall. Therefore, a program doing while true is currently unkillable.

How do I start sshd?

There is nothing that automatically starts daemons yet, so do it manually. First, generate the host key:

# ssh-keygen -A

There are no passwords yet, so you need a /root/.ssh/authorized_keys file so that you can connect. If you have trouble, double-check that /root is owned by root, as sshd will ignore this file otherwise.

Then, start sshd using its full path:

# /bin/sshd.exe

Can this run Windows programs?

No, or at least not yet.

No Win32 DLLs are deliberately implemented, except a few functions in kernelbase that the mingw runtime wants. A future improvement would be to strip these out entirely and then port across Wine versions of the Win32 DLLs. Some parts of Wine, like wineserver and ntdll, would not be needed because Moxnox already handles them.

How much AI is involved?

No substantive code was written by AI. AI was used for mechanical porting work, such as translating autotools to CMake, replacing ioctl calls with tcgetwinsize, translating C structs into Rust, and writing some smoke tests, such as cairo-test and mesa-test.

Claude really shines at reviewing your own commits: give it a hash, and it reports silly memory leaks or deadlocks before you make a fool of yourself.

Why does this exist?

For funsies. Also, the only way to really learn how something works is to write it yourself.

The NT kernel is criminally underrated and pretty much unknown to hobbyists. It had features for which Linux took years to design equivalents, such as eventfd and pidfd.

Windows keeps shying away from full POSIX compatibility. A half-complete version existed in the early days, then WSL1 appeared more recently, only to be abandoned. Nano Server was another cool idea, only to be abandoned as well. This project is the author's take on what Windows could have been.

Common misconceptions

Moxnox is a Windows replacement. No: it does not run Windows programs yet, and Win32 DLLs are not deliberately implemented beyond a few kernelbase functions.
1024 MB is enough for self-hosting. The qemu baseline uses 1024 MB, but strenuous work such as self-hosting needs more; the userspace heap allocator is the bottleneck.
btrfs support is safe for real data. No: the btrfs code is functional for basic purposes, but not battle-hardened; use throwaway filesystems.
This is ReactOS. It is not: ReactOS aims to recreate Windows exactly, while Moxnox matches NT only at syscall and low-level interface selection, not daemons or kernel structure.
POSIX coverage means any Unix software runs unchanged. No: Unix-like software should run after being recompiled, and only 642 of about 1,200 POSIX 2024 functions are implemented.

Action advice

Treat Moxnox v1.0 as a lab for software curiosity, not daily-driver compatibility. If you need a low-risk test, use a 32 GB throwaway partition, recent btrfs-progs, a q35 qemu session starting at 1024 MB, and only non-sensitive data. If you want to evaluate the build chain, use Docker, CMake, and Ninja, then start with the minimal port set before attempting all ports. If your environment depends on security, users, groups, locales, timezones, GUIs, SSH daemons that auto-start, or Windows binaries, wait for the gaps to close.