wine-devel

wine-devel@winehq.org

3 participants
84399 discussions

Dialog painting
by Niclas Karlsson MATE 10 Sep '01

10 Sep '01

Hello! Wine currently seems to have a problem painting splash dialogs properly (or at all). Is this a known problem (with a known cause)? An open source program exhibiting problems of this kind would be Speak Freely (http://www.fourmilab.ch/speakfree/windows/). I will try to single out the cause of the problem when I get a little spare time, unless the cause is already known that is. Also, I haven't used Wine for some time so I don't know if this is a long-standing problem. The version I used was a cvs snapshot from last friday before the commits. Cheers, Nicke -- -[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)

1 0

Monkey Island 3
by Johan Gill 09 Sep '01

09 Sep '01

The installation of Curse of Monkey Island seems to be broken in latest CVS. All I get is a dialog saying that setup requires a different version of Windows. A trace is available on the web at http://www.lysator.liu.se/~johane/monkey3.txt /Johan Gill, johane(a)lysator.liu.se

1 0

what if MS is forced to publish all API's?
by Scott Bradford 09 Sep '01

09 Sep '01

with all the discussion going on in the press about what to do with Microsoft to remove their Monopoly power or at least see to it that they don't abuse their power, how to folks here feel about forcing them to release all their API's? I'm not a programmer myself, but it's my understanding that not having access to the API's is what makes wine such a challenge. If this is the case, would getting access to the MS API's allow Wine to be completed? I feel that a MS breakup wouldn't have done much to change things because they can still give information only to whom they choose, leaving MS to decide who can play and who can't. Having other ways to run the application base of windows software would remove the need to run windows itself, and in my mind, this is the easiest way to remove monopoly power of MS. What do you folks, the Wine developers, think should be done to MS?

1 0

Focus livelock
by Jukka Heinonen 09 Sep '01

09 Sep '01

I posted a patch that would fix a focus related livelock. However, I have to admit that the patch is quite hacky and likely not to be included in Wine. Since I would like to get this bug fixed, I thought to ask opinions about the correct way to fix the bug. The short description of the bug is that setting active/foreground/focus window in Wine calls X11DRV_SetFocus, which calls XSetInputFocus. This makes Wine receive FocusIn event, the handler of which calls SetForegroundWindow. Even though SetForegroundWindow does nothing if its parameter matches current foreground window, it can be easily seen that having more than one window can lead into livelock. This happens repeatably every time you start Colonization for Windows. I'm currently thinking about calling directly some WINPOS_* routine from X11 FocusIn handler instead of SetForegroundWindow. If the routine acted exactly like SetForegroundWindow except it made sure that it causes no calls to X11DRV_SetFocus, focus problem would be fixed. Unfortunately I have not figured any good way to pass an extra flag to default handler for WM_ACTIVATE, so that the routine would call something like SetFocus_DontCallDriver instead of regular SetFocus... -- Jukka Heinonen <http://www.iki.fi/jhei/>

1 0

Re: Option to disable XVidMode
by Ove Kaaven 08 Sep '01

08 Sep '01

On Fri, 7 Sep 2001, François Gouget wrote: > > I had a report of a crash and it turned out to happen during the > XVidMode initialization. > What happened is that for some unknown reason XF86VidModeGetAllModeLines > returned a single mode with a width and/or height of zero > (htotal/vtotal). This caused a division by zero in convert_modeline. Last time this happened, we considered this a bug in the X server, as under these circumstances, xvidtune also crashes. > Then will come the work of trying to reproduce the problem and see > how best to deal with this server (XFree86-SVGA 4.1.0 apparently). I don't think such a server exists. There's either XFree86 4.x with loadable driver modules, or there's XFree86-SVGA 3.x. The latter sounds more likely to have this kind of bug.

2 2

Re: ukrainian layout
by Dmitry Timoshkov 08 Sep '01

08 Sep '01

"Andy Rysin" <arysin(a)yahoo.com> wrote: > Also I had to modify unicode/cp20866.c (KOI8-R) to allow conversion > of additional 4 pair of letters in Ukrainian language (KOI8-U, > RFC2319) as well as one additional pair of letters for Belorussian > language (AKA KOI8-RU, which does not have RFC though). > Strictly speaking KOI8-R is a subset (if not to take to account > pseudographics) of KOI8-U wich is a subset of KOI8-RU. > That's why I applied it to cp20866.c instead of creating smth new. > (I took it from my patches for linux kernel nls system) You can't modify cp*.c files, they are auto generated from the unicode.org file set. You need to send your patch to the unicode.org maintainers and hopefully it will be included in the next Unicode Standard release. > Another problem is that I could not test it practiacally because for > some reason Win32 programs under wine does not input cyrillic > letters, but if I swicth to X program and then back it stops input at > all if layout is cyrillic. If I swicth back to latin everything's ok. It's a known problem, that Wine's x11 keyboard driver does not work with "non-sticky" switches. I have tested cyrillic input with XFree86 3.3.6, 4.0.3 and 4.1.0 with KDE and KiKbd, all works fine for me. Proper support for non-sticky modifiers, dead-keys and the real keyboard layout support requires almost complete keyboard driver rewrite. > BTW, why not to take layouts from X system itself? > Those wich are under /etc/X11/xkb/symbols Because XFree86 is not the only X11 implementation out there. -- Dmitry.

2 2

Re: Make cmdline writable (cmdline4)
by Alexandre Julliard 08 Sep '01

08 Sep '01

Francois Gouget <fgouget(a)free.fr> writes: > In the case below. Works on Win98 but not in Wine. I believe the > reason is that Windows does not need to modify the command line anyway. In some cases it does; for instance your test program should fail under NT when using Unicode. Do you have a real app that requires this? -- Alexandre Julliard julliard(a)winehq.com

3 2

WM_[LR]BUTTON{DOWN,DBLCLK} in menus
by Bobby Bingham 08 Sep '01

08 Sep '01

I was writing a stupid app to help my friend learn to use menus in windows apps. It would call TrackPopupMenu on a WM_LBUTTONDOWN message. After some experimentation, I found that if I leftclicked in the client are, the menu would appear, as it should. But if, while the menu was still active, I leftclicked in the window's nonclient area (titlebar), the menu would appear elsewhere. By clicking the menu receives a WM_LBUTTONDOWN message, and determines that it should close the menu as it's not inside the menu, and it doesn't remove the message. This is normally fine, but if the click falls on the nonclient area of a window, the message should not be passed through. I believe this also applies to WM_LBUTTONDBLCLK, and the right button equivalents. Is there an easy way to determine what window the click would be passed through to, so we can check if it'll be in the client area or not? Bobby Bingham -- Microsoft Windows: Made for the internet The Internet: Made for UNIX

1 0

Re: Problems with WM_PAINT and threads
by Alexandre Julliard 07 Sep '01

07 Sep '01

Ove Kaaven <ovehk(a)ping.uio.no> writes: > After Wine dispatches this WM_PAINT message from the wrong thread, > 3DMark2000 fails to locate its thread-local data, gets confused, and > crashes. Does this help? Index: windows/win.c =================================================================== RCS file: /opt/cvs-commit/wine/windows/win.c,v retrieving revision 1.147 diff -u -r1.147 win.c --- windows/win.c 2001/08/29 00:16:00 1.147 +++ windows/win.c 2001/09/07 19:34:24 @@ -387,15 +387,17 @@ hwndRet = pWnd->hwndSelf; /* look among siblings if we got a transparent window */ - while (pWnd && ((pWnd->dwExStyle & WS_EX_TRANSPARENT) || - !(pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)))) + while (pWnd) { + if (!(pWnd->dwExStyle & WS_EX_TRANSPARENT) && + (pWnd->hrgnUpdate || (pWnd->flags & WIN_INTERNAL_PAINT)) && + GetWindowThreadProcessId( pWnd->hwndSelf, NULL ) == GetCurrentThreadId()) + { + hwndRet = pWnd->hwndSelf; + WIN_ReleaseWndPtr(pWnd); + break; + } WIN_UpdateWndPtr(&pWnd,pWnd->next); - } - if (pWnd) - { - hwndRet = pWnd->hwndSelf; - WIN_ReleaseWndPtr(pWnd); } TRACE("found %04x\n",hwndRet); return hwndRet; -- Alexandre Julliard julliard(a)winehq.com

2 1

Re: Bugs involving returning strings from API functions
by Alexandre Julliard 07 Sep '01

07 Sep '01

"Justin Santa Barbara" <justinsb(a)hotmail.com> writes: > As I see it, the advantage of a helper function is that for about the same > amount of work of fixing GetSystemDirectory and GetCurrentDirectory, all the > functions should work the same way meaning any bugs would quickly be found. > It might also be possible to optimize the case where buflen=0, while this > isn't practical per-function. Should I offer a patch only for wine/files/* > ? I'm afraid there are too many variations to make this useful. It would be nice if all APIs that return strings behaved the same way, but unfortunately this is not the case: some count the terminating null, some don't, some copy partial strings when the buffer is too small, some don't copy anything, etc. We would need about as many helpers as there are API functions. Also be aware that the MSDN doc cannot be trusted at all on this matter, the correct behavior needs to be verified for each function. -- Alexandre Julliard julliard(a)winehq.com

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