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

Re: [PATCH] wincodecs: Trigger conversion to target format in WriteSource()

by Vincent Povirk

> Despite the removing a questionable FIXME this part of the code won't do > what you think it does. I think it will request a specific pixel format, and the encoder may actually set a different format if it does not support that one. Am I missing something? > Besides, since there is no a single todo_wine > removed with this patch adding a bunch of tests for different encoders > is needed to show that the automatic conversion is really supposed to > happen, and that it doesn't depend on the implementation detail in some > of the encoders. According to my testing not every encoder does this > kind of thing, especially when a conversion needs a palette. As long as some of them do, it makes sense to have it in common code, and if we need to refine the behavior for individual encoders we can do that later.

Nov. 23, 2016

Re: [PATCH] wincodecs: Recognize FilterOption property in PNG encoder

by Vincent Povirk

We should either set this option when encoding, or print a fixme. I think setting it is easy enough.

Nov. 23, 2016

Re: [PATCH] quartz: Use straight assignments instead of CopyRect().

by Michael Stefaniuc

On 11/22/2016 08:01 PM, Hadrien Boizard wrote: > Signed-off-by: Hadrien Boizard <h.boizard(a)gmail.com> > --- > dlls/quartz/videorenderer.c | 8 ++++---- > dlls/quartz/vmr9.c | 8 ++++---- > 2 files changed, 8 insertions(+), 8 deletions(-) > > > 0001-quartz-Use-straight-assignments-instead-of-CopyRect.patch > > > diff --git a/dlls/quartz/videorenderer.c b/dlls/quartz/videorenderer.c > index 61f08f5..6631ccd 100644 > --- a/dlls/quartz/videorenderer.c > +++ b/dlls/quartz/videorenderer.c > @@ -483,7 +483,7 @@ static const BaseWindowFuncTable renderer_BaseWindowFuncTable = { > static HRESULT WINAPI VideoRenderer_GetSourceRect(BaseControlVideo* iface, RECT *pSourceRect) > { > VideoRendererImpl *This = impl_from_BaseControlVideo(iface); > - CopyRect(pSourceRect,&This->SourceRect); > + *pSourceRect = This->SourceRect; NACK, this is not a no-op change. CopyRect() also checks for NULL rect pointers so it protects against NULL pSourceRect. With your change apps would crash if they do that. The proper fix is to add tests for NULL rects and return the proper error in those functions. Or at least add code like: if (!pSourceRect) return E_POINTER; No clue if Andrew Eikum is willing to accept that without tests. E_INVALIDARG would be also a plausible error code. bye michael

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Huw Davies

On 23 Nov 2016, at 14:30, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Huw Davies <huw(a)codeweavers.com> wrote: >>> There should be a better way of detecting broken behaviour then, in current >>> form the failures just get hidden under a broken() blanket, effectively >>> disabling the whole test, and making it useless. Perhaps something like >>> the check for ntdll exports that's performed at the start of the test. >> >> I don’t see why this case is any different from other similar broken behaviours. >> Note that under Wine, broken is inverted, so the test is not ‘disabled' on that >> platform. > > I'm more concerned about testing Windows behaviour, and staying compatible > enough. Apparently Microsoft has changed some internal bits how window procs > get the A/W affinity (and DefWindowProcA/W in particular), and I would like > to know the reason of the test breakage. Disabling the test by marking its > result as broken is usually the last resort thing after a clear understanding > what is going on. The reason for the test breakage is because Microsoft changed some internal bits on how window procs get the A/W affinity… And made a mess of it while doing so. Another option is to just remove this test. Huw.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > >>>>>> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); > >>>>>> + if (IsWindowUnicode(hwnd)) > >>>>>> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); > >>>>>> + else > >>>>>> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); > >>>>> > >>>>> This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always > >>>>> return a unicode string regardless of wheather IsWindowUnicode() is broken > >>>>> or not, otherwise a lot of applications would misbehave in weird ways. > >>>>> This needs further investigation. > >>>> > >>>> Exactly, the reason I added that bit was to show that this behaviour > >>>> is truly broken. > >>> > >>> Sorry, but I can't believe that such a basic functionality like returning > >>> a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI > >>> uses it to retrieve and pass strings around for various purposes from getting > >>> username/password/regisration to getting random user input, so if it would be > >>> broken that would mean a lot of applications/installers/UI libraries/etc. were > >>> broken, and that wouldn't stay unnoticed. > >> > >> This is a very unique situation (look at how the window in this test is created). > >> It certainly does not apply to all windows. > >> > >> It’s difficult to know why this test was added in the first place. Any application > >> that actually relies on this behaviour would have been broken in Windows 8. > > > > There should be a better way of detecting broken behaviour then, in current > > form the failures just get hidden under a broken() blanket, effectively > > disabling the whole test, and making it useless. Perhaps something like > > the check for ntdll exports that's performed at the start of the test. > > I don’t see why this case is any different from other similar broken behaviours. > Note that under Wine, broken is inverted, so the test is not ‘disabled' on that > platform. I'm more concerned about testing Windows behaviour, and staying compatible enough. Apparently Microsoft has changed some internal bits how window procs get the A/W affinity (and DefWindowProcA/W in particular), and I would like to know the reason of the test breakage. Disabling the test by marking its result as broken is usually the last resort thing after a clear understanding what is going on. -- Dmitry.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Huw Davies

> On 23 Nov 2016, at 14:17, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Huw Davies <huw(a)codeweavers.com> wrote: > >>>>>> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); >>>>>> + if (IsWindowUnicode(hwnd)) >>>>>> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); >>>>>> + else >>>>>> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); >>>>> >>>>> This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always >>>>> return a unicode string regardless of wheather IsWindowUnicode() is broken >>>>> or not, otherwise a lot of applications would misbehave in weird ways. >>>>> This needs further investigation. >>>> >>>> Exactly, the reason I added that bit was to show that this behaviour >>>> is truly broken. >>> >>> Sorry, but I can't believe that such a basic functionality like returning >>> a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI >>> uses it to retrieve and pass strings around for various purposes from getting >>> username/password/regisration to getting random user input, so if it would be >>> broken that would mean a lot of applications/installers/UI libraries/etc. were >>> broken, and that wouldn't stay unnoticed. >> >> This is a very unique situation (look at how the window in this test is created). >> It certainly does not apply to all windows. >> >> It’s difficult to know why this test was added in the first place. Any application >> that actually relies on this behaviour would have been broken in Windows 8. > > There should be a better way of detecting broken behaviour then, in current > form the failures just get hidden under a broken() blanket, effectively > disabling the whole test, and making it useless. Perhaps something like > the check for ntdll exports that's performed at the start of the test. I don’t see why this case is any different from other similar broken behaviours. Note that under Wine, broken is inverted, so the test is not ‘disabled' on that platform. Huw.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > >>>> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); > >>>> + if (IsWindowUnicode(hwnd)) > >>>> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); > >>>> + else > >>>> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); > >>> > >>> This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always > >>> return a unicode string regardless of wheather IsWindowUnicode() is broken > >>> or not, otherwise a lot of applications would misbehave in weird ways. > >>> This needs further investigation. > >> > >> Exactly, the reason I added that bit was to show that this behaviour > >> is truly broken. > > > > Sorry, but I can't believe that such a basic functionality like returning > > a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI > > uses it to retrieve and pass strings around for various purposes from getting > > username/password/regisration to getting random user input, so if it would be > > broken that would mean a lot of applications/installers/UI libraries/etc. were > > broken, and that wouldn't stay unnoticed. > > This is a very unique situation (look at how the window in this test is created). > It certainly does not apply to all windows. > > It’s difficult to know why this test was added in the first place. Any application > that actually relies on this behaviour would have been broken in Windows 8. There should be a better way of detecting broken behaviour then, in current form the failures just get hidden under a broken() blanket, effectively disabling the whole test, and making it useless. Perhaps something like the check for ntdll exports that's performed at the start of the test. -- Dmitry.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Huw Davies

