Hi all,
Time to extend my knowledge a bit further, so here are a few misc questions:
Firstly, how do I set a breakpoint that will be triggered in a child process? I'm trying to debug a crash in an InstallShield when using native comctl32, and the backtrace looks like this:
0011: sel=008f base=4020bb20 limit=00000fff 32-bit rw- Backtrace: =>0 0x409cd9c8 (large_handles+0x4368 [gdiobj.c] in gdi32.dll.so) (ebp=40962da8) 1 0xbfb8fa6c (COMCTL32.DLL.ImageList_LoadImageW+0x1a7 in COMCTL32.DLL) (ebp=40962dbc) 2 0xbfb8f698 (COMCTL32.DLL.EntryPoint+0x36 in COMCTL32.DLL) (ebp=40962e34) 3 0x401d78b8 (process_attach+0xf8(wm=0x40310960, lpReserved=0x1) [loader.c:783] in ntdll.dll.so) (ebp=40962e58) 4 0x401d78e7 (process_attach+0x127(wm=0x40310650, lpReserved=0x1) [loader.c:775] in ntdll.dll.so) (ebp=40962e78) 5 0x401d98eb (LdrInitializeThunk+0x1f3(main_file=0x4, CreateFileW_ptr=0x40467de8, unknown3=0x0, unknown4=0x0) [loader.c:1835] in ntdll.dll.so) (ebp=40962f20) 6 0x4049e4b7 (start_process+0x93(arg=0x0) [process.c:171] in kernel32.dll.so) (ebp=40962ff4) 7 0x4002eba5 (wine_switch_to_stack+0x11 in libwine.so.1) (ebp=00000000)
0x409cd9c8 (large_handles+0x4368 [gdiobj.c] in gdi32.dll.so): addb %al,0x0(%eax)
So it seems to be jumping off to somewhere in the data segment of gdi32. I wanted to set a breakpoint a few instructions before the "call" instruction that frame 1 points to, but whenever I try that the program runs, then the standard "Unhandled exception, starting winedbg" message is printed even though it's already running inside winedbg. Do I need to do something special here?
Secondly, I noticed recently that with non-AA fonts winecfg renders wrongly, in particular the labels wrap or are clipped. I don't understand how win32 apps deal with different font sizes without containment based layout - is this a bug in my app (fwiw i've seen variants of this problem in a lot of other apps), a bug in wine, or a design flaw in win32? I've never seen that problem in real windows, so I'd guess bug in wine.
Thirdly, Greg recently mentioned "stubless proxies". Does anybody know where I can read about these?
thanks -mike
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 ;)
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
On Thursday 30 October 2003 04:16 pm, Mike Hearn wrote:
ncalrpc?
The preferred transport for local-to-self RPC/DCOM communications. In NT it's implemented on top of "NT Ports" (see Undocumented NT), the advantge being that this is fast. This RPC transport (but not the NT ports themselves) is simulated using named pipes in wine.
For example, see
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/midl/midl/n...
The whole family is nicely summarized here:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/rpc/rpc/str...
Sheesh, so much to do... it's enough to make me want to finish my cabinet work rather than confront it ;)
BTW, note that transports like http, tcp, etc, could allow wine to do DCOM without resolving the "priveleged ports" issue (at least for fixed endpoints).... of course, our wire protocol is way off and will need fixing before that's possible... luckily I have archived the spec (enclosed for your amusement), which AFAIK fell off the 'net. Older revisions are available by searching (<a href="http://www.brassroots.org/google.html">do not Google!</a>) the 'net; the enclosed version was linked to by Don Box's delicious blog back when it existed at http://www.globecom.net/ietf/draft/draft-brown-dcom-v1-spec-03.html.
On October 31, 2003 02:41 am, Gregory M. Turner wrote:
BTW, note that transports like http, tcp, etc, could allow wine to do DCOM without resolving the "priveleged ports" issue (at least for fixed endpoints).... of course, our wire protocol is way off and will need fixing before that's possible... luckily I have archived the spec (enclosed for your amusement), which AFAIK fell off the 'net. Older revisions are available by searching (<a href="http://www.brassroots.org/google.html">do not Google!</a>) the 'net; the enclosed version was linked to by Don Box's delicious blog back when it existed at http://www.globecom.net/ietf/draft/draft-brown-dcom-v1-spec-03.html.
This is a lot of cool stuff, maybe we can organize a development page for all this info, and stick it somewhere on WineHQ. Otherwise, all these links (and the ones Mike found) will soon be forgoten, and in 3 months\ time, we'll have the same discussion...
-
Dimitrie O. Paun -
Gregory M. Turner -
Mike Hearn