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

[Luke Kenneth Casson Leighton]

On Sun, Jan 16, 2005 at 05:51:54PM -0600, Rob Shearman wrote:

> We already have our own IDL parser. 

 you have an IDL parser and that is only about 10% of the work required.


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

 i do not know what the equivalent argument to dceidl -cstub is which
 asks the DCE IDL compiler to keep the intermediate c code: if MSIDL
 does not have that then obviously you will need to examine the

 if you use the MSVC 4.X studio MSIDL compiler you will find
 that what you describe as type format strings will be virtually
 identical to the attached samr_cstub.c code.

 i hassled and harried microsoft enough for them to do an almost
 total rewrite of NT 5's DCE/RPC compiler: i therefore cannot
 reliably inform you as to whether the type format strings
 are the same for the compiler used on NT 5.0.

 you will need the FreeDCE latest cvs and you will also need the patches
 that can be found on http://hands.com/~lkcl.

 these patches integrate Wez's work which he did in 2000 including
 adding "expressions" into the IDL syntax (which you will note is
 missing from DCE 1.2.2 and 1.1) and also "implicit" handles.

 so it is possible to do complex expressions such as length_is(len * 2 -
 1) and, as i understand it to be more essential to DCOM, size_is((len +
 7) & ~0x7) - things like that.

 wez focussed on this critical work in order to properly support DCOM
 formats on-wire, and the reason it only took him a couple of months is
 because of the incredibly well-designed FreeDCE code.

 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.

 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.

 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.

 thank you,

 l.

 p.s. DCE/RPC even has acf files - just like MSRPC.  it really _is_ the
 same code.

-------------- next part --------------
[ uuid(12345778-1234-abcd-ef00-0123456789ac),
  version(1.0),
  pointer_default(unique)
] interface samr
{
  const long MAX_SIZE = 1000;
  typedef [context_handle] void *connect_hnd_t;
  typedef [context_handle] void *domain_hnd_t;
  typedef [context_handle] void *user_hnd_t;
  typedef [context_handle] void *group_hnd_t;
  typedef [context_handle] void *alias_hnd_t;
  typedef [context_handle] void *obj_hnd_t;
  typedef [context_handle] void *unknown_hnd_t;

  /* Function 0x00 */
  long SamrConnect(
        [in] handle_t h ,
        [in]  unsigned short server,
       [out] connect_hnd_t *hnd,
        [in] long access
  );

}
-------------- next part --------------
interface samr {

}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: samr_cstub.c
Type: text/x-csrc
Size: 4232 bytes
Desc: not available
Url : http://www.winehq.org/pipermail/wine-devel/attachments/20050117/7b44e0e1/samr_cstub.c