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.
- 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)
- The code could lack features that the Microsoft implementation
exposes to clients.
- 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.