Re:.NET Myths Dispelled
by immutology on Saturday March 12, 2022 @06:32PM
(#30656120)
Native interop in .NET has always been via what they call "P/Invoke". On .NET Core, P/Invoke is cross-platform and you can also call .so/.dylib functions on Linux/MacOS just like you could always call .dll functions on Windows on .NET Framework before we had .NET Core.
I'm curious to know what you needed to do with native libraries. I've been programming with .NET around 20 yrs and find it fairly rare that I need to use P/Invoke... But I'm sure it depends on what you're building.
Re:.NET Myths Dispelled
by withinboredom on Saturday March 12, 2022 @06:52PM
(#30656305)
I maintain a thingy written in C# that does cool things with keyboard backlights on System76 machines in Linux. Like make the left-third respond to CPU usage, right third blink when you have unread notifications, etc. The biggest one was turning off the keyboard when the screen blanked[1]. Almost all of the fun stuff requires native interop.
1: https://withinboredom.info/blog/2019/11/26/detecting-if-a-sc...
You end up using P/Invoke any time you need to control hardware. In the last few months I needed to use P/Invoke to control cameras, motors, and compute FFTs with the GPU.
You need to use them if you need to control raw GDI objects like bitmaps.
Hmm, I've been using .NET since beta 1 in 2000. Maybe you had access to earlier bits? It was never just about webapps. In fact, Windows Forms was meant as a more sane MFC if anything.
Interop with native code was always very easy. From PInvoke to managed C++ there were a lot of ways to do it with ease. Things have changed but I still think this is one area where .NET has great support.
The first iterations of .NET were just for webapps. You could only work with and call .NET code, the only functions provided were basic IO and network.