wine-bugs July 2021

wine-bugs@winehq.org

1 participants
5453 discussions

[Bug 51453] New: oleaut32:vartype fails on Windows 10 1909+
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51453 Bug ID: 51453 Summary: oleaut32:vartype fails on Windows 10 1909+ Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: oleaut32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com oleaut32:vartype has the same set of failures on all the Windows 10 1909+ TestBot VMs: https://test.winehq.org/data/patterns.html#oleaut32:vartype vartype.c:3047: Test failed: expected 10990, got 47515; hres=0x00000000 vartype.c:3048: Test failed: expected 10990, got 47515; hres=0x00000000 vartype.c:3055: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3056: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3057: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3058: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3059: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3060: Test failed: expected 12785, got 49310; hres=0x00000000 vartype.c:3070: Test failed: expected 11722, got 48247; hres=0x00000000 vartype.c:3071: Test failed: expected 11722, got 48247; hres=0x00000000 vartype.c:3074: Test failed: expected 10960, got 47485; hres=0x00000000 vartype.c:3075: Test failed: expected 11325, got 47850; hres=0x00000000 It turns out that this happens because the Y2K cutoff date has changed in Windows 10 1903: * Earlier Windows versions used 29, that is two digit years 0-29 mapped to 2000-2029 while years 30-99 mapped to 1930-1999. * But Windows 10 1903+ use 49 by default so that two digit years 0-49 map to 2000-2049 while years 50-99 map to 1950-1999. oleaut32:vartype expects the old 29 cutoff when it tests how VarDateFromStr() parses dates such as "2 30" which is what causes the failures. Wine's VarDateFromStr() implementation should also be updated to match the current Windows versions. -- 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 51493] New: WXDrive.exe from WeCom failed to startup.
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51493 Bug ID: 51493 Summary: WXDrive.exe from WeCom failed to startup. Product: Wine Version: 6.13 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: winsock Assignee: wine-bugs(a)winehq.org Reporter: jactry92(a)gmail.com Distribution: --- Created attachment 70328 --> https://bugs.winehq.org/attachment.cgi?id=70328 The expected white dialog. Steps to reproduce: 1. `winetricks -q arial` for work around a CEF crash. 2. Download and install WeCom. 3. `cd ~/.wine/drive_c/Program Files (x86)/WXDrive` 4. `wine WXDrive.exe --disable-gpu --wxdrive-setting=0 --disable-gpu --disable-software-rasterizer --enable-features=NetworkServiceInProcess "wedocs://public.action/openmain?from=winwxwork"` Expected: The program startup and there is a white dialog. Actually: The program doesn't startup. -- 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 51410] New: mlang:mlang fails on the Hindi test configuration
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51410 Bug ID: 51410 Summary: mlang:mlang fails on the Hindi test configuration Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: mlang Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Created attachment 70266 --> https://bugs.winehq.org/attachment.cgi?id=70266 mlang/tests: Fix the check for non-English locales in test_GetCodePageInfo(). mlang:mlang fails on the Hindi test configuration: https://test.winehq.org/data/patterns.html#mlang:mlang The 36 systematic failures all happen on lines 2572 to 2580 in test_GetCodePageInfo(). For instance: mlang.c:2572: Test failed: 9: got wrong wszDescription expected L"Baltic (Windows)" return L"\092c\093e\0932\094d\091f\093f\0915 (Windows)". mlang.c:2576: Test failed: 9: got wrong wszFixedWidthFont expected L"Courier New" return L"Nirmala UI". mlang.c:2580: Test failed: 9: got wrong wszProportionalFont expected L"Arial" return L"Nirmala UI". These checks are meant to be skipped on non-English locales but the test checks the wrong Windows locale and gets confused because the Hindi test configuration still has some English locales (notably the system locale, see WineTest's locale information dump). The attached patch should fix this. -- 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 51185] New: Windows fails to load the minimal PE image in kenel32:loader
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51185 Bug ID: 51185 Summary: Windows fails to load the minimal PE image in kenel32:loader Product: Wine Version: 6.8 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: kernel32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com test_Loader() claims that Windows 7 is able to load this minimal PE image: /* Minimal PE image that Windows7 is able to load: 268 bytes */ { 0x04, 0, 0xf0, /* optional header size just forces 0xf0 bytes to be written, 0 or another number don't change the behaviour, what really matters is file size regardless of values in the headers */ 0x04 /* also serves as e_lfanew in the truncated MZ header */, 0x04, 0x40, /* minimal image size that Windows7 accepts */ 0, { ERROR_SUCCESS } }, But in fact this fails on all Windows version from Windows 7 to Windows 10 20H2... except in the early Windows 10 versions (1507 to 1809): https://test.winehq.org/data/patterns.html#kernel32:loader loader.c:1140: Test failed: 16: unexpected error 193 The failing test was introduced by this commit: commit 1a7dd7cdbe184ff3fdf2781e9a2222872bacee2c Author: Dmitry Timoshkov <dmitry(a)baikal.ru> AuthorDate: Wed May 6 15:16:01 2020 +0800 Commit: Alexandre Julliard <julliard(a)winehq.org> CommitDate: Fri May 15 11:42:28 2020 +0200 kernel32/tests: Add a PE test image that resembles format of some of 8k demos. Signed-off-by: Dmitry Timoshkov <dmitry(a)baikal.ru> 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 51346] New: x264guiEx partly shows white box characters when using Wine-Mono (default encoding issue with C++/CLI).
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51346 Bug ID: 51346 Summary: x264guiEx partly shows white box characters when using Wine-Mono (default encoding issue with C++/CLI). Product: Wine Version: 6.11 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: sagawa.aki+winebugs(a)gmail.com Distribution: Ubuntu Created attachment 70202 --> https://bugs.winehq.org/attachment.cgi?id=70202 x264guiEx configuration window x264guiEx[1] is a famous output plugin for AviUtl, Japanese video editing software[2]. When running it with AviUtl 1.10 and Wine-Mono 6.20, its configuration window partly shows white box characters instead of Japanese characters. See attached image for details. It's not typeface issue. For the attachment case, it shows three white boxes for two Japanese characters, なし. If we had have a missing typeface, it should be two. I guess Wine-Mono's default encoding incompatibility causes this issue. This plugin uses System::String without the encoding parameter in frmConfig.cpp[3]. That means constructor's argument is interpreted using default encoding[4]. [1] https://github.com/rigaya/x264guiEx [2] http://spring-fragrance.mints.ne.jp/aviutl/ [3] https://github.com/rigaya/x264guiEx/blob/9f1abe0f44be3c602ffa938e2ca7d80cea… [4] https://docs.microsoft.com/en-us/dotnet/api/system.string.-ctor?view=net-5.… -- 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 51334] New: Microsoft Xbox Live Developer Tool XblTestAccountGui crashes
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51334 Bug ID: 51334 Summary: Microsoft Xbox Live Developer Tool XblTestAccountGui crashes Product: Wine Version: 6.11 Hardware: x86-64 URL: https://web.archive.org/web/20210625235311/https://git hub.com/microsoft/xbox-live-developer-tools/releases/d ownload/2106/XboxLiveTools-2106-20210624.zip OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree Assignee: wine-bugs(a)winehq.org Reporter: the.ideals(a)gmail.com Distribution: --- Created attachment 70197 --> https://bugs.winehq.org/attachment.cgi?id=70197 crash log XblTestAccountGui clicking on the front screen buttons leads to the crash (Unhandled page fault). 1. Run XblTestAccountGui 2. Click Login 1. Run XblTestAccountGui 2. Click Clear cached login Potential separate bug for filing (System.EntryPointNotFoundException): 1. Run XblTestAccountGui 2. Click About Source: https://github.com/microsoft/xbox-live-developer-tools sha1sum XboxLiveTools-2106-20210624.zip aa601549455365f4e94ede40ea7dce07d7f93239 XboxLiveTools-2106-20210624.zip du -sh XboxLiveTools-2106-20210624.zip 6.5M XboxLiveTools-2106-20210624.zip -- 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 51319] New: server: spins in a loop consuming 100% of a hardware thread until closed, makes wineserver SCHED_FIFO unsafe.
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51319 Bug ID: 51319 Summary: server: spins in a loop consuming 100% of a hardware thread until closed, makes wineserver SCHED_FIFO unsafe. Product: Wine Version: 6.9 Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: wineserver Assignee: wine-bugs(a)winehq.org Reporter: spambox1(a)koolhoven-home.net Distribution: --- wineserver can be induced into an infinite loop of some sort and take up 100% thread/hardware CPU time. This makes setting SCHED_FIFO and SCHED_RR on wineserver unsafe, will cause immediate system lock if attempted. -- 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 28

