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

[Luke Kenneth Casson Leighton]

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. 

 what??
 
 i take it that you are concluding that it is impossible for
 freedce to be adapted - that can only be the rationale behind
 your point.

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


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

 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_
 dcethreads!!!

 ... but anyway, it's not an issue: dcethreads can happily
 coexist with linux threads because dcethreads is an emulation
 library.

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

 - 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!)

 since then:

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

 
 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.

 l.