win32u: Return ERROR_ACCESS_DENIED for WH_JOURNALRECORD and WH_JOURNALPLAYBACK on newer OS versions.
On > XP, settings WH_JOURNALRECORD or WH_JOURNALPLAYBACK hooks report ERROR_ACCESS_DENIED according to tests, even with administrator rights. PCSE_TERM depends on this to not crash. MSDN also says that journaling hooks APIs are unsupported starting in Windows 11.
So I hope this justifies the version check in NtUserSetWindowsHookEx().
--
v2: win32u: Return ERROR_ACCESS_DENIED for WH_JOURNALRECORD and WH_JOURNALPLAYBACK on newer OS versions.
win32u: Return ERROR_GLOBAL_ONLY_HOOK when a thread ID is specified for global hooks.
user32/tests: Add more parameter checks for SetWindowsHookExA().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4186
On macOS, when Stage Manager is enabled, Wine windows are frozen after minimizing and restoring.
When a window is minimized in Stage Manager, `[window miniaturize:]` is sent, we then tell the Windows app that the minimize button was pushed, if the window wants to be minimized eventually the window style gets changed and we call `[super miniaturize:]` in `setMacDrvState:`. But macOS never seems to actually minimize the window: no `windowWillMinimize` or `windowDidMinimize` is received. Instead it's just `WINDOW_LOST_FOCUS` and `APP_DEACTIVATED`, which is the same as when Stage Manager is off and the app is just backgrounded.
It seems like clicking the yellow button sends minimize, but once the system receives that and Stage Manager is on, it's actually executed as just "put app in background".
To work around this, if Stage Manager is enabled, don't request a Windows minimize, just call up to `[super miniaturize:]`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4192
Signed-off-by: Torge Matthies <openglfreak(a)googlemail.com>
--
v7: loader: Add Default, Failed, and LastKnownGood values to HKLM\System\Select.
server: Create link from HKLM\System\CurrentControlSet to ControlSet001.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3563
This value may not correspond with the renderer that would get created in `wined3d_adapter_create()` when using `WINED3D_RENDERER_AUTO`. This actually means that returning `WINED3D_RENDERER_OPENGL` from `wined3d_get_renderer()` is also wrong, but this function is only used for testing purposes anyway. A more future-proof way of doing this would be to store the actual renderer that is used somewhere after the adapter was created, and return that from `wined3d_get_renderer()`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4171
eric pouech (@epo) commented about programs/cmd/wcmdmain.c:
> } else break;
> }
>
> - } while (*extraData == 0x00);
nitpick: you could have saved one line of modif by keeping the == 0x00 test (instead of rewritten to 0x0)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4168#note_49865
the latest push looks way better, thanks!
unfortunately, running the updated tests on Windows 10 I generate errors
first errors are:
```
batch.c:427: running TEST_BUILTINS.CMD test...
batch.c:313: Test failed: excess characters on line 260 (got '------------ Testing chains ------------', wanted '')
batch.c:347: Test failed: unexpected end of output in line 717, missing sanity2
```
(followed by a bunch of others, which are likely to be because of the desynchronisation of output)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4168#note_49864
This forces mesa LLVMPIPE driver to use only one thread, and greatly
reduces its memory usage. The driver otherwises uses much more memory
than another driver would and often exhaust VM space in 32bit tests.
I believe this should fix several D3D/D2D/DShow test failures which are
plaging Gitlab CI.
--
v2: gitlab: Run tests with LP_NUM_THREADS=4 env var.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4182