SUMMARY:

'Microsoft' is the platform.system() of Vista Windows, whereas 'Windows' 
was the platform.system() of XP Windows, whoops.

STEPS TO REPRODUCE & ACTUAL RESULTS:

Run 2.5.1 Python in a Vista and see:

>>> import platform
>>> platform.system()
>>>
'Microsoft'
>>> 

EXPECTED RESULTS:

>>> import platform
>>> platform.system()
'Windows'
>>> 

WORKAROUND:

Write new Python source code like:

if platform.system() in ('Windows', 'Microsoft'): 
if not (platform.system() in ('Windows', 'Microsoft')): 

in place of obsolete Python source code like:

if platform.system() == 'Windows': # Microsoft 
if platform.system() != 'Windows': # Microsoft 

REGRESSION/ ISOLATION:

Seen by me in an Enterprise Vista. Indexed by Google as reported by 
Martin v. Löwis (loewis) circa 2007-05-29 07:11 as:

http://mail.python.org/pipermail/patches/2007-June/022947.html 
... 

Patches item #1726668, was opened at 2007-05-28 03:23 

On Microsoft Vista platform.system() returns 'Microsoft' and 
platform.release() returns 'Windows' 

Under Microsoft Windows XP SP2 platform.system() returns 'Windows' and 
platform.release() returns 'XP'. 

This is problem was caused by a change in the output of the "ver" 
command. In Windows XP SP2 "ver" outputted 'Microsoft Windows XP 
[Version 5.1.2600]'  In Microsoft Vista "ver" outputted 'Microsoft 
Windows [Version 6.0.6000]'. The lack of the 3rd word before version 
causes _syscmd_ver(...) in platform.py to return 'Microsoft' for system 
instead of 'Microsoft Windows'. This causes uname() to return the 
incorrect values. Both system() and release() call uname().

NOTES:

There is no fixing all of this?

Cross-platform scripts actually will misbehave across the large 
population that is 2.5 Python in Vista unless those scripts change to 
implement something like the suggested workaround, that's now an 
accomplished fact.

Question: Is it better to leave this feature as is, so that everyone 
eventually learns to workaround it, or is it better to fix it late now 
in 2007-09, so that many people never have to learn to workaround it?

Question: Why are we screen-scraping the Ver command, instead of calling 
Win kernel32.getVersionEx? And how can any code for screen-scraping the 
Ver command be in doubt about whether the platform.system underneath is 
'Windows'?

Wow.  I think that platform.system() should return "Windows" for both XP 
and Vista, and platform.release() should return either "Vista" or "XP".  
Seems like a patch to make this happen would be a good idea.

Attached a patch which I *THINK* fixes this, but I don't run Windows. 
Can someone else check this?

Supplied patch passes "make test", BTW.

I recommend we reject this first draft of the python-trunk-
vistaplatform.patch.

I reason as follows ...

ACTUAL RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS:

