May 2005 - Wine-Devel - list.winehq.org

UT2003 regression, Windowing problem
by Ann and Jason Edmeades May 10, 2005

May 10, 2005

Hi all, I'm trying to track down a regression which causes UT2003 (and UT2004 / Unreal2 apparently) to fail, and am getting stuck at the windowing level so would appreciate any thoughts as to possible causes. (And no, I haven't tried to work out what regressed it... Why spoil my fun!) Basically we enter RedrawWindow and continually loop because the window in question never gets repainted 'properly'. The window has just been created, and very little has happened on the window other than being activated. A +tid,+win,+msg,+x11drv,+spy (with various extra debug code in) shows: Initial pass into RedrawWindow is via UpdateWindow which forces a redrawnow 0009:fixme:win:UpdateWindow In updateWindow 0009:trace:win:RedrawWindow 0x1002e whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW 0009:fixme:win:RedrawWindow redraw hrgn Because of flags, we insist we redraw the screen now... 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 256 0009:fixme:win:RedrawWindow @@@> Calling.... (We never leave the update_now routine) 0009:fixme:win:update_now Before wait We wait for outstanding painting related events. The window has just been created, so its just a clear of the whole screen from 0009:trace:x11drv:X11DRV_Expose win 0x1002e (3000006) 0,0 648x507 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e B4 Offset into rect (0,0)-(648,507) 0009:trace:x11drv:X11DRV_Expose @@@> 0x1002e Offset into rect (-4,-23)-(644,484) 0009:trace:win:RedrawWindow 0x1002e rect (-4,-23)-(644,484) flags: RDW_INVALIDATE RDW_ERASE RDW_ALLCHILDREN RDW_FRAME 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 So the outstanding event was an invalidate of the whole area 0009:fixme:win:update_now After wait 0009:fixme:win:update_now @@> Calling erase 0009:fixme:win:update_now @@> Called erase The infinite for loop 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x40027bec The window needs redrawing 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e So the invalid region is still set, so its assumed the updates have failed so we schedule a complete erase 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing 0009:fixme:win:update_now 0x1002e region 0x150c box (4,23)-(644,503) In send_erase 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg=WM_ERASEBKGND,wp=000014ac,lp=00000000) 0009:trace:win:RedrawWindow 0x1002e rect (0,0)-(640,480) flags: RDW_INVALIDATE RDW_ERASE RDW_NOCHILDREN 0009:fixme:win:RedrawWindow redraw rects 0009:fixme:win:RedrawWindow @@@> Redrawwindow calling updatenow? 0 0009:fixme:win:send_erase Out send_erase So we loop again... 0009:fixme:win:update_now @@> FOR loop prev=(nil) child=0x1002e 0009:fixme:win:update_now Paint required! 0009:trace:msg:WINPROC_CallProc32WTo32A func 0x11017650 (hwnd=0x1002e,msg= WM_PAINT,wp=00000000,lp=00000000) ***> Nothing happens here as a result of the paint? Etc etc 0009:fixme:win:update_now @@> FOR loop prev=0x1002e child=0x1002e 0009:fixme:win:update_now @@@> 0x1002e not repainted properly, erasing 0009:trace:win:update_now 0x1002e not repainted properly, erasing etc etc So should there have been an action as a result of the WM_PAINT, and is it valid for it not to occur (ie is wine overdoing the assumption on redrawing) Is updatenow correct for an UpdateWindow call (MSDN states a WM_PAINT should be sent, but doesn't say it will check it gets done). Note there are 2 suspicious patches in painting.c both by AJ - (1.19 and 1.20) - The first tries to handle broken WM_PAINT handlers by avoiding the loop, and the 2nd (1.20) just forces the loop to occur! Adding a 'break' in the case where child==prev and a send ncpaint / send erase has occurred avoids the problem, but what is the correct fix Jason

3 2

games
by Ivan Leo Puoti May 10, 2005

May 10, 2005

If you've got a safedisk1 copy protected game please contact me by private email. All safedisk1 games have a .ICD file in the root of the CD. Ivan.

1 0

[Fwd: Re: Commercial support]
by StartCom Ltd. May 10, 2005

May 10, 2005

Or maybe just because of it, there is a need for commercial support, or somebody might need that support. If it would be running, by just clicking on the executable, no support is really needed, at least not for standard applications. IBM does very well know the existents of Wine (they even acknowledged that by themselves lately), but may very well not support it, because of inter-relation with MS. As of now (just a guess), they don't want to get into more hot water right now.... gslink wrote: > Go to the Wine HQ site and click on applications database. If you > need more applications check the listed links. > This is a problem with every development effort and nobody is blaming > anybody. The larger the effort the worse it gets. This is probably > the worst problem both Microsoft and IBM have with code. If you > change anything in Wine something somewhere will probably quit > running. This is simply the price of progress. My comment, and it is > not a criticism, is that Wine still has rough edges. Eventually these > will go away but for now, you can't simply load Wine into Linux and > blindly start loading in applications. The more complex the > application the more likely it needs setup. As versions progress > setup procedures change and as a result things quit running. > Microsoft Office doesn't run without setup and neither do many of the > older games such as Alice or Rune. Even things like Warcraft come and > go. This is not a criticism it is just the way things are and that is > why I think it is too early to start thinking about commercial support. > What somebody needs to do now is to get a relationship with IBM > similar to the one that Eclipse has. IBM has a problem currently > because there is no native Lotus Notes client for Linux. Wine could > easily solve this problem. I talked to some of the marketing managers > in IBM and most had never heard of Wine. The IBM development labs are > currently starting to develop this native client. If IBM could use > Wine it could save them money and sueing Wine is one thing sueing IBM > is another. > > -- Regards Signer: Eddy Nigg Company: StartCom Linux at www.startcom.org <http://www.startcom.org/> MediaHost^(TM) at www.mediahost.org <http://www.mediahost.org/> Skype: startcom <callto://startcom/> Phone: +1.213.341.0390 Import StartCom Public CA <http://cert.startcom.org/index.php?app=109>

2 1

Re: [QCAP] patch 4, Adding enumPins object
by Paul Vriens May 10, 2005

May 10, 2005

> Changelog > - dlls/qcap/Makefile.in > - dlls/qcap/enumpins.c > Add IEnumPins object for use by other class objects. This is taken > from quartz with only minor adaptions. > > Rolf Kalbermatter > > > +WINE_DEFAULT_DEBUG_CHANNEL(quartz); Shouldn't that be qcap ? Cheers, Paul.

1 0

Re: Commercial support
by gslink May 9, 2005

May 9, 2005

I recently took the list of applications from headquarters that are listed as running properly and found that many of these are available for little cost. I bought a few and tried to run them. Not a one ran as is from the box. I was able to get all of them to run with some trouble. One big problem I see with Wine is that there is no good testing. As versions progress things quit running and the author has no way of knowing. I have no good solution for this problem but I suspect that it needs attention. It is, of course, part of the documentation problem. It is not in the nature of programmers to document their work.

3 4

Re: dlls/opengl32: fix WGL_ACCELERATION_ARB queries from applications
by Raphael May 9, 2005

May 9, 2005

On Monday 09 May 2005 11:09, Aric Cyr wrote: > Just a small patch to Raphael's recent CVS commit which added a much > better wglChoosePixelFormatARB() and friends. This patch fixes the > return values that an application will recieve when it queries the > WGL_ACCELERATION_ARB pixel format attribute. good catch :) Regards, Raphael

2 1

Re: Make test status - latest CVS
by Juan Lang May 9, 2005

May 9, 2005

--- Shachar Shemesh <wine-devel(a)shemesh.biz> wrote: > >I don't see the same thing here. Could you send me a heap trace? > > > Aw, man! You were sitting right behind me when that happened. Couldn't > you have taken my laptop and debugged it on the spot then? :-) I wanted to have a chance to run it, read over the code, etc. I'm afraid I don't see the problem still. Maybe a storage,heap trace? --Juan __________________________________ Do you Yahoo!? Make Yahoo! your home page http://www.yahoo.com/r/hs

