ComLightInterop VS matrix.to

I have once made something remotely similar, to interop between C++ and C#: https://github.com/Const-me/ComLightInterop

I took different approach. Because I only needed to support these two languages, there’s no separate interface definition language, and no code generator for interfaces. Instead, users are expected to write both language projections manually.

Then there’s a runtime code generator on the .NET side of the interop which builds runtime callable proxy types for interfaces implemented in C++, also virtual tables for C# objects consumed by C++.

It’s pretty fast. Likely reason for that, MS designed both language and runtime this way since version 1.0. They needed that for their Windows Forms which consumes huge chunk of WinAPI.

I benchmarked a while ago when testing this library https://github.com/Const-me/ComLightInterop#performance On the computer I was using at that time (probably Ryzen 5 3600 CPU) the overhead was 15-20 nanoseconds per call.

That thing is COM, which is a small subset of C++ ABI. Technically it’s about the same as on Windows, i.e. C ABI with extra first argument for this pointer.

Once upon a time I made this library https://github.com/const-me/comlightInterop/ The native side of the interop is idiomatic C++, here’s an example https://github.com/Const-me/ComLightInterop/blob/master/Demo... The C# side of the interop is implemented through the built-in C interop, here’s the relevant part of the library https://github.com/Const-me/ComLightInterop/blob/master/ComL... I’ve tested Linux version of that library on AMD64, ARMv7, and ARM64 CPUs, but only with gcc compiler on the native side.

I like many parts of COM, but I believe that example mostly demonstrates bad parts, with IDL, registrations, and over-engineered support libraries.

There's nothing wrong with exporting factory functions from DLLs. Microsoft does it all the time, APIs like Direct3D, DirectDraw and Media Foundation don't come with type libraries are they aren't registered anywhere.

Speaking about support libraries, I once made my own: https://github.com/Const-me/ComLightInterop/tree/master/ComL... Compare examples from that article with this one: https://github.com/Const-me/ComLightInterop/blob/master/Demo... That source file is the complete DLL which implements a minimalistic COM object.

> Does it feel "brittle" to use

Yes and no.

No because when you try to do unsupported things like calling a method on an object which doesn’t support one, you gonna get an appropriate runtime exception.

Yes because if you fail lower-level things like local parameter allocation, you gonna get an appropriate runtime exception but that one is (1) too late, I’d prefer such things to be detected when you emit the code, not when trying to use the generated code (2) Lacks the context.

Overall, when I can I’m using that higher-level System.Linq.Expressions for runtime codegen. Things are much nicer at that level. I only using the low-level thing when I need to emit new types, like there: https://github.com/Const-me/ComLightInterop/blob/master/ComL...

> Do you have any good resources on writing dlls to consume via .net like you’re talking about?

For C APIs i.e. functions, structures and strings, the good resource is Microsoft documentation, the support is built-in, see “Consuming Unmanaged DLL Functions” section: https://docs.microsoft.com/en-us/dotnet/framework/interop/

For COM APIs i.e. sharing objects around see this library + demos: https://github.com/Const-me/ComLightInterop It’s only really needed on Linux because the desktop version of the framework has COM support already built-in, but it can be used for cross-platform things just fine, I tested that quite well i.e. not just with these simple demos.

> How do you deal with the managed memory when using the gc from .net

Most of the time, automatically.

When you calling C++ from C#, the runtime automatically pins arguments like strings or arrays. Pinning means until the C++ function returns, .NET GC won’t touch these things. This doesn’t normally make any copies: C++ will receive raw pointers/native references to the .NET objects.

Sometimes you do want to retain C# objects from C++ or vice versa i.e. keep them alive after the function/method returns. An idiomatic solution for these use cases is COM interop. IUnknown interface (a base interface for the rest of COM interfaces) allows to retain/release things across languages.

C++ interop is not supported in modern .NET out of the box, but wasn't too hard to implement as a library: https://github.com/Const-me/ComLightInterop

Happy to see this on HN =). Lunatik’s main author here. AMA.

Please feel welcome to join us on Matrix [1] as well.

[1] https://matrix.to/#/#lunatik:matrix.org