>>> import platform
>>> ...
>>> platform.uname()
('Microsoft', '[redacted]', 'Windows', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'Windows'
>>>

EXPECTED RESULTS OF 2.5.1 PLUS PATCH IN VISTA WINDOWS:

>>> import platform
>>> ...
>>> platform.uname()
('Windows', '[redacted]', 'Vista', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'Vista'
>>>

ACTUAL RESULTS OF 2.5 IN SP2 XP WINDOWS:

>>> import platform
>>> ...
>>> platform.uname()
('Windows', '[redacted]', 'XP', '5.1.2600', '', '')
>>> platform.system()
'Windows'
>>> platform.release()
'XP'
>>>

DISCUSSION:

Four thoughts:

1.

I think we meant to write { unameInfo[2] == 'Windows' } where we wrote 
{ unameInfo == 'Windows' } in this patch.

2.

To run the patch I created a copy of platform.py in the same folder and 
applied the patch by hand. I redacted the host names by hand and elided 
the { platform = ... } source line I wrote to let me run the patch in 
place of the original.

3.

I think we should substitute a different kind of patch, a patch to 
correct the platform.uname rather than a patch to redefine 
platform.system and platform.version.

I'd like us to hold to such cross-platform invariants as:

( platform.system() == platform.uname()[0] )

( platform.system() == platform.uname()[2] )

Out on the web I see that we have documented these invariants. I quote:

""" 14.12.1 Cross Platform 
 
uname()

... Returns a tuple of strings (system, node, release, version, 
machine, processor) identifying the underlying platform. 

""" 2007-09-17 fetch of http://docs.python.org/lib/node442.html
""" near http://docs.python.org/lib/module-platform.html

4.

I don't think we can totally fix this trouble in code: we have 
distributed 2.5.1 to Vista too massively already now.

Specifically, I think we should also fix the doc to admit the hereafter 
frequent need for people using Python to write code such as:

if not (platform.system() in ('Microsoft', 'Windows')):

Attached is a patch that fixes uname() instead of the individual
helpers.  I agree that is the better way to do it.  Again, not tested on
Windows because I don't have it.

What about adding a "isWindows()" sort of method that does the right
thing, or "amIRunningOn('Vista')"?  I suggest the latter because I
imagine the former might just lead to a bunch of "Where is isX()?" for
different platforms.  This could implement the logic so that users don't
have to know the details of this issue.

A couple of notes:

* platform.uname() needs to be fixed, not the individual query functions.

* The third entry of uname() should return "Vista" instead of
"Microsoft" on MS Vista.

* A patch should go on trunk and into 2.5.2, since this is a real bug
and not a feature change.

Any other changes to accommodate for differences between used marketing
names and underlying OS names should go into system_alias().

Shall I commit my "v2" patch then, to 2.5.2 and trunk?  It has the code
in the uname() method, as you say.

Yes, please. Thanks.

Commited in trunk revision 58183 and 25-maint revision 58184.

Works for me.

I tried python-trunk-vistaplatform-v2.patch in one sample of 2006-11 
RTM Vista plus 2.5.1 Python plus this patch. I quote:

>>> import platform
>>> platform.uname()
('Windows', '[redacted]', 'Vista', '6.0.6000', '', '')
>>> platform.system()
'Windows'
>>> platform.version()
'6.0.6000'
>>>

--- USAGE:

I agree we should let people in future write:

if not platform.system('Windows'):

rather than:

if not (platform.system() in ('Microsoft', 'Windows')):

now that our people can no longer rely on Python in Vista correctly 
understanding the plain human intent of such code fragments as:

if platform.system() != 'Windows':

--- DRAFT SPEC:

platform.system(name = None) returns the system name if name is None, 
else returns the system name if name is a well-known alias of the 
system name, else returns None.

The string 'Mac OS X' is a well-known alias for the system 'Darwin'.

The string 'Windows' is a well-known alias for the system 'Microsoft' 
in 2.5.1 Python on Vista.

The system name is itself a well-known alias of the system name. For 
example, 'Darwin' is a well-known alias of the 'Darwin' system that is 
sold as the kernel of 'Mac OS X'.

Etc.

Pat, we already have system_alias() for exactly the purpose you suggested.

Software relying on platform.system() reporting "Vista" will have to use
Python 2.5.2 as minimum Python version system requirement - pretty much
the same as with all other bug fixes.

Thanks for the cultural education of 2.5.1 isn't supposed to work, I 
didn't know that.

Also I'm glad to hear this is fixed for 2.5.2 already.

Sorry I'm too new & ignorant to understand why you believe this is 
fixed. I don't see that we already have a way to say things like:

if not platform.system('Linux'):

Do we have a way to say things like that?

My first Googles, tried here now at Mac OS X, give me useless 
suggestions like:

>>> platform.platform(aliased=True)
'Darwin-9.0.0b5-i386-32bit'
>>> platform.system_alias(platform.system(), platform.release(), 
platform.version())
('Darwin', '9.0.0b5', 'Darwin Kernel Version 9.0.0b5: Fri Aug 17 
17:24:24 PDT 2007; root:xnu-1182~1/RELEASE_I386')
>>> 

Practically speaking, I was getting by ok with:

if platform.system() != 'Windows':

Until that broke in Vista plus 2.5.1.