On Mon, 14 Oct 2002, Greg Turner wrote:
well, that sounds about right, but how to detect such a thing...? I guess I need to learn how to create 'on change some ram' breakpoints,
That's called "watchpoints". In gdb, you can set such a watchpoint with: watch *(int*)0xaddress
not to mention track down these datastructures in memory (or perhaps learn how to get debug symbols for w32-native-compiled stuff generated).
Well you can just use the pointer given to NdrClientCall2, right?
Serveral differences worth noting:
o Many more dlls loaded in the winelib version (why?)
Perhaps you have lots of unneeded import statements in your Winelib app's .spec file.
o lots of IMallocSpy activity in the winelib version (perhaps just part of the ole32 initialization?)
I suppose.
o pFormat argument to RPCRT4_NdrClientCall2 is different in the winelib version (!?)
Hmm, not good.
My theories:
o it's the try/except macros; they're causing stack corruption or something (they occur right before the NdrClientCall2) o it's MIDL_user_allocate somehow (nah) o it's a problem with dll loading (lets hope not)
o it's a calling convention problem (stdcall/cdecl, argument count, return value). This theory is substantiated by the difference in the pFormat argument. Perhaps gcc wants to return the CLIENT_CALL_RETURN structure in a way that isn't compatible with what Microsoft compilers expect (wants stack space reserved for it by the caller or something?)... I think we've had issues with gcc and returning structures before. If this is it, rpcrt4 probably need to return it as just LONG_PTR in the code, not CLIENT_CALL_RETURN?