As for doing the 10k+ lines of coding myself, I have experience in (de)marshalling and network coding, spent many years doing it, it's more a matter of available time and learning the com wire protocols, neither of which are currently available to me. Here's to hoping someone is already working on it ;).
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).
juergen
juergen.schmied@debitel.net wrote:
As for doing the 10k+ lines of coding myself, I have experience in (de)marshalling and network coding, spent many years doing it, it's more a matter of available time and learning the com wire protocols, neither of which are currently available to me. Here's to hoping someone is already working on it ;).
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.
The upshot of my comment is that it's critical that we use our own marshalling/ipc protocol.
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...
BTW, if there's anyone who wants to volunteer to attack this sooner, I think there are some corporate sponsors who'd be willing to kick in some beer money (okay, maybe we'd even spring for some *nice* beer, and a sofa to drink it on).
Jer
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.
Jeremy White wrote:
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.
For the curious: Snooping on his conversation using google.com, I see it's patent number 5297284 he's worried about.
http://164.195.100.11/netacgi/nph-Parser?Sect2=PTO1&p=1&u=%2Fnetahtm...
- Dan
Dan Kegel wrote:
Jeremy White wrote:
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.
For the curious: Snooping on his conversation using google.com, I see it's patent number 5297284 he's worried about.
http://164.195.100.11/netacgi/nph-Parser?Sect2=PTO1&p=1&u=%2Fnetahtm...
Hmmm - a few points to consider:
1) The patent seems very much oriented towards compilers for object oriented languages. I'm not sure how broadly that patent can be applied to code like ours that uses C to mimic the behaviour of a OO language. If there's an issue anywhere, I'd suspect that it's with g++, not Wine.
2) Even with g++, the work described in the patent that's actually new (ie: wasn't implemented in other C++ compilers as of April 1991) mostly seems to cover multiple inheritance related issues - adjusting the this pointer to the right part of an MI object's vtable, etc. Since a COM interface is nothing but a flat array of function pointers, I fail to see any relevance at all to the Wine side of things.
3) At least some of the g++ people seem to know something about this patent. There's a small thread here:
http://gcc.gnu.org/ml/gcc/1999-08/msg00862.html
And there's some further discussion wrt the ia64 C++ abi here:
http://reality.sgi.com/dehnert_engr/cxx/cxx-closed.html
4) G++ was around for quite some time prior to the patent application. You can download an archival copy of g++ 1.39.0, which predates the patent here:
http://planetmirror.com/pub/gcc/old-releases/gcc-1/?N=D
Anyhow, this is just from a very cursory analysis, but I'd say that the Mainsoft FUD is just that: FUD.
-Gav
-
Dan Kegel -
Gavriel State -
Jeremy White -
juergen.schmied＠debitel.net -
Mike Bond