September 2005 - Wine-Devel

Re: http://cvs.winehq.org/patch.py?id=19964
by Juan Lang Sept. 4, 2005

Sept. 4, 2005

> this latest change to the shellpath test produces the attached error on > Windows XP. Haven't looked into this further. Damn. Alexandre, would you mind backing out this patch? It needs more work. http://cvs.winehq.org/patch.py?id=19964 Thanks, --Juan __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

winedebug/gdb crashes
by Simon Kissane Sept. 4, 2005

Sept. 4, 2005

Hi Using latest wine CVS (checked out today), trying to debug the PackageForTheWeb self-extracting EXE that MS uses to distribute MSDE 2000.... The EXE works fine (albeit with some visual bugs) when running under plain wine instead of winedebug.... Anyone have any idea what might be wrong? (I am very new to wine, although I've been following the wine-devel archives for a while...) Cheers Simon Kissane ===== winedebug window ====== > winedbg --gdb --no-start z:/home/skissane/downloads/MSDE2000A.exe 0000001b:0000001c: create process 'Z:\home\skissane\downloads\MSDE2000A.exe'/0x7fff003c @0040ce00 (0<0>) 0000001b:0000001c: create thread I @0040ce00 target remote localhost:32815 0000001b:0000001c: loads DLL c:\windows\system\ntdll.dll @00840000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\kernel32.dll @00e50000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\advapi32.dll @00770000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\gdi32.dll @00370000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\user32.dll @00270000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\comctl32.dll @00430000 (0<0>) fixme:dbghelp:elf_new_wine_thunks Duplicate in comctl32<elf>: refDataPropName<004b4d60-00000020> subclasses<4b4d60-00000000> 0000001b:0000001c: loads DLL c:\windows\system\iphlpapi.dll @00b00000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\rpcrt4.dll @004e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\ole32.dll @006b0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shlwapi.dll @00d90000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\shell32.dll @00550000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\lz32.dll @003e0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\winex11.drv @00ca0000 (0<0>) 0000001b:0000001c: loads DLL c:\windows\system\imm32.dll @00710000 (0<0>) 0000001b:0000001c: exception code=0x80000003 wine-pthread: gdbproxy.c:1984: extract_packets: Assertion `i == gdbctx->out_len' failed. wine: Unhandled exception (thread 001d), starting debugger... WineDbg starting on pid 0x1e Unhandled exception: assertion failed in 32-bit code (0x595a97e2). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:1007 GS:0033 EIP:595a97e2 ESP:7fcbf38c EBP:7fcbf3a0 EFLAGS:00000202( - 00 - - I1) EAX:00000000 EBX:00004e8c ECX:00004e8c EDX:00000006 ESI:00000000 EDI:2014fff4 Stack dump: 0x7fcbf38c: 200521f8 00004e8c 2014fff4 00000000 0x7fcbf39c: b7efe9e0 7fcbf4cc 20053948 00000006 0x7fcbf3ac: 7fcbf440 00000000 00000060 7d00bf80 0x7fcbf3bc: 00000068 00000000 2008bae7 7fcbf404 0x7fcbf3cc: 7d00bf88 7d00bfec 7fcbf4dc 2014fff4 0x7fcbf3dc: 00000059 0000005a 7fcbf4b0 20086515 0200: sel=1007 base=b7f04000 limit=00001f97 32-bit rw- Backtrace: =>1 0x595a97e2 (0x7fcbf3a0) 2 0x20053948 (0x7fcbf4cc) 3 0x2004b38e (0x7fcbf510) 4 0x75ff7e2f gdb_remote+0xaab(flags=0x1) [/home/skissane/osdevel/wine/programs/winedbg/gdbproxy.c:1981] in winedbg (0x7fcbfddc) 5 0x76002b9b main+0x473(argc=0x2, argv=0x7fee04a8) [/home/skissane/osdevel/wine/programs/winedbg/winedbg.c:1285] in winedbg (0x7fcbfeac) 6 0x75fef26f __wine_exe_main+0x176 in winedbg (0x7fcbff2c) 7 0x4bdbe9e2 start_process+0xb6(arg=0x0) [/home/skissane/osdevel/wine/dlls/kernel/process.c:996] in kernel32 (0x7fcbfff4) 8 0x20004935 wine_switch_to_stack+0x11 in libwine.so.1 (0x00000000) 0x595a97e2: ret Modules: Module Address Debug info Name (21 modules) ELF 0x0051b000-00537000 Deferred ld-linux.so.2 ELF 0x00539000-00663000 Deferred libc.so.6 ELF 0x00665000-00669000 Deferred libdl.so.2 ELF 0x0066b000-0068f000 Deferred libm.so.6 ELF 0x00a05000-00a17000 Deferred libpthread.so.0 ELF 0x20000000-20018000 DIA libwine.so.1 ELF 0x20154000-201c6000 Deferred ntdll<elf> \-PE 0x20170000-201c6000 \ ntdll ELF 0x201ea000-201f5000 Deferred libnss_files.so.2 ELF 0x201f5000-2020b000 Deferred psapi<elf> \-PE 0x20200000-2020b000 \ psapi ELF 0x39fc3000-39fff000 Deferred advapi32<elf> \-PE 0x39fd0000-39fff000 \ advapi32 ELF 0x45dc6000-45e01000 Deferred dbghelp<elf> \-PE 0x45dd0000-45e01000 \ dbghelp ELF 0x4bd54000-4be4f000 Stabs kernel32<elf> \-PE 0x4bd80000-4be4f000 \ kernel32 ELF 0x6be33000-6bf28000 Deferred libwine_unicode.so.1 ELF 0x75fd7000-76019000 Stabs winedbg<elf> \-PE 0x75fe0000-76019000 \ winedbg ELF 0x7bf00000-7bf03000 Deferred <wine-loader> Threads: process tid prio (all id:s are in hex) 0000001b 0000001c 0 0000001e (D) c:\windows\system\winedbg.exe 0000001d 0 <== 0000000e 0000000f 0 0000000a 0000000b 0 WineDbg terminated on pid 0x1e ===== gdb window ====== > gdb GNU gdb Red Hat Linux (6.3.0.0-1.21rh) Copyright 2004 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:32815 Remote debugging using localhost:32815 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)

