November 2022 - Wine-Bugs - list.winehq.org

[Bug 53770] New: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls )
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53770 Bug ID: 53770 Summary: [ nls cause BUG ] local.nls should must be update (./wine/nls/local.nls ) Product: Wine Version: 7.18 Hardware: x86 OS: other Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com In China, there is a popular student software called DingTalk, in which the APP reads the sNativeDigits value in the registry (/HKEY_USERS/S-X-XX-XX/Control Panel International -> sNativeDigits) during getting the meeting time. Through research, I found that This value is obtained by the function get_locale_info, and the specific location is as follows: > case LOCALE_SNATIVEDIGITS: > if ((ret = locale_return_reg_string( &entry_scurrency, type, buffer, len )) != -1) return ret; > return locale_return_string( locale->scurrency, type, buffer, len ); Now, in wine7.12 to 7.18, for the Chinese environment (LOCALE_SNATIVEDIGITS), the sNativeDigits read from local.nls is "零一二三四五六七八九", but this is unreasonable, I checked the Windows10 registry and found that its value should be It is "0123456789" And if it is "零一二三四五六七八九", the program will have an error > The timer is displayed as Chinese characters, and the actual display of "一" is not "一" but "《", it's so strange , so I think we should update local.nls or modify the get_locale_info function. *** update local.nls：*** I would like to ask how the local.nls in wine is generated, is it directly used in windows? I once wanted to modify local.nls directly to fix this problem, but it seems to be a binary file, and I don't know how it is generated in wine, so I I don't know how to modify local.nls by myself. [HELP] If you have time, I would like to ask how the nls file is generated in wine *** modify the get_locale_info function：*** I have completed the modification of the function (assignment in the Chinese environment, other environments do not operate), if you need I can provide the source code directly. ————————— I hope that I can ask about the modification of the nls file, and complete the modification through my own efforts, so that I can also join the big project of wine, which is meaningful and interesting to me. Thanks very much, Looking forward to your reply。 Yous: SvenL -- 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 37

[Bug 53857] New: [ fontconfig ] Questions about some font selection logic
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53857 Bug ID: 53857 Summary: [ fontconfig ] Questions about some font selection logic Product: Wine Version: unspecified Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: win32u Assignee: wine-bugs(a)winehq.org Reporter: 399989567(a)qq.com Distribution: --- Created attachment 73387 --> https://bugs.winehq.org/attachment.cgi?id=73387 Simsun Test My application uses "宋体" （Simsun） as the font of choice，which use WindowsAPI > SelectObject(hdc,hfont) When I set the property(lfPitchAndFamily) of "宋体" to 0x22(FF_SWISS) and 0x36(FF_MODERN), wine converts "宋体" into Noto Sans CJK SC and Noto Sans Mono CJK SC respectively. I looked at the source code because "宋体" is not installed on my computer, so when wine doesn't find any fonts, wine end up calling "find_any_face" API and entering the first loop, using "enum_fallbacks" API to find the fonts. When i > 3, which means the fonts in the default_fixed_list are not suitable,Wine uses "fontconfig_enum_family_fallbacks" API to find fonts through fontconfig. Here wine determines which type of font the "宋体" belongs to (serif, sans-serif, monospaced) based on the "lfPitchAndFamily" attribute of the "宋体". So ended up returning a different font: > FF_SWISS -> fc-match "sans" -> Noto Sans CJK SC > FF_MODERN -> fc-match "mono" -> Noto Sans Mono CJK SC But it's not what I expected, I want "宋体" to return Noto Sans CJK SC forever,and on my computer when I use ' $ fc-match "宋体" ', it returns "Noto Sans CJK SC". I konw "宋体" became "Noto Sans Mono CJK SC" is becaues wine design. But, I would like to ask why not directly use fontconfig to find fonts according to the font name in the "fontconfig_enum_family_fallbacks" function, but to search according to the font type. ues fc-match "fontname" instead of fc-match "sans or mono or serif" Is it because using fontconfig is a very resource-intensive thing, so wine divides the fonts into three types, and stores the results of the three fonts in the cache, so that the cache can be directly read the next time it is called? I don't know if my description is correct, feel free to contact me if you have any questions ———————————— export LC_ALL=zh_CN.UTF-8 and run my exe file the first line is "宋体" 0x36 -> became Mono the second line is "宋体" 0x22 -> became Sans Don't mind the third and fourth lines -- 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 53813] New: Let's encrypt certificate validation fails
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53813 Bug ID: 53813 Summary: Let's encrypt certificate validation fails Product: Wine Version: 7.19 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: crypt32 Assignee: wine-bugs(a)winehq.org Reporter: panard(a)inzenet.org Distribution: --- Created attachment 73329 --> https://bugs.winehq.org/attachment.cgi?id=73329 WINEDEBUG=-all,cryptnet,cryptasn,wininet,chain of .NET application The .NET application "Magic Online" fails to validate the certificate of mtgologin1.mtgo.com:7770, which prevents login (the app thinks it is in maintenance mode due to the connection error). The certificate of mtgologin1.mtgo.com:7770 seems valid, however. It is issued by Let's encrypt. Certificate chain is 0 s:CN = *.mtgo.com i:C = US, O = Let's Encrypt, CN = R3 1 s:C = US, O = Let's Encrypt, CN = R3 i:C = US, O = Internet Security Research Group, CN = ISRG Root X1 2 s:C = US, O = Internet Security Research Group, CN = ISRG Root X1 i:O = Digital Signature Trust Co., CN = DST Root CA X3 >From the log, the issue seems related to the verification of the revocation status with OCSP on http://r3.o.lencr.org, with a warning on an invalid tag in CRYPT_AsnDecodeResponderID. I join the log with WINEDEBUG=-all,cryptnet,cryptasn,wininet,chain where I just kept the relevant cryptasn part. The main path of error seems the following: 0220:trace:cryptnet:verify_cert_revocation_from_aia_ext OCSP URL = L"http://r3.o.lencr.org" 0220:trace:wininet:HTTP_GetResponseHeaders version [L"HTTP/1.1"] status code [L"200"] status text [L"OK"] 01a4:warn:cryptasn:CRYPT_AsnDecodeResponderID Unexpected tag 30 0220:trace:cryptnet:verify_cert_revocation verify_cert_revocation_from_aia_ext() returned 8009310b 0220:trace:cryptnet:verify_cert_revocation no CRL found 0220:trace:cryptnet:verify_cert_revocation verify_cert_revocation_from_aia_ext() returned 80092012 0220:trace:chain:CertGetCertificateChain error status: 01000040 -- 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 8

