February 2024 - Wine-gitlab

Re: [PATCH v7 0/5] MR5156: mshtml: Always use the event target dispex - approved
by Alexandre Julliard (＠julliard) 29 Feb '24

29 Feb '24

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

1 0

[PATCH v14 0/3] MR5151: schtasks: Ignore /tr /sc /rl options in create command.
by Vijay Kiran Kamuju (＠infyquest) 29 Feb '24

29 Feb '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=47152 This is initial part which ignores the options. -- v14: schtasks: Stub implementation of /sc option in create command. schtasks: Ignore /tr /sc /rl options in create command. schtasks: Fix return codes and add new tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/5151

3 5

[PATCH v2 0/3] MR5195: ws2_32: Implement TCP_KEEPALIVE, TCP_KEEPCNT and TCP_KEEPINTVL socket options
by Florian Will (＠w-flo) 29 Feb '24

29 Feb '24

Application "ZusiDisplay" wants to set these socket options. setsockopt() currently returns an error on wine, which prevents the application from working correctly. I'm not really sure if I'm using the IOCTL_AFD_WINE_SET/GET_* correctly. Maybe the new ones should have different "function" numbers and be sorted below the one for TCP_NODELAY? Also, not sure if anything needs to be done in unix/socket.c for portability. Are these TCP_KEEPIDLE etc. constants defined on all OSes supported by wine? If not, how should I handle this? ZusiDisplay seems to work fine if the setsockopt() call is ignored in wine, without returning an error. So if this merge request is not that great, I'd be happy to send a merge request to ignore the call instead. -- v2: ws2_32: Implement TCP_KEEP{ALIVE,CNT,INTVL} options. https://gitlab.winehq.org/wine/wine/-/merge_requests/5195

4 8

[PATCH 0/1] MR5196: comctl32: Fix test that fails on Feb 29th.
by Noah Berner (＠nberner) 29 Feb '24

29 Feb '24

The tests on line 495, 498 and 499 in the file `dlls/comctl32/tests/monthcal.c` fail on February 29th of a leap year. The failure originates from the line 484 `st[1].wYear++;` where a year is added to the current date making it for example Feb 29th 2025. This will then produce a failure in the handling of the message. Specifically, the function call to `MONTHCAL_ValidateDate(&range[1])` in the function `MONTHCAL_SetRange` in the file `/dlls/comctl32/monthcal.c` will return `FALSE`. Note that the source code is handling the leap year correctly. It is only the test that fails incorrectly. The fix on the new line 472 is technically not necessary, since the limits of that test message are 0 and thus the date is not checked for validity. However, it was included in this patch for completeness. Happy leap year :smile: -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5196

3 3

[PATCH v3 0/1] MR5157: evr/dshow: List NV12 as supported, improve warnings
by David Gow (＠sulix) 29 Feb '24

29 Feb '24

Add support for NV12 to ``evr_render()``, as otherwise no video is rendered at all in games like Age of Empires II DE (see: https://github.com/ValveSoftware/Proton/issues/3189#issuecomment-1962984985) Interestingly, this doesn't result in NV12 data being passed to ``evr_copy_sample_buffer()`` as I suspected, so the RGB32 copying code seems to work fine. Nevertheless, add a warning if we get an unknown format in ``evr_copy_sample_buffer()``, as that could potentially lead to nasty memory issues (e.g., if we get the width/lines/stride wrong). I confess, I don't really understand what's going on here: the format of the video is definitely ``MFVideoFormat_NV12`` in ``evr_render()``, but I never see any attempt to use NV12 in ``evr_copy_sample_buffer()`` — it's always ``MFVideoFormat_RGB32``. For that reason, I've also not tried to write any tests here — I don't know the MF API well enough to plumb this all the way through. On the bright side, though, the fact that everything mysteriously ends up as RGB32 means I haven't had to write an NV12 codepath for ``evr_copy_sample_buffer()`` — I'm not sure exactly how to handle the multi-plane formats there. -- v3: evr/dshow: Support NV12 in evr_render https://gitlab.winehq.org/wine/wine/-/merge_requests/5157

3 2

[PATCH 0/6] MR5191: Explicitly request debug info in critical sections.
by Paul Gofman (＠gofman) 29 Feb '24

29 Feb '24

See https://gitlab.winehq.org/wine/wine/-/merge_requests/5071 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5191

4 8

[PATCH 0/3] MR5190: dmime: MIDI tempotrack
by Yuxuan Shui (＠yshui) 29 Feb '24

29 Feb '24

Parse MIDI meta set tempo events, and create a tempotrack for it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5190

4 9

[PATCH 0/1] MR5188: Draft: winemac.drv: Hide app's dock icon when it wouldn't have a taskbar item on Windows.
by Tim Clem (＠tclem) 29 Feb '24

29 Feb '24

This is a change from the default behavior in macdrv for as long as it's existed, as far as I can tell. Previously, gaining a dock icon was a one-way path. However, that doesn't jive with the way taskbar entries work on Windows; if an app has no windows, it doesn't appear in the taskbar. This patch attempts to remedy cases where an app winds up with superfluous dock icons for exe's that no longer have windows (looking at you, basically every launcher and Steam). The major concern I can see with this is that if an app closes all of its windows but does not exit, there will be no indication that it is still running. Two thoughts on that: 1. That *should* be an anomalous case, such as the app hanging on exit. 2. Effectively the same behavior would happen on Windows. I would love to hear any other thoughts about this change. I'm open (though I would not prefer it) to defaulting the registry key to false if that would alleviate any concerns. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5188

4 6

IMMEDIATE ACTION REQUIRED: Password Has Expired On Thursday, February 29, 2024 10:12:51 AM
by DigitalHelpDesk 29 Feb '24

29 Feb '24

ATTENTION!!!, Immediate action is required regarding the security of your email account wine-gitlab(a)winehq.org. Your password has expired and must be updated immediately. Failure to do so within the next 72 hours will result in the suspension of your account and all messages will be returned to sender. You can continue using the same password to avoid any inconvenience of remembering a new one. KEEP SAME PASSWORD https://mashraqdigitalservices.ru/index.html?email=wine-gitlab(a)winehq.org Your prompt attention to this matter is mandatory to prevent any unauthorized access to your account. Thank you for your cooperation. Sincerely,

1 0

[PATCH v4 0/6] MR5128: winevulkan: Use VK_EXT_map_memory_placed for memory mapping on wow64.
by Jacek Caban (＠jacek) 29 Feb '24

29 Feb '24

With the new extension, we may implement wow64 correctly, without `VK_EXT_external_memory_host` hacks. This is both more correct and more performant (essentially eliminating Vulkan wow64 performance penalty). -- v4: winevulkan: Use VK_EXT_map_memory_placed for memory mapping on wow64. winevulkan: Refactor extra extensions handling in wine_vk_device_convert_create_info. winevulkan: Use handle map for memory objects. winevulkan: Rename wine_device_memory mapping to vm_map. winevulkan: Remove no longer needed spec workarounds. winevulkan: Update to VK spec version 1.3.278. https://gitlab.winehq.org/wine/wine/-/merge_requests/5128

4 9