July 2023 - Wine-bugs - list.winehq.org

[Bug 34028] New: QuickBooks SS 2008 R1 fails to load due to licence error
by wine-bugs＠winehq.org 07 Jul '23

07 Jul '23

http://bugs.winehq.org/show_bug.cgi?id=34028 Bug #: 34028 Summary: QuickBooks SS 2008 R1 fails to load due to licence error Product: Wine Version: 1.6-rc5 Platform: x86-64 URL: http://download.microsoft.com/download/C/C/0/CC0BD555- 33DD-411E-936B-73AC6F95AE11/IE8-WindowsXP-x86-ENU.exe OS/Version: Linux Status: NEW Keywords: download Severity: minor Priority: P2 Component: msxml4 AssignedTo: wine-bugs(a)winehq.org ReportedBy: kennybobs(a)o2.co.uk Classification: Unclassified Created attachment 45219 --> http://bugs.winehq.org/attachment.cgi?id=45219 wine-1.6-rc5 console output QuickBooks SS 2008 R1 fails to load due to a "Could not initialize license properties" error. fixme:msxml:domdoc_setProperty Ignoring property L"NewParser", value {VT_I2: -1} fixme:msxml:domdoc_setProperty Ignoring property L"NewParser", value {VT_BOOL: ffffffff} [...] fixme:msxml:domdoc_get_parseError (0x1aa674)->(0x32f2dc): creating a dummy parseError Workaround is "winetricks msxml4". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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 9

[Bug 55153] New: comdlg32:filedlg sometimes crashes on Windows 7
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55153 Bug ID: 55153 Summary: comdlg32:filedlg sometimes crashes on Windows 7 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: comdlg32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com comdlg32:filedlg sometimes crashes on Windows 7: comdlg32:filedlg start dlls/comdlg32/tests/filedlg.c 0ef8:filedlg: unhandled exception c0000005 at 766523AD comdlg32:filedlg:0ef8 done (-1073741819) in 5s 56B See https://test.winehq.org/data/patterns.html#comdlg32:filedlg Where c0000005 == STATUS_ACCESS_VIOLATION The first crash happened on 2023-02-28 and there has been a bit over 1.5 per month since. -- 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 6

