December 2019 - Wine-Devel - list.winehq.org

[PATCH] kernel32/tests: Fix a test failure on Windows 10.

by Zebediah Figura

Signed-off-by: Zebediah Figura <z.figura12(a)gmail.com> --- dlls/kernel32/tests/virtual.c | 14 ++++++++++---- 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/dlls/kernel32/tests/virtual.c b/dlls/kernel32/tests/virtual.c index 952c1054c83..120e9f16f02 100644 --- a/dlls/kernel32/tests/virtual.c +++ b/dlls/kernel32/tests/virtual.c @@ -122,8 +122,11 @@ static void test_VirtualAllocEx(void) ok( bytes_written == 0, "%lu bytes written\n", bytes_written ); b = ReadProcessMemory(hProcess, addr1, src, alloc_size, &bytes_read); ok( !b, "ReadProcessMemory succeeded\n" ); - ok( GetLastError() == ERROR_NOACCESS, "wrong error %u\n", GetLastError() ); - ok( bytes_read == 0, "%lu bytes written\n", bytes_read ); + ok( GetLastError() == ERROR_NOACCESS || + GetLastError() == ERROR_PARTIAL_COPY, /* win10 v1607+ */ + "wrong error %u\n", GetLastError() ); + if (GetLastError() == ERROR_NOACCESS) + ok( bytes_read == 0, "%lu bytes written\n", bytes_read ); b = VirtualProtect( src, 0x2000, PAGE_NOACCESS, &old_prot ); ok( b, "VirtualProtect failed error %u\n", GetLastError() ); @@ -135,8 +138,11 @@ static void test_VirtualAllocEx(void) ok( bytes_written == 0, "%lu bytes written\n", bytes_written ); b = ReadProcessMemory(hProcess, addr1, src, alloc_size, &bytes_read); ok( !b, "ReadProcessMemory succeeded\n" ); - ok( GetLastError() == ERROR_NOACCESS, "wrong error %u\n", GetLastError() ); - ok( bytes_read == 0, "%lu bytes written\n", bytes_read ); + ok( GetLastError() == ERROR_NOACCESS || + GetLastError() == ERROR_PARTIAL_COPY, /* win10 v1607+ */ + "wrong error %u\n", GetLastError() ); + if (GetLastError() == ERROR_NOACCESS) + ok( bytes_read == 0, "%lu bytes written\n", bytes_read ); b = pVirtualFreeEx(hProcess, addr1, 0, MEM_RELEASE); ok(b != 0, "VirtualFreeEx, error %u\n", GetLastError()); -- 2.24.0

Dec. 31, 2019

[PATCH] include: Update DWRITE_INFORMATIONAL_STRING_ID enum.

by Nikolay Sivov

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> --- include/dwrite.idl | 12 +++++++++--- 1 file changed, 9 insertions(+), 3 deletions(-) diff --git a/include/dwrite.idl b/include/dwrite.idl index bfb2c1b37d..b92b1544e0 100644 --- a/include/dwrite.idl +++ b/include/dwrite.idl @@ -127,12 +127,18 @@ typedef enum DWRITE_INFORMATIONAL_STRING_ID DWRITE_INFORMATIONAL_STRING_LICENSE_INFO_URL, DWRITE_INFORMATIONAL_STRING_WIN32_FAMILY_NAMES, DWRITE_INFORMATIONAL_STRING_WIN32_SUBFAMILY_NAMES, - DWRITE_INFORMATIONAL_STRING_PREFERRED_FAMILY_NAMES, - DWRITE_INFORMATIONAL_STRING_PREFERRED_SUBFAMILY_NAMES, + DWRITE_INFORMATIONAL_STRING_TYPOGRAPHIC_FAMILY_NAMES, + DWRITE_INFORMATIONAL_STRING_TYPOGRAPHIC_SUBFAMILY_NAMES, DWRITE_INFORMATIONAL_STRING_SAMPLE_TEXT, DWRITE_INFORMATIONAL_STRING_FULL_NAME, DWRITE_INFORMATIONAL_STRING_POSTSCRIPT_NAME, - DWRITE_INFORMATIONAL_STRING_POSTSCRIPT_CID_NAME + DWRITE_INFORMATIONAL_STRING_POSTSCRIPT_CID_NAME, + DWRITE_INFORMATIONAL_STRING_WEIGHT_STRETCH_STYLE_FAMILY_NAME, + DWRITE_INFORMATIONAL_STRING_DESIGN_SCRIPT_LANGUAGE_TAG, + DWRITE_INFORMATIONAL_STRING_SUPPORTED_SCRIPT_LANGUAGE_TAG, + DWRITE_INFORMATIONAL_STRING_PREFERRED_FAMILY_NAMES = DWRITE_INFORMATIONAL_STRING_TYPOGRAPHIC_FAMILY_NAMES, + DWRITE_INFORMATIONAL_STRING_PREFERRED_SUBFAMILY_NAMES = DWRITE_INFORMATIONAL_STRING_TYPOGRAPHIC_SUBFAMILY_NAMES, + DWRITE_INFORMATIONAL_STRING_WWS_FAMILY_NAMES = DWRITE_INFORMATIONAL_STRING_WEIGHT_STRETCH_STYLE_FAMILY_NAME, } DWRITE_INFORMATIONAL_STRING_ID; typedef enum DWRITE_FONT_SIMULATIONS -- 2.24.1

