objections to removing Go support for Windows 2000 (x86-32)?

[Russ Cox]

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.

Thanks.

Russ

[Stephen Gutekanst]

Microsoft will officially end support of XP on April 8th.

I think as long as we support at least one version behind what Microsoft officially supports we are okay.

Stephen

[ron minnich]

And Windows 2000 support ended in 2010. It seems reasonable to me that you not support a by-definition unsupported operating system. 

[minux]

On Mon, Mar 10, 2014 at 7:02 PM, Russ Cox <r...@golang.org> wrote:

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.

From my understanding, all what we have to do is to set the TCB stack limit at goroutine

switch time? Doesn't seems too bad, or am I misunderstanding anything?

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

This is very sad. Although Windows 2000 has long been deprecated by the vendor, I've seen

them running just fine in the wild (it's the first Windows that's both easy to manage like the

9x series, and has high reliability like the Windows NT. Not to mention that it has lower resource

requirement than XP.) Also surprisingly a lot of software still runs on Windows 2000.

We probably needs a Windows 2000 builder though.

(I volunteer to run one if necessary.)

[egon]

Just a random suggestion to:

This is one of those times when on every other system you can just go to lxr/fxr and look at the source code. Oh well.

Maybe it's possible to get a similar crash out of ReactOS, at least then you have source code to work with. This of course assumes that regular go stuff will run and they have replicated that part of OS well enough.

Alternatively, maybe someone on its forums can answer about the internals more.

+ egon

[Russ Cox]

On Tue, Mar 11, 2014 at 12:23 AM, minux <minu...@gmail.com> wrote:

On Mon, Mar 10, 2014 at 7:02 PM, Russ Cox <r...@golang.org> wrote:

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.

From my understanding, all what we have to do is to set the TCB stack limit at goroutine

switch time? Doesn't seems too bad, or am I misunderstanding anything?

I'd like to keep the discussion here about Windows 2000 support in general and not about the technical details of this specific problem. If you want to discuss the technical details, see the longer discussion on the issue. Thanks.

[gta]

+1

[Nate Finch]

I used to write (Windows) financial software in my last job.  Those big banking guys were just about the last ones to upgrade.  We dropped Win 2000 support after Microsoft dropped support for it.  They might still be using Excel 2000 (seriously, we had people complaining our plugins didn't support it), but they'll be doing it on Windows XP or better (and at this point, probably Win7... no one likes Vista).  The places that are big are the places who are last to upgrade, but they're also the ones that actually use their support contracts... so when Microsoft drops support, they upgrade.  

I think it's pretty safe to drop Win 2000 support.

[André Paquet]

I know it's apples and oranges in terms of active development and commercial support, but it would be weird supporting Plan 9 but not Windows 2000, just in terms of sheer numbers. (Disclaimer: I have no data to support my claim, and I'm for supporting both systems).

André

On Monday, March 10, 2014 7:02:05 PM UTC-4, Russ Cox wrote:

[Aram Hăvărneanu]

The popularity of a platform doesn't matter, what matters is what
impact a target has on the other targets. Supporting Windows 2000 is
costly in terms of developer burden and it impacts other supported
platforms (newer Windows systems). Plan 9 costs almost nothing to
non-maintainers, almost all the Plan 9 runtime, syscall and net code
is Plan 9 specific, it's not shared with other platforms. It has a
minimal impact on other targets.

--
Aram Hăvărneanu

[Dmitry Vyukov]

just to remind, Go 1.2.1 still works on windows2k
if somebody does not want to update, let it be so

> --
> You received this message because you are subscribed to the Google Groups
> "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[André Paquet]

Hence apples and oranges. I was playing devil's advocate. Sadly, I don't have the knowledge debate technical issues. I was talking about the bigger picture and perceptions. 

That being said, I won't shed tears on the loss of Win2k support.

[Daniel Theophanes]

No issue dropping support for Windows 2000.

None of my clients are using Windows 2000, nor have I seen it being used in quite some time. Most of my clients are currently migrating away from Windows XP/2003 right now (though I would still like support for that platform for a little bit longer).

Thanks,

-Daniel

On Monday, March 10, 2014 4:02:05 PM UTC-7, Russ Cox wrote:

