coding volunteers needed for msrpc server-side API conversion

[Luke Kenneth Casson Leighton]

> I would like to agree with Elrond that the assymetry is bad. Actually
> I don't like functions that allocate resources very much unless there
> is a free function associated: malloc / strdup => free, make_XXX =>
> free_XXX, fopen => fclose etc.

ok.  it's done the way that it is because it conforms to standard usage of
function calls (malloc / free) _and_ it has to be "emulated" at the
server-end (any mallocs client-side have to be auto-malloc'd to reflect
what the client does, and additionally then have to be fred, too, in other
words).

it's also complicated by the fact that _returned_ malloc'd memory is not
controlled, necessarily, by the caller of the function, so you have to
have a "wrapper" function that the caller uses to control the freeing of
the memory malloc'd by the client-side unmarshalling code.

This Is The Way DCE/RPC Works.  we might not like it, but that's just how
it is.  and any code written by microsoft that uses DCE/RPC-based
functions already conforms to this clunky system, so we're ok there.

basically, if it's good enough for DCE and microsoft, it's good enough for
us, we just have to work out what's going on!


> My quetions is, though, would it not be better to invent a auto
> generation system (which I also have had some very loose thoughs
> about) right away, rather that redoing those functions and then invent
> an auto generation system and redo them once again?

yes it would, however it's necessary to get the marshalling code separated
from the client/server functions, first, otherwise you're throwing out
useful code that _can't_ be auto-generated!