On Wed Aug 20 17:08:48 2025 +0000, Tres Finocchiaro wrote:
> I've added a second flag for `HIGHENTROPYVA`. This new flag is longer
> and breaks some styling. Any advice is greatly appreciated. I've
> placed the style foopahs inline.
That second flag doesn't seem necessary.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113306
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
On Wed Aug 20 11:26:51 2025 +0000, Nikolay Sivov wrote:
> I'm talking about changes to VarAnd implementation - what we need is a
> least a helper that implements such type coercing with progressively
> larger integer types. Or better using something from oleaut32 itself to
> do such type conversion. It's most likely not limited to VarAnd().
Yes, you're right. We can write a helper function to handle type coercion.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8635#note_113273
Order of day or month and time or year needs to be considered.
The year also needs to be adjusted correctly.
--
v3: wininet/internet: Fix year parsing to include millennium.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8614
On Tue Aug 5 01:30:09 2025 +0000, Maotong Zhang wrote:
> Hello, I'm not entirely sure which additional test cases are needed.
> Could you please advise? Thanks!
I'm talking about changes to VarAnd implementation - what we need is a least a helper that implements such type coercing with progressively larger integer types. Or better using something from oleaut32 itself to do such type conversion. It's most likely not limited to VarAnd().
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8635#note_113260
Thanks for feedback @rbernon. I'll take a closer look to see if there are any other outstanding yabridge issues preventing merges.
I'll also gather all the relevant patches considered tested by the bug comments vs all the other irrelevant wine-staging patches that were also included.
Regardless whatever remaining broken state yabridge may still be in need of a fix, your yabridge new-wine10-embedding is in a far better and functioning state.
If yabridge devs approve new-wine10-embedding for merge then that will be reflected here to attempt a merge of the relevant wine-staging changes into upstream which will be required by the yabridge merge approval.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6569#note_113254