[GSOC 2023] .NET Port

Community
#16

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.

1 Like
#17

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?

#18

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.

#19

Tools like SharpGenTools and SWIG can somewhat simplify this process.

#20

Thanks for your supportive comments the past few days!

I’ve just submitted a proposal for this project, can’t wait until the results are released.

Until then, I’d appreciate any further comments voicing support or any suggestions on what you expect from a .NET port on Haiku.

4 Likes
#21

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

#22

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.

#23

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

1 Like
#24

SDL was even initially developed on BeOS, I believe.

1 Like
#25

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

#26

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
#27

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…

#28

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
#29

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.

#30

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:

2 Likes
#31

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

17 Likes
#32

image
image1639×988 160 KB

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.

17 Likes
#33

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.

2 Likes
#34

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.

8 Likes
#35

image
image1639×988 88 KB

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

3 Likes