DLL loading prolem when injecting into another process

[Rolf Kalbermatter]

Hongbo Ni  wrote: 

>> Not sure about what you mean with injecting here but in normal
application operation
>> when loading a DLL explicitedly from a specific directory (which is not
the current
>> directory nor the application directory or one of the standard search
paths), 
>> Windows
>	
> did you mean 'Wine', i know ms-windows has no problem.

No I was refereing to Windows and in my experience this is true for Windows
at least up to XP.
	 
>> will not resolve to other DLLs implicitedly loaded by that DLL eventhough
they are in
>> the same directory than the referencing DLL.
>	 
> This is exactly the another situation I am going to explain. Thanks.

It's been some time that I had to deal with this in an application someone
else had developed
as I have always made sure to avoid this for a long time.

But from working in higher level applications loading DLLs form a specific
absolut path, this
loading usually seems to fail if this DLL references other DLLs that are not
in the standard
Windows search locations (memory, application dir, windows and system dir,
and PATH environment
variable) eventhough those dependant DLLs reside in the same directory as
the DLL that was
just attempted to be loaded.

It may be that you have to make sure to not modify the current directory in
the process of
determining the path to load the parent DLL from. I've seen for instance in
those higher level
development environments that loading such DLL combos failed on the initial
application load
only to be prompted to locate the parent DLL in question with a file dialog
and then it magically
seemed to work. This is because the windows file dialog will automagically
modify the current
directory for the current process and now the implicit LoadLibrary during
the loading of the
parent DLL seems to also find the dependant DLLs in that same directory.

And this behaviour was certainly like that up to and including W2K but I do
believe even XP.

That is not to say that Wine might not have to do something extra here, for
instance to support
new Vista behaviour which seems to have complicated the whole DLL loading
procedure a bit.
	 
>I have produced a patch to load the imported dll from same directory
>as the referring DLL when import_dll() fail to load from standard 
>locations (current dir, app dir and PATH)
>	 
>But I did not know how to write test case for it since there are other DLL
involved.

Well it will be a bit cumbersome as you will have to create two extra dummy
DLLs A.dll and B.dll
where A.dll implicitedly loads B.dll and then load A.dll from the test
executable. A.dll and B.dll
would have to reside in a different directory (possibly subdirectory) to the
actual test executable
and of course can't be inside any directory considered a windows or system
directory. Also make sure you set the current directory to something else
than that directory. 
And then see what happens when this test is crosscompiled and run under
Windows. If the LoadLibrary
of A.dll does not fail under Windows then yes Wine will need some extra
functionality to replicate
that behaviour.

My guess is that it will however fail on most Windows versions except maybe
Vista which would still
be a reason to try to implement that behaviour in Wine too. However you will
likely have to do quite
a bit more tests to then figure out the exact conditions under which this
behaviour is applied under
newer Windows versions. 

Rolf Kalbermatter