Misc wine debugging questions

[Mike Hearn]

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