Rust for Windows – August 2025 #3746
Description
Welcome to the (belated) August issue of the Rust for Windows newsletter! This newsletter covers news and events related to Rust for Windows, and particularly the windows-rs project.
Quick links
- Repo: https://github.com/microsoft/windows-rs
- Getting started: https://kennykerr.ca/rust-getting-started/
- Samples: https://github.com/microsoft/windows-rs/tree/master/crates/samples
- Releases: https://github.com/microsoft/windows-rs/releases
- Feature search: https://microsoft.github.io/windows-rs/features/
Release
The big news is release 69 that is focused on upgrading the ecosystem to standardize on the windows-link crate for universal raw-dylib support on Windows. This avoids all kinds of build headaches and undesirable complexity in dealing with the linker directly via import libs.
To date, the only major Windows crate that still uses the older windows-targets crate for linking is the windows-sys crate. This release updates windows-sys to depend on windows-link and thus raw-dylib unconditionally. This is required for some internal OS and Azure scenarios, but also greatly improves the developer experience for Rust on Windows in general. With over a million daily downloads, the windows-sys crate plays a big part in moving the Rust ecosystem forward on Windows. It should also meaningfully reduce build time in general since the large windows-targets import lib crates no longer need to be downloaded at all.
I am also using this release as an opportunity to update all of the remaining crates to use the latest version of windows-link which itself receives a major update to finally stop overwriting the ABI (#3689), fixing a long-standing cross-target compatibility issue.
With this update, Rust for Windows no longer offers any crates that depend on the windows-targets crate. Although very stable, it will remain supported by this repo for the foreseeable future should there ever be a reason to service it. I do not however plan to provide any non-essential updates to the windows-targets crate. You should instead use the windows-link crate.
Learning series
Part 3 of the Rust for Windows video series is now available on YouTube. This is a series for Windows developers wanting to learn how to make the most of Rust on the Windows platform.
- Part 1 - https://youtu.be/MfwtC55eNzU
- Part 2 - https://youtu.be/OTgIthYqWcY
- Part 3 - https://youtu.be/odSTccFy6ZA
Part 3 introduces some more of the individual crates published as part of Rust for Windows. As requested, part 4 will cover the windows-strings crate and various string-related topics.
Notable updates
The windows-bindgen crate (0.63.0) includes updated Windows metadata (#3729) and targets the latest version of the core Windows crates. Metadata and bindings now include Windows 10.0.26100.4948. It also includes a variety of conformance and future-proofing work to ensure the best quality code gen in anticipation of future Rust updates.
The windows-link crate (0.2.0) no longer overwrites the ABI (#3689) avoiding cross-arch incompatibility but is unfortunately a subtle breaking change. If you are directly targeting windows-targets or windows-link then you should update to windows-link version 0.2.0 as your schedule allows. Fortunately, the windows-link crate is tiny (6kb) in comparison to windows-targets (6,683kb) thanks to the elimination of import libs so multiple versions of windows-link, though rare, should not be such a big problem.
The windows-sys crate (0.61.0) is updated to target the latest windows-link crate and thus raw-dylib (#3724).
The windows-core crate (0.62.0) provides a number of improvements for compatibility and target support.
The windows crate (0.62.0) is updated to target the latest windows-core crate and provides an API refresh for Windows metadata (#3729).
The windows-future crate (0.3.0) is updated to target the latest windows-core crate and provides new join and when functions for simplifying async continuation (#3708).
The windows-threading crate (0.2.0) is updated to target the latest windows-link crate and sports a new pool scope for improved lifetime management (#3696).
What's next
Work continues to improve the experience of Rust developers on Windows and more generally enabling and supporting a broad range of programming languages and frameworks by building the tools and services to enable cross-platform toolchains and frameworks to excel on Windows.
This includes a renewed focus on metadata for the canonical description of APIs and components, whether they ship inside the OS or in some other way. Metadata is the key to scaling up the generation of bindings for various languages including Rust. We must make it easier for app developers as well as language, library, and framework maintainers to approach Windows APIs so they can take advantage of what is distinctive and unique about Windows and light up those features as they are available.
Work has begun, particularly with the first complete ECMA-335 reader and writer for Rust. This gives us the ability to both read and write what are commonly referred to as .winmd files, popularized by .NET and WinRT, for describing APIs and components and has been extended to describe traditional Win32 and COM APIs as well.
The next steps include C/C++ header and IDL parsers that can generate high quality metadata so that we can more easily generate bindings for existing APIs that predate metadata. I am bringing up both an IDL and a RDL parser in tandem. The latter is an IDL dialect but based on Rust syntax and natively embeddable so that we can more easily support first-class component and API authoring in Rust without resorting to what is otherwise the very proprietary syntax that is IDL. The C/C++ header and IDL parsers will likely be somewhat tactical as those dialects are extremely complicated and extremely elusive respectively. The goal is to help developers bring older APIs and definitions forward to a supportable and open-source foundation.
With comprehensive metadata and API or ABI tooling easily accessible to Windows developers, the next step is to make Windows more accessible to non-Windows platforms by providing cross-platform fallback implementations of the various core windows-rs type system and support crates. This should allow developers to use the same languages and tools to build components and applications that necessarily communicate and interop across operating system boundaries. The windows-rs technology already supports this to some degree by allowing DirectWrite and DWriteCore, implemented with windows-rs, to support both Windows and non-Windows platforms. This is today limited to a thin slice of COM support but I hope to extend this to more of the foundational type system so that richer APIs can seamlessly work across different target platforms.
Wrapping up
And that's all for this update. Let me know what you think. What would you like to see more of? Are you interested in specific learning series topics? Are you using windows-rs today? Let me know so we can continue to prioritize investment in these tools and services.