Stream: t-compiler/major changes

Topic: Drop official support for Windows XP compiler-team#378


triagebot (Oct 27 2020 at 20:20, on Zulip):

A new proposal has been announced: Drop official support for Windows XP #378. It will be announced at the next meeting to try and draw attention to it, but usually MCPs are not discussed during triage meetings. If you think this would benefit from discussion amongst the team, consider proposing a design meeting.

Chris Denton (Oct 27 2020 at 20:46, on Zulip):

I've been informed that T-infra and T-release should also be made aware of this proposal but I'm not sure how to do that.

cuviper (Oct 27 2020 at 22:53, on Zulip):

I guess we can tag the groups, @T-infra and @T-release

Arlie Davis (Oct 27 2020 at 22:55, on Zulip):

From Microsoft's perspective, we're fairly eager to see XP (and even Vista) support dropped. Establishing Win7 as the baseline for Tier 1 is reasonable, because it is still widely used, and because much of the runtime support that is needed for modern platforms is present in Win7. Such as much better concurrency primitives, etc.

simulacrum (Oct 27 2020 at 23:03, on Zulip):

@Arlie Davis can you say more about "eager"? Is there some reason beyond simplifying code and ease of maintenance to do so? (Mostly just curious)

Jonas Schievink (Oct 27 2020 at 23:04, on Zulip):

+1 to dropping XP from the regular Windows targets if it simplifies things

Arlie Davis (Oct 27 2020 at 23:06, on Zulip):

Ease of maintenance / servicing is 100% of it. If the WinXP exists, it should work. That means supporting VMs for CI pipelines, possibly shipping hotfixes for it, etc. None of which we want to do, because XP is well past its support lifetime.

So if it isn't tested and supported, it shouldn't exist. Because if it does exist, someone will use it, and then we'll be in the awful position of someone relying on something that has no support plan.

Arlie Davis (Oct 27 2020 at 23:08, on Zulip):

Also, we pay a cost on current platforms for this. The dynamic branches, GetProcAddress, etc. calls have a real cost, for doing the delayed import binding. We would like to see those removed, and replaced with direct calls to these APIs.

Just a few days ago, I was debugging a lab failure for Rust code running on Windows. The root cause was that the variant of Windows being tested in the lab does not have a kernel32.dll. That code lives in kernelbase.dll, and kernel32.dll is only the legacy name for it. But because the Rust compatibility code in compat.rs has a hardcoded string of "kernel32.dll" in it, that code failed in the lab. I would like those kind of dynamic failure modes removed entirely, when possible.

Josh Triplett (Oct 28 2020 at 08:05, on Zulip):

The target tier policy RFC has a process for this.

Josh Triplett (Oct 28 2020 at 08:05, on Zulip):
Note that in some cases, based on the usage of existing targets within the
    Rust community, Rust developers or a target's maintainers may wish to
    modify the baseline expectations of a target, or split an existing target
    into multiple targets with different baseline expectations. A proposal to
    do so will be treated similarly to the analogous promotion, demotion, or
    removal of a target, according to this policy, with the same team approvals
    required.
    - For instance, if an OS version has become obsolete and unsupported, a
      target for that OS may raise its baseline expectations for OS version
      (treated as though removing a target corresponding to the older
      versions), or a target for that OS may split out support for older OS
      versions into a lower-tier target (treated as though demoting a target
      corresponding to the older versions, and requiring justification for a
      new target at a lower tier for the older OS versions).
Josh Triplett (Oct 28 2020 at 08:07, on Zulip):

Effectively, dropping support for XP would be equivalent to splitting the target and dropping one of the resulting targets.

Chris Denton (Oct 28 2020 at 08:13, on Zulip):

Aye this was shown to me but it was unclear what to me what "dropping one of the resulting targets means". The policy says the process for dropping a tier 3 target involves creating a PR to remove it:

If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.

But untangling the XP workarounds and compatibility layer is a major job that probably shouldn't be done in one PR. And certainly would be a lot of work to do before the fate of XP was even decided. So an MCP was suggested to me.