2 1

More debugger quesions
by Robert Lunnon Sept. 4, 2005

Sept. 4, 2005

Well we are getting somewhere When my test application segfaults the debugger attaches and runs through a number of debug events eventually ariving at a segfault strace:winedbg:dbg_handle_debug_event 00000008:00000009: loads DLL c: \windows\system\imm32.dll @7f440000 (0<0>) trace:winedbg:dbg_handle_debug_event 00000008:00000009: exception code=80000003 Now I added some instrumentation and find the following happens IE trace:winedbg:dbg_handle_debug_event Continue on first exception is true trace:winedbg:dbg_handle_debug_event Breaking switch trace:winedbg:dbg_handle_debug_event Call ContinueDebugEvent trace:winedbg:dbg_handle_debug_event Continuing executio trace:winedbg:dbg_main_loop Wait for next debug event... In this code at the top of dbg_main_loop if (dbg_curr_process) dbg_printf("WineDbg starting on pid 0x%lx\n", dbg_curr_pid); /* wait for first exception */ while (WaitForDebugEvent(&de, INFINITE)) { WINE_TRACE("Calling handle_debug_event 2\n"); if (dbg_handle_debug_event(&de)) {WINE_TRACE("Event handled\n");break;} WINE_TRACE("Wait for next debug event...\n"); } Problem is that the client program is stopped, probably on a segfault trace because I enable tracing (stops) on all machine faults and signals when I attached it (this allows my replacement for wait4 to find out if a fault or signal happened in the debuggee). Everything deadlocks then since the debugger never continues the program after the exception (Or perhaps the wineserver never gets a message to restart it) Perhaps I don't understand the semantics of PTRACE wait4 interactions. Should I just let the app trap machine faults ? All help appreciated Bob

3 4

Re: wine/dlls/dinput joystick_linuxinput.c
by Marcelo Duarte Sept. 4, 2005

Sept. 4, 2005

Alexandre Julliard escreveu: >ChangeSet ID: 19966 >CVSROOT: /opt/cvs-commit >Module name: wine >Changes by: julliard(a)winehq.org 2005/09/03 10:02:38 > >Modified files: > dlls/dinput : joystick_linuxinput.c > >Log message: > Daniel Remenak <dtremenak(a)gmail.com> > Implement EnumEffects, CreateEffect, EnumCreatedEffects, > SendForceFeedbackCommand, and GetForceFeedbackStatus for linux input > joysticks. > >Patch: http://cvs.winehq.org/patch.py?id=19966 > >Old revision New revision Changes Path > 1.25 1.26 +377 -12 wine/dlls/dinput/joystick_linuxinput.c > > I think that this patch is the cause of a compiler error in my box (Fedora core 2): make[2]: Entering directory `/home/mduarte/wine/dlls/dinput' gcc -c -I. -I. -I../../include -I../../include -D__WINESRC__ -D_REENTRANT -fPIC -Wall -pipe -mpreferred-stack-boundary=2 -fno-strict-aliasing -gstabs+ -Wpointer-arith -g -O2 -o joystick_linuxinput.o joystick_linuxinput.c joystick_linuxinput.c: In function `alloc_device': joystick_linuxinput.c:305: error: `FF_STATUS_STOPPED' undeclared (first use in this function) joystick_linuxinput.c:305: error: (Each undeclared identifier is reported only once joystick_linuxinput.c:305: error: for each function it appears in.) joystick_linuxinput.c: In function `joy_polldev': joystick_linuxinput.c:726: error: `EV_FF_STATUS' undeclared (first use in this function) joystick_linuxinput.c: In function `JoystickAImpl_EnumEffects': joystick_linuxinput.c:1182: warning: unused variable `dei' joystick_linuxinput.c: In function `JoystickWImpl_EnumEffects': joystick_linuxinput.c:1266: warning: unused variable `dei' make[2]: ** [joystick_linuxinput.o] Erro 1 make[2]: Leaving directory `/home/mduarte/wine/dlls/dinput' make[1]: ** [dinput/__install-lib__] Erro 2 make[1]: Leaving directory `/home/mduarte/wine/dlls' make: ** [dlls/__install-lib__] Erro 2

