March 2025 - Wine-gitlab - list.winehq.org

[PATCH v3 0/2] MR7119: ntdll, loader: Add __attribute__((used)) to a few symbols that shouldn't be discarded.
by William Horvath (＠whrvth) 04 Mar '25

04 Mar '25

These changes are enough to allow building the entirety of the native (ELF) side with `-flto`. -- v3: loader: Mark thread_ldt, thread_data, wld_start "used". ntdll: Mark call_init_thunk and abort_thread "used". https://gitlab.winehq.org/wine/wine/-/merge_requests/7119

4 5

Re: [PATCH v26 0/1] MR6884: Iphlpapi.dll: Included SendARP
by Thi Garlet (＠garlett) 03 Mar '25

03 Mar '25

On Mon Mar 3 23:25:58 2025 +0000, Huw Davies wrote: > It would be better to implement `SendARP()` in terms of `ResolveIpNetEntry2()`. > Further, `ResolveIpNetEntry2()` should likely use the `Nsi` functions to > retrieve the neighbour info from `nsiproxy`. I think I saw ResolveIpNetEntry2() function documentation in the past. Maybe because I could not find sources(help please), end up not using it. Or I asked somebody. Not sure. Does ResolveIpNetEntry2() need linux privileges ? Thanks -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6884#note_96714

1 0

[PATCH 0/1] MR7461: remove "Broken NVIDIA RandR detected" error line
by Andrey Zhukov (＠HP) 03 Mar '25

03 Mar '25

I am proposing to do something about the "Broken NVIDIA RandR detected" error line, i think that this error serves no good purpose. Motivation: * fallback Firstly, if wine merely switches to a fallback in case of a problem - that's not an error, that's an expected and handled issue that is successfully worked around. If there are potential issues with the workaround - that's what should be noted. Programs run with wine do work well (enough) when this "error" is present. I do understand that you can change certain settings to change the codepath so that this error to not appear, is this actually necessary to fix an actual problem? Sending someone on a path to fix this "error" when the program they're running is working perfectly well is not a great thing. * calling it an error More commonly, wine output is ignored when everything is running correctly, and only looked at when problems arise, so if you log an "error" around the time that a different issue happens it is reasonable to assume that the user will treat the error as the cause of the problem. So we end up with lots of threads like this: https://forum.winehq.org/viewtopic.php?t=32583 quote: "Please don't title a forum thread with:Broken NVIDIA RandR detected, falling back to RandR 1.0. **This is totally meaningless and does not provide any description - what-so-ever - of what the thread is about. ** Wine outputs this terminal message, for anyone using the Nvidia proprietary driver. Whether they have a crappy, ancient video card or a shiny new Geforce RTX 2080 Ti ! **I patch out this warning message, on my Gentoo wine ebuild's, because it is so annoying.** * error spam So it confuses inexperienced users very much. I shouldn't have to point out the search engine keyword irrelevancy. But even for experienced users (the quoted user uses gentoo), it is annoying enough to patch out. If the quoted example wasn't enough here's a random pastebin from 2022 i found removing the line: https://pastebin.com/6auSsL4B, and i've got at least one personal example of someone patching the error out. It is repeated just too frequently. Spam makes reading more important errors harder too. * recommending nouveau This line is in a codepath commonly used in games. Recommending nouveau to usually inexperienced linux users - gamers is a horrible idea. Don't get me wrong, i'm all for a free solution, i'd love for nouveau to be just as good, but it is simply not. For a user without a reasonable understanding of linux a messup with video drivers costs a complete reinstall. Mindshare of free software is probably out of scope for wine, but i'm sure we can agree there's some general value there. There is a wiki entry about this error: https://gitlab.winehq.org/wine/wine/-/wikis/FAQ#broken-nvidia-randr-detecte… It all generally makes sense, and if you read it carefully it does say "for users who do not need the proprietary driver", but for an inexperienced user that's an encouragement that assumes they do not in fact need the proprietary driver. Also if you do understand what RandR is you're likely to understand that a program not launching for example probably isn't related to the "error", though i think even a knowing user would still consider it a possibility. * keywords used The workaround described under that is of legitemate value, but i think the correlation between the "error" keywords and the actual problematic behavior is not great. If we wish to point the user towards the workaround the line should be something along the lines of "program starts fullscreen at low resolution". * code I am not a maintainer and am not experienced enough to just pick up a codebase like this, so i'll start off with admitting i don't really know the specifics of the code. But just by looking at it, the comment on line 511 in dlls/winex11.drv/xrandr.c says that the check that causes the "error" line to print just checks if the driver is nvidia? Isn't that not even checking the specific behavior that it supposedly doesn't implement? (if it was fixed since that code was written) Proposed solutions: Plain and simple - delete the line. This would solve all the problems mentioned above, perhaps with the exception of >keywords used. This pull request. Change the message type to debug or trace or similar. This would address >calling it an error Only print error on first use of function or in startup. This would address >error spam -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7461

