Custom ffi bindings(?)

1

In a recent conversation with the maintainer of the various windows crates, he suggested migrating off windows-sys and instead generating dedicated bindings with windows-bindgen

Personally, I would prefer to depend on an official MS crate for platform-specific code (and really like the fact that these crates exist[1]); both as a platform-specific-library developer and consumer.

What is your opinion, either as a consumer of downstream crates which need platform-specific bindings or as a developer of such libraries?

  1. Stick with windows-sys - even with slow updates it's official and therefore more trustworthy for an upstream consumer (like 2018 inverse dependents, vs 15 for windows-bindgen)
  2. Generate minimal, specific bindings via an integration test which fails if they change (this is what chrono does)
  3. Have a separate bin crate which can be run to regenerate bindings on demand, store this is the same repo but don't publish (recommendation from windows maintainer)
  4. Generate bindings every time in build.rs (option suggested by windows maintainer for direct binary crates)
  5. Create a second, dedicated win-cdrom-bindings crate, publish and depend on that (risks flooding the ecosystem with loads of similar, slightly-overlapping crates)

  1. Please don't turn this into an MS-bashing session ↩︎

2

Just reading that thread; it seems to me that what he's saying is that there's no good official option right now - windows-sys and windows are going to be replaced as per the plan in the Rust for Windows August 2026 newsletter with better options for libraries (where instead of one huge windows-sys crate, you have a set of logical crates that each bind a logical subset of the Windows API).

Given that you're not planning to wait a few years for Microsoft to do this for the whole Windows API, his recommendation is that you generate the bindings you need in build.rs or as checked-in bindings that you can regenerate with a separate executable that's not published to crates.io so that you can get your project underway today, and later, when Microsoft have official crates for the subsets of the Windows API that you use, you can replace your bindings with the official Microsoft crates.

3

I had completely missed this pending change.

This kind of bums be out a little. If I understand it correctly, their idea is to provide ready-to-use higher-level crates for common APIs. For anything that isn't covered by those ready-to-use crates, people should use windows-bindgen to generate their own wrappers. (.. and all of this is as opposed to using the windows/windows-sys crates).

My personal issue with this is that the times I use the windows-sys and windows crates, I'm usually committing unconventional crimes, that would likely not be covered by existing higher-level crates, so I'd end up needing to use windows-bindgen, which is more complicated than just using windows-sys.

As much as the churn after a semver breaking windows update sometimes drove me insane, I've overall been pretty happy with both windows and windows-sys. (I speak as someone who supports Windows, but doesn't use it as a primary platform).

The one thing that has caused me some issues with windows-sys is the slow adoption of updated versions in some projects. I've ended up a situation where I had two versions of windows-sys in a single project, and both had very different ideas of what a HANDLE's underlying type was, which was annoying because I needed to pass an event semaphore between the two.

With all that said, my general inclination is to do what maintainers recommend, because they probably course-correct for some of their internal plans for the future.

I would probably go with option 3 or 4 (slightly preferring 4, unless it's super slow) but leave the door open for option 5 in the future.

To me, it isn't an issue that a binding crate isn't officially from Microsoft, as long as the API's are somewhat congruent with Microsoft's official crates.

On a slight tangent -- Kenny Kerr's output over the years has been completely bonkers. Does this dude never sleep? I know that win32metadata is doing a lot of the heavy lifting, but even despite that, it's an insane amount of work he has done. It almost makes me sad that I don't do more Windows development in Rust.

4

I went the integration-test approach and it was surprisingly painless.[1]

Most of the work was refactoring my mod win to be in a better shape to incorporate them - which was valuable in its own right and needed doing anyway.

Yes, the guy's work is amazing and so valuable. I was concerned about opening this thread as I didn't want to cast a negative light on him in any way.

  1. results are here if anyone is interested MusicalNinjaDad/redbook ↩︎