December 2025 - Wine-gitlab

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters.
by Paul Gofman (＠gofman) 18 Dec '25

18 Dec '25

I was worrying that it may be treated as negative value by some apps rather than being too big. But yes, we have those bogus '-1' here and there and are probably to address those at once for all the cases later. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769#note_125815

1 0

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters.
by Hans Leidekker (＠hans) 18 Dec '25

18 Dec '25

It has to be '-1' for this bug. We have used this value for a long time so I'm not too worried about apps tripping over such a high value. If we do find them we could scale the values down to the 0-100 range or so (I've seen 25 for an ethernet adapter and 75 for the loopback adapter). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769#note_125814

1 0

[PATCH 0/1] MR9795: comctl32: Set default acceleration values for up-down controls.
by Sven Baars (＠sbaars) 18 Dec '25

18 Dec '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57516 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9795

3 2

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters.
by Paul Gofman (＠gofman) 18 Dec '25

18 Dec '25

I see, thanks. I did a bit of ad-hoc tests to see the metrics in both GetAdapterAddresses and GetIpForwardTable, and while the values between the two are different on Windows (unlike Wine), loopback has the higher value in GetIpForwardTable on Windows as well. My slight concern is that '-1' value looks special and not something I ever observe on Windows. Maybe we'd ideally go with some other value, like INT_MAX for such cases, will that work for the bug? We get '-1' on Linux now for some cases, e. g., here it is the case for interfaces not connected to network (Windows still has low values for those interfaces and e. g. my unplugged 'eth0' appears first in GetAdaptersAddresses with metric of 5). I guess we'd ideally want to fixup those too for some int-positive values? But just setting loopback metric to INT_MAX should work too I guess to fix the present bug, '-1' for other interfaces looks not directly related. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769#note_125811

1 0

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters.
by Hans Leidekker (＠hans) 18 Dec '25

18 Dec '25

It's adapter order from GetAdapterAddesses(). Linux doesn't have a concept of interface metric so we have to pick some value. The Windows machines I checked consistently assign a higher metric to the loopback interface compared to the ethernet interface so it sorts after and it's clear that applications depend on getting a non-loopback adapter first. This user's is running Wine in a container and the adapter with a routeable address in that container gets the highest metric which means that after that commit the loopback adapter sorts before it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769#note_125810

1 0

Re: [PATCH 0/1] MR9769: nsiproxy.sys: Assign the highest metric value to loopback adapters.
by Paul Gofman (＠gofman) 18 Dec '25

18 Dec '25

I am going to do a bit of tests around that. As that looks a bit weird to me, in principle interface or route metric estimates a cost of interface or route connection, why would it be maximum for loopback interface? The issue is complicated by the fact that Windows distinguishes route and interface metrics while the latter is mostly unsupported on Linux, and in nsi / iphlpapi we sort of establish equivalence between the two. So potentially different things may go wrong here. Do we know exactly what the app calls and what depends on? Is that adapter order from GetAdapterAddesses or maybe metric attribute itself? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9769#note_125809

1 0

[PATCH 0/1] MR9794: ntdll: Add more information to error message.
by Bernhard Übelacker (＠bernhardu) 18 Dec '25

18 Dec '25

If a user creates the wineprefix, with only 64-bit packages installed, the user gets an empty syswow64 directory inside the prefix. In that situation 64-bit applications are running, but when the user then installs the 32-bit packages the prefix stops to work with this message, even when the application to invoke is a 64-bit application and worked before: ``` wine: could not load kernel32.dll, status c0000135 ``` To help diagnosing this sitution this patch adds some more information which process could not find which kernel32.dll. This would look like this: ``` wine: could not load kernel32.dll, status c0000135, architecture wow64, in L"C:\\windows\\syswow64\\start.exe" ``` This caused probably bug #59043, and it bite me today again, when copying build directories to a ancient machine to save build time. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9794

2 1

[PATCH v2 0/2] MR9789: winebus: Use smallest report size for joystick axis
by SeongChan Lee (＠foriequal0) 18 Dec '25

18 Dec '25

Some games don't handle 32-bit sized joystick axes well. Assetto Corsa Rally, which was released a month ago as an early access and is still v0.1, is a recent example. The proof of concept 16-bit patch resolves the problem for many users and hardware on Linux, (https://github.com/ValveSoftware/Proton/issues/9220#issuecomment-3647591465) and users with open-source hardware confirmed the behavior of the game on Windows. Since it's the case that the game is non-compliant while the wine is perfectly compliant, we might be able to push and wait for the developer to release the fix, but I believe that the fix will also help to improve compatibility for some old, non-maintained, non-compliant games. -- v2: winebus: Use 16-bit relative axis range for bus_sdl https://gitlab.winehq.org/wine/wine/-/merge_requests/9789

3 9

Re: [PATCH 0/1] MR9761: urlmon/tests: Don't test function directly when reporting GetLastError()
by Alexandre Julliard (＠julliard) 18 Dec '25

18 Dec '25

That sort of thing shouldn't be necessary anymore since a9edbf49ae71df7904193b9fb99240727920fb48. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9761#note_125802

1 0

[PATCH v6 0/2] MR9660: jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter in ES5+ modes.
by Gabriel Ivăncescu (＠insn) 18 Dec '25

18 Dec '25

-- v6: mshtml: Handle DISPATCH_PROPERTYGET | DISPATCH_METHOD in dispex_value as jscript: Treat DISPATCH_PROPERTYGET | DISPATCH_METHOD as property getter https://gitlab.winehq.org/wine/wine/-/merge_requests/9660

3 4