Hello,
I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call.
It seems some discussion on this has been happening in a the past few months? Can someone maybe explain the current status on this? (probably Rob or Mike, since they seem to be the Wine COM "gurus"?) Below is is a short snip of trace logging I get:
trace:ole:COMPOBJ_DLLList_Add trace:ole:CStdPSFactory_QueryInterface (0x660cea80)->QueryInterface({d5f569d0-593b-101a-b569-08002b2dbf7a},0x4067faa4) trace:ole:CStdPSFactory_CreateProxy (0x660cea80)->CreateProxy((nil),{11ef83d1-553a-11d3-bb12-0004ac9658d6},0x4067faa0,0x4067fbfc) trace:ole:FindProxyInfo found: ProxyInfo 0x660cbc48 Index 65 trace:ole:StdProxy_Construct ((nil),0x660cd048,0x660cea80,0x4067faa0,0x4067fbfc) ICoKMFactoryManager trace:ole:StdProxy_Construct stubless=0x660c5230 trace:ole:StdProxy_Construct iid={11ef83d1-553a-11d3-bb12-0004ac9658d6} trace:ole:StdProxy_Construct vtbl=0x660cd050 trace:ole:StdProxy_Construct stubless thunks: count=6 trace:ole:StdProxy_Construct method 3: stacksize=12 trace:ole:StdProxy_Construct method 4: stacksize=16 trace:ole:StdProxy_Construct method 5: stacksize=4 trace:ole:CStdPSFactory_AddRef (0x660cea80)->AddRef() trace:ole:CStdPSFactory_Release (0x660cea80)->Release() trace:ole:StdProxy_Connect (0x4034f1f0)->Connect(0x4034f288) trace:ole:StdProxy_Release (0x4034f1f0)->Release() trace:ole:ObjectStubless (0x4034f1f4)->(3)([12 bytes]) ret=4067fc94 fixme:ole:RPCRT4_NdrClientCall2 (pStubDec == ^0x660c7c08,pFormat = ^0x660c7d30,...): stub trace:ole:IUnknown_Release_Proxy (0x4034f1f0)->Release() ICoKMFactoryManager wine: Unhandled exception (thread 0014), starting debugger...
Best regards,
Jeroen Janssen
Jeroen Janssen wrote:
Hello,
I have 'hit' upon a RPCRT4_NdrClientCall2 stub/fixme call.
It seems some discussion on this has been happening in a the past few months? Can someone maybe explain the current status on this? (probably Rob or Mike, since they seem to be the Wine COM "gurus"?) Below is is a short snip of trace logging I get:
Wow. I think that's the first time I've ever been called a guru :)
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Rob
On Thu, 29 Jul 2004 19:46:18 +0100, Robert Shearman wrote:
Wow. I think that's the first time I've ever been called a guru :)
Heh, I think Ove is the true COM guru around here ... maybe me and Rob are catching up though.
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Alexandre, why was this not merged when it was originally sent?
thanks -mike
Mike Hearn mike@navi.cx writes:
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Alexandre, why was this not merged when it was originally sent?
No idea, please resubmit.
Mike Hearn wrote:
On Thu, 29 Jul 2004 19:46:18 +0100, Robert Shearman wrote:
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Alexandre, why was this not merged when it was originally sent?
It wasn't Alexandre's fault. I didn't ask for it to be merged. One of the main problems is that because of calling convention differences for passing unions/structures we can't be binary compatible with Windows at the same time as being source compatible.
Rob
Le ven 30/07/2004 à 07:39, Robert Shearman a écrit :
Mike Hearn wrote:
On Thu, 29 Jul 2004 19:46:18 +0100, Robert Shearman wrote:
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Alexandre, why was this not merged when it was originally sent?
It wasn't Alexandre's fault. I didn't ask for it to be merged. One of the main problems is that because of calling convention differences for passing unions/structures we can't be binary compatible with Windows at the same time as being source compatible.
You can take a glance at our msvcrt div/ldiv implementation which is both source and binary compatible. binary: dlls/msvcrt/math.c source: include/msvcrt/stdlib.h (which then calls dlls/msvcrt/math.c)
Vincent
Vincent Béron wrote:
Le ven 30/07/2004 à 07:39, Robert Shearman a écrit :
Mike Hearn wrote:
On Thu, 29 Jul 2004 19:46:18 +0100, Robert Shearman wrote:
Yes, I have an implementation of NdrClientCall2 in my local tree, but I'm a bit busy with other COM things at the moment. I'll send an updated patch to the list either tonight or sometime over the weekend.
Alexandre, why was this not merged when it was originally sent?
It wasn't Alexandre's fault. I didn't ask for it to be merged. One of the main problems is that because of calling convention differences for passing unions/structures we can't be binary compatible with Windows at the same time as being source compatible.
You can take a glance at our msvcrt div/ldiv implementation which is both source and binary compatible. binary: dlls/msvcrt/math.c source: include/msvcrt/stdlib.h (which then calls dlls/msvcrt/math.c)
NdrClientCall2 is a varargs function, so I don't think that approach would work.
Rob
Le ven 30/07/2004 à 11:38, Robert Shearman a écrit : [snip]
It wasn't Alexandre's fault. I didn't ask for it to be merged. One of the main problems is that because of calling convention differences for passing unions/structures we can't be binary compatible with Windows at the same time as being source compatible.
You can take a glance at our msvcrt div/ldiv implementation which is both source and binary compatible. binary: dlls/msvcrt/math.c source: include/msvcrt/stdlib.h (which then calls dlls/msvcrt/math.c)
NdrClientCall2 is a varargs function, so I don't think that approach would work.
Sorry, misread the "passing unions/structures" part as "returning unions/structures".
Still, if you're able to have both (a source compatible and a binary compatible) independantly, there's probably a clever way to have the source one call the binary one.
Vincent
Vincent Béron wrote:
Le ven 30/07/2004 à 11:38, Robert Shearman a écrit : [snip]
It wasn't Alexandre's fault. I didn't ask for it to be merged. One of the main problems is that because of calling convention differences for passing unions/structures we can't be binary compatible with Windows at the same time as being source compatible.
You can take a glance at our msvcrt div/ldiv implementation which is both source and binary compatible. binary: dlls/msvcrt/math.c source: include/msvcrt/stdlib.h (which then calls dlls/msvcrt/math.c)
NdrClientCall2 is a varargs function, so I don't think that approach would work.
Sorry, misread the "passing unions/structures" part as "returning unions/structures".
No, I did mean "returing unions/structures" (the parameters don't matter as all the complicated ones must be passed by reference).
Rob
-
Alexandre Julliard -
Jeroen Janssen -
Mike Hearn -
Robert Shearman -
Vincent Béron