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
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:
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.
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
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.
dotnet(1) tool working on Haiku.
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
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:
Disabling IPv6 (
Despite defining all the standard constants in compile-time, Haiku does not have full IPv6 support. Some operations that .NET requires (
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 (
.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
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
run workflow, I can set up weekly binary releases on a GitHub repo as well as a NuGet feed providing the latest packages.
I once has an internship where my assigned task was to make a SOAP request by downloading a NuGet package and using that for the task.
Naturally I thought the assignment was to make the request myself.
Also SOAP is terrible.
Anyhow I decided against IT as a Job because of that! : D
downloading a NuGet package and using that for the task.
There’s a NuGet package for almost programming task you can think of. There’s even one for reading Haiku HPKG files.
We would like to try to support other languages in Genio with the full spectrum of features: build and run, syntax highlighting and LSP support (via omnisharp maybe?).
.NET and C# and Python would be our first choices.
So yes, please make the binaries available so we can experiment a bit.