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

IE6/JSCRIPT: hook:NotifyWinEvent, imm:ImmGetContext

by Abdul-Haseeb Ahmad

(sorry if this is a double post, im having difficulties with my mail client) okay I've got nhl 2004 (and the demo) to go into the menus fine but in the full version in the main menu screen (which isnt in the demo, but this error occurs similarly in the demo menu screens that do exist) the drop down menus dont show when i click them; plus there are java script errors, seems like the different html/js files arent communicating with each other properly, prevents me from starting a game because no play button shows up in the demo's game setup screen (first menu screen in the demo, full version cant even get to the game setup screen, as the main menu buttons dont show), but i get messages in the terminal everytime i click on the dropdown menu buttons, and then click off of them as if the drop downs were actually there.. they look like this: fixme:imm:ImmGetContext (0x1002f): stub fixme:hook:NotifyWinEvent (32778,0x1002f,30,0)-stub! fixme:hook:NotifyWinEvent (32773,0x1002f,31,0)-stub! does anyone know what DLL's this message stems from? looks like an incomplete implemntation of something... I also get an error related to MSXML3.DLL as well when i run winedbg on it... id really appreciate it if someone else looked at it and saw what was wrong --- - clean installation of wine20031212 - ie6 installed via mike hearn's script - nhl2004 demo installed (ftp.ea.com/pub/easports/demos/nhl2004/NHL2004Demo.exe) - nhl2004 full version also installed (instructions at http://bugs.winehq.org/show_bug.cgi?id=1970, bug info outdated, ill fix it up later today or tomorrow) - fe/nhl/html/intro.html & fe/nhl/html/sting.html edited so that the movie doesnt load, just goes straight to next page - DLLOverrides for nhl2004.exe/nhldemo.exe same as IE6 installed from Mike Hearn's script except also add oleaut32.dll (song names will show and in the demo the drop down menus will work) - copied *.tlb in my realwindows/system32 into my NHL 2004 Demo dir

Jan. 31, 2004

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

by Abdul-Haseeb Ahmad

This again is related to NHL2004 but I felt it needed to be in a different psot as I think its more related to the way WinMM works... When the HTML files w/MPEGs embedded in NHL2004 load (via IE6) theres a crash.. and it seems to be related to WinMM: ----- fixme:ole:CoCreateInstance no classfactory created for CLSID {6c736db1-bd94-11d0-8a23-00aa00b58e10}, hres is 0x80040154 No debug information in 32bit DLL 'Z:\MNT\D\NHLDEMO\BECONTROLS_PC_Z.DLL' (0x48390000) err:ole:ITypeInfo_fnInvoke did not find member id -525, flags 2! First chance exception: illegal instruction in 32-bit code (0x4685c868). Register dump: CS:0023 SS:002b DS:002b ES:002b FS:0033 GS:005f EIP:4685c868 ESP:408493b0 EBP:408493c3 EFLAGS:00010246( R- 00 I Z- -P1 ) EAX:46c8bda8 EBX:40c5a1d4 ECX:40c59de0 EDX:40310075 ESI:408493e8 EDI:4040e118 Stack dump: 0x408493b0 (KERNEL32.DLL.VerSetConditionMask+0x334386): 40c2e612 46c8bda8 40c5a1d4 4040e118 0x408493c0 (KERNEL32.DLL.VerSetConditionMask+0x334396): 4040e1b0 408493fc 40c2e4a9 4040e118 0x408493d0 (KERNEL32.DLL.VerSetConditionMask+0x3343a6): 408493e8 408493ec 4040e118 4040e118 0x408493e0 (KERNEL32.DLL.VerSetConditionMask+0x3343b6): 46c8bda8 80004005 46c8bda8 0000000d 0x408493f0 (KERNEL32.DLL.VerSetConditionMask+0x3343c6): 00000000 48520190 00000000 4084943c 0x40849400 (KERNEL32.DLL.VerSetConditionMask+0x3343d6): 70e9d83d 4040e118 00000578 40849448 0x40849410 (KERNEL32.DLL.VerSetConditionMask+0x3343e6): 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 ---- im not familiar with how WinMM works, but my hunch is that im getting a crash because my MIDI isnt set up properly because I always get the following error when starting anything in wine: err:wave:OSS_WaveOutInit /dev/mixer1: No such device err:wave:OSS_WaveInInit /dev/mixer1: No such device does anyone know how I can fix this error if its possible?

Jan. 31, 2004

IE6/JSCRIPT: hook:NotifyWinEvent, imm:ImmGetContext

by Abdul-Haseeb Ahmad

okay I've got nhl 2004 (and the demo) to go into the menus fine but in the full version in the main menu screen (which isnt in the demo, but this error occurs similarly in the demo menu screens that do exist) the drop down menus dont show when i click them; plus there are java script errors, seems like the different html/js files arent communicating with each other properly, prevents me from starting a game because no play button shows up in the demo's game setup screen (first menu screen in the demo, full version cant even get to the game setup screen, as the main menu buttons dont show), but i get messages in the terminal everytime i click on the dropdown menu buttons, and then click off of them as if the drop downs were actually there.. they look like this: fixme:imm:ImmGetContext (0x1002f): stub fixme:hook:NotifyWinEvent (32778,0x1002f,30,0)-stub! fixme:hook:NotifyWinEvent (32773,0x1002f,31,0)-stub! does anyone know what DLL's this message stems from? looks like an incomplete implemntation of something... I also get an error related to MSXML3.DLL as well when i run winedbg on it... id really appreciate it if someone else looked at it and saw what was wrong --- - clean installation of wine20031212 - ie6 installed via mike hearn's script - nhl2004 demo installed (ftp.ea.com/pub/easports/demos/nhl2004/NHL2004Demo.exe) - nhl2004 full version also installed (instructions at http://bugs.winehq.org/show_bug.cgi?id=1970, bug info outdated, ill fix it up later today or tomorrow) - fe/nhl/html/intro.html & fe/nhl/html/sting.html edited so that the movie doesnt load, just goes straight to next page - DLLOverrides for nhl2004.exe/nhldemo.exe same as IE6 installed from Mike Hearn's script except also add oleaut32.dll (song names will show and in the demo the drop down menus will work)

Jan. 31, 2004

Re: desktop mode again

by Alexandre Julliard

Alex Pasadyn <ajp(a)mail.utexas.edu> writes: > I can do that, if it would get applied. :) I sent an earlier version > of the sysmetrics patch by itself a long time ago, and it was not > applied because it could give incorrect results in desktop mode. This > version is cleaner that that one, and I think that by itself it would > at least give correct results for an application running in the one > desktop that changed its size. So, Alexandre? Is that worth sending? Sure, that sounds good. -- Alexandre Julliard julliard(a)winehq.com

Jan. 30, 2004

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

by Leo

Eric Pouech wrote: > Leo a écrit : > >> >> >> Hi, >> >> I don't know if this is the place to ask this, but anyway here it goes: >> >> I'm trying to debug a windows application using wine. > > set WINELOADER environment variable to point to your wine binary > before running winedbg > A+ > > Hello, thanks for your reply. Do you successfully debug windows apps with wine + gdb ? 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: METHOD 1: ========== ==First xterm: [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:33199 0000000a:0000000b: create process 'F:\tmp\2\a.exe'/0x4063003c @00401000 (0<0>) 0000000a:0000000b: create thread I @00401000 0000000a:0000000b: loads DLL C:\WINDOWS\SYSTEM\ntdll.dll @400a0000 (0<0>) 0000000a:0000000b: loads DLL C:\WINDOWS\SYSTEM\kernel32.dll @40330000 (0<0>) 0000000a:0000000b: loads DLL C:\WINDOWS\SYSTEM\msvcrt.dll @40860000 (0<0>) err:wineconsole:WINECON_Fatal Couldn't find a decent font, aborting 0000000a:0000000b: exit process (0) wine-pthread: gdbproxy.c:1625: packet_query: Assertion `gdbctx->process && gdbctx->process->threads' failed. wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 8 No debug information in ELF '/usr/bin/wine-pthread' ((nil)) Breakpoint 1 at 0x4000cfc0 No debug information in ELF '/usr/lib/wine/libwine.so.1' (0x40034000) No debug information in ELF '/lib/tls/libpthread.so.0' (0x4004d000) No debug information in ELF '/lib/libdl.so.2' (0x4005b000) No debug information in ELF '/lib/tls/libm.so.6' (0x4005f000) No debug information in ELF '/lib/ld-linux.so.2' (0x40000000) No debug information in ELF '/usr/lib/wine/wine/ntdll.dll.so' (0x40082000) No debug information in ELF '/usr/lib/wine/libwine_unicode.so.1' (0x400f8000) No debug information in ELF '/lib/libnss_files.so.2' (0x40018000) No debug information in ELF '/usr/lib/wine/wine/kernel32.dll.so' (0x40300000) No debug information in ELF '/usr/lib/wine/wine/winedbg.exe.so' (0x40642000) No debug information in ELF '/usr/lib/wine/wine/advapi32.dll.so' (0x407b0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\winedbg.exe' (0x40650000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\NTDLL.DLL' (0x400a0000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\KERNEL32.DLL' (0x40330000) No debug information in 32bit DLL 'C:\WINDOWS\SYSTEM\ADVAPI32.DLL' (0x407c0000) Unhandled exception: assertion failed in 32-bit code (0xffffe002). In 32-bit mode. 0xffffe002 (NTDLL.DLL.memcpy+0xbdf81a22): *** Invalid address 0xffffe002 (NTDLL.DLL.memcpy+0xbdf81a22) -- no code -- Wine-dbg> == Second xterm: [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"... (gdb) target remote localhost:33199 Remote debugging using localhost:33199 Ignoring packet error, continuing... Ignoring packet error, continuing... Couldn't establish connection to remote target Malformed response to offset query, timeout (gdb) METHOD 2: ========== ==First xterm: [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [leo(a)LeoLux 2]$ wine-pthread a.exe & [1] 2780 [leo(a)LeoLux 2]$ ==Second xterm: [leo(a)LeoLux 2]$ export WINELOADER=/usr/bin/wine-pthread [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 2780 Attaching to program: /home/leo/tmp/2/a.exe, process 2780 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) Backtrace indicates files line numbers for first line in each function. Obviously line 11 in a.cpp above doesn't have a valid statement. a.cpp is: #include <stdlib.h> // #include <sys/time.h> // #include <sys/times.h> // #include <unistd.h> #include <windows.h> void f() { // this is line 11 int a=0; for (int i=0; i<10; i++) a*=2; *(char *)0=0; } main() { // this is line 21 Sleep(10000); f(); }

Jan. 30, 2004

Re: system metrics update

by Lionel Ulmer

> **** Lionel, I looked at your ClipCursor patch, and I think it will work > correctly with this for the currently running process, but for it to > take effect in other processes, the code you put in settings.c probably > needs to go to the new X11DRV_handle_desktop_resize function I just added. Hmmm, the next time I will boot in Win2K, I will try to have a program continously print the content of the ClipCursor while another one changes the resolution just to check what happens :-) This way we will be sure exactly what Windows does. If it really propagates, we will see when we will merge both patches :-) Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 30, 2004

Re: Dungeon Keeper thread(s) recently

by Lionel Ulmer

> DINPUT.DLL is not reported as being loaded (using +loaddll) so I think > it's nothing to do with it. You're right... Actually, DungeonKeeper uses a better scheme than us to simulate relative mous grabbing... Will need to do the same in DInput :-) Anyway, with the two last patches I sent, it should work fine now. Lionel -- Lionel Ulmer - http://www.bbrox.org/

Jan. 30, 2004

Re: LostWages: status5.diff

by Eric Pouech

Tom a écrit : > > I'm getting ready to head out the door so here is #5 > it is dmitry's suggestions per: > http://www.winehq.org/hypermail/wine-devel/2004/01/0952.html > > Eric..............thumbs up/down? synchro should be ok. using avifile should be a good test case anyway (even if native mciavi doesn't use it), but this good be removed (doesn't matter much anyway) A+

Jan. 30, 2004

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

by Eric Pouech

Leo a écrit : > > > Hi, > > I don't know if this is the place to ask this, but anyway here it goes: > > I'm trying to debug a windows application using wine. set WINELOADER environment variable to point to your wine binary before running winedbg A+

Jan. 30, 2004

TransparentBlt

by Kevin Koltzau

I noticed Warren Baird has submitted an implementation of TransparentBlt back in Feb 2003.. http://www.winehq.org/hypermail/wine-patches/2003/02/0029.html I'm curious what was wrong with that implementation to keep it from being committed, and what might be done to get it up to par..or maybe it was just missed? Reason I ask is I need this function for uxtheme

Jan. 30, 2004

Re: x11drv

by Alex Pasadyn

Dimitrie O. Paun wrote: > On January 30, 2004 09:00 am, RemiAssailly(a)aol.com wrote: > >>I don't understand you ! >>Without that it does not work. >>With that, it works and graphic working is faster. > > > Maybe so, but it looks obviously incorrect. Not everything > that seems to fix problems is a real fix. You maybe hiding > a bigger issue. The fix as you sent it can't be right, but > you maybe on to something. Someone knowledgable in the area > should express a more informed opinion. > Here's the deal. ChangeDisplaySettings used to always return success, even though it actually did nothing. When I added support for resolution changing using XRandR, one of the changes was to actually fail if the requested mode did not exist. If XRandR or XVidMode is used, the requested mode must really exist, or you will get an error. In desktop mode, there is a hardcoded list of allowable modes that covers all the commonly used ones. The original post about this issue included an error message that included the string (NoRes) in it, which meant that XRandR, XVidMode, and desktop mode were all disabled. While I think the correct fix is for the user to enable desktop mode or real resolution changing, there is a different hack that can be used without causing crashes. Simply go into X11DRV_ChangeDisplaySettingsExW and replace both instances of DISP_CHANGE_BADMODE with DISP_CHANGE_SUCCESSFUL. Alex

Jan. 30, 2004

Re: Add a test case and a fix for the window styles state at the window creation time

by Bill Medland

On January 30, 2004 08:08 am, Dmitry Timoshkov wrote: > Hello, > > Changelog: > Dmitry Timoshkov <dmitry(a)codeweavers.com> > Add a test case and a fix for the window styles state > at the window creation time. > SNIP > + cs->style |= WS_CAPTION; > + wndPtr->flags |= WIN_NEED_SIZE; > + } > + } > + > /* Fill the window structure */ > > wndPtr->tid = GetCurrentThreadId(); SNIP The problem with comments is that they don't get maintained. I suggest that this is one of those "x=x+1; /* increment x */" type comments and the comment should go too. (If it is not clear to anyone, the comment suggests that below the comment is where the structure gets filled in and the casual observer won't notice that one element was actually done before the comment). Bill -- Bill Medland mailto:billmedland(a)mercuryspeed.com http://webhome.idirect.com/~kbmed

