windows

windows is the flagship crate of the windows-rs project, Microsoft’s officially maintained Rust interface to the Windows operating system. Rather than hand-writing FFI declarations, the crate is generated directly from Windows metadata, giving Rust developers typed, idiomatic access to Win32 functions, COM interfaces, and WinRT classes behind thousands of granular Cargo feature flags scoped to individual API namespaces (Foundation, Storage, Media, Data_Xml_Dom, and so on).

Beyond raw bindings, the crate builds on a set of focused companion crates published from the same monorepo — windows-core for COM/WinRT plumbing and authoring macros, windows-result for structured error propagation, windows-strings for Windows string interop, and more — so consumers only pull in what a given integration actually needs. The result is a crate that lets Rust programs call into Direct2D, WebView2, the Windows Registry, COM automation, or raw kernel32/user32 APIs with the same safety guarantees Rust developers expect elsewhere in their codebase, unsafe blocks reserved for the genuinely unsafe FFI boundary rather than the whole API surface.

What You Get

• Typed bindings for the full Win32, COM, and WinRT API surface, organized behind granular feature flags per API namespace so binaries only compile in what they call
• Companion crates (windows-core, windows-result, windows-strings, windows-registry, windows-services, windows-webview, windows-window) usable standalone for narrower integrations
• COM and WinRT authoring support via #[implement] and #[interface] macros for writing Rust types that Windows itself can call back into
• A code generator (windows-bindgen) that can emit a minimal, project-specific binding when the pre-built windows crate’s feature set doesn’t cover a needed API
• no_std support and a raw windows-sys crate for embedded or minimal-runtime scenarios that can’t pull in the full windows crate

Common Use Cases

• Calling native Win32 APIs (file handles, events, message boxes, window messages) from a Rust application without writing manual extern “system” FFI declarations
• Automating or hosting COM components — Windows Shell extensions, Office automation, or other COM-based system integrations — from safe Rust code
• Building native Windows UI or graphics with WinRT-backed crates like windows-webview (WebView2), windows-canvas (Direct2D), or windows-reactor (WinUI 3)
• Reading and writing the Windows Registry or authoring a Windows service using the dedicated windows-registry and windows-services crates
• Generating a narrow, project-specific set of Windows API bindings with windows-bindgen when the full windows crate’s feature surface is more than a project needs

Under The Hood

Architecture The repository is a large Cargo workspace under crates/, split into libs/ (the ~25 publishable crates, including windows, windows-core, and the focused per-domain crates like windows-registry and windows-webview), tools/ (the bindgen and metadata pipeline), samples/, and tests/ (a dedicated test crate per library, e.g. crates/tests/libs/windows, crates/tests/libs/core). The windows crate itself (crates/libs/windows) is a thin façade: its Cargo.toml declares dependencies on windows-collections, windows-core, windows-future, windows-numerics, windows-reference, and windows-time, and its thousands of Cargo features (one per Windows API namespace such as ApplicationModel_Background or Data_Xml_Dom) are mechanically generated rather than hand-maintained, letting consumers compile in only the slice of the Windows API surface they call. windows-core (crates/libs/core/src) supplies the COM/WinRT plumbing underneath — interface vtables, agile references, weak references, #[implement]/#[interface] authoring macros — that both the windows crate and the standalone companion crates build on, so changing that core would ripple through every downstream crate in the workspace.

Tech Stack Pure Rust, 2024 edition, with an explicit MSRV pinned in each crate’s Cargo.toml (rust-version = “1.95”) and dedicated msrv.yml/msrv-windows.yml CI workflows enforcing it. The core crates support no_std (#![cfg_attr(all(not(feature = "std")), no_std)] in windows-core), with a separate no_std CI workflow and a no-default-features workflow verifying minimal builds compile. Procedural macros (windows-implement, windows-interface) are implemented with syn/quote/proc-macro2, kept as thin wrapper crates so consumers depend on the stable windows-core re-exports rather than the macro-implementation crates directly. The binding generator (windows-bindgen) reads Windows metadata (ECMA-335-based, via windows-metadata) to mechanically produce the API surface rather than any of it being hand-written.

Code Quality Every publishable library has its own dedicated integration-test crate under crates/tests/libs/ (over 30 of them — windows, core, registry, webview, services, reactor, and so on), plus separate misc and bench test trees. CI is unusually extensive for an open-source Rust project: separate GitHub Actions workflows for test, clippy, fmt, msrv, msrv-windows, no_std, no-default-features, cross, and miri (undefined-behavior detection for the unsafe FFI layer), plus workspace-level Clippy lint configuration in the root Cargo.toml that promotes lints like redundant_clone, manual_let_else, and uninlined_format_args to warnings. Given how much of this crate’s surface is unsafe FFI by necessity, the miri and unexpected_cfgs/missing_unsafe_on_extern lint configuration is a deliberate, non-default investment in catching soundness issues early.

What Makes It Unique Unlike community-maintained Windows FFI crates that hand-write bindings for whatever subset of the API surface contributors need, windows-rs is generated end-to-end from the same Windows metadata that Microsoft’s own WinRT and COM tooling consumes, giving it comprehensive and mechanically-verified coverage of Win32, COM, and WinRT rather than partial, drifting coverage. It also uniquely spans both directions of the FFI boundary: the #[implement] and #[interface] macros let Rust code author COM/WinRT objects that Windows itself calls back into (not just call outward into Windows), which is what makes the higher-level companion crates like windows-webview and windows-reactor possible as safe wrappers over otherwise callback-heavy native APIs.