[Bug 55200] New: MSVC cl.exe misbehaving (buggy/inconsistent behaviour) wrt include paths since "ntdll: Default to Windows 10"
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55200 Bug ID: 55200 Summary: MSVC cl.exe misbehaving (buggy/inconsistent behaviour) wrt include paths since "ntdll: Default to Windows 10" Product: Wine Version: 8.1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: martin(a)martin.st Regression SHA1: 69154f0329aec4fb64886a0689da198b5323dcde Distribution: --- Background: I package MSVC with Wine wrapping, so that people can compile software using MSVC on Unix systems - see https://github.com/mstorsjo/msvc-wine. Since Wine 8.1, specifically commit 69154f0329aec4fb64886a0689da198b5323dcde "ntdll: Default to Windows 10", cl.exe in Wine started misbehaving with respect to how it finds headers in some include paths. The misbehaviour isn't entirely consistent and only appears in some fairly specific cases. (When compiling a project of the size of LLVM, with ~3000 compiled translation units, the bug appears in 3 of these translation units.) I've managed to reproduce the situation with a fairly minimal testcase. To reproduce, first install a fresh version of msvc-wine: $ git clone https://github.com/mstorsjo/msvc-wine $ cd msvc-wine $ ./vsdownload.py --dest $HOME/msvc2022-17.6 --accept-license $ ./install.sh $HOME/msvc2022-17.6 Then set up a minimal mock source project structure: $ mkdir -p msvc-include-bug/subdir $ touch msvc-include-bug/subdir/header.h $ echo '#include "subdir/header.h"' > msvc-include-bug/subdir/file.cpp Now test preprocessing file.cpp to see that it manages to find the header. Bypass the msvc-wine wrapper scripts and call it with wine manually: $ . $HOME/msvc2022-17.6/bin/x64/msvcenv.sh # Set up the INCLUDE/LIB/WINEDLLOVERRIDES env vars as necessary $ WINEDEBUG=-all wine64 $HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P -Fipreproc.cpp -I$(pwd)/msvc-include-bug/subdir -I$(pwd)/msvc-include-bug z:$(pwd)/msvc-include-bug/subdir/file.cpp Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64 Copyright (C) Microsoft Corporation. All rights reserved. file.cpp This runs successfully, as reference example. Now update file.cpp to include <corecrt_wio.h> before "subdir/header.h": $ echo '#include <corecrt_wio.h>' > msvc-include-bug/subdir/file.cpp $ echo '#include "subdir/header.h"' >> msvc-include-bug/subdir/file.cpp Rerun the same compilation command: $ . $HOME/msvc2022-17.6/bin/x64/msvcenv.sh $ WINEDEBUG=-all wine64 $HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P -Fipreproc.cpp -I$(pwd)/msvc-include-bug/subdir -I$(pwd)/msvc-include-bug z:$(pwd)/msvc-include-bug/subdir/file.cpp Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64 Copyright (C) Microsoft Corporation. All rights reserved. file.cpp z:/home/martin/msvc-include-bug/subdir/file.cpp(2): fatal error C1083: Cannot open include file: 'subdir/header.h': No such file or directory For some unknown reason, the extra set of headers included by <corecrt_wio.h> make cl.exe no longer find "subdir/header.h" even though -I$(pwd)/msvc-include-bug is passed to the compiler. The bug only appears when both $(pwd)/msvc-include-bug and $(pwd)/msvc-include-bug/subdir are added to the include path. $(pwd) expanding to an absolute unix path should be resolvable as an drive-relative (implicitly relative to z:) within Wine. Now if we clarify the include paths, that previously were set up as -I$(pwd)/... into fully absolute windows paths as -Iz:$(pwd)/..., then the test succeeds again: $ WINEDEBUG=-all wine64 $HOME/msvc2022-17.6/vc/tools/msvc/14.36.32532/bin/Hostx64/x64/cl.exe -P -Fipreproc.cpp -Iz:$(pwd)/msvc-include-bug/subdir -Iz:$(pwd)/msvc-include-bug z:$(pwd)/msvc-include-bug/subdir/file.cpp Microsoft (R) C/C++ Optimizing Compiler Version 19.36.32532 for x64 Copyright (C) Microsoft Corporation. All rights reserved. file.cpp Before the relevant Wine commit, this bug didn't appear at all in this case. It's probably easy to work around this issue within msvc-wine by rewriting -I arguments with absolute paths into Windows absolute paths like z:/... - but it's curious why this is needed now when it wasn't needed before, and MSVC cl.exe itself is acting very inconsistent here - it's only needed in this very precise setup. (For context, for future self: When compiling LLVM, this bug currently hits three files under llvm/lib/Target/AArch64/MCTargetDesc - AArch64WinCOFFObjectWriter.cpp, AArch64MCTargetDesc.cpp and AArch64TargetStreamer.cpp.) -- 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 0

[Bug 54135] New: JGlossator v5.0: Hovering textboxes not displaying
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=54135 Bug ID: 54135 Summary: JGlossator v5.0: Hovering textboxes not displaying Product: Wine Version: 8.0-rc1 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mshtml Assignee: wine-bugs(a)winehq.org Reporter: metcalsr(a)gmail.com Distribution: --- Created attachment 73666 --> https://bugs.winehq.org/attachment.cgi?id=73666 +mshtml Application features hover-over translations for text in the search box. This is not only an important QoL feature, but often provides alternative translations which aid significantly in understanding the text. These hovering boxes break under wine. -- 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 11

