[GSoC 2023] .NET Developer Platform - Progress Report #5 | Haiku Project

The long awaited stateful FD monitoring has finally been implemented on Haiku, and there now is a partial implementation of kqueue usable in libbsd. Therefore, Release builds of .NET can now work properly (after some more hacks) and have been set as the default in my custom dotnet-install.sh script.


This is a companion discussion topic for the original entry at https://www.haiku-os.org/blog/trungnt2910/2023-08-13_gsoc_2023_dotnet_port_progress_5
18 Likes

Most awesome port ever done to Haiku. Thank you, thank you, thank you! If you can get to the point where I don’t have build anything, can just install and go with binaries that can create C# Haiku GUI apps, that would be monumental.

I hope you have enough time to finish it because if you don’t, it will bit-rot before you know it. The old guard here primarily just want to either kernel fiddle or play with browsers, as if I’m going to waste my time browsing from a VirtualBox image.

1 Like

That is probably slightly harsh.

This is all super useful and it is great that it works. It is more useful than say, WebAsembly, because .Net has some actual infrastructure. But it is not currently useful in a porting UI code metaphor, so you will still end up rewriting code specifically for Haiku.

1 Like

I personally work on what I need on my own computer, which very unsurprisingly includes a working web browser and drivers for the hardware on my machine. And, yes, I don’t know much C# and have no intention to learn more if it doesn’t help me with simply keeping Haiku usable.

No interest in VirtualBox either, I don’t see why people even run Haiku in a virtual machine. But whatever, if writing C# apps that run in VirtualBox makes you happy, that’s great too!

Just sharing my experience regarding the VMs:

In my case… it is just a power efficiency (and heat/noise) issue. No CPU frequency scaling on my hardware (old CPUs) means too much wasted power heat/noise/money.

I use the same installs on both bare-metal and VM, but… I get better use of my hardware when using the VM, at least for now :slight_smile:

So far… got my AMD temp driver working on real-hardware at least :slight_smile: (hoping to be able to do something about the pstates someday!)

Sure, but that’s one more reason to spend time in “kernel fiddle” and not in porting more and more applications, I’d say? (for people who are interested in doing such things)

1 Like

There’s a little advantage to run Haiku in a VM when you have a trouble booting and nothing is written in the syslog. You can make screenshots or paste and copy of the console output that are more readable than pics made with a phone. Other than that it is, at least on my case, lazyness to reboot on an USB key.

It is already bit-rotting, if you follow my dotnet-builds repo. I am actively discussing this issue with the .NET people and will try to find a fix in the next few weeks.

I can promise support until this November (the official release of .NET 8), and then maybe a few alpha builds of .NET 9. Otherwise, I have made an effort to document everything clearly to allow anyone to start taking over my repos as seamlessly as possible.

There are two advantages of creating Haiku bindings, even when one still has to write Haiku-specific code:

  • .NET binaries are not different between OSes, except some metadata and the libraries that the concerned binary references. Having C# bindings and a surrounding SDK allows developers to create Haiku-native applications from their favorite IDE on their favorite OS with first-class integration.
  • Having a C# binding for .NET paves the way for the porting of C# cross-platform app frameworks, like .NET MAUI for the Uno Platform, to Haiku (if anyone is ambitious enough). That’s where we get to the point where we don’t “end up writing code specifically for Haiku”.

Sure, I know this. Day job I work on an Android app that uses shared code with web/desktop WPF. This includes bespoke native code we P/Invoke. Spare time I have an SDK for PSP that uses the DotNet Anywhere runtime. The former is a lot of tooling, but all pretty standard. It os mainly the config in the Nuget packages that causes us grief. The latter was fine till about .Net 6, then a load of stuff changed in Roslyn and getting it to still compile with not standard library was non trivial. All still possible, but more modern .Net tooling is more hostile to this kind of thing.

MAUI, Uno and the other cross platform SDKs would be great, but the threading is always going to be an issue. Having used Xamarin a lot over the last 3 years, it is great when it is going well, but getting the threading right is a real PITA because all .Net frameworks suffer from GUI on the main thread syndrome.

I will get around to testing, but all of my hardware is currently in storage due to house renovations. I only have my MacBook Pro to hand and that flat out refuses to run Haiku.

2 Likes