[PATCH] win32: fix unicode error caused by GetModuleFileNameEx (issue2480)

[Steve Borho]

On Wed, Nov 10, 2010 at 3:36 AM, Martin Geisler <mg at aragost.com> wrote:
> Yuya Nishihara <yuya at tcha.org> writes:
>
>> Oops, I CC-ed to BTS address wrongly, sorry.
>>
>> Yuya Nishihara wrote:
>>> # HG changeset patch
>>> # User Yuya Nishihara <yuya at tcha.org>
>>> # Date 1289320880 -32400
>>> # Node ID 08d6ea6440e222ee6530fef95aafd0b9b6d45e8f
>>> # Parent  9f2ac318b92e3bde06108bf8493b7d71219ad13e
>>> win32: fix unicode error caused by GetModuleFileNameEx (issue2480)
>> ...
>>> diff --git a/mercurial/win32.py b/mercurial/win32.py
>>> --- a/mercurial/win32.py
>>> +++ b/mercurial/win32.py
>>> @@ -106,6 +106,7 @@ def system_rcpath_win32():
>>>      try:
>>>          # This will fail on windows < NT
>>>          filename = win32process.GetModuleFileNameEx(proc, 0)
>>> +        filename = filename.encode(encoding.encoding)
>>>      except:
>>>          filename = win32api.GetModuleFileName(0)
>>>      # Use mercurial.ini found in directory with hg.exe
>>
>> I'm not pretty sure, but possibly it doesn't need to use
>> GetModuleFileName'Ex'.
>>
>> http://msdn.microsoft.com/en-us/library/ms683197(VS.85).aspx
>> http://msdn.microsoft.com/en-us/library/ms683198(v=VS.85).aspx
>>
>> GetModuleFileName'Ex' seems available to get a filename of
>> another process.
>
> Yes, I skimmed the second URL and found this
>
>  Remarks
>
>  The GetModuleFileNameEx function is primarily designed for use by
>  debuggers and similar applications that must extract module
>  information from another process. If the module list in the target
>  process is corrupted or is not yet initialized, or if the module list
>  changes during the function call as a result of DLLs being loaded or
>  unloaded, GetModuleFileNameEx may fail or return incorrect
>  information.
>
>  To retrieve the name of a module in the current process, use the
>  GetModuleFileName function. This is more efficient and more reliable
>  than calling GetModuleFileNameEx with a handle to the current process.
>
> So perhaps the whole try-block should be removed?

+1

-- 
Steve Borho