Andrew MacIntyre wrote:
You can then use another compiler supported by the
Distutils (MS CL non-optimising compiler, MinGW,
Borland etc) to build the distributable extension in
either a Python 2.2 or 2.3 installation, without risking
mixing C runtime library mismatches (VS.NET uses a
different CRT than VS6 I understand). If using a 2.3
installation, you'll need to substitute a 2.2 import
library when building the final distributable version.
Do I understand you correctly? It sounds like you are saying there is a
problem using a DLL built with VC6 and another DLL built with VS.NET in the
same application, but if you were to use a Borland or other compiler, then
you would avoid this problem.
That's not right at all. It's commonplace to have multiple DLLs loaded into
a Windows application, all built with different compilers and all using
different C runtimes. You can have one built with VC6, another with VS.NET,
and another with Borland or any other compiler. You certainly don't need to
build a DLL with Borland instead of VS.NET to avoid conflicts with another
DLL that was built with VC6.
If python22.dll has some incompatibility with other DLLs that are built with
VS.NET, then there is something seriously wrong with python22.dll.
If I misunderstood you, let me know what it was that you were getting at
here.
BTW, if you're distributing a DLL or application built with VS.NET, you do
need to make sure that the appropriate C runtime is available on the target
system. In many cases, the best way to do this is to compile and link with
the static C runtime instead of the DLL C runtime. If you use the DLL
version of the C runtime, you need to distribute it with your app or DLL.
To be sure of what other DLLs (C runtimes or whatever) your DLL or app
depends on, the best tool is Dependency Walker:
www.dependencywalker.com
-Mike
