windows-rs

oesn't use them. It makes sense for Rust bindings to define a safe wrapper type with a destructor. But if I were designing the bindings, I would have given the wrapper a different name from the original type to make the difference in semantics more obvious. The Rust BSTR type is still ABI-compatible with the C++ one (because it's repr(transparent)), so it can be valid to use it in FFI definitions, but only if that BSTR happens to be owned (like with the second parameter). A more thorough wrapper for BSTR would provide a safe borrowed type in addition to the owned type, like what &str is to String. But it appears that windows-rs doesn't provide such a type. However, windows-rs does provide an unsafe type which can be used for the purpose. Confusingly, this type is also named BSTR, but it's defined in the windows-sys crate instead of windows-strings. This BSTR is like the C++ BSTR, just an alias for a raw pointer: https://docs.rs/windows-sys/latest/windows_sys/core/type.BST... You should probably use that type for the _ribbon_id parameter. Or you could just manually write out `*const u16`. But not `*const BSTR`, which is a pointer to a pointer. `*const BSTR` happens to be the same size as `BSTR` so it doesn't cause problems for an unused parameter, but it would break if you tried to use it. Which probably doesn't matter to your application. But since you published a "correct signature for future LLMs", you should probably fix it. See also this issue report I found (not exactly on point but related): https://github.com/microsoft/windows-rs/issues/3230

is in maintenance mode[4], and Rust/WinRT never took off, and is now Rust/windows-rs[5]. As paying customer, impacted by those childish attitudes, I would have had the whole team fired. Finally, check the amount of bugs and complaints on their respective repos, https://github.com/microsoft/microsoft-ui-xaml https://github.com/microsoft/WindowsAppSDK https://github.com/microsoft/cppwinrt/ And then compare with Project Reunion vision from 2021, and where we are three years later https://blogs.windows.com/windowsdeveloper/2021/03/29/announ... Mainly because along the way, as if those changes weren't enough, they also decided to reboot their initial approach with Project Reunion, WinAppSDK took another route, and here we are. This is only a short overview of how WinRT went down since Windows 8, thus only those that never advocated for it, can honestly suggest WinUI, as they lack the background of how chaotic it all is. [0] - https://devblogs.microsoft.com/cppblog/announcing-hilo/ [1] - https://learn.microsoft.com/en-us/previous-versions/msdn10/f... [2] - https://arstechnica.com/features/2012/10/windows-8-and-winrt... [3] - https://www.youtube.com/watch?v=7TdpWB_vRZM&t=2983s [4] - https://github.com/microsoft/cppwinrt/issues/1289#issuecomme... [5] - https://github.com/microsoft/windows-rs