@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.

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.

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

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).

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

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.

@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?

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.

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

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.

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

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.

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

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).

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

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

I added the release note. Moving to 1.21.

Change https://go.dev/cl/518235 mentions this issue: internal/dl: update system requirements

Supporting a decision like this based on "If the operating system is no longer distributed or the hardware is no longer manufactured" is just plain bad policy. The users matter the most, not manufacturers. It is the users that use golang or golang-built software, not the manufacturers. So the policy should obviously be about how many users are using Windows 7, plain and simple. Your current policy is literally based on the idea that users update their computers when the latest version of Windows comes out. This is NOT TRUE, unless you're some rich developer working for Google, of course. This policy is literally why every software that comes out of big companies makes everyone's computers slow, because rich programmers clearly do not live in reality when they sit in their fancy office spaces with their over a thousand dollar laptops.

Also, all of this is incredibly surprising. Seems like Windows XP had significantly longer support than Windows 7 ever had. Maybe it's just because I grew up with Windows XP and Vista, so Windows 7 still seems very recent, or maybe it's the fact that Windows 7 was just released in 2009, and SP1 was in 2011.

Anyways, what's most disappointing is the amount of e-waste that we are creating for practically no reason because we want to remove support from things that aren't actively making development harder, lol.

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.

The latter is the logical argument, the former is not. If something is not causing substantial trouble, then removing it only causes harm to existing users, worsens the security of older platforms for no actual reason, and is extremely subjective.

I suppose y'all will end support for Windows 8.1 as well?

The Go team is a small player here. If Microsoft itself decides that it will no longer support a version of Windows, then it doesn't make sense for us to keep supporting that version of Windows. We're not going to rush out and break support for unsupported versions of Windows, but we aren't going to spend our limited resources on keeping them running either.

If there are a lot of people who want to keep running Go programs on unsupported versions of Windows, then there is a market for people to keep Go running on that platform. But it's not going to be the core Go team doing that.

I don't think there's anything to do here for the Go 1.22 milestone. Moving to the next one.

The Go team is a small player here. If Microsoft itself decides that it will no longer support a version of Windows, then it doesn't make sense for us to keep supporting that version of Windows. We're not going to rush out and break support for unsupported versions of Windows, but we aren't going to spend our limited resources on keeping them running either.

If there are a lot of people who want to keep running Go programs on unsupported versions of Windows, then there is a market for people to keep Go running on that platform. But it's not going to be the core Go team doing that.

but why c/c++ can run in window 7, and go programs dont run ??

@ianlancetaylor

We're not going to rush out and break support for unsupported versions of Windows, but we aren't going to spend our limited resources on keeping them running either.

It's already been broken: #64622

My company develops integrations for restaurant point of sale systems. These generally run on Windows and are notoriously bad at updating their version of Windows. It's a large investment for restaurants that often don't have a dedicated IT person or budget to do this type of upgrade.

Up till now our integration has supported Windows 7. With this change, we will be forced to pin our go version and accept any security risks associated with not upgrading. The alternative of changing our supported Windows version will alienate happy customers that are working today. If it would help, I could gather stats on what percent of our customers are on Win7 or Win8.

Is there any possibility of reconsidering this decision?

Notice this change seems to also break wine and proton support on Linux: running a Go .exe with them is no longer possible since Go 1.21.

Overall this seems like a really big deviation from what we'd expect as developers from the Go compiler.
We now have users running on Windows 7 coming up and complaining about cryptic error messages such as :

fatal error: bcryptprimitives.dll not found
runtime: panic before malloc heap initialized

or such as

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

that are actually caused by compiling the .exe using Go 1.21 instead of Go 1.20.

At least there could be a clear error message pointing to a compatibility issue, to avoid wasting developer's time, this is going to hurt the entire community otherwise.

In general, I think Windows 7 could have continued to be supported for the next couple of versions at least, for the following reasons:

