WingOS is a microkernel OS whose userspace owns the storage stack

The goal is an OS that is easy to program for, not one that runs workloads

WingOS is described as a small hobbyist microkernel based operating system made with less than 3 in C++, and the project description repeats it as a 64 bit microkernel based operating system written in C++ with SMP support.

The stated purpose is worth quoting in spirit because it sets the whole agenda: the project is about creating an operating system that is easy to program for, with a simple and clean API. It tries to experiment with new ideas and API, ditching old and legacy concepts when possible.

That is a different objective from building a usable general purpose system. There is no compatibility target, no POSIX conformance claim in the README, and the feature list is short enough to read in one glance: 64 bit, SMP capable, a basic scheduler with SMP support, priority and CPU affinity, plus a CPU tree for NUMA systems, with NVMe, ext4 and VFS support in userspace.

The audience is therefore people who want to understand how an operating system fits together by reading and changing one. The repository topics say hobby-os, osdev and microkernel, and the existence of a Flutter inspired UI library and a working DOOM in userspace says the same thing from a different angle: the goal is to demonstrate capability, not to serve anyone.

The project also states that it is made by humans and not by a generative AI, and ships a NO-AI-POLICY.md file next to an AGENTS.md, which is a policy choice rather than a technical one but does tell you something about how the project wants to be worked on.

Spaces and handles are the model, capability style

The architectural bet is stated in one sentence: WingOS tries to be a capability based OS, with a focus on security and stability. The keyword there is tries.

The mechanism that a capability model needs is visible in the roadmap, where spaces and handles and userspace objects are both ticked off. Spaces are the isolation units, and handles are the way a program refers to the objects inside them, whether those are virtual memory regions, physical memory, IPC endpoints or tasks. Listing services and IPC as completed means the pieces needed to pass such a handle from one space to another exist and work.

The security implication is the usual one for this model. A process that is handed a handle to a resource can use that resource and nothing else, so a compromised service does not automatically become a compromised kernel. It also implies a cost, which is the usual cost of capability systems: the API is not the one a Unix programmer already knows, and every object needs an explicit grant. The README's insistence on a simple and clean API over legacy concepts is the trade being made consciously.

Where the boundaries are drawn is visible in the feature list. PCI support, described as scanning and devices, sits in userspace, as do interrupt handling for the input stack. Kernel side, the roadmap shows x86 basics such as interrupts and paging, SMP support with the APIC, the scheduler, loading user space applications, ring 3, and syscalls as completed items.

The userspace owns the file system and the disk driver

The feature list marks three storage capabilities as living in userspace: NVMe disk support, ext4 filesystem support, and VFS support. The roadmap repeats it in the entry Hello File! with the annotation NVME + GPT + Ext4 + VFS.

That placement is the interesting decision. In a monolithic kernel design, the block driver, the file system and the virtual file system all sit inside the kernel, with the attendant requirement that they be correct, because a bug in any of them is a kernel bug. Moving them into userspace means they are ordinary programs talking to the kernel over IPC, which is the direction the microkernel argument has been pointing for a long time and which very few hobby systems have actually followed through on.

The payoff is isolation and fault containment. A file system server that crashes takes down the processes that depend on it, not the machine, and it can be restarted. The cost is that every file operation becomes an IPC round trip, which is precisely the performance objection that microkernel designs have historically failed to answer.

What the README does not give is a measurement. There is no benchmark, no latency figure, no statement of how much the IPC boundary costs in practice for a read or a write. The Hello File! milestone is described as achieved, and that is where the evidence stops.

A Flutter inspired UI library with its own rasterizer and widget system

Two of the README's feature claims concern user interface rather than kernels, and they are unusual for a hobby operating system.

The first is that WingOS has a working progress UI library inspired by Flutter with a rasterizer and a widget system. That is a rendering stack written for the OS, and the word progress is honest: the repository links a screenshot of the UI as the first image in the README, which is the sort of thing you show when the widget system draws actual windows.

The second is the DOOM screenshot, described as a WingOS screenshot running DOOM in userspace. Port DOOM is ticked in the roadmap, which means the graphics stack, the file system and the process model were all good enough to run a real program with real assets. For a system whose storage layer sits in userspace, loading a WAD file through ext4 and displaying it through a framebuffer is a real end to end demonstration.

The graphics support entry in the roadmap covers VESA and framebuffer, and input support covers keyboard and mouse with interrupt handling in userspace, so the pipeline is complete enough to host a game.

