wine-bugs March 2023

wine-bugs@winehq.org

1 participants
3414 discussions

[Bug 54149] New: shlwapi:ordinal - test_SHFormatDateTimeA() fails on the mixed locales configuration
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=54149 Bug ID: 54149 Summary: shlwapi:ordinal - test_SHFormatDateTimeA() fails on the mixed locales configuration Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: shlwapi Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- test_SHFormatDateTimeA() fails on the mixed locales configuration: ordinal.c:1765: Test failed: expected (mercredi 14 décembre 2022), got (mercredi 14 decembre 2022) ordinal.c:1773: Test failed: expected (mercredi 14 décembre 2022), got (mercredi 14 decembre 2022) ordinal.c:1787: Test failed: expected (mercredi 14 décembre 2022) got (mercredi 14 decembre 2022) for date part ordinal.c:1801: Test failed: expected (mercredi 14 décembre 2022) got (mercredi 14 decembre 2022) for date part See https://test.winehq.org/data/patterns.html#shlwapi:ordinal All was fine until 2022-12-09. Then on the 11th I let the TestBot rebuild the snapshot [1] to ensure that Internet time synchronization would be disabled to fix random failures in other tests. And on the 12th this test started failing: the date lost its e-acute! Yet the WineTest system information shows that none of the locale settings changed, not even the code page. Before and after they are: SystemDefaultLCID 0411 UserDefaultLCID 040c ThreadLocale 0411 SystemPreferredUILanguages 0412,0409 UserDefaultUILanguage 0412 ThreadUILanguage 0412 Country 231 ACP 932 The test did not change and the binary from the 9th has the same failure. So it is some obscure Windows setting that changed for some unknown reason. Furthermore given that the code page is 932 I would expect the plain 'e' to be the more correct result. Unfortunately there is no record of what the result was before the test started failing. Is it possible for SHFormatDateTimeA() and GetDateFormatA() to use different code pages? [1] It goes like this: that VM has a 'langs' powered-off snapshot with all the locales installed. This snapshot has not changed since 2022-04-24. From this the TestBot produces the 'langs-mx-MX-live' live snapshot using LibvirtTool.pl and SetWinLocale to change the locale settings. -- 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 45756] New: Button not clickable when dpi setting changed in Office 2007 Installer
by wine-bugs＠winehq.org 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=45756 Bug ID: 45756 Summary: Button not clickable when dpi setting changed in Office 2007 Installer Product: Wine Version: 3.15 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: ulrich.gemkow(a)ikr.uni-stuttgart.de Distribution: --- After upgrading from wine 3.14 to wine 3.15 (self-compiled, 32-bit-only) the push buttons in the office 2007 installer are no longer "clickable". When pushing them with the mouse, nothing happens. Using the keyboard to "push" the buttons works as before. Sometimes the mouse pointer is not even visible inside the installer window. This only happens when changing the screen resolution in winecfg (i.e. to 168 dpi). The windows version is set to Windows XP A bisect shows this commit as the first bad commit: commit 2068b73db5e19e1ce3b54b2a8ecb5a5b99ea19b5 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Aug 27 14:02:43 2018 +0200 user32: Process hardware messages in physical coordinates. 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.

2 10

[Bug 39113] New: SimplePC_SC.exe does not work
by wine-bugs＠winehq.org 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=39113 Bug ID: 39113 Summary: SimplePC_SC.exe does not work Product: Wine Version: unspecified Hardware: x86 URL: http://downloads.acs.com.hk/utility-tools/en/TOL-PCSC. zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: winscard Assignee: wine-bugs(a)winehq.org Reporter: vincent.hardy.be(a)gmail.com Distribution: --- Created attachment 52115 --> https://bugs.winehq.org/attachment.cgi?id=52115 screenshot SimplePC_SC is a programme that tests easily the basic functions of winscard with any smartcard. I file this bug in the hope that a friendly developer starts a real implementation of winscard. -- 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 8

