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