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

std: Add support for Windows XP #26601

Merged
merged 4 commits into from Jun 28, 2015
Merged

std: Add support for Windows XP #26601

merged 4 commits into from Jun 28, 2015

Conversation

@alexcrichton
Copy link
Member

@alexcrichton alexcrichton commented Jun 26, 2015

This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be very difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

  • Support for a new i686-pc-windows-msvc triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
  • All APIs not available on Windows are now accessed through our dynamic-detection mechanism
  • Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@rust-highfive
Copy link
Collaborator

@rust-highfive rust-highfive commented Jun 26, 2015

r? @pcwalton

(rust_highfive has picked a reviewer for you, use r? to override)

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 26, 2015

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 26, 2015

cc #26602, I'd love to have a 32-bit MSVC host triple for the compiler, but that's currently blocked on https://llvm.org/bugs/show_bug.cgi?id=23957.

@eefriedman
Copy link
Contributor

@eefriedman eefriedman commented Jun 26, 2015

We should be able to provide accurately rounded versions of all f32 functions on all platforms; truncating the f64 result isn't correct for transcendental functions or fmodf, even if the Visual Studio C standard library does it.

The Windows SDK apparently emulates SetFileInformationByHandle on XP through a library called FileExtd.lib; might be worth investigating to see if it's usable.

Random question: where I can I find discussion of why is "%" defined as fmodf, as opposed to remainderf?

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 26, 2015

Yeah I do agree that we can probably provide either better fallbacks in many of these scenarios or perhaps even full implementations in the f32 cases. For now, however, I wanted to land the initial support to get everything working initially and then later we can perhaps fill out these kinds of functions on-demand. In general I think that the support for XP will be available, but it won't be a 1st tier platform, so if some bits here and there aren't as fully implemented as they could be it's not the end of the world

@eefriedman
Copy link
Contributor

@eefriedman eefriedman commented Jun 26, 2015

If you want to file followup issues for improving various aspects, that seems fine.

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 26, 2015

Certainly!

@Manishearth
Copy link
Member

@Manishearth Manishearth commented Jun 27, 2015

XP support for Rust...

I'm certain that I've time travelled, just that I'm not sure if this is the future or the past 😛

Great work! 🎊

@barosl
Copy link
Contributor

@barosl barosl commented Jun 27, 2015

Gosh, you made it. I admit I was a bit skeptical to the burden of supporting Windows XP we would have, but it is always great to see the widening of the target audience. Great work as usual, @alexcrichton! 🍰 🍭

@brson
Copy link
Contributor

@brson brson commented Jun 27, 2015

@bors r+

Stunning work.

@bors
Copy link
Contributor

@bors bors commented Jun 27, 2015

📌 Commit 691f60b has been approved by brson

@brson
Copy link
Contributor

@brson brson commented Jun 27, 2015

I don't actually see anything here XP-specific, but rather just 32-bit windows support.

//! so this is just abandoned entirely. Instead the data is stored in a
//! thread-local in `panic` and retrieved during `cleanup`.
//!
//! So given all that, the bindings here are pretty small,
Copy link
Member

@sfackler sfackler Jun 27, 2015

Did this get cut off?

Copy link
Member Author

@alexcrichton alexcrichton Jun 27, 2015

Erm, yes!

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 27, 2015

I don't actually see anything here XP-specific, but rather just 32-bit windows support.

Yeah this was a major part of supporting the XP-ness that Firefox needs I believe, but all the "XP support" is mainly just lazy-binding the set of non-XP APIs and also rewriting sys::Mutex to only use SRWLOCK where available.

bors added a commit that referenced this issue Jun 27, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@bors
Copy link
Contributor

@bors bors commented Jun 27, 2015

Testing commit 691f60b with merge eb73686...

@bors
Copy link
Contributor

@bors bors commented Jun 27, 2015

💔 Test failed - auto-win-gnu-64-opt

This commit modifies the configure script and our makefiles to support building
32-bit MSVC targets. The MSVC toolchain is now parameterized over whether it can
produce a 32-bit or 64-bit binary. The configure script was updated to export
more variables at configure time, and the makefiles were rejiggered to
selectively reexport the relevant environment variables for the applicable
targets they're going to run for.
This commit adds the i686-pc-windows-msvc triple to the compiler's repertoire of
triples to prepare for targeting 32-bit MSVC.
It turns out that the 32-bit toolchain for MSVC has many of these functions as
`static inline` functions in header files so there's not actually a symbol for
Rust to call. All of the implementations just cast floats to their 64-bit
variants and then cast back to 32-bit at the end, so the standard library now
takes this strategy.
@alexcrichton alexcrichton force-pushed the xp branch 2 times, most recently from fe2d99f to ae66ad4 Jun 27, 2015
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 27, 2015