[Bug 53728] New: "Escape from Tarkov" requires "DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME" in "DisplayConfigGetDeviceInfo" stub
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53728 Bug ID: 53728 Summary: "Escape from Tarkov" requires "DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME" in "DisplayConfigGetDeviceInfo" stub Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: user32 Assignee: wine-bugs(a)winehq.org Reporter: vinni5.2001(a)web.de Distribution: --- Created attachment 73161 --> https://bugs.winehq.org/attachment.cgi?id=73161 Attachments for this report. The video game "Escape from Tarkov" requires the "DISPLAYCONFIG_DEVICE_INFO_GET_TARGET_NAME" type to be implemented in the "DisplayConfigGetDeviceInfo" function (dlls/user32/sysparams.c). The game uses that to determine monitor names to list in the ingame settings menu. When it first introduced the use of that function, the lack of it in wine made the whole menu freeze, forcing you to kill the game. That freeze was worked around by the game developers on their end, since it also affected some Windows users, but parts of the issue still remain when running the game in wine. Monitor names in the monitor list in the settings menu are simply blank, making it hard to figure out which entry in the list corresponds to which monitor. See "eft_monitors_blank.png" in "attachments.tar.gz" for reference. Creating a quick and dirty patch to make wine return a string and pretend the function was executed successfully confirms it is using that function to get monitor names and the returned string shows up in the list. See "eft_monitors_names.png" and "dirty-monitor-name-workaround.patch" in "attachments.tar.gz" for reference. I should mention that in case other people wanna test the game, it is not free and makes use of the BattlEye anticheat software, so in order to launch the game with wine, it requires staging, a patch to load the Proton BattlEye Runtime (found here, for example: https://github.com/Frogging-Family/wine-tkg-git/tree/master/wine-tkg-git/wi…), as well as the Proton BattlEye Runtime itself (can be found and installed via Steam by Valve) and the necessary environment variable that points to the Proton BattlEye Runtime ("PROTON_BATTLEYE_RUNTIME"="/path/to/runtime"). It also needs "corefonts", "vcrun2019" and "dotnet48" installed via winetricks. I hope those requirements won't prevent this issue from being looked into, but if they do, I apologize. I was able to put together the quick and dirty patch to confirm it is indeed just a missing or incomplete function, however I lack the programming skills and low-level wine/windows knowledge to implement it properly. Thank you! -- 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 53176] New: KeePassXC needs Windows.Security.Credentials.KeyCredentialManager (UWP)
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=53176 Bug ID: 53176 Summary: KeePassXC needs Windows.Security.Credentials.KeyCredentialManager (UWP) Product: Wine Version: 7.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: comctl32 Assignee: wine-bugs(a)winehq.org Reporter: mk939(a)ymail.com Distribution: --- Created attachment 72622 --> https://bugs.winehq.org/attachment.cgi?id=72622 stdout and stderr from the terminal while launching the application KeePassXC 2.7.1 (64-bit, Windows) can no longer be started due to a new Windows Hello feature. Older versions prior to Feb 2022 will work as expected. I reproduced this issue on two different machines, each with Wine 7.11 (vanilla). Source code: https://github.com/keepassxreboot/keepassxc/blob/develop/src/winhello/Windo… Specifically, creating a stub for `IsSupportedAsync()` might suffice to disable the feature for this application, assuming a proper implementation on their side: https://github.com/keepassxreboot/keepassxc/blob/develop/src/winhello/Windo… PS: The error mentions "combase", but is not an available choice in the bug report selection box. I am sorry if the selected component is wrong. -- 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 37495] New: AusweisApp2 1.0.0 (german identity card app) needs winscard.SCardEstablishContext implementation
by wine-bugs＠winehq.org 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=37495 Bug ID: 37495 Summary: AusweisApp2 1.0.0 (german identity card app) needs winscard.SCardEstablishContext implementation Product: Wine Version: 1.7.30 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winscard Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, actually it needs much more - the revival of the Wine winscard project. Years ago there were multiple attempts to implement this using pcsc-lite but abandoned later. --- snip --- $ pwd /home/focht/.wine/drive_c/Program Files/AusweisApp2 1.0.0 $ WINEDEBUG=+tid,+seh,+relay,+winscard wine ./AusweisApp2.exe --show >>log.txt 2>&1 ... 0029:Call KERNEL32.OutputDebugStringW(01d52780 L"D ReaderManager::onThreadStarted(card/base/ReaderManager.cpp:130) : thread started\n") ret=6674f9f1 ... 0029:Call KERNEL32.OutputDebugStringW(01d53378 L"D ReaderManager::registerPlugIns(card/base/ReaderManager.cpp:242) : Try to register plugins\n") ret=6674f9f1 ... 0029:Call KERNEL32.OutputDebugStringW(01d543f8 L"D ReaderManager::registerPlugIns(card/base/ReaderManager.cpp:247) : Register plugin: QJsonObject({\"IID\":\"governikus.ReaderManagerPlugIn\",\"MetaData\":{\"dependencies\":[],\"name\":\"PcscReaderManagerPlugIn\"},\"className\":\"PcscReaderManagerPlugIn\",\"debug\":false,\"version\":328450}"...) ret=6674f9f1 ... 0029:Call KERNEL32.OutputDebugStringW(01d53bf8 L"D ReaderManager::onThreadStarted(card/base/ReaderManager.cpp:136) : Start plugin: governikus::PcscReaderManagerPlugIn\n") ret=6674f9f1 ... 0029:Call winscard.SCardEstablishContext(00000000,00000000,00000000,01d53260) ret=005015b8 0029:fixme:winscard:SCardEstablishContext (0,(nil),(nil),0x1d53260) stub 0029:Ret winscard.SCardEstablishContext() retval=80100001 ret=005015b8 ... 0029:Call KERNEL32.OutputDebugStringW(01d54868 L"W PcscReaderManagerPlugIn::start(card/pcsc/PcscReaderManagerPlugIn.cpp:70) : SCardEstablishContext: \"SCARD_F_INTERNAL_ERROR\"\n") ret=6674f9f1 ... 0029:Call KERNEL32.OutputDebugStringW(01d546f0 L"W PcscReaderManagerPlugIn::start(card/pcsc/PcscReaderManagerPlugIn.cpp:71) : Not started: Cannot establish context\n") ret=6674f9f1 ... --- snip --- Source: http://source.winehq.org/git/wine.git/blob/8d23d9cbdcc604d7c00e5a1201aac8af… --- snip --- 85 LONG WINAPI SCardEstablishContext(DWORD dwScope, LPCVOID pvReserved1, 86 LPCVOID pvReserved2, LPSCARDCONTEXT phContext) 87 { 88 FIXME("(%x,%p,%p,%p) stub\n", dwScope, pvReserved1, pvReserved2, phContext); 89 SetLastError(ERROR_CALL_NOT_IMPLEMENTED); 90 return SCARD_F_INTERNAL_ERROR; 91 } --- snip --- $ sha1sum AusweisApp2-1.0.0.msi d09f8c6f2cad0a089903a3e31bf96079ae3cfe59 AusweisApp2-1.0.0.msi $ du -sh AusweisApp2-1.0.0.msi 22M AusweisApp2-1.0.0.msi $ wine --version wine-1.7.30 Regards -- 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 19

