RPCRT4_NdrClientCall2 stub (fixme)?

[Jeroen Janssen]

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

[Robert Shearman]

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

[Mike Hearn]

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

[Alexandre Julliard]

Mike Hearn <mike(a)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.

-- 
Alexandre Julliard
julliard(a)winehq.org

[Robert Shearman]

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

[Vincent Béron]

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

[Robert Shearman]

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

[Vincent Béron]

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

[Robert Shearman]

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