Tres Finocchiaro (@tresf) commented about tools/winebuild/main.c:
> { "dll", 0, LONG_OPT_DLL },
> { "def", 0, LONG_OPT_DEF },
> { "disable-dynamicbase", 0, LONG_OPT_DISABLE_DYNAMICBASE },
> + { "disable-high-entropy-va", 0, LONG_OPT_DISABLE_HIGH_ENTROPY_VA },
I would appreciate any advice from the winehq team here on styling. Mimicking the existing format for section will touch many more lines.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113298
Tres Finocchiaro (@tresf) commented about tools/winebuild/main.c:
> " -d, --delay-lib=LIB Import the specified library in delayed mode\n"
> " -D SYM Ignored for C flags compatibility\n"
> " --disable-dynamicbase Disable 'ASLR' address space layout randomization (default: ASLR on)\n"
> +" --disable-high-entropy-va Disable high-entropy 64-bit 'ASLR' (default: high-entropy on).\n"
I would appreciate any advice from the winehq team here on styling. Mimicking the format this section for 80 chars will touch many more lines.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113297
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
--
v2: Spit up DYNAMICBASE and HIGHENTROPYVA
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786
--
v2: jscript: Fix error value when passing non-string 'this' to String's toString.
jscript: Fallback to Object's toString for Arrays when 'this' isn't an
jscript: Return proper error when passing wrong type to Function.apply.
jscript: Allow objects that expose "length" prop for Function.apply under
https://gitlab.winehq.org/wine/wine/-/merge_requests/8781
Supersedes https://gitlab.winehq.org/wine/wine/-/merge_requests/8338
The header cannot seem to be generated easily from an IDL, gameinput has some unfortunate versioning which reuses the same identifiers across versions, in an incompatible way and sometimes sharing only a subset of them (for instance enum values), and uses C++ namespaces to separate versions.
The implementation needs to support every interface version at the same time, which is implemented by wrapping identifiers and adding version suffixes whenever it is included by the implementing code. The tests are also using that so we can tests multiple versions in the same file.
--
v3: dinput/tests: Add some gameinput tests.
gameinput: Introduce new DLL.
include: Add gameinput.h.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8733