Consider using `windows-bindgen` for Windows API definitions

[ChrisDenton]

Currently ring directly uses only a single function from the Windows API:

ring/src/cpu/aarch64/windows.rs

Lines 16 to 18 in 6f6e654

	use windows_sys::Win32::System::Threading::{
	IsProcessorFeaturePresent, PF_ARM_V8_CRYPTO_INSTRUCTIONS_AVAILABLE,
	};

The windows-sys crate is very large so depending on it for a single function is unfortunate. It also typically has a major release each year which means they'll often be multiple versions in a dependency tree.

An alternative to this is to use the windows-bindgen crate to generate the API definitions to a file in the src/ tree that can be committed and used like any other module. This generated code can then be audited as part of the ring crate.

[briansmith]

It also typically has a major release each year which means they'll often be multiple versions in a dependency tree.

I guess this is the biggest part of the problem? I made a PR at #2568 to update to 0.60.

Personally I'm not a fan of duplicating the effort of windows-sys on a function-by-function basis in every crate that uses Windows APIs. It is very hard to audit crates that use windows-bindgen because they rarely have automation for regenerating the bindings. Consequently I usually advise people to avoid it whenever practical.

[briansmith]

Also, from the windows-rs PR for the new release:

The windows-bindgen crate receives an update to correctly generate the link macros using the appropriate calling convention as per microsoft/windows-rs#3622. This is a major update since generated code may change.

So, even if we, at one point in time, were happy with the generated code, later the generated code might become "bad", necessitating re-review of everything that used windows-bindgen, which is hard to do correctly for the aforementioned reason.

[briansmith]

Another option is to just use std::arch:: is_aarch64_feature_detected on this target, given that I don't think no_std support is useful for aarch64-pc-windows-msvc.

[briansmith]

Another option is to just use std::arch:: is_aarch64_feature_detected on this target, given that I don't think no_std support is useful for aarch64-pc-windows-msvc.

This is PR #2570

[briansmith]

Closing this in favor of the aforementioned PRs, one of which has already been merged.