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

[Bug 52864] New: windows.media.speech:speech has a refcount failure on all Windows 10 versions
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=52864 Bug ID: 52864 Summary: windows.media.speech:speech has a refcount failure on all Windows 10 versions Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com windows.media.speech:speech fails on all Windows 10 versions: speech.c:968: Test failed: Unexpected refcount 2, expected 1 https://test.winehq.org/data/patterns.html#windows.media.speech:speech This failure is present on all Windows 10 versions except the 1809 and 1909 ones, but probably just because these turn out not to have speech support for English for some reason. So they just skip the test: speech.c:877: SpeechRecognizer default language L"en-US". speech.c:1110: Tests skipped: Could not init SpeechRecognizer with default language! Unsurprisingly a bisect shows that the failures started with the commit that introduced this new test: commit 4926bb148b049f1b60e57091f4aa87a3957aa69e Author: Bernhard Kölbl <besentv(a)gmail.com> Date: Wed Apr 6 18:28:41 2022 +0200 windows.media.speech: Add tests for IAsyncOperation. Signed-off-by: Bernhard Kölbl <besentv(a)gmail.com> Signed-off-by: Rémi Bernon <rbernon(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 3

[Bug 52861] New: kernel32:locale fails on Windows 10 1709
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=52861 Bug ID: 52861 Summary: kernel32:locale fails on Windows 10 1709 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 fails on Windows 10 1709: locale.c:4216: Test failed: failed 0 https://test.winehq.org/data/patterns.html#kernel32:locale This impacts all the Windows 1709 machines but no other Windows version. This is also a new test which was introduced by the commit below: commit b5561c8bba9a613c53ae4669c4adb7450e5f458d Author: Alexandre Julliard <julliard(a)winehq.org> AuthorDate: Wed Mar 23 11:02:57 2022 +0100 ntdll: Support UTF-8 codepage in RtlInitCodePageTable(). 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 3

[Bug 51460] New: oleaut32:vartest has a todo because Wine uses an outdated currency symbol for Swiss Francs
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=51460 Bug ID: 51460 Summary: oleaut32:vartest has a todo because Wine uses an outdated currency symbol for Swiss Francs Product: Wine Version: 6.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- Wine uses uses "SFr." as the currency symbol for Swiss francs instead of "CHF". According to Wikipedia: "The use of SFr. for Swiss Franc and fr.sv. are outdated" and are not recognized as correct by the "Secrétariat d'État à l'économie". https://en.wikipedia.org/wiki/Swiss_franc This forces the use of a todo in oleaut32:vartest: lcid = MAKELCID(MAKELANGID(LANG_FRENCH,SUBLANG_FRENCH_SWISS),SORT_DEFAULT); WCONVERT(L"3CHF", NUMPRS_CURRENCY|NUMPRS_USE_ALL); todo_wine EXPECT(1,NUMPRS_CURRENCY|NUMPRS_USE_ALL,NUMPRS_CURRENCY,4,0,0); And it may cause oleaut32:varformat to fail when run in a Swiss locale. The "SFr." currency symbol comes from nls/(de|fr|it)s.nls which are generated from Unicode tables by tools/make_unicode so it's not clear how to fix them. -- 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 52866] New: vbscript:run fails in Wine in Arabic and Hebrew
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=52866 Bug ID: 52866 Summary: vbscript:run fails in Wine in Arabic and Hebrew Product: Wine Version: unspecified Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: vbscript Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- vbscript:run fails in Wine in Arabic and Hebrew: run.c:1888: Test failed: unexpected call OnScriptError run.c:2933: Test failed: expected global_success_d run.c:2934: Test failed: expected global_success_i run.c:2936: Test failed: parse_script failed: 800a000d run.c:1204: Test failed: api.vbs: L"Err.number = 13" run.c:1204: Test failed: api.vbs: L"Err.number = 13" run.c:1874: Error in line 1162: 0 L"Type mismatch" run.c:1888: Test failed: unexpected call OnScriptError run.c:2933: Test failed: expected global_success_d run.c:2934: Test failed: expected global_success_i run.c:2936: Test failed: parse_script failed: 800a000d https://test.winehq.org/data/patterns.html#vbscript:run Incidentally these are our two right-to-left test locales so this may be related. A bisect shows that the failures started with this commit: commit ba43e4cfca97a9bba3e6575af82acbf011685862 Author: Alexandre Julliard <julliard(a)winehq.org> Date: Tue Mar 29 22:11:32 2022 +0200 kernelbase: Reimplement number formatting values in GetLocaleInfoW/Ex using the locale.nls data. 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 8

