- Wine-gitlab - list.winehq.org

[PATCH 0/5] MR9457: comctl32/toolbar: Add a helper to draw the separator.
by Zhiyi Zhang (＠zhiyi) 14 Nov '25

14 Nov '25

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9457

3 6

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) 14 Nov '25

14 Nov '25

> Sure, how about something like MR !9461? Yes. (Only nitpick is that there should be more comments explaining the why.) > Any other variables we should add there? Nothing comes to mind. More can always be added later. > Should we ignore all the SDL_ variables? Wine and forks only use them through `getenv` imported from `<stdlib.h>`, so it shouldn't matter whether they are in the Windows environment if I'm correct. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_122009

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) 14 Nov '25

14 Nov '25

Sure, how about something like MR !9461? Any other variables we should add there? Should we ignore all the SDL_ variables? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_122004

1 0

[PATCH v6 0/4] MR1825: kernelbase/path.c: UrlFixupW()
by Thomas Csovcsity (＠thc13) 14 Nov '25

14 Nov '25

## Summary Tests for UrlFixupW and semi stub function implementaion. ## Test results - Tests are 100% ok on my local WIN 10 pc. Wine test bot seems to be okay too. - Wine tests on debian machine | function type | result | | ------ | ------ | | stub | 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **200** failures), 0 skipped. | | semi stub| 0020:url: 69802 tests executed (0 marked as todo, 0 as flaky, **100** failures), 0 skipped. | ## Todos For follow up merge request(s). - [ ] Add more tests for priority investigation, who url scheme fix up is working on windows. - [ ] Implement missing parts of fix up. ## Conclusion Semi stub implementation is an improvement to the existing solution. A grep showed that wine internals do not call this function, therefore it should not introduce any new bugs. Windows applications using/relying on the function should now work better, if not they may reveal already existing bugs. -- v6: shlwapi: fixup leading and trailing typos in UrlFixupW shlwapi: check for colon in UrlFixupW kernelbase: Restructure UrlFixupW() shlwapi/tests: Add tests for UrlFixupW. https://gitlab.winehq.org/wine/wine/-/merge_requests/1825

3 11

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) 14 Nov '25

14 Nov '25

