You might want to get in touch with @jessicah, i believe she’s made some substantial progress on the port and that you may want to take it from there?.
.NET would be a great addition to Haiku. You could perhaps try to get FNA working. This would allow a number of games to run on Haiku: https://fna-xna.github.io/
There is also Ryujinx and probably a lot of other projects that would benefit from having a .NET Haiku port available.
Personally I don’t think I need .net much, but that’s irrelevant. As a GSoC project I think it would work fine: it is well defined, and probably the right amount of difficulty, especially if you already researched it a bit.
C# is still in the top ten list in many developer surveys (PYPL, StackOverflow, TIOBE, etc.).
Personally, I used to love it when I was a professional developer but how it can be relevant to Haiku may be debatable.
C# can barely exist without .NET (there are exceptions, namely a dialect made for Unity) and unless we find a viable solution to include Haiku API bindings, it’s adoption will be limited IMHO.
Haiku API bindings are in fact a part of my proposal.
I have experience in developing .NET workloads so creating one for Haiku would be easy for me.
I also know somewhat about how C++ class works and how symbols can be mangled/demangled so generating .NET classes from Haiku libraries wouldn’t be too difficult.
I find working with C# bindings much easier for many frameworks, for example WinForms vs raw Win32, GtkSharp vs the GTK C api,…
Having a Haiku .NET API binding and being able to develop Haiku applications from Visual Studio would surely attract some more potential developers of native Haiku applications.
Glad to hear that. I’m still minded that it is not a trivial task mainly due to the differences between c# and C++ and in the memory model.
C# has single inheritance and heavily relies on delegates and events while Haiku API is quite in the opposite direction.
But I really look forward to hearing from you.
You can trust me with the job, I’ve done such evil things as generating C# bindings for the browser DOM API based on TypeScript declarations.
In the end it all boils down to using interfaces and IntPtrs. C# events can be a bit trickier; it requires manual analysis of which APIs should fit in the C# event model, and then convert from member functions that takes a callback to C# events (I also have to do that for the web API bindings). As for delegates, they can be easily converted to a function pointer and marshalled to C++ code.
The thing that I’m actually more worried about are inline functions.
I’ll provide a more detailed analysis if/when I get accepted into GSoC and reach the relevant phase.
I really like the idea of porting .NET.
Currently there’s only two languages to write truly native Haiku apps, and that’s C++ and YAB.
All other bindings are incomplete and miss major functionalities, making them not really usable.
Not everyone knows the same language or likes to write apps in the same language, so I think that’s a big step to finally getting more native applications.
I personally don’t know C# very much, in fact I even know some more about C++ (ant that’s still very few) so I’m probably not the right target for your port, but I’d very much appreciate new native apps showing up after that’s done.
When generating bindings, we’re not transpiling C++ to C#.
Instead, we inspect the result binaries, demangle all names and work mostly with pointers or references to block of memory.
Inline functions are problematic because despite being part of the public API, they’re not visible when inspecting compiled libraries. They’re instead baked in each consumer of that API.
To solve this, I am thinking of using a “glue” library that explicitly exports all inline functions as PInvoker-friendly symbols.
Do you have examples of inline functions in Haiku public APIs? I can’t think of much. We do have templates, however, for things like BLayoutBuilder. But that kind of thing is probably better to reimplement natively in C#, anyways?
Template classes, template functions, inline functions or anything that is not present as an exported symbol of the library are equally challenging to bind.
But that kind of thing is probably better to reimplement natively in C#, anyways?
It depends.
Reimplementing things in C# require maintaining another version and will break if Haiku decides to change any of these template classes. For some stable, small, and performance-critical classes that have a large number of instantiations it might be worth it.
For BLayoutBuilder, I think it’s best to create a glue library that exports an instantiation where ParentBuilder = char. BLayoutBuilder classes seem to use pointers with everything, and templates here seem to be only meaningful for type checking, which we can erase at the language interop level, but restore at the C# language level.
