DCOM (was Re: Fix CoMarshalInterThreadInterfaceInStream)

Mike Hearn mh at codeweavers.com
Tue Jun 1 11:27:08 CDT 2004

On Tue, 2004-06-01 at 16:56 +0100, Robert Shearman wrote:
> Actually, it does. It appears as though the interface marshaling
> functions are all compatible with each other on Windows (even though
> MSDN says that they aren't and then says they use the same code as the
> others). Presumably InstallShield was quite understandably passing the
> IStream from on the two functions that were fixed into one of the other
> (supposedly compatible) functions and then that function failed because
> it wasn't the right format.
> 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. 

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.

> I assume you mean this:
> http://www.winehq.com/hypermail/wine-devel/2003/07/att-0179/01-ole.diff__charset_ISO-8859-1


That one is somewhat merged with winehq but yes it's the same patch
pretty much.

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

> 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. Remember that
when this patch was written:

- there were no apartments
- there was no typelib marshaller

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

> o Rewriting the Type Library marshaller -- this isn't much better than
> the code we have at the moment. Again, this isn't done through the
> correct interfaces - I would prefer to use the stubless RPC to do the
> same, but it would probably mean writing half of MIDL into RPCRT4.

Remember when Ove wrote this patch the WineHQ typelib marshaller either
wasn't written, or wasn't X11 licensed, I don't remember which.

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

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

Still, I look forward to seeing your plan for this.

thanks -mike

More information about the wine-devel mailing list