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.

Author eryksun
Recipients Elli Pirelli, eryksun, paul.moore, steve.dower, tim.golden, zach.ware
Date 2021-02-25.18:37:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1614278222.29.0.640356557306.issue29399@roundup.psfhosted.org>
In-reply-to
Content
> The APIs are the same, so you can (should) LoadLibrary the one 
> that you want.

The issue is that python3.dll doesn't depend on python3x.dll in the normal way. For example, LoadLibraryExW("path/to/python3.dll", NULL, LOAD_WITH_ALTERED_SEARCH_PATH) doesn't automatically load "python38.dll". But the forwarded functions depend on "python38.dll", e.g. "Py_Main (forwarded to python38.Py_Main)". The loader doesn't try to load "python38.dll" until the application tries to resolve a forwarded function such as "Py_Main", which in the LoadLibraryExW case is the time that GetProcAddress(hpython3, "Py_Main") is called. 

It turns out, when I tested this in 2017, that the loader in Windows 7 doesn't remember the activation context from loading "python3.dll" and thus will fail to find "python38.dll", which in turn makes the GetProcAddress() call fail. In contrast, the loader in Windows 10 knows to search for "python38.dll" in the directory of "python3.dll".
History
Date User Action Args
2021-02-25 19:32:22eryksununlinkissue29399 messages
2021-02-25 18:37:02eryksunsetrecipients: + eryksun, paul.moore, tim.golden, zach.ware, steve.dower, Elli Pirelli
2021-02-25 18:37:02eryksunsetmessageid: <1614278222.29.0.640356557306.issue29399@roundup.psfhosted.org>
2021-02-25 18:37:02eryksunlinkissue29399 messages
2021-02-25 18:37:02eryksuncreate