Dec. 31, 2019

[PATCH] po: Fix typo in Catalan translation

by Alex Henrie

Signed-off-by: Alex Henrie <alexhenrie24(a)gmail.com> --- po/ca.po | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/po/ca.po b/po/ca.po index 7255f30d38..59c69ea6d3 100644 --- a/po/ca.po +++ b/po/ca.po @@ -5,7 +5,7 @@ msgstr "" "Project-Id-Version: Wine\n" "Report-Msgid-Bugs-To: https://bugs.winehq.org\n" "POT-Creation-Date: N/A\n" -"PO-Revision-Date: 2019-12-26 18:54-0700\n" +"PO-Revision-Date: 2019-12-31 11:39-0700\n" "Last-Translator: Alex Henrie <alexhenrie24(a)gmail.com>\n" "Language-Team: Catalan\n" "Language: ca\n" @@ -17115,7 +17115,7 @@ msgstr "" "[/A] Només copiar els fitxers amb l'atribut d'arxiu establert.\n" "[/M] Només copiar els fitxers amb l'atribut d'arxiu establert, elimina\n" "\tl'atribut d'arxiu.\n" -"[/K] Copiar els atributs de fitxer; sense això, no se preserven els\n" +"[/K] Copiar els atributs de fitxer; sense això, no es preserven els\n" " atributs.\n" "[/D | /D:m-d-y] Copiar els fitxers nous o els modificats després de la data\n" "\t\tproveïda.\n" -- 2.24.1

Dec. 31, 2019

Re: [PATCH 1/2] gdi32/tests: Don't treat a return value of COMPLEXREGION from IntersectClipRect() as broken.

by Zebediah Figura

On 12/30/19 8:12 PM, Dmitry Timoshkov wrote: > Zebediah Figura <z.figura12(a)gmail.com> wrote: > >> ret = IntersectClipRect(hdc, 0, 0, 50, 50); >> - if (ret == COMPLEXREGION) >> - { >> - /* XP returns COMPLEXREGION although dump_region reports only 1 rect */ >> - trace("Windows BUG: IntersectClipRect returned %d instead of SIMPLEREGION\n", ret); >> - /* let's make sure that it's a simple region */ >> - ret = GetClipRgn(hdc, hrgn); >> - ok(ret == 1, "GetClipRgn returned %d instead of 1\n", ret); >> - dump_region(hrgn); >> - } >> - else >> - ok(ret == SIMPLEREGION, "IntersectClipRect returned %d instead of SIMPLEREGION\n", ret); >> + todo_wine ok(ret == COMPLEXREGION, "wrong region type %d\n", ret); >> + ret = GetClipRgn(hdc, hrgn); >> + ok(ret == 1, "GetClipRgn returned %d instead of 1\n", ret); >> + ret = GetRegionData(hrgn, sizeof(buffer), rgndata); >> + ok(ret == sizeof(RGNDATAHEADER) + sizeof(RECT), "got %u\n", ret); >> + ok(rgndata->rdh.nCount == 1, "got %u rectangles\n", rgndata->rdh.nCount); > > Even if every Windows version returns broken result doesn't make it > legitimate to return COMPLEXREGION when the region contains only 1 > rectangle. This is clearly broken. > Windows does many things that are nonsensical, buggy, or contradicting their own documentation or other parts of the code. This seems nothing new. If sufficiently motivated one could even argue that a simple region is a special case of a complex region (I wouldn't actually be that surprised if such reasoning led a Windows programmer to just always return COMPLEXREGION because it was easier for them). Are we abandoning the idea of bug-for-bug compatibility now? I'm not arguing that we have to return COMPLEXREGION to satisfy the test (I certainly have no intention of writing such a patch), but our tests document the behaviour of Windows functions, not their documentation; that's why they exist.

