"Dmitry Timoshkov" <dmitry@codeweavers.com> wrote:

> > This patch fixes bug 14699. It should fix all failed applications
> > which try to load a dll from specific folder, and the dll is link
> > another dll in the same folder.
>
> Please add a test case for this behaviour to confirm that your patch
> is doing a correct thing.

Please ignore this patch. This is not how window work. Window&Wine solve it by
LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH)
 
I will post another patch to just solve bug 14699.
 
As discussed in my prev email: RE: DLL loading prolem when injecting into another processū
 
@ -322,7 +322,7 @@ void *get_hook_proc( void *proc, const WCHAR *module )
{
     TRACE( "loading %s\n", debugstr_w(module) );
     /* FIXME: the library will never be freed */
-    if (!(mod = LoadLibraryW(module))) return NULL;
+   if (!(mod = LoadLibraryExW(module, NULL, LOAD_WITH_ALTERED_SEARCH_PATH))) return NULL;
   }
   return (char *)mod + (ULONG_PTR)proc;
}

Currently there is no test case to show LoadLibraryW above has loaded the module in the process
other than current process.
 
But how can I write test case to justify using LoadLibraryExW instead LoadLibraryW above ?
 
How can I know if another process has loaded the DLL containing GetMsgProc when I am trying to call
SetWindowsHookEx(WH_GETMESSAGE, GetMsgProc, g_hinstDll,GetWindowThreadProcessId(hwnd, NULL));

 
Hongbo Ni

---

in your area now! View photos of singles