@bors: r=brson ae66ad4

@bors
Copy link
Contributor

@bors bors commented Jun 27, 2015

Testing commit ae66ad4 with merge 229fc48...

bors added a commit that referenced this issue Jun 27, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 28, 2015

@bors: r=brson

On Sat, Jun 27, 2015 at 2:40 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/5478


Reply to this email directly or view it on GitHub
#26601 (comment).

@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

📌 Commit c95272b has been approved by brson

@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

Testing commit c95272b with merge 0216b59...

bors added a commit that referenced this issue Jun 28, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

💔 Test failed - auto-win-gnu-32-nopt-t

@alexcrichton alexcrichton force-pushed the xp branch 2 times, most recently from 1fe8a9b to fad95fc Jun 28, 2015
This commit enables executables linked against the standard library to run on
Windows XP. There are two main components of this commit:

* APIs not available on XP are shimmed to have a fallback implementation and use
  runtime detection to determine if they are available.
* Mutexes on Windows were reimplemented to use critical sections on XP where
  rwlocks are not available.

The APIs which are not available on XP are:

* SetFileInformationByHandle - this is just used by `File::truncate` and that
  function just returns an error now.
* SetThreadStackGuarantee - this is used by the stack overflow support on
  windows, but if this isn't available then it's just ignored (it seems
  non-critical).
* All condition variable APIs are missing - the shims added for these apis
  simply always panic for now. We may eventually provide a fallback
  implementation, but for now the standard library does not rely on condition
  variables for normal use.
* RWLocks, like condition variables, are missing entirely. The same story for
  condition variables is taken here. These APIs are all now panicking stubs as
  the standard library doesn't rely on RWLocks for normal use.

Currently, as an optimization, we use SRWLOCKs for the standard `sync::Mutex`
implementation on Windows, which is indeed required for normal operation of the
standard library. To allow the standard library to run on XP, this commit
reimplements mutexes on Windows to use SRWLOCK instances *if available* and
otherwise a CriticalSection is used (with some checking for recursive
locking).

With all these changes put together, a 32-bit MSVC-built executable can run on
Windows XP and print "hello world"

Closes rust-lang#12842
Closes rust-lang#19992
Closes rust-lang#24776
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 28, 2015

@bors: r=brson

On Sat, Jun 27, 2015 at 7:33 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-win-gnu-32-nopt-t
http://buildbot.rust-lang.org/builders/auto-win-gnu-32-nopt-t/builds/494


Reply to this email directly or view it on GitHub
#26601 (comment).

@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

📌 Commit 10b103a has been approved by brson

bors added a commit that referenced this issue Jun 28, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

Testing commit 10b103a with merge dfd9a1e...

@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

💔 Test failed - auto-win-gnu-64-opt

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 28, 2015

@bors: retry

bors added a commit that referenced this issue Jun 28, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

Testing commit 10b103a with merge 82b3f2e...

@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

💔 Test failed - auto-linux-64-nopt-t

@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Jun 28, 2015

@bors: retry

On Sat, Jun 27, 2015 at 7:52 PM, bors notifications@github.com wrote:

[image: 💔] Test failed - auto-linux-64-nopt-t
http://buildbot.rust-lang.org/builders/auto-linux-64-nopt-t/builds/5483


Reply to this email directly or view it on GitHub
#26601 (comment).

bors added a commit that referenced this issue Jun 28, 2015
This series of commits (currently rebased on #26569 to avoid conflicts) adds support for the standard library to run on Windows XP. The main motivation behind this PR is that to enable any Rust code in Firefox we need to support Windows XP.

This PR doesn't yet intend to be a move to make Windows XP an officially supported platform, but instead simply get Rust code running on it. APIs like condition variables and RWLocks will immediately panic currently on XP, and it's unclear if that story wants to change much. Additionally, we may bind APIs like IOCP which aren't available on XP and would be *very* difficult to provide a fallback implementation. Essentially this PR enables running Rust on XP, but you still have to be careful to avoid non-XP portions of the standard library.

The major components of this PR are:

* Support for a new `i686-pc-windows-msvc` triple. This primarily involves a lot of build system hackery, but there are also a number of floating point functions which had to get switched up a bit.
* All APIs not available on Windows are now accessed through our dynamic-detection mechanism
* Mutexes on Windows were rewritten to use SRWLOCK as an optimization but can fall back to CRITICAL_SECTION.
@bors
Copy link
Contributor

@bors bors commented Jun 28, 2015

Testing commit 10b103a with merge 5da0d41...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

9 participants