On 09/17/2009 08:13 AM, Paul Vriens wrote:
On 09/14/2009 03:10 PM, Huw Davies wrote:
---
programs/winetest/main.c | 87
++++++++++++++++++++++++++++++++++++++-------
1 files changed, 73 insertions(+), 14 deletions(-)


------------------------------------------------------------------------


Hi Huw,

Winetest doesn't do a complete run anymore (tested only on W2K3 and
Vista) for now. It ends with a 998 error during enumeration of the test
(oleaut32 being the last visible one).

I'm crossbuilding a winetest as we speak but just thought I'd mention it.


The attached patch fixes the issue.

We are using LOAD_LIBRARY_AS_DATAFILE as we don't really want to load the dll but we need some info from it. The problem is that GetModuleFileName can't cope with LOAD_LIBRARY_AS_DATAFILE loaded dlls.

So will using LoadLibrary introduce issues for this dll (and maybe future com dlls)?

The get_dll_path logic was introduced for .NET as we ourselves don't always know which dll/version is actually loaded. GetModuleFileName proved to be the most logic approach.

As these com dlls are hardcoded in the registry I assume we don't even need to call GetModuleFileName and just stick with that value from the registry?

--
Cheers,

Paul.
diff --git a/programs/winetest/main.c b/programs/winetest/main.c
index 10804a6..4287066 100644
--- a/programs/winetest/main.c
+++ b/programs/winetest/main.c
@@ -589,7 +589,7 @@ static HMODULE load_com_dll(const char *name)
     {
         LONG size = sizeof(dllname);
         if(RegQueryValueA(hkey, NULL, dllname, &size) == ERROR_SUCCESS)
-            dll = LoadLibraryExA(dllname, NULL, LOAD_LIBRARY_AS_DATAFILE);
+            dll = LoadLibraryA(dllname);
         RegCloseKey(hkey);
     }
 


Reply via email to