Wesley Wiser (Oct 28 2020 at 14:56, on Zulip):

I would like to see this move forward. Should we FCP this with the T-compiler, T-infra and T-release teams instead of using the "second" process?

simulacrum (Oct 28 2020 at 15:04, on Zulip):

I think that's the right step.

Wesley Wiser (Oct 28 2020 at 15:20, on Zulip):

Will rustbot fcp merge do the right thing in the compiler-team repo if I create the T-infra and T-release labels?

Arlie Davis (Oct 28 2020 at 16:13, on Zulip):

Related to this process, we (Microsoft) want to raise the possibility of creating separate Rust target triples for Win10 vs. downlevel. Win10 has different API stability guarantees ("evergreen", generally), but there are necessary differences between Win10 and { Win7, Win8.x }. Many of those differences are not relevant to libcore or libstd, and so are likely irrelevant. However, concurrency control, NUMA, and runtime security features (like Control Flow Guard) will have an impact on libcore / libstd.

Being able to represent these differences as targets makes a lot of sense. We can get the advantages of Win10, while still supporting downlevel operating systems. And it fits fairly naturally within Rust's tooling.

I'm not asking to conflate that with deprecating and removing WinXP support. However, I am curious to know what the community opinion is, and how to advance this process, if there is rough consensus that it's desirable. I've never pushed any change through the Rust RFC / MCP process.

Chris Denton (Oct 28 2020 at 16:39, on Zulip):

