wine-devel August 2016

wine-devel@winehq.org

55 participants
282 discussions

Re: user32: Fix DefWindowProc behavior on WM_NCRBUTTONDOWN message
by Marvin 26 Aug '16

26 Aug '16

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

1 0

Re: [2/3] winex11: Returning more reliable value from X11DRV_MsgWaitForMultipleObjects.
by Ken Thomases 26 Aug '16

26 Aug '16

Hi, On Aug 23, 2016, at 8:13 AM, Akihiro Sagawa <sagawa.aki(a)gmail.com> wrote: > > This patch fixes ole32 test failure with my IME window patch. > > After processing several X events, X11DRV_MsgWaitForMultipleObjects always > tells us that a new message is available. This is not true for some cases. > > For instance, when we call DestroyWindow, the X queues DestroyEvent. Then, > X11DRV_MsgWaitForMultipleObjects handles the event only; none is posted or > sent as hwnd for destroyed window is unavailable. However, the function > states "new message is available" by returning count - 1 value. > > This is an issue for CoWaitForMultipleHandles because it expects a new > message in the queue and consumes the message. I'm looking at this with an eye toward whether the Mac driver needs a similar change. First, there's no change in the ole32 tests with or without your IME window patch when using the Mac driver. There's a clipboard failure but everything else succeeds. Second, the Mac driver doesn't have a notion of the window being destroyed behind our backs. I.e. there's nothing like a DestroyNotify event for a window whose HWND is still valid. But, just because that particular case doesn't come up doesn't mean the change is not still relevant to the Mac driver for other cases. However, I'm having a hard time seeing the logic of your change. 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? 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? Thanks, Ken

2 1

What flavor of C does Wine source target?
by Ruslan Kabatsayev 26 Aug '16

26 Aug '16

Hello all, 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. So, I wonder now, what flavor of C does Wine actually target? What tools can I use to automatically restrict language features? Regards, Ruslan

3 2

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().
by Marvin 26 Aug '16

26 Aug '16

1 0

Re: [PATCH 3/6] wined3d: Handle WINED3DFMT_FLAG_BROKEN_PITCH in wined3d_format_calculate_size().
by Marvin 26 Aug '16

26 Aug '16

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.

1 0

Re: ntdll: Add missing stdint.h include for kfreebsd architectures.
by Jens Reyer 26 Aug '16

26 Aug '16

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 assume the patch itself is fine!? We deploy it on every arch (Linux: amd64 arm64 armel armhf i386 powerpc, hurd-i386, kfreebsd-i386) Authorship: The original author Mike (CCed in patch submission) is quite short on time, so I decided to bring this patch (and others that we have in Debian) here. The whole Debian packaging is LGPL-2.1+ licensed (except if we use 3rd party stuff, which isn't the case for this patch). See [1]. History of this patch: 1.7.45-1 add, Michael Gilbert [2] 1.7.54-1 temporarily disable, Michael Gilbert [3] 1.7.54-2 refresh and readd, Michael Gilbert [4] 1.7.55-1 rename, Michael Gilbert [5] 1.9.9-1 refresh, Jens Reyer [6] Is this patch needed? Related (fixed) build failures: The last successful build on kfreebsd-i386 without this patch was 1.7.41-1. There's no data for 1.7.42/1.7.43. 1.7.44 failed to build. With the patch 1.7.45 and following versions built. When the patch was removed temporarily 1.7.54-1 failed to build. Later versions with patch built again. A list of all build logs is available at [7]. I didn't run a regression test, nor can name the relevant commit that caused the failure (I assume it was a change in Wine). If required I might verify if the patch is still needed today, but I'd have to apply for access to a kfreebsd machine first. I hope this clarifies everything Greets jre [1] https://anonscm.debian.org/git/pkg-wine/wine.git/tree/debian/copyright [2] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=4d7a55e [3] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=94643f4 [4] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=0fa1339 [5] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=8deb56f [6] https://anonscm.debian.org/git/pkg-wine/wine.git/commit/?id=3d3f870 [7] https://buildd.debian.org/status/logs.php?pkg=wine-development&arch=kfreebs…

1 1

Re: [PATCH 4/4] oleaut32: Implement ITypeComp::Bind() proxy/stub
by Huw Davies 26 Aug '16

26 Aug '16

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.

1 0

Re: kernel32/tests: Add a missing linebreak to an ok() message.
by Marvin 26 Aug '16

26 Aug '16

1 0

Re: [PATCH] ntdll: Set Rip in for longjmp in RtlRestoreContext (try3)
by Marvin 26 Aug '16

26 Aug '16

1 0

Re: What flavor of C does Wine source target?
by achbarrr＠gmail.com 26 Aug '16

26 Aug '16

hello Ruslan wine is looking like emulator its works same like bluestacks app player. if its true wine is not emulator its must work like other. Ruslan Kabatsayev <b7.10110111(a)gmail.com> wrote: >Hello all, > >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. > >So, I wonder now, what flavor of C does Wine actually target? What >tools can I use to automatically restrict language features? > >Regards, >Ruslan > >

1 0

← Newer
1
2
3
4
5
6
7
8
...
29
Older →

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 August 2016