retep998 / winapi-rs Goto Github PK

View Code? Open in Web Editor NEW

1.8K 38.0 386.0 24.89 MB

Rust bindings to Windows API

Home Page: https://crates.io/crates/winapi

License: Apache License 2.0

Rust 100.00%

winapi rust windows ffi

winapi-rs's Introduction

winapi-rs

Documentation

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.

Example

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();
}

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).

winapi-rs's People

Contributors

Stargazers

Watchers

Forkers

crimsonvoid tomaka gentoo90 inrustwetrust bungcip jojonv cyderize bozaro untitaker msiglreith xirdus emberian toolness yonran danburkert sarvex bryal drewet stebalien aonorin iliekturtles jminer eminence roblabla darkf zhangf911 alexcrichton bvinc cessationoftime bvinc83 seanmonstar fornever peterreid skdltmxn techern-archived doumanash cruzbishop codyps boddlnagg recombinant red75prime overdrivenpotato therustmonk diggsey strogo impost0r pdib oli-obk contextfree obv-mikhail aceeri rpjohnst osspial sectopod robisys havvy jascha-n ktrance mvdnes danielkeep brson liunix1982 openansible sfackler mmitteregger diamondo25 neivv norbert78 wfraser ctrlzvi kvark oconnor0 roki1988 alexchandel mrvux faultyram pantaloons team-worm trlim connicpu bruflot vvuk test9753 blackyoup pctg-x8 shepmaster wilfred jmegaffin dushistov nbaksalyar susurrus dtibbs mozillaonline guillaumegomez popog rustnow notriddle vengarioth andermatt64 ruin0x11

winapi-rs's Issues

[NOTICE] 🐇 will be away

From August 1 to August 9 I will be away. I will be unable to review any pull requests during that time. If things start to explode you'll just have to survive somehow until I return.

Usage example in README

So with the new crate structure how do I use, say, PlaySoundA?

With

[dependencies.winapi]
git = "https://github.com/retep998/winapi-rs"

and

winapi::winmm-sys::PlaySoundA

all I get is the unresolved name winapi::winmm error.

CancelIo in kernel32-sys missing

CancelIo is missing from kernel32-sys crate.

Definition is:

BOOL WINAPI CancelIo(
  _In_  HANDLE hFile
);

Split code into modules

Currently lib.rs is a massive file which makes editing difficult, and can bring certain editors to a crawl.

Move code from each header into separate module
Split libraries into separate crates
Get rid of ugly :: everywhere as soon as glob imports aren't broken.

missing some structure and constant for windows console

currently winapi missing some structure and constant from windows console subsystem.

This is some of them:

#[repr(C)]
#[derive(Copy)]
pub struct KEY_EVENT_RECORD {
    pub bKeyDown : BOOL,
    pub wRepeatCount : WORD,
    pub wVirtualKeyCode : WORD,
    pub wVirtualScanCode : WORD,

    // Rust don't support union so we use the widest type as default
    // union {
        pub UnicodeChar : WCHAR,
        // pub AsciiChar : CHAR,
    // } uChar;

    pub dwControlKeyState : DWORD,
}
pub type PKEY_EVENT_RECORD = *mut KEY_EVENT_RECORD;

// ControlKeyState flags
pub const CAPSLOCK_ON : DWORD        = 0x0080; // the capslock light is on.
pub const RIGHT_ALT_PRESSED : DWORD  = 0x0001; // the right alt key is pressed.
pub const LEFT_ALT_PRESSED : DWORD   = 0x0002; // the left alt key is pressed.
pub const RIGHT_CTRL_PRESSED : DWORD = 0x0004; // the right ctrl key is pressed.
pub const LEFT_CTRL_PRESSED : DWORD  = 0x0008; // the left ctrl key is pressed.
pub const SHIFT_PRESSED : DWORD      = 0x0010; // the shift key is pressed.
pub const NUMLOCK_ON : DWORD         = 0x0020; // the numlock light is on.
pub const SCROLLLOCK_ON : DWORD      = 0x0040; // the scrolllock light is on.
pub const ENHANCED_KEY : DWORD       = 0x0100; // the key is enhanced.

#[repr(C)]
#[derive(Copy)]
pub struct MOUSE_EVENT_RECORD {
    pub dwMousePosition : COORD,
    pub dwButtonState : DWORD,
    pub dwControlKeyState : DWORD,
    pub dwEventFlags : DWORD,
}
pub type PMOUSE_EVENT_RECORD = *mut MOUSE_EVENT_RECORD;

