wine-devel

wine-devel@winehq.org

15 participants
84452 discussions

Wine staging 8.19 release
by Alistair Leslie-Hughes 30 Oct '23

30 Oct '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.18 (493 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * ntdll: Don't use Wine frames during exception processing on x64. Added: * None Updated: * vkd3d-latest to latest. * fltmgr.sys-FltBuildDefaultSecurityDescriptor Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Win16 tests
by Zeb Figura 23 Oct '23

23 Oct '23

Hello! The idea of having tests for our win16 functionality has been raised every so often, but never actualized. I would like to change that now. I think win16 has been broken several times recently, especially with large scale refactoring like the PE conversion and wow64 work, and I'd like to put tests in place to stop that happening. I'd also like to have a way to easily *write* tests for nontrivial functionality, which is currently something of an ordeal. By my understanding, the big blocker for having win16 tests in tree is the lack of a usable win16 compiler. Existing win16 compilers are mostly hard to find; OpenWatcom is sometimes mentioned, but that only has win32 builds (as far as I'm aware), which makes it hard if not impossible to integrate into Wine. I've spent a while over the past year or so trying a certain idea, where we write a small win16 entry point, and use generic thunks to call into win32 code, then use generic thunks the other way (WOWCallback16Ex) to call back into win16 functions. I managed to get a working PoC that actually worked on Windows XP; however, it did not work on Windows 98 [1]. In light of this, I tried a different approach. I considered but ultimately rejected the idea of introducing Win16 support into GCC [2], and instead tried an experiment to see if I could write an extremely minimalist, non-optimizing Win16 compiler myself from "scratch" [3]. It turns out that I could, in the span of what didn't end up being more than a couple months' worth of weekends. The compiler is called Rosé, and it lives here: https://gitlab.winehq.org/zfigura/rose It is not fully featured; it's still missing a few notable pieces (in particular: unions, multiple code segments) but it is reasonably complete, and I was able to use it to compile a modified version of winetest.exe, and produce working executables for Windows 98. It is therefore my proposal to use this compiler in Wine, and write in-tree Win16 tests. Here are some of the important considerations involved in this proposal: * The compiler is small and could potentially be easily just imported into Wine. I don't have any feelings about continuing to maintain it outside of Wine—i.e. it could easily just be imported and any further development done in Wine (much like e.g. widl). "Small" here means about 15k LoC across a few files, including the builtin CRT and headers. * NE executables, unlike both their predecessor (MZ) and successor (PE), cannot output to a controlling console, and in general have no concept of a stdin/stdout/stderr. This does not fit well with wine tests, which are built to run with a console. There is also not much in the way of IPC available to a win16 process. They can, on the other hand, open a file and output to it. For Marvin (or gitlab CI), this is not a huge concern, but for development it's a bit more important. In light of this we may want to write a small win32 wrapper for win16 tests, possibly one that self-extracts the win16 test. * In order to properly test Win16 we need a contemporaneous test VM, I think ideally 98. A modern 32-bit Windows machine (of which I think we still have some) will *run* 16-bit code, and may be usable to test *some* functionality, but I do not think the results can be trusted. This is probably a more general problem—I think our current ability to test native ddraw is similarly worthless. (ddraw is also harder, though, because we need contemporaneous *hardware* as well.) There may be other areas where our current CI is not very valuable and we really do want to test old Windows versions, although I can't think of any off the top of my head. Thoughts and opinions? If not (as per usual) I will try to put together a patch series soon. --Zeb [1] In a sense this is actually very similar to how we currently implement 16-bit DLLs in Wine, except that we use a private thunk instead of the exported generic thunks [CallProcEx32W], so I spent some time refactoring various parts of krnl386 and winebuild to match my proposed design. This was going well up until I tried running the executable on Windows 98. It turns out that, unlike with NT, one cannot call any win32 functions from the 32-bit DLL without crashing. This may not be prohibitive per se [if we avoid ever making any win32 calls] but it did impose some pretty severe limitations. It's also worth mentioning that the process of refactoring was *very* convoluted, things had to be moved around very carefully in order to work. [2] The idea of introducing compiler support into GCC has obvious advantages: not just the reuse of frontend and optimization code, but the dialect is something that will already be perfectly familiar to a Wine developer. However, it also has disadvantages: it would take a lot of time to become familiar with gcc, and I expect that segmented address spaces will be very hard to fit into the GCC code and probably not accepted upstream. [3] In fact it is not built from scratch, but rather built from the HLSL compiler. This is largely because I am very familiar with the HLSL compiler, and familiarity is very important. I also found it far less daunting to start with the HLSL compiler, rip out everything specific to HLSL, rather than to start from scratch even using the HLSL compiler as a model.

5 8

New failures analysis
by Francois Gouget 20 Oct '23

20 Oct '23

New failures: Where do they come from? How do they get in? All you've ever wanted to know (or not). So I collected data about the new failure modes (see failure-new.txt), mostly from the start of July (older data is incomplete). By new failure mode I mean any failure group that I can say started happening on a specific day in that range. This calls for some caveats: * A failure mode is a group of failures that happens together in a given test unit and thus likely all have the same origin. Normally each failure mode is described in a bug. In the rest of this document I'll just say 'failure' in place of 'failure mode'. * This includes failures that happen on non GitLab / TestBot machines. * I don't know the origin of all of them so there are certainly some that are not caused by a change in Wine. So not all are Wine regressions. * But until their cause is known they still need to be investigated so I'm still counting them when it seems appropriate. However I did not include those where it was known from the start that they were caused by external factors. First the date range I used for each month: Jul 2023-06-30 - 2023-07-28 28 days Aug 2023-07-28 - 2023-08-28 31 days (08-28 is about when the TestBot -> GitLab CI bridge broke) Sep 2023-09-01 - 2023-10-06 39 days So how many new failures are there? Jul 36 new failures -> 1.3 / day Aug 7 new failures -> 0.2 / day (vacation effect!) Sep 53 new failures -> 1.4 / day Note that a single MR may cause multiple tests to fail but each new failing test would be counted separately here on the premise that they each need to be investigated and reported. Where do they come from? Jul Aug Sep Unknown 8 4 18 Commit 4 1 6 MR 7 2 17 Total 19 7 41 Total / day 0.7 0.2 1.1 * These counts are deduplicated except for the new failures of unknown origin obviously. * The commits correspond to direct Wine commits so they don't go through the GitLab CI or the TestBot. * About half of the new failures have no known origin. This can be because they happen on machines I don't have access to and thus where I cannot bisect. It can also be because the failure fails to reproduce which is annoyingly common. * To keep up 5 to 8 failure would have to be fixed How do they get in? Jul Aug Sep Untested 2 1 7 Bad 2 0 0 Module 1 0 1 Extra configs 0 0 2 Flaky 2 0 2 WineTest only 1 0 0 Bridge 0 0 7 Misc 1 1 0 Total 9 2 19 Here's a description of the way the failures got in. Those correspond to deduplicated failure counts since we're not interested in the number of tests impacted but in how the commits got in: o 33% Untested These correspond to direct Wine commits. As such they bypass the GitLab CI and TestBot so there was no way to detect them beforehand. There has been a lot of changes in the lowe level code lately so I think this is usually lower. o 23% Bridge These failures were detected by the TestBot but not forwarded to the MR page because the mailing list to GitLab bridge broke on or about 2023-08-28. o 13% Flaky These failures are random and just did not happen when the MR got tested by the GitLab CI and TestBot. One way to minimize the chances of this happening is to run the tests multiple times. But the TestBot already runs the tests on up to 24 Windows configurations and 10 Linux ones which means random failures that are not configuration-specific have a very good chance of being caught. It's the other ones that get through, like those that only impact a specific locale or a specific Windows version. o 7% Module When a patch modifies a module but not the tests it contains the TestBot skips some test configurations which can lead to some failures being undetected. o 7% Extra This corresponds to failures specific to test configurations that the TestBot only uses for the nightly WineTest runs. In the above counts I omitted the following: o 18 Unknown This corresponds to cases where what is causing the failure has not been identified, and thus how they got in undetected is not known. Note that there is one exception: if the failure does not impact the GitLab and TestBot machines then the reason is automatically "Non TestBot". o 17 Non TestBot These new failures impact neither the GitLab nor the TestBot machines. This corresponds to macOS-specific failures for instance. Detecting them beforehand is therefore impossible... except by expanding the set of test machines. Are they fixed yet? Jul Aug Sep Fixed 15 (47%) 2 (33%) 21 (40%) Not fixed 17 (53%) 4 (67%) 31 (60%) Not there yet. * Take with a big grain of salt : the bugs are not always closed when a failure is fixed. I may also have forgotten to mark some entries as fixed in failures-new.txt but I think that part is mostly okay now. * Older failures don't seem more likely to be fixed. But then failures are not necessarily reported in the order they appear. -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

GitLab CI's Most Wanted list
by Francois Gouget 20 Oct '23

20 Oct '23

Processing the failures-mr.txt file for the past month (see previous email) points to the following test units as plagging the most merge requests: 100 msxml3:domdoc (55720) 87 amstream:amstream (55725) 81 quartz:filtergraph (55758) 44 build:mac 26 d2d1:d2d1 (55765) 19 winmm:mci (55605) 15 user32:msg (55786, mostly) 13 user32:win (55766) 12 psapi:psapi_main (55744, fixed on day 3) 11 wscript.exe:run (55746, fixed on day 3) 11 tasklist.exe:tasklist (55745, fixed on day 3) Good hunting! -- Francois Gouget <fgouget(a)codeweavers.com>

4 4

TestBot News - MR false positives analysis
by Francois Gouget 19 Oct '23

19 Oct '23

I have been reviewing the TestBot and GitLab CI test results for the merged MRs. While doing that I updated the TestBot's known failures list (https://testbot.winehq.org/FailuresList.pl) in order to drive down the false positive rate. Incidentally I also collected the list of test units causing false positives, so I'll start with that. Specifically, here are the bugs to fix to help the GitLab CI: * Bug 53433 - mmdevapi:capture - impacted 18 MRs * Bug 54064 - ntdll:threadpool - impacted 15 MRs * Bug 54078 - ntdll:pipe - impacted 11 MRs * Bug 54140 - mmdevapi:render - impacted 5 MRs * Bug 54005 - ole32:clipboard - impacted 5 MRs * Bug 54037 - user32:msg - impacted 5 MRs * Bug 54074 - ws2_32:sock - impacted 5 MRs I classified the TestBot / GitLab CI results as follows: * False positive Cases where the CI system incorrectly claimed the MR introduces new failures. This is typically the case when the failures that are already present in nightly WineTest results. * Bad merge MRs that break a test and got merged anyway. * Collateral Damage from a bad merge The false positives (aka collateral damage) caused by one of the bad merges above. * Outside interference This identifies false positives that are not random and intrinsic to the test but that result from change outside the Wine infrastructure, for instance certificates that expire, or configuration changes to servers that break the tests that depend on it. Of those the only ones that a CI can really avoid are the first type, aka "False positive". So I calculated the corresponding weekly rate: Adjusted False Positive rate Week | TestBot | GitLab CI 2022-11-14 | 21.9% | 8.3% 2022-11-21 | 8.0% | 21.6% 2022-11-28 | 14.7% | 28.4% 2022-12-05 | 8.5% | 24.5% 2022-12-12 | 0.0% | 20.0% Note that the TestBot's 8% rate for the 11-21 week is not representative because Wine was broken that week (collateral damage) which prevented the tests from running in Wine, and thus from contributing real "false positives". Also the 12-12 week is still incomplete obviously. Even so I think his shows the TestBot is improving. Here's a list of the incidents for the weeks above: * 11-14 An external certificate revocation issue caused crypt32:cert to fail systematically. This impacted 14 merge requests and was fixed in MR1360. * 11-17 MR!1399 got merged despite the TestBot detecting that it prevented 32-bit Wine tests from running to completion. This impacted 39 merge requests. I could have reduced that number if I had been faster to reconfigure the TestBot to stop running the full 32-bit Wine test suite. This was fixed in MR!1524. * 11-17 MR!1398 got merged despite the TestBot detecting that it broke ntoskrnl.exe:ntoskrnl on Windows 7. This was fixed in MR!1803. * 11-22 MR!1495 got merged despite the TestBot detecting that it broke vbscript:run on Windows *. I don't have a record of the impacted MRs or of when it was fixed. * 11-23 The b00a831d direct commit broke kernel32:process in Wine. This got fixed since. * 12-07 MR!1732 got merged despite the TestBot detecting that it broke taskschd:scheduler on Windows *. I immediately added a known failure entry and no MR got impacted. This was fixed in MR!1736. If not filtering out the failures caused by these incidents, the false positive rate is: Raw False Positive rate Week | TestBot | GitLab CI 2022-11-14 | 52.1% | 27.1% 2022-11-21 | 50.0% | 29.5% 2022-11-28 | 20.0% | 33.7% 2022-12-05 | 19.1% | 57.4% 2022-12-12 | 0.0% | 20.0% I think that also shows that the TestBot is improving. I have attached the raw data I collected and shell snippets to extract various statistics (failures-mr.txt) as well as a spreadsheet import (failures.xls). -- Francois Gouget <fgouget(a)codeweavers.com>

1 5

Wine staging 8.18 release
by Alistair Leslie-Hughes 14 Oct '23

14 Oct '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.18 (496 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * dmime: Implement IDirectMusicSegment8 Download. * dmime: Play a sound in IDirectMusicPerformance8 PlaySegmentEx * d3dx9: D3DXLoadMeshHierarchyFromXInMemory support empty mesh. * include: Always define hton/ntoh macros. Added: * [39876] d3dx9: D3DXLoadMeshHierarchyFromXInMemory return a dummy ID3DXAnimationController. Updated: * vkd3d-latest to latest. * msxml3-FreeThreadedXMLHTTP60 * odbc-remove-unixodbc Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Wine staging 8.17 release
by Alistair Leslie-Hughes 30 Sep '23

30 Sep '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.17 (494 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * systeminfo: add basic functionality. Added: * [39876] d3dx9: D3DXLoadMeshHierarchyFromXInMemory return a dummy ID3DXAnimationController. Updated: * vkd3d-latest to latest. * user32-recursive-activation Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

TestBot News
by Francois Gouget 27 Sep '23

27 Sep '23

* GitLab bridge The bridge to add the TestBot failures as comments on GitLab is broken. It seems like it happened near the end of August. So be sure to look at the wine-gitlab mailing list to not miss issues in your merge requests. * VM changes debian11, debian11b and debiant now have UsePPosition in their fvwm configuration. See the full fvwm configuration below: https://wiki.winehq.org/Wine_TestBot_VMs#Unix_configuration These VMs also got an update to the latest packages. Also there is an ongoing experiment to figure out the best window manager for the tests. And who knows, maybe we'll event keep more than one? Anyway we currently have: - debian11 fvwm2 - debian11b fvwm2 - debian12 openbox - debiant fvwm3 * Test result changes Thanks to Esme's work, user32:msg now has a lot fewer failures, most notably on Windows 7 and 11: https://test.winehq.org/data/patterns.html#user32:msg d3d9:device also got quite a bit better thanks to Stefan's work: https://test.winehq.org/data/patterns And Alexandre fixed a bunch of stack, pointer and parameter size failures in various tests: https://test.winehq.org/data/patterns.html#kernel32:loader https://test.winehq.org/data/patterns.html#kernel32:thread https://test.winehq.org/data/patterns.html#ntdll:om https://test.winehq.org/data/patterns.html#oleaut32:usrmarshal https://test.winehq.org/data/patterns.html#winmm:capture ... Unfortunately there are other tests that started failing: 09-18 - 55650 dbghelp:dbghelp fails on macOS 09-14 - 55648 ntdll:wow64 - test_peb_teb() crashes on macOS - 55658 psapi:psapi_main - test_EnumProcessModules*() fails on macOS - 55655 user32:dialog - test_IsDialogMessageA_proc() fails in the Hindi locale on Wine - 55656 user32:dialog - test_IsDialogMessage() fails in the hi-u8 and mx-MX locales on Windows (bug 55656) 09-12 - 55649 quartz:vmr9 - test_changed3ddevice() fails on the TestBot's w11pro64-amd & -nv VMs 09-11 - 55637 dmime:dmime - test_performance_pmsg() sometimes fails due to bad timing on Windows and Wine - 55656 ntdll:exception - test_thread_context() fails on macOS 09-08 - 55583 d3d8:device - test_wndproc() often is missing a WM_WINDOWPOSCHANGING in Wine 08-30 - 55569 mshtml:dom - The 32-bit test_attr_collection_attr() crashes on Windows 10 2004+ 08-23 - 55588 mf:mf - test_scheme_resolvers() crashes on Windows 7 -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

Wine staging 8.16 release
by Alistair Leslie-Hughes 16 Sep '23

16 Sep '23

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.16 (495 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * dnsapi/tests: Add some tests for DNS_TYPE_SRV messages. * dnsapi: Accept name records of exact size at the end of the packet. * dnsapi: Set correct wDataLength for DNS_TYPE_SRV records. Added: * [10729] ddraw: Implement Pick() and GetPickRecords(). Updated: * vkd3d-latest to latest. Where can you help * Run Steam/Battle.net/GOG/UPlay/Epic * Test your favorite game. * Test your favorite applications. * Improve staging patches and get them accepted upstream. * Suggest patches to be included in staging. As always, if you find a bug, please report it via https://bugs.winehq.org Best Regards Alistair.

1 0

Recent ntdll/unix/signal_x86_64.c changes
by Gerald Pfeifer 15 Sep '23

15 Sep '23

commit ea640f6cece7660ffc853b7d574fbe52af34901a Author: Alexandre Julliard <julliard(a)winehq.org> Date: Mon Sep 11 11:25:29 2023 +0200 ntdll: Ignore attempts to change segment registers on x86-64. moved the following code +#ifdef DS_sig + DS_sig(sigcontext) = ds64_sel; +#else + __asm__ volatile( "movw %0,%%ds" :: "r" (ds64_sel) ); +#endif +#ifdef ES_sig + ES_sig(sigcontext) = ds64_sel; +#else + __asm__ volatile( "movw %0,%%es" :: "r" (ds64_sel) ); +#endif into static inline void leave_handler( const ucontext_t *sigcontext ) Alas this has "const ucontext_t *sigcontext", so platforms like FreeBSD that define DS_sig will try to do DS_sig(sigcontext) = ds64_sel; which results in GCC rightfully diagnosing: dlls/ntdll/unix/signal_x86_64.c: In function ‘leave_handler’: dlls/ntdll/unix/signal_x86_64.c:822:24: error: assignment of member ‘mc_ds’ in read-only object 822 | DS_sig(sigcontext) = ds64_sel; | ^ I submitted https://gitlab.winehq.org/wine/wine/-/merge_requests/3845 which restores the build on FreeBSD and presumably NetBSD, but wonder: Could FreeBSD/NetBSD align with Linux and macOS which d not define DS_sig (and ES_sig) and thus use into different code paths in leave_handler? Gerald

2 1

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-devel