all: announce end of support for old Windows releases

[cagedmantis]

Microsoft continuously releases new version of Windows. We should announce end of support for Windows versions as we discover that they are either no longer supported by Microsoft or no longer have any use as a builder.

Relevant recent discussion: #47845

/cc @golang/release

[cagedmantis]

@zx2c4 The creation of this issue does not signal a plan to drop support. This issue has been created in order to add an explicit step for the consideration of our support stance during each release.

[zx2c4]

Makes sense. One nit though:

as we discover that they are either no longer supported by Microsoft or no longer have any use as a builder.

Windows 7 is basically out of support now by Microsoft. But it's still supported by Chrome. I tried to come up with a reasonable set of criteria for when I should/could drop support for old Windows for my own software, but ultimately I kept coming back to, "if Chrome supports it, why shouldn't I?" I wonder if Go finds itself in a similar situation there too.

[alexbrainman]

I still use Windows 7 on one of my computers. And I have to install Microsoft updates on it pretty regularly (every week). So there are still enough users for Microsoft to care.

Alex

[dmitshur]

Adding a data point observed in Git for Windows release notes upcoming breaking changes section:

[...] Around the beginning of 2023, Git for Windows will drop support for Windows 7 and for Windows 8, following Cygwin's and MSYS2's lead (Git for Windows relies on MSYS2 for components such as Bash and Perl).

[qmuntal]

Another data point: .NET support for Windows 7 and 8.1 will end in January 2023: dotnet/announcements#226

[zx2c4]

Only kind of:

We will offer support for Windows Server 2012/R2 throughout .NET 7 and .NET 8

2012R2 is v6.3, like 8.1.

[aclements]

@thanm recently ran into a problem where it seems recent Windows C toolchains produce binaries that don't run on the Windows 2008 (≈ Windows 7) builder, which is further support for dropping Windows 7. I'm probably summarizing that poorly. Than?

[thanm]

Details for the problem I ran into can be found in #56904. Use case is a bit on the obscure side (external linking + race + windows-amd64-2008 builder). I have to admit that I am not sure exactly what vintage of windows this builder is.

[alexbrainman]

Details for the problem I ran into can be found in #56904. Use case is a bit on the obscure side (external linking + race + windows-amd64-2008 builder). I have to admit that I am not sure exactly what vintage of windows this builder is.