4 5

[PATCH 0/6] MR7436: d3dx9: More changes to D3DXSaveSurfaceToFileInMemory().
by Connor McAdams (＠cmcadams) 03 Mar '25

03 Mar '25

This patch series reworks `D3DXSaveSurfaceToFileInMemory()` to use the new `d3dx_save_pixels_to_memory()` function. It also adds support for selecting a replacement pixel format when the image file format being saved to doesn't have direct support for the pixel format being saved. The code for calculating the best replacement format was inspired by the code in `check_texture_requirements()` in `d3dx9_36/texture.c`. This should fix WineHQ bug 51584, but I haven't tested that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7436

3 11

[PATCH v4 0/10] MR7407: windowscodecs: Implement query strings enumerator.
by Nikolay Sivov (＠nsivov) 03 Mar '25

03 Mar '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v4: windowscodecs: Implement GetPreferredVendorGUID(). windowscodecs/metadata: Implement GetClassID(). windowscodecs/tests: Add some tests for metadata handler GetClassID(). windowscodecs/metadata: Replicate original stream position when creating writer instances from readers. windowscodecs/metadata: Restore original stream position on GetStream(). windowscodecs/tests: Add some tests for stream position handling when nested readers are used. windowscodecs: Implement CreateQueryWriterFromReader(). windowscodecs/metadata: Do not decorate 'wstr' items with a type name in returned queries. windowscodecs/tests: Add some more tests for query enumeration. windowscodecs: Implement query strings enumerator. https://gitlab.winehq.org/wine/wine/-/merge_requests/7407

3 14

[PATCH v29 0/1] MR7400: cmd: Allow any key to continue past DIR /P pauses.
by Joe Souza (＠JoeS209) 03 Mar '25

03 Mar '25

Current code requires entering a newline character in order to continue past DIR /P prompts. This change allows any key to be pressed instead. Code to handle this was similar to existing WCMD_pause() so we leveraged that code for this purpose as well. Key to the fix was the removal of ENABLE_LINE_INPUT from the console flags, and ENABLE_PROCESSED_INPUT was added in order to preserve the ability to abort the operation via Ctrl-C. -- v29: cmd: Allow any key to continue past DIR /P pauses. https://gitlab.winehq.org/wine/wine/-/merge_requests/7400

2 1

Re: [PATCH v2 0/1] MR7477: include: Add some flags constants used in pipes API. - approved
by Alexandre Julliard (＠julliard) 03 Mar '25

03 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7477

1 0

Re: [PATCH v2 0/1] MR7476: ws2_32/tests: Allow WSAConnectByNameA test to fail with WSAEOPNOTSUPP. - approved
by Alexandre Julliard (＠julliard) 03 Mar '25

03 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7476

1 0

Re: [PATCH v3 0/1] MR7473: winetest: Avoid underflow when computing filtered output size. - approved
by Alexandre Julliard (＠julliard) 03 Mar '25

03 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7473

1 0

Re: [PATCH v3 0/1] MR7438: wbemprox: Add Manufacturer and Speed to Win32_PhysicalMemory. - approved
by Alexandre Julliard (＠julliard) 03 Mar '25

03 Mar '25

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7438

1 0