> On 23 Nov 2016, at 13:54, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Huw Davies <huw(a)codeweavers.com> wrote: > >>>> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); >>>> + if (IsWindowUnicode(hwnd)) >>>> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); >>>> + else >>>> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); >>> >>> This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always >>> return a unicode string regardless of wheather IsWindowUnicode() is broken >>> or not, otherwise a lot of applications would misbehave in weird ways. >>> This needs further investigation. >> >> Exactly, the reason I added that bit was to show that this behaviour >> is truly broken. > > Sorry, but I can't believe that such a basic functionality like returning > a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI > uses it to retrieve and pass strings around for various purposes from getting > username/password/regisration to getting random user input, so if it would be > broken that would mean a lot of applications/installers/UI libraries/etc. were > broken, and that wouldn't stay unnoticed. This is a very unique situation (look at how the window in this test is created). It certainly does not apply to all windows. It’s difficult to know why this test was added in the first place. Any application that actually relies on this behaviour would have been broken in Windows 8. Huw.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Dmitry Timoshkov

Huw Davies <huw(a)codeweavers.com> wrote: > >> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); > >> + if (IsWindowUnicode(hwnd)) > >> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); > >> + else > >> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); > > > > This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always > > return a unicode string regardless of wheather IsWindowUnicode() is broken > > or not, otherwise a lot of applications would misbehave in weird ways. > > This needs further investigation. > > Exactly, the reason I added that bit was to show that this behaviour > is truly broken. Sorry, but I can't believe that such a basic functionality like returning a unicode string using SendMessageW(WM_GETTEXT) is actually broken. Any UI uses it to retrieve and pass strings around for various purposes from getting username/password/regisration to getting random user input, so if it would be broken that would mean a lot of applications/installers/UI libraries/etc. were broken, and that wouldn't stay unnoticed. -- Dmitry.

Nov. 23, 2016

Re: user32/tests: Mark built-in wndproc auto-detection behaviour as broken on Windows 8 and 10.

by Huw Davies

> On 23 Nov 2016, at 12:46, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > > Huw Davies <huw(a)codeweavers.com> wrote: > >> + SendMessageW(hwnd, WM_GETTEXT, sizeof(buf) / sizeof(buf[0]), (LPARAM)buf); >> + if (IsWindowUnicode(hwnd)) >> + ok(memcmp(buf, unistring, sizeof(unistring)) == 0, "WM_GETTEXT invalid return\n"); >> + else >> + ok(memcmp(buf, unistring, sizeof(unistring)) != 0, "WM_GETTEXT invalid return\n"); > > This doesn't look right. SendMessageW(WM_GETTEXT) is supposed to always > return a unicode string regardless of wheather IsWindowUnicode() is broken > or not, otherwise a lot of applications would misbehave in weird ways. > This needs further investigation. Exactly, the reason I added that bit was to show that this behaviour is truly broken. Huw.

Nov. 23, 2016