On Thu, 30 Oct 2003 15:28:49 -0600, Sir Gregory M. Turner scribed thus:
Unfortunately, there isn't a ton of documentation -- or, more accurately, the documentation that you may find is scattered throughout MSDN and the internet, instead of being in an "obvious" place. The MSDN documentation for NdrClientCall2, for example, is almost worthless from the wine implementer's perspective, just stating something like "This is the entry-point for stubless proxies." From the perspective of most users, stubless proxies are a behind-the-scenes implementation detail that isn't worth learning too much about.
The end-programmer's perspective is as follows: pass /Oicf to MIDL, and MIDL will magically generate stubless proxies. I forget if /Oic is considered "stubless" as well, I think it may be. The resulting client proxy code generated by MIDL will contain "NdrClientCall2" or "NdrClientCall" instead of the usual multi-step proxy code (there is no in-proxy marshalling, exception-handling, etc -- just the single call).
In wine, NdrClientCall2 (the more common entry-point) is totally unimplemented -- it simply emits a FIXME and returns indicating success.
The server side is analogous. You will see some code by Ove floating around to generate the manager entry-point thunks in asm, but I don't think they are used yet (?).
Unfortunately, stubless proxies have been the recommended (by Microsoft) mode of generating code from MIDL for many years. Increasingly, I see calls to NdrClientCall2. The only solution (aside from coding wine) is to use native rpcrt4/ole32 -- but this, in turn, means you must use Windows 98 dll's or else you will bump up against the missing "Ports" API if ncalrpc is used (it usually is -- this is why I keep musing that I want to take a crack at implementing this).
ncalrpc?
I think, the way to code those is to use the structures provided by MIDL (and eventually widl) to determine the necessary steps. In particular, I think this is where the format strings come in handy -- presumably, NdrClientCall2 should parse the format strings and determine what to marshall/unmarshall using those. My theory is that the steps taken in NdrClientCall2 would look very much like those MIDL would spit out in /Oi mode.
Your theory is correct. Somehow I stumbled upon this article:
http://www.microsoft.com/msj/0199/com/com0199.aspx
which explains the whole thing. It also talks about how the MS typelib marshaller is implemeneted - basically it generates format strings from the typelib data then feeds that to the Ndr format string interpreters.
Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine.
Indeed. That seems to be the way it goes....
thanks -mike