- Wine-Devel - list.winehq.org

Wine staging 8.19 release
by Alistair Leslie-Hughes Oct. 30, 2023

Oct. 30, 2023

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 Oct. 23, 2023

Oct. 23, 2023

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 Oct. 20, 2023

Oct. 20, 2023

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 Oct. 20, 2023

Oct. 20, 2023

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 Oct. 16, 2023

Oct. 16, 2023

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 Sept. 30, 2023

Sept. 30, 2023

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 Sept. 27, 2023

Sept. 27, 2023

* 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 Sept. 16, 2023

Sept. 16, 2023

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 Sept. 15, 2023

Sept. 15, 2023

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

Wine staging 8.15 release
by Alistair Leslie-Hughes Sept. 2, 2023

Sept. 2, 2023

Binary packages for various distributions will be available from: https://www.winehq.org/download Summary since last release * Rebased to current wine 8.15 (496 patches are applied to wine vanilla) Upstreamed (Either directly from staging or fixed with a similar patch). * None. Added: * None Updated: * vkd3d-latest to latest. * user32-rawinput-mouse * mshtml-TranslateAccelerator 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