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.
