please don't apply RPC Merge D_PL1

[Ove Kaaven]

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?