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