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

[Guido van Rossum]

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

Now, now, you don't want to sound like Ted Kazinsky, do you? :-)

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

OK.  That means I need two separate variables: where to install the MS
DLLs and where to install the Py 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.

I just downloaded and installed it.  I've never seen an installer like
this -- they definitely put a lot of effort in it.  Annoying nit: they
tell you to install "MS Windows Installer" first, and of course, being
a MS tool, it requires a reboot. :-(

Anyway, ActivePerl installs its DLLs (all 5) in c:\Perl\bin\.  So
there.  It also didn't change PATH for me, even though the docs
mention that it does -- maybe only on NT?

(PATH on Win9x is still a mystery to me.  Is it really true that in
order to change PATH an installer has to edit autoexec.bat?  Or is
there a better way?  Anything that claims to change PATH for me
doesn't seem to do so. Could I have screwed something up?)

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

OK, got it.

But I'm still hoping that there's something we can do differently.

Didn't someone tell me that at least on Windows 2000 installing
app-specific files (as opposed to MS-provided files) in the system
directory is a no-no?  What's the alternative there?  Is the same
mechanism supported on NT or Win98?

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