- Wine-devel - list.winehq.org

Problems with WM_PAINT and threads
by Ove Kaaven 30 Aug '01

30 Aug '01

After trying to merge Wine 20010824 into WineX, I've encountered a threading issue. A window is created in an app thread: 0806d1f0:Call user32.CreateWindowExA(00000000, 403cb0d4 "Afx:400000:3",0055b674 "3DMark - Display Window", 80000000,00000000,00000000,00000280,000001e0,00000000, 00000000,00400000,00000000) ret=5f40c486 trace:win:WIN_CreateWindowEx "3DMark - Display Window" "Afx:400000:3" 00000000 80000000 0,0 640x480 0000 0000 00400000 (nil) trace:win:WIN_CreateWindowEx winproc type is 2 (WIN_PROC_32A) ... This works fine, until our ddraw update thread somehow decides to send it a message after syncing its own window 31bc: 08107170:Ret x11drv.CreateWindow() retval=00000001 ret=407f542f trace:win:WIN_CreateWindowEx created window 31bc 08107170:Call x11drv.SetWindowPos(44a12e88) ret=407fb159 trace:x11drv:X11DRV_SetWindowPos hwnd 31bc, swp (0,0)-(0,0) flags 0000255b trace:x11drv:X11DRV_SetWindowPos current (0,0)-(800,600), style 84000000 warn:x11drv:SWP_DoOwnedPopups (31bc) hInsertAfter = 0000 trace:x11drv:X11DRV_sync_whole_window_position setting win 3200001 pos 0,0,800x600 after 8081268 changes=40 trace:x11drv:X11DRV_SetWindowPos mapping win 31bc trace:x11drv:X11DRV_SetWindowPos status flags = 1843 08107170:Ret x11drv.SetWindowPos() retval=00000001 ret=407fb159 trace:win:RedrawWindow 31bc (0000) NULL 0,0-0,0 0000 flags=0180 trace:win:RDW_UpdateRgns hwnd 31bc [0000] -> hrgn [0000], flags [0180] trace:win:RDW_Paint hwnd 31bc [0000] -> hrgn [0000], flags [0180] 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000002,44a12da4,ffffffff,000000ff,00000000) ret=407e4237 trace:x11drv:X11DRV_Expose win 31bc (3200002) 0,0 800x600 trace:win:RedrawWindow 31bc (0000) rect 0,0-800,600 0000 flags=0005 trace:win:RDW_UpdateRgns hwnd 31bc [174a] -> hrgn [0000], flags [0005] trace:win:RDW_Paint hwnd 31bc [174a] -> hrgn [0000], flags [0005] 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000002 ret=407e4237 08107170:Call x11drv.MsgWaitForMultipleObjectsEx(00000000,00000000,00000000,00000000,00000000) ret=407a1ca4 08107170:Ret x11drv.MsgWaitForMultipleObjectsEx() retval=00000102 ret=407a1ca4 trace:msg:MSG_peek_message got type 5 msg f hwnd 0 wp 0 lp 0 trace:win:WIN_FindWinToRepaint found 3124 trace:win:RedrawWindow 3124 (1746) NULL 0,0-0,0 0000 flags=0050 trace:win:RDW_UpdateRgns hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:win:RDW_Paint hwnd 3124 [1746] -> hrgn [0000], flags [0050] trace:message:SPY_EnterMessage (00003124) "3DMark - D..." message [000f] WM_PAINT dispatched wp=00000000 lp=00000000 08107170:Call window proc 0x5f4019fa (hwnd=00003124,msg=WM_PAINT,wp=00000000,lp=00000000) ^^^^^^^^ ^^^^^^^^ After Wine dispatches this WM_PAINT message from the wrong thread, 3DMark2000 fails to locate its thread-local data, gets confused, and crashes. Maybe Alexandre did a mistake somewhere in his restructures?

1 0

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??
by Uwe Bonnes 30 Aug '01

30 Aug '01

