November 2025 - Wine-gitlab

Re: [PATCH v4 0/1] MR9362: opengl32: Simplify extension tokenization.
by Jacek Caban (＠jacek) 06 Nov '25

06 Nov '25

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) 06 Nov '25

06 Nov '25

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) 06 Nov '25

06 Nov '25

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) 06 Nov '25

06 Nov '25

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) 06 Nov '25

06 Nov '25

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

[PATCH v4 0/3] MR9383: appbar: SHAppBarMessage: silence warnings about unknown message types
by Matthias Schwarzott (＠zzam) 06 Nov '25

06 Nov '25

rate-limit these warnings: 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETSTATE): stub 0078:fixme:appbar:handle_appbarmessage SHAppBarMessage(ABM_GETTASKBARPOS, hwnd=...): stub silence these warnings: 0024:fixme:appbar:SHAppBarMessage unknown msg: 4 0024:fixme:appbar:SHAppBarMessage unknown msg: 1 -- v4: appbar: Limit the number of FIXME lines appbar: SHAppBarMessage: silence warnings about unknown message types appbar: Add test for ABM_GETSTATE https://gitlab.winehq.org/wine/wine/-/merge_requests/9383

2 3

Re: [PATCH v5 0/3] MR8834: server: Use process_vm_writev / process_vm_readv instead of ptrace when available.
by Marc-Aurel Zent (＠mzent) 06 Nov '25

06 Nov '25

Yeah this was my bad, it should be as @rbernon already said `vm_region_basic_info_data_64_t` instead of `vm_region_basic_info_data_t`... The MR linked above does fix the crash. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8834#note_121020

1 0

Re: [PATCH v5 0/3] MR8834: server: Use process_vm_writev / process_vm_readv instead of ptrace when available.
by Marc-Aurel Zent (＠mzent) 06 Nov '25

06 Nov '25

On Thu Nov 6 11:38:17 2025 +0000, Paul Gofman wrote: > If I have to guess, this part looks suspicious: > ``` > ret = mach_vm_region( process_port, &region_address, > &region_size, VM_REGION_BASIC_INFO_64, > (vm_region_info_t)&info, &info_count, &object_name ); > ``` > ((vm_region_info_t)&info). That seems like the parameter which address > on stack is below our 'written' (so writing past it can do this), and it > is suspiciously casted. The cast there is how the API is supposed to be used, but this is indeed where the stack is getting smashed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8834#note_121019

1 0

[PATCH 0/1] MR9385: server: Fix Mach vm region info datatype in write_process_memory().
by Marc-Aurel Zent (＠mzent) 06 Nov '25

06 Nov '25

Fixes the issue found here: https://gitlab.winehq.org/wine/wine/-/merge_requests/8834#note_120929. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9385

2 1

[PATCH v2 0/1] MR9103: ntdll/unix: Explicitly cast to XSAVE_FORMAT* before dereferencing FPUX_sig
by Thibault Payet (＠thpayet) 06 Nov '25

06 Nov '25

This will fixes build on FreeBSD targeting i386. -- v2: ntdll/unix: Explicitly cast the NULL value for FPU_sig, FPUX_sig and XState_sig to the correct one https://gitlab.winehq.org/wine/wine/-/merge_requests/9103

4 6