This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: 32-bit Python on 64-bit Windows reports incorrect architecture
Type: behavior Stage: resolved
Components: Library (Lib), Windows Versions: Python 3.2, Python 2.7
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: r.david.murray Nosy List: brian.curtin, lemburg, pitrou, r.david.murray, santoso.wijaya
Priority: normal Keywords: patch

Created on 2010-02-05 18:07 by brian.curtin, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
arch_misrepresented.diff brian.curtin, 2010-02-05 18:07 patch against trunk
uname_WOW64_test.patch r.david.murray, 2010-03-20 01:24
uname_WOW64_test2.patch brian.curtin, 2010-03-22 14:02
Messages (11)
msg98890 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-02-05 18:07
When running 32-bit Python on a 64-bit version of Windows, therefore running the process in WOW64 mode, platform.machine returns a misleading value. When running in WOW64, the processor architecture is masked to appear as "x86" when the machine is actually "AMD64" (which you see on a 64-bit app on 64-bit OS).

The change involves looking at an environment variable only set on WOW64 processes to see the native architecture. See http://blogs.msdn.com/david.wang/archive/2006/03/26/HOWTO-Detect-Process-Bitness.aspx

The patch does not include any test, as I'm not really sure how you could test this without using the change itself to figure out when it should be tested. Suggestions would be appreciated.
msg98896 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-02-05 19:20
It's also inconsistent with Linux behaviour:

>>> import sys 
>>> sys.maxsize
2147483647
>>> import platform
>>> platform.machine()
'x86_64'
>>> platform.architecture()
('32bit', 'ELF')

(on a Python compiled with "-m32" on a 64-bit Linux)
msg98897 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-02-05 19:23
The test could simply check that platform.machine() never returns "x86" when sys.maxsize is greater than 2**32.
(and it would even be platform-agnostic)
msg98902 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-02-05 19:43
The patch looks ok. Since we are emulating the Unix uname() function here, we might as well mimic its inconsistencies.

Note that platform.machine() and platform.processor() are not really very reliable ways of determining the machine type or processor.
msg98922 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-02-05 23:56
Antoine Pitrou wrote:
> 
> Antoine Pitrou <pitrou@free.fr> added the comment:
> 
> The test could simply check that platform.machine() never returns "x86" when sys.maxsize is greater than 2**32.
> (and it would even be platform-agnostic)

I'm not sure what such a test would prove, e.g. on 64-bit Mac OS X,
platform.machine() return 'i386'. That could be mapped to 'x86'...

Note that 'x86_64' is just a 'x86' compatible processor with
the AMD 64-bit extensions, so 'x86' is a superset of 'x86_64'.
msg98926 - (view) Author: Antoine Pitrou (pitrou) * (Python committer) Date: 2010-02-06 00:32
> I'm not sure what such a test would prove, e.g. on 64-bit Mac OS X,
> platform.machine() return 'i386'. That could be mapped to 'x86'...

You're right. There doesn't seem to be much consistency accross
platforms.

> Note that 'x86_64' is just a 'x86' compatible processor with
> the AMD 64-bit extensions, so 'x86' is a superset of 'x86_64'.

Oops, indeed.
msg101331 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-03-19 15:17
#7347 depends on this for proper testing, and arch_misrepresented.diff seems to have been labeled as acceptable. Would anyone be willing to check it in?
msg101352 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-03-20 01:24
I think it is actually pretty straightforward to write a *unit* test for this.  We just need to check that the logic works correctly given the expected presence or absence of the environment variables.  That doesn't test whether or not the right thing happens in the environment when you actually run a WOW64, but I don't think it is Python's responsibility to test that.  If Microsoft changes the API, platform will break and the tests won't notice, but I don't think there's anything we can do about that, since as you say the API is the only way to find out what to expect for results.

Test patch attached.  Brian, if you can confirm that this test fails before your patch and succeeds afterward, I will commit both patches.
msg101509 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-03-22 14:02
Ah, that's simple enough :)

Minor changes to the test patch: uname caches it's results, so I added a few lines to clear the cache before the uname calls. In order to not affect other tests, the whole thing is in a try/finally so we don't leave anything behind in cache.

The test passes on both a 32 and 64 bit Python.
msg101524 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-03-22 18:22
Patches applied to trunk in r79294, py3k in r79298.  Should this be backported?
msg101528 - (view) Author: Marc-Andre Lemburg (lemburg) * (Python committer) Date: 2010-03-22 19:47
R. David Murray wrote:
> 
> R. David Murray <rdmurray@bitdance.com> added the comment:
> 
> Patches applied to trunk in r79294, py3k in r79298.  Should this be backported?

I don't think so: applications relying on the previous behavior
would need to be updated and requiring this for a patch level
release of Python is not a good idea.
History
Date User Action Args
2022-04-11 14:56:57adminsetgithub: 52108
2011-06-13 19:53:31santoso.wijayasetnosy: + santoso.wijaya
2010-03-23 01:56:12r.david.murraysetstatus: open -> closed
keywords: patch, patch
stage: commit review -> resolved
resolution: accepted -> fixed
versions: - Python 2.6, Python 3.1
2010-03-22 19:47:40lemburgsetmessages: + msg101528
2010-03-22 18:22:08r.david.murraysetkeywords: - needs review

messages: + msg101524
stage: patch review -> commit review
2010-03-22 14:02:52brian.curtinsetkeywords: patch, patch, needs review
files: + uname_WOW64_test2.patch
messages: + msg101509
2010-03-20 01:24:09r.david.murraysetfiles: + uname_WOW64_test.patch

nosy: + r.david.murray
messages: + msg101352

assignee: r.david.murray
keywords: patch, patch, needs review
2010-03-19 15:17:29brian.curtinsetkeywords: patch, patch, needs review

messages: + msg101331
2010-02-23 15:04:06brian.curtinsetkeywords: patch, patch, needs review
resolution: accepted
2010-02-06 19:01:49brian.curtinlinkissue7347 dependencies
2010-02-06 00:32:32pitrousetmessages: + msg98926
2010-02-05 23:56:22lemburgsetmessages: + msg98922
2010-02-05 19:43:29lemburgsetkeywords: patch, patch, needs review

messages: + msg98902
2010-02-05 19:23:05pitrousetkeywords: patch, patch, needs review

messages: + msg98897
2010-02-05 19:20:32pitrousetkeywords: patch, patch, needs review
nosy: + pitrou
messages: + msg98896

2010-02-05 19:16:55pitrousetkeywords: patch, patch, needs review
nosy: + lemburg
2010-02-05 18:07:49brian.curtincreate