microsoft/windows-rs

Rust for Windows

View on GitHub ↗Jump to charts ↓Open shareable report

Summary Information

Updated 45 minutes ago
Added to GitGenius on September 4th, 2026
Created on September 12th, 2019
Open Issues & Pull Requests: 22 (+0)
GitHub issues: Enabled
Number of forks: 661
Total Stargazers: 12,733 (+0)
Total Subscribers: 118 (+0)

Repository Insights (GitGenius)

Median issue/PR response: 5.4 hours
Mean response time: 13.9 days
90th percentile: 10.6 days
Tracked items: 548

How this project is maintained

Around half of the issues opened in the past year never receive a reply. 64% of open issues come from outside the core team, a mix of external reports and the maintainers' own roadmap. Work labelled "bug" is answered fastest, typically in about 3 hours, while "newsletter" waits about 11 days. Only 11% of issues opened in the past year have been closed. Three people close 87% of everything that gets resolved.

Charts & Analytics

Fetching additional details & charts...

Issue Activity (beta)

Open issues: 22
New in 7 days: 10
Closed in 7 days: 17
Avg open age: 390 days
Stale 30+ days: 16
Stale 90+ days: 5

Recent activity

Opened in 7 days: 10
Closed in 7 days: 8
Comments in 7 days: 7
Events in 7 days: 27

Top labels

  • question (262)
  • enhancement (160)
  • bug (68)
  • newsletter (13)
  • upstream (4)

Detailed Description

windows-rs is a collection of Rust crates that provide bindings and safe wrappers for Windows APIs, from COM and WinRT types to system services, UI frameworks, and raw Win32 functions.

The project solves the problem of safely and ergonomically calling Windows APIs from Rust code. Rather than exposing raw, unsafe bindings directly, it provides layered abstractions: focused crates for specific domains like registry access, window creation, and async operations; core interop crates for COM, WinRT types, and error handling; and code generation tools for custom bindings. This modular approach lets developers choose the right level of abstraction for their use case, from high-level declarative UI libraries down to minimal generated bindings for niche APIs.

Reusable libraries should prefer the focused crates over the broad umbrella crates windows and windows-sys, which add dependency weight and version churn when multiple libraries depend on them. Binary applications can use the umbrella crates with feature flags for broad API coverage. The project explicitly recommends using windows-bindgen to generate minimal project-specific bindings for APIs not covered by existing focused crates, avoiding the dependency bloat of pulling in large umbrella crates for a handful of functions. Developers building UI applications will find declarative UI support through windows-reactor backed by WinUI 3, along with lower-level graphics and composition APIs. Those working with system-level concerns can use crates for registry access, Windows services, version detection, and thread pool management.

The project maintains a large surface area of Windows API coverage through code generation from official metadata rather than hand-written bindings. Development activity shows consistent attention to the focused crate ecosystem, with individual crates covering specific problem domains rather than monolithic catch-all bindings. The project provides detailed crate-specific documentation and usage guidance rather than treating all APIs uniformly.