detect-targets: Add fallback to windows

[NobodyXu]

Fixed #642

• Add new dep windows-sys v0.42.0 for win only
• Add new dep windows-dll v0.4.1 for win only
• Add x86_64 fallback targets for windows
• Add x86 fallback targets for windows
• Add arm32 fallback targets for windows
• Add arm64 fallback targets for windows
• Add gnu/gnu-llvm fallback targets for windows

Signed-off-by: Jiahao XU [email protected]

[NobodyXu]

The CI has failed silently on windows with no error message or whatever.

The integration CI failed with exit code 127.

[passcod]

Possibly to do with that API's requirement of windows build 22000. Maybe we can test for the build number and only call this if it's >=22000?

[NobodyXu]

Possibly to do with that API's requirement of windows build 22000.

Aha, so it panics instead of returning an error?

Maybe we can test for the build number and only call this if it's >=22000?

How do we test that?

Edit:

I've found GetVersion which is deprecated after windows 8, GetProductInfo which seems to be a replacement for GetVersion, then finally IsWindowsVersionOrGreater.

[NobodyXu]

Possibly to do with that API's requirement of windows build 22000. Maybe we can test for the build number and only call this if it's >=22000?

And that would also means that we cannot test the fallback logic on GHA...

[NobodyXu]

Possibly to do with that API's requirement of windows build 22000. Maybe we can test for the build number and only call this if it's >=22000?

@passcod I added a version check using GetVersionExA, but now the tests failed with exit code: 0xc0000139 in unit test and still failed with exit code 127 in integration test.

[passcod]

hmm, 0xc0000139 is a windows exception for failing to load a dll, so I guess it could be a need to detect even earlier... but I don't really know at this point.

[NobodyXu]

hmm, 0xc0000139 is a windows exception for failing to load a dll, so I guess it could be a need to detect even earlier... but I don't really know at this point.

So basically it's giving out runtime link error because GetMachineTypeAttributes isn't available...
The only option seems to be using a min-size x64 binary, or maybe we can run an external shell command on windows @passcod ?

I thought about using something like dlsym but I don't know that windows counterpart and not sure how to the raw function pointer obtained.

[passcod]

Apparently the proper way to do this is to dynamically load Kernel32.dll with any of LoadLibraryA, LoadLibraryExA, LoadPackagedLibrary, or GetModuleHandleExA (dunno which to prefer, maybe try the last one given kernel is... probably always loaded? idk. Then use GetProcAddress to lookup and check the function exists.

[NobodyXu]

@passcod Thanks, this makes me even more appreciate the separation of libc and syscalls in linux, meaning that for missing syscalls we would simply get a ENOSYS.

[passcod]

Might be simpler to try using delay-loading:

fn main() {
    println!("cargo:rustc-link-arg=/DELAYLOAD:Kernel32.dll");
    println!("cargo:rustc-link-lib=static=delayimp");
}

which if I'm reading some threads correctly means it should error normally (via result) at call time...

[passcod]

welp, nevermind:

Delay loading Kernel32.dll isn't supported. This DLL must be loaded for the delay-load helper routines to work.

[passcod]

windows-dll crate seems to handle the machinery for us, if it's too hard to get working directly. With default-features = false, features = ["windows"] it will also not use the old winapi crate

[NobodyXu]

@passcod Thanks, I would use it to wrap GetMachineTypeAttributes, which I believe is the raw C/C++ symbol for the function.

[NobodyXu]

@passcod I've fixed the code according to your advice, but we can't test the code on the GHA since it's still on windows 10.

If you have a windows 11 build system with cargo installed, can you run the tests locally please?

While I have a windows 11 laptop, it's up for sale so I can't install cargo on it.

[NobodyXu]

@passcod If you are free and have access to a windows machine, can you test this PR please?

[NobodyXu]

It's been stale for a really long time.

[passcod]

Going to do this today!

[passcod]

Well it builds and the standard test suite runs. I wasn't able to run e2e-tests yet because windows is a poopy head. Will try more tomorrow.

[NobodyXu]

Trying to run this on windows 11 gives me:

Windows is such a pain to deal with

[NobodyXu]

This PR has been stale for quite long.
@passcod What should we do with this PR?
Maybe we could just release it and roll it back if it goes seriously wrong?

[NobodyXu]

Or maybe we can just drop it.
Even running cargo-binstall on windows is a pain.

[passcod]

Yeah, let's drop it. Someone who wants to get those can use --target manually, and we've had no feedback that this is a missing feature really.

[NobodyXu]

Trying to run this on windows 11 gives me:

Windows is such a pain to deal with

Just realize that I failed to extract the file and run it directly in file explorer preview like #1099 (comment), so I want to reopen this and reevaluate this.

[NobodyXu]

I successfully run this on my aarch64 windows VM.

It checks for target:

• aarch64-pc-windows-msvc
• aarch64-pc-windows-gnu
• aarch64-pc-windows-gnullvm
• x86_64-pc-windows-msvc
• x86_64-pc-windows-gnu
• x86_64-pc-windows-gnullvm
• i586-pc-windows-msvc
• i586-pc-windows-gnu
• i586-pc-windows-gnullvm
• i686-pc-windows-msvc
• i686-pc-windows-gnu
• i686-pc-windows-gnullvm

It's working as intended and given that the CI also passes, so I guess this is mostly ok-ish.
@passcod can you review this PR and approve this if it looks ok to you?

[passcod]

Yeah let's give it a go. Best test is to put it in front of people, we can always revert if some windows user finds an edge case.