[Bug 53679] New: The 64-bit ntdll:env fails on Windows 7
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53679 Bug ID: 53679 Summary: The 64-bit ntdll:env fails on Windows 7 Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The 64-bit ntdll:env fails on Windows 7: env.c:340: Test failed: wrong buffer 77c/77c env.c:341: Test failed: wrong buffer 794/792 env.c:342: Test failed: wrong buffer 7ac/7aa env.c:344: Test failed: wrong buffer 7b4/7b2 https://test.winehq.org/data/patterns.html#ntdll:env A bisect shows the commit below is responsible for these failures: commit 5d99b2a32c2d679aa2bc47ef6e087aeb29a33e5f Author: Alexandre Julliard <julliard(a)winehq.org> Date: Fri Sep 9 15:10:57 2022 +0200 ntdll/tests: Remove workarounds for old Windows versions. I have not been informed that Windows 7 is no longer part of the Windows versions we care about so I assume this is an unintended side effect of the patch. -- 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 53552] New: Line width calculation failure in WineMono.Tests.System.Windows.Media.TextFormatting.TextFormatterTest.NewlineCharacterCollapsibleTest
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53552 Bug ID: 53552 Summary: Line width calculation failure in WineMono.Tests.System.Windows.Media.TextFormatting.Tex tFormatterTest.NewlineCharacterCollapsibleTest Product: Wine Version: 7.14 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: dwrite Assignee: wine-bugs(a)winehq.org Reporter: conmanx360(a)gmail.com Distribution: --- Somewhere between the release of Wine Mono 7.3.0 and Wine 7.14 the WineMono.Tests.System.Windows.Media.TextFormatting.TextFormatterTest.NewlineCharacterCollapsibleTest test began failing with: 1) NewlineCharacterCollapsibleTest (WineMono.Tests.System.Windows.Media.TextFormatting.TextFormatterTest.NewlineCharacterCollapsibleTest) line.Width Expected: 206.31333333333333d But was: 302.31333333333333d I'm assuming this is dwrite related, but I could be wrong on that. -- 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 19

