Issue 2745: Add support for IsWow64Process (original) (raw)

Created on 2008-05-03 00:22 by mhammond, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
iswow64process.patch mhammond,2008-05-03 00:22 Add the function, docs, news and a test
Messages (7)
msg66137 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2008-05-03 00:22
As per a thread on python-dev, I offered to add sys.iswow64process. I'm attaching a patch that does this (including news, docs and tests). I'm adding Martin to the nosy list as he has expressed reservations ("It sounds like clutter of the sys module to me"), so I expect this to be rejected.
msg66146 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-05-03 07:29
I think this can be just as well done with (untested, as I don't have access to a Windows system right now) def iswow64(): if platform.getarchitecture()[0] == '64-bit':return False return os.environ["PROCESSOR_ARCHITECTURE"] != "x86" IOW, it's wow64 iff it's a 32-bit Python not running on an x86 machine.
msg66188 - (view) Author: Mark Hammond (mhammond) * (Python committer) Date: 2008-05-04 02:14
I'm not sure if that is suggesting MS had no reason to add that API function, or those reasons don't apply to users of Python, but as its clear there is significant resistance I'm rejecting this report.
msg66190 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-05-04 04:53
One reason for IsWow64Process is that it allows to determine the wow-ness of a different process, which is e.g. needed to display the asterisk in the process viewer. This reason indeed doesn't apply to Python, and your patch doesn't expose that functionality.
msg115855 - (view) Author: Pete Bartlett (pcb21) Date: 2010-09-08 09:54
Hi, I am a Python user seeking an implementation of iswow64 and found this tracker. Unfortunately I don't think Martin's suggested alternative approach works. os.environ["PROCESSOR_ARCHITECTURE"] returns "x86" on my system when run from a 32-bit python, even though if I look at my "real" environment I see D:\>echo %PROCESSOR_ARCHITECTURE% AMD64 i.e it appears that Windows is passing "false information", if you will, to whatever populates os.environ in 32-bit windows. Perhaps Mark's patch should be resurrected. Or is there a further way to get this information? [My Python version information: D:\>python ActivePython 2.6.5.12 (ActiveState Software Inc.) based on Python 2.6.5 (r265:79063, Mar 20 2010, 14:22:52) [MSC v.1500 32 bit (Intel)] on win32 ]
msg115902 - (view) Author: Brian Curtin (brian.curtin) * (Python committer) Date: 2010-09-08 21:12
os.environ["PROCESSOR_ARCHITEW6432"] will tell you the true underlying processor architecture when under WOW. Therefore, if you find that this variable exists, you are under WOW. Example, on my 64-bit machine with a 32-bit compiled Python: Python 3.1.2 (r312:79149, Mar 21 2010, 00:41:52) [MSC v.1500 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import os >>> os.environ["PROCESSOR_ARCHITECTURE"] 'x86' >>> os.environ["PROCESSOR_ARCHITEW6432"] 'AMD64'
msg115947 - (view) Author: R. David Murray (r.david.murray) * (Python committer) Date: 2010-09-09 14:11
See also Issue7860.
History
Date User Action Args
2022-04-11 14:56:33 admin set github: 46994
2010-09-09 14:11:47 r.david.murray set nosy: + r.david.murraymessages: +
2010-09-08 21:12:13 brian.curtin set nosy: + brian.curtinmessages: +
2010-09-08 09:54:49 pcb21 set nosy: + pcb21messages: +
2008-05-04 04:53:18 loewis set messages: +
2008-05-04 02:14:59 mhammond set status: open -> closedresolution: rejectedmessages: +
2008-05-03 07:29:24 loewis set messages: +
2008-05-03 00:22:44 mhammond create