view CONTRIBUTORS @ 48191:67d14d4e036c

exewrapper: find the proper python3X.dll in the registry

Previously, we relied on the default library lookup[1], which for us is
essentially to look on `PATH`.  That has issues- the Python installations are
not necessarily on `PATH`, so I started copying the DLLs locally in 2960b7fac966
and ed286d150aa8 during the build to work around that.  However, it's been
discovered that causes `python3.dll` and `python3X.dll` to get slipped into the
wheel that gets distributed on PyPI.  Additionally, Mercurial would fail to run
in a venv if the Python environment that created it isn't on `PATH`, because
venv creation doesn't copy the DLLs locally.

The logic here is inspired by the `py.exe` launcher[2], though this is simpler
because we don't care about the architecture- if this is a 32 bit process
running on Win64, the registry reflection will redirect to where the 32 bit
Python process wrote its keys.  A nice unintended side effect is to also make
venvs that don't have their root Python on `PATH` work without all of the code
required to read `pyvenv.cfg`[3].  I don't see any reasonable way to create a
venv without Python being installed (other than maybe building Python from
source?), so punt on trying to read that file for now and save a bunch of string
manipulation code.

I somehow managed to corrupt my Windows user profile, and that makes the
Microsoft Store python not run (even loading the DLL gives an access error), so
I'm giving priority to both global and user specific python.org installations.

Loading python3.dll is new, but when I went down the rabbit hole of implementing
`pyvenv.cfg` support, I saw a comment[4] that led me to think we could have
trouble if we don't.  The comment in ed286d150aa8 confirms this, so we should
probably bail out completely if Python3 can't be loaded from the registry,
rather than getting something random on `PATH`.  But I'll leave that for the
default branch.

[1] https://docs.microsoft.com/en-us/windows/win32/Dlls/dynamic-link-library-search-order#standard-search-order-for-desktop-applications
[2] https://github.com/python/cpython/blob/adcd2205565f91c6719f4141ab4e1da6d7086126/PC/launcher.c#L249
[3] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L707
[4] https://github.com/python/cpython/blob/bb3e0c240bc60fe08d332ff5955d54197f79751c/PC/getpathp.c#L1098

Differential Revision: https://phab.mercurial-scm.org/D11454

[This file is here for historical purposes, all recent contributors
should appear in the changelog directly]

Andrea Arcangeli <andrea at suse.de>
Thomas Arendsen Hein <thomas at intevation.de>
Goffredo Baroncelli <kreijack at libero.it>
Muli Ben-Yehuda <mulix at mulix.org>
Mikael Berthe <mikael at lilotux.net>
Benoit Boissinot <bboissin at gmail.com>
Brendan Cully <brendan at kublai.com>
Vincent Danjean <vdanjean.ml at free.fr>
Jake Edge <jake at edge2.net>
Michael Fetterman <michael.fetterman at intel.com>
Edouard Gomez <ed.gomez at free.fr>
Eric Hopper <hopper at omnifarious.org>
Alecs King <alecsk at gmail.com>
Volker Kleinfeld <Volker.Kleinfeld at gmx.de>
Vadim Lebedev <vadim at mbdsys.com>
Christopher Li <hg at chrisli.org>
Chris Mason <mason at suse.com>
Colin McMillen <mcmillen at cs.cmu.edu>
Wojciech Milkowski <wmilkowski at interia.pl>
Chad Netzer <chad.netzer at gmail.com>
Bryan O'Sullivan <bos at serpentine.com>
Vicent Seguí Pascual <vseguip at gmail.com>
Sean Perry <shaleh at speakeasy.net>
Nguyen Anh Quynh <aquynh at gmail.com>
Ollivier Robert <roberto at keltia.freenix.fr>
Alexander Schremmer <alex at alexanderweb.de>
Arun Sharma <arun at sharma-home.net>
Josef "Jeff" Sipek <jeffpc at optonline.net>
Kevin Smith <yarcs at qualitycode.com>
TK Soh <teekaysoh at yahoo.com>
Radoslaw Szkodzinski <astralstorm at gorzow.mm.pl>
Samuel Tardieu <sam at rfc1149.net>
K Thananchayan <thananck at yahoo.com>
Andrew Thompson <andrewkt at aktzero.com>
Michael S. Tsirkin <mst at mellanox.co.il>
Rafael Villar Burke <pachi at mmn-arquitectos.com>
Tristan Wibberley <tristan at wibberley.org>
Mark Williamson <mark.williamson at cl.cam.ac.uk>