--
v4: kernelbase: Implement QueueUserAPC2().
ntdll: Use NtContinueEx in KiUserApcDispatcher on x64.
ntdll: Implement QUEUE_USER_APC_CALLBACK_DATA_CONTEXT in NtQueueApcThreadEx2() on x64.
server: Do not allow queueing special APCs to wow64 threads.
ntdll: Pass user APC flags to call_user_apc_dispatcher().
ntdll: Validate reserve handle in NtQueueApcThreadEx2().
ntdll: Add semi-stub for NtQueueApcThreadEx2().
https://gitlab.winehq.org/wine/wine/-/merge_requests/8569
Commit 518e394794160818ffe6826c874ff2f550c95bbb introduced new and important default behavior for PE binaries built using `winegcc`/`wineg++`/`winebuild`.
* `/DYNAMICBASE` - Generates an executable image that can be randomly rebased at load time by using the address space layout randomization (ASLR) feature of Windows that was first available in Windows Vista.
* `/HIGHENTROPYVA` - Randomized 64-bit virtual addresses make it more difficult for an attacker to guess the location of a particular memory region.
... however as identified in https://bugs.winehq.org/show_bug.cgi?id=58480, this new default behavior can severely impact applications that interact with binaries created for Windows XP and older. This is quite common for legacy audio plugins, such as VST2(TM) plugins.
This MR keeps the new default "dynamicbase" and "highentropyva" flags by default, but mirrors the mingw/msys2 `--disable-dynamicbase` flag as explained here: https://www.msys2.org/news/#2021-01-31-aslr-enabled-by-default. MSVC also provides a similarly named flag [here](https://learn.microsoft.com/en-us/cpp/build/reference/dynamicbase).
Downstream, the LMMS project has successfully deployed the mingw flag and the MSVC flag for our Windows builds. Our Linux builds use a custom wine-bridge and would benefit from the same.
We've currently tested this MR downstream against a snapshot of master branch to passing results.
Downstream PRs:
* Linux: https://github.com/LMMS/lmms/pull/7987
* Windows: https://github.com/LMMS/lmms/pull/7976
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786
Esme Povirk (@madewokherd) commented about dlls/sane.ds/ui.c:
> + if (changed)
> + {
> + save_cfg_data(NULL, path, SINGLE, opt.optno);
> + InitializeDialog(hwnd);
> + }
> free( value );
> }
>
> +LRESULT CALLBACK SaveWindowProc(HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
> +{
> + switch (uMsg)
> + {
> + case WM_CREATE:
> + {
> + RECT rcClient;
> + HWND tag, edit, btnSave, btnLoad;
This seems like unnecessarily complicated UI to me. Why not just have Save and Load buttons in the main window that bring up standard Open/Save dialogs? (And maybe a "Save Defaults" that writes it to the default location. That could be added first, with the extra dialogs added in a later commit.)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8778#note_113179