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