April 2015 - Wine-Devel - list.winehq.org

Re: [PATCH 1/6] dmloader: Use the generic DirectMusicObject implementation for DMContainer.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13064 Your paranoid android. === build (build) === Make failed

April 27, 2015

jscript: Date.parse: long date with '/' or '-'

by Thomas Faller

Am 25.04.2015 um 18:43 schrieb Stefan Dösinger: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-04-25 um 17:45 schrieb Thomas Faller: >> This format is not documented under >> >> https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx >> >> but its implemented in the internet explorer and in the windows >> script host. > In this case a test would be very useful. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx > 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c > QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE > fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE > +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 > HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 > aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl > HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a > lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 > sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W > cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu > Ln6ptTTJVzUg3QpSR6jN > =a7ty > -----END PGP SIGNATURE----- The TestBot test was positive (https://testbot.winehq.org/JobDetails.pl?Key=13063) Dates like 1970/01/01 were parsed by jscript as expected here.

April 27, 2015

Re: jscript: Date.parse: long date with '/' or '-'

by Thomas Faller

Am 25.04.2015 um 18:43 schrieb Stefan Dösinger: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Am 2015-04-25 um 17:45 schrieb Thomas Faller: >> This format is not documented under >> >> https://msdn.microsoft.com/en-us/library/k4w173wk%28v=vs.84%29.aspx >> >> but its implemented in the internet explorer and in the windows >> script host. > In this case a test would be very useful. > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v2 > > iQIcBAEBAgAGBQJVO8QzAAoJEN0/YqbEcdMwl4EP/1+xPW5sSLx86MPGq8e1eXCx > 7ON4cSV1u0IIAnw1qMc/VuUxxHw3LN6VSrBN8Rbq6XxXx/1fLvaIz7+ckdBvOz3c > QhregFjv7kBsRs3WCDuz8SujMMCeBL0FdeAg7xuWl61mHRKxkaeBNROHlfPxG7GE > fYBdOTUPzdEj8eYTB48xozHPMV3EadpO7GL+742upv4qxJa3m7V2ZU3/+4O1atjE > +yZyVKEwxKU6PLJNMMzva/TpQPxIEPsKg2L3hFAXnZXjn6lJeew6PWGQiR/OpNR0 > HLQcdGk3xQlslefauJpJ6ffSyHl+wRrK7DUpUDsNAQuWQ4ALwHsjkFGG8ph8xRL4 > aMnnA+afBU2VXnVpkmnjHlILIaWtCejMo4zveXjD1dk15CeOcs2ezasxhbbl9FUl > HySkMNyX6gX07BfR6e9N5gwCzHdOj0GbvRtPMcRXWkPwgzj47xX4NbT0QT8ncg2a > lsey/aE8aEscUwGROWm9xv7egKxdBM5kxccBxAMFY1Z5MBNbntlMVTwKERWAl1q9 > sRjf77vuuD8LIyXpntqVOb96Hq+4mIo0VzAClFOqSIf6bv8fPz8oFD1elE6G3M4W > cXH620URbzXsXg4ZBVRUP6t5sIy5jnSZG+I5h0BUxSizw5ekxbKWlfCicFSZStbu > Ln6ptTTJVzUg3QpSR6jN > =a7ty > -----END PGP SIGNATURE----- The TestBot test was positive (https://testbot.winehq.org/JobDetails.pl?Key=13063) Dates like 1970/01/01 were parsed by jscript as expected here.

April 27, 2015

Re: [PATCH 2/2] winemac: Don't pump messages in ChangeDisplaySettings (v3).

by Ken Thomases

On Apr 27, 2015, at 2:54 AM, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Version 3: Use SendNotifyMessage for sending WM_MACDRV_DISPLAYCHANGE. > Ken, I need your review again to make sure that this change doesn't > have any negative impact regarding the sync_window_position call that > is part of the WM_MACDRV_DISPLAYCHANGE message handling. Looks OK to me. It is not necessary for the sync_window_position() call to be made synchronously with respect to the sending code. -Ken

April 27, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Matteo Bruni

2015-04-27 17:54 GMT+02:00 Marvin <testbot(a)winehq.org>: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > https://testbot.winehq.org/JobDetails.pl?Key=13061 > > Your paranoid android. > > > === build (build) === > Patch failed to apply It looks like the testbot failed the update to today's git: http://testbot.winehq.org/JobDetails.pl?Key=13049.

April 27, 2015

Re: [PATCH 5/5] d3d9/tests: Add spotlight and light range tests.

by Marvin

Hi, While running your changed tests on Windows, I think I found new failures. Being a bot and all I'm not very good at pattern recognition, so I might be wrong, but could you please double-check? Full results can be found at https://testbot.winehq.org/JobDetails.pl?Key=13061 Your paranoid android. === build (build) === Patch failed to apply

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> Why do you need to leave the function instead of checking for further > >> >> messages? What is the issue you are seeing? > >> > > >> > If you mean the only quoted piece of code (MSG_POSTED case) then only > >> > reason of the change is to make it consistent with the sent message case. > >> > >> I don't really see any reason to make it consistent, but I'd like to > >> know why you need the other one too. > > > > The other one is needed to make the test pass for the sent message case. > > If you have a suggestion how fix it differently please let me know. > > I may have one, once I understand what you are trying to fix. What is > the actual problem that prompted you to write the tests and the fix? The problem is described in the first test for sending inter-thread messages: https://www.winehq.org/pipermail/wine-patches/2015-April/138750.html My original guess was that the problem is caused by internal message handling in Wine, and the tests I created confirmed that there is a problem in that area. The patch we are discussing fixes the problem discovered by these tests. Another guess was that it's a race between EndDialog and DestroyWindow leading to a crash. According to my tests under Windows EndDialog called from another thread never returns. At the moment I'm inclined to another theory about the source of the problem: it's the implementation of SetWindowPos called for another thread window, and the tests+patches I sent today confirm that. Moreover it looks like the real fix for the problem. There are other discovered problems caused by DestroyWindow from window's thread+SendMessage from another thread, but let's leave them aside for the time being. -- Dmitry.

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags >> >> > else >> >> > peek_message( msg, info.msg.hwnd, info.msg.message, >> >> > info.msg.message, flags | PM_REMOVE, changed_mask ); >> >> > - continue; >> >> > + >> >> > + /* give a chance to real message to arrive */ >> >> > + HeapFree( GetProcessHeap(), 0, buffer ); >> >> > + return FALSE; >> >> >> >> Why do you need to leave the function instead of checking for further >> >> messages? What is the issue you are seeing? >> > >> > If you mean the only quoted piece of code (MSG_POSTED case) then only >> > reason of the change is to make it consistent with the sent message case. >> >> I don't really see any reason to make it consistent, but I'd like to >> know why you need the other one too. > > The other one is needed to make the test pass for the sent message case. > If you have a suggestion how fix it differently please let me know. I may have one, once I understand what you are trying to fix. What is the actual problem that prompted you to write the tests and the fix? -- Alexandre Julliard julliard(a)winehq.org

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Dmitry Timoshkov

Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags > >> > else > >> > peek_message( msg, info.msg.hwnd, info.msg.message, > >> > info.msg.message, flags | PM_REMOVE, changed_mask ); > >> > - continue; > >> > + > >> > + /* give a chance to real message to arrive */ > >> > + HeapFree( GetProcessHeap(), 0, buffer ); > >> > + return FALSE; > >> > >> Why do you need to leave the function instead of checking for further > >> messages? What is the issue you are seeing? > > > > If you mean the only quoted piece of code (MSG_POSTED case) then only > > reason of the change is to make it consistent with the sent message case. > > I don't really see any reason to make it consistent, but I'd like to > know why you need the other one too. The other one is needed to make the test pass for the sent message case. If you have a suggestion how fix it differently please let me know. -- Dmitry.

April 27, 2015

Re: user32: After handling an internal message give a chance to real message to arrive.

by Alexandre Julliard

Dmitry Timoshkov <dmitry(a)baikal.ru> writes: > Alexandre Julliard <julliard(a)winehq.org> wrote: > >> > @@ -2931,7 +2931,10 @@ static BOOL peek_message( MSG *msg, HWND hwnd, UINT first, UINT last, UINT flags >> > else >> > peek_message( msg, info.msg.hwnd, info.msg.message, >> > info.msg.message, flags | PM_REMOVE, changed_mask ); >> > - continue; >> > + >> > + /* give a chance to real message to arrive */ >> > + HeapFree( GetProcessHeap(), 0, buffer ); >> > + return FALSE; >> >> Why do you need to leave the function instead of checking for further >> messages? What is the issue you are seeing? > > If you mean the only quoted piece of code (MSG_POSTED case) then only > reason of the change is to make it consistent with the sent message case. I don't really see any reason to make it consistent, but I'd like to know why you need the other one too. -- Alexandre Julliard julliard(a)winehq.org

April 27, 2015