On Wed Aug 20 19:41:56 2025 +0000, Tres Finocchiaro wrote:
> `HIGHENTROPYVA:NO` allows `DYNAMICBASE` to remain active for both 32-bit
> and 64-bit executables while only disabling the 64-bit `HIGHENTROPYVA`
> features. Since `DYNAMICBASE` is widely preferred for security
> purposes, this provides just-enough granularity to close
> [#58480](https://bugs.winehq.org/show_bug.cgi?id=58480), and matches
> more closely to that of cygwin and MSVC compilers. Note that this
> `HIGHENTROPYVA:NO` solution is new information since creating that bug report.
> On the other hand, if it's winehq's stance that these flags should be
> toggled together, I'd happily change this back. I was fearful that
> handling them together may not be succinct enough, but I'm happy to oblige.
DYNAMICBASE by itself is not meaningful for .exe.so binaries, they are mapped by the Unix loader anyway, which provides its own ASLR.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113321
On Wed Aug 20 18:17:23 2025 +0000, Alexandre Julliard wrote:
> That second flag doesn't seem necessary.
`HIGHENTROPYVA:NO` allows `DYNAMICBASE` to remain active for both 32-bit and 64-bit executables while only disabling the 64-bit `HIGHENTROPYVA` features. Since `DYNAMICBASE` is widely preferred for security purposes, this provides just-enough granularity to close [#58480](https://bugs.winehq.org/show_bug.cgi?id=58480), and matches more closely to that of cygwin and MSVC compilers. Note that this `HIGHENTROPYVA:NO` solution is new information since creating that bug report.
On the other hand, if it's winehq's stance that these flags should be toggled together, I'd happily change this back. I was fearful that handling them together may not be succinct enough, but I'm happy to oblige.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/8786#note_113319
The `Allocate` method has two variants:
* Allocate(size_t): Performs a normal allocation, but throws a COMException on OOM.
* Allocate(ptrdiff_t offset, size_t size): Allocates a block of size `size`, and initializes a control block for an `IWeakReference` at `offset`. The weak reference resolves to the allocated object, which can finally be freed by calling `ControlBlock::ReleaseTarget`.
The IWeakReference implementation seems to be rather odd, which I have tried to demonstrate (and test) in the unit tests:
* `ReleaseTarget` only frees the object if the strong ref count is _below_ 0.
* `IWeakReference::Resolve` will _not_ set the output pointer to `NULL` if the weak reference is no longer alive.
This MR implements these functions sans exception support.
--
v2: vccorlib140: Implement Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
vccorlib140: Add stub for Platform::Details::{Allocate(ptrdiff_t, size_t), ControlBlock::ReleaseTarget}.
https://gitlab.winehq.org/wine/wine/-/merge_requests/8774
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