DCE 1.2.2 released under LGPL license (strategically important for Wine)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jan 17 15:23:21 CST 2005
On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:
> 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.
lacking expertise due to lack of funding and sponsorship is a
more accurate picture.
> 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.
i appreciate this.
> >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
the dce idl compiler consists of 70,000 lines of highly complex code,
20,000 of which is the data handling code.
> >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
> It has nothing to do with the language.
my apologies for being too brief and simplistic in an area
where there are people who have more expertise, time and
funding than i have.
> >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.
it has been a long time since i actually programmed with COM objects:
MSVC 4.3 to be precise, in about 1994.
once again i apologise for my memory on these issues being rusty
in an area where you have more expertise than i.
my main concern in mentioning the capabilities of FreeDCE
are in an effort to save you effort.
> >perhaps i should put you in touch with wez furlong who did
> >the original FreeDCE DCOM work.
> What DCOM work?
i will let wez answer this one, if he is amenable.
> >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.
if you used FreeDCE you would not need to implement any.
you do realise that you are duplicating a project that already exists
(FreeDCE) which is a BSD implementation
... and you do also realise that you are also working, albeit from a
different angle, on exactly the same thing that the samba 4 project is
i find this alternately hilarious and frustrating and on
balance am quite torn about actually telling you in case
you get offended about being told that you are doing a "not
invented here" syndrome or something.
please: i am genuinely curious and seek enlightenment on this issue:
_why_ are you duplicating the efforts of two separate free
> >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.
the area that i understand in particular detail is the
DCE/RPC side of things, and i can say from experience that
the capability of the DCE/RPC side of FreeDCE is outstanding
the area which i am not entirely familiar with is the DCOM side, and
you have the knowledge and expertise in that area.
surely, therefore, it would be reasonable to evaluate FreeDCE for use
in order to get from "here" to "there" in a far quicker time?
More information about the wine-devel