Python DLL in Windows Folder

[Lie]

On Dec 25, 3:04 am, "Markus Gritsch" <m.grit... at gmail.com> wrote:
> On 24/12/2007, Chris Mellon <arka... at gmail.com> wrote:
>
>
>
> > On Dec 23, 2007 12:27 PM, Markus Gritsch <m.grit... at gmail.com> wrote:
> > > On 23/12/2007, Christian Heimes <li... at cheimes.de> 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