Looks promising!
A few questions for you:
The approach that CppSharp (and probably any C# binding generator for languages with multiple inheritance like C++ or TypeScript) use is letting that class inherit one base class only. For the other classes, additional interfaces are generated; those classes and any other classes that directly inherit them in C++ will have C# classes implementing the corresponding interfaces.
For example, the declaration of BMenuItem is:
public unsafe partial class BMenuItem : global::Haiku.Support.BArchivable, global::Haiku.App.IBInvoker, IDisposable
I am currently working on that. vtable interop is currently faulty for some reason, any attempt to call virtual methods on a derived class results in a segfault.
Currently not. If I remember correctly, CppSharp contains a native part based on LLVM. It therefore cannot run on Haiku.
Generation is currently done on Linux using a cross-compile rootfs or a HyClone HPREFIX.
It’s been a while, but I have made significant improvements to the bindings.
The sample application now looks like this:
using Haiku.App;
using Haiku.Interface;
using static Haiku.Interface.Symbols;
public class Test : BApplication
{
private readonly BWindow _mainWindow;
public Test() : base("application/x-vnd.Test")
{
_mainWindow = new MainWindow();
_mainWindow.Show();
}
public static void Main()
{
var application = new Test();
application.Run();
}
private class MainWindow : BWindow
{
public MainWindow()
: base(new BRect(100, 100, 740, 580), "Main Window", WindowType.TitledWindow, B_QUIT_ON_WINDOW_CLOSE)
{
}
}
}
Most significant changes are:
0 parameter passed to BWindow by the MainWindow constructor has been removed. CppSharp now generates default parameters, allowing us to omit this 0 just like on Haiku.TitledWindow) instead of Haiku/BeOS convention (B_PREFIX_SCREAMING_SNAKE_CASE B_TITLED_WINDOW).using static Haiku.<Kit name>.Symbols, these names can be used the way they are used in C++. Note that the class name Symbols is temporary; I am thinking of a name that is more futureproof and will not be likely to clash with future Haiku classes.Currently my bindings include the Application, Interface, Kernel, Storage, and Support kits. For the Kernel kit only enumerations and constants are generated; low level system functionality involving C-style non-member functions should be accessed through the standard .NET APIs and/or through manual P/Invokes like on other OSes.
Macros are currently not converted. There might also be some mistakes in the marshalling of a few types/methods. The only way to discover these issues is to try to use the bindings to create some real applications. Therefore, in the next few days I will organize my code into a proper build system while waiting my PRs to CppSharp to get merged and try to make the bindings available for testing as soon as possible.
I have created a net8.0-haiku workload. However, it is currently not working on mainstream .NET due to the lack of official support for the haiku-x64 RID.
There are a few other random things I have to take care of, hopefully the bindings and workload source code, and maybe along with a blog post, will be up this time next week.
trungnt2910/dotnet-haiku: Home of the unofficial custom .net8.0-haiku TFM (github.com)
I have uploaded the source code for the .NET workload for Haiku here.
I will upload instructions to install this workload from NuGet without going through the whole build process in the next few days. I might also write a blog on how everything works; creating .NET workloads is something not many people outside of Microsoft and probably Samsung know.
As for the workload itself, I will respond to any feedback posted here, on IRC, or on GitHub issues. I am exploring the generated DoxyGen documents and see if I can integrate them into the C# bindings. Also, if/when proper support for epoll/kqueue comes I will experiment more with building apps natively on Haiku.
So - this workload can be used under Haiku, or needs to be used on another platform with .Net 8? I will give it a go as I do .Net day in day out.
In its current state, it can only be used on Haiku. As documented on the README, the workload requires the haiku-x64 RID, which is only available on my custom .NET builds for Haiku.
In the future, when .NET finally decides to merge this PR, theoretically, the workload can be installed on other platforms as well. This means building Haiku apps with Visual Studio Intellisense will be possible.
If you really need to run this workload under Linux or Windows, you can build .NET from source with that PR applied; but it would be a time-consuming process.
I can also publish the Haiku.dll binary as its own NuGet package, allowing projects to add it as a normal PackageReference. I will do this if you want to bypass the complicated workload installation process and get straight to the API bindings.
Yeah - that would be helpful as I would probably ssh the compiled stuff to Haiku as it lacks a decent IDE.
I have updated the workload repository to include install instructions:
To install, run the install-manifest.sh script:
bash -c "$(curl -fsSL https://raw.githubusercontent.com/trungnt2910/dotnet-haiku/HEAD/install-manifest.sh)"
The script requires dotnet, curl, jq, and unzip to be installed and be available in $PATH.
It installs the latest version of the advertising manifests for the Haiku workload.
After that, the haiku workload will be available for install like any other workload:
dotnet workload install haiku
Note that you have to subscribe to @trungnt2910’s GitHub Packages feed.
If .NET for Haiku from the dotnet-builds repository has already been installed, you have already subscribed to this feed.
Otherwise, run:
dotnet nuget add source --username your_github_username --password your_github_token --store-password-in-clear-text --name dotnet_haiku_nuget "https://nuget.pkg.github.com/trungnt2910/index.json"
your_github_token should be a personal access token with at least the read:packages permission.
I have published this standalone Haiku API package on GitHub Packages. It contains Haiku.dll and the required libHaikuGlue.so and works without the workload.
Package Haiku.Templates (github.com)
The workload now comes with a set of templates.
Just like any other .NET workload, to create a new net8.0-haiku application, simply run:
dotnet new haiku
Cool. I will give it a go today! My main hold back was lack of hardware as I had to take Haiku off my main machine as I needed the space for another OS for a project.
I have a computer running a nightly, do I need to do anything specific to get it to run outside of your instructions? I will build under MacOS probably.
Theoretically, you just need to follow the instructions from the two repos. First install the custom .NET build, then install the workload.
If you do run into any problems, please inform me so that I could update and improve my guide.
I have tested .NET with the recent event_queue change by waddlesplash. While some minor new problems do arise, the major blocker for the SDK has been fixed.
The script from my dotnet-builds repo has therefore been updated to provide Release builds of .NET. These builds should be much much faster (nearly as good as Microsoft’s official builds on Linux and other supported platforms).
From now I will try to use this build of .NET to bootstrap .NET from Haiku and potentially run more library/runtime tests.
The project is finally coming to an end.
It is a bit sad that there are still some technical difficulties in providing the documentation for the Haiku API bindings, as well as various problems preventing .NET from being built natively on Haiku (for now).
For the last few days, I am trying to keep .NET up to date with the changes upstream. A recent change from Microsoft broke the dotnet-builds repo, and a few extra flags related to runtime IDs need to be passed to fix the build. Then, some components of .NET are starting to bump their versions to .NET 9, so my pipelines are also updated to release two versions simultaneously: .NET 8 rc2 and .NET 9 alpha.
In the future, I will try to keep the .NET builds stable and updated, at least until .NET 8 gets officially released this November. After that, I will treat this project like any of my other personal open-source projects - the one with the most community interest will get my attention (when I have free time).
Another (quite old) PR from the arcade repo has been merged: Haiku: Update arcade support by trungnt2910 · Pull Request #13755 · dotnet/arcade · GitHub
The only problem left in the arcade repo is the libunwind version being hardcoded to llvm12 while llvm16 support is coming. Current .NET builds specifically require llvm12-libunwind, but it does not seem to be compatible with llvm16 packages.
For that, I chose to upstream Haiku patches specifically for libunwind so that in the (hopefully not too far) future .NET can be built with the in-tree libunwind. I really don’t know how long patches to LLVM will take and how to get the reviewers’ attention though…
On the .NET side, the only big PR that I’m watching now is https://github.com/dotnet/runtime/pull/86391. This one is also quite old, though there is not much hope it will be merged before this November as Microsoft is prioritizing finalizing everything before the release of .NET 8.0 LTS.
Don’t know which is the best place to create a reminder but…
Haiku patches for libunwind has landed to LLVM. According to LLVM’s release schedule it would land in LLVM18, which has a stable release around late March - early April 2024.
Around that time, libunwind should be updated (similar to this commit) to the LLVM18 version with Haiku support.
Then we can remove some Haiku-specific patches to dotnet, such as this.
Usually adding a comment in the code is better.
Seems like the nightly builds are rolling out again after nearly two weeks of interruption, and so are the .NET weekly builds.
Microsoft has bumped the runtime version to 9.0, so you will see both 9.0 runtime and SDK, instead of a mix of 8.0 and 9.0 on the haiku-dotnet9 branch like a few weeks ago.
Also, the people at .NET are more active at reviewing the Haiku support PRs when the development cycle has moved to .NET 9. Recently, a pull request for the SDK (Add support for Haiku by trungnt2910 · Pull Request #35231 · dotnet/sdk · GitHub) has been merged. A lot of discussion about some details about adding support for new OSes is also happening here.
Great news that the builders are up and running again, but also that .NET is actively looking into the PR’s, thanks for your work here! 