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

[Greg Stein]

On Mon, 3 Apr 2000, Guido van Rossum wrote:
>...
> Actually, I just wanted to get the discussion started.  It worked. :-)

hehe. True :-)

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

What's his physical address again? I have this nice little package to send
him...

>...
> > IMO, put the DLL back into System32. If somebody can *demonstrate* (not
> > hypothesize) a mechanism that works, then it can be switched.
> > 
> > The underlying issue is this: Python16.dll in the app directory works for
> > Python as an executable. However, it completely disables any possibility
> > for *embedding* Python. On Windows, embedding is practically required
> > because of the COM stuff (sure... a person could avoid COM but...).
> 
> Yes, I know this.  I'm just not happy with it, and 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 evil, but it is also unavoidable. The alternative is to munge the
PATH variable, but that is a Higher Evil than just dropping DLLs into the
system directory.

> 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?

Not at all. In fact, Microsoft explicitly recommends including those in
the distribution and installing them over the top of *previous* versions.
They should never be downgraded (i.e. always check their version stamp!),
but they should *always* be upgraded.

Microsoft takes phenomenal pains to ensure that OLD applications are
compatible with NEW runtimes. It is certainly possible that you could have
a new app was built against a new runtime, and breaks when used against an
old runtime. But that is why you always upgrade :-)

And note that I do mean phenomenal pains. It is one of their ship
requirements that you can always drop in a new RT without breaking old
apps.

So: regardless of where you decide to put python16.dll, you really should
be upgrading the RT DLLs.

> David Ascher: if you're listening, could you forward this to someone
> at ActiveState who might understand the issues here?  They should have
> the same problems with ActivePerl, right?  Or don't they have COM
> support?

ActivePerl does COM, but I dunno much more than that.

> (Personally, I think that it wouldn't be so bad if we made it so that
> if you install just Python, the DLLs go into MAINDIR -- if you install
> the COM support, it can move/copy them to the system directory.  But
> you may find this inelegant...)

Eek. Now you're talking about one guy reaching into another installation
and munging it around. Especially for a move (boy, would that throw off
the uninstall!). If you copied, then it is possible to have *two* copies
of the DLL loaded into a process. The primary key is the pathname. I've
had two pythoncom DLLs loaded in a process, and boy does that suck! The
bugs are quite interesting, to say the least :-) And a total bear to track
down until you have seen the double-load several times and can start to
recognize the effects.

In other words, moving is bad for elegance/uninstall reasons, and copy is
bad for (potential) runtime reasons.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/