November 2024 - Wine-GitLab

[PATCH 0/3] MR6763: dplayx fixes
by Alistair Leslie-Hughes (＠alesliehughes) Nov. 4, 2024

Nov. 4, 2024

This patchset does includes a patch from another patchset, which I'll rebase once this one is accepted. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6763

3 4

[PATCH 0/4] MR6733: Mfplat HTTP byte stream implementation
by Torge Matthies (＠tmatthies) Nov. 3, 2024

Nov. 3, 2024

This has been tested with VRChat in Proton, and with one change to `IMFMediaEngine` and some small changes to winegstreamer it is able to play YouTube videos in Unity video player based players. The AVPro based players have many more issues, because that API uses YouTube's HLS files instead of the direct MP4 links, and new media source would need many fixes to be able to play HLS correctly. Which it isn't supposed to do anyway since that's the `IMFMediaEngine`'s job. There are some things that I did not implement: - `IMFByteStreamBuffering::SetBufferingParams`, the parameters don't have any obvious effect on the functionality of the byte stream or the HTTP requests it makes. It's probably not used by anything anyway. - How much data has to be pre-buffered before it considers buffering to be complete and sends `MEBufferingStopped`. I didn't put much time into this and just chose 64 KiB. - Persistent caching of downloaded data; Native seems to be able to omit redownloading data it has previously downloaded before by using the `If-Modified-Since` header. This seems like more work and unnecessary complexity than it's worth. - Mapping of all the WinHTTP errors to HRESULTs; HTTP status codes are handled, as well as the most common `ERROR_WINHTTP_*` values, but anything else just goes through `HRESULT_FROM_WIN32`. I don't even know how to trigger most of the WinHTTP errors; It's probably fine, the most important info is just that there has been an error anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6733

4 39

Re: [PATCH v3 0/2] MR6584: wintab32: Improve wow64 support
by John Chadwick (＠jchw) Nov. 2, 2024

Nov. 2, 2024

FWIW, as far as I'm concerned, this or a similar patch should probably still be merged, to fix the wow64 stub. It basically just comes down to the approach to fix it. If anyone gets a chance to look at this let me know. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6584#note_86467

1 0

[PATCH v4 0/1] MR6285: shell32: Allow FindExecutables to find unix files.
by Alistair Leslie-Hughes (＠alesliehughes) Nov. 2, 2024

Nov. 2, 2024

This fixes one of the regression with ShellExecute when using a full patch and an executable without an extension. -- v4: shell32: Allow FindExecutables to find unix files. https://gitlab.winehq.org/wine/wine/-/merge_requests/6285

2 1

Re: [PATCH v7 0/2] MR6737: comctl32/toolbar: forward unhandled WM_NOTIFY
by Alanas (＠BZZZZ) Nov. 2, 2024

Nov. 2, 2024

On Sat Nov 2 08:52:23 2024 +0000, Zhiyi Zhang wrote: > This `else` branch should never get executed because only the > test_WM_NOTIFY() test sends a WM_NOTIFY with TEST_WM_NOTIFY_CODE. So you > can delete this branch. `else` branch will be executed if WM_NOTIFY message gets forwarded twice by buggy non-test code -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86464

1 0

Re: [PATCH v7 0/2] MR6737: comctl32/toolbar: forward unhandled WM_NOTIFY
by Alanas (＠BZZZZ) Nov. 2, 2024

Nov. 2, 2024

> With this change, unhandled notifications are all forwarded to hwndNotify and I worry that it might not be the case. Yes, windows does have more handled notifications. There are notifications that don't get forwarded. There are notifications that `nmhdr->code` overwritten and get forwarded. Not all notifications have `nmhdr->code` that is equal to a macro in mingw-w64's [commctrl.h](https://github.com/mingw-w64/mingw-w64/blob/e3a3dc588a6358bda82… and [prsht.h](https://github.com/mingw-w64/mingw-w64/blob/e3a3dc588a6358bda82693…. See https://bugs.winehq.org/attachment.cgi?id=77351&action=edit and https://bugs.winehq.org/attachment.cgi?id=77352&action=edit. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86463

1 0

[PATCH 0/2] MR6759: kernelbase: Make trailing slashes in CreateFileW set ERROR_PATH_NOT_FOUND
by Fabian Maurer (＠DarkShadow44) Nov. 2, 2024

Nov. 2, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57376 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6759

4 4

Re: [PATCH v7 0/2] MR6737: comctl32/toolbar: forward unhandled WM_NOTIFY
by Zhiyi Zhang (＠zhiyi) Nov. 2, 2024

Nov. 2, 2024

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/toolbar.c: > } > } > > return TRUE; Please add a dot at the end of the commit subject. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86460

1 0

Re: [PATCH v7 0/2] MR6737: comctl32/toolbar: forward unhandled WM_NOTIFY
by Zhiyi Zhang (＠zhiyi) Nov. 2, 2024

Nov. 2, 2024

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/toolbar.c: > return 0; > > default: With this change, unhandled notifications are all forwarded to hwndNotify and I worry that it might not be the case. Please add tests for [pager notification codes](https://learn.microsoft.com/en-us/windows/win32/controls/bumper-page… and [tooltips notification codes](https://learn.microsoft.com/en-us/windows/win32/controls/bumper-tool…. Also add a TRACE() when forwarding notifications to hwndNotify. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86461

1 0

Re: [PATCH v7 0/2] MR6737: comctl32/toolbar: forward unhandled WM_NOTIFY
by Zhiyi Zhang (＠zhiyi) Nov. 2, 2024

Nov. 2, 2024

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/toolbar.c: > > return 0; > } > + case TEST_WM_NOTIFY_CODE: > + if (expecting_test_WM_NOTIFY) > + { > + ok(hdr == &test_WM_NOTIFY_nmhdr, "Got unexpected header.\n"); > + ok(wParam == TEST_WM_NOTIFY_IDFROM, "Got unexpected wParam 0x%Ix.\n", wParam); > + } > + else This `else` branch should never get executed because only the test_WM_NOTIFY() test sends a WM_NOTIFY with TEST_WM_NOTIFY_CODE. So you can delete this branch. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86459

1 0