February 2024 - Wine-GitLab

Re: [PATCH v5 0/1] MR5184: winecrt0: Use load config on all targets. - approved
by Alexandre Julliard (＠julliard) Feb. 29, 2024

Feb. 29, 2024

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

1 0

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

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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) Feb. 29, 2024

Feb. 29, 2024

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 Feb. 29, 2024

Feb. 29, 2024

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