DCE 1.2.2 released under LGPL license (strategically important
for Wine)
Wez Furlong
wez at thebrainroom.com
Sun Jan 16 16:44:26 CST 2005
I've been distant from DCE for a little while, so I don't have all the
details at the tip of my brain.
Luke isn't quite correct, but is mostly correct :-)
FreeDCE doesn't contain a working DCOM implementation. The following
areas need(ed) some work for that:
1/ NTLMSSP (which we now have in freedce, thanks to Luke)
2/ The rpcd/endpoint mapper needs awareness of ORPC and implement one or
two ORPC specific services in order to maintain the lifetime of remotely
activated components.
3/ The IDL compiler and marshalling stubs need awareness of ORPC
4/ On top of that, the local COM library needs to be implemented
Filling out these areas is *massively less work* than re-implementing
DCE-RPC; I made a fair start on (2) and (3) 4 years ago, but lack of
interest from the world at large (and a need to pay my bills) caused it
to be put on hold.
Please believe me when I say that there is a large amount of non-trivial
code in there; I have huge respect for the people that wrote it and the
amount of time that it took to get it there. Don't forget that this is
production quality code that has been used by huge players for years. I
pity anyone that would think of taking on the task of re-implementing
it, not because it's nasty but because it's a *huge* effort.
While I can't commit development time right at this moment (I'm booked
up with the PHP project in most of my "free" time), I am happy to help
in any other way that I can; I researched the implementation of DCOM
quite heavily back then, so I probably have a better idea than most
about getting it done.
--Wez.
PS: I'd *love* to have someone sponsor my employer (omniti.com) to have
me work on getting this implemented.
Luke Kenneth Casson Leighton wrote:
>>I already checked out FreeDCE and the newly released DCE-RPC several days
>>ago. Neither provides a DCOM implementation, neither resembles what we
>>need. We may be able to take some code or ideas from them with some work
>>to massage it, but there's not much of use there.
>
>
> dear mike,
>
> you are correct about DCE 1.2.2 not containing DCOM: it is
> FreeDCE that does.
>
> other than that - with all due respect, and if i understand
> you correctly: you are wrong [or looking in the wrong place]
>
>e see this:
>
> http://cvs.sourceforge.net/viewcvs.py/freedce/freedce/dcom/dcom.h?rev=1.1&view=markup
>
> which has been available for just over four years, now.
>
>
> are you _seriously_ intending to reimplement the DCE/RPC IDL
> compiler - because that's what's required!!!
>
> DCOM is DCE/RPC underneath: DCOM even has the uuids and
> transports of DCE/RPC. DCOM is just a c++ wrapper on top of
> some underlying c APIs, and from what i can gather, you "up"
> the revision numbers of the interfaces, which DCE/RPC can even
> do for you.
>
> perhaps i should put you in touch with wez furlong who did
> the original FreeDCE DCOM work.
>
> you _cannot_ be serious about reinventing the 250,000 lines
> of c code required to properly support DCE/RPC which is a
> prerequisite for supporting DCOM.
>
> i can understand the samba team doing that, but _another_
> project doing it???
>
> please tell me i am wrong in believing that you are giving
> serious consideration to a _third_ DCE/RPC runtime and
> development environment, to compete with samba 4's GPL'd
> implementation which is in development and with FreeDCE's
> complete reference implementation which is available under an
> OSF 1.0 BSD-like license.
>
> l.
>
More information about the wine-devel
mailing list