This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Title: python dll not installed in windows system directory
Type: behavior Stage:
Components: Installation Versions: Python 3.0, Python 2.6
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: loewis Nosy List: amaury.forgeotdarc, loewis, mhammond, theller
Priority: normal Keywords: needs review, patch

Created on 2008-10-09 18:20 by theller, last changed 2022-04-11 14:56 by admin. This issue is now closed.

File name Uploaded Description Edit
system32.diff loewis, 2008-10-13 13:57
Messages (5)
msg74591 - (view) Author: Thomas Heller (theller) * (Python committer) Date: 2008-10-09 18:20
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

Observed on Windows XP SP3.
msg74597 - (view) Author: Amaury Forgeot d'Arc (amaury.forgeotdarc) * (Python committer) Date: 2008-10-09 19:48
The following lines in 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")
msg74602 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-09 20:52
> (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

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.
msg74686 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-13 13:57
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
msg74907 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-10-17 13:48
Committed as r66958, r66959, and r66960.
Date User Action Args
2022-04-11 14:56:40adminsetgithub: 48341
2008-10-17 13:48:14loewissetstatus: open -> closed
resolution: fixed
messages: + msg74907
2008-10-13 13:57:37loewissetkeywords: + patch, needs review
files: + system32.diff
messages: + msg74686
2008-10-09 22:36:27mhammondsetnosy: + mhammond
2008-10-09 20:52:53loewissetassignee: loewis
messages: + msg74602
nosy: + loewis
2008-10-09 19:48:06amaury.forgeotdarcsetnosy: + amaury.forgeotdarc
messages: + msg74597
2008-10-09 18:20:22thellercreate