November 2025 - Wine-gitlab

[PATCH v4 0/1] MR9375: opengl32: Avoid null pointer dereferences when filtering extensions.
by Tim Clem (＠tclem) 05 Nov '25

05 Nov '25

Fixes: 2127e9ae7d90466f3b8883708799047214409832 --- Fixes a crash on macOS. Perhaps the extensions string regularly has a trailing space on other platforms? The previous filter_extensions_list method set `end` differently and avoided this case. -- v4: opengl32: Avoid null pointer dereferences when filtering extensions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9375

4 4

[PATCH 0/3] MR9377: wineandroid, winemac, winex11: Fix ProcessEvents drained return value.
by Rémi Bernon 05 Nov '25

05 Nov '25

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58915 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9377

1 3

[PATCH v19 0/17] MR7111: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) 05 Nov '25

05 Nov '25

relevant bug reports: - https://bugs.winehq.org/show_bug.cgi?id=41712 - https://bugs.winehq.org/show_bug.cgi?id=51051 -- v19: ntoskrnl: move i386 specific Rtl*ByteSwap() into separate source. ntoskrnl: move _chkstk() / __chkstk() into separate source. msvcrt: move i386 specific _ftol() into separate source. kernel32: move x86-64 specific GetProcAddress() into separate source. kernel32: move i386 specific Interlocked*() into separate source. kernel32: move i386 specific ExitProcess() into separate source. kernelbase: move x86-64 specific GetProcAddress() into separate source. ntdll: move i386 specific Rtl*ByteSwap() into separate source. tools: add LTO quirks. makedep: support skipping/disabling LTO. configure: enable building Wine with LTO. makedep: support LTO builds. winegcc: support LTO builds. winebuild: support LTO builds. tools: helper functions for LTO builds. ntdll: add attribute "used" to a few symbols that should not be discarded. loader: add attribute "used" to a few symbols that should not be discarded. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/7111

1 1

[PATCH v3 0/1] MR9375: opengl32: Avoid null pointer dereferences when filtering extensions.
by Tim Clem (＠tclem) 05 Nov '25

05 Nov '25

Fixes: 2127e9ae7d90466f3b8883708799047214409832 --- Fixes a crash on macOS. Perhaps the extensions string regularly has a trailing space on other platforms? The previous filter_extensions_list method set `end` differently and avoided this case. -- v3: opengl32: Avoid null pointer dereferences when filtering extensions. https://gitlab.winehq.org/wine/wine/-/merge_requests/9375

2 2

[PATCH 0/1] MR9372: winemac.drv: Explicitly add an ivar for contentViewMaskLayer.
by Tim Clem (＠tclem) 05 Nov '25

05 Nov '25

Required for @synthesize when building with older compilers. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58916 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9372

2 1

Re: [PATCH v2 0/2] MR9369: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file.
by Jacek Caban (＠jacek) 05 Nov '25

05 Nov '25

Jacek Caban (@jacek) commented about dlls/wininet/tests/http.c: > > init_events(); > init_status_tests(); > +#if 1 A leftover? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9369#note_120865

1 0

Re: [PATCH v2 0/2] MR9369: wininet: Return correct errors and put handle into invalid state when seeking beyond end of file.
by Jacek Caban (＠jacek) 05 Nov '25

05 Nov '25

Jacek Caban (@jacek) commented about dlls/wininet/http.c: > return GetLastError(); > if (!ReadFile(req->req_file->file_handle, buffer, size, &ret_read, NULL)) > return GetLastError(); > + } else if (req->content_pos > req->cache_size) { > + req->invalid_state = TRUE; Do we need a separate mechanism for that? Could we use `hdr->dwError` for this? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9369#note_120864

1 0

[PATCH v3 0/5] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) 05 Nov '25

05 Nov '25

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- v3: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 6

[PATCH v2 0/5] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) 05 Nov '25

05 Nov '25

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- v2: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot. kernel32: Use GetCurrentProcess() handle in CreateToolheap32Snapshot if possible. kernel32: Test CreateToolhelp32Snapshot with TH32CS_SNAPMODULE32. include: Add TH32CS_SNAPMODULE32. kernel32/tests: Fix CreateToolhelp32Snapshot failure check. https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 6

[PATCH 0/5] MR9371: kernel32: Implement TH32CS_SNAPMODULE32 support for CreateToolhelp32Snapshot.
by Yuxuan Shui (＠yshui) 05 Nov '25

05 Nov '25

Intention is to use `CreateToolhelp32Snapshot` in `dbghelp.dll: EnumerateLoadedModulesW64`. Right now we can't because `CreateToolhelp32Snapshot` can't capture 32bit modules in wow64 processes, which is needed to support `SYMOPT_INCLUDE_32BIT_MODULES`. The advantage of using `CreateToolhelp32Snapshot` in mainly performance. Right now `EnumerateLoadedModulesW64` is `O(n^2)`, because of each module it calls `GetModuleInformation` which is itself `O(n)` w.r.t. number of modules. Whereas with `CreateToolhelp32Snapshot` there is no need for `GetModuleInformation`, thus reduce the complexity to just `O(n)`. * * * P.S. I am also uncomfortable with the amount of similar code between `CreateToolhelp32Snapshot` and `EnumProcessModulesEx`. Can something be done here? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9371

2 6