S
sturlamolden
This question has been asked many times, and last time I was accused of
spreading FUD. So now I will rather propose a solution.
The reason for the problem is as follows:
The binary installer for Python built by te python.org team is compiled
with Microsoft Visual Studio 2003. It is linked with the C runtime
msvcrt71.dll. The copyright to msvcrt71.dll is owned by Microsoft, and
it is not an integral part of the Windows operating system. This leads
to two distinct problems:
Problem 1: You want to use a particular compiler to build a Python
extension library, but it links with the wrong CRT. Typical examples
are MinGW, Microsoft Visual C++ 6.0 and Microsoft Visual C++ Express.
There is a remedy for MinGW, but not for the other two.
Problem 2: You want to distribute a program created Py2Exe, but has no
license for Visual Studio 2003. You are therefore not allowed to
redistribute msvcrt71.dll. But without this DLL your program will not
work. As a side note: Visual Studio 2003 is out of sale, so if you
don't have it already you may be out of luck.
The solution: modify the IAT of to use the correct binary.
The process is really simple:
Solution to problem 1:
Compile with your compiler or choice, never mind which CRT are used.
Use a 'dumpbin' program, find all references to msvcrt in the binary
DLL file. Create a dll with name "py_crt" that exports these functions
but redirects them to msvcrt71. That is, in the file py_crt.def we put
something like
EXPORTS
malloc=msvcr71.malloc
free=msvcr71.free
etc.
Compile the DLL py_crt.dll and then open your pyd file in binary mode.
Exchange all occurances of the string "msvcrt" (or any other CRT name)
with "py_crt". Now your binary should work just fine. What you need to
make sure is just that the name of the proxy has the same number of
letters as the CRT your compiler linked. So if it is msvcrt81.dll, e.g.
use something like py_crt81.dll instead of py_crt.dll.
Solution to problem 2:
This would be the opposite, involving modifying Python25.dll and all
pyd and dll files gathered by Py2Exe to use msvcrt.dll instead of
msvcr71.dll. One could e.g. create a DLL called py_cr71.dll that
redirects CRT calls to msvcrt.dll or any other CRT of choice. In
py_cr71.def we would then have:
EXPORTS
malloc=msvcrt.malloc
free=msvcrt.free
etc.
And then it is simply a matter of modifying the binaries to load
py_cr71.dll instead of msvcrt71.dll.
What we need to make this work:
1. A dumpbin facility similar to the one that ships with Visual Studio
that can be freely distributed.
2. A python script that parses the output from dumpbin, creates the
proxy and redirects the CRT. (I already have such a script working.)
Finally, a setup script (setup.py) could automate this task for
"problem 1" above.
Another variant of the fake-CRT procedure, which would also work, is to
create a fake msvcrt71.dll that redirects to your CRT of choice, and
replace the msvcrt71.dll that came with Python with that. That is
conceptually simpler, as it involves not binary modifications, but
someone might mistake your msvcrt71.dll for the msvcrt71.dll from
Microsoft. Also antivirus-software might not like attempts to load such
a DLL as it would look like your program is hijacked by a trojan
(although it is not).
What do you think?
spreading FUD. So now I will rather propose a solution.
The reason for the problem is as follows:
The binary installer for Python built by te python.org team is compiled
with Microsoft Visual Studio 2003. It is linked with the C runtime
msvcrt71.dll. The copyright to msvcrt71.dll is owned by Microsoft, and
it is not an integral part of the Windows operating system. This leads
to two distinct problems:
Problem 1: You want to use a particular compiler to build a Python
extension library, but it links with the wrong CRT. Typical examples
are MinGW, Microsoft Visual C++ 6.0 and Microsoft Visual C++ Express.
There is a remedy for MinGW, but not for the other two.
Problem 2: You want to distribute a program created Py2Exe, but has no
license for Visual Studio 2003. You are therefore not allowed to
redistribute msvcrt71.dll. But without this DLL your program will not
work. As a side note: Visual Studio 2003 is out of sale, so if you
don't have it already you may be out of luck.
The solution: modify the IAT of to use the correct binary.
The process is really simple:
Solution to problem 1:
Compile with your compiler or choice, never mind which CRT are used.
Use a 'dumpbin' program, find all references to msvcrt in the binary
DLL file. Create a dll with name "py_crt" that exports these functions
but redirects them to msvcrt71. That is, in the file py_crt.def we put
something like
EXPORTS
malloc=msvcr71.malloc
free=msvcr71.free
etc.
Compile the DLL py_crt.dll and then open your pyd file in binary mode.
Exchange all occurances of the string "msvcrt" (or any other CRT name)
with "py_crt". Now your binary should work just fine. What you need to
make sure is just that the name of the proxy has the same number of
letters as the CRT your compiler linked. So if it is msvcrt81.dll, e.g.
use something like py_crt81.dll instead of py_crt.dll.
Solution to problem 2:
This would be the opposite, involving modifying Python25.dll and all
pyd and dll files gathered by Py2Exe to use msvcrt.dll instead of
msvcr71.dll. One could e.g. create a DLL called py_cr71.dll that
redirects CRT calls to msvcrt.dll or any other CRT of choice. In
py_cr71.def we would then have:
EXPORTS
malloc=msvcrt.malloc
free=msvcrt.free
etc.
And then it is simply a matter of modifying the binaries to load
py_cr71.dll instead of msvcrt71.dll.
What we need to make this work:
1. A dumpbin facility similar to the one that ships with Visual Studio
that can be freely distributed.
2. A python script that parses the output from dumpbin, creates the
proxy and redirects the CRT. (I already have such a script working.)
Finally, a setup script (setup.py) could automate this task for
"problem 1" above.
Another variant of the fake-CRT procedure, which would also work, is to
create a fake msvcrt71.dll that redirects to your CRT of choice, and
replace the msvcrt71.dll that came with Python with that. That is
conceptually simpler, as it involves not binary modifications, but
someone might mistake your msvcrt71.dll for the msvcrt71.dll from
Microsoft. Also antivirus-software might not like attempts to load such
a DLL as it would look like your program is hijacked by a trojan
(although it is not).
What do you think?