Fix _win32_check_running_pid on natvie windows
Created attachment 101595 [details] Patch
Comment on attachment 101595 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101595&action=review > Tools/Scripts/webkitpy/common/system/executive.py:254 > - ("szExeFile", ctypes.c_char * 260)] > + ("szExeFile", ctypes.c_char * 260), > + ("th32MemoryBase", ctypes.c_long), > + ("th32AccessKey", ctypes.c_long)] I don't see these new members mentioned here: <http://msdn.microsoft.com/en-us/library/ms684839(v=vs.85).aspx>. Looks like they only exist in the WinCE version of the struct. So I think we need to detect whether we're on WinCE or not. Otherwise won't this break non-CE builds?
Comment on attachment 101595 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101595&action=review >> Tools/Scripts/webkitpy/common/system/executive.py:254 >> + ("th32AccessKey", ctypes.c_long)] > > I don't see these new members mentioned here: <http://msdn.microsoft.com/en-us/library/ms684839(v=vs.85).aspx>. Looks like they only exist in the WinCE version of the struct. So I think we need to detect whether we're on WinCE or not. Otherwise won't this break non-CE builds? This is not related to WinCE! I try the get the native windows python test all pass on my windows box (german Windwos 7 Professional SP1 64bit). I tried different versions of this patch, but this is the only one which workded for me. :-/ Any idea why the function fails on my box without the two additional members?
Comment on attachment 101595 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101595&action=review >>> Tools/Scripts/webkitpy/common/system/executive.py:254 >>> + ("th32AccessKey", ctypes.c_long)] >> >> I don't see these new members mentioned here: <http://msdn.microsoft.com/en-us/library/ms684839(v=vs.85).aspx>. Looks like they only exist in the WinCE version of the struct. So I think we need to detect whether we're on WinCE or not. Otherwise won't this break non-CE builds? > > This is not related to WinCE! > I try the get the native windows python test all pass on my windows box (german Windwos 7 Professional SP1 64bit). > I tried different versions of this patch, but this is the only one which workded for me. :-/ > Any idea why the function fails on my box without the two additional members? Hm, I wonder if we need to be using ctypes.c_wchar instead of ctypes.c_char for the szExeFile parameter? I can't tell from the code whether we're calling Process32FirstW or Process32FirstA.
Comment on attachment 101595 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=101595&action=review >>>> Tools/Scripts/webkitpy/common/system/executive.py:254 >>> >>> I don't see these new members mentioned here: <http://msdn.microsoft.com/en-us/library/ms684839(v=vs.85).aspx>. Looks like they only exist in the WinCE version of the struct. So I think we need to detect whether we're on WinCE or not. Otherwise won't this break non-CE builds? >> >> This is not related to WinCE! >> I try the get the native windows python test all pass on my windows box (german Windwos 7 Professional SP1 64bit). >> I tried different versions of this patch, but this is the only one which workded for me. :-/ >> Any idea why the function fails on my box without the two additional members? > > Hm, I wonder if we need to be using ctypes.c_wchar instead of ctypes.c_char for the szExeFile parameter? I can't tell from the code whether we're calling Process32FirstW or Process32FirstA. There is no Process32FirstA: Form http://msdn.microsoft.com/en-us/library/ms684834%28v=vs.85%29.aspx: Process32FirstW (Unicode) and Process32First (ANSI) So I think we call the ansi version here. A ctypes.sizeof PROCESSENTRY32 also returns the same size as in C code. Does this code work on your box with "natvie python"?
Created attachment 102461 [details] Patch Seams to be a problem of 64bit python, not windows :-)
Comment on attachment 102461 [details] Patch Clearing flags on attachment: 102461 Committed r92188: <http://trac.webkit.org/changeset/92188>
All reviewed patches have been landed. Closing bug.