[issue29399] python3.dll export forwarders not resolved in all situations due to missing python3?.dll dependency and DLL search path behavior

2017-01-31 Thread Elli Pirelli

Elli Pirelli added the comment:

I should perhaps clarify my sentence "As described, as long as forwarder.dll 
does not contain a import dependency on real.dll, loading forwarder.dll and 
doing GetProcAddress("Func") will fail, if real.dll is not in the standard DLL 
search path."

What i tried to say was:

As described, as long as forwarder.dll does not contain a import dependency on 
real.dll, loading forwarder.dll succeeds, but doing GetProcAddress("Func") will 
fail if real.dll is not in the standard DLL search path. If this forwarder.dll 
is put in one of the standard DLL search paths, GetProcAddress("Func") 
successfully resolves the address of the dummy function Func in real.dll.

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29399] python3.dll export forwarders not resolved in all situations due to missing python3?.dll dependency and DLL search path behavior

2017-01-31 Thread Elli Pirelli

Elli Pirelli added the comment:

It does not work on Windows 7 Pro x64.

And i am not the only one. The maintainer of the "python-embedded-launcher" 
also encountered the issue (see discussion here: 
https://github.com/zsquareplusc/python-embedded-launcher/issues/3)

Are you sure it really works on Windows 10? Perhaps you have the python3?.dll 
in the standard DLL search path already, making you mistakenly believe that it 
works properly? I would suggest to use a tool like SysInternal's Process 
Monitor to see and verify where the python3?.dll is really being loaded from.


The issue is not with incorrectly using LoadLibraryEx, SetDllDirectory and 
AddDllDirectory. The problem can be reduced to the python3.dll not having a 
dependcy on python3?.dll.

I did verify this with a little project, emulating how python3.dll uses export 
forwarders. I made a DLL (real.dll) with a dummy function Func  and another DLL 
(forwarder.dll) containing just an export forwarder Func=real.Func. 

As described, as long as forwarder.dll does not contain a import dependency on 
real.dll, loading forwarder.dll and doing GetProcAddress("Func") will fail, if 
real.dll is not in the standard DLL search path.

As soon as forwarder.dll includes a dependency to real.dll, the export 
forwarder can be resolved by GetProcAddress("Func") properly.

If i were using LoadLibraryEx/SetDllDirectory/AddDllDirectory incorrectly, 
attempting to load the forwarder.dll with the dependency on real.dll would just 
fail -- which it doesn't.

Unfortunately, the whole business with export forwarders is very poorly 
documented. It could perhaps be that MS did change something in Win8/2K12 or 
Win10 to fix this issue. Since i currently don't have access to either of these 
OS, i myself cannot confirm whether the problem would also occur or not on Win 
10...

--

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29399] python3.dll export forwarders not resolved in all situations due to missing python3?.dll dependency and DLL search path behavior

2017-01-31 Thread Elli Pirelli

Changes by Elli Pirelli <gonzelm...@gmail.com>:


--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com



[issue29399] python3.dll export forwarders not resolved in all situations due to missing python3?.dll dependency and DLL search path behavior

2017-01-31 Thread Elli Pirelli

New submission from Elli Pirelli:

Let me first apologize if this issue has already been reported and discussed 
before. I would be surprised if there are not a few developers that had to deal 
with this issue before, but i was unable to find an existing bug report or 
discussion about this. So, here it goes...


Importing/using Py_* symbols from python3.dll instead directly from 
python3?.dll can be a problem when python3.dll and python3?.dll reside in a 
directory that is not part of the standard DLL search path. An example would be 
an application that tries loading Python from a sub directory of the 
application.

The functions exported in python3.dll are export forwarders referencing the 
respective functions in python3?.dll.
python3.dll itself has no import dependency on python3?.dll.

Without an import dependency on python3?.dll, this DLL will be loaded when one 
of the export forwarders in python3.dll will be resolved, for example when 
calling GetProcAddress("Py_Main").

However, in such a case an altered DLL search path will be completely ignored, 
and python3?.dll will only be looked for in the standard DLL search paths. 
Since the sub directory with the python DLLs is not part of the standard DLL 
search paths, the resolution of the export fowarder(s) fails.

Trying to alter the DLL search path has no effect. Loading python3.dll with 
LoadLibraryEx and the flag LOAD_WITH_ALTERED_SEARCH_PATH does not help. Neither 
does calling SetDllDirectory or AddDllDirectory before loading python3.dll 
and/or before invoking GetProcAddress.

Note that loading python3.dll itself works fine. However, resolving one of the 
exports with GetProcAddress will fail if python3?.dll cannot be found in the 
standard DLL search path.

I don't know, if there is a way to make it work properly...

As of now the only two options out of this dilemma are either to put the python 
DLLs (and assorted files) in the same directory as the application exe (ugly 
mess) or to load python3?.dll instead of python3.dll (which sort of defeats the 
purpose of having python3.dll, i guess).

My suggestion for future Python 3 versions is to let python3.dll have a DLL 
dependency on python3?.dll. Linking python3.dll to python3?.dll (i.e., loading 
python3.dll will cause python3?.dll being loaded) allows using altered DLL 
search paths.

--
messages: 286544
nosy: Elli Pirelli
priority: normal
severity: normal
status: open
title: python3.dll export forwarders not resolved in all situations due to 
missing python3?.dll dependency and DLL search path behavior
type: behavior
versions: Python 3.5, Python 3.6, Python 3.7

___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue29399>
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com