[GSOC 2023] .NET Port

I just want to play osu! on Haiku :wink:

A quick browse through osu!'s source reveals that it depends on SDL. Is it available on Haiku?

If it is then I’ll try to test SDL’s C# wrapper.

SDL2 and SDL are indeed availble as media-libs/libsdl and media-libs/libsdl2

1 Like

SDL was even initially developed on BeOS, I believe.


I’m very pleased to hear that we might be able to write native GUI applications in C#.

If you need some one to test the port, let me know.

I’m a c# backend developer, Have good knowlage about Haiku but not that mutch about c/c++ but know how it’s work and how to make easy changes :slight_smile:

1 Like

Anything we can get ;).

But I do thing it’s important that it’s easy to install and use with what we have ready, what ewer part it is. Thats what’s make c# on Windows so easy, it’s just works…

If anyone wants to play with .NET, there’re some build instructions here:

Building .NET for Haiku

Note that this requires a Linux machine. Also, only some primitive tests are passing, nothing else is really running yet. This is the .NET port’s status as of last year.

1 Like

While things seemed to work a few months ago, everything is broken today.

PAL tests seem to be passing, but there’s some bug related to the JIT, at least on HyClone.
Native Haiku didn’t even get that far to reproduce the bug but segfaults instead.

If this project is to be accepted, it will surely be an interesting and long one.

Don’t have one and it was 10-15 years ago I installed one last time. So I hoping on this project :stuck_out_tongue_winking_eye:


Thank you so much for all your support! This project has been accepted into GSoC 2023!


Behold, the first .NET 8.0 binary running on Haiku.

(The first binary ever was for .NET 7.0 in last year’s effort).

At this stage, it is theoretically possible to run many computation-heavy .NET apps such as the Roslyn C# compiler given enough effort to set up a correct environment.

The source code for this year’s CoreCLR porting effort looks much cleaner, but there are still a few final issues that have to be resolved. I’ve talked about these problems on the IRC channel, but if you’re interested, I can write a blog update this weekend.


A blog update would be nice for those of us that don’t frequent the IRC channel. Though not if it takes a lot of time from your main efforts.


Blog posts are important for long term archival and tracking of the work done. It’s not very convenient to have to find informations about things on the IRC channels after a few years have passed, whereas blog posts can more easily be found and reused.


The .NET CLI is (somewhat) working. I’ll just have to find a way to install the SDK.


dotnet(1) tool working on Haiku.

The helloworld.dll is scped from Linux, I don’t know how to obtain an SDK tarball (yet) so I cannot test dotnet build and other functions.


It’s been a while, but here is the current status of the port:

As said in a blog that should have been merged last week, I am working on the SDK and the managed libraries simultaneously.

After fixing a few Haiku memory bugs, one of which crashes the kernel, this is where I got.

The exception message is due to .NET complaining about a lack of epoll. So today this port officially joins the list of projects affected by epoll.


After applying some hacks to the .NET SDK, dotnet passed the Restore phase and got to the Build phase (where it invokes Roslyn).

Sadly, this phase raises yet another Haiku virtual memory bug and crashes the kernel. Before dotnet could even reach this phase at all, two patches (#6392 and #6394) need to be applied, both of which fix some kind of VM-related Haiku bug.


With a few more hacks, the .NET SDK is working and successfully builds and runs a binary.

Specifically, there are two hacks involved:


Despite defining all the standard constants in compile-time, Haiku does not have full IPv6 support. Some operations that .NET requires (setsockopt with IPV6_V6ONLY) is currently stubbed. I do not have much experience with the internet protocol so for now I will just disable IPv6 altogether.

Disabling the double mapper (COMPlus_EnableWriteXorExecute=0)

.NET has a strange feature that allows mapping the same physical pages once with read-write and another time with read-exec called the “double mapper”. On macOS, it is cleanly implemented using vm_remap. On other UNIXes, a workaround using a shared memory file is used instead.

The implementation for Haiku currently follows the shared memory file path, but this causes problems on fork and also somehow makes the system unstable after multiple usage. Haiku has a method to clone virtual address pages (clone_area), but this function only allows cloning one area at a time, while .NET needs to atomically clone arbitrary ranges of pages.

In my opinion the ideal fix is a new syscall, _kern_remap_memory, that I have mentioned in my previous blog. For a while I thought I could make an attempt to implement this, but I was stuck on the problem of potentially having to merge two VMCaches.

For now, I will just disable this feature to focus on the main goal of this project.


I wonder if there are any interests in binary downloads of the .NET runtime and SDKs for Haiku.

If there is significant community interest in testing my WIP branch, now that it can handle the basic restore, build, and run workflow, I can set up weekly binary releases on a GitHub repo as well as a NuGet feed providing the latest packages.