Comprehensive Rust FFI bindings to the entire Windows API, enabling native Windows development in Rust.
winapi-rs is a Rust crate that provides raw Foreign Function Interface (FFI) bindings to all Windows APIs, manually gathered from the Windows 10 SDK. It serves as the foundational crate for Windows development in Rust, aiming to unify and replace fragmented Windows FFI implementations across the ecosystem. The crate is minimal and focused, offering direct access to Windows system calls without abstractions.
Rust developers building applications or libraries that require direct, low-level interaction with the Windows API, including those working on system-level tools, embedded projects, or cross-platform software with Windows-specific components.
Developers choose winapi-rs for its complete, hand-curated coverage of the Windows API, feature-gated modules for selective inclusion and reduced compile times, and its role as a unified replacement for legacy -sys crates. It also supports no_std environments by default and acts as a no-op on non-Windows platforms for portability.
Rust bindings to Windows API
Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.
Provides hand-curated bindings for the entire Windows API from the Windows 10 SDK, ensuring no missing system calls for low-level development.
Each API module like winuser is behind a feature flag, allowing selective inclusion to reduce compile times and binary size, as explained in the FAQ.
By default, it works without Rust's standard library, enabling use in embedded or kernel-mode projects, with an optional std feature for integration.
Aims to replace fragmented -sys crates like kernel32-sys with a unified solution, reducing dependency bloat and maintenance overhead.
Acts as a no-op on non-Windows platforms, ensuring code compiles elsewhere without modification, as stated in the README.
The README admits there is no documentation on how to use the bindings, forcing developers to rely on external MSDN resources for guidance.
All bindings are 100% unsafe, requiring manual memory management and error handling, which increases the risk of bugs and security vulnerabilities.
Users must enable specific features for each module, leading to confusion and compilation errors if not configured correctly, as noted in the FAQ.
Provides only raw FFI bindings, forcing developers to build their own safe wrappers or depend on additional crates for idiomatic interfaces.