// ButtonState flags
pub const FROM_LEFT_1ST_BUTTON_PRESSED : DWORD = 0x0001;
pub const RIGHTMOST_BUTTON_PRESSED : DWORD     = 0x0002;
pub const FROM_LEFT_2ND_BUTTON_PRESSED : DWORD = 0x0004;
pub const FROM_LEFT_3RD_BUTTON_PRESSED : DWORD = 0x0008;
pub const FROM_LEFT_4TH_BUTTON_PRESSED : DWORD = 0x0010;

// EventFlags
pub const MOUSE_MOVED : DWORD  = 0x0001;
pub const DOUBLE_CLICK : DWORD = 0x0002;

#[repr(C)]
#[derive(Copy)]
pub struct WINDOW_BUFFER_SIZE_RECORD {
    pub dwSize : COORD,
}
pub type PWINDOW_BUFFER_SIZE_RECORD = *mut WINDOW_BUFFER_SIZE_RECORD;

#[repr(C)]
#[derive(Copy)]
pub struct MENU_EVENT_RECORD {
    pub dwCommandId : UINT,
}
pub type PMENU_EVENT_RECORD = *mut MENU_EVENT_RECORD;

#[repr(C)]
#[derive(Copy)]
pub struct FOCUS_EVENT_RECORD {
    pub bSetFocus : BOOL,
}
pub type PFOCUS_EVENT_RECORD = *mut FOCUS_EVENT_RECORD;

// EventType flags:
pub const KEY_EVENT : WORD =  0x0001; // Event contains key event record
pub const MOUSE_EVENT : WORD =  0x0002; // Event contains mouse event record
pub const WINDOW_BUFFER_SIZE_EVENT : WORD =  0x0004; // Event contains window change event record
pub const MENU_EVENT : WORD =  0x0008; // Event contains menu event record
pub const FOCUS_EVENT : WORD =  0x0010; // event contains focus change

#[repr(C)]
#[derive(Copy)]
pub struct INPUT_RECORD {
    pub EventType : WORD,
    // union {
        // pub KeyEvent : KEY_EVENT_RECORD,
        // pub MouseEvent : MOUSE_EVENT_RECORD,
        pub WindowBufferSizeEvent : WINDOW_BUFFER_SIZE_RECORD,
        // pub MenuEvent : MENU_EVENT_RECORD,
        // pub FocusEvent : FOCUS_EVENT_RECORD,
    // }
}
pub type PINPUT_RECORD = *mut INPUT_RECORD;


#[repr(C)]
#[derive(Copy)]
pub struct CHAR_INFO {
    // union {
        pub UnicodeChar : WCHAR,
        // pub AsciiChar : CHAR,
    // }
    pub Attributes : WORD,
}
pub type PCHAR_INFO = *mut CHAR_INFO;

// Attributes flags:
pub const FOREGROUND_BLUE : WORD      = 0x0001; // text color contains blue.
pub const FOREGROUND_GREEN : WORD     = 0x0002; // text color contains green.
pub const FOREGROUND_RED : WORD       = 0x0004; // text color contains red.
pub const FOREGROUND_INTENSITY : WORD = 0x0008; // text color is intensified.
pub const BACKGROUND_BLUE : WORD      = 0x0010; // background color contains blue.
pub const BACKGROUND_GREEN : WORD     = 0x0020; // background color contains green.
pub const BACKGROUND_RED : WORD       = 0x0040; // background color contains red.
pub const BACKGROUND_INTENSITY : WORD = 0x0080; // background color is intensified.

Broken implementation of winuser::INPUT, must use largest variant

The implementation you provide for INPUT is broken. The union field is too small to contain any of its variants, as it is type ().

Given the state of union support in Rust, the only declaration that produces a correctly sized struct is declaring the struct with the largest, most-aligned variant, as I did in my pull request.

Thus this:

#[repr(C)] #[derive(Copy)] pub struct INPUT {
    pub type_: ::DWORD,
    pub union_: MOUSEINPUT,
}

rather than this:

#[repr(C)] #[derive(Copy)] pub struct INPUT {
    pub type_: ::DWORD,
    pub union_: (), // FIXME - Use unions or unsafe enums here somehow
}

