Add explicit XP targets #66801
Add explicit XP targets #66801
Conversation
|
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @varkor (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
|
@ChrisDenton Windows XP compatible compilation need to properly specify the /subsystem property to the linker.
Here's the ms document for these: Extra notes: MINGW GNU flavor linker syntax is "--subsystem which:major.minor", changing the comma to a semicolon. |
|
Thanks. My thinking was to provide these targets as a baseline to be improved if there is an appetite for it. Windows XP is already considered a "tier 3" platform using However, I'll attempt the changes. On my first attempt I missed your note about MINGW so I'll need to rethink that commit. |
|
Hopefully this commit is more robust. There's basically two parts to it. It adds an optional pub struct WindowsSubsystem {
pub name: String,
pub version: Option<String>
}The part that may be more iffy is where I override Windows XP targets to set the subsystem version. |
|
What's the problem with the dynamic fallbacks as they exist now? I now care not even about XP/Vista, but about ReactOS, which may lack some newer APIs without matching a specific version of Windows precisely, thus probably requiring dynamic fallbacks. |
|
I think the split is mainly trying to reflect
I don't really know the current status of ReactOS, but I think at least ReactOS can use tier-3 xp target when the issues above are solved. |
|
Incidentally when More broadly I agree with crlf0710 that splitting the targets reflects the actual split between a tier-1 Windows 7+ target and tier-3 (to be generous) XP target that currently exists in practice. Having them tied together unnecessarily complicates supporting both. Note that the XP "fallbacks" don't do anything useful other than prevent some linking errors. You just get unexpected failures at runtime if you happen to use a libstd function that calls the API. |
|
MinGW support isn't that easy because winpthread library could be compiled targetting newer systems (MSYS2 mingw-w64 targets Windows 7 for an example, see msys2/MSYS2-packages#1784). |
|
There's also the wider discussion of how to handle targeting specific versions of an OS in general. There are plenty of features added in many versions of Windows that crates would like to know whether they can rely on or have to support dynamic fallback for. |
|
@retep998 yeah, I'm trying to avoid over complicating this particular PR because I think that's a bigger issue and there is still value in treating XP as a separate platform even if it's solved. Visual Studio treats XP somewhat specially (and btw, marks it deprecated now) so this is not without precedent. For what it's worth I did consider adding something like a
But this would be a major change and would probably need a lot more discussion. And I'm still getting to grips with the moving parts of Rust's build system. |
|
I can personally review the technical implementation details here, but I would not be comfortable being a sole person signing off on inclusion of these targets. This is pretty different from all our other targets since we don't really have all that many targets which are the same except for OS version. @joshtriplett with your recent work on tiers and such, would you be able to help out in reviewing the addition of these two targets? (in concept, not in terms of the technical details) |
|
That sounds fair. My argument would be that we do already have a separate UWP target so it's not unprecedented. And the current pc-windows-msvc targets are the only ones to my knowledge that target both Tier 1 and Tier 3 OSes. I think a new target would be the least invasive option if/when XP is dropped completely from official support. That said another option would be to make new more generic platform version information available from some kind of config option. XP would need to be special cased though, as it is in VS. |
|
@alexcrichton This seems entirely reasonable to me in principle, and the code changes look reasonable as well. Firefox no longer supports Windows XP, and I don't know of any other projects still attempting to support XP, so splitting this out and declaring it a tier 3 target seems like a reasonable step. I do wonder where the dividing line should be; I've seen proposals to put Vista support in this bucket as well, which seems similarly reasonable as Vista has also been EOLed and no longer has security support. I do not want to derail this, but as a side note, I'd also love to see a "Windows 10 and newer only" target, which could then make many more assumptions about available APIs and capabilities, especially when it comes to POSIX compatibility. But let's not let that distract from the proposal to separate out XP support. |
|
I do think we should at least think about how this would be part of a future world where we have multiple targets for different minimum Windows versions. What sort of naming convention would we follow and what would vista+ or 7+ or 10+ targets be called? |
|
Future marketing strategy is impossible to predict, but if you want a consistent naming, maybe something like this https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions :
With that said, maybe it makes no sense to add any of these to the "default" windows target, maybe add one of these tags when such a target falls off tier 1 level, i think |
|
IMHO, I don't think Rust has ever officially supported Vista (even if it worked)? Windows 7+ is supported and I think the Firefox people were the main advocates for limited XP support but there was no Vista policy. In any case, I feel that Vista+ versions of Windows are similar enough that new targets for each would not be necessary. But yes, I think this is a long standing important issue but drifting off the topic of this PR. My preference would, as I briefly hinted at above, be to have some kind cfg value that holds the Windows SDK version being targetted. So something like Maybe this should be a new issue or forum discussion? |
|
AFAIK we do not have precedent for different targets for different OS versions. We do have different targets for different runtimes/libc implementations (e.g. gnu/musl, msvc/gnu, msvc/uwp, etc), and it's not like we can't have different implementations for different versions of an OS, we just haven't really had a need come up since we've always dealt with it in code and that's been a satisfactory solution for the time beign. That's just some thoughts though, I'd prefer to defer to a consensus of a group that we should add these targets. |
|
That's fair, I'm not arguing against reaching a consensus whatever the outcome. I'm just clumsily trying to make my reasons clear. Which I've done, so I'll wait to see what decision is made. |
|
So the Rust team is in favor of <rust-lang/rfcs#2837>. We could have the same consensus |
|
The manufacturer situation is similar: Apple removed 32 bit support in Xcode 10, while MS removed XP support in VS 2019. So one would similarly require CI providers to keep support for VS 2017. But there is still a significant user base running on XP. According to netmarketshare it's 2.29% of the Desktop pie, more than Linux or semi-old Mac OS versions.
Furthermore, even if XP had lower market share, it's still running on countless legacy systems around the world. Those systems are in our power plants, MRI scanners, manufacturing machines, aircraft carriers, etc. Maybe not all of those systems are being served updates, but I guess some are. It would be sad if you couldn't put Rust there. Apple hardware on the other hand isn't really deployed in those places that require long-term support. |
|
The proposal is to separate XP support, not to immediately drop that support. |
|
Yes a separate XP target wouldn't remove XP support. In fact it may even improve it, especially if someone were willing to actively maintain it. At the minute you have to go through a bit of effort to produce even a hello world app that runs on XP. Btw, since April 9, 2019 there is no version of XP that's supported by MS, even for paying customers. This does make supporting it harder. However, if there are still people willing to patch up Rust for XP then having a target to focus their contributions on can only help. |
|
@joshtriplett I was replying to @luzato and interpreting "same consensus" as eventual removal of the XP target (the RFC is very much in that direction even though it doesn't remove the support fully yet). I'm not in favour of XP removal, at least not at this point. A separate XP target is a good idea. |
|
☔ The latest upstream changes (presumably #67540) made this pull request unmergeable. Please resolve the merge conflicts. |
Adds explicit targets for Windows XP.
XP requires an older subsystem to be used than is the default.
This reverts commit 3f8c0da415824be941292981ea40f115a94f0d97.
XP requires an older subsystem to be used than is the default. To support this, an optional version parameter has been added to the Linker `subsystem` function and a WindowsSubsystem struct to CodegenResults.
|
I think the best way forward here is to start a fcp, and proceed when consensus is reached? What do you think? @pietroalbini who started the fcp in rfc2837 cc @rust-lang/release @rust-lang/compiler |
|
I'll defer what to do here to @alexcrichton. |
|
I'm not prepared, nor can I at this time, lead a proposal to add this target to the compiler. The building of consensus, or the discussion of how to build consensus, about adding XP targets to the compiler will need to be led by someone else. I believe such consensus, however, is the next step here. |
|
While I am in favor of being able to distinguish building for different versions of Windows, I don't think that overloading the target vendor for that is the correct way to do it. I am neutral on whether it should be a new target or another mechanism, but whatever it is, it should be flexible enough that we can easily extend it to any version of Windows. Also whatever we end up doing, it should allow the user to write code that does "Am I targeting at least Windows XP" and not "Am I targeting exactly Windows XP". Having a cfg on |
|
Yeah, I'm not suggesting this as a general solution to targetting Windows versions. I have some thoughts on that and I think Vista+ will be well suited to using whatever mechanism that ends up being. However I think we do need something that says "Am I targetting exactly XP" because compiling for XP is so different, quite apart from available APIs etc (and even there there can be subtle incompatibilities). Ideally XP needs a particular msvc toolset as well as the linker options and more. This PR currently does the bare minimum just to get something that will sort of run. assuming panics aren't used and you avoid other pitfalls. If, hypothetically, XP were a tier one target I'm not sure how it could be fully supported with "Am I targeting at least Windows XP" alone. In short, I think XP is sufficiently special to warrant special treatment in some way, even if not using |
|
Handling XP specific toolchain stuff can be done by checking |
|
Right, but my point is there is a need to target XP specifically (in whatever way) and more importantly that it needs to be checked in a different situation to Win 7+, simply to compile a working binary. I feel like I'm not explaining myself very well so I'll take the example of how Microsoft Visual C++ does it. To make a new C++ Windows 7+ application in Visual Studio 2019 all you have to do is create a new project and build it. You don't need to do anything particularly special, aside perhaps making sure you call the right OS functions in the right way (this is where versionhelper macros can sometimes be useful). However, to make a new C++ Windows XP application you first need to install the VS 2017 XP toolset.
Then you have to go to your project and change it to use that specially modified toolset.
This sets necessary options as well as linking older platform libraries, So with Windows 7+ the build environment remains the same across Windows versions. Changes are optional and for the most part confined to how the application calls system functions. With Windows XP (unlike 7SP1, 8.1, 10) you need a different build environment. Could Rust use a I'm not insisting that Windows XP needs to be an explicit target, but I am saying it needs to be built differently than all the versions of Windows that come after it. |
|
Thinking about it, one alternative might be to mirror Visual Studio more closely. Rust could have a |
|
Having discussed this with nagisa, I don't think there's a way forward with this PR in its current form. There are alternatives, such as adding an optional version parameter to the Some of the linker interface code in this PR could be reused in other proposals but those will need discussions of their own. So I think this should be closed. |
Windows XP support in Rust can generously be described as anaemic (if not outright broken) and yet the fully supported Windows 7+ target is partially reliant on maintaining some compatibility with XP (e.g. the runtime compatibility layer in libstd). So this PR adds two target triples for XP, allowing 32-bit and 64-bit Windows XP to be targetted separately from Windows 7+. For now the targets are literally a copy/paste of the current i686-pc-windows-msvc and x86_64-pc-windows-msvc, though this could be improved if someone is willing to tackle XP support more thoroughly.
I think this is advantageous whatever the future of XP in Rust. If support is dropped completely then this could potentially provide a more graceful transition before removing it. However if anybody is willing to maintain an XP target then having an explicit triple can only help. And even if XP support remains, as it is now, in a kind of limbo then at least crates will be able to target XP separately from Windows 7+ (although unsurprisingly most crates ignore XP support entirely).
In any case allowing the pc-windows targets to be focused on Windows7+ support would be an advantage.