wine-devel October 2005

wine-devel@winehq.org

165 participants
333 discussions

testsuite patch - please run on windows
by Marcus Meissner 01 Oct '05

01 Oct '05

Hi, Can one of the Windows testers please try this testsuite patch? The second test fails on WINE, but I have a Bugzilla where the reporter said it should not. (http://bugs.winehq.org/show_bug.cgi?id=1847) Ciao, Marcus Index: dlls/user/tests/win.c =================================================================== RCS file: /home/wine/wine/dlls/user/tests/win.c,v retrieving revision 1.71 diff -u -r1.71 win.c --- dlls/user/tests/win.c 29 Sep 2005 13:36:14 -0000 1.71 +++ dlls/user/tests/win.c 1 Oct 2005 15:18:35 -0000 @@ -2173,6 +2173,8 @@ static void test_capture_3(HWND hwnd1, HWND hwnd2) { + BOOL ret; + ShowWindow(hwnd1, SW_HIDE); ShowWindow(hwnd2, SW_HIDE); @@ -2188,7 +2190,10 @@ ShowWindow(hwnd1, SW_SHOW); check_wnd_state(hwnd1, hwnd1, hwnd1, hwnd2); - ReleaseCapture(); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE.\n"); + ret = ReleaseCapture(); + ok (ret, "releasecapture did not return TRUE after second try.\n"); } static void test_keyboard_input(HWND hwnd)

2 1

Bug Triage: Infinite loop in painting.c / winpos.c (2658)
by Molle Bestefich 01 Oct '05

01 Oct '05

Hello I'd like to take a stab at helping clear out bugzilla. I've chosen this particular entry: http://bugs.winehq.org/show_bug.cgi?id=2658 A trial version can be downloaded here: http://www.download.com/Trillian/3000-2150-10047473.html The installer runs the setup wizard, which will crash and misbehave. Ignore that, and continue onwards with running "wine trillian.exe". In today's CVS, the application behaves as explained in the Bugzilla. The app goes into an infinite loop somewhere around user/painting.c and user/winpos.c. The visual effect is that: 1. The splash screen pops up in the middle of the screen, 2. It moves a notch (3 by 3 pixels) down and to the right, 3. Step 2.) repeats almost ad infinitum. That is, until the window is at the bottom edge of the screen and halfway to the right edge. 4. The application then waits for a very short while before finally starting over from step 1. Google gives us a few hints, so I'll take you on a short tour: http://bugs.winehq.org/show_bug.cgi?id=2658 "With previous versions, at least the splash window worked [...] but 20050111 makes the splash screen go crazy [...]! It shows up in the middle of the screen, but then goes down until the bottom of the screen." http://article.gmane.org/gmane.comp.emulators.wine.user/3048 "I've been running Trillian Pro quite successfully on wine-20030508 since, well, May 8th." http://article.gmane.org/gmane.comp.emulators.wine.user/6 "CodeWeavers Crossover Plugin works 100% with Trillian, no window move issues." http://www.desktoplinux.com/news/NS4813802007.html "Jan. 23, 2003 [...] CodeWeavers, Inc. today announced the release of CrossOver Plugin Version 1.2, [...] the new release also [... has] improved support for [...] Trillian." http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;forum=1 "Has anyone tested the new version 3.0 already with Crossover?" "Yes. It works somewhat okay - there are bugs that need to be ironed out (i.e. new windows don't pop up well, dragging windows causes artsd to lock up on KDE)." Also slightly interesting: http://www.codeweavers.com/site/compatibility/browse/name?app_id=251;issues… So, it seems it works with CrossOver, but not vanilla Wine. Something fishy seems to be going on in Wine's USER32. I've run with +win, which gives an infinitely repeating list consisting of RedrawWindow, BeginPaint, GetWindowRect, SetWindowPos, MoveWindow, WINPOS_GetMinMaxInfo and others. Here's the infinitely looping part of a +win run: win:RedrawWindow 0x10028 whole window flags: RDW_ALLCHILDREN RDW_UPDATENOW win:BeginPaint hdc = 0xbb4 box = (0,0 - 177,368), fErase = 0 win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:GetWindowRect hwnd 0x10028 (741,1244)-(924,1634) win:SetWindowPos hwnd 0x10028, after (nil), 549,317 (183x390), flags 80000015 win:dump_winpos_flags flags: SWP_NOSIZE SWP_NOZORDER SWP_NOACTIVATE 80000000 [ notice the block below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:MoveWindow 0x10028 552,336 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 552,336 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (549,317)-(732,707) win:WINPOS_GetMinMaxInfo 183 390 / 552 336 / 183 390 / 183 390 [ it's repeated now, below.. ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:MoveWindow 0x10028 555,355 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 555,355 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (552,336)-(735,726) win:WINPOS_GetMinMaxInfo 183 390 / 555 355 / 183 390 / 183 390 [ above block repeats 10 more times, only coordinates changing. ] [ then poof happens the below. Almost a repeat, except for the GetMinMaxInfo params: ] win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE RDW_FRAME win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:MoveWindow 0x10028 645,925 183x390 0 win:SetWindowPos hwnd 0x10028, after (nil), 645,925 (183x390), flags 0000001c win:dump_winpos_flags flags: SWP_NOZORDER SWP_NOREDRAW SWP_NOACTIVATE win:GetWindowRect hwnd 0x10028 (642,906)-(825,1296) win:WINPOS_GetMinMaxInfo 1282 1026 / -1 -1 / 1288 1032 / 112 27 win:RedrawWindow 0x10028 whole window flags: RDW_ERASE RDW_ERASENOW RDW_FRAME win:GetWindowRect hwnd 0x10028 (645,925)-(828,1315) win:RedrawWindow 0x10020 region 0x192c box (642,906)-(825,1296) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE win:RedrawWindow 0x10020 region 0x1934 box (639,887)-(822,1277) flags: RDW_INVALIDATE RDW_ALLCHILDREN win:RedrawWindow 0x10028 whole window flags: RDW_INVALIDATE RDW_ERASE [ above repeats 30 times, albeit with new coordinates etc. ] After this, the trace "wraps around" and repeats itself from the beginning. Coordinates change slightly though, it's a few pixels off from the first run. Please help me understand why the above infinite loop occurs! I also did a +relay trace and ran it through examine-relay. The resulting call stack is awe inspiring - it's as deep as the Mariana Trench. See the attached snippet. Does it not seem "wrong"? I also did a +all trace, which instantly got very big and confusing. I tried grepping to get rid of parts of it, which went OK, but then examine-relay wouldn't indent half of the lines in it, and in the end it complained about a bunch of leftover calls. So I patched Wine (attached) to output only toplevel calls, which gave me this listing: Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGING,wp=00000000,lp=4069e7b0) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_NCPAINT,wp=00000001,lp=00000000) retval=00000000 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) Ret window proc 0x3400c710 (hwnd=0x10028,msg=WM_ERASEBKGND,wp=00000bb4,lp=00000000) retval=00000001 Call window proc 0x3400c710 (hwnd=0x10028,msg=WM_WINDOWPOSCHANGED,wp=00000000,lp=4069e7b0) [ window moves a lot now ] Etc. ad infinitum. The above should be the stuff that Trillian actually calls in Wine, but my patch might be wrong. Seems odd that the WM_blah calls do not show up in +relay mode. Please help me understand: Why is that? Thank You for Paying Attention. And Please Help Me Fix This Bug! :-)

1 0

WSACleanup() again?
by JustFillBug 01 Oct '05

01 Oct '05

I saw the bug described in: http://winehq.com/hypermail/wine-users/2001/01/0516.html happened again to a program I was trying to use. At least the behavior is the same. I have no access to the source code. It seems the problem was fixed in revision 1.42 of socket.c. But now at 1.139, WSACleanup again return 0 forever on repeating calls.

2 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel October 2005