winsafe wraps a hand picked slice of Win32 in safe Rust with a GUI layer on top

A hand maintained safe slice of a very large API

WinSafe is described as Windows API and GUI in safe, idiomatic Rust, and the important word in the repository description is handwritten: it has been handwritten since 2019, and the README adds that LLM-generated pull requests are not welcome. That single line tells you the maintenance model. This is a curated binding set that a person keeps in step with the platform, not a generated one that follows a metadata file. The crate has two layers. The low-level layer gives you Win32 API constants, functions and structs, and the high-level layer gives you structs for building native Win32 GUI applications, where the high-level GUI abstractions live behind their own Cargo feature. For a Rust developer whose program has to talk to Windows properly, that is the pitch: the safety of the language applied to an API surface that is otherwise all pointers and handles.

The coverage table, and the honest caveat under it

The README publishes a table of how much of the platform is implemented, and the numbers are large. 924 functions, 266 structs, 12,330 constants, 684 window messages, 55 handles, 99 COM interfaces and 645 COM methods, with a badge putting the project at 70.3 thousand lines of code. Underneath that table sits the caveat that matters most for a decision. The README says that although WinSafe already has a lot of Win32 APIs, it does not have everything, simply because the Win32 API is gigantic, and then it points readers who want comprehensive coverage at the winapi and windows crates, noting that those are unsafe but have everything. That is an unusually clear statement of the trade. You choose this crate for the safety and the GUI layer and accept that a specific API you need might be missing, or you choose a generated binding and write the unsafe code yourself.

Cargo features are the compile-time switch

The APIs are split into Cargo features, named mostly after the native Windows DLLs and libraries they cover, and the stated reason is to speed up compilation time, since only the features you include will be compiled. The list runs from advapi for Advapi32.dll and Ktmw32.dll, through comctl for the Common Controls, dshow for DirectShow, dwm for the Desktop Window Manager, dxgi, gdi for Windows GDI, htmlhelp, kernel for Kernel32.dll, mf for Media Foundation, ole and oleaut for OLE and OLE Automation, psapi for the Process Status API, shell for the COM-based Windows Shell, taskschd for the Task Scheduler, user for User32.dll and ComDlg32.dll, uxtheme for extended window theming, version for manipulating executable version information, wininet, winmm, winspool for the Print Spooler API and winusb. The gui feature pulls in comctl and uxtheme, and there is a separate raw-dylib feature that enables raw-dylib linking. The dependency graph is published as a chart in the repository, and the README notes that you do not need to think about transitive feature resolution, since Cargo handles that once you use a feature.

Windows come in two flavours, programmatic or from a resource file

WinSafe lets you create windows in two ways. You can define the parameters programmatically, or you can load dialogs from a .res file created with a WYSIWYG resource editor, which is the route for anyone who has laid out a dialog visually. The programmatic path is the interesting one, because the shape of the API is what makes the crate pleasant to use. A window is a struct that owns the window manager, and a control holds a reference to its parent:

#[derive(Clone)]
pub struct MyWindow {
    wnd: gui::WindowMain,   // responsible for managing the window
    btn_hello: gui::Button, // a button
}

impl MyWindow {
    pub fn create_and_run() -> w::AnyResult<i32> {
        let wnd = gui::WindowMain::new(
            // instantiate the window manager
            gui::WindowMainOpts {
                title: "My window title",
                size: gui::dpi(300, 150),
                ..Default::default() // leave all other options as default
            },
        );

The options struct takes a title and a size expressed with a dpi helper that scales the values, and the rest of the fields are filled from a default, so you only state what differs. The dependency block for a project using the GUI layer enables the gui feature:

[dependencies]
winsafe = { version = "0.0.29", features = ["gui"] }

The high level layer covers the controls a desktop app actually uses

The GUI abstractions cover two groups. The first is user custom windows and dialogs in five flavours: main, modal, modeless, control and message-only. The second is native controls, and the list is the one you would expect from a Windows application: button, check box, combo box, date and time picker, edit, header, label, list box, list view, month calendar, progress bar, radio button, status bar, tab, track bar, tree view and up down. The event handling is where the safety story shows, because the README's example notes how the click event is handled with a closure rather than a subclass procedure and a window procedure pointer, which is the part of raw Win32 where lifetimes and unsafe code usually leak in. If you are porting a dialog from a resource file, the controls you find in a .res are likely to be on that list, which is a good sign that the abstraction was designed around real dialogs.

Docs, examples and formatting rules live in separate places

The documentation is split by release channel, with the stable API on docs.rs and the nightly master branch published to the author's GitHub Pages site. Examples are not in this repository at all. They live in a dedicated repository, rodrigocfd/winsafe-examples, and the README links to specific folders in it, such as the button click example and the dialog resources example. The top level of this repository shows the supporting files: a ch.sh script, a doc.sh script, a features-chart.md dependency graph, a rustfmt.toml and the src directory. The split is deliberate and follows the usual pattern for a library crate, where the published package is kept small. The Cargo manifest also sets include to a short list, the source, the manifest, the licence and the readme, so the published artifact carries the library and not the examples.

Pre-1.0 versioning on edition 2024

The manifest is small enough to read in full and tells you what kind of project this is. The package is winsafe at version 0.0.29, licensed MIT, categorised as api-bindings, gui and os::windows-apis, on edition 2024 with rust-version 1.87. The docs.rs metadata builds the documentation for the x86_64 Windows MSVC target by default, with aarch64 and i686 also listed, and with all features enabled so the published docs cover the whole surface. The repository has no GitHub releases, so the crates.io version is the release channel, and the last push was on 2026-10-12, days before the current date, so the work is current. A version number of 0.0.29 is worth understanding as a signal: the author has not committed to a stable API surface yet, and the README's own advice, that LLM-generated pull requests are not welcome, suggests changes are reviewed by hand.

Editorial conclusion

Adopt winsafe if you are writing a native Windows application in Rust and want memory-safe calls into the Win32 API plus a GUI layer that saves you from the raw message loop, since the high-level window and control abstractions are the reason to choose this crate over a generic binding generator. Do not adopt it expecting complete Win32 coverage, because the README says so itself and points to the unsafe winapi and windows crates for that. Before you start, decide which Cargo features you need, since the features are the compile-time switch and the dependency graph is published as a chart, and check the version, because the crate is still at 0.0.29 with a pre-1.0 version number.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. rodrigocfd/winsafe on GitHub