• Microsoft has officially ended Mainstream Support and Extended Support for regular Windows 7 editions, however they are still providing Windows Embedded POSReady 7 with Extended Security Updates (ESU) support until October 8, 2024, this is in ~9 months, which contradicts the above statement about "Availability" being the main issue.
• The Go Community Code of Conduct is explicit about committing "to providing a friendly, safe and welcoming environment for all", however this change is going to disproportionately affect specific countries, as pointed out in the linked issue:

  Just for everyone's general awareness, this issue affects users in poorer countries disproportionately in a dramatic way. In China, for example, 24% of our users are on Windows 7 or below. I would guess the number is even higher elsewhere.

• The overhead in supporting it seems minimal, since it was already "built-in" compared to the headaches it causes developers facing the above cryptic messages.

Since this kind of issues will probably come back to bite us with Windows 10 in a few years, should we consider improving messaging and have an explicit error in the case where a Go binary is run on an unsupported Windows version instead of silently not supporting them? (I'm happy to open a new proposal for that if the consensus is that it is desirable.)

Since this kind of issues will probably come back to bite us with Windows 10 in a few years, should we consider improving messaging and have an explicit error in the case where a Go binary is run on an unsupported Windows version instead of silently not supporting them? (I'm happy to open a new proposal for that if the consensus is that it is desirable.)

Please go ahead and open a proposal with what you have in mind, any improvement is more than welcome!

Notice this change seems to also break wine and proton support on Linux: running a Go .exe with them is no longer possible since Go 1.21.

Wine does ship with bcryptprimitives.dll since 8.13: wine-mirror/wine@83d4075. I know that it is quite a recent version, but wine is not an officially supported target, so I think it is fair to ask people to upgrade wine when they upgrade Go if they find any incompatibility.

The overhead in supporting it seems minimal, since it was already "built-in" compared to the headaches it causes developers facing the above cryptic messages.

Keeping Windows 7 working requires a non-negligible amount of work, I can assure you that, and the Windows maintainer group has limited capacity. If we decided to continue supporting Windows 7, it will be in detriment of newer Windows versions. Having said this, I'm happy to provide some guidance if someone is willing to stand-up a self-hosted Windows 7 builder and commit to maintaining the Windows 7 port.

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)?

Having said this, I'm happy to provide some guidance if someone is willing to stand-up a self-hosted Windows 7 builder and commit to maintaining the Windows 7 port.

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?

Change https://go.dev/cl/556896 mentions this issue: wiki: update Windows support matrix

@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)?

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?

I'll also note that this change was made, in part, to address confusing DLL loading semantics triggered by the runtime, as discussed in https://go.dev/issue/64411. I'd want to make sure that any change we make here in order to support Windows 7 doesn't reintroduce this problem for binaries on other Windows versions.

Since this kind of issues will probably come back to bite us with Windows 10 in a few years, should we consider improving messaging and have an explicit error in the case where a Go binary is run on an unsupported Windows version instead of silently not supporting them? (I'm happy to open a new proposal for that if the consensus is that it is desirable.)

Please go ahead and open a proposal with what you have in mind, any improvement is more than welcome!

Notice this change seems to also break wine and proton support on Linux: running a Go .exe with them is no longer possible since Go 1.21.

Wine does ship with bcryptprimitives.dll since 8.13: wine-mirror/wine@83d4075. I know that it is quite a recent version, but wine is not an officially supported target, so I think it is fair to ask people to upgrade wine when they upgrade Go if they find any incompatibility.

The overhead in supporting it seems minimal, since it was already "built-in" compared to the headaches it causes developers facing the above cryptic messages.

Keeping Windows 7 working requires a non-negligible amount of work, I can assure you that, and the Windows maintainer group has limited capacity. If we decided to continue supporting Windows 7, it will be in detriment of newer Windows versions. Having said this, I'm happy to provide some guidance if someone is willing to stand-up a self-hosted Windows 7 builder and commit to maintaining the Windows 7 port.

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)?

why c++/c/rust/Native aot c# can easily run on window 7 with visual c++ was installed

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

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.

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

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.

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.

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