OS News Archive

Neptune OS is a Windows NT personality of the seL4 microkernel. It implements what Microsoft calls the “NT Executive”, the upper layer of the Windows kernel NTOSKRNL.EXE, as a user process under the seL4 microkernel. The NT Executive implements the so-called NT Native API, the native system call interface of Windows upon which the more familiar Win32 API is built. These are exposed to the user mode via stub functions in NTDLL.DLL (a somewhat redundant name if you ask me) with names such as NtCreateProcess. The NT Executive is also responsible for the Windows kernel driver interface (known as the Windows driver model), which includes functions like IoConnectInterrupt and IoCallDriver. On Windows these are loaded into kernel mode and linked with the NTOSKRNL.EXE image. On Neptune OS, we run all the Windows kernel driver in user mode and they communicate with the NT Executive process via standard seL4 IPC primitives. The eventual goal of the Neptune OS project is to implement enough NT semantics such that a ReactOS user land can be ported under Neptune OS, as well as most ReactOS kernel drivers. In theory we should be able to achieve binary compatibility with native Windows executables provided that our implementation of the NT Native API is sufficiently faithful. We should also be able to achieve a high degree of source code compatibility with Windows kernel drivers. The main obstacle of achieving binary compatibility of kernel drivers is that many Windows kernel drivers do not follow the standard Windows driver communication protocol (ie. passing IRPs when you need to call another driver) and instead just pass pointers around and call into other drivers directly. In Neptune OS unless it’s a driver-minidriver pair we always run “kernel” drivers in their separate processes so it is not possible to do that. Very cool idea for a project, and awesome to see that they plan on integrating the work done by the ReactOS team.

As many of you have no doubt noticed, a recent bug in our CMS flipped everyone over to our experimental dark mode (along with some other quirks). We haven’t had the time to address the issue at its core yet, but for the time being, if you’re a registered user, you should be able to get light mode back now by clicking the “Revert to Light Mode” link in your right sidebar. We’ll get light mode working for non-logged-in users ASAP. I sincerely appreciate that so many people emailed us to tell us how much you hate the dark mode. Really! Let us know in the comments if you notice anything else.

Oxide announced Hubris, their microkernel OS for embedded systems, and Humility the debugger for it. As time went on in early 2020 and we found ourselves increasingly forcing existing systems out of the comfort of their design centers, we wondered: was our assumption of using an existing system wrong? Should we in fact be exploring our own de novo operating system? Instead of having an operating system that knows how to dynamically create tasks at run-time (itself a hallmark of multiprogrammed, general purpose systems), Cliff had designed Hubris to fully specify the tasks for a particular application at build time, with the build system then combining the kernel with the selected tasks to yield a single (attestable!) image. This is the best of both worlds: it is at once dynamic and general purpose with respect to what the system can run, but also entirely static in terms of the binary payload of a particular application — and broadly static in terms of its execution. Oxide is working on producing what is basically a rack sized blade server. It’s a rack pre-populated with hardware controlled by a single control plane. The rack is meant to be a single, sealed unit, and as such, they needed something which could be embedded into the various controllers in the rack. Hubris is written in Rust, it’s MPL licensed, and there is a GitHub repository.

Today we celebrate the third birthday of SerenityOS, counting from the first commit in the git repository, on October 10, 2018. Previous birthdays: 1st, 2nd. What follows is a list of interesting events from the past year, mixed with random development screenshots and also reflections from other developers in the SerenityOS community. SerenityOS is simply a great project, with a good mindset, good people, and lots and lots of talent. These birthday posts are a great way to check if you’ve missed any of the developments around the project this year.

The FyneDesk project is taking a fresh look at what it means to be a desktop environment. Using the same beautiful and user friendly graphics of the Fyne toolkit you will find it a great place to call home on your computer. We also want to make it easy to update, add to or change your desktop just like you can with any other Open Source software. And so the design of our desktop project has put ease of learning and development in the centre of how we work. Now you can have the desktop of your dreams – and share the result for others as well. That’s some flowery language, but look past it and there’s a number of very interesting projects here. The desktop environment itself seems a bit rough around the edges, but the underlying toolkit is quite fascinating – it’s not yet another Qt or GTK derivative, but instead completely new and written in Go. There’s a number of applications, too.

I am one of the RSoC (Redox Summer of Code) participants (students) this year (2021). As part of RSoC, I have been working on porting QEMU to Redox OS for the past one month. This is my first post detailing my project in order to give you an insight into it and what the future might hold. This will be an interesting project to follow.