[Bug 54584] New: kernel32:locale - The NtGetNlsSectionPtr() test fails on Windows 11
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=54584 Bug ID: 54584 Summary: kernel32:locale - The NtGetNlsSectionPtr() test fails on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com kernel32:locale - The NtGetNlsSectionPtr() test fails on Windows 11: locale.c:4978: Test failed: 14: failed 0 See https://test.winehq.org/data/patterns.html#kernel32:locale This means Windows 11 supports a new type of NLS section (14). Also NtGetNlsSectionPtr() returns success so presumably that section type does not take an id parameter. -- 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 54583] New: kernel32:locale - The non-breaking space GetNumberFormatEx() test fails on Windows 11
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=54583 Bug ID: 54583 Summary: kernel32:locale - The non-breaking space GetNumberFormatEx() test fails on Windows 11 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com kernel32:locale - The non-breaking space GetNumberFormatEx() test fails on Windows 11: locale.c:1820: Test failed: Expected L"-12\00a0345,00", got L"-12\202f345,00" See https://test.winehq.org/data/patterns.html#kernel32:locale So Windows 11 returns a narrow non-breaking space instead of a 'plain' non-breaking space separator when using the French format. The narrow non-breaking space is probably more correct. -- 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 54534] New: dbghelp:dbghelp - The test_loaded_modules() enumeration fails on Windows 10 1607
by WineHQ Bugzilla 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=54534 Bug ID: 54534 Summary: dbghelp:dbghelp - The test_loaded_modules() enumeration fails on Windows 10 1607 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: dbghelp Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com dbghelp:dbghelp - The test_loaded_modules() enumeration fails on Windows 10 1607: dbghelp.c:517: Test failed: SymLoadModuleExW failed on C:\WINDOWS\System32\bcryptPrimitives.dll: 0 See https://test.winehq.org/data/patterns.html#dbghelp:dbghelp This is the only Windows 10 version which fails. A bisect confirms that this failure was introduced by the commit below: 8be5c10ff893a22330ad94ae18dfb5fa497b09fd Author: Eric Pouech <eric.pouech(a)gmail.com> AuthorDate: Thu Feb 16 10:48:53 2023 +0100 dbghelp/tests: Add tests for 'module' name in EnumLoadedModules() callback. Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com> -- 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 43224] New: Freelist scan can result in O(n) time when allocating
by wine-bugs＠winehq.org 03 Mar '23

03 Mar '23

https://bugs.winehq.org/show_bug.cgi?id=43224 Bug ID: 43224 Summary: Freelist scan can result in O(n) time when allocating Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: ranma42(a)gmail.com Distribution: --- Created attachment 58517 --> https://bugs.winehq.org/attachment.cgi?id=58517 Micro-benchmark that shows the degenerate behaviour The heap implementation in ntdll can be very inefficient for some allocation patterns. Specifically, it is possible that a freelist contains thousands of entries of a given size and it is scanned while looking for a bigger entry, that will not fit in any of those. This is demonstrated by the attached program. It accepts a size as an argument and will allocate 1000000 elements of that size, deallocate half of them (the "even" ones), then allocate 1000 elements that are just one bit bigger. For most sizes the program terminates in milliseconds, but in my environment it takes several seconds for sizes 16, 32, 48, 64, 80, 88, 96, 112, 120, 128. A possible workaround (that I had implemented in the past, for short-lived applications) is to allocate from a freelist whose entries are all at least as big as the block that is being allocated, but that can cause inefficient memory usage. I noticed that wine includes an implementation of a red-black tree. Would it make sense to organise the free entries as lists in such a tree? That should ensure O(log N) in the worst case. If performance is a concern, it might be possible to use "direct" freelists for small sizes (ensuring that all of the alignment-compatible sizes are covered) and use a tree for bigger sizes. I am willing to work on this, but I need some directions on what is the best path forward (namely, if we should prefer the memory-inefficient but simpler approach of just allocating from "bigger" freelists or if the tree approach is the desired one). The bug https://bugs.winehq.org/show_bug.cgi?id=37773 might be related. -- 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-bugs March 2023