Today it can be a little hard to manage your dependencies when windows-bindgen introduces dependencies in generated code. Although --no-deps is useful for raw or sys-style bindings to limit or eliminate dependencies, it is not so easy to limit or eliminate dependencies for the default richer bindings generated by windows-bindgen and required for more convenient access to COM and WinRT APIs.

This update does two things:

1. Improve consistency and convenience by default when windows-core is required to avoid a growing set of dependencies by using windows-core uniformly for most dependencies where feasible.

2. Allow for more granular and specific dependency targeting and avoid the windows-core dependency unless required with the new --specific-deps option.

Let's say for example you generate bindings for the IsCharLowerA function

windows_bindgen::bindgen([
    "--out",
    "src/bindings.rs",
    "--filter",
    "IsCharLowerA",
    "--flat",
])
.unwrap();

Today the resulting bindings look something like this:

// before
#[inline]
pub unsafe fn IsCharLowerA(ch: i8) -> windows_core::Result<()> {
    windows_link::link!("user32.dll" "system" fn IsCharLowerA(ch : i8) -> windows_core::BOOL);
    unsafe { IsCharLowerA(ch).ok() }
}

Here you'll need to add dependencies for both the windows-core and windows-link crates.

Following this change, the generated bindings will use windows-core exclusively to avoid the need for the extra explicit dependency:

// after
#[inline]
pub unsafe fn IsCharLowerA(ch: i8) -> windows_core::Result<()> {
    windows_core::link!("user32.dll" "system" fn IsCharLowerA(ch : i8) -> windows_core::BOOL);
    unsafe { IsCharLowerA(ch).ok() }
}

As you can see, only the windows-core crate is assumed by the generated bindings. Note that this is merely a convenience to simplify dependency and version management. You will still get a dependency on the windows-link crate in both cases. You just don't need to manage this dependency yourself in the latter case.

On the other hand, you may want to avoid a dependency on the windows-core crate entirely because it is non-trivial and only really required for COM support. In such cases, you can opt in to manage your dependencies more directly with the new --specific-deps option that will instruct windows-bindgen to use the most specific crate dependencies where feasible.

Take for example the WindowsStringHasEmbeddedNull function. As before, this would previously require a dependency on both the windows-core and windows-link crates:

// before
#[inline]
pub unsafe fn WindowsStringHasEmbeddedNull(
    string: &windows_core::HSTRING,
) -> windows_core::Result<windows_core::BOOL> {
    windows_link::link!(<bla bla bla>);
    unsafe {
        let mut result__ = core::mem::zeroed();
        WindowsStringHasEmbeddedNull(core::mem::transmute_copy(string), &mut result__)
            .map(|| result__)
    }
}

Following this change, it will by default only require the windows-core crate:

// after (default)
#[inline]
pub unsafe fn WindowsStringHasEmbeddedNull(
    string: &windows_core::HSTRING,
) -> windows_core::Result<windows_core::BOOL> {
    windows_core::link!(<bla bla bla>);
    unsafe {
        let mut result__ = core::mem::zeroed();
        WindowsStringHasEmbeddedNull(core::mem::transmute_copy(string), &mut result__)
            .map(|| result__)
    }
}

To avoid a dependency on the windows-core crate entirely and instead target the specific - and much smaller - crates directly you only need to add the new --specific-deps option to produce the following:

// --specific-deps
#[inline]
pub unsafe fn WindowsStringHasEmbeddedNull(
    string: &windows_strings::HSTRING,
) -> windows_result::Result<windows_result::BOOL> {
    windows_link::link!(<bla bla bla>);
    unsafe {
        let mut result__ = core::mem::zeroed();
        WindowsStringHasEmbeddedNull(core::mem::transmute_copy(string), &mut result__)
            .map(|| result__)
    }
}

As you can see, the bindings now directly reference the windows-strings, windows-result, and windows-link crates. This option is not the default because this level of control is not for everyone but if that's you then enjoy!