5 ms·

There are*: https://github.com/dotnet/Silk.NET https://github.com/dotnet/Silk.NET, https://github.com/terrafx https://github.com/terrafx and https://github.com/

There are*: https://github.com/dotnet/Silk.NET https://github.com/dotnet/Silk.NET, https://github.com/terrafx https://github.com/terrafx and https://github.com/microsoft/Win2D https://github.com/microsoft/Win2D Now, I don't know (or care, to be fair) about the internal aspect of the culture on what is in vogue in various MSFT teams, but there is a rich ecosystem of libraries in .NET to massively simplify interaction with pretty much anything that can be called from C or C++ on Windows. * Not sure about Windows 11 shell integration, but I'm generally unhappy with the way W11 is - what kept me on Windows were games and certain Visual Studio extensions, and with both issues being almost completely addressed on Linux (and on macOS too, surprisingly, with the latest GPTK2), it is time to move.

pjmlp 2y ago
They aren't from WinDev, rather those valiant engineer efforts. There are many Windows APIs that cannot be cannot directly, because they expect C or C++ semantics, hence why there are enough wrapper libraries that still reach out to C++/CLI to ease the task. Additionally anything that requires in-proc COM, or apartment threading models not supported on .NET, can only be implemented in C and C++. Eventually Rust. Usually the work around is to implement the binding glue in C++ and then RPC into a .NET process, if one is really keen in using .NET for such use cases. That is something that isn't covered by Native AOT, and was supported by .NET Native in WinRT, mostly because deep down .NET on WinRT is like VB 6 with COM, and not regular .NET.
- neonsunset 2y ago
  I don't think there is anything left that is actively maintained and production-grade (e.g. above packages) that uses C++/CLI. It is important to acknowledge that it did and still does exist, but I'm unaware of anyone seriously using it over regular C# + P/Invoke (generated or otherwise). .NET has COM interop (from its inception?). In .NET 6, a newer ComWrappers API was introduced, which then also gained the capability to be source-generated to work with AOT in .NET 8. Links: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/com-wrappers https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation https://learn.microsoft.com/en-us/dotnet/standard/native-int...
  - pjmlp 2y ago
    You are not seeing inside every company in the world that is doing Windows development. The COM interop in .NET is mostly for consumption, not implementation, other than other userspace applications, Office automation style. For the Windows extension points that use COM, writing those implementations in COM is not an option, when they are, again, in-proc COM, and use apartment models not covered by interop. I use .NET since the prerelease days, when it was only available to MSDN partners with draft documentation written in red, and Windows itself since 3.0, you won't tell me nothing on Windows system programming that I haven't seen before.
    - neonsunset 2y ago
      It can go both ways, there are engineers who use their prior knowledge to understand where the design principles come from yet acknowledge the current state of affairs and there are engineers which use it as an excuse to ignore anything that happened past their active learning phase. I worked with sufficient amount of the latter type to remind myself everyday to be wary of this failure mode, and to appreciate the former when such people do come by.
      - pjmlp 2y ago
        I agree, but hardly any of your replies were into the sense of what WinDev is doing to support .NET on Windows like Swift are Java/Kotlin are on their respective platforms, instead of their usual COM and C++ agenda, rather what DevDiv, rogue engineers we should be thankful for their sice project efforts, and FOSS .NET community. Yes the community is doing lots, WinDev is not.
        neonsunset 2y ago
        My goal was to provide context on what is out there in terms of consumption of Windows APIs (many people are hand-rolling bindings, where they could have added CsWin32/Rt and two lines to an imports file, or write a complex C++ sandwich for DX12 where they could have consumed it, effectively, directly) and to that extent it is achieved :) We don't know what is current WinDev situation, FWIW COM interop changes in .NET are "official" rather than grassroots, but then again, MSFT is pretty much a huge conglomerate of smaller sized companies rather than a huge monolithic entity.

pjmlp 2y ago

They aren't from WinDev, rather those valiant engineer efforts. There are many Windows APIs that cannot be cannot directly, because they expect C or C++ semantics, hence why there are enough wrapper libraries that still reach out to C++/CLI to ease the task. Additionally anything that requires in-proc COM, or apartment threading models not supported on .NET, can only be implemented in C and C++. Eventually Rust. Usually the work around is to implement the binding glue in C++ and then RPC into a .NET process, if one is really keen in using .NET for such use cases. That is something that isn't covered by Native AOT, and was supported by .NET Native in WinRT, mostly because deep down .NET on WinRT is like VB 6 with COM, and not regular .NET.

neonsunset 2y ago
I don't think there is anything left that is actively maintained and production-grade (e.g. above packages) that uses C++/CLI. It is important to acknowledge that it did and still does exist, but I'm unaware of anyone seriously using it over regular C# + P/Invoke (generated or otherwise). .NET has COM interop (from its inception?). In .NET 6, a newer ComWrappers API was introduced, which then also gained the capability to be source-generated to work with AOT in .NET 8. Links: https://learn.microsoft.com/en-us/dotnet/standard/native-interop/cominterop https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/com-wrappers https://learn.microsoft.com/en-us/dotnet/standard/native-int... https://learn.microsoft.com/en-us/dotnet/standard/native-interop/comwrappers-source-generation https://learn.microsoft.com/en-us/dotnet/standard/native-int...
- pjmlp 2y ago
  You are not seeing inside every company in the world that is doing Windows development. The COM interop in .NET is mostly for consumption, not implementation, other than other userspace applications, Office automation style. For the Windows extension points that use COM, writing those implementations in COM is not an option, when they are, again, in-proc COM, and use apartment models not covered by interop. I use .NET since the prerelease days, when it was only available to MSDN partners with draft documentation written in red, and Windows itself since 3.0, you won't tell me nothing on Windows system programming that I haven't seen before.
  - neonsunset 2y ago
    It can go both ways, there are engineers who use their prior knowledge to understand where the design principles come from yet acknowledge the current state of affairs and there are engineers which use it as an excuse to ignore anything that happened past their active learning phase. I worked with sufficient amount of the latter type to remind myself everyday to be wary of this failure mode, and to appreciate the former when such people do come by.
    - pjmlp 2y ago
      I agree, but hardly any of your replies were into the sense of what WinDev is doing to support .NET on Windows like Swift are Java/Kotlin are on their respective platforms, instead of their usual COM and C++ agenda, rather what DevDiv, rogue engineers we should be thankful for their sice project efforts, and FOSS .NET community. Yes the community is doing lots, WinDev is not.
      - neonsunset 2y ago
        My goal was to provide context on what is out there in terms of consumption of Windows APIs (many people are hand-rolling bindings, where they could have added CsWin32/Rt and two lines to an imports file, or write a complex C++ sandwich for DX12 where they could have consumed it, effectively, directly) and to that extent it is achieved :) We don't know what is current WinDev situation, FWIW COM interop changes in .NET are "official" rather than grassroots, but then again, MSFT is pretty much a huge conglomerate of smaller sized companies rather than a huge monolithic entity.