Running python 32 bit on Windows 7 64 bit:
>>> import platform
>>> platform.platform()
'Windows-post2008Server-6.1.7600'

Should be corrected to display
'Windows-7-6.1.7600'

Fix:
>        elif maj == 6:
>            if min == 0:
>                    # ..................
>                    release = 'Vista'
>                else:
>                    if productType == VER_NT_WORKSTATION:
>                        release = 'Vista'
>                    else:
>                        release = '2008Server'
>            elif min == 1:
>                release = '7'
>            else:
>                release = 'post2008Server'

Confirmed on Python 2.7a2.

Note that this will also need the Workstation check that 6.0 has right above this, because both Windows 7 and Windows Server 2008 R2 are version 6.1.x.

Also of note is that sys.getwindowsversion (renamed as GetVersionEx here) has been expanded to make use of the OSVERSIONINFOEX structure in trunk and py3k, which will make things like getting the platform and service pack info cleaner.

I'll work on a patch.

Here's a patch which fixes this on trunk. 

2.6/3.1 is a different story as there doesn't appear to be a way to get the platform type to differentiate workstation/server. #7766 is what makes it easy on trunk, but it's a new feature and isn't backported. Thoughts?

Brian Curtin wrote:
> 
> Brian Curtin <curtin@acm.org> added the comment:
> 
> Here's a patch which fixes this on trunk. 
> 
> 2.6/3.1 is a different story as there doesn't appear to be a way to get the platform type to differentiate workstation/server. #7766 is what makes it easy on trunk, but it's a new feature and isn't backported. Thoughts?

We can't backport #7766, so unless there's some win32 or OS env var trick
that we could apply, I'm not sure whether Windows 7 support can be
added to 2.6/3.1.

I don't have access to a Windows 7 installation, so can't really
test this on that version. Have you tested the patch on other
Windows versions ?

Esp. the csd change looks like it could break on older versions.

I'll look into whatever other trickery could be applied to 2.6/3.1.

The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 

The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.

Brian Curtin wrote:
> 
> Brian Curtin <curtin@acm.org> added the comment:
> 
> I'll look into whatever other trickery could be applied to 2.6/3.1.
> 
> The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 
> 
> The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.

Python 2.7 doesn't support Windows NT, so we should be fine if the
patch can handle Windows 2000 and later.

See http://www.python.org/dev/peps/pep-0011/

Marc-Andre Lemburg wrote:
> 
> Marc-Andre Lemburg <mal@egenix.com> added the comment:
> 
> Brian Curtin wrote:
>>
>> Brian Curtin <curtin@acm.org> added the comment:
>>
>> I'll look into whatever other trickery could be applied to 2.6/3.1.
>>
>> The patch against trunk works correctly for Win7, Win 2003 Server SP1, Win XP SP2, and Win 2000 Server SP2. platform.platform() outputs the same info for the latter three OSes whether or not the patch is applied. 
>>
>> The csd change will work going back to Windows 2000. If we have to support anything prior, which I don't believe we do, then you are correct that it won't work. If that's an issue, I can revert that part of the change.
> 
> Python 2.7 doesn't support Windows NT, so we should be fine if the
> patch can handle Windows 2000 and later.
> 
> See http://www.python.org/dev/peps/pep-0011/

Hmm, then again: platform.py supports more than just the latest
Python release, so it's better to only use the new csd
approach for Python versions that do support the new windows
version named tuple return value and fallback to the old style
on all other versions.

Here is the patch which checks whether the new info is available and uses it, otherwise it falls back to the original way.

Brian Curtin wrote:
> 
> Brian Curtin <curtin@acm.org> added the comment:
> 
> Here is the patch which checks whether the new info is available and uses it, otherwise it falls back to the original way.

Thanks. Could you apply the same logic to the second hunk of the
patch ?

Whoops, sorry. Here is the change as requested. It reverts to the old way when needed, which hardcodes the version to VER_NT_WORKSTATION as it effectively used to. 


Outside of a hackish and incredibly slow method, I have no idea how to figure out workstation vs. server when OSVERSIONINFOEX isn't available. The slow hack would be to use a subprocess to call "systeminfo" and parse the results, but that would take 4-5 seconds at best.

I'll try to get access to a Server 2008 box again after PyCon and see if there's anything I'm missing when trying to identify it.

This patch should cover everything, and it works with 2.6 as well. In order to figure out workstation vs. server, it uses the ProductName from the registry when it can't the info from getwindowsversion. If it finds a server name, it's a server, otherwise fallback to be a workstation.

This was able to correctly differentiate Vista and Server 2008. I don't have access to Server 2008 R2, but I can't imagine it missing a registry key that exists on every computer I looked at (XP, 2003, Vista, 2008, 7).

Any thoughts on this last bit about using the registry to identify between workstation and server?

Brian Curtin wrote:
> 
> Brian Curtin <curtin@acm.org> added the comment:
> 
> Any thoughts on this last bit about using the registry to identify between workstation and server?

I can't comment on that since I don't know anything much
about the MS registry and the entries used for the various
versions. Isn't there some page page on MSDN that explains
these ?

I do have one nit with your patch, though: could you please
remove the inline function check_registry() and instead use
a regular if-then-else for this ?

Thanks.

Updated patch to remove the function.

MSDN says nothing about available registry keys or their information, at least from what I could tell. I guess it is possible that future versions might not have the value we are looking for, but I kind of doubt that, plus the fallback value is what we've been doing all along. I realize that isn't strong reasoning, so I could remove that registry check if you aren't comfortable with it.

Now that I have access to a Server 2008 R2 machine, I've verified that this fix works there.

Committed in r80857 through r80860.

Brian Curtin wrote:
> 
> Brian Curtin <curtin@acm.org> added the comment:
> 
> Now that I have access to a Server 2008 R2 machine, I've verified that this fix works there.
> 
> Committed in r80857 through r80860.

Thanks, Brian.