May 2022 - Wine-bugs - list.winehq.org

[Bug 45388] New: user32: edit fails on Traditional Chinese and Korean locales
by wine-bugs＠winehq.org 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=45388 Bug ID: 45388 Summary: user32:edit fails on Traditional Chinese and Korean locales Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- user32:edit fails with the following errors on Traditional Chinese and Korean locales: edit.c:1489: Test failed: 0: got 1, 1 edit.c:1510: Test failed: 0: got 1, 1 edit.c:1524: Test failed: 0: got 1, 1 edit.c:1538: Test failed: 0: got 1, 1 See: * Source matching the above https://source.winehq.org/git/wine.git/?a=blob;f=dlls/user32/tests/edit.c;h… * user32:edit WineTest failures https://test.winehq.org/data/tests/user32:edit.html The errors can be reproduced on the newtb-wvistau64-zh-cn TestBot VM, and also happen on fg-win7u64-1spie9-ko. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

2 3

[Bug 52771] New: Wine console creation breaks comctl32:button, dinput:keyboard, user32:dialog, user32:input, user32:monitor and user32:win
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52771 Bug ID: 52771 Summary: Wine console creation breaks comctl32:button, dinput:keyboard, user32:dialog, user32:input, user32:monitor and user32:win Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- The way Wine creates the window for console applications breaks comctl32:button, dinput:keyboard, user32:dialog, user32:input, user32:monitor and user32:win. https://test.winehq.org/data/patterns.html#comctl32:button https://test.winehq.org/data/patterns.html#dinput:keyboard https://test.winehq.org/data/patterns.html#user32:dialog https://test.winehq.org/data/patterns.html#user32:input https://test.winehq.org/data/patterns.html#user32:monitor https://test.winehq.org/data/patterns.html#user32:win These all started failing in Wine on 2022-03-17 with the commit below (also referenced in bug 52761): commit f034084d49b354811096524d472ae5172ac1cebf Author: Eric Pouech <eric.pouech(a)gmail.com> Date: Thu Mar 17 08:27:28 2022 +0100 kernelbase: Handle corner case in CreateProcess. In CreateProcess, if: - parent isn't attached to a console - CreateProcess's flag isn't set with DETACHED_PROCESS nor CREATE_NEW_CONSOLE - child is a CUI program then a console must be allocated for the child. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52048 Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> The way the TestBot starts the tests in Wine is this [1]: testagentd (Unix, no terminal) \- shell script (sh Unix, no terminal) \- WineTest.pl (perl Unix, no terminal) \- ./wine TestLauncher (Windows CUI, no console) \- unit test (Windows CUI) -> creates a console \- unit test can recurse upon itself (CUI) I will now try to summarize the current understanding of the issue from the wine-devel discussion [2], using the above figure as a reference: 1. testagentd is a daemon so it does not have an associated terminal. 2. When ./wine does not have a terminal it does not create a console window, even when starting a console application. This is so wine can be used for background (batch) tasks without requiring a X session or popping up windows all over the place. 3. But when a Windows application calls CreateProcess() without DETACHED_PROCESS, a console does get created. This is what happens when TestLauncher starts a unit test. 4. While the console object is created synchronously in the wineserver process, the actual window is created asynchronously (by wineconsole). This causes it to pop up while the unit test as already started, which confuses the tests that check the window hierarchy, the focus, etc. There are two ways the above differ from Windows: 1. I believe Windows creates both the console object and the matching window synchronously. So even if the console was created when starting the test unit there should be no failure. 2. On Windows the shell script is replaced by a batch script which triggers the console creation. So the console creation happens a bit earlier which could also mask any window creation delay. The reason why f034084d49b3 made a difference is that before Wine was not creating console windows. [1] More details on the different ways the TestBot starts the tests: https://www.winehq.org/pipermail/wine-devel/2022-April/212550.html [2] March: https://www.winehq.org/pipermail/wine-devel/2022-March/212330.html April: https://www.winehq.org/pipermail/wine-devel/2022-April/212513.html -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 52149] New: user32:dialog fails in test_DialogBoxParam() on current Windows 10 21H1
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52149 Bug ID: 52149 Summary: user32:dialog fails in test_DialogBoxParam() on current Windows 10 21H1 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com user32:dialog fails in test_DialogBoxParam() on current Windows 10 21H1: dialog.c:1854: Test failed: got 1407 https://test.winehq.org/data/patterns.html#user32:dialog So instead of failing with an error code of 0, the call below fails with ERROR_CANNOT_FIND_WND_CLASS... which makes sense? ret = DialogBoxParamA(GetModuleHandleA(NULL), "TEST_DIALOG_INVALID_CLASS", 0, DestroyDlgWinProc, 0); It's interesting to note that this failure did not happen on the initial Windows 10 21H1 test configurations (2021-08-23). As far as I can tell it's only after KB5006670 was applied (on 2021-10-21) that the test started failing. Unfortunately this is a cumulative update so it may not help narrow down the cause very much. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 52362] New: Powershell Core 7 installer hangs forever on Chinese locale (LC_ALL=zh_Han.UTF-8)
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52362 Bug ID: 52362 Summary: Powershell Core 7 installer hangs forever on Chinese locale (LC_ALL=zh_Han.UTF-8) Product: Wine Version: 7.0-rc3 Hardware: x86-64 URL: https://github.com/PowerShell/PowerShell/releases/down load/v7.1.5/PowerShell-7.1.5-win-x64.msi OS: Linux Status: NEW Keywords: download Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: --- Hi, someone i was trying to help someone to get this installed and he reported this to me (I couldn`t reproduce it), that the installer hung for him, and in fact he found that it was due to the fact he was running with LC_ALL=zh_Han.UTF-8 I don`t know anything about these chinese locales, but report anyway as could be a bug in wine (?). reproduce: LC_ALL=zh_Han.UTF-8 5ine msiexec /i PowerShell-7.1.5-win-x64.msi A +relay shows it`s looking for files in directory zh-CN which is not there, though there is zn-Han(s) directories. But just copying zh-Han to zh-CN didn`t help either. Anyway, I guess someone with more knowledge about (Chinese) locales would have lots more clues than i have... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 52743] New: regression cannot write to _fdopen'ed stdout
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52743 Bug ID: 52743 Summary: regression cannot write to _fdopen'ed stdout Product: Wine Version: 7.5 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: xantares09(a)hotmail.com Distribution: --- since wine 7.2, opening stdout with _fdopen and printing into it crashes ``` #include <stdio.h> #include <io.h> #include <fcntl.h> int main() { FILE * m_stdout = _fdopen(_fileno(stdout), "wb"); fprintf(m_stdout, "foo\n"); fclose(m_stdout); return 0; } $ x86_64-w64-mingw32-gcc main.c $ wine a.exe ... wine: Unhandled page fault on read access to 0000000000000050 at address 0000000170059685 (thread 0128), starting debugger... ... ``` For context, this is what qt-xmlpatterns does: https://github.com/qt/qtxmlpatterns/blob/dev/tools/xmlpatterns/main.cpp#L184 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 52869] New: kernel32:locale - test_CompareStringA() fails in Wine in Hindi
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52869 Bug ID: 52869 Summary: kernel32:locale - test_CompareStringA() fails in Wine in Hindi Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- test_CompareStringA() started failing in Wine in Hindi recently: locale.c:1884: Test failed: expected CSTR_LESS_THAN, got 2 locale.c:1886: Test failed: expected CSTR_GREATER_THAN, got 2 https://test.winehq.org/data/patterns.html#kernel32:locale A bisect shows this failure started with the commit below: commit 8993e15cfa5b77ac2487239354ffe63bbc5e562d Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Apr 11 17:21:47 2022 +0200 kernelbase: Support UTF-7/8 codepages in get_codepage_table(). Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 52922] New: The Evil Within crashes before entering the main menu using Vulkan renderer
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52922 Bug ID: 52922 Summary: The Evil Within crashes before entering the main menu using Vulkan renderer Product: Wine Version: 7.7 Hardware: x86-64 OS: Linux Status: NEW Keywords: regression Severity: normal Priority: P2 Component: directx-d3d Assignee: wine-bugs(a)winehq.org Reporter: andrey.goosev(a)gmail.com CC: z.figura12(a)gmail.com Regression SHA1: e7d86d9c6e58e8e133c606099615b0d9e7940132 Distribution: --- wine: Unhandled page fault on read access to 00007F3B54255B28 at address 00007F32CDDE5A09 (thread 0740), starting debugger... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 52887] New: Get-Computerinfo from NoPowershell crashes
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52887 Bug ID: 52887 Summary: Get-Computerinfo from NoPowershell crashes Product: Wine Version: 7.7 Hardware: x86-64 URL: https://github.com/bitsadmin/nopowershell/releases/tag /1.23 OS: Linux Status: NEW Keywords: dotnet, download Severity: normal Priority: P2 Component: wmi&wbemprox Assignee: wine-bugs(a)winehq.org Reporter: xerox.xerox2000x(a)gmail.com Distribution: --- Created attachment 72275 --> https://bugs.winehq.org/attachment.cgi?id=72275 patch NoPowershell.exe provides a number of commandlets without the need to install it(https://github.com/bitsadmin/nopowershell/releases/tag/1.23). Prerequisite: winetricks -q dotnet48 The commandlet Get-Computerinfo acts as replacement of systeminfo.exe Source: https://github.com/bitsadmin/nopowershell/blob/master/Source/NoPowerShell/C… Currently fails with: Get-ComputerInfo : System.ArgumentOutOfRangeException: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index at System.ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument argument, ExceptionResource resource) at NoPowerShell.Commands.Management.GetComputerInfo.Execute(CommandResult pipeIn) at NoPowerShell.Program.Main(String[] args) Attached patch fixes it, to run into next bug . Next bugs are some missing props from various classes. After adding them (albeit quickly with some hacks) the cmdlet runs. I attach first three patches, rest follows later. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 52847] New: GetACP() returns CP_UTF8 on some debian VM
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=52847 Bug ID: 52847 Summary: GetACP() returns CP_UTF8 on some debian VM Product: Wine Version: 7.6 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: eric.pouech(a)orange.fr Distribution: --- wine's tests in kernel32/tests/process.c fail on some Debian VM (Dhivehi:Maldives and Hindi:India) debugging it shows: - conhost (in window.c) aborts at startup because TranslateCharsetInfo( GetACP() ...) fails in Wine - both locale return CP_UTF8 from GetACP() - testing on windows vm (Hindi), show that GetACP() returns 1252 CP - moreover, testing on Win11 TranslateCharsetInfo( CP_UTF8 ) succeeds returning the Win11 values for CP_UTF8 in TranslateCharsetInfo let the kernel32:process run "correctly" (ie no longer showing the specific errors related to TranslateCharsetInfo) -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 48045] New: comdlg32:filedlg crashes or times out randomly
by WineHQ Bugzilla 06 May '22