I get that it's a fixme, but it's also unusable right now. I'd basically have to declare my own INPUT with the correct size and pass that to SendInput(), ignoring this altogether.

For now, using the largest variant will guarantee the correct size of the struct, and will allow transmute_copys of all three union variants into the union_ field.

Could you fix this?

kernel32 [A-G]

hid-sys

@ruabmbua poked me on IRC about needing hid-sys but I wasn't around to respond.

If you need something which would fall under this project but isn't done yet, by all means feel free to fill it in and submit a pull request.

Add bindings for IFileDialog

@retep998 asked for me to post an issue for what implementation I needed
MSDN Reference for this: https://msdn.microsoft.com/en-us/library/windows/desktop/bb775966%28v=vs.85%29.aspx

Bindings for Wldap32

Hi,

I'like to make use of ldap related functions from Wldap32.dll from rust, would it be possible to add them to winapi ? The current wldap32-sys crate looks empty so far...
(I could try to do this myself and send a pull request if you can provide some guidance on how to do this, are you using an automated tool to generate the bindings ?)

Thanks !

gdi32

file notification api

It'd be nice to have the things necessary for file notifications. To be honest I'm not exactly sure what is necessary, but I imagine at least the stuff that's used here.

Bindings to raw input

https://msdn.microsoft.com/en-us/library/windows/desktop/ms645536(v=vs.85).aspx

Question: Is it possible to do a Win32 UI?

Is it possible to build a Win32 UI with this in Rust? If you create a new project in Visual Studio 2013, you get this template. Is it possible to write this in Rust instead? I would love to see that as an example?

// Win32Project1.cpp : Defines the entry point for the application.
//

#include "stdafx.h"
#include "Win32Project1.h"

#define MAX_LOADSTRING 100

// Global Variables:
HINSTANCE hInst;                                // current instance
TCHAR szTitle[MAX_LOADSTRING];                  // The title bar text
TCHAR szWindowClass[MAX_LOADSTRING];            // the main window class name

// Forward declarations of functions included in this code module:
ATOM                MyRegisterClass(HINSTANCE hInstance);
BOOL                InitInstance(HINSTANCE, int);
LRESULT CALLBACK    WndProc(HWND, UINT, WPARAM, LPARAM);
INT_PTR CALLBACK    About(HWND, UINT, WPARAM, LPARAM);

int APIENTRY _tWinMain(_In_ HINSTANCE hInstance,
                     _In_opt_ HINSTANCE hPrevInstance,
                     _In_ LPTSTR    lpCmdLine,
                     _In_ int       nCmdShow)
{
    UNREFERENCED_PARAMETER(hPrevInstance);
    UNREFERENCED_PARAMETER(lpCmdLine);

    // TODO: Place code here.
    MSG msg;
    HACCEL hAccelTable;

    // Initialize global strings
    LoadString(hInstance, IDS_APP_TITLE, szTitle, MAX_LOADSTRING);
    LoadString(hInstance, IDC_WIN32PROJECT1, szWindowClass, MAX_LOADSTRING);
    MyRegisterClass(hInstance);

    // Perform application initialization:
    if (!InitInstance (hInstance, nCmdShow))
    {
        return FALSE;
    }

    hAccelTable = LoadAccelerators(hInstance, MAKEINTRESOURCE(IDC_WIN32PROJECT1));

    // Main message loop:
    while (GetMessage(&msg, NULL, 0, 0))
    {
        if (!TranslateAccelerator(msg.hwnd, hAccelTable, &msg))
        {
            TranslateMessage(&msg);
            DispatchMessage(&msg);
        }
    }

    return (int) msg.wParam;
}



//
//  FUNCTION: MyRegisterClass()
//
//  PURPOSE: Registers the window class.
//
ATOM MyRegisterClass(HINSTANCE hInstance)
{
    WNDCLASSEX wcex;

    wcex.cbSize = sizeof(WNDCLASSEX);

    wcex.style          = CS_HREDRAW | CS_VREDRAW;
    wcex.lpfnWndProc    = WndProc;
    wcex.cbClsExtra     = 0;
    wcex.cbWndExtra     = 0;
    wcex.hInstance      = hInstance;
    wcex.hIcon          = LoadIcon(hInstance, MAKEINTRESOURCE(IDI_WIN32PROJECT1));
    wcex.hCursor        = LoadCursor(NULL, IDC_ARROW);
    wcex.hbrBackground  = (HBRUSH)(COLOR_WINDOW+1);
    wcex.lpszMenuName   = MAKEINTRESOURCE(IDC_WIN32PROJECT1);
    wcex.lpszClassName  = szWindowClass;
    wcex.hIconSm        = LoadIcon(wcex.hInstance, MAKEINTRESOURCE(IDI_SMALL));

    return RegisterClassEx(&wcex);
}

