OSDev.org

Hello,

Just to say that I’ve managed to compile a very basic C# kernel to x86 machine code, and then successfully boot it in QEMU.

I've used the .Net AOT compiler that ships with .Net 7 / 8, as I found the C Sharp Bare Bones tutorial on OSDev Wiki quite out of date.

The repo for my kernel is here: PatienceOS (nb. ignore the 'OS' moniker, high ambitions I guess) and an accompanying blog post with more details here: Compiling a C# kernel to bare metal and booting in QEMU.

Posting this here, in case anyone else is interested in compiling a bare bones, bare metal, C# .Net kernel using contemporary versions of .Net.

Frank

Update - I've introduced XUnit and written some initial unit tests for several of the kernel classes. Interestingly, it involves building and linking the kernel against the standard .Net BCL, rather than zerosharp ie. being able to multi-target which BCL to use.

I took the idea from Building a self-contained game in C# under 8 kilobytes, namely:


One VS solution builds and links the PatienceOS kernel against the custom .Net BCL (zerosharp based), handy for when you are coding within Visual Studio and want to quickly check building against the custom runtime types.

The other VS solution builds and links the PatienceOS kernel against the standard .Net 8.0 runtime, allowing you to develop and run unit tests within the built-in Visual Studio Test Explorer, as per any other .Net unit test project.

See instructions here: Developing PatienceOS

Regards,
Frank

Update - Attempting to develop a whole OS is a pretty big deal, especially if you've never done anything like this before. It's also very easy to quickly become overwhelmed, disillusioned and put off, as my post PatienceOS isn’t living up to its name starts to indicate.

I suspect that maintaining focus on the most interesting things (personally), having a clear list of prioritised topics to delve into, better information management (eg. note-taking whilst also keeping the majority of information pigeonholed until actually needed), and the ability to quickly start and stop new pieces of work as time allows, are major strategies to adopt.

Some ideas to try include:

1. Follow Simon Willison’s advice in How I build a feature.
2. Experiment with community involvement, eg. Top Issues GitHub Action.
3. Adopt practices from the Better Software Requirements handbook

From Simon's article above, I particularly like:

"Every piece of work I do has an associated issue. This acts as ongoing work-in-progress notes and lets me record decisions, reference any research, drop in code snippets and sometimes even add screenshots and video" and also "Being able to quickly spin up a development environment for a project is crucial. All of my projects have a section in the README or the documentation describing how to do this".

I intend to make better use of Issues for managing the ongoing development of PatienceOS.