Jan. 30, 2004

RE: desktop mode again

by Robert Shearman

Alex Pasadyn wrote: > > Robert Shearman wrote: > > > I suggest you put the system metrics stuff in a separate patch. > It is a lot more tested and more likely to get in than the other > code, which is quite a big change. > > I can do that, if it would get applied. :) I sent an earlier version > of the sysmetrics patch by itself a long time ago, and it was not > applied because it could give incorrect results in desktop mode. This > version is cleaner that that one, and I think that by itself it would at > least give correct results for an application running in the one desktop > that changed its size. So, Alexandre? Is that worth sending? How about a quick hack doing the same as we do now if the user wants desktop mode, but use the new code otherwise? Then if a version of this patch gets applied you can remove that hack. > X doesn't allow inter-process operations right? > > Actually, I think X doesn't care. It has no problem with me having one > process create the desktop window and another process creating a > "normal" window inside it. Or did you mean something else? > > This is bad. There shouldn't be a direct server call in a > > normal wine program. We should try and find the right Windows API > > to do this, or create our own export from user32. Only user32, > > gdi32, ntdll and x11drv should need to use server calls (and > > kernel32 out of convenience). It has just occurred to me that CreateDesktop and SwitchDesktop are the functions to use, but that means writing a lot of extra code. > > Why do you need two windows procedures? If you're sure you do > need both of them, a comment in the code explaining why would be > good. It's not at all obvious to the casual observer (i.e. me) otherwise. > > That I can add. The basic thing is that the "main" window created by > winedesktop is just a normal ordinary window, and it can be minimized, > etc. The child window came in because an app should be able to ask for > the size of the desktop window and always get the right answer. I > thought it was better to create a child window than to have to put code > in the server to intercept calls to get the size of the desktop and > fudge the results if it was minimized. Ok, that sounds sensible. > > It appears you don't launch winedesktop anywhere and you don't > > remove any options from the config file. It will be a bit > > confusing for people who do use the wine desktop when it doesn't > > do anything after applying your patch (until they launch > > winedesktop). Do you plan to launch winedesktop at startup > > (possibly just after wineserver is launched) if the desktop > > setting is enabled? > This was described when I originally posted a version of this a long > time ago. The general idea is that if no other Wine apps are running, > you can start winedesktop. I still think it would be a good idea to launch it for them automatically. > While it's running, all Wine apps that get > started get trapped inside the desktop. I would like to find a way to > have multiple desktops or desktop coexisting with non-desktop, but that > would be a ton of additional bookkeeping in the server. We can adapt the multi-monitor APIs to do this. However, Windows doesn't support multiple independent desktops, but there are probably was around this. Rob

