DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)

[Robert Shearman]

On Tue, 2004-06-01 at 17:27, Mike Hearn wrote:
> On Tue, 2004-06-01 at 16:56 +0100, Robert Shearman wrote:
> > Even on Wine, those other functions, such as CoMarshalInterface do
> > actually attempt to get a marshaller or just use the standard one and 
> 
> and ... ? 
> 
> You mean it correctly does inter-thread marshalling? Last time I checked
> WineHQ didn't have any code to do this properly, we just handed raw
> pointers around. This is what Oves patch adds. 

No, we actually do proper marshalling. This is either via the generated
*_p.c files or via the type library marshaller. In the *_p.c case, the
proxies are generated in dlls/rpcrt4/cproxy.c and the stubs in cstub.c
The last bit of pointer passing was the bit I just removed.

> The current code for one uses pipes for everything rather than going via
> RPC, even in the inter-thread case. COM_AptWndProc should be processing
> RPC messages.

Yes, that is correct.

> > I've had a look at what is in there. The way I interpret it, there are a
> > couple of sections:
> > o Auto-generated marshaling code -- this is fine to be included in Wine
> > and could probably be done so at any point
> 
> Last time I checked Alexandre saw using MIDL code in Wine as a temporary
> hack, he may require us to get widl up to speed to produce this code.

Yes, there is a lot of work to do.

> > o Converting COM (ole32) to using RPC -- as you can see by the comments
> > in the code, this isn't really done through the correct interfaces yet
> > (and this is stuff that you only want implement once) and hence I'm not
> > confident that the related stuff is done correctly. There are useful
> > bits, but I doubt I will use all of that code.
> 
> It's not so much converting as adding the necessary code.

I meant converting as in converting it from using its own named pipes
(and IRpc* interfaces) to using proper RPC ones. Obviously there would
need to be extra code to handle this (and also a lot of code removed).

> In particular I think our proxy/stub code currently isn't up to doing
> inter-thread marshalling.

What makes you think that?

> And yeah, iirc the Windows typelib marshaller generates format strings.
> In fact isn't there an ITypeLib::GetMOPs method or somesuch?

Yes, you're right. I had initially thought that it was all done in
RPCRT4, but it looks like it is spread out across both libraries.

> The main reason I'm unhappy about the idea of reimplementing what's in
> the TransGaming patch is that this patch works, I have merged it with
> WineHQ and used it with some fairly complex scenarios (think lots of
> inter-thread IDispatch marshalling happening simultaneously).

I'll submit a patch containing the autogenerated stuff since we need
that anyway. Like I said, the proxy code isn't 100% correct. It may be
fine for Crossover or for Wine temporarily however.

> We still
> need to write test cases, but the complexity of DCOM is staggering and
> the more code we re-use the more time we have for documenting it,
> writing tests, filling out the details and so on.

I don't understand a lot of the apartment, OXID and OID code that is in
the patch so I would have a hard time documenting it.
I have a fairly large RPC test suite, but I have yet to really delve
into the DCOM side of things.

Rob