- Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR9384: vccorlib140: Implement {Get, Weak}ResolveWeakReference.
by Vibhav Pant (＠vibhavp) Nov. 6, 2025

Nov. 6, 2025

-- v2: vccorlib140: Implement {Get, Resolve}WeakReference. https://gitlab.winehq.org/wine/wine/-/merge_requests/9384

3 4

[PATCH v2 0/3] MR9386: jscript: Implement Uint8ClampedArray.
by Gabriel Ivăncescu Nov. 6, 2025

Nov. 6, 2025

-- v2: jscript: Return JS_E_OBJECT_EXPECTED in valueOf with NULL disps in IE10+ jscript: Expose Uint8ClampedArray only in ES6 mode. jscript: Implement Uint8ClampedArray. https://gitlab.winehq.org/wine/wine/-/merge_requests/9386

2 4

[PATCH 0/1] MR9387: po: update Polish translation
by Adam Markowski (＠AMark) Nov. 6, 2025

Nov. 6, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9387

2 1

[PATCH 0/3] MR9386: jscript: Implement Uint8ClampedArray.
by Gabriel Ivăncescu Nov. 6, 2025

Nov. 6, 2025

-- https://gitlab.winehq.org/wine/wine/-/merge_requests/9386

1 3

Re: [PATCH v4 0/1] MR9362: opengl32: Simplify extension tokenization.
by Rémi Bernon Nov. 6, 2025

Nov. 6, 2025

On Thu Nov 6 17:21:53 2025 +0000, Jacek Caban wrote: > First of all, this is your change, so my question is: why do we now have > to use `ARRAY_SIZE`? > Historically, there was a large janitorial effort that introduced > `ARRAY_SIZE` as a Wine extension and replaced many open-coded cases. My > best guess as to why `ARRAYSIZE` (available in the Windows SDK) wasn’t > used at the time is simply oversight and that’s where your usage stats > come from. The latter was added later for MSVC compatibility, and both > have been fine ever since, but if you’re proposing some kind of > unification, I’m not in favor of enforcing the non-compatible variant. I'm sorry but this has been merged without my approval, when I had explicitly requested changes to the code which I found ugly and inconsistent, by squeezing the change to a different MR which I wasn't assigned to. And now I have to spend time on it and justify the changes I had previously requested? I don't really care which one between ARRAY_SIZE or ARRAYSIZE is better, I only see that ARRAY_SIZE is 10 times more widely used than the other, and I believe code should be kept consistent to avoid wasting our time on such considerations. The consistency is in favor of ARRAY_SIZE, period. If you think that Wine should drop ARRAY_SIZE and use ARRAYSIZE everywhere, I'm fine with it, but it should be done at a large scale, not by introducing small diverging usages here and there. Like we did with ULONG types. In the meantime, please stick to ARRAY_SIZE. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9362#note_121051

1 0

Re: [PATCH v4 0/1] MR9362: opengl32: Simplify extension tokenization.
by Jacek Caban (＠jacek) Nov. 6, 2025

Nov. 6, 2025

Jacek Caban (@jacek) commented about dlls/opengl32/unix_wgl.c: > + > + if (!(extensions = malloc( size * sizeof(*extensions) + (ptr - str) ))) return; > + > + for (out = (char *)&extensions[size], ptr = str; *ptr; out++, ptr++) > { > - if (*ext == ' ') > - { > - *ext = 0; > - extensions[count++] = ext + 1; > - } > - ext++; > + if (ptr == str || ptr[-1] == ' ') extensions[count++] = out; > + *out = *ptr == ' ' ? 0 : *ptr; > } > - assert( count + ARRAYSIZE(legacy_extensions) - 1 == size ); > + if (ptr != str) *out = 0; This may overflow the allocated buffer. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9362#note_121049

1 0

Re: [PATCH v4 0/1] MR9362: opengl32: Simplify extension tokenization.
by Jacek Caban (＠jacek) Nov. 6, 2025

Nov. 6, 2025

On Wed Nov 5 18:12:02 2025 +0000, Rémi Bernon wrote: > Why do we now have to use ARRAYSIZE here? The underscore variant has > many more uses (~13k vs ~200), including on unix side code. First of all, this is your change, so my question is: why do we now have to use `ARRAY_SIZE`? Historically, there was a large janitorial effort that introduced `ARRAY_SIZE` as a Wine extension and replaced many open-coded cases. My best guess as to why `ARRAYSIZE` (available in the Windows SDK) wasn’t used at the time is simply oversight and that’s where your usage stats come from. The latter was added later for MSVC compatibility, and both have been fine ever since, but if you’re proposing some kind of unification, I’m not in favor of enforcing the non-compatible variant. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9362#note_121048

1 0

Re: [PATCH v4 0/4] MR9354: ntdll: Fix a couple of epilogue unwind issues on x64.
by Paul Gofman (＠gofman) Nov. 6, 2025

Nov. 6, 2025

Thanks a lot for detailed report, logs, etc! At the first glance looks like it is from 052722667c9dbf96a5dc04d45af55599718d9f92 : there is an 0xe9 jump in the middle of the things which is now wrongly treated as epilogue (tripped by chained unwind info, it wrongly decides that the jump is out of the function). I will need to do some unit test and then it should be probably easy to fix. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9354#note_121029

1 0

Re: [PATCH v4 0/4] MR9354: ntdll: Fix a couple of epilogue unwind issues on x64.
by mbriar (＠mbriar) Nov. 6, 2025

Nov. 6, 2025

I think this MR, which has also been added to Proton Experimental Bleeding Edge, causes some strange issue in Silent Hill f that I've described here: https://github.com/ValveSoftware/Proton/issues/9194 Sorry for hijacking this merged MR discussion for that, but since I can't tag the commit author @gofman on github, I'm doing it this way. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9354#note_121024

1 0

[PATCH v2 0/2] MR9385: server: Fix Mach vm region info datatype in write_process_memory().
by Marc-Aurel Zent (＠mzent) Nov. 6, 2025

Nov. 6, 2025

Fixes the issue found here: https://gitlab.winehq.org/wine/wine/-/merge_requests/8834#note_120929. -- v2: server: Correctly report partial write size in Mach write_process_memory(). https://gitlab.winehq.org/wine/wine/-/merge_requests/9385

2 2