| msg98920 - (view) |
Author: Ad Aluky (aluky) |
Date: 2010-02-05 23:32 |
| 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' |
|
|
| msg98921 - (view) |
Author: Ezio Melotti (ezio.melotti) *  |
Date: 2010-02-05 23:37 |
| Confirmed on Python 2.7a2. |
|
|
| msg98923 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-05 23:58 |
| 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. |
|
|
| msg98927 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-06 01:57 |
| 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? |
|
|
| msg99160 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-02-10 09:00 |
| 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. |
|
|
| msg99175 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-10 17:01 |
| 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. |
|
|
| msg99239 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-02-11 21:48 |
| 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/ |
|
|
| msg99241 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-02-11 21:50 |
| 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. |
|
|
| msg99922 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-23 14:58 |
| Here is the patch which checks whether the new info is available and uses it, otherwise it falls back to the original way. |
|
|
| msg99923 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-02-23 15:05 |
| 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 ? |
|
|
| msg99934 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-23 17:11 |
| 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. |
|
|
| msg100103 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-02-25 20:46 |
| 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). |
|
|
| msg103911 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-21 20:50 |
| Any thoughts on this last bit about using the registry to identify between workstation and server? |
|
|
| msg103914 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-04-21 21:30 |
| 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. |
|
|
| msg103917 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-04-21 22:39 |
| 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. |
|
|
| msg105122 - (view) |
Author: Brian Curtin (brian.curtin) * |
Date: 2010-05-06 03:10 |
| Now that I have access to a Server 2008 R2 machine, I've verified that this fix works there. Committed in r80857 through r80860. |
|
|
| msg105127 - (view) |
Author: Marc-Andre Lemburg (lemburg) * |
Date: 2010-05-06 07:11 |
| 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. |
|
|