Re: winetest: Add the ability to retrieve the dll path for com dlls from the registry.

[Paul Vriens]

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.

winetest: Add the ability to retrieve the dll path for com dlls from the registry.

[Paul Vriens]

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?

winetest: Add the ability to retrieve the dll path for com dlls from the registry.

[Huw Davies]

Paul Vriens wrote:
> 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?

Hi Paul,

Thanks for tracking this down.  There shouldn't be any issues with using 
LoadLibrary, so we can either use your patch or just rely on the info 
from the registry, I don't think it really matters.  Shall I leave you 
to send in a patch?

Thanks again,
Huw.

winetest: Add the ability to retrieve the dll path for com dlls from the registry.

[Paul Vriens]

On 09/17/2009 11:39 AM, Huw Davies wrote:
> Paul Vriens wrote:
> > 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?
>
> Hi Paul,
>
> Thanks for tracking this down. There shouldn't be any issues with using
> LoadLibrary, so we can either use your patch or just rely on the info
> from the registry, I don't think it really matters. Shall I leave you to
> send in a patch?
>
> Thanks again,
> Huw.

I'll sent a patch with the LoadLibrary.