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

Rob Shearman rob at codeweavers.com
Sun Jan 16 17:51:54 CST 2005

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

I hope you're joking. A DCOM implementation is more than a header file 
containing a few comments and a few declarations of Win32 functions that 
are randomly placed in there.

>are you _seriously_ intending to reimplement the DCE/RPC IDL
>compiler - because that's what's required!!!

We already have our own IDL parser. The only step left is for it to 
generate appropriate type format strings in the same format as Microsoft 

>DCOM is DCE/RPC underneath: DCOM even has the uuids and
>transports of DCE/RPC.

We know.

>  DCOM is just a c++ wrapper on top of
>some underlying c APIs,

No, it is an object oriented wrapper for normal RPC interfaces where a 
state parameter representing the object is implicitly passed to the 
function. It has nothing to do with the language.

> and from what i can gather, you "up"
>the revision numbers of the interfaces, which DCE/RPC can even
>do for you.

No. DCOM interfaces always have a version number of 0.0. To create 
extend an interface you must create a new interface. Microsoft typically 
appends a number to the interface name and makes the new one inherit 
from the old one. I suggest you take a few minutes to read the DCOM 
draft specification, which should clear up a few misconceptions.

>perhaps i should put you in touch with wez furlong who did
>the original FreeDCE DCOM work.

What 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 think you're over estimating by a factor of 2.5 there. Sure, it is a 
large undertaking, but one that we can do one step at a time. We don't 
have to implement *every* protocol to start with and we don't have to 
implement every Ndr data type.

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

No other project has implemented an API that is compatible to 
Microsoft's yet.


More information about the wine-devel mailing list