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

Re: [PATCH 1/2] enhmfdrv: Always set ExtTextOut bounding rect if we're not inside path bracket

by Piotr Caban

Hi, On 04/28/16 12:14, Huw Davies wrote: > I think we need a better understanding of paths on metafiles. There > have been a number of patches which mainly hack ExtTextOut when it's > clear that the issues extend beyond that single record. > > For example, I've just noticed that a Rectangle within a path doesn't > update the emf's bounds. This unfortunately was not spotted by > test_emf_GetPath() because for some reason compare_emf_bits() doesn't > check them. I've sent patches that modify all functions that can be used within the path. I've also tested most other functions that are not affected by BeginPath call (like StretchBlt, SetPixel, etc). Please let me know if anything else needs to be done. Thanks, Piotr

April 28, 2016

Re: kernel32/tests: Add more tests for GetConsoleFontInfo

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=22682 Your paranoid android. === w8 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 3696961328 console.c:1445: Test failed: [15] Expected output count to be 0, got 3696961328 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 3696961328 console.c:1689: Test failed: [13] Expected output count to be 0, got 3696961328 console.c:1689: Test failed: [15] Expected output count to be 0, got 3696961328 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 3696961328 === w864 (32 bit console) === console.c:1445: Test failed: [13] Expected output count to be 0, got 4078116005 console.c:1445: Test failed: [15] Expected output count to be 0, got 4078116005 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 4078116005 console.c:1689: Test failed: [13] Expected output count to be 0, got 4078116005 console.c:1689: Test failed: [15] Expected output count to be 0, got 4078116005 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 4078116005 === w1064 (32 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [13] Expected output count to be 0, got 3654641613 console.c:1445: Test failed: [15] Expected output count to be 0, got 3654641613 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 3654641613 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [13] Expected output count to be 0, got 3654641613 console.c:1689: Test failed: [15] Expected output count to be 0, got 3654641613 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 3654641613 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w864 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1 === w1064 (64 bit console) === console.c:2567: Test failed: expected ERROR_INVALID_HANDLE, got 1 console.c:2573: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2580: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:2587: Test failed: expected ERROR_NOT_ENOUGH_MEMORY, got 998 console.c:1270: Test failed: expected VerifyConsoleIoHandle to succeed console.c:1445: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1445: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [3] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [11] Expected output count to be 3735928559, got 0 console.c:1689: Test failed: [18] Expected output count to be 3735928559, got 0 console.c:2148: Test failed: [7] Expected count to be 0, got 1 console.c:2214: Test failed: [7] Expected count to be 0, got 1 console.c:2280: Test failed: [7] Expected count to be 0, got 1

April 28, 2016

Re: kernel32/tests: Add more tests for GetConsoleFontInfo

by Sebastian Lackner

On 28.04.2016 15:27, Hugh McMaster wrote: > Signed-off-by: Hugh McMaster <hugh.mcmaster(a)outlook.com> > --- > dlls/kernel32/tests/console.c | 66 ++++++++++++++++++++++++++++++++++++++++++- > 1 file changed, 65 insertions(+), 1 deletion(-) > They don't pass here: console.c:2858: Test failed: got 0, expected 80 console.c:2859: Test failed: got 0, expected 25 console.c:2866: Test failed: got 0, expected 80 console.c:2867: Test failed: got 0, expected 25 console.c:2901: Test failed: got 0, expected 83 console.c:2903: Test failed: got 0, expected 30 console.c:2911: Test failed: got 0, expected 83 console.c:2912: Test failed: got 0, expected 30

April 28, 2016

Re: server: Fix detection of duplicate console history lines. (v2)

by Alexandre Julliard

Sebastian Lackner <sebastian(a)fds-team.de> writes: > Signed-off-by: Sebastian Lackner <sebastian(a)fds-team.de> > --- > Changes in v2: > * We can't really use memcmp because it could allow exploits with special input, > like "abc\0def", where it would probably compare past the end of the string. Note that you don't need special input, any comparison with a shorter string can potentially overrun. -- Alexandre Julliard julliard(a)winehq.org

April 28, 2016

Re: [PATCH 1/2] enhmfdrv: Always set ExtTextOut bounding rect if we're not inside path bracket

by Huw Davies

On Tue, Apr 26, 2016 at 02:19:27PM +0200, Piotr Caban wrote: > Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> > --- > dlls/gdi32/enhmfdrv/dc.c | 6 ++++++ > dlls/gdi32/enhmfdrv/enhmetafiledrv.h | 1 + > dlls/gdi32/enhmfdrv/graphics.c | 4 +++- > dlls/gdi32/enhmfdrv/init.c | 1 + > dlls/gdi32/tests/metafile.c | 11 +++++++++++ > 5 files changed, 22 insertions(+), 1 deletion(-) I think we need a better understanding of paths on metafiles. There have been a number of patches which mainly hack ExtTextOut when it's clear that the issues extend beyond that single record. For example, I've just noticed that a Rectangle within a path doesn't update the emf's bounds. This unfortunately was not spotted by test_emf_GetPath() because for some reason compare_emf_bits() doesn't check them. Huw.

April 28, 2016

Re: jscript: Fix handling of numbers starting with decimal separator

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=22675 Your paranoid android. === wxppro (32 bit) === Found no trace of the test summary line or of a crash === w2003std (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (32 bit) === Found no trace of the test summary line or of a crash === w2008s64 (32 bit) === Found no trace of the test summary line or of a crash === w7u (32 bit) === Found no trace of the test summary line or of a crash === w7pro64 (32 bit) === Found no trace of the test summary line or of a crash === w8 (32 bit) === Found no trace of the test summary line or of a crash === w864 (32 bit) === Found no trace of the test summary line or of a crash === w1064 (32 bit) === Found no trace of the test summary line or of a crash === wvistau64 (64 bit) === Found no trace of the test summary line or of a crash === w2008s64 (64 bit) === Found no trace of the test summary line or of a crash === w7pro64 (64 bit) === Found no trace of the test summary line or of a crash === w864 (64 bit) === Found no trace of the test summary line or of a crash === w1064 (64 bit) === Found no trace of the test summary line or of a crash

April 28, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 3)

by Nikolay Sivov

On 28.04.2016 6:54, Sebastian Lackner wrote: > On 27.04.2016 09:40, Nikolay Sivov wrote: >> I didn't try myself, but I think we have everything to implement it, >> like this: >> >> GetFileInformationByHandleEx with FileNameInfo -> GetVolumePathNameW -> >> GetVolumeInformationW. >> >> If this works for affected application I think it's better to implement >> it instead of getting in a stub, to find out later that it's not enough. > > Actually, the proper way would be to move the code from kernel32 to ntdll, > and then call NtQueryVolumeInformationFile() which takes a HANDLE argument. > Even better.

April 28, 2016

Re: [PATCH 1/2] mciqtz: Dispatch messages while waiting on command completion.

by Alexandre Julliard

Andrew Eikum <aeikum(a)codeweavers.com> writes: > Without this, we can hit a deadlock if the task thread tries to call a > SendMessage on a window owned by the calling thread. > > Signed-off-by: Andrew Eikum <aeikum(a)codeweavers.com> > --- > dlls/mciqtz32/mciqtz.c | 13 +++++++++++-- > 1 file changed, 11 insertions(+), 2 deletions(-) This breaks the tests here: ../../../tools/runtest -q -P wine -T ../../.. -M winmm.dll -p winmm_test.exe.so mci && touch mci.ok mci.c:1362: Test failed: Expect message 0001 from open alias notify mci.c:1375: Test failed: Expect message 0002 from play (superseded) mci.c:1376: Test failed: Expect message 0001 from status mci.c:1391: Test failed: Expect message 0004 from play (aborted by close) Makefile:226: recipe for target 'mci.ok' failed make: *** [mci.ok] Error 4 -- Alexandre Julliard julliard(a)winehq.org

April 28, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 3)