1 0

APPDB: Half-Life and Counter-Strike with WINE
by Hiji May 9, 2005

May 9, 2005

Any ideas? (I'm forwarding the message, so, it defaults to showing below my message. Sorry!) :( Note: forwarded message attached. __________________________________ Yahoo! Mail Mobile Take Yahoo! Mail with you! Check email on your mobile phone. http://mobile.yahoo.com/learn/mail

2 1

Window management - what to do next?
by Vitaliy Margolen May 9, 2005

May 9, 2005

Ok, I've been digging this stuff for more then a week now. And I still don't have even a partial understanding of what's going on in there. If someone please explain me these: 1. Where wine stops and passing over to X/window manager? I'm most interested in handling focus changes, minimize/maximize/restore. 2. What are we doing about properly implementing minimize/maximize/restore. Here is what I uncovered so far about SetWindowPos: 1. Wine does not send WM_WINDOWPOSCHANGING/WM_WINDOWPOSCHANGED. 2. Wine does not redraw owner/owned windows (or not in a proper order) when z-order changes. It looks like these heavily depend on focus changes and owner/owned windows relations. Some times native redraws both owner and owned windows. Sometimes none at all. Same goes for messages. I'm kind of stuck here. To go any further I need to know what part should we delegate to WM and what part do ourselves. -- Best regards, Vitaliy

2 1

Regression in start wars jedi knight: jedi academy
by Stefan Dösinger May 9, 2005

May 9, 2005

Hello, I've yet another problem with the OpenGL patches from April 28: Star Wars Jedi Knight: Jedi Academy crashes during startup. The problematic commit is http://www.winehq.org/hypermail/wine-cvs/2005/04/0308.html, it's not the same problem as with Half-life. The crash happens in ntdll in HEAP_CreateFreeBlock. The call trace shows EDIT_MakeFit on wine/dlls/user/edit.c as the function which calls the heap functions. The crash only occurs if the game's configuration file exists, so the first start succeeds, but the following calls fail. I've attached 3 +opengl,+edit traces: before.out: Game start with config file and without the mentioned wine patch after.out: Game start with config file and with the patch applied(crash) nocfg.out: Game start without config file and with the patch(no crash) Any ideas? The whole thing looks quite strange as the crash is not directly related to OpenGL. Stefan The crash dump is: wine: Unhandled exception (thread 0009), starting debugger... WineDbg starting on pid 0x8 Unhandled exception: page fault on read access to 0x77cfff70 in 32-bit code (0x77ec1139). In 32 bit mode. Register dump: CS:0073 SS:007b DS:007b ES:007b FS:003b GS:0033 EIP:77ec1139 ESP:77a7e588 EBP:77a7e5a8 EFLAGS:00010283( - 00 -RIS1C) EAX:77d00000 EBX:77ef6d8c ECX:77efdb1c EDX:00110000 ESI:77cfff70 EDI:77c3bcb0 Stack dump: 0x77a7e588: 77a7e5c4 77ec198f 77bf0000 77efdb1c 0x77a7e598: 77ec221d 77ef6d8c 00000848 77c3b460 0x77a7e5a8: 77a7e5c4 77ec14a6 77bf0000 77c3bcb0 0x77a7e5b8: 000c42c0 77c3b460 77c3b468 77a7e61c 0x77a7e5c8: 77ec2c3e 77bf0000 77c3b460 00000848 0x77a7e5d8: 00000001 77a7e5ec 77ec2e40 77bf001c Backtrace: =>1 0x77ec1139 HEAP_CreateFreeBlock+0x69(subheap=0x77bf0000, ptr=0x77c3bcb0, size=0xc42c0) [heap.c:447] in ntdll (0x77a7e5a8) 2 0x77ec14a6 HEAP_ShrinkBlock+0x56(subheap=0x77bf0000, pArena=0x77c3b460, size=0x848) [heap.c:543] in ntdll (0x77a7e5c4) 3 0x77ec2c3e RtlReAllocateHeap(heap=0x77bf0000, flags=0xa, ptr=0x77c3a5a8, size=0x848) [heap.c:1348] in ntdll (0x77a7e61c) 4 0x77b33774 HeapReAlloc(heap=0x77bf0000, flags=0x8, ptr=0x77c3a5a8, size=0x848) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:280] in kernel32 (0x77a7e638) 5 0x77b33f76 GlobalReAlloc+0x1b6(hmem=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:617] in kernel32 (0x77a7e668) 6 0x77b3457d LocalReAlloc+0x2d(handle=0x77c3641a, size=0x840, flags=0x42) [/windows/c/sonstiges/wine/dlls/kernel/heap.c:926] in kernel32 (0x77a7e680) 7 0x77148793 EDIT_MakeFit+0x1a3(es=0x77c36368, size=0x41e) [/windows/c/sonstiges/wine/dlls/user/edit.c:1787] in user32 (0x77a7e6b0) 8 0x7714b24f EDIT_EM_ReplaceSel+0x17f(es=0x77c36368, can_undo=0x0, lpsz_replace=0x77c38a58, send_update=0x1, honor_limit=0x1) [/windows/c/sonstiges/wine/dlls/user/edit.c:3045] in user32 (0x77a7e718) 9 0x77145e84 EditWndProc_common+0x634(hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958, unicode=0x0) [/windows/c/sonstiges/wine/dlls/user/edit.c:617] in user32 (0x77a7e794) 10 0x77146c1c EditWndProcA(hWnd=0x1002c, uMsg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/edit.c:1016] in user32 (0x77a7e7b0) 11 0x7719ecef WINPROC_wrapper+0x17 in user32 (0x77a7e7d4) 12 0x7719f056 WINPROC_CallWndProc+0x76(proc=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:419] in user32 (0x77a7e80c) 13 0x771a5fe7 CallWindowProcA(func=0x77146bf0, hwnd=0x1002c, msg=0xc2, wParam=0x0, lParam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/winproc.c:3216] in user32 (0x77a7e840) 14 0x77170c61 call_window_proc+0x171(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, unicode=0x0, same_thread=0x1) [/windows/c/sonstiges/wine/dlls/user/message.c:1521] in user32 (0x77a7e89c) 15 0x77172cbf SendMessageTimeoutA+0x1ff(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958, flags=0x0, timeout=0xffffffff, res_ptr=0x77a7e92c) [/windows/c/sonstiges/wine/dlls/user/message.c:2399] in user32 (0x77a7e908) 16 0x77172db1 SendMessageA+0x51(hwnd=0x1002c, msg=0xc2, wparam=0x0, lparam=0x77a7e958) [/windows/c/sonstiges/wine/dlls/user/message.c:2443] in user32 (0x77a7e934) 17 0x00454613 in jamp (+0x54613) (0x0000001f) 18 0x00000000 (0x00000000) 0x77ec1139 HEAP_CreateFreeBlock+0x69 [heap.c:447] in ntdll: movl 0x0 (%esi),%ecx Unable to open file 'heap.c' Modules: Module Address Debug info Name (70 modules) PE 0x00400000-01327000 Export jamp PE 0x10000000-100f2000 Deferred openal32 ELF 0x712fc000-71376000 Deferred libglu.so.1 ELF 0x71376000-71410000 Deferred opengl32<elf> \-PE 0x713b0000-71410000 \ opengl32 ELF 0x71a5b000-71a70000 Deferred midimap.drv<elf> \-PE 0x71a60000-71a70000 \ midimap.drv ELF 0x71b8c000-71bb0000 Deferred msacm32<elf> \-PE 0x71b90000-71bb0000 \ msacm32 ELF 0x71bb0000-71bc9000 Deferred msacm.drv<elf> \-PE 0x71bc0000-71bc9000 \ msacm.drv ELF 0x71bc9000-71c0e000 Deferred wineoss.drv<elf> \-PE 0x71be0000-71c0e000 \ wineoss.drv ELF 0x71c5b000-71c7a000 Deferred imm32<elf> \-PE 0x71c60000-71c7a000 \ imm32 ELF 0x71c7a000-71c7e000 Deferred iso8859-1.so ELF 0x71c85000-71ca2000 Deferred ximcp.so.2 ELF 0x71ca2000-71ca5000 Deferred xlcdef.so.2 ELF 0x71ca5000-71cae000 Deferred libxcursor.so.1.0.2 ELF 0x71cae000-71cb6000 Deferred libxrender.so.1 ELF 0x761e5000-761ed000 Deferred libgcc_s.so.1 ELF 0x761ed000-76201000 Deferred librt.so.1 ELF 0x762d5000-76b65000 Deferred fglrx_dri.so ELF 0x76b65000-76c09000 Deferred libgl.so.1 ELF 0x76c09000-76cd4000 Deferred libx11.so.6 ELF 0x76dd4000-76df6000 Deferred libexpat.so.0 ELF 0x76df6000-76e20000 Deferred libfontconfig.so.1 ELF 0x76e20000-76e34000 Deferred libz.so.1 ELF 0x76e4e000-76ecf000 Deferred libfreetype.so.6 ELF 0x76ecf000-76ef9000 Deferred ws2_32<elf> \-PE 0x76ee0000-76ef9000 \ ws2_32 ELF 0x76ef9000-76f16000 Deferred wsock32<elf> \-PE 0x76f00000-76f16000 \ wsock32 ELF 0x76f16000-76f36000 Deferred iphlpapi<elf> \-PE 0x76f20000-76f36000 \ iphlpapi ELF 0x76f36000-76f80000 Deferred rpcrt4<elf> \-PE 0x76f50000-76f80000 \ rpcrt4 ELF 0x76f80000-7700e000 Deferred ole32<elf> \-PE 0x76fa0000-7700e000 \ ole32 ELF 0x7700e000-7704e000 Deferred advapi32<elf> \-PE 0x77020000-7704e000 \ advapi32 ELF 0x7704e000-770dd000 Deferred gdi32<elf> \-PE 0x77060000-770dd000 \ gdi32 ELF 0x770dd000-7720f000 Stabs user32<elf> \-PE 0x77100000-7720f000 \ user32 ELF 0x7720f000-77290000 Deferred winmm<elf> \-PE 0x77220000-77290000 \ winmm ELF 0x77ad8000-77bf0000 Stabs kernel32<elf> \-PE 0x77b00000-77bf0000 \ kernel32 ELF 0x77d09000-77d13000 Deferred libnss_files.so.2 ELF 0x77d13000-77d1d000 Deferred libnss_nis.so.2 ELF 0x77d1d000-77d32000 Deferred libnsl.so.1 ELF 0x77d32000-77d3b000 Deferred libnss_compat.so.2 ELF 0x77d55000-77d78000 Deferred libm.so.6 ELF 0x77d78000-77e6d000 Deferred libwine_unicode.so.1 ELF 0x77e87000-77f00000 Stabs ntdll<elf> \-PE 0x77ea0000-77f00000 \ ntdll ELF 0x77f00000-77f03000 Deferred <wine-loader> ELF 0x77f41000-77f4f000 Deferred libxext.so.6 ELF 0x77f4f000-77f54000 Deferred libxxf86vm.so.1 ELF 0x77f54000-77f5a000 Deferred libxxf86dga.so.1 ELF 0x77f5a000-77f72000 Deferred libice.so.6 ELF 0x77f72000-77f7b000 Deferred libsm.so.6 ELF 0x77f7b000-78000000 Deferred x11drv<elf> \-PE 0x77f90000-78000000 \ x11drv ELF 0xb7e47000-b7e4b000 Deferred libdl.so.2 ELF 0xb7e4b000-b7f62000 Deferred libc.so.6 ELF 0xb7f62000-b7fb4000 Deferred libpthread.so.0 ELF 0xb7fb4000-b7fcd000 Deferred libwine.so.1 ELF 0xb7fe8000-b8000000 Deferred ld-linux.so.2 Threads: process tid prio (all id:s are in hex) 00000008 (D) G:\jedi academy\GameData\jamp.exe 00000009 0 <== WineDbg terminated on pid 0x8

3 6