We are trying to track down some flakiness in the windows/386 port. The current hypothesis is that the problems are caused by Go managing stacks itself while at the same time depending on Windows's Structured Exception Handling (SEH) to turn memory faults and divides by zero into panics. There are details at golang.org/issue/7325
. I believe the flakiness has always been present, but we are pushing harder on the system during the toolchain build and are finally noticing it. (We don't run Go on 32-bit Windows in production, so the toolchain build is about all we do.)
Many people claim that you simply cannot manage your own stacks on Windows, which would mean that Go on windows/386 is just impossible. However, Go only uses its own stacks for Go execution; it switches back to the OS stack for (nearly) all OS calls, so I'd like to believe we can find a way around the SEH problem and keep Go on windows/386 working.
The most promising solution so far seems to be to switch to Vectored Exception Handling (VEH), which is not implemented in terms of stack addresses and therefore should be less incompatible with Go's management of the stack. However, VEH was introduced in Windows XP; we have no prospective solutions at the moment that would make Windows 2000 work.
There are a few other APIs that the runtime already uses that are Windows XP-specific, but we have managed to keep running in a slightly degraded mode on Windows 2000 when they are not present. That approach does not appear to be possible in this case.
The question then is this: how many people care about support for Windows 2000 specifically? Are there reasons that the next release of Go on 32-bit Windows cannot or should not require Windows XP (or newer)? As a reminder, "Windows XP or newer" includes Windows Server 2003 (or newer).
Please reply to this thread, not to the issue.