# XenevaOS: an operating system written from scratch on a hybrid Aurora kernel > XenevaOS is a from-scratch operating system in C with its own hybrid kernel called Aurora, targeting x86 and ARM with a compositor, window manager, graphics library, terminal and desktop environment, plus an XR direction built around a single core with multiple domains. It suits systems programmers who want to read and modify a whole operating system, and the project says plainly that it is in early development with many listed features not implemented yet. **manaskamal/XenevaOS** — The Xeneva Operating System - Repository: https://github.com/manaskamal/XenevaOS - Stars: 744 · Forks: 60 - Language: C - License: BSD-2-Clause - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/manaskamal-xenevaos ## Aurora, a hybrid kernel with a higher half memory map XenevaOS is described as an operating system built from scratch targeted at modern hardware, designed for both x86 and ARM architectures with plans for RISC-V implementation in the near future. The kernel has its own name, Aurora, and is described as a hybrid kernel. The specific architectural commitments in the feature list give the shape of it. There is a fully higher half memory model with MMIO mappings, which is the modern x86-64 convention where the kernel runs in the upper half of the address space and the lower half is left for user space. Memory mapped I/O is handled through the same mechanism. There is ACPI support through acpica, and the repository has an `Acpica/` directory and a `Boot/` and `BootAA64/` pair, so the firmware handoff is implemented for both architectures. The `Aurora.sln` file at the root and the `Kernel/` and `KernelAA64/` directories confirm the same split in the kernel itself. Driver loading and linking happens through dll files, which is the mechanism behind the drivers the project lists: Intel High Definition Audio, USB3 class drivers including a USB HID mouse, a USB tablet and a USB MSC driver, a DWC2 OTG driver as the USB controller, and Virtio drivers. Storage support covers AHCI/SATA and NVMe. Networking covers IPv4 and IPv6, UDP, IP, TCP, IP, ICMP, NDP and routing, and there is a Bluetooth stack with Bluetooth HCI UART. Multiprocessor support is listed, and the feature list annotates it with a warning in brackets: the multiprocessor scheduler is not ready. That kind of inline caveat in a feature list is a sign the author is being straight about the gap between the item and the state of the item. The project is licensed BSD 2-clause, the primary language is C, and the last push was on 2026-10-19. ## Deodhai composites, Chitralekha draws, Namdapha is the desktop The user-facing side of the system is built from named components, and the names are distinctive enough that they are worth tracking. There is a compositing window manager called Deodhai, a graphics library known as Chitralekha, a Xeneva Terminal with basic ANSI and VT100 escape sequence support, and a desktop environment called Namdapha Desktop. There is also an audio server called Deodhai-Audio, described as working in 44kHz/16bit audio format with stereo and mono panning and gain control. Fonts come from Freetype2 as the font rendering engine, which is the standard choice for a system with no legacy of its own, and it means the terminal and the desktop can render proportional text without the project having to write a rasteriser. The compositing model is the significant design decision here. A compositing window manager draws every window into an offscreen surface and then composites those surfaces to the screen, which is what makes effects like blur, transparency and shadows possible, and it is also what makes a 3D interface a reasonable goal rather than a fantasy. The stated goal is a native 3D interface as GUI making it suitable for XR, AR and VR computing. The XR direction is not a separate product. The goal section says XenevaOS aims to be a single core with multiple domains, with XR (AR and VR), robotics and custom niche solutions given as examples. One kernel serving several domains means the isolation boundary between, say, an XR compositor and a robotics controller is a domain boundary inside one system rather than a hypervisor between two. The application list is what shows the desktop in use. Accent Player, an audio player, a file browser, a calculator, the Xeneva Terminal, XEShell, the DeodhaiAudio server, two command line applications called play and piano, a calendar, and background services such as a Net Manager. There is also a Netsurf browser, marked as work in progress, and a set of games including Doom II, Knplay with pacman and flappy bird. ## Building on QEMU first, MSVC and MSYS2 for the other paths The build documentation is split by host and target, which tells you the maturity of each path. The project supports Windows and Linux development environments. On Windows there is the MSVC workflow, and a separate AArch64 build instruction set for the Windows and MSYS2 paths. On Linux there is the AArch64 LLVM and Clang build, and that one is described as the maintained Linux and QEMU compatibility workflow. The word maintained is doing work there, since it distinguishes the Linux path from the others. The build instructions live in `Docs/BuildInstructions.md` for the Windows MSVC route, `Docs/BuildInstructions(ARM64).md` for the Windows AArch64 routes, and `Docs/BuildInstructions(Linux).md` for the Linux QEMU workflow. The `Docs/` directory also holds `Index.md` as a table of contents, `Introduction.md` as a high-level overview and `Contributing.md` alongside an AI policy document. There is a Makefile at the root, and it shows what the XR work looks like from the host side. The comments describe it as host-side only convenience targets, with `make xr-demo` building two tools, `xeneva-xr-view`, an HMD viewer, and `xeneva-xr-client`, an interactive monitor client. The guest side, DeodhaiXR with the OpenXR QEMU runtime, is configured and launched from a modular Bash TUI, and the comment gives the invocation as `Scripts/Linux/build_and_run_qemu.sh --llvm --xr-demo`. The full flow described in that comment is worth reading, because it shows how far the XR path has been carried: a build script with an `--xr-demo` flag, then a viewer using EGL, then output to a Quest 2 over WiVRn. That is a real end-to-end path rather than a stub, and it involves a separate toolchain per host, an OpenXR runtime inside a guest, and a wireless display link to a headset. The Makefile itself is short, and the targets are the whole of the host-side XR tooling: ```bash xr-demo: xr-view xr-client xr-view: $(MAKE) -C Tools/xeneva-xr-view xr-client: $(MAKE) -C Tools/xeneva-xr-client ``` The top level listing shows the rest of the build surface: `Solutions/`, `Templates/`, `Tools/`, `Libs/`, `Vendored/`, `Ports/`, `Process/`, `Resources/`, `Icons/`, `DCL/`, `BaseHdr/`, `XELoader/`, `LittleBoot/`, `Scripts/`, `Tests/`, and both `tests/` and a `test_xeshell.sh` script at the root. A `Directory.Build.props` file and a `.vs/` directory show that the MSVC path is the one the project is developed against. ## What the project admits is not finished The README carries a note that deserves to be quoted in substance, because it is unusual in how plainly it states the gap between the feature list and the state of the code. It says XenevaOS is in early development, and that some of the features listed are not implemented yet, because the project is at foundation level. The commitment stated is to explore each of them through focused iterations and community feedback. So the feature list is a roadmap as much as a description, and the annotations in it are the guide. The multiprocessor scheduler is marked not ready. The board support entries are marked work in progress: the iMX8MP SoC based board, the Toradex Verdin Dahlia SoM, and the BCM2837 SoC based Raspberry Pi 3b+ board, while the QEMU Virt Board carries no such marker. The Netsurf browser is marked work in progress. The RISC-V implementation is listed as upcoming rather than present. That last set of markers is genuinely useful. The QEMU Virt board is the one target without a work-in-progress label, which makes it the sensible place to start, and it is consistent with the Linux QEMU path being called the maintained workflow in the build section. The project is also explicit about its own origins. It says the project was not started with a specific goal or purpose in mind, that it began as a passionate solo developer project aiming to learn and address what existing operating systems lack, and that as it grew it became necessary to have a clear purpose. It has since evolved from a one-person effort to a collaborative team. The stated purpose is worth reading carefully, because it explains the design choices. The argument is that mature kernels are feature-complete but come with layers of legacy code that make it difficult to experiment with new ideas on top of them, and that XenevaOS aims to provide a flexible playground for experiments with new designs and architectures. The stated goals include minimal software abstractions as the project grows, handling dependencies and errors transparently, and researching new low-level architectures with security concerns in mind, such as lightweight sandboxes and memory safety techniques. ## Against Linux and against a hobby kernel that boots and stops The comparison is not between XenevaOS and another hobby OS, but between XenevaOS and the two realistic reasons to look at an operating system at all. The first reason is learning, and against that the comparison is straightforward. A hobby kernel is usually a small, readable codebase that boots, prints a message and stops, and that is a weekend's worth of reading. XenevaOS is a different kind of object: it has a compositor, a window manager, a graphics library, a terminal, a desktop environment, an audio server, a Bluetooth stack, a web browser and a set of games, all in one tree. The value is not that it is small, it is that you can trace a keypress from the USB HID driver through the compositor to the terminal and back out through the audio server, in one repository, with no userspace inherited from somewhere else. The second reason is using it, and here the honest answer is that it is not usable yet. An operating system that lists a feature set of this size, marks its scheduler and most of its real hardware board support as work in progress, and describes itself as being at foundation level, is not a candidate for anything you depend on. The comparison with Linux is not close, and pretending otherwise would be misleading. The comparison with a mature kernel on its own terms, though, is where the project makes a real argument. The claim is that mature kernels come with legacy layers that block experimentation, and that a from-scratch system with minimal abstractions gives you a place to try new designs. That argument is a design philosophy rather than a feature, and it is the thing to evaluate if you are reading the source. The domain model is the other differentiator. A single core serving XR, robotics and custom workloads through domains, with research into sandboxes and memory safety as a stated goal, is a coherent idea for a system aimed at embedded and specialised targets. Whether it is the right shape for those targets is a question the project is still answering, and the existence of an end-to-end Quest 2 path through WiVRn suggests it is being answered in public. ## Conclusion Adopt XenevaOS if you are a systems programmer who wants to read, build and change a whole operating system, and follow the QEMU path first since the board support for real SoCs is still work in progress. Do not adopt it as a daily driver or as a platform for production software, because the project states it is in early development at foundation level, and check first that the features you need are actually implemented, since the list in the README mixes shipped items such as the compositor and terminal with several marked as not yet done. ## FAQ ### What is the Aurora kernel in XenevaOS? Aurora is XenevaOS's own hybrid kernel, the base the operating system is built on. The feature list mentions a fully higher half memory model with MMIO mappings, ACPI support through acpica, x64 and arm64 kernels, driver loading and linking through dll files, and multiprocessor support whose scheduler is not ready yet. ### Which architectures does XenevaOS target? Both x86 and ARM, with plans for a RISC-V implementation in the near future listed as upcoming. The kernel directories are Kernel/ and KernelAA64/, with matching Boot/ and BootAA64/ directories, and the graphics library, compositor and window manager are named Chitralekha, Deodhai and Deodhai-Audio respectively. ### How do I build XenevaOS? The project supports Windows and Linux hosts. There is an MSVC workflow on Windows, an AArch64 Windows and MSYS2 path, and an AArch64 LLVM and Clang build on Linux that the docs describe as the maintained Linux and QEMU compatibility workflow. The instructions live under Docs/ in the repository. ### Is XenevaOS finished enough to use? No. The README states that XenevaOS is in early development, that some of the listed features are not implemented yet, and that the project is at foundation level. The scheduler is marked not ready, most real hardware board support is marked work in progress, and Netsurf is listed as work in progress. ### What user-facing software does XenevaOS ship with? The installed application list includes Accent Player, a file browser, a calculator, the Xeneva Terminal with ANSI and VT100 support, XEShell, the DeodhaiAudio server, the play and piano command line applications, a calendar, and background services such as a Net Manager. There is also a Netsurf browser, marked work in progress. ### What is the XR support in XenevaOS? The project targets a native 3D interface as GUI for XR, AR and VR computing, and aims to be a single core with multiple domains covering XR, robotics and custom solutions. The root Makefile has host-side xr-demo targets building an HMD viewer and an interactive monitor client, and the guest side runs through a QEMU OpenXR path to a Quest 2 over WiVRn. ## Sources - [Issues](https://github.com/manaskamal/XenevaOS/issues) - [License: BSD-2-Clause](https://github.com/manaskamal/XenevaOS/blob/master/LICENSE) - [manaskamal/XenevaOS on GitHub](https://github.com/manaskamal/XenevaOS) - [README](https://github.com/manaskamal/XenevaOS/blob/master/README.md) - [Releases](https://github.com/manaskamal/XenevaOS/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/manaskamal-xenevaos