[pjmlp]

On the contrary, C++/CX was (still is) a great development experience, for the very first time, Microsoft hat something that could rival C++ Builder.

Instead an small group rioted, came up with C++/WinRT with support from management and complete disrespect for paying customers.

Now a decade later, C++/WinRT in in maintenance, the roadmap vision shown at CppCon 2017 unfulfilled, and the same team is now having fun with Rust in windows-rs.

> This isn't meant as a negative statement. cppwinrt has reached all of its goals and is generally considered complete and largely bug-free (1). Whether WinRT/WinUI/WinAppSDK is the future is debatable. My experience has shown me that the Windows operating system is at its best when you embrace the Windows API as a whole, including Win32/COM/WinRT, and not just the latest shiny wave. You can see this in action with the popularity of projects like win32metadata and windows-rs that support both WinRT and non-WinRT APIs seamlessly.

Quote from the devs on Github.

Thanks for nothing, I guess.

[EFLKumo]

Making a XAML UI is fundamentally authoring a WinRT interface, I guess. And for cppwinrt, Microsoft's solution is like describing in so-called MIDL .idl files, compiler generating cpp stubs, copying these stubs and filling in implementations. After static reflection introduced in cpp idk if this process could become better, but Microsoft just left cppwinrt in maintenance mode, it's impossible I guess.

On the Rust side, IMO the windows-rs even has not thought about authoring new com interfaces, only consuming or impl-ing existing ones. In fact the experience of consuming windows apis in rust feels good if one would like to get rid of C++. Rust with NAPI or BoltFFI etc. offers an maintaining-friendly option for cross-platform app authors to interact with the OS more deeply. So in conclusion the situation right now is that windows apis just become not so unapproachable, while in-depth things keeping comfortable only with C# or .NET.