What the README does not say is what the UI library is good for. Nothing is written about a widget toolkit being the intended path for application developers on WingOS, and the two unchecked items on the roadmap that would make it one, a basic POSIX server and a shell, are both still pending.

Scheduling covers SMP, priority, affinity and a NUMA cpu tree

The scheduler is described in one dense line in the feature list, and each phrase is a separate piece of work.

It is SMP capable, meaning multiple CPUs. It has a basic scheduler with SMP support. It supports priority. It supports CPU affinity, which is the ability to pin a thread to a specific processor. And it has support for a CPU tree for NUMA systems.

The CPU tree is the part that goes furthest. On a non-uniform memory access machine the processors are not equivalent, and a scheduler that treats them as equal will place a thread on a far processor and pay the memory latency. A tree structure over the processors lets the scheduler know which CPUs are close to which memory, and it is not a trivial data structure to get right.

Affinity and priority together are what a scheduler needs to be useful to a real user rather than a demo: affinity lets an application pin its real time threads, priority expresses the relative importance of them, and NUMA awareness stops the scheduler from undoing the locality the application asked for.

The word basic is doing work in that sentence, and the README does not claim more. There is no description of the scheduling policy, of how the run queues are organised, or of how a thread migrates between processors. For a reader who wants to know what the algorithm actually is, the source is the only place it exists.

Building means cutekit, a purpose built cross compiler and QEMU

The build system is cutekit, and the bootloader is limine. The README is upfront that there is no complete dependency list yet, and then lists what you need: cutekit itself, a Clang cross compiler for x86_64, everything needed to build a cross compiler, plus git, wget, gptfdisk, mkfs.fat from dosfstools and qemu.

The first command builds a WingOS specific version of gcc:

bash meta/build/make_cross_compiler.sh

Then the build and run is two words long:

ck s

And a separate command handles ports, the external programs ported to the system:

ck p

The note on that last command is worth repeating because it is a common trip hazard: no ports are buildable as things stand, so you need to do a recursive git clone to get all of them.

The presence of gptfdisk and mkfs.fat in the dependency list is a detail that connects back to the storage design. The system boots with a GPT partitioned disk and a FAT filesystem for the boot stage, which is what limine loads, and the ext4 and NVMe support in userspace take over after that.

The repository also ships project.json and project.lock at the top level, which are the cutekit manifest and its lockfile, and meta/ holds the build scripts including the cross compiler script referenced above.

BSD 2 Clause, no tagged releases, and two unchecked roadmap items

The licence is BSD-2-Clause, with the terms in the LICENSE file at the root. That is a short permissive licence with no copyleft obligation, and for a hobby kernel that people read and modify it is a sensible choice.

Maintenance is active without being versioned. The last push was on 2026-10-05 and the repository is not archived, but it publishes no GitHub releases. The project instead documents itself through milestone blog posts linked from the README, with entries for milestone 1, milestone 2 and milestone 3 on the author's blog, and a website at wingos.org. The milestones are the release units, and they are prose posts rather than tagged software.

The roadmap is the best summary of the state. Booting, x86 basics, SMP support, the scheduler, loading user space applications, ring 3, syscalls, spaces and handles, userspace objects, services and IPC, PCI support, Hello File!, blocking IPC, graphics, input with interrupt handling in userspace, Port DOOM and signals are all done. Two items remain open: a basic POSIX server and a shell.

Those two unchecked boxes are the honest measure of how far the system is from being usable by a program you did not write. Without a POSIX layer, existing Unix software cannot be ported by recompiling, and without a shell there is no interactive environment. A third entry, Above and beyond, is deliberately left vague.

One more logistical note: the project is synced to codeberg, and the README says the aim is to be fully ported to codeberg in the future, so the two hosts are equivalent today but may not stay that way.

Editorial conclusion

WingOS fits a systems programmer who wants to read and modify a small, legible operating system, and who is comfortable building a Clang cross toolchain, running QEMU and reading source rather than documentation. It does not fit anyone who needs a production system, a general purpose Unix, or an API they already know, since the POSIX server and the shell are both unchecked boxes on the roadmap. Before you invest an evening, read the milestone blog posts linked from the README, run the build with ck s and boot the result under QEMU, and then read src/ looking for the parts you intend to change, because the documentation is thin and the code is the documentation.

Frequently asked questions

Official sources

1. Issues
2. License: BSD-2-Clause
3. Project website
4. README
5. Supercip971/WingOS on GitHub