DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)

[Mike Hearn]

On Tue, 2004-06-01 at 19:26 +0100, Robert Shearman wrote:
> 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.

Hm, OK, I took my eye off the ball. I hadn't even seen the cproxy/cstub
files.

> 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).

Ah right, I'm with you now.

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

Well, last time I tried it, it didn't work :) Since then I've kept half
an eye on wine-patches for RPC/DCOM related patches and have seen a few,
but I must have totally missed some big ones. Either that, or there was
a little one that makes it all go via the pipes/server which I also
missed.

> 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.

There is an article somewhere that explains how it works. Basically the
ITypeInfo (sorry not ITypeLib) objects understand how to convert their
type data into marshal ops/format strings (which term do you prefer?),
which are fed to the RPC runtime which then in turn converts them to
calls to the Ndr APIs. I remember you implementing the last bit (was it
merged?) so for 100% correctness we'd need to rewrite the typelib
marshaller to work the way Windows does.

To be frank I doubt anything depends on that. The custom marshalling it
uses is probably fine for now. One of my goals for CodeWeavers is to
eliminate our dependency on DCOM95.EXE, and obviously that means fixing
whatever bugs block apps.

> 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.

Could you elaborate on how it's not correct? If you mean things like the
lack of IRemoteActivation then yeah, I agree, though I think for now
nailing what we have the floor with test cases and getting InstallShield
solid is more important.

> 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.

Cool, will you be submitting the RPC tests anytime soon?

As for the apartment/OXID/OID stuff, I feel I have a basic understanding
of it. The DCOM RFC makes for informative reading, but it's rather
heavyweight. One of the things I want to do is document this in an
easier to read form in the Wine developers guide, which can also point
to the relevant pieces of code in Wine.

thanks -mike