[PATCH STABLE] exewrapper: adapt for legazy HackableMercurial

Adrian Buehlmann adrian at cadifra.com
Wed Aug 1 01:00:20 CDT 2012

On 2012-08-01 03:20, Mads Kiilerich wrote:
> Adrian Buehlmann wrote, On 07/31/2012 10:16 PM:
>> Note that this *still* requires pythonXX.dll next to the hg.exe in the root
>> directory of HackableMercurial, or globally installed, for example, in
>> C:/Windows/system32. exewrapper makes no attempt whatsoever to locate
>> pythonXX.dll. It deliberately depends on standard Windows behavior for locating
>> that dll.
> Is it inherent to the way exewrapper works that it can't look for the 
> dll in other places? It can't be controlled on run-time?

Correct. Because that's the job of Windows.

That's a consequence of using the Python.h header, in combination with
the PythonXX.lib provided by CPython at compile time, and the
PythonXX.dll at runtime.

It also makes it simple and standard, as every other application on
Windows does it like that. With the consequence that the normal rules
for finding the pythonXX.dll at runtime apply.

I do consider that an advantage, as it's absolutely the same for
python.exe itself too: python.exe either has its pythonXX.dll right next
to it in the same directory where it is installed ("just for me" install
of Python), or the pythonXX.dll is installed system-wide: for Python
2.7, they choose to install it in C:/Windows/System32. But we should be
ignorant of that. So we should *not* have to put the full path of the
Python dll into the hashbang of the python script (like exemaker
requires it).

For a global install on a x64 system, the x64 python27.dll is installed
in C:/Windows/System32, whereas the x86 python27.dll is installed in
C:/Windows/SysWOW64. Which allows to have both the same x86 and x64
variant of the very same Python version installed on the same computer.
Windows will automatically pick the right location depending on bitness,
following its normal rules.

I am rather firmly convinced that trying to interfere with the normal
DLL load logic of Windows (bitness, manifests, assembly cache, whatever)
and trying to be clever as exemaker tries it for loading the Python dll,
is asking for troubles. And exemaker demonstrated that it wasn't able to
do it right. Perhaps someone might come up with a correct implementation
for exemaker on modern Windows platforms some day. But until that
happens, I'd really prefer not betting on it today and keep things
simple and stupid.

More information about the Mercurial-devel mailing list