[Bug 52857] New: msvcp140:msvcp140 fails in Windows 8.1 on the cw-rx460 machine
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=52857 Bug ID: 52857 Summary: msvcp140:msvcp140 fails in Windows 8.1 on the cw-rx460 machine Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: msvcp Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com msvcp140:msvcp140 fails in Windows 8.1 on the cw-rx460 machine msvcp140.c:1617: Test failed: Got unexpected err 87. msvcp140.c:1622: Test failed: Got unexpected err 87. https://test.winehq.org/data/patterns.html#msvcp140:msvcp140 These are new tests so unsurprisingly the failures are caused by the commit that introduced them: commit d72d596070eb28fd5f747fb6120d36f66ff93bec Author: Paul Gofman <pgofman(a)codeweavers.com> Date: Mon Apr 11 21:44:35 2022 +0300 msvcp140: Implement _Copy_file(). Signed-off-by: Paul Gofman <pgofman(a)codeweavers.com> Signed-off-by: Piotr Caban <piotr(a)codeweavers.com> Signed-off-by: Alexandre Julliard <julliard(a)winehq.org> The fact that only this specific Windows 8.1 configuration fails makes sense because it is the only one to have msvcp140 and it is a relatively old version: it is installed by the Radeon driver. However: * The w7u VM does have (a much newer) msvcp140 and has no failure. * The w1064v1607 VM has the same msvcp140 version and has no failure either. Furthermore kernel32:file also fails in the same way in the same configuration and shouldn't depend on msvcp140. So it's possible the issue is not related to msvcp140 at all. Here is a summary of the msvcp140 versions on the Windows 7, 8.1 and older Windows 10 machines: Win Machine msvcp140 win7 w7u 14.29.30037.0 win7 w7pro64 missing (at least for 64-bit) win81 cw-gtx560 missing win81 cw-rx460 14.0.23026.0 win81 w8 missing win81 w864 missing win1507 cw-gtx560 missing win1507 cw-rx460 missing win1507 w1064v1507 missing win1607 w1064v1607 14.0.23026.0 -- 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 52828] New: Incorrect instruments in MIDI playback over ALSA
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=52828 Bug ID: 52828 Summary: Incorrect instruments in MIDI playback over ALSA 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: dark(a)darkok.xyz Distribution: --- Created attachment 72216 --> https://bugs.winehq.org/attachment.cgi?id=72216 MIDI file that is played noticably wrong Starting from Wine 7.5, some MIDIs aren't played back properly as they have the incorrect instruments, at least when I've tried playing them using aplaymidi on a VST using SAVIHost. Downloads: https://www.hermannseib.com/programs/savihostx64.zip https://cdn.roland.com/assets/media/zip/scva_win_trial.zip Steps to reproduce: 1. Execute "winetricks mfc90" to get a required DLL 2. Extract scva_win_trial.zip and install the Roland Sound Canvas VA VST 3. Extract savihostx64.zip, and move savihost.exe to "C:\Program Files\Roland\Sound Canvas VA" 4. Rename savihost.exe to "Sound Canvas VA.exe" 5. Run the renamed executable 6. Go to Devices>MIDI, and set Input Port 1 to "Midi Through Port-0" 7. Run "aplaymidi -p 14:0 smr_101.mid" to start playing the MIDI 8. In the VST, click "PART", and the correct instruments should be Vibraphone for the first three, and "KICK&SNARE" for the 11th. However, starting from Wine 7.5, these instruments are incorrectly set to "Piano 1" for the first three, and "Syn. Strings 1" for the 11th. -- 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 48048] New: urlmon:protocol - The ftp test fail on Vista to Windows 8
by WineHQ Bugzilla May 6, 2022

May 6, 2022

https://bugs.winehq.org/show_bug.cgi?id=48048 Bug ID: 48048 Summary: urlmon:protocol - The ftp test fail on Vista to Windows 8 Product: Wine Version: unspecified Hardware: x86 OS: Windows Status: NEW Severity: normal Priority: P2 Component: urlmon Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The ftp protocol test in urlmon:protocol fails frequently on Windows from Vista to Windows 8: protocol.c:1188: Test failed: hrResult = 800c0006, expected E_PENDING or S_OK protocol.c:1193: Test failed: dwError = 12111, expected ERROR_SUCCESS protocol.c:3656: Test failed: wait timed out urlmon:protocol:0700 done (258) in 120s Test failed: timed out Note: 800c0006 is INET_E_OBJECT_NOT_FOUND See https://test.winehq.org/data/tests/urlmon:protocol.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 5

[Bug 18635] New: Menu bar is hidden in Adobe Lightroom 2.3
by wine-bugs＠winehq.org May 6, 2022

May 6, 2022