Dec. 31, 2019

Re: win32 on macOS

by Vincent Povirk (they/them)

I'd guess the actual plan is to have winebuild generate the thunks based on a spec file.

Dec. 31, 2019

Re: [PATCH 1/2] gdi32/tests: Don't treat a return value of COMPLEXREGION from IntersectClipRect() as broken.

by Dmitry Timoshkov

Zebediah Figura <z.figura12(a)gmail.com> wrote: > ret = IntersectClipRect(hdc, 0, 0, 50, 50); > - if (ret == COMPLEXREGION) > - { > - /* XP returns COMPLEXREGION although dump_region reports only 1 rect */ > - trace("Windows BUG: IntersectClipRect returned %d instead of SIMPLEREGION\n", ret); > - /* let's make sure that it's a simple region */ > - ret = GetClipRgn(hdc, hrgn); > - ok(ret == 1, "GetClipRgn returned %d instead of 1\n", ret); > - dump_region(hrgn); > - } > - else > - ok(ret == SIMPLEREGION, "IntersectClipRect returned %d instead of SIMPLEREGION\n", ret); > + todo_wine ok(ret == COMPLEXREGION, "wrong region type %d\n", ret); > + ret = GetClipRgn(hdc, hrgn); > + ok(ret == 1, "GetClipRgn returned %d instead of 1\n", ret); > + ret = GetRegionData(hrgn, sizeof(buffer), rgndata); > + ok(ret == sizeof(RGNDATAHEADER) + sizeof(RECT), "got %u\n", ret); > + ok(rgndata->rdh.nCount == 1, "got %u rectangles\n", rgndata->rdh.nCount); Even if every Windows version returns broken result doesn't make it legitimate to return COMPLEXREGION when the region contains only 1 rectangle. This is clearly broken. -- Dmitry.

Dec. 31, 2019

Re: Wine Gecko 2.47.1 is not compatible with Python 2 or 3

by Jacek Caban

Hi Michael, On 23.12.2019 20:28, Michael Cronenworth wrote: > On 12/23/19 12:21 PM, Jacek Caban wrote: >> >> That was from my import, I missed the fact that it's too new to be in >> Git. You may just fetch and cherry-pick this commit from here: >> >> https://github.com/mozilla/gecko-dev/commit/4262e28d067edd239f96cb75a8280b9… >> > > Pip 8.1.1 is still using the deprecated call. > > ... > 0:03.19$<2> File > "/builddir/build/BUILD/wine-gecko-2.47.1/wine-gecko-2.47.1/python/virtualenv/virtualenv_support/pip-8.1.1-py2.py3-none-any.whl/pip/download.py", > line 93, in user_agent > 0:03.19$<2> zip(["name", "version", "id"], > platform.linux_distribution()), > 0:03.19$<2> AttributeError: module 'platform' has no attribute > 'linux_distribution' I just pushed fixes to git. master branch should work with Python 3.8. Please give it a try. Jacek

Dec. 31, 2019

Re: [PATCH] kernel32: Exclude IsBadStringPtrA() from relay traces.

by Marvin

Hi, While running your changed tests, 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=62689 Your paranoid android. === debian10 (32 bit Chinese:China report) === kernel32: debugger.c:320: Test failed: GetThreadContext failed: 5 debugger.c:320: Test failed: GetThreadContext failed: 5 === debian10 (32 bit WoW report) === kernel32: comm.c:918: Test failed: OutQueue should not be empty debugger: Timeout === debian10 (64 bit WoW report) === kernel32: comm.c:918: Test failed: OutQueue should not be empty

Dec. 30, 2019

Re: win32 on macOS

by Fabian Maurer

> Alexandre doesn't want an approach that requires the custom compiler in > upstream Wine, so we'll presumably eventually need another approach. I > think he basically wants to reduce the non-PE surface area far enough that > it becomes feasible to manually write thunks at the PE/host interface. > > I hope that answers your question. Yes it does, thank you! Another option would be to auto-generate the thunks through usage of libclang, that would be better than handwritten, IMHO. Regards, Fabian Maurer

Dec. 30, 2019

Re: Wine Gecko 2.47.1 is not compatible with Python 2 or 3

by Michael Cronenworth

On 12/30/19 6:03 PM, Jacek Caban wrote: > I just pushed fixes to git. master branch should work with Python 3.8. Please give > it a try. Those dozen patches got us past the Python scripts. The compile is crunching away. I suspect it will be OK. Thanks for the help. Happy new year.

Dec. 30, 2019