rpcrt4 <-> freedce conversion guide: functions and structures with direct equivalence

[Luke Kenneth Casson Leighton]

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.