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