[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: InstallShield and ole question...
From:       "Mike Bond" <mbond () cox ! rr ! com>
Date:       2001-04-28 3:00:45
[Download RAW message or body]


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.

[prev in list] [next in list] [prev in thread] [next in thread]