[prev in list] [next in list] [prev in thread] [next in thread]
List: wine-devel
Subject: Re: Does wine send window messages without waiting apps to reenter userdll?
From: Javier_Pimás <elpochodelagente () gmail ! com>
Date: 2015-08-31 18:41:02
Message-ID: CAAYkY5ShALPmyPpgxsNvAAPbUjz0-6=d6MgGOqSRFDtLtcQyBQ () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
Ok, that should be 39182 <https://bugs.winehq.org/show_bug.cgi?id=39182>. I
downloaded wine source applied the patch and compiled (first time I ever do
that), but the output of the test didn't change.
On Sun, Aug 30, 2015 at 5:36 AM, Sebastian Lackner <sebastian@fds-team.de>
wrote:
> Thanks for providing the testcase. It indeed looks like a wine bug. Would
> you
> mind to open a bug report on bugs.winehq.org with your testcase and
> explanation?
> Feel free to add me as CC.
>
> The following quick & dirty hack fixes the issue (but will very likely
> break
> other stuff): http://ix.io/kx0
>
> Does it also help for your app?
>
> Regards,
> Sebastian
>
> On 28.08.2015 17:52, Javier Pimás wrote:
> > I wrote a small test which I attach here, very small program where you
> can
> > see if WndProc is called from WaitMessage. It fails, which I think shows
> > what I doubted is actually happening. Tested in the old 1.6.2 wine and
> also
> > in 1.7.50.
> >
> > Cheers!
> >
> > On Wed, Aug 26, 2015 at 11:29 AM, Sebastian Lackner <
> sebastian@fds-team.de>
> > wrote:
> >
> >> On 26.08.2015 16:04, Sebastian Lackner wrote:
> >>> If you are concerned that WaitMessage immediately dispatches the
> >> messages,
> >>> Wine doesn't do that. Processing of window messages is only done in the
> >>> context of GetMessage and PeekMessage, no matter if its a "queued" or
> >>> "non-queued" message. In fact Wine doesn't really make a difference
> >> between
> >>> the two, it just assigns specific internal message numbers for
> non-queued
> >>> messages. To identify those the the highest bit (0x80000000) is set.
> >>
> >> After reading the last part again I noticed that I wasn't really very
> >> precise,
> >> because I somehow already assumed that you are talking about non-queued
> >> messages
> >> caused by SetWindowPos and things like that. Those are implemented using
> >> internal
> >> messages in Wine, and might be affected by the "bugs" mentioned in the
> >> last mail.
> >>
> >> Besides that its of course also possible to send other non-queued
> messages
> >> directly with SendMessage and similar functions. But in this case the
> >> answer would
> >> be the same: WaitMessage does not dispatch them immediately, they are
> >> processed
> >> during a call to PeekMessage or GetMessage.
> >>
> >> Regards,
> >> Sebastian
> >>
> >>
> >
> >
> >
> >
> >
>
>
--
Javier Pimás
Ciudad de Buenos Aires
[Attachment #5 (text/html)]
<div dir="ltr">Ok, that should be <a \
href="https://bugs.winehq.org/show_bug.cgi?id=39182" target="_blank">39182</a>. I \
downloaded wine source applied the patch and compiled (first time I ever do that), \
but the output of the test didn't change.</div><div class="gmail_extra"><br><div \
class="gmail_quote">On Sun, Aug 30, 2015 at 5:36 AM, Sebastian Lackner <span \
dir="ltr"><<a href="mailto:sebastian@fds-team.de" \
target="_blank">sebastian@fds-team.de</a>></span> wrote:<br><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">Thanks for providing the testcase. It indeed looks like a \
wine bug. Would you<br> mind to open a bug report on <a href="http://bugs.winehq.org" \
rel="noreferrer" target="_blank">bugs.winehq.org</a> with your testcase and \
explanation?<br> Feel free to add me as CC.<br>
<br>
The following quick & dirty hack fixes the issue (but will very likely break<br>
other stuff): <a href="http://ix.io/kx0" rel="noreferrer" \
target="_blank">http://ix.io/kx0</a><br> <br>
Does it also help for your app?<br>
<br>
Regards,<br>
Sebastian<br>
<div class="HOEnZb"><div class="h5"><br>
On 28.08.2015 17:52, Javier Pimás wrote:<br>
> I wrote a small test which I attach here, very small program where you can<br>
> see if WndProc is called from WaitMessage. It fails, which I think shows<br>
> what I doubted is actually happening. Tested in the old 1.6.2 wine and also<br>
> in 1.7.50.<br>
><br>
> Cheers!<br>
><br>
> On Wed, Aug 26, 2015 at 11:29 AM, Sebastian Lackner <<a \
href="mailto:sebastian@fds-team.de">sebastian@fds-team.de</a>><br> > wrote:<br>
><br>
>> On 26.08.2015 16:04, Sebastian Lackner wrote:<br>
>>> If you are concerned that WaitMessage immediately dispatches the<br>
>> messages,<br>
>>> Wine doesn't do that. Processing of window messages is only done in \
the<br> >>> context of GetMessage and PeekMessage, no matter if its a \
"queued" or<br> >>> "non-queued" message. In fact Wine \
doesn't really make a difference<br> >> between<br>
>>> the two, it just assigns specific internal message numbers for \
non-queued<br> >>> messages. To identify those the the highest bit \
(0x80000000) is set.<br> >><br>
>> After reading the last part again I noticed that I wasn't really \
very<br> >> precise,<br>
>> because I somehow already assumed that you are talking about non-queued<br>
>> messages<br>
>> caused by SetWindowPos and things like that. Those are implemented using<br>
>> internal<br>
>> messages in Wine, and might be affected by the "bugs" mentioned in \
the<br> >> last mail.<br>
>><br>
>> Besides that its of course also possible to send other non-queued \
messages<br> >> directly with SendMessage and similar functions. But in this \
case the<br> >> answer would<br>
>> be the same: WaitMessage does not dispatch them immediately, they are<br>
>> processed<br>
>> during a call to PeekMessage or GetMessage.<br>
>><br>
>> Regards,<br>
>> Sebastian<br>
>><br>
>><br>
><br>
><br>
><br>
><br>
><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div \
class="gmail_signature"><div dir="ltr">Javier Pimás<br>Ciudad de Buenos \
Aires</div></div> </div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic