Rust-Winapi rs: winapi-rs Windows — Windows API bindings


Build status Build status Build Status Gitter Lines of Code 100% unsafe Open issues License


Official communication channel: #windows-dev on the Rust Community Discord

This crate provides raw FFI bindings to all of Windows API. They are gathered by hand using the Windows 10 SDK from Microsoft. I aim to replace all existing Windows FFI in other crates with this crate through the "Embrace, extend, and extinguish" technique.

If this crate is missing something you need, feel free to create an issue, open a pull request, or contact me via other means.

This crate depends on Rust 1.6 or newer on Windows. On other platforms this crate is a no-op and should compile with Rust 1.2 or newer.

Frequently asked questions

How do I create an instance of a union?

Use std::mem::zeroed() to create an instance of the union, and then assign the value you want using one of the variant methods.

Why am I getting errors about unresolved imports?

Each module is gated on a feature flag, so you must enable the appropriate feature to gain access to those items. For example, if you want to use something from winapi::um::winuser you must enable the winuser feature.

How do I know which module an item is defined in?

You can use the search functionality in the documentation to find where items are defined.

Why is there no documentation on how to use anything?

This crate is nothing more than raw bindings to Windows API. If you wish to know how to use the various functionality in Windows API, you can look up the various items on MSDN which is full of detailed documentation.

Can I use this library in no_std projects?

Yes, absolutely! By default the std feature of winapi is disabled, allowing you to write Windows applications using nothing but core and winapi.

Why is winapi's HANDLE incompatible with std's HANDLE?

Because winapi does not depend on std by default, it has to define c_void itself instead of using std::os::raw::c_void. However, if you enable the std feature of winapi then it will re-export c_void from std and cause winapi's HANDLE to be the same type as std's HANDLE.

Should I still use those -sys crates such as kernel32-sys?

No. Those crates are a legacy of how winapi 0.2 was organized. Starting with winapi 0.3 all definitions are directly in winapi itself, and so there is no longer any need to use those -sys crates.



winapi = { version = "0.3", features = ["winuser"] }

#[cfg(windows)] extern crate winapi;
use std::io::Error;

