Use windows-bindgen to replace windows-sys with generated bindings?

[djc]

windows-sys is a large crate (a 2.4M download) with considerable churn. The windows-rs org also provides a windows-bindgen API that crates can use to generate their own bindings for the part of the API that they need, which trades some downstream complexity for maintenance complexity (although the latter is pretty limited in my experience). See nushell/nu-ansi-term#71 for an example.

Would you be open to something like this for errno? It seems like a good fit to me.

[sunfishcode]

rust-errno here is extremely small, but imagining what this would look like if many more crates did a similar thing, my concern would be that end users would have less visibility and control over what versions of the bindings their dependencies are using.

Imagine there is a security bug in the windows bindings some day. These are unsafe FFI bindings so UB is possible. With windows-sys, then the maintainers would fix it and send notifications, and people can check if they're affected and update, just like any other library. If there are many libraries using windows-bindgen generated bindings, what does the process look like? The example in your link uses a dev-dependency, the windows-bindgen documentation says to use a build-dependency, and perhaps other projects do other things, and the process of figuring out what versions of the bindings one is using looks non-trivial. And once you've identified which dependencies are affected, you have to ask their maintainers to update them before you can update.

I'm curious if anyone has looked into using windows-bindgen to generate general-purpose subsets of windows-sys. Perhaps a subset for "features that correspond to things in libc on Unix". Or "features used by widely-used Rust crates". It seems likely that such a library could be much smaller than windows-sys, and then perhaps could make sense for rust-errno and many other things to depend on.