On Wednesday, 28 September 2016 21:50:54 UTC+1, eryk sun wrote: > On Wed, Sep 28, 2016 at 2:35 PM, Paul Moore <p.f.mo...@gmail.com> wrote: > > So I thought I'd try SetDllDirectory. That works for python36.dll, but if I > > load > > python3.dll, it can't find Py_Main - the export shows as "(forwarded to > > python36.Py_Main)", maybe the forwarding doesn't handle SetDllDirectory? > > It works for me. Are you calling SetDllDirectory with the > fully-qualified path? If not it's relative to the working directory, > which isn't necessarily (generally is not) the application directory, > in which case delay-loading python36.dll will fail. You can create the > fully-qualified path from the application path, i.e. > GetModuleFileNameW(NULL, ...).
That might be the issue. I was using a relative directory (I was being lazy for a quick test) but I was at the time in the right directory for the relative directory name to work. But I'll do a proper test today. > That said, I prefer using LoadLibraryExW(absolute_path_to_python3, > NULL, LOAD_WITH_ALTERED_SEARCH_PATH). The alternate search substitutes > the DLL's directory for the application directory when loading > dependent DLLs, which allows loading python36.dll and vcruntime140.dll > without having to modify the DLL search path of the entire process. That does indeed sound like a better idea. I had read the docs for LoadLibraryEx, but I must admit I got very muddled from the various options, and ended up going back to LoadLibrary because it seemed simpler :-( Thanks for the suggestions, Paul PS It's a shame there's no way to put the embedded distribution in a subdirectory *without* needing to use dynamic loading, but I guess that's basically an OS limitation. -- https://mail.python.org/mailman/listinfo/python-list
