x16-PRos is a 16-bit operating system that runs DOS games

Writing a real-mode OS in NASM, with a GUI, in one repository

x16-PRos is a lightweight real-mode multitasking operating system designed for the x86 architecture and written entirely in NASM. It features CLI, TUI and GUI interfaces, supports the FAT12 file system, and includes a large standard software suite.

The framing in the README adds the second purpose: it is also a platform for low-level programming enthusiasts to explore development for x86 operating systems. That is the honest way to read the project, and it changes what you should expect from it.

The feature list shows the scope of what has been attempted. There is MS-DOS compatibility, with native support for running standard MS-DOS `.COM` and `.EXE` executables, and the README claims Windows 1.01, DOOM and Turbo C 2.0 run on x16-PRos. Multitasking is cooperative, for `.PLE` programs, which are the native program format. The GUI is a customizable graphical user interface for windowed `.PLE` programs.

There is a native assembler, an Intel syntax assembler with which you can create programs directly in the operating system. User authentication is a login system with a configurable user account using an XOR-encrypted password. Customization covers 10+ color themes and a fully customizable THEME.CFG, along with the command prompt, username, timezone and font settings.

Then the parts that make it feel like a system rather than a demo. Over 40 bundled programs including games, file utilities, players, a BMP viewer with upscale and a paint program. First-boot setup, a wizard that installs the OS on your PC and helps you customize everything. AUTOEXEC.BIN support. A mouse driver for `.BIN` and `.PLE` programs and for the MS-DOS compatibility layer. Multiple disk support to detect and list drives, switch drives and install x16-PRos on any of them. cp866 support for reading Russian-language text documents in cp866 encoding. And sound, covering the PC speaker, Sound Blaster WAV playback and AdLib/OPL2 IMF music.

The last line of the feature list is just AND MUCH MORE, which is a good sign of the author's relationship with the reader.

Building it is four packages and a script

The dependency list is short, which is one of the appeals of the project. The table gives the command per distribution family: `sudo apt install nasm mtools dosfstools qemu-system-x86` on Debian and Ubuntu, the same four with pacman on Arch and Manjaro, and with dnf on Fedora and CentOS.

Only NASM, mtools and dosfstools are needed to build x16-PRos, and QEMU is for running. That split is worth noting because it means you can build the disk images on a machine with no virtualisation at all.

The build itself is three steps. Clone and change directory:

git clone https://github.com/PRoX2011/x16-PRos.git
cd x16-PRos

Make the build script executable:

chmod +x build-linux.sh

And then run it:

./build-linux.sh

The outputs are a bootable 1.44 MB floppy image at `disk_img/x16pros.img`, a 5 MB hard disk image at `disk_img/HDD.img`, and the separate binaries in `bin/`.

The advanced flags are documented too, and they are the interesting part for anyone who wants to iterate. `-quiet` disables all script messages but not nasm's warnings and errors, and `-no-music` and `-no-txt` leave music and text files out of the system build. `-no-boot-recomp` and `-no-kernel-recomp` skip recompiling the bootloader or the kernel and use the previously compiled ones from `bin/`, which is the flag that makes a fast edit-compile-test cycle possible. And `-dtm` disables setup on first boot for development testing.

The last flag is the one to reach for first. Every first boot otherwise runs the setup wizard, which is not what you want when you are testing a change to the kernel.

Running it means QEMU with two floppies and a sound card

The run script is the normal path:

./run-linux.sh

The script starts QEMU with both floppies, the hard disk, PC speaker and AdLib sound.

The by-hand invocation is also given, and it shows exactly what the run script does:

qemu-system-x86_64 -display gtk -fda disk_img/x16pros.img -machine pcspk-audiodev=snd0 -device adlib,audiodev=snd0 -audiodev pa,id=snd0

