On Tue, Feb 7, 2017 at 3:27 PM, Paul Moore <[email protected]> wrote: > On 7 February 2017 at 14:29, Steve Dower <[email protected]> wrote: >> You can leave python.exe out of your distribution to avoid it showing up on >> PATH, or if your stub explicitly LoadLibrary's vcruntime140.dll and then >> python36.dll you should be able to put them wherever you like. > > Understood, but I may need python.exe present if the script uses > multiprocessing, so I'm trying to avoid doing that (while I'm doing > things manually, I can do what I like, obviously, but a generic "build > my app" tool has to be a bit more cautious). > > LoadLibrary might work (I'm only calling Py_Main). I seem to recall > trying this before and having issues but that might have been an > earlier iteration which made more complex use of the C API. Also, I > want to load python3.dll (the stable ABI) as I don't want to have to > rebuild the stub once for each Python version, or have to search for > the correct DLL in C. But I'll definitely give that a go.
LoadLibrary and GetProcAddress will work, but that would get tedious if a program needed a lot of Python's API. It's also a bit of a kludge having to manually call LoadLibrary with a given DLL order. For the latter, I wish we could simply load python3.dll using LoadLibraryEx with LOAD_WITH_ALTERED_SEARCH_PATH, but it doesn't work in good old Windows 7. python3.dll doesn't depend on python3x.dll in its DLL import table. I discovered in issue 29399 that in this case the loader in Windows 7 doesn't use the altered search path of python3.dll to load python3x.dll and vcruntime140.dll. As you're currently doing (as we discussed last September), creating an assembly in a subdirectory works in all supported Windows versions, and it's the most convenient way to access all of Python's limited API. _______________________________________________ Python-ideas mailing list [email protected] https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
