DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)

[Robert Shearman]

On Tue, 2004-06-01 at 19:42, Mike Hearn wrote:

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

I haven't really implemented the Ndr APIs properly yet, but I have
written an interpreter outside of Wine that can parse every type. It's
just a question of outputting the right information on the wire. The
test framework could be ideal for this type of situation. The big patch
I had was implementing the stubless interpreter (NdrClientCall2).

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

That depends on what your definition of "fine" is. I think I've hit a
bug in it that causes InstallShield to fail. In the long run I think it
would be best to use as much RPC code as possible so that we only have
to fix bugs in one place.

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

IRemoteActivation is one, but there are too many other hacks. If it
solves a bug that stops InstallShield working, then fine, we should
merge the code.

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

Unfortunately not. Due to the different calling conventions with
structures, the tests don't work when compiled as ELF.

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

Ok, I had forgotten about the DCOM RFC. Maybe reading that will clear
some things up for me.

Rob