Currently XP is a "tier 3" platform which, if I've understood, means that nobody is going to intentionally break XP support (even if it would be beneficial to do so) but it's not going to be officially tested either. If for example a rustc or Cargo release happens not to work for XP targets then it's no big deal.
Since April of 2019 there is, to my knowledge, no version of XP still being supported by Microsoft.
Are there plans to officially end XP support, even as a tier 3 platform?
What's the motivation for doing so? Some cleanup?...
A relevant issue: Also it was previously proposed to drop XP support here. Considering that XP support is essentially broken for more than 3 years, I think dropping it is a long overdue. Moreover I believe we need an official policy for dropping OS versions support.
One simplification example: removing XP and Vista support would allow us to use BCryptGenRandom for all Windows targets instead of relying on deprecated RtlGenRandom on non-UWP targets, see this issue.
I asked a while back:
I didn't end up writing an RFC though.
The jump from XP to Vista (and even more so to 7) included some big architectural changes under the hood, which is reflected in a lot of new or enhanced APIs that Rust relies on. Currently Rust has a compatibility layer that's used for some functions that don't exist at all. And there are workarounds for missing features in functions that do exist, e.g. see pipes (which technically introduces a security issue but as it only affects XP nobody was interested in creating and maintaining a fix). I think removing these would be "nice" if nothing else and would signal that official(?) crates like rand can stop worrying about XP as newpavlov mentioned. .
But yeah, all that is somewhat moot as the XP target has been effectively broken for years (although it is still possible to work around or avoid some of the issues).
I think Vista support is "interesting". Windows 7+ is officially supported by Rust and XP support was pushed by people who needed it at the time. I don't think anyone has really made efforts to make Rust compatible with Vista (correct me if I'm wrong) but it's possibly close enough to 7 that Rust has worked regardless (though I haven't tested it).
But Vista was an odd release. It was quickly superseded by 7 and seems to have been skipped over entirely by most large orgs. Its usage share was an order of magnitude below even XP's last I looked.
So I guess a case could be made for "ending" support for Vista whenever XP support ends because it's not entirely clear to me that it was ever supported in the first place.
It should at least be possible to specify a target of Windows 7 or above when building. This would remove the compatibility layer, which has a runtime cost.
With that in mind I think explicitly adding a target for XP would be a good idea. It could just be a copy/paste of the current MSVC target but would provide a way to target XP at compile time. This would at least allow for replacing the runtime compatibility layer with compile time cfg checks. It would also help the wider crates ecosystem (e.g. rand, as mentioned above).
Hmm, should this be an RFC?
I'd personally just send in a PR.
Would all this just affect people using libstd?
If you make a no_std binary, you could still target XP using the normal i686-pc-windows-msvc, right? (or even Win XP 64 with x86_64-pc-windows-msvc hopefully)
Yes. The point of no_std is to be platform independent so it assumes there are no OS APIs available unless you explicitly link them.
For whatever it's worth, when I started an open source project 5 years ago that exclusively targets Windows, we decided to not bother supporting XP to begin with. To this day, we routinely get requests to add support for it. We consistently just recommend that they upgrade their OS for security reasons.
From what types of users do such requests typically originate, and what reasons do they give you when they say why they haven't updated?
So, some context. It’s a plug-in for the MS Office VBA editor. I would say the majority of these users work at small businesses where, for some reason, they’ve never upgraded their computers. A small percentage of users are from 3rd world countries where they’re running on the rest of the world’s hand me downs. The prior isn’t really a concern for Rust in my opinion. Small businesses still running ancient versions of an OS aren’t really the target demographic. The latter is possibly more of a concern. It hurts to tell less fortunate people they can’t use/learn Rust because their equipment is too old.
It is my understanding that the RwLock implementation could also be simplified if we dropped support for XP? Currently this goes through GetProcAddress, which is quite annoying for supporting them in Miri...
Yes. Although as I understand it this may become a moot point when parking_lot takes over mutex duties.
I've been thinking more on this. An issue is that there are at least some people who want XP support (for whatever reason) but there aren't people who feel particularly motivated to support it.
So, as smj389 says, separating Windows XP target from the Windows 7+ target would better reflect this. It may also provide a target to rally round if there are people willing to come forward to offer XP support.
An alternative to having a separate XP target would be to somehow allow users of Rust to set the Windows "platform toolset" / "sdk version" for their project, as they can in a Visual Studio C++ project (this would actually be useful regardless). But note that even in Visual Studio, XP is treated as a special case (and it's currently marked as deprecated). I think Windows changed a lot under the hood from XP to Vista and this is reflected in the dev facing APIs, so considering them different platforms is warranted.
In summary, if the goal is to better support XP then having an XP target helps. On the other hand if XP support is (as now) more or less left to rot then having an XP target will at least keep the rot from affecting or holding back the Win7+ target. If official XP support is to be dropped, then separating it into its own target could be a prelude to that.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.