Missing APIs in the library

[joaoviictorti]

Hi guys.

I have a question about the library: does it contain all the APIs documented by Microsoft for Windows kernel drivers using Rust? I noticed that I didn't find some APIs in the library, like PsGetCurrentThread and Minifilters. I know that I can make the connection manually and call the function in the code, but I wondered if that was the intention of not having them. I'm thinking of making a Pull Request related to this, but I wanted to clear this doubt first.

[joaoviictorti]

From what I've analyzed, the PsGetCurrentThread API uses the CFORCEINLINE macro. As the library doesn't use the .generate_inline_functions(true) option in the bindgen, the correct bindings are not generated for this API. The bindgen may even generate the bindings, but it ends up not putting #[inline], for example.

I saw some discussions on rust-bindgen GitHub about this issue and I also noticed that someone made a pull request in the windows-driver-rs repository related to problem #51. I still don't know how this pull request is progressing, but the question about the file system filter APIs remains. Anything I can do a pull request on, I look forward to hearing back! 😁

[wmmc88]

does it contain all the APIs documented by Microsoft for Windows kernel drivers using Rust?

Not currently. We are planning on expanding api coverage, grouping headers into functional areas (ex. I have a branch adding all the headers related to HID. I'd consider PRs expanding coverage, but will not review them until after #186 merges. With that said, PsGetCurrentThread is in ntddk.h, which is already included.

From what I've analyzed, the PsGetCurrentThread API uses the CFORCEINLINE macro. As the library doesn't use the .generate_inline_functions(true) option in the bindgen, the correct bindings are not generated for this API. The bindgen may even generate the bindings, but it ends up not putting #[inline], for example.
You're right in that PsGetCurrentThread is not currently generated because it is an inline function. generate_inline_functions doesnt help here because it would have no implementation to link to. The experimental wrap_static_fns may work, but I haven't tested it. For more info: https://rust-lang.github.io/rust-bindgen/faq.html#why-isnt-bindgen-generating-bindings-to-inline-functions.

#51 is largely irrelevant to this issue since that is only for WDF apis

[smichaku]

Now that #186 is merged, what are the guidelines for adding new APIs?

I, for example, need the UDECX API. This API also uses a function table UdecxFunctions, so like for WDF there are no direct bindings. I generalized the call_unsafe_wdf_function_binding_impl macro in wdk-macros in order to support both WDF and UDECX and updated the wdk-sys build to include the relevant USB and UDECX headers. I doubt this is the right way to go especially following the changes introduced by #186... Perhaps such APIs deserve a crate of their own? Or, if we still want them under wdk-sys, can we opt them in/out with crate features?

[shujaatak]

Ah Minifilters!