[Bug 53437] New: Windows program (ZOSICloud.exe) ran great under an earlier version, but now crashes
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=53437 Bug ID: 53437 Summary: Windows program (ZOSICloud.exe) ran great under an earlier version, but now crashes Product: Wine Version: 7.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: major Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: david(a)depowell.com Distribution: --- Created attachment 72817 --> https://bugs.winehq.org/attachment.cgi?id=72817 Console output when program is run I have a program, called ZOSICloud.exe, that I installed on my Ubuntu Focal Fossa (20.04) laptop about six months ago to monitor my security cameras. It ran perfectly under WINE, but I honestly don't know what version of WINE I was running. For some reason, my WINE installation disappeared, perhaps during an update. I haven't a clue why. So I reinstalled it using apt. The installation went well, but I wound up with version 5.0 of WINE. Most of my other Windows programs would run, but a lot of useful functionality (e.g., printing) was missing. ZOSICloud.exe would not run at all, just crash immediately. I uninstalled WINE 5.0 and installed version 7.0 by following the instructions on the winehq.org web site. This restored the missing functionality in my other Windows programs, but ZOSICloud.exe still crashes when I try to launch it. I have reinstalled ZOSICloud.exe several times, using both the default (64-bit) wineprefix and in a 32-bit wineprefix (I don't know how to tell if ZOSICloud.exe is 64- or 32-bit), but it won't run either way. The application (ZOSICloud.exe) can be downloaded from https://s3.amazonaws.com/ansjerfilemanager/ZOSICloud_3.0.1.2.exe Note that the desktop link it creates is incorrect; it runs a program called "test_link.exe" instead of "ZOSICloud.exe". -- 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 52648] New: conhost.exe:tty test_read_console_control() fails in Hindi and Portuguese
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=52648 Bug ID: 52648 Summary: conhost.exe:tty test_read_console_control() fails in Hindi and Portuguese Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: programs Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com conhost.exe:tty test_read_console_control() fails on Windows in Hindi and Portuguese: tty.c:1365: Test failed: keyboard state: got 8, expected 18 https://test.winehq.org/data/patterns.html#conhost.exe:tty This can be reproduced on w10pro64-hi, w10pro64-pt-BR and w10pro64-pt-PT but does not fail in the other locales. This failure started when these tests were added: commit 89a8b32d7a976504ee98ba1a7d08574bc9bc00e6 Author: Eric Pouech <eric.pouech(a)gmail.com> AuthorDate: Tue Mar 1 09:26:08 2022 +0100 conhost/tests: Add tests for ReadConsoleW with control. 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> -- 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 51775] New: Axiom Verge 2 crashes on startup due to incomplete sapi implementation
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=51775 Bug ID: 51775 Summary: Axiom Verge 2 crashes on startup due to incomplete sapi implementation Product: Wine Version: 6.17 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: sapi Assignee: wine-bugs(a)winehq.org Reporter: leslie_alistair(a)hotmail.com Distribution: --- This game initializes sapi, even though it doesn't appear to use it at all. It appears from the .NET backtrace, that speechsynthesizer.SetOutputTotDefaultAudioDevice is at fault. After playing around, we can reproduce the crash in a C# application with the following lines ... System.Speech.Synthesis.SpeechSynthesizer synth = new SpeechSynthesizer(); synth.SetOutputToDefaultAudioDevice(); ... Function SetOutputToDefaultAudioDevice, requires that basic iteration and a few registry values are in place. -- 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 51529] New: CloseHandle(INVALID_HANDLE_VALUE) returns FALSE, GetLastError is ERROR_INVALID_HANDLE
by WineHQ Bugzilla Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=51529 Bug ID: 51529 Summary: CloseHandle(INVALID_HANDLE_VALUE) returns FALSE, GetLastError is ERROR_INVALID_HANDLE Product: Wine Version: 5.0 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: sergey.bychkow(a)gmail.com Distribution: --- Created attachment 70368 --> https://bugs.winehq.org/attachment.cgi?id=70368 Test CloseHandle(INVALID_HANDLE_VALUE) CloseHandle(INVALID_HANDLE_VALUE) returns FALSE, GetLastError is ERROR_INVALID_HANDLE on Wine. I tried it with MacOSX and Linux. But on Windows CloseHandle(INVALID_HANDLE_VALUE) returns TRUE. So many programs could fail if they didn't expect FALSE here. Test case (Pascal). Can be compiled with FPC or Delphi. // file TestCloseHandle.lpr program TestCloseHandle; {$APPTYPE CONSOLE} uses //Winapi.Windows; Windows; var aHandle: THandle; aResult: HRESULT; begin //aHandle := 0; aHandle := INVALID_HANDLE_VALUE; if CloseHandle(aHandle) then aResult := 0 else aResult := GetLastError; Writeln('Result: ', aResult); end. -- 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 38604] New: winedbg: internal crash when valgrinding ieframe/tests/ie.c with pdb debug symbols
by wine-bugs＠winehq.org Nov. 2, 2022

Nov. 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=38604 Bug ID: 38604 Summary: winedbg: internal crash when valgrinding ieframe/tests/ie.c with pdb debug symbols Product: Wine Version: 1.7.43 Hardware: x86 OS: Linux Status: NEW Keywords: download, source, testcase, valgrind Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: austinenglish(a)gmail.com Distribution: --- Created attachment 51499 --> https://bugs.winehq.org/attachment.cgi?id=51499 log See also bug 38594 for a similar issue, though this one causes winedbg to crash. Log is attached. -- 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 5