//
//   FUNCTION: InitInstance(HINSTANCE, int)
//
//   PURPOSE: Saves instance handle and creates main window
//
//   COMMENTS:
//
//        In this function, we save the instance handle in a global variable and
//        create and display the main program window.
//
BOOL InitInstance(HINSTANCE hInstance, int nCmdShow)
{
   HWND hWnd;

   hInst = hInstance; // Store instance handle in our global variable

   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,
      CW_USEDEFAULT, 0, CW_USEDEFAULT, 0, NULL, NULL, hInstance, NULL);

   if (!hWnd)
   {
      return FALSE;
   }

   ShowWindow(hWnd, nCmdShow);
   UpdateWindow(hWnd);

   return TRUE;
}

//
//  FUNCTION: WndProc(HWND, UINT, WPARAM, LPARAM)
//
//  PURPOSE:  Processes messages for the main window.
//
//  WM_COMMAND  - process the application menu
//  WM_PAINT    - Paint the main window
//  WM_DESTROY  - post a quit message and return
//
//
LRESULT CALLBACK WndProc(HWND hWnd, UINT message, WPARAM wParam, LPARAM lParam)
{
    int wmId, wmEvent;
    PAINTSTRUCT ps;
    HDC hdc;

    switch (message)
    {
    case WM_COMMAND:
        wmId    = LOWORD(wParam);
        wmEvent = HIWORD(wParam);
        // Parse the menu selections:
        switch (wmId)
        {
        case IDM_ABOUT:
            DialogBox(hInst, MAKEINTRESOURCE(IDD_ABOUTBOX), hWnd, About);
            break;
        case IDM_EXIT:
            DestroyWindow(hWnd);
            break;
        default:
            return DefWindowProc(hWnd, message, wParam, lParam);
        }
        break;
    case WM_PAINT:
        hdc = BeginPaint(hWnd, &ps);
        // TODO: Add any drawing code here...
        EndPaint(hWnd, &ps);
        break;
    case WM_DESTROY:
        PostQuitMessage(0);
        break;
    default:
        return DefWindowProc(hWnd, message, wParam, lParam);
    }
    return 0;
}

// Message handler for about box.
INT_PTR CALLBACK About(HWND hDlg, UINT message, WPARAM wParam, LPARAM lParam)
{
    UNREFERENCED_PARAMETER(lParam);
    switch (message)
    {
    case WM_INITDIALOG:
        return (INT_PTR)TRUE;

    case WM_COMMAND:
        if (LOWORD(wParam) == IDOK || LOWORD(wParam) == IDCANCEL)
        {
            EndDialog(hDlg, LOWORD(wParam));
            return (INT_PTR)TRUE;
        }
        break;
    }
    return (INT_PTR)FALSE;
}

PlaySound

I'm missing the PlaySond function.
http://msdn.microsoft.com/en-us/library/windows/desktop/dd743680%28v=vs.85%29.aspx

Isn't it a part of the Windows API?