06 May '22

https://bugs.winehq.org/show_bug.cgi?id=48045 Bug ID: 48045 Summary: comdlg32:filedlg crashes or times out randomly Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: comdlg32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 65586 --> https://bugs.winehq.org/attachment.cgi?id=65586 comdlg32:filedlg: Traces to debug random crash / timeouts. comdlg32:filedlg crashes randomly on all Windows versions from Vista to Windows 8 while Windows 10 (at least 1507, 1709 and 1809) gets random timeouts. https://test.winehq.org/data/tests/comdlg32:filedlg.html When successful comdlg32:filedlg does not print much so the standard reports are pretty much useless to spot the place where the test gets stuck on Windows 10, assuming it gets stuck in a specific place rather than just being slow. As for the crashes, they don't trigger the tests exc_filter() so there is no indication of the last successful ok() call. Turning on 'Report successful tests' may be preventing the crash (or these runs just got lucky). It's possible to reproduce the crash while adding the traces in the attached patch. This is not entirely fruitful as the crashes don't seem to always happen in the same place. test_extension() is the place where most issues happen though: https://testbot.winehq.org/JobDetails.pl?Key=59060 -> wvistau64: Crash in test_extension(). Based on the test_extension_helper() traces, it happened in the loop with i=1 so for "TestFilter (*.abc;)\0*.abc;\0". https://testbot.winehq.org/JobDetails.pl?Key=59086 -> w2008s64+exe: Crash on or after test_extension() return https://testbot.winehq.org/JobDetails.pl?Key=59088 -> wvistau64+exe: Crash in test_DialogCancel() https://testbot.winehq.org/JobDetails.pl?Key=59091 -> wvistau64_fr: Spent 39s in test_null_filename() but no timeout https://testbot.winehq.org/JobDetails.pl?Key=59139 -> wvistau64: Crash in test_null_filename() -> wvistau64_fr: Timeout in test_extension() filedlg.c:1048: filter=[TestFilter (*.ab?) lpstrDefExt=NULL] https://testbot.winehq.org/JobDetails.pl?Key=59151 -> wvistau64: Crash in test_extension() filedlg.c:1048: filter=[TestFilter (*.abc.def)] -> wvistau64_fr: Timeout in or after test_mru() filedlg.c:637: 19 test_ok filedlg.c:904: 29 test_getfolderpath filedlg.c:986: 30 test_mru -> w1064v1809_zh_CN: Two failures in test_extension() filedlg.c:1053: Test failed: TestFilter (*.pt*;*.abc): expected TRUE filedlg.c:1059: Test failed: TestFilter (*.pt*;*.abc): Filename is deadbeef, expected deadbeef.xyz Memory corruption, maybe happening quite early in the test? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.

1 3