August 2016 - Wine-Devel - list.winehq.org

Re: user32: Fix DefWindowProc behavior on WM_NCRBUTTONDOWN message

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=25405 Your paranoid android. === w7u (32 bit msg) === msg.c:4771: Test failed: ShowWindow(SW_RESTORE):overlapped: 18: the msg sequence is not complete: expected 0000 - actual 0088 === w8 (32 bit msg) === msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (32 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w864 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000 === w1064 (64 bit msg) === msg.c:6482: Test failed: Update region shouldn't be empty msg.c:6715: Test failed: InvalidateErase: 0: the msg sequence is not complete: expected 0085 - actual 0000 msg.c:6717: Test failed: Paint: 0: the msg sequence is not complete: expected 000f - actual 0000 msg.c:7078: Test failed: SetWindowPos:FrameChanged_clip: 10: the msg sequence is not complete: expected 0000 - actual 001a msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:6488: Test failed: Regions are different msg.c:13932: Test failed: WM_NCRBUTTONDOWN on caption: 3: the msg sequence is not complete: expected 007b - actual 0000

Aug. 26, 2016

Re: [2/3] winex11: Returning more reliable value from X11DRV_MsgWaitForMultipleObjects.

by Akihiro Sagawa

On Thu, 25 Aug 2016 13:35:43 -0500, Ken Thomases wrote: > Hi, Hi, (snip) > In process_events(), you use a variable named "queued" to hold the result > of calls to event handlers. That implies that event handlers should > only return true if they have posted or sent a Windows message or > hardware input. But that doesn't seem to be what you've actually done > in the event handlers. For example, in the first "if" statement in > X11DRV_MapNotify(), you return true without queuing anything. > > Instead, you seem to be returning true for some notion of "success" > in handling events, but I'm not sure how that plays into the rationale > for this patch. Am I misunderstanding something? Ideally, event handlers should return FALSE if they succeed and nothing is posted or sent by them. However, at that time, I was afraid of introducing regressions, I limited return FALSE case if the handler completely fails. So, It's not perfect, yet. In other words, my patch allows the handler states it never posts/sends a message by returning FALSE. But returning TRUE doesn't mean there is a new message. > I also don't get why you changed the TRACE at the end of > process_events(). The events really were processed. They aren't > "ignored" just because they didn't result in messages or input being > queued. Also, shouldn't the return type of process_events() be changed > to BOOL? Good point. I'll sent a patch in this weekend. Thanks too, Akihiro Sagawa

Aug. 26, 2016

Re: What flavor of C does Wine source target?

by Michael Stefaniuc

On 08/26/2016 04:31 PM, Andrew Eikum wrote: > On Fri, Aug 26, 2016 at 08:59:01AM +0300, Ruslan Kabatsayev wrote: >> While developing some code for Wine I wanted to ensure that I don't >> use some C99 features like C++-style comments or declaration of >> variables after statement. But the only way I found to do this with >> gcc was to use '-std=c89 -pedantic'. This appears to break lots of >> other things in winelib, particularly 'inline' functions, so it can't >> really be used for Wine/Winelib sources. The default for GCC is gnu89, >> which does allow the things Wine doesn't want. >> > > I don't think we really have a strict standard. You've already > identified the two big no-nos. Someone can correct me, but I believe > we use C89 for most of our code because we expect Microsoft's C++ > compiler to build it, and it only supports up to C89. > > Some parts of Wine, for example winealsa.drv, will never be useful on > Windows, so they may use features that wouldn't work in msvc, > intentionally or not. But mostly we stick to C89 for consistency. > >> So, I wonder now, what flavor of C does Wine actually target? What >> tools can I use to automatically restrict language features? >> > > Wine's default flags should warn about declaring variables after code, > and it's easy to make sure you're not using C++-style comments > visually or with grep or so. There isn't really much else most > developers will have to worry about. Feel free to ask if you think you > might be using something that's not in C89. Nameless structs and unions. But only Francois really cares about those and he'll fix that code up later on. bye michael

Aug. 26, 2016

Re: What flavor of C does Wine source target?

by Andrew Eikum

On Fri, Aug 26, 2016 at 08:59:01AM +0300, Ruslan Kabatsayev wrote: > While developing some code for Wine I wanted to ensure that I don't > use some C99 features like C++-style comments or declaration of > variables after statement. But the only way I found to do this with > gcc was to use '-std=c89 -pedantic'. This appears to break lots of > other things in winelib, particularly 'inline' functions, so it can't > really be used for Wine/Winelib sources. The default for GCC is gnu89, > which does allow the things Wine doesn't want. > I don't think we really have a strict standard. You've already identified the two big no-nos. Someone can correct me, but I believe we use C89 for most of our code because we expect Microsoft's C++ compiler to build it, and it only supports up to C89. Some parts of Wine, for example winealsa.drv, will never be useful on Windows, so they may use features that wouldn't work in msvc, intentionally or not. But mostly we stick to C89 for consistency. > So, I wonder now, what flavor of C does Wine actually target? What > tools can I use to automatically restrict language features? > Wine's default flags should warn about declaring variables after code, and it's easy to make sure you're not using C++-style comments visually or with grep or so. There isn't really much else most developers will have to worry about. Feel free to ask if you think you might be using something that's not in C89. Andrew

Aug. 26, 2016

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().

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=25402 Your paranoid android. === w864 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f. === w1064 (64 bit device) === device.c:4392: Test failed: cw is 0xf60, expected 0x7f. device.c:4401: Test failed: Callback cw is 0xf60, expected 0x7f.

Aug. 26, 2016

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().

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=25401 Your paranoid android. === w8 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480. === w864 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480. === w1064 (32 bit device) === device.c:2779: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2784: Test failed: The focus window is active. device.c:2792: Test failed: Got unexpected hr 0x88760869. device.c:2796: Test failed: Got unexpect screen size 800x600. device.c:2811: Test failed: Expected message 0x47 for window 0, but didn't receive it, i=1. device.c:2820: Test failed: Got unexpect screen size 800x600. device.c:2833: Test failed: Expected message 0x7e for window 0, but didn't receive it. device.c:2841: Test failed: Got unexpect width 640. device.c:2842: Test failed: Got unexpect height 480.

Aug. 26, 2016

Re: ntdll: Add missing stdint.h include for kfreebsd architectures.

by Jens Reyer

On 25.08.2016 13:32, Jens Reyer wrote: > On 24.08.2016 19:05, Marvin wrote: >> Thank you for your contribution to Wine! >> >> This is an automated notification to let you know that your patch has >> been reviewed and its status set to "Pending". >> >> This means that the patch is not necessarily wrong, but its >> correctness is not obvious. You should either write a test case >> demonstrating that it is correct, try to fix the problem in a more >> straightforward way, or better explain why you are doing things this >> way. >> >> If you do not understand the reason for this status, disagree with our >> assessment, or are simply not sure how to proceed next, please ask for >> clarification by replying to this email. > > It's not clear to me why this was set to pending, so I'll try to cover > most bases in this mail: I saw you committed it yesterday, conditionally only if we have the header file. I'll keep that in mind. Thanks a lot!

Aug. 26, 2016

Re: [PATCH 4/4] oleaut32: Implement ITypeComp::Bind() proxy/stub

by Huw Davies

On Thu, Aug 25, 2016 at 08:57:18PM +0300, Nikolay Sivov wrote: > + if (hr == S_OK) > + { > + switch (*desckind) > + { > + case DESCKIND_FUNCDESC: > + bindptr->lpfuncdesc = funcdesc; > + break; > + case DESCKIND_VARDESC: > + bindptr->lpvardesc = vardesc; > + break; > + case DESCKIND_TYPECOMP: > + bindptr->lptcomp = typecomp; > + break; > + default: > + ; > + } You're missing DESCKIND_IMPLICITAPPOBJ which should be handled like DESCKIND_VARDESC. Huw.

Aug. 26, 2016

Re: kernel32/tests: Add a missing linebreak to an ok() message.

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=25390 Your paranoid android. === w1064 (32 bit thread) === thread.c:1086: Test failed: got 0 with 5 (expected FALSE with ERROR_GEN_FAILURE)

Aug. 26, 2016

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try3)

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=25379 Your paranoid android. === wvistau64 (32 bit exception) === exception.c:551: Test failed: 42: Unexpected eip 0x2c0000/0x2c0001 exception: unhandled exception 80000004 at 002C0000 exception.c:551: Test failed: 42: Unexpected eip 0x77baed97/0x2c0001 === w7u (32 bit exception) === exception.c:551: Test failed: 42: Unexpected eip 0x3c0000/0x3c0001 exception: unhandled exception 80000004 at 003C0000 exception.c:551: Test failed: 42: Unexpected eip 0x77cde34f/0x3c0001 === w1064 (32 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died) === w1064 (64 bit exception) === An error occurred while waiting for the test to complete: network read timed out (wait2/connect:AgentVersion.h:0/9) The test VM has crashed, rebooted or lost connectivity (or the TestAgent server died)

Aug. 26, 2016