- Wine-GitLab - list.winehq.org

[PATCH v19 0/17] MR7111: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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) Nov. 5, 2025

Nov. 5, 2025

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

[PATCH 0/4] MR9370: msado15: Improvements for Recordset::AddNew and get_RecordCount functions.
by Piotr Caban (＠piotr) Nov. 5, 2025

Nov. 5, 2025

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

2 4

[PATCH v2 0/2] MR9299: ole32, combase: Add tests for COM context switching and delayed marshaling.
by Vibhav Pant (＠vibhavp) Nov. 5, 2025

Nov. 5, 2025

When `RoGetAgileReference` is used with `AGILEREFERENCE_DELAYEDMARSHAL`, the returned `IAgileReference` also contains a reference to the apartment the object belongs to. Thus, when `IAgileReference::Resolve()` gets called, the object will get marshaled inside the owning apartment, not the caller's apartment. This seems to be made possible by the `IContextCallback` interface. It provides a way to (ab)use the marshaller to execute arbitrary code inside a COM context, which is an additional bit of state nested inside apartments. An apartment can contain multiple COM contexts, and the standard marshaller will keep track of which context a marshaled interface is bound to. All method calls through that marshalled pointer will be wrapped around a context-switch, even when the caller is in the same apartment. Additionally, creating an instance of the class `CLSID_IContextCallback` allows us to create new contexts inside an apartment. C++/WinRT makes use of `IContextCallback` to [implement support for C++ coroutines ](https://github.com/microsoft/cppwinrt/blob/ebace4abb8f48b6b9a612e8b84667e6044976a47/strings/base_coroutine_threadpool.h#L51)(co_await, et al) inside application STA code. Another use of COM contexts seems to be the UI code in WinRT applications, where certain objects can only be `Released`/destructed from the apartment they were created in. (I was able to find another instance of `IContextCallback` usage in the wild [here](https://github.com/Open-Shell/Open-Shell-Menu/blob/4ebeadd949d0550642…, to get an `IAccessible` implementation that has apartment-affinity). -- v2: ole32/tests: Add tests for IContextCallback::ContextCallback and CoDisconnectContext. combase/tests: Add tests for delayed marshaling of objects with apartment affinity. https://gitlab.winehq.org/wine/wine/-/merge_requests/9299

2 2