Compiling a C# kernel to bare metal and booting in QEMU

[FrankRay78]

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

[FrankRay78]

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:

For example, parts of the game could be included from an xUnit project to get unit test coverage.

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

[FrankRay78]

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.

[FrankRay78]

UPDATE - I'm pretty sure I'm going to abandon PatienceOS, at least for a while, as I'm finding 95% of my time is spent fighting the .Net AOT compiler, rather than being able to learn and develop an OS.

I think I have fallen foul of the advice here: https://osdev.org/Languages

eg. C# has no ability to include assembly code, and it also seems no standard way to link to other object files once AOT compiled. So writing to an output port becomes very very difficult. It does allow p/invokes to other dll's, so that's one possibility, however embeddeding the DLL to p/invoke seems to only be possible when using the 'dotnet publish' command, which does not respect my asm bootloader. The Microsoft linker doesn't offer linker templates, so the fine-grain control offered by LD is not possible. All sorts of compiler methods need to be implemented, for example, RhpNewFast, for new object creation, which is orders of magnitude harder than a basic malloc implementation.

It's obviously possible to have a C# compiled kernel, ie. MOOS and FlingOS (nb. Fling has a handrolled C# to native compiler), but I think as a starter OS for someone with zero low-level experience, C# was a bad choice. Perhaps once I've handrolled a C OS, I'll come back to PatienceOS with fresh eyes.

[eekee]

I wish you well with your C OS. I had to abandon my Forth plans because you need to know loads of different tricks to write good Forth, and I wasn't finding it easy to learn them.

On another note though, can you please not colourise your links? I have to lean right into the screen to read them.

[FrankRay78]

Sorry eekee, I didn't realise I was harming accessibility. Point noted.

[kerravon]

eg. C# has no ability to include assembly code, and it also seems no standard way to link to other object files once AOT compiled. So writing to an output port becomes very very difficult. It does allow p/invokes to other dll's, so that's one possibility, however embeddeding the DLL to p/invoke seems to only be possible when using the 'dotnet publish' command, which does not respect my asm bootloader. The Microsoft linker doesn't offer linker templates, so the fine-grain control offered by LD is not possible.

The author of pdld (a public domain linker that handles a variety of input and output formats) may be willing to fill this "market gap" you have identified.

You'll need to be able to articulate the options more accurately with example object code you are attempting to link together.