Support Specifying _NT_TARGET_VERSION in metadata.wdk for driver configuration

[zanpocc]

There are two issues I've identified in the project:
1、The WDK version must be 22621, as the wdk-build script relies on the tools path being located via version. When I installed WDK 22000, it didn't install to C:\Program Files (x86)\Windows Kits\10\Tools\10.0.22000.0. However, version 22621 installed correctly,use winget.

2、The driver uses ExAllocatePool2 for memory allocation. However, when compiling the driver and attempting to run it on lower versions of Windows, it fails because lower versions of the kernel do not export this function. When I load the compiled driver on a 1809 system, it returns "STATUS_DRIVER_ENTRYPOINT_NOT_FOUND". I'm not entirely sure, but I suspect this might be the reason.

[wmmc88]

The logic to detect the WDK is contained here. It should support winget installs, running in an eWDK prompt, and local installs. I believe local installs rely on the WDK installer setting a regkey to the installed kit. If this regkey detection is failing, then it is a bug. Can you check to see if your installation set the relevant reg keys?

Our current support policy is in the readme:

While this crate is written to be flexible with different WDK releases and different WDF version, it is currently only tested for NI eWDK, KMDF 1.33, UMDF 2.33, and WDM Drivers. There may be missing linker options for older DDKs.

and here:

This project was built with support of WDM, KMDF, and UMDF drivers in mind, as well as Win32 Services. This includes support for all versions of WDF included in WDK 22H2 and newer. Currently, the crates available on crates.io only support KMDF v1.33, but bindings can be generated for everything else by cloning windows-drivers-rs and modifying the config specified in build.rs of wdk-sys. Crates.io support for other WDK configurations is planned in the near future.

We would consider PRs that extend support farther back, but do not want to incur extra maintenance burden on this early project (and choose to focus on providing safer rust abstractions). You are also free to roll your own memory allocator (it should be fairly straight forward to).

[zanpocc]

@wmmc88 For the second point, Does it support generating drivers for specific versions of Windows? For example, setting _NT_TARGET_VERSION to Windows 1809 in VS will result in an error for ExAllocatePool2 during compilation.

[wmmc88]

@wmmc88 For the second point, Does it support generating drivers for specific versions of Windows? For example, setting _NT_TARGET_VERSION to Windows 1809 in VS will result in an error for ExAllocatePool2 during compilation.

Currently, if you wanted to tweak the bindings, you would need to make a source modification in the build script of wdk-sys to define _NT_TARGET_VERSION to a non-default value.

With that said, I am very close to having a PR that solves #82, which will bring in a Cargo Metadata based configuration system. This system is planned to support _NT_TARGET_VERSION