August 2001 - Wine-Devel - list.winehq.org

Re: wine-devel digest, Vol 1 #445 - 9 msgs

by Francois Gouget

On Thu, 30 Aug 2001, Robert Lunnon wrote: > Attempt 2 :-) > > > I am trying to get winsock to work under Solaris and need a little help. > > When connecting, the call to connect doesn't generate a syn packet as expected, The problem > appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, > as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which > makes the subsequent call to connect succeed without establishing a connection because a UDP > endpoint was created instead of a tcp one. > > Now to find out where SOCK_STREAM is getting defined as 1 :-/ I believe that the problem is that SOCK_STREAM==1 SOCK_DGRAM==2 on windows and linux. So WSOCK32_socket assumed that the type parameter does not need any conversion, which seems to be wrong on Solaris. Try the attached patch. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Demander si un ordinateur peut penser revient à demander si un sous-marin peut nager.

Aug. 30, 2001

Re: [PATCH] DestroyWindow16

by eric pouech

Gerard Patel wrote: > > As DestroyWindow does a lot of handle comparaisons, it is necessary > to give it a real 32 bit handle. This avoids a systematic crash when > ForteFreeAgent 16 bit exits. I have not looked for other places where > this can be necessary - but it would not be surprising that this happens. perhaps as an extension of the relay code ? (it would mean typing correctly windows handles in spec files though) A+ -- --------------- Eric Pouech (http://perso.wanadoo.fr/eric.pouech/) "The future will be better tomorrow", Vice President Dan Quayle

Aug. 30, 2001

Problems with WM_PAINT and threads

by Ove Kaaven

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?

Aug. 30, 2001

Re: wine-devel digest, Vol 1 #445 - 9 msgs

by Robert Lunnon

Attempt 2 :-) I am trying to get winsock to work under Solaris and need a little help. When connecting, the call to connect doesn't generate a syn packet as expected, The problem appears to be WSOCK32_socket, where the type of socket is passed as type 1 for a tcp service, as it turns out the Solaris header file defines SOCK_STREAM as 2 and SOCK_DGRAM as 1 which makes the subsequent call to connect succeed without establishing a connection because a UDP endpoint was created instead of a tcp one. Now to find out where SOCK_STREAM is getting defined as 1 :-/ I probably need to check the standard function calls between a solaris binary and a windows one so does someone have a simple test program and a unix source (IE windows binary with unix compatible source code) that I can use to compare behaviours between the two environments ? Thanks Bob

Aug. 30, 2001

Re: BUG with wine/dlls/ntdll/string.c:_ultoa() ???!!??

by Uwe Bonnes

>>>>> "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 ----------

Aug. 30, 2001

Re: Mouse Events

by Brad Campbell

Brad Campbell wrote: > > 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.. This is probably a more correct patch as it only changes the Pos variables when it's a buttonpress and the absolute flag is set. Because the message in event.c that sends this refers to the getcoords function for it's position data, then the position data is guaranteed to be absolute thus I added the absolute flag to the message sent, this should not affect anything else.. You will have to excuse the logic in input.c as I'm working from a beginners guide to C. I'm a PASCAL programmer by nature.. Thanks for any input.. --- windows/input.c.orig Wed Aug 29 22:44:47 2001 +++ windows/input.c Thu Aug 30 15:13:08 2001 @@ -187,6 +187,12 @@ } } + if (!(mi->dwFlags & MOUSEEVENTF_MOVE) && (mi->dwFlags & MOUSEEVENTF_ABSOLUTE)) + { + PosX = mi->dx; + PosY = mi->dy; + } + if (mi->dwFlags & MOUSEEVENTF_MOVE) { queue_raw_hardware_message( WM_MOUSEMOVE, keystate, 0, PosX, PosY, --- windows/x11drv/event.c.orig Thu Aug 30 15:14:28 2001 +++ windows/x11drv/event.c Thu Aug 30 14:52:15 2001 @@ -477,7 +477,7 @@ break; } - X11DRV_SendEvent( statusCodes[buttonNum], pt.x, pt.y, + X11DRV_SendEvent( statusCodes[buttonNum] | MOUSEEVENTF_ABSOLUTE, pt.x, pt.y, keystate, wData, event->time - X11DRV_server_startticks, hWnd); } -- Brad.... /"\ Save the Forests \ / ASCII RIBBON CAMPAIGN Burn a Greenie. X AGAINST HTML MAIL / \

Aug. 30, 2001

Comment from IBM developer re FS register corruption

by Jeremy White

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.

Aug. 30, 2001

Re: Powerdvd running under linux

by Bobby Bingham

I'd say zilch. If the chipset isn't supported by linux, there's no way wine/wineX can use any advanced features of it because wine uses what linux/X have to offer, which isn't support for this chipset. I don't know what kind of performance it would get without hardware acceleration. Bobby Bingham On Wednesday 29 August 2001 09:37 pm, you wrote: > 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

Aug. 30, 2001

Re: Powerdvd running under linux

by Francois Gouget

On Thu, 30 Aug 2001, Robert Lowery wrote: > 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? Before the chipset is supported by Linux? Zero. Once XFree86 provides XVideo support for your chipset (or even better, the newer brand of XVideo, the one that also include motion compensation, I don't remember the name), then you may get hardware acceleration in Wine. But I think that currently DDraw does not support hardware acceleration for these things. So it will probably require some work on Wine too. -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ May your Tongue stick to the Roof of your Mouth with the Force of a Thousand Caramels.

Aug. 30, 2001

Powerdvd running under linux

by Robert Lowery

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

Aug. 30, 2001