[Bug 55024] New: Sims 4 Studio window flickering
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55024 Bug ID: 55024 Summary: Sims 4 Studio window flickering Product: Wine Version: 8.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: ryu.ketsueki(a)outlook.com Distribution: --- This is something that was happening before for a while now but it was tolerable. Now it's unusable. Sims 4 Studio updated to the (Star) release, as in the 3.2.0.6 and it's actually usable now. The application doesn't freeze when trying to render anything 3D, which was apparently an issue on Sims 4 Studio itself, as even in a virtual machine, it had the exact same error. Could only get around it by a dual boot with Windows. Not anymore. Sims 4 Studio runs relatively well and I can create and modify game packages normally. That was until recently, when the flickering got so much worse. I'll explain what is happening. The window would hang frames for a bit and flicker them instead of completely update to the newest frame. Now it doesn't hang anymore. Instead, the window appears completely black, except when hovering over buttons or menus, when the window flash its content for a split second and goes black again. This is still on top of the flickering of before, so it still hangs frames but still goes black constantly, making the application unusable. Now, to my knowledge, Sims 4 Studio requires .NET 6.0 to launch at all. I had to install it to make it work, even when it was usable. Maybe this is related Mono or .NET itself, I don't know. I did observe a behavior that may be connected to what is going on. When the window is flashing black, the center of the window has a square showing the correct content but it's following the Windows 10/11 spinning wheel, so only this loading wheel shows correctly. The behavior persists even when the wheel is gone -- 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 55193] New: user32:sysparams - test_WM_DISPLAYCHANGE() fails on Windows 8
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55193 Bug ID: 55193 Summary: user32:sysparams - test_WM_DISPLAYCHANGE() fails on Windows 8 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:sysparams - test_WM_DISPLAYCHANGE() fails on Windows 8: sysparams.c:2473: Test failed: ChangeDisplaySettingsExW returned -1 sysparams.c:2504: Tests skipped: bpp 8: ChangeDisplaySettingsExW returned -1 sysparams.c:2504: Tests skipped: bpp 16: ChangeDisplaySettingsExW returned -1 sysparams.c:2505: Test failed: bpp 16: ChangeDisplaySettingsExW returned -1 sysparams.c:2504: Tests skipped: bpp 24: ChangeDisplaySettingsExW returned -1 sysparams.c:2505: Test failed: bpp 24: ChangeDisplaySettingsExW returned -1 sysparams.c:2523: Test failed: ChangeDisplaySettingsExW returned -1 See https://test.winehq.org/data/patterns.html#user32:sysparams Where -1 == DISP_CHANGE_FAILED (so not very helpful) This is systematic and impacts the two TestBot Windows 8 VMs. Also this check does not make sense: broken( DISP_CHANGE_FAILED && bpp == 8 ) and given that we get this res value for all bpps, maybe it should be: broken( res == DISP_CHANGE_FAILED ) -- 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 55195] New: wininet:http - test_http_connection() sometimes fails with a SENDING_REQUEST status on Windows
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55195 Bug ID: 55195 Summary: wininet:http - test_http_connection() sometimes fails with a SENDING_REQUEST status on Windows Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: wininet Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com wininet:http - test_http_connection() sometimes fails with a SENDING_REQUEST status on Windows: http.c:4126: Testing reading compressed content from cache http.c:376: Test failed: unexpected status 30 (INTERNET_STATUS_SENDING_REQUEST) http.c:376: Test failed: unexpected status 31 (INTERNET_STATUS_REQUEST_SENT) http.c:376: Test failed: unexpected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) http.c:376: Test failed: unexpected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) http.c:376: Test failed: unexpected status 50 (INTERNET_STATUS_CLOSING_CONNECTION) http.c:376: Test failed: unexpected status 51 (INTERNET_STATUS_CONNECTION_CLOSED) http.c:3665: Test failed: expected status 30 (INTERNET_STATUS_SENDING_REQUEST) 1 times, received 2 times http.c:3666: Test failed: expected status 31 (INTERNET_STATUS_REQUEST_SENT) 1 times, received 2 times http.c:3667: Test failed: expected status 40 (INTERNET_STATUS_RECEIVING_RESPONSE) 1 times, received 2 times http.c:3668: Test failed: expected status 41 (INTERNET_STATUS_RESPONSE_RECEIVED) 1 times, received 2 times http.c:5908: Testing InternetReadFileExW with IRF_ASYNC flag... See https://test.winehq.org/data/patterns.html#wininet:http Sometimes some of the 41, 50 and 51 status failures do not happen. These failures go back to at least 2022-11-29 and have happened a bit over once per month since, impacting all Windows versions. But there have been months with no failure too, and lately it has mostly been happening on Windows 8: * 2022-11-29 win22H2_fgtb-w10pro64-rx550-64 * 2023-03-10 win21H1_newtb-w10pro64-32 * 2023-03-20 win7_newtb-w7pro64-64 * 2023-03-28 win22H2_fgtb-w10pro64-32 * 2023-04-06 win7_newtb-w7u-pt-PT * 2023-04-28 win21H1_newtb-w10pro64-ru-64 * 2023-05-22 win21H1_newtb-w10pro64-fr-64 * 2023-06-08 win81_newtb-w8adm * 2023-07-04 win81_newtb-w864-64 * 2023-07-04 win81_newtb-w8 -- 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 1

