RFC: Drop support running LLVM on Windows Vista/7/8 (original) (raw)

I’d like to raise our baseline Windows system requirements to Windows 10, dropping support for running LLVM on Windows Vista. Microsoft dropped support for Vista in 2012 (Vista EOL was 4/10/12, extended support ended 4/11/17). Windows 7 was EOL’ed 1/14/20, and Windows 8 was EOL’ed 1/10/23.

This will not prevent generating binaries which run on Vista, but may prevent running clang or LLVM tools on Windows Vista.

I am proposing that we drop support for Windows Vista as a host for the toolchain.

This is motivated by the desire to use some newer functionality introduced in Windows 10 to address a gap in the file rename API support on Windows (gory details: there is a means of enabling POSIX compatibility which allows moving files which are currently open to allow us to remove a small window of non-atomic file operations). PR: Support: unlock Windows API support, switch to Windows 10 RS1+ APIs by compnerd · Pull Request #102240 · llvm/llvm-project · GitHub

Please respond if you have any objections. If there are no strong objections, I think we can start using the new API in a week or so. This would be something which targets the LLVM 20 release, not the 19 release so we should have ample time for downstream users to adapt.

CC: @rnk @AaronBallman @mstorsjo

I don’t see a need to support Windows Vista as a host for the toolchain. But you’re proposing we drop support for Vista, Windows 7, Windows 8, and then moving to Windows 10, right?

From looking at Desktop Windows Version Market Share Worldwide | Statcounter Global Stats (not certain if there’s a better source for this information), it seems that Windows 7 + Windows 8 is around 4% of the Windows market, with Windows 10 being 65% and Windows 11 at 31%.

Windows 10 RS1 came out in Aug 2016, so this means we require an OS that’s 8 years old or newer. Based on this, I think it’s reasonable to drop everything before Windows 10 RS1 (so long as we get reasonable CMake diagnostics helping people who might be on an earlier Windows 10 realize what’s going on).

I’d be curious to hear if this causes any problems for anyone, or whether folks (esp downstream folks) need longer than a week to investigate or adjust.

compnerd August 8, 2024, 5:22pm 3

Correct, I am proposing that we move to Windows 10 as a toolchain host.

Yes, I felt that 8 years is a reasonably old release for developers to use for development. We can absolutely add a check for this in CMake, though I wonder if we did that in the past (not that I think that is a justification for not doing it going forward).

For what it’s worth, I have run modern LLVM on Windows 7 in recent times (but I suppose it’s a year or two ago now). I think it’s a nice property of open-source software that it often works on software/hardware beyond official vendor EOL.

On the other hand, having a more reliable lvm::sys::fs::rename on Windows would be nice.

Is there any chance that we could check for availability of the new API at runtime and fall back to the old one otherwise?

tschuett August 8, 2024, 6:16pm 5

There will be a cmake error and updated documentation in the first PR.

The CMake error would only affect people building LLVM on an earlier Windows version, right? But this RFC is proposing dropping support for running LLVM on such versions.

tschuett August 8, 2024, 6:30pm 7

So I may build LLVM on Windows Vista, but running the toolchain is unsupported?

compnerd August 8, 2024, 8:32pm 9

Right, that would be the limitation - the binary itself would rely on functionality that would cause it not run properly there.

compnerd August 8, 2024, 8:33pm 10

I’m not sure that there is a good way to do that as it isn’t the API that is necessarily unavailable, it is a constant that is being passed to the system that is new, the API itself is old. So we would need to detect the OS version at runtime :frowning:.

mstorsjo August 8, 2024, 8:34pm 11

I’m pretty sure that Vista is already dropped - since Require Windows API of version 6.1 (Windows 7). · llvm/llvm-project@6b129bd · GitHub.

Yes, this is my opinion as well - I appreciate being able to run things across an as wide range of versions as possible.

That said, I don’t have a strong case for why it would need to be retained - only that this has been the status quo so far, and I’d prefer it to remain so unless there are strong arguments for why it can’t. But I guess I’m a minority having this opinion.

I did suggest this on the PR, and I have made a suggested alternative version of the PR that does exactly that, see this commit. (I haven’t updated the commit message, only the contents of the commit.) The viability of the fallback is being discussed in Support: unlock Windows API support, switch to Windows 10 RS1+ APIs by compnerd · Pull Request #102240 · llvm/llvm-project · GitHub.

mstorsjo August 8, 2024, 8:35pm 12

I don’t see why we’d need to detect the OS version. The existing API will return a clear error of ERROR_INVALID_PARAMETER when the existing API is passed the new constant that the old OS doesn’t support/recognize.

tschuett August 9, 2024, 3:45am 13

It had always been a hard LLVM rule: no BuildBot no support. Assuming that there are no BuildBots running Windows Vista, Windows 7, and Windows 8, I would update the documentation stating: the minimal supported Windows version is 10. Then add a cmake error if someone dares to build LLVM on an unsupported Windows platform. For the rename API, there will be no fallbacks to unsupported Windows versions,

You can always use an LLVM toolchain running on Windows 10 to build binaries for Vista and running them on Vista, but that will be unsupported.

rnk August 14, 2024, 10:11pm 15

I want to raise the practical consideration that we do have two build bots running Windows Server 2012R2:

Internet research suggests that Server 2012 roughly corresponds with Windows 8.

I’m the administrator for these bots and I do periodically perform needed maintenance on them (mainly full disk issues), but I do not have the bandwidth to reimage and recreate them. They were brought into existence before we had good tools to automate the creation of Windows VM images, so it’s all manual.

These buildbots cover two key use cases that are probably not well-covered by other bots:

These bots are old and need to be reimaged, but you might find it easier to proceed with the plan to probe for API support instead of waiting until that happens. If someone else wants to donate compute resources to cover these configs, they are welcome to do so, and I can set up a call to help with that.

Thank you for bringing this up! That does make fallback behavior more important to support; we definitely need to keep those bots working for the coverage.

pogo59 August 20, 2024, 3:08pm 17

More like a soft rule. I am confident there is no bot intended to build with the oldest nominally supported versions of gcc and MSVC, for example. More than once, I’ve run into issues where those versions did not succeed. One time I patched the source, one time I updated my version of gcc.

Sony already requires Windows 10 or later, this won’t bother us. We have data suggesting there are some Server 2016 users but we don’t officially support that.

ChrisR August 21, 2024, 3:31pm 18

Windows Server 2012 continues to be supported by Microsoft with their extended security updates up to 2026, so there is still a supported version of that API in the wild. The product I work on uses libclang for Windows (built on Windows 7, currently) and some of our customers are very conservative in their platform upgrades so it’s possible we will be affected by this change.

That being said, it’s not clear that anyone is using Server 2012 to run our product.

pirama August 21, 2024, 9:41pm 19

The Android NDK (which distributes clang) is still supported (to run on) Windows 8. Happy to chat about any contribution we can make to keep this support for a little while longer until Windows 8 platform is supported for Android development.

pirama August 21, 2024, 11:16pm 20

Sorry for the noise, dropping Windows 8 support should be ok for the Android NDK.