(Using WBScript currently as a workaround: http://stackoverflow.com/a/23316395/257568).

Some missing functions

https://gist.github.com/engstad/9679342a36ab6582289c

CONTEXT is too small on x86_64

The current size is 1136, but if I print out the size in C it's 1232. Perhaps this is related to the 16-byte alignment requirements? Unfortunately I don't know of a great way to get that kind of alignment other than just adding the padding manually for now.

Add bindings for IShellExtInit and IContextMenu

Also, can you give me some tips on implementing COM interface in Rust?
I was going to try creating a shell extension in Rust, but got stuck on this.

DirectX bindings

Is there any plan to support DirectX API here?

shell32

ntdll [R]

Add windows API errors handling

Many of WinAPI calls return error codes listed in winerror.rs which sometimes should be returned to user as Result.
Add appropriate data structures to prevent their reinvention in each crate which uses winapi.
Maybe something like:

#[derive(Debug)]
pub struct WinError {
    err: winapi::DWORD,
    message: String,
}

impl WinError {
    pub fn new(err: winapi::DWORD) -> WinError {
        WinError{ err: err, message: error_string(err)}
    }
}

pub type WinResult<T> = std::result::Result<T, WinError>;

// copycat of rust/src/libstd/sys/windows/os.rs::error_string
// `use std::sys::os::error_string` leads to
// error: function `error_string` is private.
// Get a detailed string description for the given error number
fn error_string(errnum: winapi::DWORD) -> String {
    let mut buf = [0 as winapi::WCHAR; 2048];
    unsafe {
        let res = kernel32::FormatMessageW(winapi::FORMAT_MESSAGE_FROM_SYSTEM |
                                 winapi::FORMAT_MESSAGE_IGNORE_INSERTS,
                                 ptr::null_mut(),
                                 errnum as winapi::DWORD,
                                 0,
                                 buf.as_mut_ptr(),
                                 buf.len() as winapi::DWORD,
                                 ptr::null_mut());
        if res == 0 {
            // Sometimes FormatMessageW can fail e.g. system doesn't like langId,
            // let fm_err = errno();
            return format!("OS Error {} (FormatMessageW() returned error)",
                           errnum);
        }

        let b = buf.iter().position(|&b| b == 0).unwrap_or(buf.len());
        let msg = String::from_utf16(&buf[..b]);
        match msg {
            Ok(msg) => msg.trim_right().to_string(),
            Err(..) => format!("OS Error {} (FormatMessageW() returned \
                                invalid UTF-16)", errnum),
        }
    }
}

Usage:

fn use_winapi_call() -> winapi::WinResult<()> {
    match unsafe {
        advapi32::SomeApiCall(param) as winapi::DWORD
    } {
        0 => Ok(()),
        err => Err(winapi::WinError::new(err))
    }
}

kernel32 [H-Z]

[build] undefined reference to AddClipboardFormatListener | Define WINVER?

Some functions requires to have speicfiic windows versions.
By default in (gcc)winuser.h:

#ifndef WINVER
#define WINVER 0x0502
#endif

Due to that for example AddClipboardFormatListener() will not work as there will be no reference in header, though it is available starting from Vista

I believe that winver is defined only in windows headers, but not sure what's approach should be in case of gcc

As of current my build fails like that:
undefined reference to AddClipboardFormatListener'`

GCC 4.9.2 winuser.h:

#if WINVER >= 0x0600
  WINUSERAPI WINBOOL WINAPI AddClipboardFormatListener (HWND hwnd);
  WINUSERAPI WINBOOL WINAPI RemoveClipboardFormatListener (HWND hwnd);
  WINUSERAPI WINBOOL WINAPI GetUpdatedClipboardFormats (PUINT lpuiFormats, UINT cFormats, PUINT pcFormatsOut);
#endif

#[link(name="...")]

Are there any plans to add link attributes to the extern "system" blocks for function definitions? This would prevent sending -l gdi32 and etc. into rustc.

Cargo features to conditionally link libraries

Because standard Rust installations do not come with all the winapi libraries, use cargo features to allow end-users of the library to only select the libraries they need.

mmap constants are missing

The Following mmap constants are missing, as documented here:

FILE_MAP_READ
FILE_MAP_WRITE
FILE_MAP_ALL_ACCESS
FILE_MAP_COPY
FILE_MAP_EXECUTE

MAKEINTRESOURCE macro

Winuser.h defines a macro that is used a fair bit : MAKEINTRESOURCE.

Converts an integer value to a resource type compatible with the resource-management functions. This macro is used in place of a string containing the name of the resource.

#define MAKEINTRESOURCEA(i) ((LPSTR)((ULONG_PTR)((WORD)(i))))
#define MAKEINTRESOURCEW(i) ((LPWSTR)((ULONG_PTR)((WORD)(i))))

Would it be within the scope of this crate to reimplement this macro for inclusion inside winuser.rs ?

Version bump user32-sys

There are some functions in user32 that have not been published to crates.io that are required by a PR to Glutin. It would be appreciated if user32-sys could be published to make those functions available.

getpid and process termination

Please consider adding the following:

  pub fn GetCurrentProcessId() -> DWORD;
  pub fn TerminateProcess(hProcess: HANDLE, uExitCode: UINT) -> BOOL;

to the kernel32 bindings.

Rust warning: crate names soon cannot contain hyphens: advapi32-sys

http://internals.rust-lang.org/t/pre-rfc-resolve-support-for-hyphens-in-crate-names/1459

Update winmm-sys (and other out of date crates) on crates.io

The version of winmm-sys on crates.io is pretty out of date, when I tried to pull it down on a new machine it didn't have some of the functions I needed even though they're present on master. I don't know what other crates are affected. Also the link to documentation that shows up on crates.io is out of date and doesn't give a valid page.

ld: cannot find crt2.o: No such file or directory

Recently there's been a linking error building kernel32-sys with the latest Rust nightlies.

rustc --version: rustc 1.1.0-nightly (ce1150b9f 2015-05-04) (built 2015-05-04)

Building Racer:

smolny:~/rust/racer$ cargo build
   Compiling kernel32-sys v0.1.0
   Compiling bitflags v0.1.1
   Compiling libc v0.1.6
   Compiling rustc-serialize v0.3.14
   Compiling unicode-xid v0.0.1
error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-static-libgcc" "-m64" "-L" "C:\spool\Rust\bin\rust                                        lib\x86_64-pc-windows-gnu\lib" "-o" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\build\kernel32-sys-852914e74bb6c4c5\build_script_bui                                        ld.exe" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\build\kernel32-sys-852914e74bb6c4c5\build_script_build.o" "-Wl,--gc-sections" "-                                        L" "C:\spool\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib" "-lstd-4e7c5e5c" "-L" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\deps" "-L                                        " "C:\spool\cygwin\home\Artem\rust\racer\target\debug\deps" "-L" "\\?\C:\spool\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib" "-L" "C:\spool\cy                                        gwin\home\Artem\rust\racer\.rust\bin\x86_64-pc-windows-gnu" "-L" "C:\spool\cygwin\home\Artem\rust\racer\bin\x86_64-pc-windows-gnu" "-Wl,--wh                                        ole-archive" "-Wl,-Bstatic" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "-lws2_32" "-luserenv" "-lcompiler-rt"
note: ld: cannot find crt2.o: No such file or directory
ld: cannot find crtbegin.o: No such file or directory
ld: cannot find crtend.o: No such file or directory

error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `kernel32-sys`.

To learn more, run the command again with --verbose.

Verbose:

error: linking with `gcc` failed: exit code: 1
note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-static-libgcc" "-m64" "-L" "C:\spool\Rus
t\bin\rustlib\x86_64-pc-windows-gnu\lib" "-o" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\build\kernel32-sys-852914e74bb6c
4c5\build_script_build.exe" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\build\kernel32-sys-852914e74bb6c4c5\build_script_b
uild.o" "-Wl,--gc-sections" "-L" "C:\spool\Rust\bin\rustlib\x86_64-pc-windows-gnu\lib" "-lstd-4e7c5e5c" "-L" "C:\spool\cygwin\home
\Artem\rust\racer\target\debug\deps" "-L" "C:\spool\cygwin\home\Artem\rust\racer\target\debug\deps" "-L" "\\?\C:\spool\Rust\bin\ru
stlib\x86_64-pc-windows-gnu\lib" "-L" "C:\spool\cygwin\home\Artem\rust\racer\.rust\bin\x86_64-pc-windows-gnu" "-L" "C:\spool\cygwi
n\home\Artem\rust\racer\bin\x86_64-pc-windows-gnu" "-Wl,--whole-archive" "-Wl,-Bstatic" "-Wl,--no-whole-archive" "-Wl,-Bdynamic" "
-lws2_32" "-luserenv" "-lcompiler-rt"
note: ld: cannot find crt2.o: No such file or directory
ld: cannot find crtbegin.o: No such file or directory
ld: cannot find crtend.o: No such file or directory

error: aborting due to previous error
Build failed, waiting for other jobs to finish...
Could not compile `kernel32-sys`.

Caused by:
  Process didn't exit successfully: `rustc C:\Users\Артем\.cargo\registry\src\github.com-1ecc6299db9ec823\kernel32-sys-0.1.0\build
.rs --crate-name build_script_build --crate-type bin -C prefer-dynamic -g --out-dir C:\spool\cygwin\home\Artem\rust\racer\target\d
ebug\build\kernel32-sys-852914e74bb6c4c5 --emit=dep-info,link -L dependency=C:\spool\cygwin\home\Artem\rust\racer\target\debug\dep
s -L dependency=C:\spool\cygwin\home\Artem\rust\racer\target\debug\deps -Awarnings` (exit code: 101)

C:\spool\cygwin\home\Artem\rust\racer>

Worked fine before.

I wonder if I'm not alone in seeing this problem?

ole32

Discrepancy with struct member types for SYSTEMTIME

According to MSDN documentation, SYSTEMTIME's members are of type WORD as opposed to DWORD.

ReadDirectoryChangesW last param type LPOVERLAPPED_COMPLETION_ROUTINE must be wrapped in an Option

In order to be able to pass no function to the last parameter of ReadDirectoryChangesW, which is of type: LPOVERLAPPED_COMPLETION_ROUTINE, the function pointer must be wrapped in an Option.

Also see:

We (@Centril, @retep998, @blaenk) discussed this on IRC.

Linking XInput

I'm trying to get xinput-sys working, and I'm having trouble getting linking setup. The changes I've made can be found on my fork, the important files are Cargo.toml and build.rs. When I try to build with the current setup I get the error ld: cannot find -lxinput.

I appreciate any help you can offer.

user32

Why are the VK_KEY constants of type WPARAM

These are single byte values.

Plus WPARAM is a different size depending on Win 32-bit vs 64-bit which could easily break people's code if they don't have both 32 and 64 bit to test on.

Helper Implementations for COM Types

Winapi-rs has has support for COM types through manually declaring the vtable, but I've noticed that using these types is pretty nasty compared to doing so in C (see this example). This could be greatly simplified by adding an impl to the various COM types that wrap up the calls to the vtable functions. I've started implementing this on my fork (see this commit), but I wanted to get some feedback before making a pull request. Is this sort of change in line with the design ethos of winapi-rs? It seems like the idea is to only provide the C bindings to the Windows APIs, so this starts to go beyond that in providing a wrapper around the C bindings to provide a cleaner API. The reason I still think this is a good idea is that it recreates the C++ API that COM is supposed to have, which I would argue still adheres to the design ethos of winapi-rs.

Let me know what you think. If this seems like something worth doing I can make PRs as get things put together.

#[link(name = "gdi32")]
extern "system" {
    pub fn CreateCompatibleDC(hdc: HDC) -> HDC;

    pub fn DeleteDC(hdc: HDC) -> BOOL;

    pub fn CreateCompatibleBitmap(hdc: HDC, nWidth: c_int, nHeight: c_int) -> HBITMAP;

    pub fn SelectObject(hdc: HDC, hgdiobj: HGDIOBJ) -> HGDIOBJ;

    pub fn GetStockObject(fnObject: c_int) -> HGDIOBJ;

    pub fn DeleteObject(hObject: HGDIOBJ) -> BOOL;

    pub fn SetDCBrushColor(hdc: HDC, crColor: COLORREF) -> COLORREF;

    pub fn BitBlt(hdcDest: HDC, nXDest: c_int, nYDest: c_int, nWidth: c_int, nHeight: c_int,
                  hdcSrc: HDC, nXSrc: c_int, nYSrc: c_int, dwRop: DWORD) -> BOOL;

    pub fn FillRect(hDC: HDC, lprc: *const RECT, hbr: HBRUSH) -> c_int;

    pub fn Rectangle(hDC: HDC, nLeftRect: c_int, nTopRect: c_int, nRightRect: c_int, nBottomRect: c_int) -> BOOL;

    pub fn CreateFontW(
        height: c_int, width: c_int, escapement: c_int, orientation: c_int,
        weight: c_int, italic: DWORD, underline: DWORD, strikeOut: DWORD,
        charSet: DWORD, outputPrecision: DWORD, clipPrecision: DWORD,
        quality: DWORD, pitchAndFamily: DWORD, face: LPCWSTR
    ) -> HFONT;

    pub fn TextOutW(
        hdc: HDC, nXStart: c_int, nYStart: c_int, lpString: LPWSTR, cchString: c_int
    ) -> BOOL;

    pub fn SetTextColor(hdc: HDC, color: COLORREF) -> COLORREF;

    pub fn SetBkColor(hdc: HDC, color: COLORREF) -> COLORREF;
}

HEAP_NO_SERIALIZE            = 0x00000001
HEAP_GENERATE_EXCEPTIONS     = 0x00000004
HEAP_ZERO_MEMORY             = 0x00000008
HEAP_REALLOC_IN_PLACE_ONLY   = 0x00000010
HEAP_CREATE_ENABLE_EXECUTE   = 0x00040000

For use with HeapAlloc and related functions.