[ro]

Before you into the numbers:

Plan 9 is open-source still being actively developed.

Windows 2000 is closed-source and abandoned by the company that build it.

I believe this concludes the discussion on Windows 2000's part.

[RickyS]

Is there even 1 customer using an application written in Go on a Win2k box?

[Czarek Tomczak]

On Tuesday, March 11, 2014 12:02:05 AM UTC+1, Russ Cox wrote:

...

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

Usage share of operating systems as of February 2014:

Desktop operating system browsing statistics on Net Applications
Windows 7			47.53%
Windows XP			28.53%
Windows 8			10.68%
OS X			7.68%
Windows Vista			2.10%
Linux			1.48%

Reference:

https://en.wikipedia.org/wiki/Usage_share_of_operating_systems

Best regards,

Czarek

[Hotei]

I am definitely not a MS fan, but I have to admit Win2K was one of their success stories.  I continue to run Win2K (in VirtualBox) precisely because it has an extremely low resource footprint (IIRC the VM RAM footprint was a something like 64 MB) and it does run a heck of a lot of stuff that I either bought or wrote in C/C++.  I wasn't even aware that go would work in that environment, but if it's relatively easy to keep it working I think that's a good thing. If it's getting more trouble than it's worth that's understandable too.   Should you choose to stop supporting Win2K I hope you'll consider freezing the last working go version - whatever that is/becomes - so that go stays available for Win2K even if it's not the most current version.

On Monday, March 10, 2014 7:02:05 PM UTC-4, Russ Cox wrote:

[John Jeffery]

+1

[John Jeffery]

+1

[Carl Menezes]

No issues with dropping support for Windows 2000 from my end.

[Lars Seipel]

On Tue, Mar 11, 2014 at 06:44:50AM -0700, André Paquet wrote:
> I know it's apples and oranges in terms of active development and
> commercial support, but it would be weird supporting Plan 9 but not Windows
> 2000, just in terms of sheer numbers. (Disclaimer: I have no data to
> support my claim, and I'm for supporting both systems).

"Sheer numbers" don't matter. What does matter though is people who
care. People who care enough to do the work, in particular.

Recently there was some talk about dropping Plan 9 support for Go 1.3,
as the state of the port was pretty bad. Some people rolled up their
sleeves and invested the time to fix it (great work, guys!). Prospects
look much better now.

So when you have such people with interest in Plan 9 but can't find a
single gopher who even runs Windows 2000 dropping the latter while
keeping Plan 9 isn't weird at all.

Lars

[Joseph Poirier]

Must not have read through the thread. 

[Russ Cox]

Thanks everyone for your replies. It turns out that VEH does fix the problem we're seeing, so for the reasons laid out both in my mail and by others in this thread, Go 1.3 will remove support for Windows 2000. 

I do realize that a few people spoke up saying that they use or prefer Windows 2000, but we have to draw a line somewhere, there are very few potential users on that side of the line, and the available Windows 2000 expertise we developers can draw on is near zero and shrinking. The simplifications and fixes made possible in the runtime by assuming Windows XP outweigh the few potential uses. Go 1.2.1 will of course continue to run as well as it does today (I think it has the same latent bugs but if you're not seeing them, you probably won't start seeing them).

The discussion also raised a comparison with Plan 9, which I think is an interesting one. When there are mysterious problems on Plan 9, the source code is available for consultation, we have Plan 9 experts on hand to answer questions, and, in at least one instance, Plan 9 has been changed to aid Go's implementation. None of this is true of Windows 2000.

Russ

[André Paquet]

For the record I didn't want to start a battle with Plan 9 and its devoted following. Ironically, I just setup this past weekend an auth+cpu server on a virtual machine specifically to write go code in acme. So I'm looking forward to use a stable plan 9 go compiler.

André

[Lars Seipel]

On Wed, Mar 12, 2014 at 02:20:21PM -0500, Joseph Poirier wrote:
> > Must not have read through the thread.

Actually, I did. I'm not sure though that keeping a Windows 2000 virtual
machine to run old non-portable software (like Hotei wrote he does)
counts in this respect.

What I didn't read before replying here was the other thread on the -dev
list where Russ asked to keep the discussion here on -nuts. ☺