DCE 1.2.2 released under LGPL license (strategically important
rob at codeweavers.com
Mon Jan 17 21:27:52 CST 2005
Luke Kenneth Casson Leighton wrote:
>On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:
>>The only step left is for it to
>>generate appropriate type format strings in the same format as Microsoft
> attached is an example from FreeDCE: samr.idl, with only one function
> in it for simplicity / demonstration purposes.
> you can compile the same IDL file with MSIDL.exe and compare the
<snip interesting info about FreeDCE IDL compiler>
> 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. Anything which relys on that format is going to be of
no use to us. I don't know how much of the codebase that represents.
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.
> if you want to do _that_ you would be well advised to examine matthew
> chapman's "muddle" compiler.
> so i am also placing matthew chapman's "muddle 0.9.0" "un-IDL"
> compiler up on the same site as above.
> in it you will find a decoder that can understand the equivalent
> structures of samr_cstub.c above but in microsoft IDL format not
> DCE/RPC IDL format.
Writing a decompiler and writing the actual functions to do the
marshaling, unmarshaling and sizing are two different things. I have
written an IDL decompiler myself (although it probably isn't anywhere
near as good as muddle appears to be), so I know how to parse most of
the data structures. The fun part is writing the correct data to the
wire and writing test suites to confirm this.
> i hope that this helps you to appreciate that several man-years of
> effort may be shortcut by utilising this amazing piece of technology.
> putting it bluntly: don't waste this opportunity and don't waste this
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
1. There are often a lot of dependencies, such as dcethreads, that one
has to take into account.
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.
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. Whatever the
decision, it would be useful to have someone with your knowledge of the
DCE/RPC protocol helping us with our implementation.
We have re-used code from other projects in the past where the code was
self-contained, such as here:
So please don't think we are dead-set against reusing code and want to
do it all ourselves.
> p.s. DCE/RPC even has acf files - just like MSRPC. it really _is_ the
> same code.
I think you and I have different concepts of what the code means in this
case. I think of the IDL and ACF files as the specification and the
client/server code it generates as the actual code. The code generated
by MIDL is not the same as that generated by the FreeDCE compiler.
More information about the wine-devel