Misc wine debugging questions

[Gregory M. Turner]

On Thursday 30 October 2003 02:35 pm, Mike Hearn wrote:
> Thirdly, Greg recently mentioned "stubless proxies". Does anybody know
> where I can read about these?
>
> thanks -mike

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).

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.

Stated succinctly, stubless proxies are the RPC/DCOM holy grail for wine.

Unfortunately, it doesn't make much sense to start working /Oic[f] until /Oi 
mode is working a lot better.  Things like the OXID Resolver, 
IObjectExporter, RpcObjectSetType, etc, really ought to be in place before we 
start complicating matters by implementing subless proxies... of course, if 
someone wants to prove me wrong, be my guest ;)

-- 
gmt

"To take from one, because it is thought his own industry and that
of his fathers has acquired too much, in order to spare to others,
who, or whose fathers, have not exercised equal industry and skill,
is to violate arbitrarily the first principle of association,
the guarantee to everyone the free exercise of his industry and
the fruits acquired by it." --Thomas Jefferson