This is specific to the Windows platform as it's the only platform that uses the registry and other path hacks to identify the default module path. This patch is mostly intended for embedded Python, but is also applicable to a stand-alone Python.

A few years ago, I was looking at relocating my Python interpreter so that an embedded application (that I didn't have control over) would use the correct module path. While merging my code into CPython, I quickly noticed that Python already supported doing this with Py_ENABLE_SHARED but due to the implementation wasn't actually using it for some reason. The code that implements this is 10+ years old, so perhaps it was just an oversight or some other reason that I didn't know about.

Inside PC/getpathp.c there's a static variable, "dllpath", that is initialized with the path to the DLL that is being dynamically loaded when Py_ENABLE_SHARED is specified. Normally arg0 is used to locate the module path, but when embedding Python the .exe and thus arg0 is not involved. So, this patch uses "dllpath" by adding a final case to the calculation of the path by assigning it to "pythonhome" if the home was not able to be determined by any other means. This is done in 2 places within "calculatepath()".

This allows one to have multiple versions of Python (32-bit, 64-bit, older versions, etc) on the same Windows system and so a user should not need to copy the Python library into their System path or explicitly set any environment variables (unless truly desired of course). This should greatly simplify relocation of Python as the DLL and executable can be moved around without being dependant on any external invariants.