Are you using the Windows crate?

[kennykerr]

Hi folks, we're trying to gauge adoption and understand how we can best serve the Rust community with the Windows crate. In order to do this, I would love to hear from you! How has the Windows crate influenced your decision making? Did it help you decide to use Rust or target Windows? Is Rust replacing another language for a product you've previously shipped?

Feel free to leave a response here or email me directly to keep things private: kenny.kerr@microsoft.com

If the Windows crate matters to you, don't miss this opportunity to let me know and help influence the future of Rust on Windows.

[Berrysoft]

Two problems I've found:

• ARM64 support: the linker will complain that windows.lib could not be found. According to Are you planning to support ARM64 architecture ?  #1175 (comment) it is being fixed.
• Lacking functionality of specifying exactly some APIs. I could specify the exact class and method I want, but now I need to enable the whole namespace, which may import many unwanted dlls, though they could be linked out with LTO.

I'm also looking forward to the ability of authoring XAML UWP or WinUI3 applications. Is there any plan of providing an XAML compiler?

[samlh]

I currently only use Rust for personal projects - that being said, windows-rs has made me comfortable trying out the Win32 API in earnest for the first time. At this point, I'm very happy with the developer experience using window-rs with prebuilt bindings.

My next project is to find a usable native-feeling UI framework I can use from Rust - if I'm able to get WinUI 3 to work, I expect I'll be implementing all of my projects for the foreseeable future in Rust. Note that I don't feel blocked on a XAML compiler - I'm hoping to build the UI using api calls.

[kennykerr]

@Berrysoft thanks for the feedback, but please create new issues to report any problems you may have. Here I'm really just trying to collect feedback on who is using the Windows crate and how it is helping you build software for Windows. (ARM64 support shipped in 0.25 for MSVC and namespace refactoring is an ongoing process here.)

[Jasper-Bekkers]

Hi Kenny,

Ever since #432 got resolved, we've started the process on our side of switching over to windows-rs since for us this seems to be the way forward.

For we're mostly waiting on the rest of the ecosystem to slowly catch up, I think other then our own code winit is probably the biggest dependency we have on the old winapi crate. Though this also includes things like libloading, notify, ntapi, parking_lot, rand, ring, time, tokio, walkdir and lots more.

One thing that could be helpful also to speed up ecosystem adoption would be to publish a rustsec advisory stating that winapi is/will be deprecated. At the moment it's hardly maintained and windows-rs seems to be the way forward.

Additionally it could be extremely helpful if Microsoft would help evangelize the windows-rs adoption throughout the ecosystem, either by doing some of the heavily lifting itself on some of the very foundational crates, or by filing issues on larger repo's and making project maintainers aware and potentially advising on the switch.

We're eagerly awaiting the namespace changes to come through since right now we're having a bit of trouble keeping our feature set lean (for example we need to enable Win32_Graphics_Direct3D11 even though we're exclusively using Dx12).

One thing I'm worried about going forward is build times; right now only leaf nodes in our dependency tree are depending on windows-rs, which means that the parallel builds can hide quite a big chunk of the windows-rs build times on our heavy threadrippers. However, on smaller machines, or if window-rs gets pushed closer to the root of the dependency tree, I'm worried this may become a problem again.

• Jasper

[mwgabby-li]

How has the Windows crate influenced your decision making?

Official support from Microsoft on their platform has given me a lot more confidence in being able to create a robust Rust application on Windows. I am much more likely to use this crate for Windows interfacing thanks to the official support from Windows.

Did it help you decide to use Rust or target Windows?

No, because I was already planning to use Rust.

Is Rust replacing another language for a product you've previously shipped?

No. But it seems likely to start replacing languages like C and C++ in future projects.

[Alovchin91]

Hi Kenny,

First of all, thank you for all the hard work you're doing! 🌷

Right now, there are basically two things that I'm waiting on to start adopting windows-rs:

• Authoring support. Our codebase is mainly C# and I would like to start introducing Rust, but for that I need an ability to author a Windows Runtime component so that it could easily be wired up with C# code.

• WinUI 3 and XAML compiler support. If speaking of new projects, I would like to avoid writing UI in one language and BL in another. XAML compilation is a big deal for me here. That's what would help me to switch to Rust as my primary language.

I also hope that the future of Rust on Windows is not under question, given the record of Microsoft not allocating enough resources to a project and then killing it over the lack of adoption... 😬

[joshtriplett]

I'm really enthusiastic about the windows crate. I'm looking forward to being able to use it with raw-dylib, which will allow linking Windows applications without needing all the libraries around.

I would love to find the right combination of "make Rust compile faster" and "ship pre-compiled indexes of interfaces" and "make the compiler smarter about compiling only the used subset of a crate" to allow people to just use windows without having to set feature flags for the APIs they want to use.

[LGUG2Z]

I was a pretty early adopter of this crate, I've been using it in my tiling window manager since 0.3.

Before starting this project, I had zero familiarity with the Windows development ecosystem (and honestly, outside of this crate, I still don't), and I don't think I would have started this project if this crate was not available because I was not interested in learning C#, C++ or having a workflow centered around Visual Studio.

The only real pain point for me has been keeping up to date with the breaking changes between the updates (quite a few between 0.3 and 0.25 😅). I appreciate the changelog, but more often than not, when updating this crate results in a broken build, I have to diff through the examples and create a mental 'migration guide'.

Something like Rocket's migration guide for breaking changes would be a welcome addition whenever there is a new release with potentially build-breaking changes.

[nothingismagick]

We had the pleasure of working with @wravery on integrating windows-rs over at the Tauri ecosystem.

https://github.com/tauri-apps/tao/blame/next/Cargo.toml#L76

On a sidenote, tao started out as a winit fork, but the next branch is now using windows-rs; not sure if this addresses @Jasper-Bekkers concerns - because we have added general features that the winit maintainers felt were out of scope (like accelerators and menus)...

Definitely agree with @LGUG2Z about more strict change management.

[wravery]

We had the pleasure of working with @wravery on integrating windows-rs over at the Tauri ecosystem.

Coincidentally, I'm testing an update which will bump Tauri to windows-rs v0.25.0 and webview2-com to a version which matches. The latest windows-rs includes pre-compiled library support, which greatly simplifies the dependencies since the consumer can reference types directly in the windows crate instead of needing to build them all into an intermediate bindings crate. The webview2-com crate doesn't need to include everything its consumers might reference, and the Tao crate itself doesn't need to depend on webview2-com anymore since it can get those types directly from windows.

The only downside is that the windows::runtime::build macro doesn't yet point types referenced in another winmd file back to the pre-compiled libraries. I have to unwrap and rewrap a few types (e.g. windows::Win32::Foundation::HWND and windows::Win32::Foundation::RECT) when passing values through WebView2 APIs/callbacks. For Tauri, I also had to cast (i.e. QueryInterface) between a webview2_com::Win32::System::Com::IStream and windows::Win32::System::Com::IStream, as well as aliasing the types to disambiguate them.