@Arlie Davis This has been desired in one form or another for awhile. For example, there was pre-RFC for target_api_version. This would be a compile time configuration option rather than new targets (I'm not sure what the pro/cons of this are). But I don't think it's been formally put forward yet. There are other ideas floating around but I'm not aware of anything that's concrete.

I think the normal procedure is to start with posting ideas to https://internals.rust-lang.org/ and asking for general feedback and where to go next.

As you say, I am nervous about conflating this with Windows XP support. My nightmare is that talk of dropping XP yet again ends up fizzling out without anything being decided. Whatever happens with future targets, I think dropping XP support is worthwhile, at least until someone steps up to maintain it. And even in that case I think it should be separate from official Windows support so that Tier 1 targets aren't having to tip toe around a Tier 3 target.

simulacrum (Oct 28 2020 at 16:40, on Zulip):

Wesley Wiser said:

Will rustbot fcp merge do the right thing in the compiler-team repo if I create the T-infra and T-release labels?

I expect it to, yeah

simulacrum (Oct 28 2020 at 16:40, on Zulip):

You need to also tag with T-compiler

Arlie Davis (Oct 28 2020 at 16:46, on Zulip):

@Chris Denton Agreed on all. Let's get the Tier 1 platform raised to Win7, then remove the use of late-binding in std in a separate PR, and call it a day, on this front. It sounds like there's consensus on just this part, although we certainly need to get buy-in from more of the community. Then, separately, deal with target SDK levels or whatever we want to call them.

Wesley Wiser (Oct 28 2020 at 16:50, on Zulip):

@simulacrum Thanks! That worked.

Mara (Oct 28 2020 at 19:12, on Zulip):

Arlie Davis said:

Let's get the Tier 1 platform raised to Win7, then remove the use of late-binding in std

There's also some Windows 8+ APIs that std doesn't use right now, but might be used in the future for optimized synchronization primitives (like those of parking_lot): WaitOnAddress and WakeByAddress*. So those would still need late binding. (Or there needs to be a separate target for Win8+.)

Arlie Davis (Oct 29 2020 at 04:42, on Zulip):

@Mara Certainly, agreed. My own preference would be that Rust would have two targets for Windows: "Downlevel" and "Win10". Win10 would be able to use APIs like WaitOnAddress directly, without late-binding, while Downlevel would be at the opposite end of the spectrum. Downlevel would run on Win7 or anything later, using late-binding where necessary.

Arlie Davis (Oct 29 2020 at 04:45, on Zulip):

There's also another, somewhat-related issue, which is moving Rust to use the "Universal CRT", rather than the "Legacy CRT", on Windows. The Universal CRT has a lot of advantages for portability and serviceability. My team handles Windows' requirements for the UCRT for C/C++, and I'm looking into what the best relationship is between Rust and the UCRT.

It's fairly clear that, if we do have a Win10 Rust target, that having it target the UCRT is probably the best thing to do. It also _might_ be the best thing for Downlevel, but I'm not certain of that yet.

Peter Rabbit (Oct 29 2020 at 07:22, on Zulip):

I certainly would love to see more progress towards target_api_version, and then we can provide a full depth of targets instead of just Win10 vs Win7.

Josh Triplett (Oct 30 2020 at 15:59, on Zulip):

@Arlie Davis I would love to see Rust using the UCRT.

Josh Triplett (Oct 30 2020 at 16:00, on Zulip):

@Arlie Davis As a step towards several of these improvements, might your team have time to work on the implementation for raw-dylib?

mati865 (Oct 30 2020 at 16:00, on Zulip):

Doesn't windows-msvc target already use UCRT?

Josh Triplett (Oct 30 2020 at 16:01, on Zulip):

@Arlie Davis https://github.com/rust-lang/rust/issues/58713

Arlie Davis (Oct 30 2020 at 22:22, on Zulip):

At Microsoft, we have to deal with a _lot_ of different components, and some of them do not have the option of using the UCRT. I want to make sure that Rust can still be used when linked into those components. It ain't much, but it's honest work.

Arlie Davis (Oct 30 2020 at 22:23, on Zulip):

@Josh Triplett About raw-dylib, could you tell me a bit more about what the issue it? It sounds like the kind of work that my team should definitely at least understand, and quite possibly sign up to do.

Diggory Blake (Oct 30 2020 at 22:29, on Zulip):

@Arlie Davis The RFC linked from the issue should have all the information

Arlie Davis (Oct 30 2020 at 22:35, on Zulip):

Great, thanks.

Josh Triplett (Oct 31 2020 at 05:41, on Zulip):

@Arlie Davis And the primary reason you might care in this particular context is that it would allow Rust to link to any Windows library without needing an import library.

Josh Triplett (Oct 31 2020 at 05:42, on Zulip):

Which would make it easier and more reliable to link to ucrt or any other Windows library whether the toolchain ships it or not.

Peter Rabbit (Oct 31 2020 at 13:46, on Zulip):

mati865 said:

Doesn't windows-msvc target already use UCRT?

I too am wondering about this. When we link to the CRT currently, we link to msvcrt.lib or libcmt.lib both of which will effectively link to the UCRT given a new enough VC++ and Windows SDK. @Arlie Davis Is there something different that you mean by linking to the UCRT?

Arlie Davis (Oct 31 2020 at 23:46, on Zulip):

Right, that's how Rust, as it ships now, links against the UCRT. In my case, I just need to have adequate control over precisely which version of the CRT is used, because I deal with components that either must link to the UCRT, or must _not_ link to the UCRT, due to existing constraints on those components. Long story short, my team is working on how best to enable Rust for Windows components, so we have to deal with all of the many permutations of build options that Windows components use.

In many cases, there's nothing that needs to be done in Rust to support this, since generally we invoke rustc.exe directly, and do not use it for linking. We run all of our binaries through the MSVC linker, and we control everything that we pass to it. And thankfully, libstd's dependencies on the CRT are fairly minimal.

Luqman Aden (Nov 02 2020 at 22:48, on Zulip):

Josh Triplett said:

Arlie Davis As a step towards several of these improvements, might your team have time to work on the implementation for raw-dylib?

re the raw-dylib work there was a zulip thread about some initial work but looks like it has stalled

rylev (Jan 15 2021 at 11:58, on Zulip):

Hey all, do we know when the MCP will be merged and we can start removing XP support from the std lib? https://github.com/rust-lang/compiler-team/issues/378

Wesley Wiser (Jan 15 2021 at 12:27, on Zulip):

Looks like this was just an oversight. I'll mark it accepted and close it now.

triagebot (Jan 15 2021 at 12:27, on Zulip):

This proposal has been accepted: #378.

Last update: May 07 2021 at 08:00UTC