> Wine currently seems to have a problem painting splash dialogs properly
> (or at all).
I took a closer look at this. I just ripped out the interesting parts
from Speak freely in order to find a simple program exhibiting the
problems. What I ended up with was a program which does nothing
interesting except to show a simple dialg using CreateDialog(). It
still doesn't work under Wine. The source is attached.
I'm somewhat at a loss about what to do now. I'm just not clear about
what should happen and why it doesn't. Some browsing around in the
source suggests that it may related to the focus problems Gerard has
been talking about, but I'm far from sure.
Any comments?
Nicke
--
-[ nkarlsso(a)abo.fi ]- Seek simplicity, and distrust it. (A. Whitehead)
Hi all.
I've seen in the recent past a task list for newbie developer for wine.
I would like to know what are still open, how I could contribute.
I've very few skills in Windows development. However, I've good
knowledge of development under linux, and usage of gnu tools (autoconf).
Bye
Marco
--
Marco Bizzarri - Responsabile Tecnico - Icube S.r.l.
Sede: Via Ridolfi 15 - 56124 Pisa (PI), Italia
E-mail: m.bizzarri(a)icube.it WWW: www.icube.it
Tel: (+39) 050 97 02 07 Fax: (+39) 050 31 36 588
At 10:09 AM 09/09/2001 +0300, you wrote:
>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.
I think that the problem with focus is that when a window is shown
by Wine, synthetic WM_GETFOCUS and WM_SETFOCUS events
are generated, that are themselves generating X focus events.
The X events are kept in the X queue until Wine finds time to handle
them.
Wine creates window A : WM_GETFOCUS for A
Wine creates window B : WM_KILLFOCUS for A, WM_GETFOCUS for B
Wine creates window C : WM_KILLFOCUS for B, WM_GETFOCUS for C
Now, when after all this the X events are processed, Wine handles a X
focusin event for A, that is generating a WM_GETFOCUS, then a focusout
for A, generating other WM_KILLFOCUS and WM_ GETFOCUS,
focusin for B, etc..; the sequence of events when creating windows is
perfect, but there are extra events after.
IMO what's wrong is that X focus events are not ignored when they are the
following of program action.
The following hack disables focus handling in this case. I have no
clue on its value since I am currently struggling with other bugs.
and I will not come to these problems until some time - maybe a lot
of time if current Wine progress (aka regressions :-)) continues.
--- event.c.orig Fri Aug 24 09:30:46 2001
+++ event.c Mon Sep 10 13:00:28 2001
@@ -534,6 +534,8 @@
if (!hWnd) return;
+ if (!event->send_event) return;
+
bIsDisabled = GetWindowLongA( hWnd, GWL_STYLE ) & WS_DISABLED;
/* If the window has been disabled and we are in managed mode,
HTH
Gerard
At 03:11 PM 09/09/2001 +0200, you wrote:
>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
>
I have looked at your trace -the app is trying to use a Win32s function.
Maybe the problem is that it succeeds. However, Win32s is present
in Wine since years and has not been touched since a long time.
I think unlikely that it could be a new problem - when was the
last working Wine version before current Cvs ?
You can find in documentation/cvs-regression a few tips on how
to search for the exact date of a regression.
FYI the Wine app database list this game as 'playing perfectly
directly off the CD' :-)
Gerard
At 06:40 PM 30/08/2001 +0200, you wrote:
>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)
What do you mean by typing ?
There is no hwnd type in the spec files, AFAICT. That's
not a matter of typing GetWindow(hwnd word) instead of
GetWindow(word word) - I think it is necessary to
actually change winebuild to define a new type and
write a bunch of code to support it.
I have looked at the points where it current cvs crashes
and it's necessary to fix 16 to 32 bits handles and I have
found that 2 changes cure all my new crashes : the one
in DestroyWindow16 and another in DefWindowProc16
The reason for these problems is the same : Wine is keeping window handles
in several variables (active window, focus window)
and Wine code does several comparisons between
applications provided handles and these values.
In the last case for example, the test
/* activate hwndTop if needed. */
if (hwndTop != GetActiveWindow())
{
in focus.c fails because of the high word part (and
creates an infinite focus loop)
I'd say that by adding also handle fixes in SetWindowPos16,
SetFocus16 and SetActiveWindow16 as well as fixing
the handles setters in queue.c, everything would be
covered.
IMO your solution is
1) somewhat complex for a fix to apps not widely
used anymore
2) overkill because it's not necessary to convert
window handles for each and every Api.
OTOH your solution is more elegant.
I don't know what to do.
Gerard
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)
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
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?
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/>
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.
