Moxnox is a hobby operating system that seeks to bridge the gap between two major computing philosophies: the architectural design of Windows NT and the software compatibility of POSIX. Unlike ReactOS, which attempts to replicate Windows as closely as possible, Moxnox adopts the low-level interfaces and system calls of the NT kernel while remaining capable of running software written for Unix-like systems. To achieve this, the project implements a wide range of POSIX functions—approximately 642 of the 1,200 functions in POSIX 2024—and includes a full GNU base system. This allows users to run recompiled Unix-like software on a kernel that mirrors the behavior of Windows NT.

A terminal interface screenshot of the Moxnox operating system.
A screenshot of the Moxnox operating system showing its command-line environment.github.com

This image provides a visual representation of the Moxnox operating system's current command-line interface.

The technical implementation of Moxnox involves several specific design choices to maintain this hybrid identity. The system uses PE format binaries with `.exe` and `.dll` extensions, and it handles C++ exceptions through Structured Exception Handling (SEH). It also adopts the Windows calling convention (rcx, rdx, r8, r9) and specific C eccentricities, such as `sizeof(long)` equaling `sizeof(int32_t)`. However, it deviates from Windows in its filesystem structure; while NT uses a complex hidden virtual filesystem, Moxnox uses POSIX-like paths with forward slashes and a `/` root directory. To support the POSIX side, the developer integrated several Linux-inspired features, including a dentry cache, large folios, and evdev support.

Despite its maturity—evidenced by its ability to self-host and its ~130,000 lines of C++—Moxnox currently has several limitations. It lacks a graphical user interface (GUI), support for different timezones, and multi-user capabilities. From a performance standpoint, the project faces bottlenecks in its userspace heap allocator and TCP performance, which currently defaults to a 64KB window without negotiating a Maximum Segment Size (MSS). Additionally, while the Btrfs filesystem support is functional for basic purposes, it has not been 'battle-hardened,' and the developer advises against mounting anything other than throwaway filesystems for the time being.