>>>>> "Johann" == Johann Messner <johann.messner(a)zid.uni-linz.ac.at> writes: Johann> Hi there, First: thanks & compliments for your impressive Johann> project!!! Johann> please check wine/dlls/ntdll/string.c:_ultoa() ... I think there Johann> is a bug in it ... There are for sure more bug... Johann> hans Johann> ==> this is the path to it in the web cvs: ... Johann> ==> this is the source snippet with the patch as suggested ... Did you test? As no win function is uses, you can easily write a test programm wrapper, like static char *_ultoa(... void main() { char buffer[32]; printf(" x %d, radix %d, result %s\n",1000,10,_ultoa(1000,buffer,10)); printf("... } The loop decrements p after use, so p needs to be corrected and I would think that the original version is right. Bye -- Uwe Bonnes bon(a)elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

1 0

Mouse Events
by Brad Campbell 30 Aug '01

30 Aug '01

G'day all, Maiden post. Please be gentle.. I had a problem using wine with a touchscreen under XFree 4.0.2. With the help of Gerard Patel and Ove Kaaven I have come up with a patch that solves my problem, and does not appear to disrupt any of the other machines and programs I use. I have looked at several ways of achieving this, and this seems to be the least messy. This has been tested with both the touchscreen and also ps/2 mouse and works well with both. I'm not a C programmer at all, and have little experience with the WINE code. All comments both positive and negative appreciated.. Thanks.. To be applied to windows/input.c --- input.c Wed Aug 29 21:00:42 2001 +++ input.c.new Wed Aug 29 20:59:01 2001 @@ -195,43 +195,43 @@ if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTDOWN : MOUSEEVENTF_RIGHTDOWN)) { MouseButtonsStates[0] = AsyncMouseButtonsStates[0] = TRUE; - queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_LEFTUP : MOUSEEVENTF_RIGHTUP)) { MouseButtonsStates[0] = FALSE; - queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_LBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTDOWN : MOUSEEVENTF_LEFTDOWN)) { MouseButtonsStates[2] = AsyncMouseButtonsStates[2] = TRUE; - queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & (!SwappedButtons? MOUSEEVENTF_RIGHTUP : MOUSEEVENTF_LEFTUP)) { MouseButtonsStates[2] = FALSE; - queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_RBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEDOWN) { MouseButtonsStates[1] = AsyncMouseButtonsStates[1] = TRUE; - queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONDOWN, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_MIDDLEUP) { MouseButtonsStates[1] = FALSE; - queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, PosX, PosY, + queue_raw_hardware_message( WM_MBUTTONUP, keystate, 0, mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } if (mi->dwFlags & MOUSEEVENTF_WHEEL) { queue_raw_hardware_message( WM_MOUSEWHEEL, MAKELONG( keystate, mi->mouseData), 0, - PosX, PosY, mi->time, mi->dwExtraInfo ); + mi->dx, mi->dy, mi->time, mi->dwExtraInfo ); } } -- Brad Campbell /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

1 1

Comment from IBM developer re FS register corruption
by Jeremy White 30 Aug '01

30 Aug '01

At LinuxWorld today, a couple of developers from IBM stopped by and mentioned a patch that they recently sent to Linus (which he accepted with dismay at such a long standing bug, and apparently committed to the 2.4.8 tree). Sadly, I have forgotten the woman's name, but she indicated that there was a race condition that could sometimes cause the fs register to become corrupt, and that this problem had existing in all versions of Linux, as far as they could tell. She indicated that the patch had a fairly innocuous description, but it might be worth understanding this problem better (although from her description, it didn't sound like a good workaround was available). Cheers, Jeremy p.s. Wine was a finalist for best open source project, but lost out to KDE. Next time, the crystal plaque is ours. I can feel it.

1 0

Powerdvd running under linux
by Robert Lowery 30 Aug '01

30 Aug '01

Hi I have a graphics card with an SIS6326 chipset. Under Windows 98 (using PowerDVD), I get fantastic performance on my Pention 233MMX as it supports YUV->RGB, Motion Compensation and iDCT in hardware. This chipset is not currently supported under Linux. What do you think the chances are of PowerDVD working with hardware acceleration under WINE/WINEX? What sort of performance should I expect? Please cc replies to my email, as I am not subscribed Thank-you for your help -Robert

3 2

./configure file in cvs
by Gioele Barabucci 30 Aug '01

30 Aug '01

Hello everyone, why is there a ./configure file in your cvs? configure was meant to be created for endusers, not for developers. Many projects based on auto* tools create a ./autogen.sh or ./bootstrap script. The fact is that the configure supplied (and all the auto* files) creates lot of confusion and some errors sometime. simple as: #!/bin/sh # rm -f configure ltmain.sh config.guess config.sub echo "Running libtoolize..." libtoolize --force --copy >/dev/null echo "Running aclocal..." aclocal $ACLOCAL_FLAGS echo "Running autoheader..." $use_autoheader echo "Running autoconf..." $use_autoconf echo "Running automake..." automake --add-missing --copy --foreign -- Gioele Barabucci (Gb]) <gioeleb(a)tiscalinet.it>

