proposal: all: remove support for windows/arm

[qmuntal]

Proposal Details

The windows/arm port, which runs on a Windows with 32-bit ARM architecture, has been broken and unable to initialize the Go runtime since Go 1.18 (see #68552 and #70705). Even more, we haven't got a builder for ages.

From the Windows side, 32-bit ARM is no longer supported on Windows 11, as per these docs: https://learn.microsoft.com/en-us/windows/arm/arm32-to-arm64.

Windows devices running on an Arm processor (for example, Snapdragon processors from Qualcomm) will no longer support AArch32 (Arm32).

As a maintainer of the Go Windows port, having to keep up with the windows/arm port when changing the Go standard library (mainly the runtime package) is tedious and time consuming. Even if it doesn't really work, CI test that at least it can be cross-compiled, so I can't just pretend it doesn't exist.

Having said all these arguments, I propose to remove the windows/arm port support from the Go toolchain, tentatively targeting Go 1.25.

@golang/windows @golang/release

[gabyhelp]

Related Issues

• build: windows/arm (32-bit ARM) port is broken #70705
• all: port to Windows/ARM32 #26148
• runtime: windows arm32 1.22 broken #68996 (closed)
• x/build: add a Windows ARM32 builder #46492 (closed)

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/648795 mentions this issue: all: remove support for windows/arm

[kristibektashi]

First of all, thank you for keeping and maintaining the ARM32 Windows version of go for as long as you have (even if it broken and even if it eventually gets removed).

And second, I personally disagree with this proposal. There IS demand for the windows/arm version of go, not on the ARM64 versions of Windows before version 24H2 (although it should also continue to run there as well for ease of testing and debugging), but on older, ARM32-only versions of Windows running Windows RT (some of which can also run a special version of Windows 10 for the ARM32 architecture) since it is the only version of go what would run on these devices.

Although such devices are rare nowadays, there are people (like me) who do have them, and being able to run software based on go is a blessing for us due to the limited application support that these devices have always had.

I also want to note that demand for ARM32 Windows software is rising as people are digging up their old devices since more and more software is being ported. In fact, there is an entire comunnity based on porting software to such devices (and just bringing back life to them in general), and they're fairly active: Link to OpenRT Discord server.

As for the port itself, both of the issues that the ARM32 Windows port had have been fixed by @wmjb (#70234, #68996), and both the builder as well as the CI tests should run just fine on an ARM64 device running Windows 10 ARM64 or Windows 11 ARM64 up to version 23H2 (since these can run ARM32 apps), on in an emulated QEMU device running ARM32 Windows 10: https://files.open-rt.party/Miscellaneous/qemu-win10-15035-arm32.7z.

With all that said, I personally believe the windows/arm port of go should not be removed, since the OpenRT community can be expected to use it and provide bug reports, testing and pull requests in case something breaks. Some of them may even be willing to set up their own builders for the platform in order for it to continue to be supported and tested.

@qmuntal I want to hear your thoughts on this, and if you're still inclined to remove the windows/arm port, I also have an alternative proposal that I would like you to hear first.

[rsc]

This proposal has been added to the active column of the proposals project
and will now be reviewed at the weekly proposal review meetings.
— rsc for the proposal review group

[kristibektashi]

I would also like to mention that another valid use case for the windows/arm version of go is running it in the ARM32 version of Windows Nano Server, which is a super lightweight version of Windows Server meant to be ran in a Docker container

[qmuntal]

Although such devices are rare nowadays, there are people (like me) who do have them, and being able to run software based on go is a blessing for us due to the limited application support that these devices have always had.

I also want to note that demand for ARM32 Windows software is rising as people are digging up their old devices since more and more software is being ported. In fact, there is an entire comunnity based on porting software to such devices (and just bringing back life to them in general), and they're fairly active: Link to OpenRT Discord server.

@kristibektashi it is really cool that there is a community of people porting software to Windows ARM32 and bringing back old devices to live. I'm afraid it doesn't change my opinion here, though. The Go Windows maintainer team is small and we have to pick our battles, having the windows/arm port in the current state doesn't benefit anyone. You can always fork the Go toolchain and keep the ARM32 support, you are probably already doing that for the other applications ported to Windows ARM32.

[kristibektashi]

I understand what you're saying, which is why I want to propose an alternative.

Have a list of "unsupported" ports (which would be similar to the list of "broken" ports) where support is done on a best effort basis by the community and it doesn't block releases or get tested by default (for compiling/functionality/etc), so it's not guaranteed to work in newer versions but someone could always fix it if they wanted to.

This would probably also mean issues about these ports would be closed as wontfix unless someone actually sends code and submits a PR fixing the issue.

windows/arm would be the first architecture to be added to the list, but more would probably be added over time as architectures become unused and less and less people use them.

This would have the benefit of not needing to use a fork for running go on these once-supported architectures (instead it would just take a command-line switch such as --unsupported), but also not forcing the maintainers to fix bugs and maintain builders and tests for these seldom-used architectures, and it could also be a way for newly-introduced but currently non-working architectures to be added to the master branch before work on them is finalized.

[thepudds]

Hi @kristibektashi, FWIW I appreciate the desire to keep things working and the willingness to help out, but it's worth calling out this bit from @qmuntal's first comment:

As a maintainer of the Go Windows port, having to keep up with the windows/arm port when changing the Go standard library (mainly the runtime package) is tedious and time consuming. Even if it doesn't really work, CI test that at least it can be cross-compiled, so I can't just pretend it doesn't exist.

In other words, routine changes to support Windows in general are currently slowed down by this, and it's not just about other gophers being willing to jump in when something breaks. There's a continual, on-going cost to people like @qmuntal and others.

[ianlancetaylor]

@kristibektashi Our current policy on these sorts of issues is described at https://go.dev/wiki/PortingPolicy.

[kristibektashi]

In other words, routine changes to support Windows in general are currently slowed down by this, and it's not just about other gophers being willing to jump in when something breaks. There's a continual, on-going cost to people like @qmuntal and others.

Yes I understand that, which is why I proposed the alternative since I thought it would alleviate this issue (since they could just ignore it theoretically, especially if the "unsupported" ports weren't automatically cross-compiled at all in the CI jobs, and it would have been up to the users to test them).

However I understand there's an unwillingness in maintaining this port at all, and I also don't want to seem pressuring for something that actively hurts other development work (since that's not at all my intention), so I will not comment further on this, and I want to apologize for any inconvenience I may have caused. Once again thank you for all your work and for maintaining the windows/arm port for however long you have. The OpenRT community is likely to create a fork to maintain support once it gets removed from upstream anyway.