by Sebastian Lackner

On 27.04.2016 09:40, Nikolay Sivov wrote: > I didn't try myself, but I think we have everything to implement it, > like this: > > GetFileInformationByHandleEx with FileNameInfo -> GetVolumePathNameW -> > GetVolumeInformationW. > > If this works for affected application I think it's better to implement > it instead of getting in a stub, to find out later that it's not enough. Actually, the proper way would be to move the code from kernel32 to ntdll, and then call NtQueryVolumeInformationFile() which takes a HANDLE argument.

April 28, 2016

Re: kernel32: add GetVolumeInformationByHandleW stub (try 3)

by Sebastian Lackner

On 27.04.2016 08:58, Austin English wrote: > I used DWORD * / WCHAR * to avoid adding LP* obfuscations, which is > usually discouraged. > > Try 3: fix formatting > > -- -Austin > > > 0001-kernel32-add-GetVolumeInformationByHandleW-stub-try-.patch > > > From e96e61749556454fb97c382f5f2452d1a825c053 Mon Sep 17 00:00:00 2001 > From: Austin English <austinenglish(a)gmail.com> > Date: Mon, 4 Apr 2016 13:22:44 -0500 > Subject: [PATCH] kernel32: add GetVolumeInformationByHandleW stub (try 3) > > Signed-off-by: Austin English <austinenglish(a)gmail.com> > --- > dlls/kernel32/kernel32.spec | 2 +- > dlls/kernel32/volume.c | 12 ++++++++++++ > include/winbase.h | 1 + > 3 files changed, 14 insertions(+), 1 deletion(-) > > diff --git a/dlls/kernel32/kernel32.spec b/dlls/kernel32/kernel32.spec > index 71dbe4d..2ad9ad4 100644 > --- a/dlls/kernel32/kernel32.spec > +++ b/dlls/kernel32/kernel32.spec > @@ -875,7 +875,7 @@ > @ stdcall GetVersionExA(ptr) > @ stdcall GetVersionExW(ptr) > @ stdcall GetVolumeInformationA(str ptr long ptr ptr ptr ptr long) > -# @ stub GetVolumeInformationByHandleW > +@ stdcall GetVolumeInformationByHandleW(ptr wstr long ptr ptr ptr wstr long) HANDLEs should be marked as "long" in the spec file. > @ stdcall GetVolumeInformationW(wstr ptr long ptr ptr ptr ptr long) > @ stdcall GetVolumeNameForVolumeMountPointA(str ptr long) > @ stdcall GetVolumeNameForVolumeMountPointW(wstr ptr long) > diff --git a/dlls/kernel32/volume.c b/dlls/kernel32/volume.c > index 4f01c99..81905e8 100644 > --- a/dlls/kernel32/volume.c > +++ b/dlls/kernel32/volume.c > @@ -2309,3 +2309,15 @@ BOOL WINAPI SetVolumeMountPointW(LPCWSTR path, LPCWSTR volume) > SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > return FALSE; > } > + > +/*********************************************************************** > + * GetVolumeInformationByHandleW (KERNEL32.@) > + */ > +BOOL WINAPI GetVolumeInformationByHandleW(HANDLE handle, WCHAR *volnamebuf, DWORD volnamesize, DWORD *volserial, > + DWORD *maxlength, DWORD *flags, WCHAR *fsnamebuf, DWORD fsnamesize) > +{ > + FIXME("%p %s %d %p %p %p %s %d\n", handle, debugstr_w(volnamebuf), volnamesize, volserial, maxlength, flags, > + debugstr_w(fsnamebuf), fsnamesize); According to MSDN, those WCHAR arguments should be output parameters. It doesn't really make sense to trace them with debugstr_w. > + SetLastError(ERROR_CALL_NOT_IMPLEMENTED); > + return FALSE; > +} > diff --git a/include/winbase.h b/include/winbase.h > index c5332c0..fac6c29 100644 > --- a/include/winbase.h > +++ b/include/winbase.h > @@ -2167,6 +2167,7 @@ WINBASEAPI BOOL WINAPI GetVersionExW(OSVERSIONINFOW*); > WINBASEAPI BOOL WINAPI GetVolumeInformationA(LPCSTR,LPSTR,DWORD,LPDWORD,LPDWORD,LPDWORD,LPSTR,DWORD); > WINBASEAPI BOOL WINAPI GetVolumeInformationW(LPCWSTR,LPWSTR,DWORD,LPDWORD,LPDWORD,LPDWORD,LPWSTR,DWORD); > #define GetVolumeInformation WINELIB_NAME_AW(GetVolumeInformation) > +WINBASEAPI BOOL WINAPI GetVolumeInformationByHandleW(HANDLE,WCHAR *,DWORD,DWORD *,DWORD *,DWORD *,WCHAR *,DWORD); > WINBASEAPI BOOL WINAPI GetVolumeNameForVolumeMountPointA(LPCSTR,LPSTR,DWORD); > WINBASEAPI BOOL WINAPI GetVolumeNameForVolumeMountPointW(LPCWSTR,LPWSTR,DWORD); > #define GetVolumeNameForVolumeMountPoint WINELIB_NAME_AW(GetVolumeNameForVolumeMountPoint) > -- 2.8.0.rc3 > > >

April 28, 2016