i've started documenting and reviewing the functions and structures in wine's rpcrt4 implementation and providing direct equivalents, including the prototypes of each, in freedce.
http://lkcl.net/software/msrpc_to_dcerpc
i figured that if i was going to be saying "the two are equivalent" i might best actually be telling the truth :) so far, it looks like i'm about... 40% accurate: certainly 95% of the "public" functions (the ones with IDL files specifying them) are dead-on, with NDRCContext* and NDRSContext* being difficult to find equivalents (will look tomorrow), Mep* functions being _way_ out (10of), Ndr* presently difficult to track down (will look tomorrow), RpcServer* being 95% dead-on, RpcBinding* being 100% on, Uuid* is going to be dead-on, RpcAsync* being _way_ out, etc. etc.
i left the Ndr marshalling functions (conformant, simple, etc) for now, will get to those later.
these are just the public functions i'm evaluating (quantity 283 in rpcrt4.def) - there are behind-the-scenes implementations of the second-and-beyond layer APIs which are... well... is it actually worth evaluating them?
that wasn't a rhetorical question.
is it a worthwhile exercise to point out the equivalent functions, those that can be identified, between "internal" functions as found in rpcrt4, and those in freedce?
e.g. struct connection_ops will have a direct equivalence somewhere in freedce (i'd start investigating ncklib/transport/cn/cninit.c, with rpc_prot_call_epv_t and other friends being likely candidates).
the internal infrastructure in freedce is just... _incredible_. everything's subdivided down into clean interfaces behind vector tables, such that it's an incredibly trivial task to add a new transport or a new authentication module. i dropped in uxd_naf (unix domain sockets network address family) really easily - the interface for adding network address families (towers, aka sockaddr types) is clearly laid out. the transports are subdivided into dg (datagram) and cn (connection) so if you want to add a datagram transport, you know which set of 25 functions to implement, and likewise for a connection-orientated transport.
remember - people have been dropping dce/rpc on top of ncacn_http, direct onto netbios datagrams and netbios sessions, decnet, osi networking, _goodness_ knows what else, and dropping in kerberos authentication, nt domains authentication - the works.
you would do well to consider taking at the very least the transport infrastructure and the authentication infrastructure from freedce and just dropping it in. i've already added ncacn_np - on top of _real_ NamedPipes - for the Win32 port of freedce.
l.