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

[PATCH 0/1] MR3862: user32/tests: Ignore other messages in test_broadcast.
by Esme Povirk (＠madewokherd) March 18, 2025

March 18, 2025

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54194 If the SendMessageTimeout call takes a long time, we can get other messages which also set the observed wparam value. Apparently, this is especially likely on Windows 7. This also removes the (wParam == 0xbaadbeef) check which may have been intended to serve the same goal but doesn't work because the observed wParam value is still assigned. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3862

3 2

[PATCH v3 0/1] MR7344: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow.
by Dmitry Timoshkov (＠dmitry) March 18, 2025

March 18, 2025

Original patch description https://www.winehq.org/pipermail/wine-patches/2017-February/157574.html winehq.org no longer provides the wine-patches archives, so it's necessary to dig into [web.archive.org](https://web.archive.org/web/20211011014926/https://www.win…: https://web.archive.org/web/20211011014926/https://www.winehq.org/pipermail… https://web.archive.org/web/20211011014930/https://www.winehq.org/pipermail… =================================================================== Based on a patch by Dmitry Timoshkov. ## Signed-off-by: Sebastian Lackner sebastian(a)fds-team.de Fixes https://bugs.winehq.org/show_bug.cgi?id=33943. Battle.Net initially creates completely transparent popup windows and afterwards uses UpdateLayeredWindow without hdcSrc to let them fade in. Testing confirms that this works fine on Windows - on Wine however the original content is lost and no longer available. To avoid that, this patch stores the original content in the surface and uses \_NET_WM_WINDOW_OPACITY to create a transparency effect. The same method is already used by SetLayeredWindowAttributes. If compositing is disabled, the window content will be visible immediately. Dmitrys original patch used a different approach, and manually implemented the alpha blending in x11drv_surface_flush using additional buffers, however this shouldn't really be necessary (yet). We can still use it later if there is any benefit compared to using \_NET_WM_WINDOW_OPACITY. -- v3: winex11: Fix alpha blending in X11DRV_UpdateLayeredWindow. https://gitlab.winehq.org/wine/wine/-/merge_requests/7344

3 9

[PATCH v3 0/1] MR7594: msvcrt: Add _IONBF flag check in _filbuf to avoid dead loop in application which sets the flag.
by Kun Yang (＠yangkun) March 18, 2025

March 18, 2025

Signed-off-by: Kun Yang <yangkun(a)uniontech.com> Change-Id: Ia68e11ccb0aa563eeb73a2f5cb93afcd328e1937 [fgetws_test.7z](/uploads/7b706f2c4f639e4260c548d834658b32/fgetws_test.7z) If the application calls setvbuf(.., _IONBF, ..) before fgetws, wine sets the flag. In fgetws, this flag is not checked. read_i is called with paramenter count 1 which is not allowed in read_i implemantion. Function read_i returns -1 and the file stream is not actually read by program. The file pointer is not moved. If the application writes fgetws in a loop, it never reach EOF and falls in dead loop. By adding check for _IONBF in _filbuf, the application will run into another branch(file->_bufsiz=2). Thats's correct. Please checkout the example in my attachment. This application exits normally in Windows but falls in dead loop in wine. -- v3: msvcrt: Add MSVCRT__NOBUF flag check in _filbuf to avoid dead loop in application which sets the flag. https://gitlab.winehq.org/wine/wine/-/merge_requests/7594

3 2

Re: [PATCH v3 0/6] MR7530: win32u, server: Improve tracking mouse messages from pointer messages.
by Rémi Bernon March 18, 2025

March 18, 2025

On Tue Mar 11 14:30:34 2025 +0000, Paul Gofman wrote: > I don't see how to avoid that in principle? > - the logic is triggered by calling DefWindowProc, so we can't avoid > some action from DefWindowProc; > - after WM_POINTERUPDATE with changing coordinates the messages should > be generated (and, separately, updating cursor position) regardless of > DefWindowProc calls; also generating that in DefWindowProc or > accept_hardware_message would be clumsy because > NtUserSendHardwareInput() can't generate the exact message we need, that > would need some custom interface (and won't avoid a server call to send > message anyway); > - we could in principle stop sending those `track_mouse_from_pointer` > calls once the tracking switched to server side (by returning the > corresponding flag from this call and tracking this part of state in > thread data), but we also want to update driver cursor position which > seems to cope nicely with this call, in that case it would need to be > done in some other more complicated ways. So reducing the amount of > those calls (by not sending them once server tracking started) is > possible but it will require these parts. I thought it doesn't add too > much of calls, do you think it worth it? > EDIT: updated. I don't know, this call feels inherently racy and I would like to give it more thought and time to check how windows behave. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7530#note_98225

1 0

[PATCH 0/6] MR7605: PDB rewrite #3
by eric pouech (＠epo) March 18, 2025

March 18, 2025

This serie (PDB rewrite #3) mostly handles the debug information needed to support C++ enum underlying integral type. - it generalizes the use of VARIANT to gather enum values, - to make things simple, in PDB, the type of variant used has nothing to do with the size of the C++ integral type, but is the smallest size to hold the considered enum value, - adapt the dwarf backend to behave the same way as the PDB one, - adapt debugger to support up to 8-bytes variant types. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7605

2 6

[PATCH v7 0/1] MR6938: winewayland.drv: Implement support for xdg-toplevel-icon.
by Etaash Mathamsetty (＠etaash.mathamsetty) March 18, 2025

March 18, 2025

-- v7: winewayland.drv: Implement support for xdg-toplevel-icon. https://gitlab.winehq.org/wine/wine/-/merge_requests/6938

3 2

[PATCH v5 0/2] MR7290: kernelbase: Handle correctly paths with forward slashes in ReplaceFileW.
by Roman Pišl March 18, 2025

March 18, 2025

PathRemoveFileSpecW keeps only the drive if the path contains all forward slashes as shown in tests. But then the temporary file is created in the root folder which fails for drive Z:. This fixes a corner case when using CMake in Wine. Another usage of PathRemoveFileSpecW is in PathRelativePathToW which should be also checked. I'm leaving this as a draft until getting some feedback and adding tests. -- v5: kernelbase: Handle correctly paths with forward slashes in ReplaceFileW. kernel32: Test ReplaceFileW with forward slashes. https://gitlab.winehq.org/wine/wine/-/merge_requests/7290

1 2

[PATCH 0/1] MR7603: kerberos: Fix imported target name leak.
by Dmitry Timoshkov (＠dmitry) March 18, 2025

March 18, 2025

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

3 2

[PATCH v2 0/4] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Yongjie Yao (＠yaoyongjie) March 18, 2025

March 18, 2025

In CopyFileEx, and DeleteFile functions, by default, the file name and path are limited to MAX_PATH characters. To extend this limit to 32,767 wide characters, need prepend "\\\\?\\" to the path. -- v2: kernelbase: Limit the maximum path length for DeleteFile. kernelbase: Fix DeleteFileA doesn't support long path. kernelbase: Limit the maximum path length for filesystem. kernel32/tests: Add tests for maximum path length limitation. https://gitlab.winehq.org/wine/wine/-/merge_requests/7540

3 10

Re: [PATCH v3 0/1] MR5052: krnl386: Restore simulated real mode interrupts. - closed
by Alex Henrie (＠alexhenrie) March 17, 2025

March 17, 2025

This merge request was closed by Alex Henrie. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5052

1 0