November 2024 - Wine-gitlab

[PATCH 0/1] MR6765: winegcc: Skip --no-default-config in find_libgcc.
by Jacek Caban (＠jacek) 04 Nov '24

04 Nov '24

The default config provides a valid way of defining the default compiler’s libgcc (or its equivalent). Future llvm-mingw will use it instead of shell wrappers. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6765

2 1

[PATCH 0/1] MR6764: kernelbase: Add undocumented EXTENDED_FLAGS to process attribute list.
by eric pouech (＠epo) 04 Nov '24

04 Nov '24

Let the sub-process be created, without implementing any additional behavior from these flags. Native cmd.exe uses this flag when spawning itself again for handling builtin commands inside a pipe. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6764

2 1

[PATCH 0/3] MR6763: dplayx fixes
by Alistair Leslie-Hughes (＠alesliehughes) 04 Nov '24

04 Nov '24

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) 03 Nov '24

03 Nov '24

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) 02 Nov '24

02 Nov '24

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) 02 Nov '24

02 Nov '24

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) 02 Nov '24

02 Nov '24

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) 02 Nov '24

02 Nov '24

> 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) 02 Nov '24

02 Nov '24

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) 02 Nov '24

02 Nov '24

Zhiyi Zhang (@zhiyi) commented about dlls/comctl32/tests/toolbar.c: > > static void *alloced_str; > > -static LRESULT parent_wnd_notify(LPARAM lParam) > +#define TEST_WM_NOTIFY_IDFROM 0xabcd0002 > +#define TEST_WM_NOTIFY_CODE 0xabcd0003 > +#define TEST_WM_NOTIFY_RETURN 0xabcd0004 > +static BOOL expecting_test_WM_NOTIFY; > +static const NMHDR test_WM_NOTIFY_nmhdr = > +{ > + /* .hwndFrom should not be accessed */ > + .hwndFrom = (HWND)0xabcd0001, Let's add a TEST_WM_NOTIFY_HWND as well for this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6737#note_86458

1 0