winapi-rs

winapi (winapi-rs) provides raw FFI bindings to all of the Windows API for Rust. Hand-gathered from the Windows 10 SDK, it exposes the Win32, COM, DirectX, and kernel interfaces as Rust extern declarations, types, constants, and structs so Rust programs can call directly into Windows system libraries.

The crate is organized so that each Windows module (for example winuser, winnt, or wincon) sits behind its own Cargo feature flag, keeping compile times manageable by pulling in only the definitions you need. It supports no_std by default, works across the msvc and gnu toolchains for 32- and 64-bit targets, and for years was the de-facto foundation that most Windows-facing Rust crates built upon.

What You Get

• Raw FFI bindings to the Win32, COM, DirectX, and kernel Windows APIs
• Feature-gated modules so you compile only the definitions you use
• no_std support by default, allowing Windows apps with only core and winapi
• Cross-toolchain coverage (msvc and gnu) for i686 and x86_64 targets
• Consolidated definitions that replace the legacy 0.2-era -sys crates

Common Use Cases

• Calling Win32 system functions directly from Rust for OS-level features
• Building the FFI foundation for higher-level, safe Windows wrapper crates
• Interacting with COM and DirectX interfaces from Rust applications
• Writing no_std Windows tools that avoid the standard library

Under The Hood

Architecture - winapi mirrors the Windows SDK header layout rather than imposing its own. The src directory is split into the classic Windows namespaces (shared, um for user-mode, km for kernel-mode, vc, and winrt), each containing one Rust module per Windows header such as winuser, winnt, and wincon. Every module is gated behind a Cargo feature of the same name, and a build.rs plus toolchain-specific i686 and x86_64 helper crates handle the import-library plumbing for the gnu targets. The bindings are declared under cfg(windows) so the crate is an empty no-op elsewhere.

Tech Stack - Pure Rust FFI (advertised as 100% unsafe) with no runtime dependencies, categorized as external-ffi-bindings, no-std, and os::windows-apis. It defines its own c_void so it can stay std-free by default, re-exporting the std type only when the std feature is enabled. Build metadata targets the msvc and gnu toolchains across i686, x86_64, and aarch64.

Code Quality - The bindings are hand-gathered from the Windows 10 SDK, so correctness rests on manual transcription against MSDN rather than automated tests; a tests directory exists but coverage is inherently limited for pure declarations. The project is stable but in low-activity maintenance (latest release 0.3.9 in 2020), and Microsoft’s official windows crate is the actively developed successor.

API Design - There is deliberately no ergonomic layer: items map one-to-one to their C counterparts, so usage means unsafe calls, manual union handling via mem::zeroed(), and cross-referencing MSDN for semantics. The main friction is discovering which feature flag exposes a given item (the docs.rs search helps), making this a low-level foundation intended to be wrapped rather than used directly.