October 2003 - Wine-Devel - list.winehq.org

Re: Misc wine debugging questions

by 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

Oct. 30, 2003

Misc wine debugging questions

by Mike Hearn

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

Oct. 30, 2003

RE: UI bugs hampering porting effort for shaped window

by Rob

Hi Mike, >> bug 1541 is still *not* fixed correctly. See when passing in NULL in windows >Ah OK, sorry about that, I reopened the bug. Would getifaddrs() do the >trick here? I've not done much work in our winsock code so I can't >really help here. Likely, I don't know the correct cross-platform *nix way of doing it. I only saw source from a STUN server on vovida.org which does SIOCGIFCONF - but I don't know if that is proper way of doing it. Basically, it must return all local IPs on the box, if getifaddrs on *nix does that - then it will work. >Could you write a patch perhaps, as you seen to know what needs to be >done. I would do so if I know what I were doing when it came to doing it the right cross-platform-*nix way. I'd more likely introduce more issues than solve, or introduce some kind of compilation issue on various *nix platforms. My background is from windows, so I'm not sure the correct way of doing it on *nix. >I'm not sure. It might have broken other apps, the window management >code is extremely tricky to get right but Alexandre is the expert here. I can only imagine how tricky this is... However, the current way is definitely broken too - I guess it's the lesser of the two broken evils... Our application is basically useless on WINE without Jerry's fix. -Rob

Oct. 30, 2003

RE: UI bugs hampering porting effort for shaped window

by Mike Hearn

On Thu, 2003-10-30 at 18:59, Rob wrote: > Hi Mike, > > bug 1541 is still *not* fixed correctly. See when passing in NULL in windows > to gethostbyname, it is guarenteed to return a list of local IP addresses > mapped on the box. However, with WINE, passing NULL causes gethostname to be > passed into gethostbyname and does *not* always return back the list of > local IP addresses on the box. This may work on some boxes, and not others, > depending on how the machine is configured and if the DNS lookup on the host > name resolves to the local IP addresses. Ah OK, sorry about that, I reopened the bug. Would getifaddrs() do the trick here? I've not done much work in our winsock code so I can't really help here. > whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something... Could you write a patch perhaps, as you seen to know what needs to be done. > Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea > why it isn't applied to the CVS tree? We have the version out of CVS, which > definately has issues with B1-B4. I'm not sure. It might have broken other apps, the window management code is extremely tricky to get right but Alexandre is the expert here. thanks -mike

Oct. 30, 2003

RE: UI bugs hampering porting effort for shaped window

by Rob

