Can we migrate unmanaged libraries (System.Native.*) to C#

[deeprobin]

Hello everyone,

There are still a few native libraries under src/native/libs.

Is there anything against rewriting them in C#?
If not, is there a plan or concrete issues here?

Nowadays we have Spans & co. and I could imagine that you could get a comparable or even better performance out of many things.

I haven't had a closer look now, but I could imagine some things being feasible, something like System.Globalization.Native perhaps?
Instead of building a own (wrapper-)library here, we could possibly reference the libraries we still depend on directly via LibraryImport. I assume this concerns something like libicu.

Also I think System.IO.Compression.Native could be done in managed code instead of writing a wrapper around of zlib.

The System.Net.Security.Native things would probably have to be approached more carefully, but that also seems to me to be within the realms of possibility.

---

Are there any reasons why this is all unmanaged code?

[bartonjs]

Is there anything against rewriting them in C#?

• Every time that information is copied from a .h file (or whatever) into a .cs file there's room for error, and there's maintenance burden to ensure that it's correct.
• Transitioning from managed into native isn't free. An operation involving a loop in managed code that calls a native function within the body pays that overhead cost for every loop iteration. If the loop is in the native code, it's only paid once.
• function-like macros are really hard to transliterate. The macro can be expanded, but that goes back to the maintenance burden.

In Android Crypto interop there are functions that we've written in Java rather than C using JNI to call into system libraries. The Java code more closely matches what any other caller code is going to look like.

In Apple Crypto interop there are functions written in Swift. We had a big long discussion as to why we don't want to rewrite those into C# (which involved points from above).

A lot of things boil down to "C# is the best language[citation needed], but it's not always the best language for every problem"... especially when interoperating with a library built around the concepts/conventions of some other language.

[huoyaoyuan]

No. See https://github.com/dotnet/runtime/blob/main/docs/coding-guidelines/interop-guidelines.md#unix-shims . In short, we have to rely on the platform C compilers to create a stable ABI for P/Invoke.

[huoyaoyuan]

For Compression while it isn't against the rule, it increases maintenance cost drastically without providing any meaningful benefit. The performance impact of P/Invoke is minimal when the data is operated in large blocks. At https://github.com/dotnet/runtimelab/tree/feature/ManagedZLib there is an intern project for managed zlib, but it require well maintenance to achieve the quality, performance and correctness.