There is this list of 15-minute bugs that should be easy to tackle https://bugs.kde.org/buglist.cgi?bug_severity=critical&bug_s...

Also strarting on smaller KDE applications is usually a great way to start, For example the Plasma widgets/applets or KDE games or educational applications.

You can join the New Contributors char room on Matrix to get help with starting out https://matrix.to/#/#new-contributors:kde.org

There's also https://matrix.to/#/#review-requests:nixos.org

Hi, I'm the Thib person mention in this article, and I agree that QA is super important. I can mostly talk about matrix.org, since I have little power over the Element clients. Disclaimer though: I'm technically employed by Element (to make paperwork simpler since I'm France-based, Element has an entity in France, and the Foundation is UK-based), but I'm working for the Foundation full time.

This kind of article is super valuable since it gives us the perspective of a new user. I opened https://github.com/matrix-org/matrix.org/issues/2178 to translate the gripes mentioned in the issue into actionable items for us. I took action on the most urgent one (updating the Try Matrix page), but want to take the time to go beyond the surface symptoms and address the root cause of the other gripes.

On the Foundation side, we're a small but mighty team of four. The website is currently maintained part time by me and a volunteer who is doing an excellent job at it.

As I wrote recently in a blog post "Tracking what works, not people" (https://ergaster.org/posts/2024/01/24-tracking-what-works/), I would love to have the resources to conduct user research and user testing on the website but I unfortunately don't. We deployed privacy-preserving analytics to see where people drop and what confuses them. It's not nearly as good as proper QA and user testing, but that's what we can afford for now.

Overall I'm grateful to the author for documenting their frustration, and even more grateful for reacting constructively to our responses and integrating them in the blog post! One of the strengths of open source is to find and address issues collectively. I consider this blog post to be a good open source contribution.

If people around believe in our mission and want to help us with their brainpower, I invite them to join our "Office of the Matrix.org Foundation" room: https://matrix.to/#/%23foundation-office:matrix.org

For those aligned with our mission and who want to support us financially, the https://matrix.org/support/ page should give you all the information you need to help us out.

https://matrix.to/#/#openbao-general:chat.lfx.linuxfoundatio...

Hi all,

This project release is a long time coming. It was a big uphill battle, and by far my largest endeavor so far. I built it for Sandstorm because I believe in Sandstorm's model, and I wanted to show that there's still life and potential in it. If you're inspired, joining our OpenCollective would be really helpful: https://opencollective.com/sandstormcommunity (keeping in mind that Sandstorm has now moved from its original leadership to a community project https://sandstorm.org/news/2023-11-03-from-io-to-org).

You can also join our mailing list or connect on the fediverse: https://sandstorm.org/community (The IRC link is outdated, we've effectively moved to Matrix for now due to the libera.chat split: https://matrix.to/#/#sandstorm:libera.chat)

Also: I'm open for hire! You can see some of my skills in putting things together in this blog post. I'd love to work in something FOSS or OSM related, but not a requirement. I mostly do Python and Golang, with a bit of Haskell under my belt. Other projects and resume here: https://github.com/orblivion/me

I really appreciate you sharing your concerns, and for all the hope and energy you've put into Matrix to date. Very much to your point, we're not yet in a state where I recommend Matrix to friends and family. Right now I only use it with people in FOSS and other circles where folks are a little more patient with the tech.

Only time will tell, and of course I'm biased as the Matrix.org Foundation's Managing Director, but I think there's good reason to remain hopeful:

The spec continues to evolve with major improvements expected in feature set and performance in the next year as we get to the 2.0 spec release, the Foundation is staffing up and beginning to fundraise, we're on the cusp of holding our first ever community elections to seat a Governing Board, and adoption has continued doubling on an annual basis.

I invite you and anyone else who is invested and/or concerned to join us in the Foundation's new office room – it's a way to get a view into ongoing activities, ask questions, provide direct feedback, and celebrate all the little wins on our way to collective success: https://matrix.to/#/#foundation-office:matrix.org

Cool! Just in case you haven't come across this, we've got a (rather quiet lately) chat that might be useful.

https://matrix.to/#/#usb-rs:matrix.org