Trying to track down a failure in a native, non-MS DLL for which
I have no source
mike at codeweavers.com
Tue Sep 27 21:48:54 CDT 2005
David D. Hagood wrote:
> I'm trying to get the Delorme packages (AAA MapNGo, Street Atlas)
> running under the latest Wine. They used to work back when Wine used the
> MS DLLs for DCOM, but then they stopped working when Wine started
> supplying their own DCOM DLLS.
If you're pretty sure that the difference is because of ole, and it
can't load a file, then I'd suspect ole storage or OleFont.
> The FONT.FNT file is being opened (strace shows it being opened).
> The mapsys32.dll file is being loaded (WINEDEBUG=+relay shows it)
> The mapsys32.dll does not implement DllRegisterServer (regsvr32 says so).
> The problem exists even though I've blown away my entire .wine directory
> and recreated it from scratch.
> The problem has been in the code for several months, and as of 19 Sept
> 2005's CVS it still is.
> So, how can I see what is going on with mapsys32.dll?
Try a +olerelay,+storage,+relay trace. Try to pinpoint the failure (ie.
where it starts doing HeapFree(), DestroyWindow(), ExitProcess, etc,
then work back from there. Try see if there's a
StgOpenStorage/StgCreateStorage call, or perhaps if the IOleFont object
is being used.
Calls to ole interfaces don't show up in with a +relay trace, so you
need +olerelay (which only shows up if somebody put a TRACE_(olerelay)
macro in the ole functions).
The other thing to try is a +relay,+snoop trace, which will show you the
entry points being called in mapsys32.dll.
More information about the wine-devel