1 0

wined3d - d3d9 regression testing
by Oliver Stieber Sept. 3, 2005

Sept. 3, 2005

Hi, Wined3d in CVS is now in a reasonable state to start regression testing new changes against. I usually regression test against a few game demos and DirectX 9 tutorials, I'm going to list the DirectX 9 tutorials as they start to work (there are 68 tutorials that work with the big patch). The current list of working DirectX 9 demos is: from http://www.codesampler.com/dx9src.htm dx9_1pass_emboss_bump_mapping dx9_2pass_emboss_bump_mapping dx9_alpha_blending_texture dx9_multiple_vertex_buffers dx9_texture_dot3_blending dx9_texture_filtering dx9_texture_mipmapping dx9_texture_subloading dx9_tokamak_chain dx9_transforms dx9_vertex_data dx9_view_matrix dx9_view_ports dx9_spot_light dx9_texture dx9_texture_addressing (has a mipmapping error with ATI's drivers) dx9_primitive_types dx9_point_light dx9_dot3_bump_mapping dx9_effect_simple dx9_fonts dx9_indexed_geometry dx9_initialization dx9_lighting (has a slight artifact) dx9_material dx9_multitexture dx9_offscreen_rendering (faked) dx9_2d_demo_game (text for non-power2 textures, ship doesn't animate yet) from http://triplebuffer.devmaster.net/tutorials.php BumpMapping tb_dx9_03 tb_dx9_04 tb_dx9_05 (sort of) tb_dx9_06 tb_dx9_07 tb_dx9_08 tb_dx9_09 tb_dx9_10 from http://www.clootie.ru/delphi/download_dx90.html#Direct3D Tut01_CreateDevice Tut02_Vertices Tut03_Matrices Tut04_Lights Tut05_Textures Tut06_Meshes cull ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

5 12

wine20050830 - is quite fast
by Vijay Kiran Kamuju Sept. 3, 2005

Sept. 3, 2005

hi, previous it took 3-4 minutes to show the application in wine20050725, but the latest has reduced to less than a min. even in managed mode its faster. bye, Vijay

3 3

wine/ tools/winebuild/import.c dlls/winecrt0/M ...
by Stefan Leichter Sept. 3, 2005

Sept. 3, 2005

Hello, this patch http://cvs.winehq.org/patch.py?id=19957 broke the inital startup (creating of .wine directory) of wine for me. Wine crashes now with: wine: creating configuration directory '/home/sle/.wine'... wine-pthread: ne_module.c:203: __wine_dll_register_16: Assertion `i < 50' failed. wine: Unhandled exception (thread 0009), starting debugger... err:seh:EXC_DefaultHandling Unhandled exception code c0000005 flags 0 addr 0x41603340 wine: wineprefixcreate failed while creating '/home/sle/.wine'. sle(a)sle3:/usr/src/wine/wine-20050902-0944> wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/system.reg : No such file or directory wineserver: could not save registry branch to /home/sle/.wine-iqLHbI/ user.reg : No such file or directory on my system (SuSE 9.0) Bye Stefan

1 0

http://cvs.winehq.org/patch.py?id=19964
by Paul Vriens Sept. 3, 2005

Sept. 3, 2005

Hi, this latest change to the shellpath test produces the attached error on Windows XP. Haven't looked into this further. Cheers, Paul.

1 0

Opposite for wine_get_unix_filename()
by Phil Krylov Sept. 3, 2005

Sept. 3, 2005

Hi, What can I use as a function opposite to wine_get_unix_filename() (e.g. to pass a filename to GetSaveFileNameW() dialog)? -- Ph.

2 2

winebuld/winecrt changes and breakages
by Ivan Leo Puoti Sept. 3, 2005

Sept. 3, 2005

Your recent changes have broken the ntoskrnl build, because we're forced to link to kernel32 (that we don't need nor want) Could you please fix this? ntoskrnl is meant to be a native program anyway, so it shouldn't have an entry point routine like win32 progs. Being able to use NtProcessStartup instead of main would be an extra bonus. Of course this means we'll have to call NtProcessTerminate at shutdown but that's something all native progs on windows have to do too. Also I believe this patch of your to be wrong: http://cvs.winehq.org/patch.py?id=19957 The entry point of native drivers is DriverEntry, native drivers don't link to kernel32, thus can't call ExitProcess, also consider DriverEntry is like DllMain, it's an initialisation routine, the real work is then done by the DispatchDeviceControl function, so if you call ExitProcess nobody will have a chance to call the driver anyway. And all this is taken care by the io subsystem, so that entry point routine really shouldn't be there (Apart from the fact that windows doesn't have it). Ivan.

1 0