As noted in https://github.com/python/cpython/tree/master/Tools/msi
===
When installed for all users, the following files are installed to
either "%SystemRoot%\System32" or "%SystemRoot%\SysWOW64" as
appropriate. For the current user, they are installed in the Python
install directory.

.\python3x.dll      The core interpreter
.\python3.dll       The stable ABI reference
===

However, at least with the Python 3.5.3 and Python 3.6.0 installers from the official download page, even an all-users install puts the relevant DLLs in the installation directory instead.

This is the both with the command-line option and checking the relevant box during installation.

I've also confirmed that it happens whether you add Python to the path or not. The latter is my use-case as I have multiple versions of Python installed and use the Python Launcher for Windows to select a version to run or virtualenv to build.

Looking at the source, I suspect this feature was completely lost when the MSI build system was rewritten in commit https://github.com/python/cpython/commit/bb24087a2cbfb186b540cc71a74ec8c39c1ebe3a (formerly https://hg.python.org/cpython/rev/e7dbef447157) for issue #23260 which removed all references to SystemFolder or System64Folder

3.5+ doesn't install files to system directories -- except the py launcher in %SystemRoot%. This was an intentional change, so I'm flagging this as a documentation issue.

I don't even think there's documentation to fix, the install page should say where things are installed.

The system directory is for the system to install files - the Python installer is not a system component, it's a developer kit. For most cases, the install directory was "fixed" rather than broken.

If you have particular needs to install a system-wide python3x.dll, I'd suggest crafting your own install script from the files in a normal install (though putting the install directory on PATH should also enable dependency resolution for most processes).

If this is just a documentation fix, then there's two places that need it:

* https://github.com/python/cpython/blob/master/Tools/msi/README.txt contains the text I quoted in the original report.

* Some kind of release note (https://docs.python.org/3/whatsnew/3.5.html) so that things that have relied on this behaviour in the past (e.g. gvim with the Python3/dynamic build option) can have all their documentation updated to tell people to... I don't know? Grab the embedded version into the gvim install directory? What _is_ the recommended approach here, to give system-wide-installed applications access to a system-wide-installed Python environment?

==============================================

I don't agree that this change is correct. It's inconsistent with the Linux experience of an all-users installation (i.e. anything on the system can link against libpython2.7.so and get the expected behaviour of using the system-installed Python) and I would also consider an All-Users install to *be* a system component, since the intent is clearly to make it available to all users and applications without further effort.

Unlike putting python.exe in the path, the DLLs are version-named, so you don't suffer the conflict of *which Python* you get. The Python Launcher for Windows has taken care of that nicely, and if I have to add all the Python install directories to my path to ensure the DLLs are visible to applications that link against them, that seems to be a regression in the behaviour that launcher was trying to fix.

An issue I see with the embedded installation approach is that if I want to make modules available to something like gvim's Python environment, then I need to maintain those modules distinctly from the modules I maintain on the system level. It also means I need to be modifying gvim's install directory to add that embedded distribution, and that leaves a whole bunch of manual tracking of installed things I need to worry about.

I have the same concerns (manual tracking of things) if I have to add extra infrastructure to manage a copy of python3.X.dll in System32. Searching Google for this issue suggests that many people are just grabbing a random DLL off the internet named python3.5.dll and putting it in System32 when they encounter this problem, because "it used to work with Python 3.2".

Alternatively... Does it make sense to have a "System Component" installer version of Python for use by other applications that want to offer (optional) Python interpreter support? It would be pretty-much identical to the installer we have now, except putting the DLL entry point (python3.x.dll) into the system path, but not having python.exe in the path to confuse command-line usage.

Maybe I need to look through the history to see whether I actually intended the all-users install to be in System, but I don't think I did (despite writing the documentation linked - it may have been adapted from the old documentation).

Applications that need Python should look in the registry or embed the embeddable distro, depending on whether they are providing access to the user's own Python (e.g. an IDE) or it's an internal implementation detail (e.g. a tool that just happens to be implemented using Python). The former should really offer options for the user to specify a path to the install as well.

Reliably finding the required standard library for a copy of Python that is installed somewhere else is every bit as problematic as locating the install itself. When everyone follows PEP 514 properly it may be safe for a System32-DLL to use the registry again for finding its library, but as long as various distros want to overwrite the core registry keys, everyone is better off without it being a system component.

tbh, I would rather have it default for all python files installed for all users to go in ``%SystemDrive%\Python{major}{minor}`` on windows and then work with then the environment variables like currently so that way none of the python dll's are outside of such folder in case someone installs for example 3.6.0 in ``%SystemDrive%\Python360`` and then installs 3.6.1 in ``%SystemDrive%\Python361`` without uninstalling 3.6.0.

> It's inconsistent with the Linux experience of an all-users 
> installation

Yes, if you build with --enable-shared on Linux, then the shared libraries libpython3.X.so.1.0 and libpython3.so are installed in /usr/local/lib. 

Currently there's no direct equivalent for 3.5+ on Windows. However, delay-loading the DLL is an alternative to a static import. At program startup, get the install path from the registry and load python3x.dll manually via LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH. Delayed loading automates calling GetProcAddress, so you get the flexibility of a dynamic import without losing the convenience of a static import.

> add all the Python install directories to my path to ensure the DLLs 
> are visible to applications that link against them

If the 32-bit DLL were distributed as, for example, python36-32.dll, then this would at least be reliable, albeit tedious. Using System32 and SysWOW64 handles this problem reliably via file-system redirection.

> all users to go in ``%SystemDrive%\Python{major}{minor}``

The change to use %ProgramFiles% for a machine installation and %LocalAppData% for a user installation locks down the discretionary file security. In contrast, the file security inherited from C:\ is permissive. It allows any authenticated user the right to modify the directory, subdirectories, and files. The only rights not granted are delete-child (meaningless since the user has delete access for all files) and the right to modify the file security.

"Tools/msi/README.txt" still references "%SystemRoot%\System32" and "%SystemRoot%\SysWOW64" as the location of "python3[x].dll" for all-users installs. The containing paragraph can be removed. Move the lines for ".\python3x.dll" and ".\python3.dll" unconditionally into the installation directory listing. Maybe also add ".\vcruntime140[_1].dll" to the listing.

New changeset 098a33f6a60ca2df88e03024ac9d8da507cfa5c8 by Zachary Ware in branch 'main':
bpo-29844: Remove obsolete paragraph from Tools/msi/README.txt (GH-29141)
https://github.com/python/cpython/commit/098a33f6a60ca2df88e03024ac9d8da507cfa5c8

With the readme updated (and backports in progress), I'm closing the issue.

New changeset a8912a0f8d9eba6d502c37d522221f9933e976db by Miss Islington (bot) in branch '3.10':
bpo-29844: Remove obsolete paragraph from Tools/msi/README.txt (GH-29141)
https://github.com/python/cpython/commit/a8912a0f8d9eba6d502c37d522221f9933e976db

New changeset 7c8d1f0238842fb8da099e797eea5973b66638a9 by Miss Islington (bot) in branch '3.9':
bpo-29844: Remove obsolete paragraph from Tools/msi/README.txt (GH-29141)
https://github.com/python/cpython/commit/7c8d1f0238842fb8da099e797eea5973b66638a9