fn print_message(msg: &str) -> Result<i32, Error> {
    use std::ffi::OsStr;
    use std::iter::once;
    use std::os::windows::ffi::OsStrExt;
    use std::ptr::null_mut;
    use winapi::um::winuser::{MB_OK, MessageBoxW};
    let wide: Vec<u16> = OsStr::new(msg).encode_wide().chain(once(0)).collect();
    let ret = unsafe {
        MessageBoxW(null_mut(), wide.as_ptr(), wide.as_ptr(), MB_OK)
    if ret == 0 { Err(Error::last_os_error()) }
    else { Ok(ret) }
fn print_message(msg: &str) -> Result<(), Error> {
    println!("{}", msg);
fn main() {
    print_message("Hello, world!").unwrap();

Financial Support

Do you use winapi in your projects? If so, you may be interested in financially supporting me on Patreon. Companies in particular are especially encouraged to donate (I'm looking at you Microsoft).


  • Missing Cloud Filter API
    Missing Cloud Filter API

    Jun 5, 2020

    Defined in cfapi.h, used for creating placeholder files and directories for cloud sync engines.

    missing api 
  • Missing: WTS session APIs
    Missing: WTS session APIs

    Jun 8, 2020

    Such as WTSRegisterSessionNotification. The constants for the messages it uses ( are present and defined in winuser, but the registration function and its Unregister counterpart are missing.

    missing api 
  • Add FILTERKEYS struct and constants
    Add FILTERKEYS struct and constants

    Jun 8, 2020

    This PR adds the FILTERKEYS struct and its associated constants from WinUser.h.

    waiting on review 
  • Add STICKYKEYS struct and associated constants
    Add STICKYKEYS struct and associated constants

    Jun 9, 2020

    This PR adds the missing STICKYKEYS struct and its associated constants from the WinUser.h header.

    waiting on review 
  • Added missing FileVersionInfo functionality
    Added missing FileVersionInfo functionality

    Jun 11, 2020

    Added missing functions to Reordered to match the order of the original header Replaced explicit pointers in with their concise winapi equivalents

    Created from versrc.h and populated it with the constants and struct type

    waiting on review 
  • Missing Propvarutil.h
    Missing Propvarutil.h

    Jun 11, 2020

    missing api 
  • Update ::sapi and move to um::sapi
    Update ::sapi and move to um::sapi

    Feb 22, 2017

    Work in progress. I still need to clear up a few things in um::sapi and add um::sapiaut + um::sapiddk. This PR also brings in um::servprov and an incomplete um::urlmon. I can either finish the latter in this PR or in a separate one later.

  • Add iphlpapi support
    Add iphlpapi support

    Feb 13, 2018



    C Header | Rust | Review ----------------- | --------------------------------------- | -------- shared/ifdef.h | shared/ | TODO shared/ifmib.h | shared/ | TODO shared/ipifcons.h | shared/ | TODO shared/ipmib.h | shared/ | TODO shared/Iprtrmib.h | shared/ | TODO shared/mprapidef.h | shared/ | TODO shared/nldef.h | shared/ | TODO shared/tcpestats.h | shared/ | TODO shared/tcpmib.h | shared/ | TODO shared/udpmib.h | shared/ | TODO um/IPExport.h | um/ | TODO um/IPTypes.h | um/ | TODO um/iphlpapi.h | um/ | TODO


    • [ ] Dependency Tree ( )
    • [ ] Header Translation
    • [ ] Code Style
  • winapi 0.3 overhaul
    winapi 0.3 overhaul

    Aug 13, 2016

    All progress is in the dev branch.

    • [x] Remove all trait impls except Copy and Clone.
      • [x] Update all macros to do so.
      • [x] Get rid of any derives that are floating around, not behind a macro.
    • [x] Make enums nothing more than integer constants with the enum type being an alias for u32.
    • [x] Update all copyrights and license stuff.
    • [x] For each header do the following:
      • Move it to the appropriate directory based on where it is located in the Windows SDK such as um or shared.
      • Create a feature for that header such as foo.
      • Add the appropriate pub mod foo; to that folder's module.
      • Add a cfg to that mod such as #[cfg(feature = "foo")].
      • Get rid of all :: and add imports to pull in any definitions it needs from other headers.
      • Add the feature to and specify its dependencies on other headers and also libraries.
    • [x] For each -sys crate do the following:
      • Move the function definitions to the header module where it is actually defined.
      • Ensure that any header that has functions from that library specifies that dependency in
    • [x] Update all usage of UNION! to UNION2!. Once that is done, rename UNION2! to UNION!.
    • [x] Inform everyone with an open PR that they'll need to update their PR for the new world order.
  • Porting more APIs to 0.3
    Porting more APIs to 0.3

    May 4, 2017

    This is blocking on #437, which is why that commit shows up here as well. I've realized merging can be problematic when pulling stuff out of these large older source files, so I've been stacking them up. Maybe I'll submit a bunch as a single PR in the future so the inter-patch dependencies are less of an issue.

    I'm filing this now to get a head-start on any compilation builds on CI.

  • Finish porting advapi32 to v0.3
    Finish porting advapi32 to v0.3

    May 21, 2017

    Used @Susurrus's fork as a base.

    All functions exported by advapi32 that can be found in the SDK headers* have been added to their corresponding Rust files with the exception of SetServiceBits (um/LMServer.h). If a Rust version of a header already existed then only the required pieces were added to the file. If the Rust file didn't exist already the full header was ported to the extent I was able to.

    *139 functions are exported from the DLL but have no declaration in any header in the latest Windows SDK.

  • Update license and copyright header
    Update license and copyright header

    Jul 28, 2016

    I would like to update winapi to be dual licensed under MIT and Apache 2.0. For the sake of consistency I would also like to update the copyright header in every file as follows.

    // Copyright © 2016 winapi-rs developers
    // Licensed under the Apache License, Version 2.0
    // <LICENSE-APACHE or> or the MIT license
    // <LICENSE-MIT or>, at your option.
    // All files in the project carrying such notice may not be copied, modified, or distributed
    // except according to those terms.

    To do this I need the consent of contributors to this project so please state whether you consent here. Even if you don't consent, I still need to know so I can rewrite your contribution from scratch. Thanks.

    • [x] @aarzee
    • [x] @Aceeri
    • [x] @alexcrichton
    • [x] @application-developer-DA
    • [x] @ArtemGr
    • [x] @bitbegin
    • [x] @Boddlnagg
    • [x] @bozaro
    • [x] @bungcip
    • [ ] @bvinc
    • [ ] @bvinc83
    • [x] @cessationoftime
    • [x] @cmr
    • [x] @Connorcpu
    • [x] @cpardotortosa
    • [ ] @CrimsonVoid
    • [x] @CruzBishop
    • [x] @Daggerbot
    • [x] @danburkert
    • [x] @DanielKeep
    • [x] @diaphore
    • [x] @Diggsey
    • [x] @DoumanAsh
    • [x] @Draivin
    • [x] @Eh2406
    • [x] @excaliburHisSheath
    • [x] @ForNeVeR
    • [x] @gentoo90
    • [x] @Havvy
    • [x] @iliekturtles
    • [x] @inrustwetrust
    • [x] @Jascha-N
    • [x] @jeandudey
    • [x] @jmesmon
    • [x] @jminer
    • [ ] @jojonv
    • [x] @Jonesey13
    • [x] @ktrance
    • [x] @mmitteregger
    • [x] @msiglreith
    • [x] @Osspial
    • [x] @overdrivenpotato
    • [x] @pdib
    • [x] @recombinant
    • [x] @red75prime
    • [x] @retep998
    • [x] @rpjohnst
    • [x] @seanmonstar
    • [x] @sectopod
    • [x] @sfackler
    • [x] @skdltmxn
    • [x] @skeleten
    • [x] @Stebalien
    • [x] @steffengy
    • [x] @thelink2012
    • [x] @tomaka
    • [ ] @toolness
    • [x] @varding
    • [x] @Xirdus
    • [x] @yonran