- wine-gitlab - winehq.org

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

02 Nov '24

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

02 Nov '24

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

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

[PATCH v7 0/1] MR5145: opengl32: speed up wow64 mapping
by Etaash Mathamsetty (＠etaash.mathamsetty) 02 Nov '24

02 Nov '24

My hardware is Ryzen 7 4700u with the integrated graphics Flatout (Direct3D 9): 20 fps (renders correctly) Unigine Heaven (OpenGL): ~40-60 fps (renders correctly) Unigine Heaven (Direct3D 9): 20-30 fps (renders correctly) Unigine Heaven (Direct3D 11): 20-30 fps as well (renders correctly) Elder Scrolls IV (Direct3D 9): 20 fps (renders correctly) BeamNG Tech Demo 0.3 (Direct3D 9): 2 fps (renders correctly, but still runs poorly) Massive step up from getting 2 fps across many wined3d games, but it's still pretty bad, ~~and sometimes runs worse than the original code~~. Now with a combination of using the new and old code dynamically you can get the best of both worlds! Unfortunately, we lose the ability to get lucky with the mapping just happening to be in the 32 bit range. -- v7: opengl32: speed up wow64 mapping. https://gitlab.winehq.org/wine/wine/-/merge_requests/5145

4 5

[PATCH 0/4] MR6663: Draft: Placed-allocation-callback solution for wow64 GL memory mappings
by Derek Lesho (＠dlesho) 02 Nov '24

02 Nov '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6663

6 9

[PATCH 0/4] MR6751: dplayx: Misc fixes and CREATEPLAYER handling.
by Anton Baskanov (＠baskanov) 01 Nov '24

01 Nov '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6751

4 6

[PATCH 0/6] MR6758: d3dx9: PNG/JPG file handling changes.
by Connor McAdams (＠cmcadams) 01 Nov '24

01 Nov '24

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/6758

3 7

[PATCH v10 0/2] MR498: server: Allow creating named pipes using \Device\NamedPipe\ as RootDirectory. (#52105)
by Jinoh Kang (＠iamahuman) 01 Nov '24

01 Nov '24

On Windows, \Device\NamedPipe\ is the root directory of the named pipe file system (NPFS), and can be used as RootDirectory to skip its path when accessing the NPFS namespace. --- **Note**: `subpath->str` may look hacky, but it's used to indicate trailing `\\`[^bks] and existing code already does it too: - `server/directory.c` checks `name->str`[^dir] to test if this is the last component. This is evident by the fact that changing it to `name->len` will lead to major regression. - `server/registry.c` has similar lookup logic.[^reg1][^reg2] [^bks]: https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1… [^dir]: https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1… [^reg1]: <https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1…> [^reg2]: <https://gitlab.winehq.org/wine/wine/-/blob/c64aa0006e4a33d755a57a693cd81dc1…> -- v10: server: Implement more FSCTLs on \Device\NamedPipe and \Device\NamedPipe\. server: Allow creating named pipes using \Device\NamedPipe\ as RootDirectory. https://gitlab.winehq.org/wine/wine/-/merge_requests/498

2 3

[PATCH 0/1] MR6757: include: Annotate PFN_CMSG_ALLOC with __WINE_ALLOC_SIZE.
by Alex Henrie (＠alexhenrie) 01 Nov '24

01 Nov '24

To match [PFN_CRYPT_ALLOC](https://gitlab.winehq.org/alexhenrie/wine/-/blob/3a736901c… and get better warnings when compiling with `-fanalyzer`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6757

1 0

2025

2024

2023

2022

wine-gitlab