DCE 1.2.2 released under LGPL license (strategically important for Wine)

[Wez Furlong]

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.
>