Choose between windows-rs and this crate

[HoShiMin]

Hi! Thanks for your awesome work, but I have a question: windows-rs has bindings for WDK based on wdkmetadata, your crate uses bindgen. So... which crate should I use for a long-term project? Which crate is "official" WDK port that Microsoft recommends to use for drivers? And which approach is better (wdkmetadata vs bindgen) in terms of accuracy and completeness?

[ghost]

I am not sure why it's not integrated. However, a great job they have done. Thank you Microsoft Team. I look forward to more development in this area and windows-rs.

[wmmc88]

Hello! Yes, both windows-rs and windows-drivers-rs have some overlap in the bindings that get generated, however the two projects have different goals:

windows-rs provides generated API bindings akin to the Windows SDK and WDK. It aims to provide complete API coverage for Windows. It has comprehensive coverage of user-mode APIs and an early preview of some kernel-mode APIs. It does not generally provide any handwritten wrappers.

windows-drivers-rs provides libraries for driver development. It focuses on those APIs needed for driver development, and also providing any required build support in order to do windows driver development in Rust. This includes being able to dynamically change the binding generation to meet the desired WDK configuration. Although what is open-sourced currentlly in windows-drivers-rs mainly consists of these dynamically configurable bindings (wdk-sys) and relevant build/configuration support(wdk-build), one of our main focus going forward will be writing idiomatic Rust wrappers around the FFI bindings in the wdk crate.

[HoShiMin]

Aham, got it, thanks for explanation! But I still have questions:

• The first is about usecases for windows-rs and for windows-drivers-rs. Is it correct that if I want to use raw APIs (like windows-sys for usermode apps) - I shall use windows-rs (WDK part I mean); but if I need wrappers (like windows-rs wrappers for usermode) - I shall use windows-drivers-rs?
• The second one is about differences in approaches (bindgen vs wdkmetadata)? I mean, why do you use bindgen instead of wdkmetadata if it was envolved exactly for WDK bindings? Is the problem with wdkmetadata in versioning and targeting of the driver (e.g., we could use WDK10 or WDK11 of different revisions with bindgen, but we can't do it with wdkmetadata)?
• And the third one is about support of these crates. I mean, which of these will use Microsoft to develop its own drivers in the future and which should we use for production-ready kernel components (of course, when they will be ready for production use). Or, maybe, there is (are?) another closed implementations developed by different teams that will be published later as official bindings? In other terms, if I want to develop a kernel driver now - what should I choose to be sure that the chosen framework will not be abandoned or deprecated?

[wmmc88]

The first is about usecases for windows-rs and for windows-drivers-rs. Is it correct that if I want to use raw APIs (like windows-sys for usermode apps) - I shall use windows-rs (WDK part I mean); but if I need wrappers (like windows-rs wrappers for usermode) - I shall use windows-drivers-rs?

If you are using the raw apis for driver development, it is the opinion of the windows-drivers-rs team that it is best to use wdk-sys as our project is specifically targeting driver development scenarios. Its worth emphasizing though that right now both windows-rs (for wdk metadata) and windows-drivers-rs are very early projects, so all the standard warnings for early projects apply (ex. higher frequency of (possibly breaking) changes). In terms of wrappers, yes, windows-drivers-rs will have wrappers in the wdk crate, but as of right now there are not many available yet.

The second one is about differences in approaches (bindgen vs wdkmetadata)? I mean, why do you use bindgen instead of wdkmetadata if it was envolved exactly for WDK bindings? Is the problem with wdkmetadata in versioning and targeting of the driver (e.g., we could use WDK10 or WDK11 of different revisions with bindgen, but we can't do it with wdkmetadata)?

Yes you're spot on. The wdk metadata project currently has some limitations that directly affect driver developers. One example of this is not being able to generate based off of different wdk configurations (ex. driver type, target os version, WDK version, etc). That is why we went the bindgen route. Our main goal is to eventually have idiomatic Rust APIs, and we need raw bindings to start. Its possible that in the far far future, we swap the raw bindings used in our wrappers from bindgen to metadata, but as it stands today, metadata isn't ready for that.

Another major limitation of the metadata-based project is that they have no utilities to call inline functions (which includes all of WDF). In windows-drivers-rs, since our focus is driver development, we have provided a macro that helps developers emulate what the WDF inline functions do. Example usage of this macro is available here and expands to this code that interacts with the generated WDF function table bindings.

In other terms, if I want to develop a kernel driver now - what should I choose to be sure that the chosen framework will not be abandoned or deprecated?

If you are trying to develop a kernel driver in Rust right now, the advice of the windows-drivers-rs team is that neither are ready for widespread production use. With that said, windows-drivers-rs is being primarily being developed by driver developers within Surface, with the express purpose of ultimately incorporating Rust into our own drivers for Surface products.