wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

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 29 Aug '01

29 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

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

29 Aug '01

At 10:34 PM 28/08/2001 +0200, you wrote: >Notice the change in the hwnd Windows handles are now generated on the server. This is a historical moment, btw :-) Now Wine has all the architectural features of Win 95 Not everything is implemented, FindWindow does not yet work across processes for example. But it's an important step nonetheless. Alexandre Julliard has implemented the 'generation' feature of handles. The higher part of a 32 bit handle is used for a counter that is incremented from a window creation to another, avoiding the age-old problem of windows being deleted, then braindead application trying to use their handles, using newly created windows instead. 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... The dialog code uses a 16 bit only Api (FillWindow) The following (and simplistic) patch should make your app crash a bit later. Gerard --- defdlg.c.orig Tue Aug 21 15:09:31 2001 +++ defdlg.c Wed Aug 29 00:07:28 2001 @@ -135,10 +135,18 @@ static LRESULT DEFDLG_Proc( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, DIALOGINFO *dlgInfo ) { + HBRUSH hbrush; switch(msg) { case WM_ERASEBKGND: - FillWindow16( hwnd, hwnd, (HDC16)wParam, (HBRUSH16)CTLCOLOR_DLG ); + hbrush = SendMessageA( hwnd, WM_CTLCOLORDLG, + wParam, (LPARAM)hwnd ); + if (hbrush ) + { + RECT r; + GetClientRect(hwnd, &r); + FillRect( (HDC) wParam, &r, hbrush ); + } return 1; case WM_NCDESTROY:

1 0

Jump to page:

2025

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