Using the Windows "embedded" distribution of Python

[Paul Moore]

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.moore at 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.