3 2

Re:Call for Volunteers (Re: Newbie work?)
by Eric Pouech 29 Aug '01

29 Aug '01

> Also I'm thinking about starting an additional section for > 'hard(er)' projects that would significantly improve Wine. > Maybe it > could also list projects that are already underway and for which help > would be appreciated (DCOM?, STRICT handles?). I think that when folks start working on a rather large chunk they should talk about it a bit more (that they started, post some ideas on how it should be done, call for contributions...). All developpers are rather terse on this matter. > Easy: > Medium (I expect these would take longer or be a bit harder) > * Provide a pedump utility > #91: http://wine.codeweavers.com/bugzilla/show_bug.cgi?id=91 > I know there's sample code that does that already floating around so > it should be relatively simple. > Eric Pouech seems to be working on this. I did not check if his > pedump dump the imports/exports but it probably does. yes, but it's missing delayed imports and resource. disass could be provided to. A+ --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) The future will be better tomorrow, Vice President Dan Quayle __________________________________________________________ Faites un vu et puis Voila ! www.voila.fr Pendant tout l'été, gagnez une Ford Ka sur Voila Gratter ! http://cybergrattage.voila.fr/voila

2 1

Re: Newbie work?
by Gerard Patel 29 Aug '01

29 Aug '01

At 03:25 PM 28/08/2001 -0700, you wrote: >I noticed that there was a file on >ftp://ibiblio.org/pub/Linux/ALPHA/wine/ about projects for newbie wine >developers. I also noticed that it was written in 1994. So I was wondering >if there was a more up to date version or if anyone had some ideas of >usefull work that a developer new to wine could do? www.winehq.com/projects The one I would like to be done is 'loadable fonts'. It's difficult but it would make many people happy with Wine from some posts I see on cemw. Gerard

1 0

Re: Crash in latest version
by Gerard Patel 29 Aug '01

29 Aug '01

