You might want to look at how ptrace and process_vm_readv checks on Linux then. Apart from the euid check, depending on the system setting, these two syscall additionally requires the caller process to be an ancestor of the target.
If you don’t like this centralized vm_remap-style API, then might it be better if I implemented process_vm_readv, FreeBSD mremap and a custom commit_memory instead?
For the debugger, applications should be able to protect themselves, for example by using disable_debugger/enable_debugger (I don’t know if that already works, but it sounds like these should protect from attaching a debugger).
So, the fact that a security problem exists with this is not a reason to open an even wider security problem.
Applications should be not able to protect themself against system administrator.
Maybe do what Linux does then? Either the caller must be root or an ancestor of the target, if you think the euid check is inadequate.
I remember plenty of tricks in Windows applications, to prevent debugging with SoftICE.
Had a go at porting just that today, however, there is some bug with GitHub - realm/realm-core: Core database component for the Realm Mobile Database SDKs, so I gave up.
I might pick this up again one day if the HaikuPorts folks ported this thing to Haiku (compilation is trivial, but there are some tricky bugs somewhere).
FNA is working:
Using a sample here: FNA.Examples/DrawACube at main · danielcrenna/FNA.Examples · GitHub
There are some native components, but these can build on Haiku without any patches; the only thing needed is for someone to write up a recipe for those and all FNA games can run unmodified.
I think it has some potential legitimate usages (e.g. implementing drivers in userland), but probably not broad usage, no.
Actually there are some parts of the kernel that might benefit from this (IO routines handling userspace buffers which presently use either lock_memory or clone_area for example.)
If we both agree that it might be useful, then this patch should be eventually merged, shouldn’t it (not trying to rush the review process or anything, just trying to say that it should not be completely rejected)?
On the CoreCLR side, in the end it’s the people at dotnet who ultimately decides whether some code/an approach is acceptable or not.
Well that was quick! Fantastic work!
using Haiku.App;
using Haiku.Interface;
public class Test : BApplication
{
private BWindow _window;
public Test() : base("application/x-vnd.Test")
{
_window = new BWindow(new BRect(100, 100, 300, 300), "Test", WindowType.B_TITLED_WINDOW, 0, 0);
_window.Show();
}
public static void Main()
{
var application = new Test();
application.Run();
}
}
What do you think of this kind of programming?
This is the current state of Haiku C# API bindings, generated using CppSharp by Mono.
There are a few issues related to the native portion of the bindings (a special shared library that is created in order to keep inlined functions alive), so the thing isn’t working correctly at runtime yet.
Got this tiny test window
Looking good
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.