[Bug 55192] New: user32:sysparams - test_SPI_SETWALLPAPER() fails to restore the '(None)' wallpaper
by WineHQ Bugzilla 05 Jul '23

05 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55192 Bug ID: 55192 Summary: user32:sysparams - test_SPI_SETWALLPAPER() fails to restore the '(None)' wallpaper 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:sysparams - test_SPI_SETWALLPAPER() fails to restore the '(None)' wallpaper: sysparams.c:2442: Test failed: ***warning*** failed to restore the original value: rc=0 err=2 sysparams.c:346: Test failed: Wrong value in registry: Control Panel\Desktop Wallpaper '' instead of '(None)' See https://test.winehq.org/data/patterns.html#user32:sysparams Where 2 == ERROR_FILE_NOT_FOUND This is systematic and specific to the w7u VM. The way I understand it that VM does not have a wallpaper but instead of returning the like of an empty string, SPI_GETDESKWALLPAPER returns '(None)' (maybe this is even the registry value). Anyway when we try to restore the value, SPI_SETDESKWALLPAPER checks that the '(None)' file exists and fails. To investigate: * Is '(None)' the actual registry value? * Do our other VMs really all have a wallpaper? Is that why none of them returns '(None)'? * If another Windows version has no wallpaper does SPI_GETDESKWALLPAPER return 'None' or is that specific to Windows 7? * To fix the test, check whether the oldvalue file exists and set the wallpaper to an empty string if not? Or bypass SPI_SETDESKWALLPAPER to set the registry directly in that case? -- 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 1

[Bug 55171] New: Wine app does not run on openSUSE Leap
by WineHQ Bugzilla 04 Jul '23

04 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=55171 Bug ID: 55171 Summary: Wine app does not run on openSUSE Leap Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: niltongmedeiros(a)gmail.com Distribution: --- The Wine app does not run on openSUSE Leap 15.5 KDE 5.103.0, does not appear in the menu, downloaded and installed from the Discover store. How can I proceed? -- 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 47067] New: Font is too wide in RPGMaker game Hello Charlotte
by wine-bugs＠winehq.org 04 Jul '23

04 Jul '23

https://bugs.winehq.org/show_bug.cgi?id=47067 Bug ID: 47067 Summary: Font is too wide in RPGMaker game Hello Charlotte Product: Wine Version: 4.6 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: dark.shadow4(a)web.de Distribution: --- Created attachment 64246 --> https://bugs.winehq.org/attachment.cgi?id=64246 Screenshot on Wine The font in the game is too wide, meaning long lines are cut off. Already tried winetricks allfonts, which doesn't help. To reproduce, just download the game, run Game.exe and click Start in the mainmenu. -- 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 6