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

[Guido van Rossum]

> [Guido]
> > ...
> > I'm waiting for Tim Peters' response in this thread -- if I recall he
> > was the one who said that python1x.dll should not go into the system
> > directory.

[Tim]
> Not that I don't say a lot of dumb-ass things <wink>, but I strongly doubt I
> would have said this one.

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. :-)

> In my brief career as a Windows app provider, I
> learned four things, the first three loudly gotten across by seriously
> unhappy users:
> 
> 1. Contra MS guidelines, dump the core DLLs in the system directory.
> 2. Contra MS guidelines, install the app by default in C:\name_of_app\.

It's already been said that the drive letter could be chosen more
carefully.

I wonder if the pathname should also be an 8+3 (max) name, so that it
can be relyably typed into a DOS window.

> 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.
> 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.
> 
> In the end, the last one is the only one I disagreed with (in recent years I
> believe MS DLL upgrades have gotten much more likely to fix bugs than to
> introduce incompatibilities; OTOH, from Tcl to Macsyma Pro I see 6 apps on
> my home machine that use their own copy of msvcrt.dll -- /F, if you're
> reading, how come the Pythonworks beta does this?).

Probably because Pythonworks doesn't care about COM or embedding.

Anyway, I now agree with you on 1-2 and on not following 4.  As for 3,
I think that for Mark's COM support to work, the app won't necessarily
be able to guess what \name_of_app\ is, so that's where the registry
comes in handy.  PATH info is really about all that Python puts in the
registry, so I think we're okay here.  (Also if you read PC\getpathp.c
in 1.6, you'll see that it now ignores most of the registry when it
finds the installation through a search based on argv[0].)

> > ...
> > I've definitely heard people complain that it is evil to install
> > directories in the system directory.  Seems there are different
> > schools of thought...
> 
> Well, mucking with the system directories is horrid!  Nobody likes doing it.
> AFAIK, though, there's really no realistic alternative.  It's the only place
> you *know* will be on the PATH, and if an app embedding Python can't rely on
> PATH, it will have to hardcode the Python DLL path itself.
> 
> > 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
> > servicepack 1 versions of these files.  Won't this be a problem for
> > installations that already have an older version?  (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?)
> 
> You're using a std installer, and MS has rigid rules for these DLLs that the
> installer will follow by magic.  Small comfort if things break, but this one
> is (IMO) worth playing along with.

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.

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?

--Guido van Rossum (home page: http://www.python.org/~guido/)