mach.net

[mateli]

Dotnet bindings for mach/libmach with

• Create bindings for libmach. Long term it may be useful to use something different than a C api for this but as there is a C under development it is useful to have at least that supported
• Support dotnet 8, AOT compilation and the Remote Objects C# compiler. That means some restrictions such as not using any reflection (as bytecode may be unavailable at runtime)
• Remote Objects can produce WASM binaries so being able to run mach.net application/game in a browser is a very useful feature
• Make sure all mach.net libraries are compatible with AOT/Native compilation. Pure C bindings should of course be compatible by default but abstract wrappers may need more effort
• Work on a multi-platform AOT-compatible Windows.Forms replacement (Mach.Forms) that has a graphical form editor.

[emidoots]

Is this something you'd like to work on?

My intention is for Mach to only expose a C API (libmach, as you found) and bindings for a single other language that I feel comfortable maintaining (Go), and then letting the community maintain bindings for other languages such as DotNet

[mateli]

Yes. It is highly dependent on the C api however what is a good C api for C applications is not always a good API for high level applications. Call to API:s usually cost more in high level languages but is not "free" in C either. My suggestion is to think about how to avoid making C API calls and use other forms of communication such as "lock-free" lists in shared memory with the application and the api having two different threads. With this the application can lay out all the data needed to render a scene and then the api is informed that the data is ready and renders the scene. This can be significantly faster than having lots of calls building up the scene internally inside the API/engine. It can be useful to think of it as a client-server protocol where the application is the client and where modifying shared data is way faster than making a function call as different form of communication.

All of this mostly benefits clients written in languages like C and C# that has easy to use ways to work with structured data in memories.

As far as creating bindings go there are tools that does this with header files and I intend to explore that. Such tools exist for many languages and well written header files usually work in all, however it depends on not mixing headers that define the API with actual code that makes them hard to interpret. So generating bindings for C# is a very similar problem to generating bindings for Java, Python etc.