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

[Rob Shearman]

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 
>>use.
>>    
>>
>
> 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
> output.
>  
>
<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
> code.
>  
>

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.
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:
http://cvs.winehq.org/cvsweb/wine/dlls/iccvid/iccvid.c?rev=1.6&content-type=text/x-cvsweb-markup
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.

Rob