- Wine-devel - list.winehq.org

Re: A case for policy changes to get to zero test failures
by Francois Gouget 31 Oct '23

31 Oct '23

On Mon, 23 Oct 2023, Francois Gouget wrote: [...] > So the conclusion I have come to is that making further and lasting > progress will require policy changes to incentivize work on the tests. * The goal is to get rid of the TestBot so the bridge to GitLab will not be restored in any form. There will also be no further TestBot development. * Wine developers are on their own to figure out if their commits cause new failures, and if they do they are on their own to figure out how to reproduce the issues. * The other policy changes are still to be determined. -- Francois Gouget <fgouget(a)codeweavers.com>

2 1

Re: A case for policy changes to get to zero test failures
by Giovanni Mascellani 30 Oct '23

30 Oct '23

Hi, Il 23/10/23 14:29, Francois Gouget ha scritto: > * Replicating failures can sometimes be frustratingly hard. Even if you > happen to have access to the CI environment! [2] > > * And usually one does not have access to the CI environment. That's the > the case for the Windows environments for licensing reasons. On the > Linux side the GitLab CI should mean progress but replicating it needs > to be made much simpler before that's effective. In the meantime that > means no debugger, no watching what happens on screen while the test > runs, little poking into the test environment entrails (short of > writing a dedicated program to do the poking), etc. In short it's > remote debugging. This is indeed a pain point. So much that at some point I even began to write a tentative solution to that, which so far I have only shared inside CodeWeavers. There is in fact (as far as I am aware) no reason why it should not be made available publicly, so here it is, I just released it: https://gitlab.winehq.org/giomasce/minitestbot Here is the train of thoughts that brought to MiniTestBot: * As you say, accessing the TestBot/CI environment is hard: the interface is limited and people have to share the available time, so if many people are hitting the TestBot/CI at the same time they have to wait for each other's job, which can be frustrating. * Much better it would be if you could run the TestBot/CI's environment directly on your hardware. Then you don't compete with others anymore and you can interact with your VM however you please, including changing settings and installing stuff. * As you say, the problem is that we can't just distribute Windows images. But we can distribute the scripts used to generate them, which is essentially what MiniTestBot does! The MiniTestBot user needs to independently provide the Windows ISO (Microsoft distributes them for free, at least for some Windows versions) and is directly responsible for complying with licenses, while distributing the scripts does not infringe any copyright, as they are all free software and free of Microsoft intellectual property. Though I am not a lawyer, so don't take this as legal advice! :-) * If the TestBot/CI used images generated with these scripts (or, rather, what they would become after having made better) we'd have both the possibility to run tests in the cloud, which is handy for many reasons, and the possibility to run them on premises in the same environment, which is handy in other cases. I hope that would help to remove at least some of the frustration of debugging tests on Windows. In practice MiniTestBot is a few scripts that take a Windows image and (nearly) automatically create an image out of it, together with other scripts to submit job to be automatically be executed inside that image, TestBot style. It is really a proof of concept at this stage, but I'm already finding it useful for development. At least another person in CodeWeavers told me they find it useful. It would require some more work to be integrated in the TestBot/CI, but that work shouldn't be impossible to do. What do you think of this approach? Also, I am happy to receive comments, suggestions and MRs (yes, those too!) for MiniTestBot. Gio.

1 0

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 21 Oct '23

21 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.

2 1

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>

2 1

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

20 Oct '23

On Fri, 20 Oct 2023, Eric Pouech wrote: [...] > I've tried to repro a couple of them locally, recreating the docker image with > the docker script... to no avail I have a question on that subject: how do you run the Wine tests in your local docker image? The reason I ask is that reproducing GitLab CI's container and using it for builds is pretty easy. But running the tests in it requires starting X and the commands (in test.yml) for that are not directly usable outside the GitLab environment. So do you copy/paste all the xinitrc, startx, wine-mono & co stuff to a script, append the ./wine command you want to run at the end and do something like "docker run gitlab-debian12 ./myscript"? That also assumes mounting the current directory somewhere in the container but having a script that does echo >~/.xinitrc sounds like a disaster waiting to happen if it's accidentally run in the wrong environment. Or did you add a RUN directive in the Dockerfile to start X and then 'docker exec' your test in it? I feel like it would be nice if tools/gitlab contained a script or something to make this whole process easier. Developers have actually asked me [1] "how can I replicate the GitLab CI environment" a few times already. [1] Why ask me? Am I the GitLab CI maintainer now? -- Francois Gouget <fgouget(a)codeweavers.com>

1 0

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