On 2017-03-15 13:51, Ben Coman wrote:
On Wed, Mar 15, 2017 at 4:42 PM, Raffaello Giulietti
<raffaello.giulie...@lifeware.ch
<mailto:raffaello.giulie...@lifeware.ch>> wrote:
Hi Ben,
my understanding is that SetDllDirectory only affects the search
path of libraries that are loaded at *run-time* with LoadLibrary.
What I'm asking for is a mechanism that works at *load-time*, when a
library I'm accessing directly depends on another one which I'm not
targeting directly.
I don't quite follow. I'm not intimate with Windows dynamic loading, so
these questions are an opportunity for me to learn...
You can't mean when Pharo loads, because it wouldn't know of OTHER.DLL ?
Do you mean that LoadLibrary is not called explicitly by YOUR.DLL before
its uses the function from OTHER.DLL?
During the build of YOUR.DLL, you can specify that it should depend on
OTHER.LIB (kind of binary which lists function headers and static data
declarations for OTHER.DLL). Linking resolution is then done at
load-time of YOUR.DLL, not by invoking LoadLibrary("OTHER.DLL").
When YOUR.DLL is loaded by UFFI at run-time (here by means of
LoadLibrary(), I guess), Windows (not the UFFI) also attempts to load
OTHER.DLL because of the linking information gathered during the build.
Notice that the linking information does *not* include a specific path
for OTHER.DLL.
(You don't have to mention standard *.LIBs like Kernel32.lib because
they are included by default. But of course, Windows knows where to find
the corresponding .dll.)
OTHER.DLL is searched using the strategy described in the MSDN page you
mention. My expectation is/was that UFFI has/had an API for specifying
the search paths where to find OTHER.DLL in a platform-independent way.
In other words, I would expect the UFFI to do the call of
SetDllDirectory() or whatever is needed on Windows for me or to use
other mechanisms on other platforms.
Do you mean you link OTHER.DLL to YOUR.DLL at compile time?
But still, YOUR.DLL it not loaded until called via Pharo FFI, so neither
is OTHER.DLL,
and Dynamic-Link Library Search Order [1] says... "If a DLL with the
same module name
is already loaded in memory, the system uses the loaded DLL, no matter
which directory it is in.
The system does not search for the DLL."
So maybe before calling any of YOUR.DLL,
do a SetDllDirectory followed by a LoadLibrary(OTHER.DLL)
and later when you call into YOUR.DLL,
OTHER.DLL is already loaded.
Yes, this might work but is rather contrived.
Otherwise it would seems(?) your options are either Manifests
or Dynamic-Link Library Redirection, both done outside of Pharo.
What if neither YOUR.DLL nor OTHER.DLL are under my control? The only
thing I know is where the .dll and the corresponding .lib + .h are.
Thanks for your interest
Raffaello
But I'll try whether SetDllDirectory also affects load-time searches.
Anyway, I hope future versions of the UFFI to offer setting the
search paths more easily.
Greetings
Raffaello
