Trying to track down a failure in a native, non-MS DLL for which I have no source

[Mike McCormack]

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.

Mike