From: "Jeremy White" jwhite@codeweavers.com
juergen.schmied@debitel.net wrote:
For local marshalling we could use our own protocol and even our own way
of ipc if we don't try to mix processes with native and wine com-dll's. It com server is only interested in the result ;-). And isn't the com marshalling similar to the dce one?
For networking - the dcom protocoll is documented (IMHO).
With COM, the other issue is that someone needs to look at the MS patents in this area. Mainsoft is telling people that they can't use Wine to port COM code, because Microsoft holds patents on some of the Vtable logic used in COM (and no, I don't have any more detail than that, this came to me third hand). I've also asked the FSF for help tracking this FUD down and refuting it.
That would be unfortunate, I would like to hear more about what you find out from FSF.
The upshot of my comment is that it's critical that we use our own marshalling/ipc protocol.
The only problem with this is that CLSCTX_REMOTE_SERVER would then be limited to connecting only to other Wine apps, which could be fairly crippling. If, on the other hand, there is a way to work around these patents, then it would probably be best to not implement the protocol twice. It may well be better to wait a bit and hear the FSF response.
DCOM is documented, and what's more it appears to be well documented, and what's more, it doesn't look as though the implementation will be particularly hard...
Yes, DCOM is very well documented.