[Bug 25167] New: Eraser 6.0 fails to start (with Mono)
by wine-bugs＠winehq.org 30 Jul '21

30 Jul '21

http://bugs.winehq.org/show_bug.cgi?id=25167 Summary: Eraser 6.0 fails to start (with Mono) Product: Wine Version: 1.3.7 Platform: x86-64 URL: http://eraser.heidi.ie/download.php OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: mscoree AssignedTo: wine-bugs(a)winehq.org ReportedBy: RandomAccountName(a)mail.com Created an attachment (id=31924) --> (http://bugs.winehq.org/attachment.cgi?id=31924) Terminal output Attempting to start the program only yields an error message saying "collecting from unknown thread." I've used winetricks mono26 beforehand. I didn't test with .NET since it requires .NET 3.5 SP1, which won't work in Wine yet as far as I know. -- 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 17

[Bug 51284] New: shell32:shellpath fails on Windows 8.1 when there is more than on CD drive
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51284 Bug ID: 51284 Summary: shell32:shellpath fails on Windows 8.1 when there is more than on CD drive Product: Wine Version: 6.10 Hardware: x86-64 OS: Windows Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com shell32:shellpath fails on Windows when there is more than on CD drive: https://test.winehq.org/data/patterns.html#shell32:shellpath shellpath.c:380: Test failed: Full path L"C:\\Users\\winetest\\AppData\\Local\\Microsoft\\Windows\\Burn\\Burn1" does not end with relative path L"Microsoft\\Windows\\Burn\\Burn" For now these failures happen on the Windows 8.1 cw-rx460 and cw-gtx560 machines. That's because these machines have both Burn\Burn and Burn\Burn1 folders. Paradoxically these don't have a CD drive at all. However they are connected to a KVM which can serve ISOs in the form of a USB CD drive. I suspect that with ISO changes, connection/disconnections Windows 8.1 ended up thinking there were two USB CD drives and thus created one folder for each drive. I have confirmed that adding two drives to a recent Windows 10 VM gives the same result so this is not something specific to Windows 8.1 or the cw-* machines. Incidentally the failing test was introduced by the commit below: commit 73c08fb638938ac6f903ad91d5ef2c93ae18a971 Author: Andrew Eikum <aeikum(a)codeweavers.com> AuthorDate: Thu May 27 13:38:16 2021 -0500 shell32/tests: Add tests to show relative known folder paths match SHGetKnownFolderPath. Signed-off-by: Andrew Eikum <aeikum(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 6

[Bug 51196] New: ntdll:om has a timing-related failure in Wine
by WineHQ Bugzilla 30 Jul '21

30 Jul '21

https://bugs.winehq.org/show_bug.cgi?id=51196 Bug ID: 51196 Summary: ntdll:om has a timing-related failure in Wine Product: Wine Version: 6.8 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: fgouget(a)codeweavers.com Distribution: --- ntdll:om randomly fails with an error of the form: om.c:2307: Test failed: got 88 and/or om.c:2322: Test failed: got 87 The value is the time spent in RtlWaitOnAddress(..., timeout=100 ms). The test generously expects at least 90 ms and the failure occurs whenever it is below that. Because the failure is intermittent and the duration typically varies between 85 and 89 ms, this failure is prone to generating false positives in the TestBot. Furthermore this only happens in Wine which suggests there is some implementation issue there. -- 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

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 July 2021