Investigate fallback implementations on Windows XP

[alexcrichton]

Right now we have a large list of APIs we're using on Windows which aren't available on XP. The fallback implementations range from "call SetLastError" to "panic when called". There are likely at least somewhat compatible fallbacks in each situation that can be used:

• Condition variables can likely be implemented on top of some other system primitive.
• RwLock can be implemented on top of condition variables and mutexes
• Various fs syscalls can likely have some form of a fallback.

[MrAlert]

I'm looking into implementing SRWLocks and condition variables in a similar way to their actual implementation in Vista+ (atomics and keyed events.) Keyed events are undocumented and don't perform as well under XP as they do under Vista+, but for compatibility code, I think it would be sufficient.

[MrAlert]

Since the TryAcquireSRWLock* functions are unavailable in Vista, but SRWLocks are otherwise available, I'm thinking we should also split the compatibility fallbacks into groups where all the fallbacks will be used if ANY of the functions are unavailable, since the compatibility implementations of TryAcquireSRWLock* are unlikely to be compatible with the real thing.

[MrAlert]

Got a work in progress for SRWLocks and condition variables at MrAlert/rust@dbf7ca0. Most of the related tests seem to pass under XP except for sync::condvar::tests::wait_timeout_with. Don't have the fallback grouping stuff yet though, so this'll cause problems under Vista.

[MrAlert]

Updated WIP at MrAlert/rust@0841300. Added fallback groups, and removed branches on calls to compatibility functions by initializing the function pointers to point to loader stubs instead of NULL. Should perform roughly as well as regular DLL calls now (if it didn't already.)

I also tested the fallbacks under Windows 7, and for whatever reason sync::condvar::tests::wait_timeout_with still fails, even after I fixed the return values on SleepConditionVariableSRW. Everything else passes, however.

When using the executable from make check-stage1-std, thread::local::tests::dtors_in_dtors_in_dtors hangs under Windows XP, but using the stage2 test executable, it runs fine. Probably has to do with TLS callback stuff failing to work on a dynamically-linked libstd on XP for some reason.

libstd tests that currently fail in XP include: env::tests::test_env_set_var, fs::tests::truncate_works, all tests in net::tcp and net::udp, and sync::condvar::tests::wait_timeout_with.

[Amanieu]

The parking_lot crate provides implementations of Mutex, Condvar, RwLock and Once that works on Windows XP.

[briansmith]

#37638 proposes to provide a way to detect if XP compatibility is even wanted. It would be great if libstd could use a mechanism like that so that XP fallbacks are only provided when XP is actually being targetted. This would eliminate the additional runtime overhead of selecting different implementations based on the Windows version.

[Mark-Simulacrum]

I believe that LLVM no longer supports Windows XP, so arguably while work on our side within our libraries would be a slight quality of life improvement, it is not going to change the unsupportedness of XP. If we're interested in individual improvements, please ask on internals.rust-lang.org or by filing an issue here and we can go forward from there.

[retep998]

This issue is for tracking XP compatibility for binaries produced by rustc, not rustc itself. Therefore this should remain open.