I suspect windows-amd64-2008 builder runs Windows Server 2008 (search for "Windows Server 2008" in https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions ) and Windows Server 2008 is just a Windows Vista (search for "Windows Vista" in https://en.wikipedia.org/wiki/Windows_Server_2008 ).

Windows Vista is a version between Windows XP and Windows 7 (search https://en.wikipedia.org/wiki/List_of_Microsoft_Windows_versions for "Windows Vista").

Windows Vista was never a big / important version of Windows. I doubt there are many Windows Vista users.

Windows 7 is different from Windows Vista.

And the problem @thanm is having is most likely to do with gcc and not Windows. Windows does not come with free C compiler. So Go uses gcc for cgo. So we cannot blame Windows if gcc does not work in some situations / or Windows versions.

I don't think we should drop support of old versions of Windows if gcc does not work there. I doubt many Go Windows users use cgo, and broken gcc does not affect them.

Personally I only have Windows 10 these days. And I don't even use it day to day anymore. So whatever you decide here is fine with me.

Alex

[heschi]

Trouble with the race detector doesn't seem like reason enough to drop a Windows version to me. However, Chrome is dropping Windows 7 and 8.1 support at about the same time Go 1.20 will come out, so maybe the timing is right anyway.

[alexbrainman]

However, Chrome is dropping Windows 7 and 8.1 support at about the same time Go 1.20 will come out, so maybe the timing is right anyway.

I am not against dropping Windows 7 support in Go 1.20. But what are the benefits of dropping support for the Go Team?

Chrome might have some problems supporting Windows 7. What are the problems with Windows 7 that Go Team have?

Alex

[heschi]

Every first-class port is a drain on our resources to some extent; tests can flake, compilers can be broken as above, running builders costs money. So perhaps we have opposite perspectives: my attitude is that things have to continuously justify their existence, whereas yours is that we should only remove them if they're causing substantial trouble.

Maybe we should be able to declare particular OS versions second-class; if we could do that I'd say that we can just demote 8.1 and lower to second-class and let interested parties such as yourself maintain them.

[alexbrainman]

Every first-class port is a drain on our resources to some extent; tests can flake, compilers can be broken as above, running builders costs money. So perhaps we have opposite perspectives: my attitude is that things have to continuously justify their existence, whereas yours is that we should only remove them if they're causing substantial trouble.

I don't believe that Windows 7 users report more issues than others. And Go Team does not have Windows 7 builder. So I don't see why Go Team would pick on Windows 7 users. On the other hand it is good marketing for the project when it supports its existing users (while other projects dropping support for their OS).

Alex

[rsc]

As a reminder, from a Go project policy perspective, we've already set the criteria for keeping an operating system supported. That discussion was #19002, and the documented policy is at https://github.com/golang/go/wiki/PortingPolicy#removing-old-operating-system-and-architecture-versions. Quoting that text:

The important considerations when deciding whether to remove support for an old operating system or architecture version are:

• Availability. If the operating system is no longer distributed or the hardware is no longer manufactured, for example, there's not a clear need to keep it going. For example, Go's ppc64 port no longer supports the IBM POWER5 architecture.
• Manufacturer support. If the operating system or architecture is no longer supported by its manufacturer, that is a strong signal that a future version of Go can remove support as well. For example, each year, Apple typically issues one new version of macOS and deprecates one old version. Go typically deprecates old macOS versions at the same rate.
• Actual or expected user base. If there are relatively few users, significant effort to maintain a port may not be worthwhile.
• Ongoing costs. Ports that require significant ongoing debugging or implementation efforts will be scrutinized more than ports that don't.

When the considerations weigh in favor of removing a port and a proposal is accepted, Go 1.N's release notes will announce that support for a given operating system or architecture will be dropped in Go 1.(N+1).

For Windows, the manufacturer support factor is the most important one.

Since MS has dropped Windows 7, so should we (by announcing in Go 1.20 that it will be removed in Go 1.21).

[heschi]

I had never noticed the "proposal is accepted" part of the policy. Filed #57003 and #57004.

[heschi]

Nothing left to do until the proposals above are processed and we decide what to put in the release notes. OK after RC.

[qmuntal]

If there is a relatively simple way to do this I'm not particularly opposed, but it's unclear to me how easy a fallback for both the runtime and crypto/rand would be. Do we have a cheap way of determining what Windows version we are running on?

Yep, RtlGetNtVersionNumbers, as in

go/src/runtime/os_windows.go

Line 459 in 704401f

stdcall3(_RtlGetNtVersionNumbers, uintptr(unsafe.Pointer(&maj)), uintptr(unsafe.Pointer(&min)), uintptr(unsafe.Pointer(&build)))

This change is extremely detrimental to my company and our customers. We haven't contributed to go before, but I'd like to hear more about what is involved. If us owning the Windows 7 port gets compatibility back, I think we would consider doing it. Can you give me more specifics about what this would look like?

This is info you are looking for: https://go.dev/wiki/PortingPolicy. The first step would be to create a proposal asking to reintroduce Windows 7 support and volunteering to support it. Just take in account that it might be rejected. In fact, IMO it will be much easier for your to just maintain a private fork of Go that can support your business needs instead of having to maintain something for the whole community.

[jlevitt]

@qmuntal thanks for the info! I will bring it back to my team to decide how we want to move forward.

[ianlancetaylor]

On the other hand, I also think that completely breaking Windows 7 in a go1.21 patch version was unfortunate. @rolandshoemaker @ianlancetaylor do you think it would make sense to partially revert CL 545355 so we fall back to RtlGenRandom if ProcessPrng is not available (only in the go1.21 release branch)?

I would support this change if it's not too invasive.

[jlevitt]

On the other hand, I also think that completely breaking Windows 7 in a go1.21 patch version was unfortunate. @rolandshoemaker @ianlancetaylor do you think it would make sense to partially revert CL 545355 so we fall back to RtlGenRandom if ProcessPrng is not available (only in the go1.21 release branch)?

I would support this change if it's not too invasive.

I'm feeling like there may be some bystander effect going on here. Who should make this change? I'm happy to do it, but I will have to ramp up as a golang contributor. I'm not sure if there's a core team that would normally make changes in this part of the code.

[gdy666]

I found this project, which can make programs compiled by the new version of golang run on win7.
https://github.com/vxiiduu/VxKex/

[i486]

I've successfully compiled the latest version of Hugo (v0.125.4) using the latest version of Go (v1.22.2), with VxKex enabled. Hugo itself (which also needs to have VxKex enabled) and the website I built with it are functioning perfectly.

While I'm not exactly a programmer, it appears that only a select few Win 10+ APIs were causing trouble for Go on Windows 7. It would be absolutely fantastic if some compatibility enhancements could be implemented, perhaps in the upcoming 1.21 & 1.22 update to ensure it's at least functional on Windows 7, even if it's not officially supported.

Kudos to the team for all their hard work!

[OrbintSoft]

I wonder why Plan9 (with a market share around 0) receives a better support than windows 7 still supported on embedded devices with extended support (market share around 3% for online devices, but higher in developed countries and on industrial devices).

I understand that it's expensive to keep windows 7 supported as first class platform, but I don't even think it's wise to completely broken it.

[ianlancetaylor]

Go doesn't support old versions of Plan 9 either. And, more importantly, nobody on the core Go team works on it; it is maintained by Plan 9 supporters. I have already indicated that it would be OK if a Windows 7 supporter sent in a patch to fall back to RtlGenRandom if necessary.

[stunndard]

You keep breaking it, we keep fixing it; Simple binary patcher to make Go >=1.21 exe's work on Win7/Server 2008: https://github.com/stunndard/golangwin7patch

[dmitshur]

There are no changes here for the Go 1.24 milestone. Moving to the next.

[StefanoBalzarottiNozomi]

https://github.com/thongtech/go-legacy-win7/releases/tag/v1.23.4-2

Big thanks to thongtech for the work.

[cagedmantis]

Support for Windows 10 will end in October 2025. According to the porting policy, we should pre-announce the end of support for Windows 10 and Go 1.26 in the Go 1.25 release notes.

[CameronGo]

Support for Windows 10 will end in October 2025. According to the porting policy, we should pre-announce the end of support for Windows 10 and Go 1.26 in the Go 1.25 release notes.

Several Windows 10 LTSC releases will continue to be supported by Microsoft well past that date. We are running Windows 10 IoT Enterprise LTSC 2021 for example, which is supported until January 2032.

[StefanoBalzarottiNozomi]

Microsoft dropped support of Windows 7 POSReady ESU 3 on 7 October 2024: https://learn.microsoft.com/en-us/lifecycle/products/windows-embedded-posready-7

Microsoft is still supporting Windows Server 2012 (equivalent to windows 8) until October 13, 2026 via ESU: https://learn.microsoft.com/en-us/windows-server/get-started/extended-security-updates-overview

Windows 10 Enterprise LTSC 2021 will be supported until 2032, and support will be probably extended via ESU.

So don't rush to drop support

[jlevitt]

Please don't drop Win 10 support any time soon. We support clients that are not tech savvy and are very slow to upgrade their software. We can't control what OS they run. Dropping Win7 was a huge headache for us.

[cagedmantis]

@CameronGo @StefanoBalzarottiNozomi @jlevitt These are great points. Thank you for posting them. Please note that we won't drop support for Windows 10 without an accepted proposal.