windows::Win32::Foundation::HWND and windows::Win32::Foundation::RECT) when passing values through WebView2 APIs/callbacks. I have to unwrap and rewrap a few types (e.g. 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. 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 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. We had the pleasure of working with on integrating windows-rs over at the Tauri ecosystem.Ĭoincidentally, I'm testing an update which will bump Tauri to windows-rs v0.25.0 and webview2-com to a version which matches.

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. 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. 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).

At the moment it's hardly maintained and windows-rs seems to be the way forward.Īdditionally 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. 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. Though this also includes things like libloading, notify, ntapi, parking_lot, rand, ring, time, tokio, walkdir and lots more.

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.įor 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.

Windows api enumprintersw