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);
}