Jan. 30, 2004

Re: Wine totally broken on Fedora Core because of security patch in kernel

by Abdul-Haseeb Ahmad

Ivan Leo Murray-Smith wrote: > FC has some security patch in the kernel, so wine fails with this error: > > err:virtual:map_image Standard load address for a Win32 program (0x00400000) > not available - security-patched kernel ? > wine: could not load L"C:\\Program Files\\Common > Files\\InstallShield\\Engine\\6\\Intel 32\\IKernel.exe" as Win32 binary > > as reported by Marek Lipovcan and some users on the newsgroup, I don't have fc > myself, but I guess something should be done about this. > > Ivan. > > > > i made myself a script that runs LD_ASSUME_KERNEL=2.2.5 setarch i386 wine $* it should work if you run wine in a similar format to this in bash

Jan. 30, 2004

Re: [oleaut32] implement VarMod() + tests, fix bug in VarNot()

by Chris Morgan

On Friday 30 January 2004 04:50 am, Hans Leidekker wrote: > On Friday 30 January 2004 04:30, Chris Morgan wrote: > > Still have a couple of issues with this change. I'm not sure why the > > (BSTR) tests fail under wine and not windows, I've wrappered them with > > todo_wine{} but they still get listed as failures. > > Run it like so: > > WINETEST_PLATFORM="wine" wine oleaut32_crosstest.exe vartest > > and you won't get the failures. > > -Hans Ahh ok ;-) Chris

Jan. 30, 2004