Hi Mike, bug 1541 is still *not* fixed correctly. See when passing in NULL in windows to gethostbyname, it is guarenteed to return a list of local IP addresses mapped on the box. However, with WINE, passing NULL causes gethostname to be passed into gethostbyname and does *not* always return back the list of local IP addresses on the box. This may work on some boxes, and not others, depending on how the machine is configured and if the DNS lookup on the host name resolves to the local IP addresses. File: dlls/winsock/socket.c static WIN_hostent * __ws_gethostbyname(const char *name, int dup_flag) { WIN_hostent *retval = NULL; struct hostent* host; #ifdef HAVE_LINUX_GETHOSTBYNAME_R_6 char *extrabuf; int ebufsize=1024; struct hostent hostentry; int locerr = ENOBUFS; #endif char buf[100]; if( !name) { name = buf; if( gethostname( buf, 100) == -1) { SetLastError( WSAENOBUFS); /* appropriate ? */ return retval; } } whereas if (!name) should use SIOCGIFCONF - SIOCGIFADDR or something... Jerry's patch *does* fix the UI issues actually - B1 through B4 - any idea why it isn't applied to the CVS tree? We have the version out of CVS, which definately has issues with B1-B4. B5 is still broken, but not critical. B6 is confirmed fixed now with CVS build. B7 is still broken, but it's not critical as we have a work around solution. -Rob -----Original Message----- From: wine-devel-admin(a)winehq.org [mailto:wine-devel-admin(a)winehq.org]On Behalf Of Mike Hearn Sent: October 30, 2003 1:22 AM To: wine-devel(a)winehq.com Subject: Re: UI bugs hampering porting effort for shaped window On Wed, 29 Oct 2003 16:59:59 -0800, Sir Rob scribed thus: > Bugzilla Bug 1541 > WS2_32 version of gethostbyname with NULL argument doesn't follow > specification > http://bugs.winehq.org/show_bug.cgi?id=1541 [mike(a)littlegreen working]$ cvs log -N -r1.135 dlls/winsock/socket.c RCS file: /home/wine/wine/dlls/winsock/socket.c,v Working file: dlls/winsock/socket.c head: 1.138 branch: locks: strict access list: keyword substitution: kv total revisions: 138; selected revisions: 1 description: ---------------------------- revision 1.135 date: 2003/09/02 18:12:20; author: julliard; state: Exp; lines: +10 -0 Rein Klazes <rklazes(a)xs4all.nl> _ws_gethostbyname() and WSAAsyncGetHostByName() when called with a null name, should use the name returned by gethostname(). ============================================================================ = What version of Wine were you using? It seems this bug was fixed some time ago, we just forgot to update bugzilla. > B1, B2, B3, and B4 can be fixed by putting a title bar on the application. > (See MAKE_IT_LOOK_LIKE_A_NORMAL_APP_AT_STARTUP in winetest.cpp.) Yes they are caused by our use of override-redirect, which causes a LOT of bug reports. I can't remember why Jerrys patch was not applied, but I think Alexandre has very specific ideas about what to do in this area. > - B6. Copy to the clipboard doesn't work (though pasting from the clipboard > does work). What does a +clipboard trace show? Does the demo app show this? > - B7. Attempting to bring up the right-click context menu causes the app to > hang. Does the demo app show this? If so, perhaps one of us can get a backtrace of the deadlock. thanks -mike

Oct. 30, 2003

Re: getting started with Winelib

by Ralf Juengling

Okay, I got it to compile by manipulating the Makefile.in (kicking some *.rc files). But the executable segfaults: [juenglin(a)alpspitze winemine]$ make sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' ./wineapploader.in >wineapploader || rm -f wineapploader LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/wrc -I. -I/local/include/wine/windows -o rsrc.res rsrc.rc gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o dialog.o dialog.c gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o main.o main.c gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o winemine.exe.dbg.o winemine.exe.dbg.c LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/winebuild -fPIC -o winemine.exe.spec.c --exe winemine.exe -mgui rsrc.res dialog.o main.o winemine.exe.dbg.o -L/local/lib/wine -L/local/lib/wine -ladvapi32 -lcomdlg32 -lgdi32 -lkernel32 -lodbc32 -lole32 -loleaut32 -lshell32 -luser32 -lwinspool gcc -c -I. -I/local/include/wine/windows -g -O2 -fPIC -D_REENTRANT -o winemine.exe.spec.o winemine.exe.spec.c gcc -shared -Wl,-Bsymbolic -o winemine.exe.so dialog.o main.o winemine.exe.dbg.o winemine.exe.spec.o -L/local/lib -lwine -lwine_unicode -lwine_uuid -lm test -f winemine || install wineapploader winemine [juenglin(a)alpspitze winemine]$ winemine Segmentation fault Might this be a configuration problem, or is something broken in Winelib? Since I have no root account, I had to skip the invocation of /sbin/ldconfig when installing wine-20031016. So I set LD_LIBRARY_PATH to /local/lib:/local/lib/wine. Any help appreciated, Ralf On Mon, 2003-10-27 at 18:23, Ralf Juengling wrote: > On Mon, 2003-10-27 at 13:09, Alexandre Julliard wrote: > > Ralf Juengling <juenglin(a)cse.ogi.edu> writes: > > > > > So there is nothing I can do about it at the moment? > > > What is the most recent Wine version in which winemaker used to work? > > > > The previous release should work. Or try this patch: > > > > Index: tools/winemaker > > =================================================================== > > RCS file: /opt/cvs-commit/wine/tools/winemaker,v > > retrieving revision 1.65 > > diff -u -p -r1.65 winemaker > > --- tools/winemaker 5 Aug 2003 18:31:32 -0000 1.65 > > +++ tools/winemaker 27 Oct 2003 21:07:38 -0000 > > @@ -2769,14 +2769,10 @@ then > > WINE_DLL_ROOT="/lib:/lib/wine:/usr/lib:/usr/lib/wine:/usr/local/lib:/usr/local/lib/wine" > > fi > > fi > > -AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.dll.so],[ > > - AC_MSG_ERROR([Could not find the Wine dlls (libntdll.dll.so)]) > > +AC_PATH_FILE(WINE_DLL_ROOT,[libntdll.def],[ > > + AC_MSG_ERROR([Could not find the Wine dlls (libntdll.def)]) > > ],[$WINE_DLL_ROOT]) > > - > > -AC_PATH_LIBRARY(WINE_DLL_ROOT,[-lntdll.dll],[$WINE_LIBRARY_PATH -lwine -lwine_unicode],[ > > - AC_MSG_ERROR([Could not link with the Wine dlls (libntdll.dll.so)]) > > -],[$WINE_DLL_ROOT]) > > -WINE_DLL_PATH="-L$WINE_DLL_ROOT/wine" > > +WINE_DLL_PATH="-L$WINE_DLL_ROOT" > > > > if test -z "$WINE_TOOL_PATH" > > then > > Thanks, together with the patch > > --- /local/downloads/wine-20031016/tools/winemaker 2003-10-27 > 18:02:41.000000000 -0800 > +++ /local/bin/winemaker 2003-10-27 18:14:22.000000000 -0800 > @@ -2635,7 +2635,7 @@ > WINE_UNICODE_ROOT="$WINE_ROOT:$WINE_ROOT/lib:$WINE_ROOT/unicode" > WINE_UUID_ROOT="$WINE_ROOT:$WINE_ROOT/lib:$WINE_ROOT/ole" > > WINE_TOOL_PATH="$WINE_ROOT:$WINE_ROOT/bin:$WINE_ROOT/tools/wrc:$WINE_ROOT/tools/winebuild" > - WINE_DLL_ROOT="$WINE_ROOT/dlls:$WINE_ROOT/lib" > + WINE_DLL_ROOT="$WINE_ROOT/dlls:$WINE_ROOT/lib:$WINE_ROOT/lib/wine" > fi > > AC_ARG_WITH(wine-includes, > > > the generated configure script does its job without errors. > Now I the following error from make: > > [juenglin(a)alpspitze winemine]$ make > sed -e 's,@bindir\@,/usr/local/bin,g' -e 's,@winelibdir\@,.,g' > ./wineapploader.in >wineapploader || rm -f wineapploader > LD_LIBRARY_PATH="/local/lib:$LD_LIBRARY_PATH" /local/bin/wrc -I. > -I/local/include/wine/windows -o En.res En.rc > En.rc:23:22: Error: parse error > make: *** [En.res] Error 1 > > > > -- Ralf Juengling <juenglin(a)cse.ogi.edu>

Oct. 30, 2003

Re: compiling winemine resources

by Ralf Juengling

On Thu, 2003-10-30 at 08:58, Vincent Béron wrote: > Le mer 29/10/2003 à 17:52, Ralf Juengling a écrit : > > I was not successful with compiling the winemine application in > > wine-20031016. When the resource compiler is to compile one > > of the language dependent files, it issues a 'parse error': > > > > [juenglin(a)alpspitze winemine]$ wrc En.rc > > En.rc:23:22: Error: parse error > > > Line 23 in En.rc reads > > LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US > > > > So it looks like wrc does not know what to do with the > > constant LANG_ENGLISH. Is this a bug? Any idea whats going > > wrong here? > > Is LANG_ENGLISH defined (ie, does wrc finds the correct #includes)? > > After thinking a bit more: answer will be no, because you need to > compile rsrc.rc rather than En.rc. En.rc is just an #include for > rsrc.rc. I understand. That means that winemaker is not smart enough to recognize this: the Makefile.in generated by winemaker includes the lines winemine_exe_RC_SRCS = En.rc \ Es.rc \ Fr.rc \ Pt.rc \ Ru.rc \ Si.rc \ rsrc.rc So this is either a bug in winemaker or in the winelib user's guide, which states (in section 1.3.2) that, winemaker --lower-uppercase . ./configure --with-wine=/usr/local/wine make is all one has to do to compile winemine. Thanks to all, Ralf > > Vincent -- Ralf Juengling <juenglin(a)cse.ogi.edu>

Oct. 30, 2003

Re: compiling winemine resources

by Vincent Béron

Le mer 29/10/2003 à 17:52, Ralf Juengling a écrit : > I was not successful with compiling the winemine application in > wine-20031016. When the resource compiler is to compile one > of the language dependent files, it issues a 'parse error': > > [juenglin(a)alpspitze winemine]$ wrc En.rc > En.rc:23:22: Error: parse error > Line 23 in En.rc reads > LANGUAGE LANG_ENGLISH, SUBLANG_ENGLISH_US > > So it looks like wrc does not know what to do with the > constant LANG_ENGLISH. Is this a bug? Any idea whats going > wrong here? Is LANG_ENGLISH defined (ie, does wrc finds the correct #includes)? After thinking a bit more: answer will be no, because you need to compile rsrc.rc rather than En.rc. En.rc is just an #include for rsrc.rc. Vincent

Oct. 30, 2003

Re: Conformance tests fail with 20031016 build

by Sylvain Petreolle

> ~/.wine/config would be good. Attached. > That's interesting. My syslog doesn't have any message like that. > What > kernel are you running? I'm using 2.6.0-test8 on quisquiliae. It seems Im using kernel 2.4.20-20.9 (redhat 9 rpm) here. > Yep, I get that (except I get 14 lines in total) when I take the -q > option > out. ===== Sylvain Petreolle (spetreolle_at_users_dot_sourceforge_dot_net) ICQ #170597259 Say NO to software patents Dites NON aux brevets logiciels "What if tomorrow the War could be over ?" Morpheus, in "Reloaded". ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

Oct. 30, 2003

Re: Where do old rpms go

by Vincent Béron

Le jeu 30/10/2003 à 10:15, Bill Medland a écrit : > On October 29, 2003 10:28 pm, Marcus Meissner wrote: > > On Wed, Oct 29, 2003 at 08:25:39PM -0800, Bill Medland wrote: > > > I apologise for not concentrating; I'm sure that someone has already > > > answered this but I can't find the answer. > > > > > > Do the rpms at SourceForge expire? > > > > According to the file upload page no (or just occasionaly). > > > > But you can "hide" releases, which I do for the SUSE RPMs, to reduce > > the size of my part of the Download page. > > I don't see an obvious option for that. Do I need to get a username and login > to get at that? The hiding is done by packagers. Old links to the individual files still work, but they are not shown on the Download page. Else we'd have about 6 more releases for each distro, which would be a huge mess (unless we sort them by release instead of distro, but I'm not the one asking that). > > > > > > I just want to know since if that is the case I will have to start taking > > > copies. > > > > > > On the same subject, does anyone have a consistant SuSE 8.1 rpm of the > > > 20030618 version? > > > > I can send you the RPM I did for this release. It is still on SF, just > > hidden. > > If it is still there then I can grab it from there, thanks. > (I wish I'd known that it was there a couple of weeks ago) Here's the link for 0618 (Marcus explains why the version is 0619 in his release notes) for SUSE Linux 8.1: http://prdownloads.sourceforge.net/wine/wine-20030619-SL8.1.i586.rpm?downlo… Vincent

Oct. 30, 2003