On Dec 25, 3:04 am, "Markus Gritsch" <[EMAIL PROTECTED]> wrote: > On 24/12/2007, Chris Mellon <[EMAIL PROTECTED]> wrote: > > > > > On Dec 23, 2007 12:27 PM, Markus Gritsch <[EMAIL PROTECTED]> wrote: > > > On 23/12/2007, Christian Heimes <[EMAIL PROTECTED]> wrote: > > > > Markus Gritsch wrote: > > > > > why does the Python installer on Windows put the Python DLL into the > > > > > Windows system32 folder? Wouldn't it be more clean to place it into > > > > > the Python installation folder beside the python.exe file? > > > > > It's the easiest and best way to expose Python for 3rd party > > > > applications and COM. The DLL is removed by the Windows Installer when > > > > its usage counter drops to 0. There is no need to worry ;) > > > > I am not worrying about an orphaned DLL. The Problem is that this way > > > the Python DLL is being made available for 3rd party applications, > > > which possibly need a version of Python which is compiled using > > > another compiler. We are embedding Python into our application which > > > gets compiled using MSVC 8.0. We like to link dynamically, so the > > > Python interpreter is not statically linked into the program. The > > > Python DLL from the Python installer in the Windows system32 folder is > > > compiled using MSVC 7.1. > > > What the python installer is doing is the Right Thing for making the > > standard python dll available to third party applications. > > But this forces the 3rd party application being compiled with the same > compiler as the Python DLL which is MSVC 7.1 for Python 2.5 which is a > quite old compiler nowadays.
Unfortunately, Windows doesn't give a lot of support around preventing DLL duplication. It is regular to found multiple duplicate DLLs on a Windows system (especially for different version), a common example is msvcrtxx.dll, which is C's runtime, many program pack their own msvcrt into their installation package. Therefore it is important for a windows program to include all the required DLLs into the installer package and use their own, unless they're sure that they can use other version (good programs are not DLL implementation specific and good DLLs maintain a stable interface). > > Applications that want a specific version of a specific DLL should use > > the mechanisms available for doing so, instead of relying on there > > being a specific version of the python dll in the windows folder. > > We do not rely on having some specific version of the Python DLL in > the Windows system 32 folder. However, the MSVC 7.1 compiled version > gets in the way when using a different compiler. If that's the case, just use the MSVC 7.1's compiled code, there won't be much difference. 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. That's the Best Practice in Windows. > Kind regards, > Markus -- http://mail.python.org/mailman/listinfo/python-list
