Re: Python DLL in Windows Folder

On 26/12/2007, Lie Ryan <lie.1296@xxxxxxxxx> wrote:


On Dec 25, 2007 4:43 PM, Markus Gritsch <m.gritsch@xxxxxxxxx> wrote:
On 24/12/2007, Lie <Lie.1296@xxxxxxxxx> wrote:

(good programs are not DLL implementation specific

Assume an application embedding Python being compiled with MSVC 8.0.
It uses the runtime msvcr80.dll. If you now pass objects created in
your application to the Python interpreter which is compiled with MSVC
7.1 which uses msvcr71.dll, you are asking for serious trouble. It is
not a matter of being a "good program".

don't cut my word, good programs aren't DLL implementation specific and good
DLL have consistent interface (consistent interface implies consistent
behavior). Of course this is a bit "utopia", as most DLL would sadly have to
change its interfaces once or twice and it is sometimes impossible for
programs to be completely free from its DLLs implementation

Instead of being upset about cutting your word (which was not my
intention, sorry about that), it would be nice if you could make a
statement concerning the problem I mentioned: Having an object being
created by one MSVC runtime, msvcr80.dll and passing it to another
one, msvcr71.dll.

If that's the case, just use the MSVC 7.1's compiled code, there won't
be much difference.

See above.


I think you don't get my point... if you don't modify the python interpreter
(from what I understand, you just recompile your Python DLL without
modification), there is no need to compile your own interpreter, it just
makes problem and the performance benefits is outweighed by the problems of
having to use 3rd party Python DLL (even if you don't modify the code and
just recompile it, it is not the official release, thus 3rd party).

I do get your point, but your point is maintaining compatibility
between two different *versions* of a DLL/Program. I am talking about
having a DLL/Program combination which uses different MSVC runtimes.

If you insist to use your own version (or don't
have a choice), you could instead pack your own DLL, use the local
DLL, and ignore the system's DLL.

Yes, that works fine when deploying the application. However, during
development it is inconveninent to put our own Python DLL beside our
executable every time. Our Python DLL (compiled with MSVC 8.0) is in
the PATH. If the original Python DLL would be located in the Python
installation folder, there would be no problem. But since it is
placed in the system32 folder which is searched before the PATH

(http://msdn2.microsoft.com/en-us/library/ms682586(VS.85).aspx),
the
original Python DLL (compiled with MSVC 7.1) is used instead of your
own one.

If that is the case, you could just simply substitute the system32's dll
with your in the test machine. If you don't want to dirty the system
(perhaps because you use the system for other things too), then you could
benefit from dual booting or virtualization technology.

Dual Booting is putting two (almost) completely seperate OSes in a single
machine.
Virtualization is a technology that allows an OS to be run inside another
OS, an example would be VMWare. This result in degraded performance in the
client OS, but it's easier to manage than Dual Booting.

You don't need any special program to set up a dual boot system, although
you might require special knowledge on how to do it. For virtualization
technology, VMWare and Microsoft have a free version of their virtual
machines. So basically, these two set ups costs nothing.

Thank you for explaining that.
.

Relevant Pages