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