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
use.
>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.
Rob
More information about the wine-devel
mailing list