January 2004 - Wine-Devel - list.winehq.org

Re: Wineconf Webcast

by Shachar Shemesh

Uwe Bonnes wrote: >Hallo, > > >could it be that the site is overloaded? > > > >>ping wine.codeweavers.com >> >> >PING wine.codeweavers.com (198.144.15.226) 56(84) bytes of data. > >no reaction... > > Someone ran ifdown on the server which was at colo. The server is back online now, and you can use the streaming. Shachar

Jan. 31, 2004

Wineconf Webcast

by Uwe Bonnes

Hallo, could it be that the site is overloaded? > ping wine.codeweavers.com PING wine.codeweavers.com (198.144.15.226) 56(84) bytes of data. no reaction... -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

Jan. 31, 2004

Re: Hel debugging windows app with wine(dbg) + gdb

by Eric Pouech

> Logs with the WINECONSOLE set: that shouldn't matter. The issue you got is linked to the wineconsole's fonts configuration. You shouldn't need to use WINECONSOLE env var. And setting it won't solve your issues. > > METHOD1: > ========= > > == First xterm: > > [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole > [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ > winedbg -- --gdb --no-start a.exe > Using wine_path: /usr/bin/wine-pthread > target remote localhost:34369 > 0000002e:0000002f: create process 'F:\tmp\2\a.exe'/0x4063003c @00401000 > (0<0>) > 0000002e:0000002f: create thread I @00401000 > 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\ntdll.dll @400a0000 (0<0>) > 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\kernel32.dll @40330000 > (0<0>) > 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\msvcrt.dll @40860000 (0<0>) > Unknown option '--use-event=8' this is still a wineconsole configuration problem. I still think your wineconsole isn't properly setup. I'd bet wineconsole -- --backend=user wcmd will fail (while it should work) Note also since you're running with --no-start, you need, before entering the 'target remote' command to: 1/ tell gdb which file it's going to debug (the wine loader) with the 'file' command 2/ use 'sharedlibrary' command I strongly suggest that you don't use the --no-start command (winedbg will do everything you need). > METHOD 2: > ========== > > == First xterm: > > [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole > [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ > /usr/bin/wine-pthread ./a.exe & > [1] 2573 > [leo(a)LeoLux 2]$ > > ==Second xterm: > > [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread this one is not needed for gdb (only for winedbg) > Reading symbols from /usr/lib/wine/libwine.so.1... > (no debugging symbols found)...done. where did you get wine from. looks like all modules are stripped. > See, in this backtrace I get debug info for the wine executable. > If I run gdb ./a.exe instead of gdb /usr/bin/wine-pthread, I do get > (wrong) debug info: again, gdb doesn't understand win32 modules, so it won't work with .exe (you need to specify the wine loader as the program to debug under gdb) A+

Jan. 31, 2004

Re: Hel debugging windows app with wine(dbg) + gdb

by Leo

Eric Pouech wrote: >> Hello, thanks for your reply. >> >> Do you successfully debug windows apps with wine + gdb ? > > yes Great! Please don't go! :) > >> I've tried setting that env variable, but it's even worse in method 1 >> bellow. >> >> I'm pasting the xterm outputs for my attempts: > > there are several unrelated errors/issues you need to fix first. > >> METHOD 1: >> ========== >> >> ==First xterm: >> err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting > > that's the first issue. Your a.exe app is a CUI app. You first need to > set wineconsole to make it work (basically it doesn't find a fixed > font with decent size). It's been a while since we hadn't gotten this > error... > and the rest of the debugging session fails because your debuggee > needs the console up & running (and dies prematurely) > this should work ok even without the --no-start flag Ok, that's fixed (no console problem), but then another error happens (see the log bellow). > >> METHOD 2: >> ========== >> gdb a.exe > > gdb doesn't know nothing about windows application. You should run it > with gdb wine-pthread (as I assume your system is -pthread) Yes, I tried that too (gdb wine, and gdb wine-pthread), but I don't get debug info for my program (just the wine exec). > > However, if your a.exe has been compiled with a win32 compiler, you > won't get any symbol from it (except if the compiler is mingw) Yes, my compiler is mingw, and I've tried -gstabs and -ggdb debug formats. Logs with the WINECONSOLE set: METHOD1: ========= == First xterm: [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ winedbg -- --gdb --no-start a.exe Using wine_path: /usr/bin/wine-pthread target remote localhost:34369 0000002e:0000002f: create process 'F:\tmp\2\a.exe'/0x4063003c @00401000 (0<0>) 0000002e:0000002f: create thread I @00401000 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\ntdll.dll @400a0000 (0<0>) 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\kernel32.dll @40330000 (0<0>) 0000002e:0000002f: loads DLL C:\WINDOWS\SYSTEM\msvcrt.dll @40860000 (0<0>) Unknown option '--use-event=8' Wine 20040121 Usage: wine [options] [--] program_name [arguments] The -- has to be used if you specify arguments (of the program) Options: --debugmsg name Turn debugging-messages on or off --dll name This option is no longer supported --help,-h Show this help message --version,-v Display the Wine version The program winedbg does not exit at this point, just stays there. == Second xterm: [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole [leo(a)LeoLux 2]$ gdb /usr/bin/wine-pthread GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found)... (gdb) target remote localhost:34369 Remote debugging using localhost:34369 Ignoring packet error, continuing... Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target Malformed response to offset query, timeout (gdb) (gdb) c The program is not being run. (gdb) q [leo(a)LeoLux 2]$ METHOD 2: ========== == First xterm: [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ /usr/bin/wine-pthread ./a.exe & [1] 2573 [leo(a)LeoLux 2]$ ==Second xterm: [leo(a)LeoLux 2]$ export WINECONSOLE=/usr/bin/wineconsole [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ gdb wine-pthread GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (no debugging symbols found)... (gdb) attach 2573 Attaching to program: /usr/bin/wine-pthread, process 2573 Reading symbols from /usr/lib/wine/libwine.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/wine/libwine.so.1 Reading symbols from /lib/tls/libpthread.so.0...(no debugging symbols found)... done. [New Thread 1074271616 (LWP 2573)] Loaded symbols for /lib/tls/libpthread.so.0 Reading symbols from /lib/tls/libc.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libc.so.6 Reading symbols from /lib/libdl.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/libdl.so.2 Reading symbols from /lib/tls/libm.so.6...(no debugging symbols found)...done. Loaded symbols for /lib/tls/libm.so.6 Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done. Loaded symbols for /lib/ld-linux.so.2 Reading symbols from /usr/lib/wine/wine/ntdll.dll.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/wine/wine/ntdll.dll.so Reading symbols from /usr/lib/wine/libwine_unicode.so.1... (no debugging symbols found)...done. Loaded symbols for /usr/lib/wine/libwine_unicode.so.1 Reading symbols from /lib/libnss_files.so.2...(no debugging symbols found)... done. Loaded symbols for /lib/libnss_files.so.2 Reading symbols from /usr/lib/wine/wine/kernel32.dll.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/wine/wine/kernel32.dll.so Reading symbols from /usr/lib/wine/wine/msvcrt.dll.so... (no debugging symbols found)...done. Loaded symbols for /usr/lib/wine/wine/msvcrt.dll.so 0xffffe002 in ?? () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1074271616 (LWP 2573)] 0x0040130b in ?? () (gdb) bt #0 0x0040130b in ?? () #1 0x00401347 in ?? () #2 0x00401182 in ?? () #3 0x00401018 in ?? () #4 0x4038e077 in SetThreadExecutionState () from /usr/lib/wine/wine/kernel32.dll.so (gdb) See, in this backtrace I get debug info for the wine executable. If I run gdb ./a.exe instead of gdb /usr/bin/wine-pthread, I do get (wrong) debug info: [leo(a)LeoLux 2]$ gdb ./a.exe GNU gdb Red Hat Linux (5.3post-0.20021129.18rh) Copyright 2003 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"... (gdb) attach 2579 Attaching to program: /home/leo/tmp/2/a.exe, process 2579 0xffffe002 in ?? () (gdb) c Continuing. Program received signal SIGSEGV, Segmentation fault. 0x0040130b in f() () at a.cpp:11 11 { (gdb) bt #0 0x0040130b in f() () at a.cpp:11 #1 0x00401347 in main () at a.cpp:21 #2 0x00401182 in _image_base__ () #3 0x00401018 in _image_base__ () #4 0x4038e077 in ?? () (gdb) I think method 2 seems best (I get debug info), but wrong line numbers. What am I doing wrong? Also, I've tried tu run the tests above with WINELOADER=/usr/bin/wine, and run wine instead of wine-pthread but same thing happens. Thanks.

Jan. 31, 2004

Re: Hel debugging windows app with wine(dbg) + gdb

by Eric Pouech

> Hello, thanks for your reply. > > Do you successfully debug windows apps with wine + gdb ? yes > I've tried setting that env variable, but it's even worse in method 1 > bellow. > > I'm pasting the xterm outputs for my attempts: there are several unrelated errors/issues you need to fix first. > METHOD 1: > ========== > > ==First xterm: > err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting that's the first issue. Your a.exe app is a CUI app. You first need to set wineconsole to make it work (basically it doesn't find a fixed font with decent size). It's been a while since we hadn't gotten this error... and the rest of the debugging session fails because your debuggee needs the console up & running (and dies prematurely) this should work ok even without the --no-start flag > METHOD 2: > ========== > gdb a.exe gdb doesn't know nothing about windows application. You should run it with gdb wine-pthread (as I assume your system is -pthread) However, if your a.exe has been compiled with a win32 compiler, you won't get any symbol from it (except if the compiler is mingw) A+

Jan. 31, 2004

Re: File change notifications

by Joerg Mayer

On Thu, Jan 29, 2004 at 05:23:24PM -0800, Duane Clark wrote: > No, that is the named pipe problem. I retain a private patch in my tree, > which reverts the named pipe patch that causes the crawl. Just a thought: This is not the only time, where a hack is used to fix a specific problem/application that is unacceptable for inclusion into the source tree. How about adding a hacks/ directory where patches like this one can be collected and (more or less) maintained? The maintainance would be the responsibiblity of those who use the patch. Ciao Jörg -- Joerg Mayer <jmayer(a)loplof.de> We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology.

Jan. 31, 2004

Re: WinMM/MIDI problem? (/dev/mixer1 error message)

by Eric Pouech

> Backtrace: > =>0 0x4685c868 (MIDIMAP.DRV..data+0x4aa8868) (ebp=408493c3) > 1 0xc2e4a940 (MSVCRT.DLL..reloc+0x4ae0d940) (ebp=8493fc40) > *** Invalid address 0x8493fc40 (MSVCRT.DLL..reloc+0xc902c40) > > 0x4685c868 (MIDIMAP.DRV..data+0x4aa8868): lock push %ds the offset (0x4aaa8868) is clearly out of midimap.drv module bounds. Don't get mislead by that. A+

Jan. 31, 2004

TransparentBlt

by Kevin Koltzau

Implementation of TransparentBlt This brings up an interesting thing however..it works perfectly under windows (tested on XP), but produces strange results under wine. MaskBlt seems to be broken, but I'm not quite sure what the cause is yet I figured I'd send this out incase the problem is obvious to anyone

Jan. 31, 2004

Re: Posix Subsystem for ReactOS - Project 2010

by Steven Edwards

--- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: > While it's certainly an exiting project, I understood that it was NOT > > based on the Windows subsystem mechanism, but rather hacking your way > > into Windows NT's ring 0 using a device driver. While I'm a great fan > of > "if it works", wouldn't it be nicer, long run, to have a proper > subsystem of it? As one of the other comments said the Windows POSIX subsystem model has some limitations. I would like to bring CoLinux to the point that it ties in as well to Windows and ReactOS as SFU does. > Also, what are you planning on doing with graphic applications? > CoLinux > works by running a X server on the windows machine. That's probably > not > the best solution there is. How is the ReactOS windowing back-end > implemented? We are looking at that currently. ReactOS's TCP/IP implemetation is lacking so running XFree/Cygwin is not a option atm. Once we get TCP/IP going than any Xserver for Windows should do but I would like to bring libw11 in to ReactOS and implement a Xserver as a core OS componate. LibW11 if you dont know about it sits on top of User32/GDI and translates all of the XLib calls to Win32 calls. I we can make a faster/lighter Xserver reusing this code. Thanks Steven __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free web site building tool. Try it! http://webhosting.yahoo.com/ps/sb/

Jan. 31, 2004

Wineconf notice

by Jeremy White

Hi all, Barring disaster, we're going to start Wineconf tomorrow morning at 9:30 am. It looks like we'll have streaming video working; I've updated the wineconf page with some instructions, and a Wine tarball that Works For Me (TM) with the Quicktime player (although mplayer works quite well also). See http://www.winehq.org/wineconf/ for more info. We should also have good 'net connectivity, so feel free to join in via irc. Cheers, Jeremy

Jan. 31, 2004