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