Reading that command line is a good summary of the project's ambitions. The `-fda` attaches the floppy image as drive A, and `-machine pcspk-audiodev=snd0` wires the emulated PC speaker to a backend called snd0, which is how a machine with only a PC speaker gets sound on a modern Linux host with PulseAudio. The `-device adlib,audiodev=snd0` adds the AdLib card, and the `-audiodev pa,id=snd0` points it at the PulseAudio backend. The `-display gtk` gives you a window.

Running on real hardware is supported too. You write the image to a USB stick, or to a floppy, and boot in BIOS mode, and on a UEFI machine you turn on CSM or Legacy Boot first.

That last sentence is the constraint that dates the project to the pre-UEFI era, and it is also what makes the guest real-mode code authentic. A modern machine with Secure Boot and no CSM option will not boot it, which is the price of a real-mode operating system in 2026.

DOS compatibility is the interoperability story

The DOS compatibility is what makes x16-PRos more than a closed system, and it is implemented in layers.

The native support for running standard MS-DOS `.COM` and `.EXE` executables means the same PC that boots x16-PRos can also run DOOM, Windows 1.01 and Turbo C 2.0. The mouse driver is documented as covering `.BIN` and `.PLE` programs and the MS-DOS compatibility layer, so a DOS program gets mouse input as well.

There is a native assembler, Intel syntax, with which you can create programs directly in the operating system. So the workflow is: boot the OS, edit or write a program in the built-in assembler, run it. That is a complete loop with no external toolchain, and it is the thing that makes the system educational rather than merely a bootable image.

The `.PLE` format is the native one, and it is what the multitasking and the GUI are for, with cooperative multitasking support for `.PLE` programs and a windowed interface for them. The distinction is that a `.PLE` program is aware of the system's windowing and scheduling model, and a DOS program is not, which is why the mouse and the multitasking do not compose in the same way.

The bundled program list is in docs/PROGRAMS.md with screenshots, and the screenshots in the README show a terminal, a GUI, a setup wizard, a file manager, DOOM and a hex editor. DOOM running is the screenshot that tells you the DOS compatibility is real rather than aspirational.

The documentation, the contributing guide and the todo file

Four documents carry the project, and each one is linked from the README.

The API document, docs/API.md, covers the x16-PRos system calls, and it is the contract for anyone writing a `.PLE` program. The programs package document, docs/PROGRAMS.md, lists every bundled program with screenshots, which is the fastest way to see what the software suite actually contains. The configuration document, docs/CONFIGURATION.md, covers the config files and what each of them changes, which matters because the system has a THEME.CFG, a command prompt configuration, username, timezone and font settings, and the first-boot wizard is where you set them. And CONTRIBUTING.md covers the coding standards, the program templates and how to send changes.

There is a repository layout detail that says a lot about the project. Alongside src/, programs/, scripts/ and docs/ there is a project_philosophy.txt and a todo.txt at the root. A todo list kept in the repository, next to a statement of philosophy, is what a project that is openly unfinished looks like. The README also carries a note that this is a minimalist system, and the two together are more informative than a feature list.

The contributing section lists four ways to help: report bugs on GitHub Issues, submit code by forking and opening pull requests, write programs using the PRos API, and improve the docs by email. That third item, write programs, is unusual to see listed as a contribution category and tells you the software suite is meant to grow from outside.

The project is MIT licensed with a LICENSE.TXT at the root, the primary language is Assembly, and the last push was on 2026-10-19 with version 1.0 tagged on 2026-09-24 after v0.9 in May and v0.8 in March.

Editorial conclusion

Adopt x16-PRos if you are learning x86 real-mode kernel development, or if you want a toy operating system you can build from source and poke at in QEMU without any hypervisor setup. Skip it if you need a general-purpose or production operating system, because this is a hobby project in a documented state of partial completion, with a todo.txt in the repository root. Verify first that your host can run QEMU with the sound devices the run script expects, that you are on Linux for the build scripts provided, and that you read the API documentation before writing a .PLE program, since the system call interface is the contract you build against.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. PRoX2011/x16-PRos on GitHub
4. README
5. Releases