DCE 1.2.2 released under LGPL license (strategically important for Wine)
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Tue Jan 18 05:18:29 CST 2005
On Mon, Jan 17, 2005 at 09:27:52PM -0600, Rob Shearman wrote:
> >the expression format of what you refer to as "type format strings"
> >that wez picked was for practicality purposes not for compatibility or
> >interoperability with NT.
> This is the point.
i take it that you are concluding that it is impossible for
freedce to be adapted - that can only be the rationale behind
> Anything which relys on that format is going to be of
> no use to us.
oh _come_ on, it took wez and myself a pitiful amount of time,
relatively speaking, to add that, and the reason we arbitrarily
picked "any old" extension to the type format strings was because we
didn't have a requirement for format-compatibility with MSRPC.
if someone pays me or wez to do that you'll _have_ type format
string compatibility within a very short amount of time.
> I don't know how much of the codebase that represents.
the patch is about 5,000 lines and as such represents under 1% of
> Sure, we can probably use other parts of the codebase like the different
> transports, as long as they don't depend on stuff like dcethreads, which
> is most likely incompatible with Wine.
it is my understanding that, from various empirical observations
and hints, that microsoft adopted dcethreads as Win32 threads.
and the TRY/CATCH/RAISE/RERAISE macros and principles.
i find it hilarious that people bitch about how unreliable and
flakey DCOM and Win32 threaded programs, because that flakiness
i believe is derived from The Open Group's necessary decision
to guess which way the POSIX threads final implementation
they had to implement code NOW and had to go with POSIX Draft
4 threads, so off they went, and then the POSIX committee
retrospectively decided that things like signal propagation
(such that a client may press ctrl-c and the server receive
it, and the server may segfault and the client receive it)
were far too complicated oh, nonononono, can't have that,
and removed it from the final threads model.
... but anyway, i digress.
from what i can piece together, Wine's threads should _be_
... but anyway, it's not an issue: dcethreads can happily
coexist with linux threads because dcethreads is an emulation
it's perfectly possible to link FreeDCE client-side stub code
into other projects, and expect it to work.
> I do thank you for your concern, but I don't think you appreciate the
> effort in ripping code kicking and screaming and integrating it in into
> another project.
> 1. There are often a lot of dependencies, such as dcethreads, that one
> has to take into account.
i would not consider that to be an issue: loic is an expert on threads
including dcethreads, posix threads and NLTP (i probably have those
letters in the wrong order)
> 2. The code could lack features that the Microsoft implementation
> exposes to clients.
> 3. If a Wine developer writes the code it is more likely to be
> maintained and we will have an expert to report problems to.
well there is a simple answer to both point 2) and 3): contract
hire or sponsor me and/or wez and/or elrond to work on this
stuff, focussing on wine integration, and to do knowledge
transfer on the code to bring the Wine team up to speed.
> I'll certainly look into re-using as much code as possible, but last
> time I looked it didn't look like it was worth the effort.
the first time i looked at DCE was in about 1996.
i too concluded that:
- it was totally useless
- that there was no benefit to it
- that i would have more fun learning how to do this myself
- that i did not have sufficient knowledge to delve into DCE code
in order to modify or maintain it.
- that the copyright and licensing were incompatible anyway
- that DCE wouldn't be capable of doing the wire-compatibility
for MSRPC nor that it could be adopted.
- that 250,000 lines of code is not only scary but is also totally
- that i needed to avoid the documentation for copyright reasons
- that i needed to do this on my own because of clean-room
network-reverse engineering reasons.
i was wrong on virtually every single count, to various degrees
(except the fun bit, for the first three years: it was GREAT!)
- i implemented from 1997 to 1999 approximately 30,000 of hand-crafted
IDL marshalling and unmarshalling code which led me to understand
the IDL format in great detail
- i implemented 20,000 lines of client-side code that looks
_strikingly_ similar to Win32 APIs and critical unpublished
microsoft APIs such as the lsa code, netlogon code and samr code
- i implemented 40,000 lines of server-side code that again looks
(i managed to briefly glance over someone's shoulder when they
were editing Advanced Server for Unix source code at an interop
lab) strikingly similar to NT.
in about 1999 i began to realise that the path i had led was completely
nuts - _three years later_ - and began to seek out the DCE
documentation, and methods to simplify the tasks involved.
matthew chapman hunted down the dce stuff, examined the nt dlls, and
came up with MUDDLE, which if you try it on NT 4.0 server dlls, you end
up with idl files.
with the benefit of the experience and knowledge that we had gained,
i concluded that it would be insane to continue to develop the
hard-coded framework any further, and i began to focus my efforts
on understanding FreeDCE.
at that point, i also noticed significant overlap with other projects,
and the number of projects has increased since 2000 (ReactOS, the linux
NTFS kernel driver, OpenChange).
since then, i have been advocating to others that FreeDCE will save
them an awful lot of time
the only person that has listened so far is luke howard, and
in XAD he has produced not a free software project but has
utilised "outsourcing" techniques to integrate free software
basically, what i am saying is that this stuff is sufficiently
complex and _way_ over our heads that it may be that, just
like i did, you will need another two years of battling with
what you are doing before realising either with hindsight
(if you are successful) or frustration (if only partially so)
that utilising FreeDCE would have been a good idea, or that
you yourself now have enough knowledge to realise so.
(that was intended respectfully, by the way, in case that
wasn't clear: if you choose to continue reimplementing MSRPC,
i sincerely hope that it is successful and turns out to be
the right choice)
alternatively, you are now aware of the people that have the
expertise and the willingness - _if_ they receive money - to
work on this stuff, and to put all the pieces together.
the choice is yours.
More information about the wine-devel