http://bugs.winehq.org/show_bug.cgi?id=18635 Summary: Menu bar is hidden in Adobe Lightroom 2.3 Product: Wine Version: 1.1.22 Platform: Other OS/Version: other Status: UNCONFIRMED Severity: enhancement Priority: P2 Component: -unknown AssignedTo: wine-bugs(a)winehq.org ReportedBy: thomas+wine(a)stromberg.org With the Adobe Lightroom 2.3 demo, the menu bar titles (File, etc.) do not display. If you click on the area that they should be, the menu does appear however. Lightroom 2.3 can be downloaded from https://www.adobe.com/cfusion/tdrc/index.cfm?product=photoshop_lightroom (free Adobe login required) I'm not sure where to go about tracing the issue down to, but I did notice the following calls that show that it is calling DrawMenuBar(). 0009:Call user32.GetMenu(0002003c) ret=60030cbe 0009:Ret user32.GetMenu() retval=000000f0 ret=60030cbe 0009:Call user32.GetMenuBarInfo(0002003c,fffffffd,00000000,0032e1a4) ret=60030cec fixme:menu:GetMenuBarInfo (0x2003c,0xfffffffd,0x00000000,0x32e1a4) 0009:Ret user32.GetMenuBarInfo() retval=00000000 ret=60030cec 0009:Call user32.GetSystemMenu(0002003c,00000000) ret=60030beb 0009:Ret user32.GetSystemMenu() retval=00000280 ret=60030beb 0009:Call user32.GetSystemMenu(0002003c,00000000) ret=60030c06 0009:Ret user32.GetSystemMenu() retval=00000280 ret=60030c06 0009:Call user32.GetMenuItemInfoW(00000280,0000f060,00000000,0032e08c) ret=60030c22 0009:Ret user32.GetMenuItemInfoW() retval=00000001 ret=60030c22 0009:Call user32.DrawMenuBar(0002003c) ret=6008d171 -- 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 21

[Bug 52902] New: gdi32:font has specific failures on Windows 10 with the UTF-8 codepage
by WineHQ Bugzilla May 2, 2022

May 2, 2022

https://bugs.winehq.org/show_bug.cgi?id=52902 Bug ID: 52902 Summary: gdi32:font has specific failures on Windows 10 with the UTF-8 codepage Product: Wine Version: unspecified Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: gdi32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com The following gdi32:font failures are specific to UTF-8 on Windows 10: --- test_RealizationInfo(): font.c:4356: Test failed: info[0] = 103 for the system font --- test_GetCharacterPlacement(): font.c:4998: Test failed: Unexpected first glyph L":" font.c:5012: Test failed: GetCharacterPlacementA returned different result: 1048638 vs 1048637 font.c:5016: Test failed: GetCharacterPlacementA returned different result: 1048638 vs 1048637 font.c:5023: Test failed: GetCharacterPlacementA returned different result: 1048638 vs 1048637 font.c:5025: Test failed: Unexpected first glyph L":" --- test_GetCharWidthInfo(): font.c:7396: Test failed: expected 0, got -8 font.c:7397: Test failed: expected 0, got -9 font.c:7398: Test failed: expected 0, got 1 https://test.winehq.org/data/patterns.html#gdi32:font They can be reproduced on w10pro64-hi-u8. Note that w10pro64-hi which uses the Hindi locale too but not UTF-8 (so the system locale is English) has its own set of totally unrelated failures. -- 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 51365] New: wininet:http causes urlmon:protocol to time out
by WineHQ Bugzilla May 1, 2022

May 1, 2022

https://bugs.winehq.org/show_bug.cgi?id=51365 Bug ID: 51365 Summary: wininet:http causes urlmon:protocol to time out Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: urlmon Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com If wininet:http is run before urlmon:url the latter will time out as follows: protocol.c:348: Test failed: unexpected call OnResponse protocol.c:839: Test failed: unexpected call ReportProgress_MIMETYPEAVAILABLE protocol.c:1101: Test failed: unexpected call ReportData protocol.c:3437: Test failed: wait timed out protocol.c:3439: Test failed: expected Switch protocol.c:3560: Testing http protocol (redirected, disable auto redirect)... protocol.c:469: QueryService(IID_IGetBindHandle) protocol.c:475: QueryService(IID_IWindowForBindingUI) protocol.c:1178: Test failed: unexpected call ReportResult protocol.c:1186: Test failed: hrResult = 800c0014, expected: 00000000 urlmon:protocol:0bd0 done (258) in 120s (0x800c0014 = INET_E_REDIRECT_FAILED) The timeout actually happens in test_http_protocol_url() on line 3437: ok( WaitForSingleObject(event_complete, 90000) == WAIT_OBJECT_0, "wait timed out\n" ); This actually happens on machines that use the wt-daily.bat script [1] because that script first runs the 32-bit tests (including wininet:http) and then the 64-bit tests and, obviously, no configuration 'reset' happens in between. Specifically this causes failures in the 64-bit urlmon:protocol results on cw-gtx560 and cw-rx460: https://test.winehq.org/data/patterns.html#urlmon:protocol [1] https://github.com/fgouget/wt-daily/blob/master/wt-daily.bat.template#L138 -- 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