Python 2.6 final and Python 3.0 rc1 do NOT install the python dlls into
the windows system directory, even when installing 'for all users' and
with admin rights.  This causes problems with COM objects implemented in
Python.

Observed on Windows XP SP3.

The following lines in msi.py seem to be the cause of the change:

   #dlldir = PyDirectory(db, cab, root, srcdir, "DLLDIR", ".")
   #install python30.dll into root dir for now
   dlldir = root

They were added by r61109: Bundle msvcr90.dll as a "private assembly".

I don't know if simply restoring the previous value will work in every 
case: If the C Run-Time is installed "privately", then python26.dll must
stay in c:\python26.

(And I thought that manifests and side-by-side assemblies were supposed 
to solve the "DLL hell")

> (And I thought that manifests and side-by-side assemblies were 
> supposed to solve the "DLL hell")

I'm now convinced that they make things worse, to the degree that
certain deployments that used to work cannot be longer made to work
(e.g. the Python setup of having DLLs and executables in different
directories).

This was one of the reasons why I resisted Python switching to VS 2005,
and hesitant to accept the switch to VS 2008. It is telling that the MS
merge module for the CRT automatically sets ALLUSERS=1, refusing even to
consider non-admin installs.

Going forward with py3k, we should try to drop even more dependencies on
the C library, and then perhaps try to link statically for the rest.

r61109 became obsolete when I added support for the merge module; here
is a patch that fixes this. An installer demonstrating the change is
available from

http://www.dcl.hpi.uni-potsdam.de/home/loewis/u/python-2.7.14165.msi

Committed as r66958, r66959, and r66960.