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 eryksun, mhammond, paul.moore, steve.dower, tim.golden, zach.ware
Date 2016-01-10.16:44:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1452444243.28.0.519872357668.issue26071@psf.upfronthosting.co.za>
In-reply-to
Content
> why isn't the directory containing the loaded DLL searched 
> for dependencies?

That's possible. The loader provides several ways to go about solving this problem. The directory of the DLL can be added to the search path if you use LoadLibraryEx with the flag LOAD_WITH_ALTERED_SEARCH_PATH and use an absolute path. Python already does this for loading extension modules. 

If we didn't have to worry about older systems, in Windows 8/10 (and Vista/7 with KB2533623), the loader supports a set of flags that give detailed control of the DLL path, including LOAD_LIBRARY_SEARCH_DLL_LOAD_DIR. Individual directories can be added via AddDllDirectory and enabled via the flag LOAD_LIBRARY_SEARCH_USER_DIRS. Default flags can be set via SetDefaultDllDirectories, which affects LoadLibrary as well as LoadLibraryEx. 

On a related note, it would be nice to modify ctypes to call LoadLibraryEx instead of LoadLibrary. If the flags value is 0 the two calls are identical, so it wouldn't be a disruptive change. The existing dlopen "mode" parameter can be used for the flags, since it isn't used on Windows currently.
History
Date User Action Args
2016-01-10 16:44:03eryksunsetrecipients: + eryksun, mhammond, paul.moore, tim.golden, zach.ware, steve.dower
2016-01-10 16:44:03eryksunsetmessageid: <1452444243.28.0.519872357668.issue26071@psf.upfronthosting.co.za>
2016-01-10 16:44:03eryksunlinkissue26071 messages
2016-01-10 16:44:02eryksuncreate