[Python-Dev] DLL in the system directory on Windows.

[James C. Ahlstrom]

Guido van Rossum wrote:
> OK, it must be my overworked tired brain that is playing games with
> me.  It might have been Jim Ahlstrom then, our resident Windows 3.1
> supporter. :-)

I think I've been insulted.  What's wrong with Windows 3.1??   :-)
 
> > 1. Contra MS guidelines, dump the core DLLs in the system directory.

The Python DLL must really go in the Windows system directory.  I
don't see any other choice.  This is in accordance with Microsoft
guidelines AFAIK, or anyway, that's the only way it Just Works.  The
Python16.dll is a system file if you are using COM, and it supports
an embedded scripting language, so it goes into the system dir.  QED.

> > 3. Contra MS guidelines, put all the config options you can in a text file
> >        C:\name_of_app\name_of_app.ini
> >    instead of the registry.

This is an excellent practice, and there should be a standard module to
deal
with .ini files.  But, as you say, the registry is sometimes needed.

> > 4. This one was due to my boss:  Contra MS guidelines, put a copy of
> >    every MS system DLL you rely on under C:\name_of_app\, so you don't
> >    get screwed when MS introduces an incompatible DLL upgrade.

Yuk.  More trouble than it's worth.

> > > I've definitely heard people complain that it is evil to install
> > > directories in the system directory.  Seems there are different
> > > schools of thought...

It is very illegal to install directories as opposed to DLL's.  Do
you really mean directories?  If so, don't do that.

> > > Another issue: MSVCRT.DLL and its friend MSVCIRT.DLL will also go into
> > > the system directory.  I will now be distributing with the VC++ 6.0

If you distribute these, you must check version numbers and only replace
old versions.  Wise and other installers do this easily.  Doing
otherwise
is evil and unacceptable.  Checking file dates is not good enough
either.

> > > servicepack 1 versions of these files.  Won't this be a problem for
> > > installations that already have an older version?

Probably not, thanks to Microsoft's valiant testing efforts.

> > > (Now that I think
> > > of it, this is another reason why I decided that at least the alpha
> > > release should install everything in MAINDIR -- to limit the damage.
> > > Any informed opinions?)

Distribute these files with a valid Wise install script which checks
VERSIONS.

> One more thing that I just realized.  There are a few Python extension
> modules (_tkinter and the new pyexpat) that rely on external DLLs:
> _tkinter.pyd needs tcl83.dll and tk83.dll, and pyexpat.pyd needs
> xmlparse.dll and xmltok.dll.

Welcome to the club.

> If I understand correctly how the path rules work, these have to be on
> PATH too (although the pyd files don't have to be).  This worries me
> -- these aren't official MS DLLs and neither are the our own, so we
> could easily stomp on some other app's version of the same...
> (The tcl folks don't change their filename when the 3rd version digit
> changes, e.g. 8.3.0 -> 8.3.1, and expat has no versions at all.)
> 
> Is there a better solution?

This is a daily annoyance and risk in the Windows world.  If you require
Tk, then you need to completely understand how to produce a valid Tk
distribution.  Same with PIL (which requires Tk).  Often you won't
know that some pyd requires some other obscure DLL.  To really do this
you need something high level.  Like rpm's on linux.  On Windows, people
either write complex install programs with Wise et al, or run third
party installers provided with (for example) Tk from simpler install
scripts.  It is then up to the Tk people to know how to install it, and
how to deal with version upgrades.

JimA