At 04:03 PM 28/08/2001 -0700, you wrote: >Gerard Patel <gerard.patel(a)nerim.net> writes: > >> What this means is that any use of 16 bit code with >> window handles in Wine will break as the handles >> will be truncated. I already see many new crashes... > >Actually truncated handles should work just fine, the generation >number is simply ignored if it is zero. There may theoretically be >problems when we pass a truncated handle to a 32-bit app that compares >it to a full 32-bit handle stored previously, but this should be >fairly rare behavior. So your crashes are probably caused by something >else. > .Backtrace for the next crash : Unhandled exception: page fault on read access to 0x00000000 in 32-bit code (0x00462b9b). In 32-bit mode. 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe): movl 0x0(%eax),%eax >0 0x00462b9b (eudora.exe.EntryPoint+0xb2ee in H:\eudora\eudora\eudora.exe) (ebp=406159c0) 1 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=40615a04) 2 0x40724e33 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:171] in libuser32.so) (ebp=40615a30) 3 0x4072a919 (WINPROC_CallProc32WTo32A+0x89(func=0x462daa, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2442] in libuser32.so) (ebp=40615a58) 4 0x4072af32 (CallWindowProcW+0xb2(func=0x40dc1069, hwnd=0x3b, msg=0x87, wParam=0x0, lParam=0x0) [winproc.c:2683] in libuser32.so) (ebp=40615a8c) 5 0x406c37fe (call_window_proc+0x9e(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, unicode=0x1) [message.c:1108] in libuser32.so) (ebp=40615ae4) 6 0x406c434b (SendMessageTimeoutW+0xcb(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0, flags=0x0, timeout=0xffffffff, res_ptr=0x40615b68) [message.c:1498] in libuser32.so) (ebp=40615b44) 7 0x406c45c7 (SendMessageW+0x37(hwnd=0x3b, msg=0x87, wparam=0x0, lparam=0x0) [message.c:1576] in libuser32.so) (ebp=40615b78) 8 0x406fb4ec (DEFDLG_SetFocus+0x5c(hwndDlg=0x1003a, hwndCtrl=0x3b) [defdlg.c:32] in libuser32.so) (ebp=40615b9c) 9 0x406fb5d7 (DEFDLG_RestoreFocus+0x67(hwnd=0x1003a) [defdlg.c:74] in libuser32.so) (ebp=40615b This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. I have a third new one for you, but I have not the time to search for the reason this night (there is no hint of 16 bit handles here) 0x4071ff50 (GetParent+0x30 [win.c:2143] in libuser32.so): movl 0x20(%eax),%esi 2143 retvalue = wndPtr->parent->hwndSelf; Wine-dbg>bt bt Backtrace: =>0 0x4071ff50 (GetParent+0x30(hwnd=0x20021) [win.c:2143] in libuser32.so) (ebp=40615e7c) 1 0x4070a17f (DefMDIChildProcA+0x1f(hwnd=0x20021, message=0x82, wParam=0x0, lParam=0x0) [mdi.c:1617] in libuser32.so) (ebp=40615e98) 2 0x00474107 (eudora.exe.EntryPoint+0x1c85a in H:\eudora\eudora\eudora.exe) (ebp=40615f54) 3 0x00462ba3 (eudora.exe.EntryPoint+0xb2f6 in H:\eudora\eudora\eudora.exe) (ebp=40615fc8) 4 0x00462dd7 (eudora.exe.EntryPoint+0xb52a in H:\eudora\eudora\eudora.exe) (ebp=4061600c) 5 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [w inproc.c:171] in libuser32.so) (ebp=40616038) 6 0x4072ae72 (CallWindowProcA+0xb2(func=0x462daa, hwnd=0x20021, msg=0x82, wParam=0x0, lParam=0x0) [winpr oc.c:2647] in libuser32.so) (ebp=4061606c) 7 0x406c3823 (call_window_proc+0xc3(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, unicode=0x0) [messag e.c:1112] in libuser32.so) (ebp=406160c4) 8 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0, flags=0x0, timeou t=0xffffffff, res_ptr=0x40616148) [message.c:1544] in libuser32.so) (ebp=40616124) 9 0x406c4617 (SendMessageA+0x37(hwnd=0x20021, msg=0x82, wparam=0x0, lparam=0x0) [message.c:1587] in libu ser32.so) (ebp=40616158) 10 0x4071d6a4 (WIN_DestroyWindow+0x94(wndPtr=0x40403d54) [win.c:420] in libuser32.so) (ebp=40616180) 11 0x4071ebb2 (DestroyWindow+0x282(hwnd=0x20021) [win.c:1243] in libuser32.so) (ebp=406161a0) 12 0x40708506 (MDIDestroyChild+0xd6(parent=0x1002b, ci=0x403f4528, child=0x20021, flagDestroy=0x1) [mdi. c:712] in libuser32.so) (ebp=406161c4) 13 0x407096d2 (MDIClientWndProc_common+0x3d2(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0, un icode=0x0) [mdi.c:1295] in libuser32.so) (ebp=40616218) 14 0x407099f6 (MDIClientWndProcA+0x36(hwnd=0x1002b, message=0x221, wParam=0x20021, lParam=0x0) [mdi.c:14 06] in libuser32.so) (ebp=4061623c) 15 0x40724e03 (WINPROC_wrapper+0x17 in libuser32.so) (ebp=40616260) 16 0x40724e83 (WINPROC_CallWndProc+0x73(proc=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam =0x0) [winproc.c:171] in libuser32.so) (ebp=4061628c) 17 0x4072ae72 (CallWindowProcA+0xb2(func=0x407099c0, hwnd=0x1002b, msg=0x221, wParam=0x20021, lParam=0x0 ) [winproc.c:2647] in libuser32.so) (ebp=406162c0) 18 0x406c3823 (call_window_proc+0xc3(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, unicode=0x0) [ message.c:1112] in libuser32.so) (ebp=40616318) 19 0x406c4496 (SendMessageTimeoutA+0xd6(hwnd=0x1002b, msg=0x221, wparam=0x20021, lparam=0x0, flags=0x0, All I can say for now is that wndPtr->parent is NULL. And I have yet another 20 apps to try :-) Gerard

1 0

Re: Crash in latest version
by Alexandre Julliard 29 Aug '01

29 Aug '01

Gerard Patel <gerard.patel(a)nerim.net> writes: > This crash goes away by changing the HWND16 in DIALOG_INFO to HWND. Seems to be less rare than I hoped then ;-) I've added a fix. > All I can say for now is that wndPtr->parent is NULL. This one should be fixed too. -- Alexandre Julliard julliard(a)winehq.com

1 0