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

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

18 Mar '25

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) 18 Mar '25

18 Mar '25

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 18 Mar '25

18 Mar '25

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) 18 Mar '25

18 Mar '25

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) 18 Mar '25

18 Mar '25

-- 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 18 Mar '25

18 Mar '25

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) 18 Mar '25

18 Mar '25

-- 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) 18 Mar '25

18 Mar '25

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) 18 Mar '25

18 Mar '25

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

1 0

Re: [PATCH v3 0/1] MR5052: krnl386: Restore simulated real mode interrupts.
by Alex Henrie (＠alexhenrie) 18 Mar '25

18 Mar '25

On Mon Mar 17 22:03:12 2025 +0000, Alexandre Julliard wrote: > You should add a separate handler just for what the app needs, instead > of forcing all handlers to support real-mode pointers. > I added an example in 7e3bfd4e5e4f9ca689e1734da05a90b1b14351c9, it seems > to work here but it could be extended if necessary. I see what you mean now about having a separate handler. I still don't understand why it's better to have two implementations of the DOS "get volume serial number" ioctl, a more realistic implementation in [int21.c](https://gitlab.winehq.org/wine/wine/-/blob/6298b0cab2086ae61f46b28… and a less realistic implementation in [int31.c](https://gitlab.winehq.org/wine/wine/-/blob/6298b0cab2086ae61f46b28…, or why it's hard to support real-mode pointers (the original [CTX_SEG_OFF_TO_LIN](https://gitlab.winehq.org/wine/wine/-/commit/526b245237… macro seemed to work just fine). But the two-implementation solution works, so my unresolved questions are just curiosities at this point. Thank you very much for taking the time to fix Myst. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5052#note_98205

1 0