Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Investigate fallback implementations on Windows XP #26654

Closed
alexcrichton opened this issue Jun 29, 2015 · 15 comments
Closed

Investigate fallback implementations on Windows XP #26654

alexcrichton opened this issue Jun 29, 2015 · 15 comments
Labels
A-concurrency Area: Concurrency C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. O-windows Operating system: Windows T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.

Comments

@alexcrichton
Copy link
Member

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.
@alexcrichton alexcrichton added the O-windows Operating system: Windows label Jun 29, 2015
@MrAlert
Copy link
Contributor

MrAlert commented Jun 30, 2015

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
Copy link
Contributor

MrAlert commented Jun 30, 2015

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
Copy link
Contributor

MrAlert commented Jul 2, 2015

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
Copy link
Contributor

MrAlert commented Jul 8, 2015

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
Copy link
Member

Amanieu commented Jun 24, 2016

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

@briansmith
Copy link
Contributor

#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
Copy link
Member

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
Copy link
Member

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

@retep998 retep998 reopened this May 16, 2017
@Mark-Simulacrum
Copy link
Member

My understanding was that LLVM doesn't support XP as a target platform -- but I'm fine with keeping this open; I don't exactly know what the problems there are. I agree that it'd be great if we could continue to work on XP.

@retep998
Copy link
Member

LLVM requires Windows 7 or newer as a host platform. It is capable of targeting much older than that, although you still have to tell the linker to target an older version as well as limiting your usage of system APIs to those that are available on older Windows.

@techtonik
Copy link

Can LLVM target XP and Vista from Linux?

@retep998
Copy link
Member

@techtonik LLVM's ability to target a specific architecture or operating system is not limited by what host system it is running on. The ability to link the resulting binaries however, does depend on your ability to acquire the appropriate libraries and linker. In the case of targeting Windows from Linux, you'd likely use MinGW for this, which is definitely capable of linking binaries that can run on XP.

@Mark-Simulacrum Mark-Simulacrum added the C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. label Jul 22, 2017
@steveklabnik
Copy link
Member

I've created a thread about considering dropping XP support: https://internals.rust-lang.org/t/consider-dropping-support-for-windows-xp/8745

@techtonik
Copy link

image

@jonas-schievink jonas-schievink added T-libs-api Relevant to the library API team, which will review and decide on the PR/issue. A-concurrency Area: Concurrency labels Mar 13, 2020
@KodrAus KodrAus added the Libs-Tracked Libs issues that are tracked on the team's project board. label Jul 29, 2020
@wesleywiser
Copy link
Member

Closing as Windows XP is no longer supported rust-lang/compiler-team#378

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-concurrency Area: Concurrency C-tracking-issue Category: A tracking issue for an RFC or an unstable feature. Libs-Tracked Libs issues that are tracked on the team's project board. O-windows Operating system: Windows T-libs-api Relevant to the library API team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

12 participants