So, a deny list? Sounds fine to me. (`QT_PLUGIN_PATH` as well.) Though, what about the reversion of d4920360bffddaa5923a8da0b15f3ad9a2a97e78? (Regardless of the deny list.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_122002

1 0

[PATCH v3 0/1] MR7479: wow64win: fix the access exception when the lparam is an address larger than 2G.
by Jiajin Cui (＠jin-king1) 14 Nov '25

14 Nov '25

Signed-off-by: Jiajin Cui <cuijiajin(a)uniontech.com> -- v3: wow64win: change parameter types from LONG to ULONG in wow64_NtUserMessageCall https://gitlab.winehq.org/wine/wine/-/merge_requests/7479

3 6

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Alexandre Julliard (＠julliard) 14 Nov '25

14 Nov '25

> Importing something is better than nothing, and this achieves the goal of keeping popular configuration envars like DXVK_FRAME_RATE. IMO, it is absolutely worth the code bloat. Code bloat is not an issue, I'm more concerned about the unpredictability of which variables will be removed. Maybe now that we have b1e94119f07919991edb1e629090b04e7e8b34a9 we could be more aggressive in removing unneeded vars. For instance it's very unlikely that NIXPKGS variables would be needed by a Windows app. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121997

1 0

Re: [PATCH v4 0/1] MR9423: ntdll: Warn when environment block is too large, instead of removing it
by Martino Fontana (＠tinozzo123) 14 Nov '25

14 Nov '25

As the release approaches, I remain concerned about the breaking changes. I use configuration envars much more frequently than the EA App, meaning this change would require me to apply workarounds everywhere (including the EA App itself) rather than just for one application. This increases the manual intervention burden significantly for users like me. Plus, that EA itself is disincentivizing the use EA App their push of anti-Linux anticheats, so the percentage of users with a big envar block that don't use the EA App is likely substantial. The previous discussion established that [Wine doesn't do breaking changes or workarounds](https://gitlab.winehq.org/wine/wine/-/merge_requests/6140#note…. While other solutions could be explored longer-term, for now it would be best if the next Wine release ships without this breaking change. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9423#note_121996

1 0

Re: [PATCH v5 0/1] MR9418: winex11.drv: use proper timestamp for X11 clipboard selection
by Rémi Bernon 14 Nov '25

14 Nov '25

Rémi Bernon (@rbernon) commented about dlls/winex11.drv/clipboard.c: > + > + if (xevent->type == PropertyNotify && > + xevent->xproperty.window == xwindow && > + xevent->xproperty.atom == x11drv_atom(__wine_timestamp_prop)) > + return True; > + > + return False; > +} > + > + > +/************************************************************************** > + * get_server_time > + * > + * Get the current X11 server timestamp by generating a PropertyNotify event > + */ > +static Time get_server_time( Display *display, Window win ) This looks complicated and we probably don't want to touch the X11 event queue outside of ProcessEvents. There's already `EVENT_x11_time_to_win32_time` which estimates the X server time, and it is used in `set_input_focus` for the same kind of purpose as you need here. It might not be very accurate though, and if you need it to be, maybe it would be better to find a way to detect remote vs local X server and check / assume that a local server uses `clock_gettime` / `CLOCK_MONOTONIC` for its time which I believe most if not all implementations do (or some other clock, I'm not 100% confident). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9418#note_121992

1 0

[PATCH v44 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) 14 Nov '25

14 Nov '25

Follow-up of !2786, which appears to have been abandoned. Depends on !8182, !8575, !8578 # Execute minimal test case 1. checkout wine into \~/src/wine 2. in dlls/ws2_32/tests/sock.c wrap all calls to test functions after `Init()` until `test_afunix()` with #if 0 ... #endif 3. build into \~/src/wine-build 4. run `(cd ~/src/wine-build; WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -q -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock)` # How to debug wineserver Since `wineserver` runs in the background, simple calls to printf() will show nothing when the test case is executed. A workaround is to open a file and call fprintf() to write debug messages to this file, which can then be inspected. # How to debug a wine test case At https://gitlab.winehq.org/wine/wine/-/blob/master/tools/runtest#L151 there is mentioned a environment variable name `WINETEST_WRAPPER`, with which it may be possible to run gdb to debug test cases ``` (cd ~/src/wine-build; make -j10 ; WINETEST_WRAPPER="gdb --args" WINEPREFIX=~/src/wine/.wine ../wine/tools/runtest -P wine -T . -M ws2_32.dll -p dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) Reading symbols from ./wine... (gdb) set follow-fork-mode child (gdb) r current directory: 'Z:\home\ralf.habacker\src\wine-build' sock.c:14624: Test failed: test_afunix.sock: wrong attr ffffffff sock.c:14658: Test failed: test_afunix.sock: wrong family 0 sock.c:14693: Test failed: test_afunix.sock: wrong family 0 ... ``` With this you can debug the wine application, but unfortunally not the windows api. # How to debug a wine test case (windows api) 1. After building wine install the binaries into a temporary location ``` make -C ~/src/wine-build install DESTDIR=~/src/wine-install ``` 2. run ``` (cd ../wine-build; \ WINEPREFIX=~/src/wine/.wine \ WINEDLLOVERRIDES=';ws2_32.dll=b' \ WINETEST_PLATFORM=wine \ ./wine programs/winedbg/i386-windows/winedbg.exe --gdb dlls/ws2_32/tests/i386-windows/ws2_32_test.exe sock) ``` Now let's look at the loaded shared libraries ``` Wine-gdb> info sharedlibrary >From To Syms Read Shared Object Library 0xf7b39000 0xf7bff6e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine/.wine/drive_c/windows/system32/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine/.wine/drive_c/windows/system32/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine/.wine/drive_c/windows/system32/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine/.wine/drive_c/windows/system32/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine/.wine/drive_c/windows/system32/gdi32.dll 0x7a0b1000 0x7a0e48e8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` It is visible, that the unix variant of the shared libraries (ntdll.so) are read from the build dir and also the test case. The Windows part (\*.dll) is loaded from the wine prefix, so that these must be copied from the build directory initially and whenever changes are made. With this is possible to set breakpoints ``` Wine-gdb> b GetFileAttributesW(a)4 Breakpoint 1 at 0x7b5d3725: file ../wine/dlls/kernelbase/file.c, line 1665. Wine-gdb> c Continuing. Breakpoint 1, GetFileAttributesW(a)4 ( name=0x40fcfa <test_afunix+1434> L"\xec83\x8304\xfff8\x940f\x89c0\x247c\xf08\xc0b6\x44c7\x424\x1bbf\103\x489\xe824\x52e6\001\x44c7", <incomplete sequence \x824>) at ../wine/dlls/kernelbase/file.c:1665 1665 TRACE( "%s\n", debugstr_w(name) ); ``` # Followup By adding `WINESYSTEMDLLPATH=/home/user/src/wine-install/usr/local/lib/wine/i386-windows/` to the command line, some shared libraries are loaded directly from the build directory, so they do not need to be copied. ``` >From To Syms Read Shared Object Library 0xf7eb2000 0xf7f786e0 Yes /home/user/src/wine-build/dlls/ntdll/ntdll.so 0x00401000 0x00478e2c Yes /home/user/src/wine-build/dlls/ws2_32/tests/i386-windows/ws2_32_test.exe 0x7bcc1000 0x7bd69280 Yes /home/user/src/wine/.wine/drive_c/windows/system32/ntdll.dll 0x7bb31000 0x7bb91594 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernel32.dll 0x7b5b1000 0x7b841f38 Yes /home/user/src/wine/.wine/drive_c/windows/system32/kernelbase.dll 0x77fd1000 0x77ff89d8 Yes /home/user/src/wine/.wine/drive_c/windows/system32/iphlpapi.dll 0x7b4b1000 0x7b4ebcb8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/advapi32.dll 0x7b1e1000 0x7b280014 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/msvcrt.dll 0x7b151000 0x7b16de40 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/sechost.dll 0x7adf1000 0x7aec2690 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ucrtbase.dll 0x77f71000 0x77f85a80 Yes /home/user/src/wine/.wine/drive_c/windows/system32/dnsapi.dll 0x77f31000 0x77f3b240 Yes /home/user/src/wine/.wine/drive_c/windows/system32/nsi.dll 0x7ad41000 0x7ad6653c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/ws2_32.dll 0x7a111000 0x7a2cc55c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/user32.dll 0x7a631000 0x7a6ae67c Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/gdi32.dll 0x79e31000 0x79e648e8 Yes /home/user/src/wine-install/usr/local/lib/wine/i386-windows/win32u.dll 0x78121000 0x7813de90 Yes /home/user/src/wine/.wine/drive_c/windows/system32/imm32.dll ``` Why this does not apply to all system libraries is currently unclear. -- v44: ws2_32: Add note in bind() for AF_UNIX sockets ws2_32/tests: In tests for AF_UNIX sockets print actual directory used server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. ws2_32: Add support for AF_UNIX sockets. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

3 7