please don't apply RPC Merge D_PL1
ovek at arcticnet.no
Tue Oct 15 10:53:30 CDT 2002
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'
That's called "watchpoints". In gdb, you can set such a watchpoint with:
> 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
> o lots of IMallocSpy activity in the winelib version
> (perhaps just part of the ole32 initialization?)
> 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
More information about the wine-devel