0.2.0 - This version may not be safe as it has not been updated for a long time. Find out if your coding project uses this component and get notified of any reported security vulnerabilities with Meterian-X Open Source Security Platform
Maintain your licence declarations and avoid unwanted licences to protect your IP the way you intended.
MIT - MIT LicenseOfficial 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.
Use std::mem::zeroed()
to create an instance of the union, and then assign the value you want using one of the variant methods.
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.
You can use the search functionality in the documentation to find where items are defined.
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.
Yes, absolutely! By default the std
feature of winapi
is disabled, allowing you to write Windows applications using nothing but core
and winapi
.
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
.
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.
Cargo.toml:
[target.'cfg(windows)'.dependencies]
winapi = { version = "0.3", features = ["winuser"] }
main.rs:
#[cfg(windows)] extern crate winapi;
use std::io::Error;
#[cfg(windows)]
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) }
}
#[cfg(not(windows))]
fn print_message(msg: &str) -> Result<(), Error> {
println!("{}", msg);
Ok(())
}
fn main() {
print_message("Hello, world!").unwrap();
}
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).