Switch from winapi to windows-sys

[CraftSpider]

This is a rebase of #494, as it was mentioned in #537 that there was potential interest in such a thing.

[CraftSpider]

Currently, this avoids actually depending on windows-bindgen at build-time by simply using a file generated with the arguments in bindings.txt. This is similar to how std does it, and avoids issues with as-if-std. While similar to the previous method, this way the windows system APIs are generated entirely by the same system as windows-sys, and are based on the official API metadata.

[ChrisDenton]

If we're using generated bindings then I don't think we need verify-windows-sys. There's no need to hand-write the bindings when we can use the generated bindings directly.

EDIT: never mind, that won't work because windows-bindgen doesn't have a way to generate delay-loaded imports.

[ChrisDenton]

Looks good to me. Just one nit.

[CraftSpider]

If we're using generated bindings then I don't think we need verify-windows-sys. There's no need to hand-write the bindings when we can use the generated bindings directly.

EDIT: never mind, that won't work because windows-bindgen doesn't have a way to generate delay-loaded imports.

It may be a good idea to remove the feature and make the assertion unconditional - it's purely compile-time, and since we are comparing to the auto-generated bindings, we always have access to the original definitions. Either a feature in windows-bindgen to generate type for each function, or access to typeof in Rust, would let us just use the binding types directly, but alas.

[workingjubilee]

Only a pair of nits.

[workingjubilee]

Thanks for rebasing! Finally figured out what busted CI so I'm gonna merge this through finally.

[kleisauke]

FWIW, this breaks the tier-3 thumbv7a-pc-windows-msvc and thumbv7a-uwp-windows-msvc targets. For example, IMAGE_FILE_MACHINE_ARMNT is gone now.

backtrace-rs/src/backtrace/dbghelp32.rs

Line 222 in 38d49aa

IMAGE_FILE_MACHINE_ARMNT

PR rust-lang/rust#112527 could be relevant here.

[workingjubilee]

Tier 3 targets are allowed to be broken. If they weren't, I wouldn't be able to even land this PR. If someone wants them to be supported, they need to start maintaining them. https://doc.rust-lang.org/rustc/target-tier-policy.html

[workingjubilee]

And the appropriate venue for this is not in the tail end of a PR, but a new issue.

[kleisauke]

Sorry, the last time I dealt with a similar issue (see #572) the fix was straightforward, but this is somewhat non-trivial as windows-sys lacks platform-specific type definitions for ARM32.

That said, this is a good opportunity to remove this unsupported Microsoft target from my toolchain. If anyone fancies it, they can fix this, but it won't be me this time.