Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

all: announce end of support for old Windows releases #52188

Open
cagedmantis opened this issue Apr 6, 2022 · 34 comments
Open

all: announce end of support for old Windows releases #52188

cagedmantis opened this issue Apr 6, 2022 · 34 comments
Labels
Builders x/build issues (builders, bots, dashboards) Documentation NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Milestone

Comments

@cagedmantis
Copy link
Contributor

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 cagedmantis added Documentation NeedsFix The path to resolution is known, but the work has not been done. release-blocker recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. labels Apr 6, 2022
@cagedmantis cagedmantis added this to the Go1.19 milestone Apr 6, 2022
@cagedmantis
Copy link
Contributor Author

@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
Copy link
Contributor

zx2c4 commented Apr 6, 2022

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
Copy link
Member

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 dmitshur added this to Planned in Go Release Team Apr 12, 2022
@dmitshur
Copy link
Contributor

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

@dmitshur dmitshur added the Builders x/build issues (builders, bots, dashboards) label May 31, 2022
@dmitshur dmitshur modified the milestones: Go1.19, Go1.20 Jun 1, 2022
@qmuntal
Copy link
Contributor

qmuntal commented Jun 23, 2022

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

@zx2c4
Copy link
Contributor

zx2c4 commented Jun 23, 2022

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
Copy link
Member

@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
Copy link
Contributor

thanm commented Nov 23, 2022

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
Copy link
Member

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
Copy link
Contributor

heschi commented Nov 28, 2022

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
Copy link
Member

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
Copy link
Contributor

heschi commented Nov 28, 2022

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
Copy link
Member

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
Copy link
Contributor

rsc commented Nov 30, 2022

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
Copy link
Contributor

heschi commented Nov 30, 2022

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

@heschi
Copy link
Contributor

heschi commented Dec 2, 2022

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

@heschi heschi added the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 2, 2022
@gopherbot gopherbot removed the okay-after-rc1 Used by release team to mark a release-blocker issue as okay to resolve either before or after rc1 label Dec 7, 2022
@heschi
Copy link
Contributor

heschi commented Dec 21, 2022

I added the release note. Moving to 1.21.

@heschi heschi modified the milestones: Go1.21, Go1.22 Mar 22, 2023
@dmitshur dmitshur changed the title build: announce end of support for old Windows releases all: announce end of support for old Windows releases Jun 14, 2023
@gopherbot
Copy link

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

gopherbot pushed a commit to golang/website that referenced this issue Aug 10, 2023
As described at https://go.dev/doc/go1.21#ports:

- Go 1.21 requires at least Windows 10 or Windows Server 2016;
  support for previous versions has been discontinued.
- Go 1.21 requires macOS 10.15 Catalina or later;
  support for previous versions has been discontinued.

For golang/go#23011.
For golang/go#52188.

Change-Id: I7a3dd6e82400b238a2220d34bcffbbfc2f1b68a1
GitHub-Last-Rev: c637a1c
GitHub-Pull-Request: #240
Reviewed-on: https://go-review.googlesource.com/c/website/+/518235
TryBot-Result: Gopher Robot <gobot@golang.org>
Reviewed-by: Heschi Kreinick <heschi@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
@clseibold
Copy link

clseibold commented Oct 12, 2023

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?

@ianlancetaylor
Copy link
Contributor

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.

@dmitshur
Copy link
Contributor

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

@dmitshur dmitshur modified the milestones: Go1.22, Go1.23 Oct 13, 2023
@NCLnclNCL
Copy link

NCLnclNCL commented Nov 30, 2023

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

@jlevitt
Copy link

jlevitt commented Jan 3, 2024

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

@AnomalRoil
Copy link

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

@qmuntal
Copy link
Contributor

qmuntal commented Jan 19, 2024

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

@jlevitt
Copy link

jlevitt commented Jan 19, 2024

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?

@gopherbot
Copy link

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

@rolandshoemaker
Copy link
Member

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

@NCLnclNCL
Copy link

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

@qmuntal
Copy link
Contributor

qmuntal commented Jan 23, 2024

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

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
Copy link

jlevitt commented Jan 23, 2024

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

gopherbot pushed a commit to golang/wiki that referenced this issue Jan 26, 2024
Updates golang/go#52188.

Change-Id: I97c3e8ebcfd325016b6610cf219a48c50d0584be
Reviewed-on: https://go-review.googlesource.com/c/wiki/+/556896
Reviewed-by: Dmitri Shuralyov <dmitshur@golang.org>
Commit-Queue: Quim Muntal <quimmuntal@gmail.com>
@ianlancetaylor
Copy link
Contributor

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
Copy link

jlevitt commented Mar 5, 2024

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
Copy link

gdy666 commented Apr 10, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Builders x/build issues (builders, bots, dashboards) Documentation NeedsFix The path to resolution is known, but the work has not been done. recurring Issues that should never be closed, but moved to the next milestone once fixed in the current one. release-blocker
Projects
Status: Planned
Status: No status
Development

No branches or pull requests