December 2025 - Wine-gitlab

[PATCH 0/2] MR9722: windowscodecs: Support trivial cases for copying 1bpp indexed data.
by Dmitry Timoshkov (＠dmitry) 12 Dec '25

12 Dec '25

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

3 3

[PATCH 0/1] MR9760: win32u: Update window state after setting internal pixel format.
by Rémi Bernon (＠rbernon) 12 Dec '25

12 Dec '25

We need to inform wineserver that the window has a drawable now and should be clipped out of the window surface updates. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58491 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9760

2 1

[PATCH 0/2] MR9759: ntdll: Correct times reported by SystemPerformanceInformation and SystemProcessorPerformanceInformation on macOS.
by Sven Baars (＠sbaars) 12 Dec '25

12 Dec '25

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

2 2

[PATCH 0/1] MR9757: mfsrcsnk: Use stream_map for index value on stream start.
by Brendan McGrath (＠redmcg) 12 Dec '25

12 Dec '25

Fixes an issue where the queued samples for one stream can end up on the other when performing a pause/play. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9757

3 3

[PATCH v9 0/5] MR8837: opcservices: Add basic support for reading OPC packages.
by Vibhav Pant (＠vibhavp) 12 Dec '25

12 Dec '25

This MR introduces an initial implementation for `ReadPackageFromStream` in order to be able to decompress/read OPC packages, and enumerate their parts. This is required for supporting AppX packages, which themselves are OPC packages as well. As such, the code does not implement support for reading relationships or interleaved archives, as AppX does not support either (`APPX_E_RELATIONSHIPS_NOT_ALLOWED`, `APPX_E_INTERLEAVING_NOT_ALLOWED`). -- v9: opcservices: Implement IOpcPart::GetContentType for opened packages. opcservices: Implement IOpcPart::GetContentStream for opened packages. opcservices: Create IOpcPart objects for ZIP entries in an opened package. https://gitlab.winehq.org/wine/wine/-/merge_requests/8837

3 8

[PATCH v20 0/17] MR7111: support building Wine with LTO
by Konstantin Demin (＠rockdrilla) 12 Dec '25

12 Dec '25

relevant bug reports: - https://bugs.winehq.org/show_bug.cgi?id=41712 - https://bugs.winehq.org/show_bug.cgi?id=51051 -- v20: 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

2 2

[PATCH v8 0/3] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) 12 Dec '25

12 Dec '25

There are several motivations to enable ctor/dtor support: 1. ASan. This is not just about my wine-asan work, this is important for @bernhardu's PE asan work as well. The compiler generates ctors that poisons memory around global variables so misuses of them can be caught. This is the same both of our implementations of ASan. 2. Building third-party codebases against wine's CRT. This is not necessary for mingw-gcc or llvm-mingw, but the MSVC frontend of clang is another option for cross-compiling to Windows. However right now that requires Windows SDK. Bringing wine CRT to the point of being functional enough will give us another option. Could be useful for things like Proton. 3. (Controversial) Many dlls perform init/deinit tasks in `DllMain`. Some of them might benefit from a conversion to ctor/dtor. Since nothing in wine uses ctor/dtor right now, this change shouldn't have any impact by itself. -- v8: crt: Run MSVC constructors and destructors. winegcc: Merge .CRT sections for windows targets. winebuild: Generate start and end symbols for .CRT sections. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

2 5

[PATCH 0/6] MR9758: Draft: crt: Run MinGW constructors and destructors
by Yuxuan Shui (＠yshui) 12 Dec '25

12 Dec '25

(stacked over !9265) @jacek does this look like a good idea? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9758

2 6

[PATCH v7 0/3] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) 12 Dec '25

12 Dec '25

There are several motivations to enable ctor/dtor support: 1. ASan. This is not just about my wine-asan work, this is important for @bernhardu's PE asan work as well. The compiler generates ctors that poisons memory around global variables so misuses of them can be caught. This is the same both of our implementations of ASan. 2. Building third-party codebases against wine's CRT. This is not necessary for mingw-gcc or llvm-mingw, but the MSVC frontend of clang is another option for cross-compiling to Windows. However right now that requires Windows SDK. Bringing wine CRT to the point of being functional enough will give us another option. Could be useful for things like Proton. 3. (Controversial) Many dlls perform init/deinit tasks in `DllMain`. Some of them might benefit from a conversion to ctor/dtor. Since nothing in wine uses ctor/dtor right now, this change shouldn't have any impact by itself. -- v7: crt: Run MSVC constructors and destructors. winegcc: Merge .CRT sections for windows targets. winebuild: Generate start and end symbols for .CRT sections. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

3 10

[PATCH v21 0/3] MR9632: sxs: avoid uninitialised len_name length
by Hans Chen (＠hans.chen) 12 Dec '25

12 Dec '25

The `redirect_data->clrdata_len` [is unset in /dlls/ntdll/actctx.c#L4411-4412](https://gitlab.winehq.org/wine/wine/-/blob/master/dlls/ntdll/actctx.c?ref_type=heads#L4411-4412) when using registration-free COM in C# NET code. Program.cs ```C# //... Guid guid = Guid.Parse("COM clsid"); Type type = Type.GetTypeFromCLSID(guid, true); var instance = Activator.CreateInstance(type)); //... ``` App.manifest ```xml <assembly> <file name="ExampleCOM.dll"> <comClass description="ExampleCOM" progid="ExampleCOM" clsid="{COM clsid}" threadingModel="Free"/> </file> </assembly> ``` The above C# code gets this error on its second line. ```Shell System.AccessViolationException: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. ``` This is because `len_name` is uninitialized when calling `memcpy(ret_strings, ptr_name, len_name);` in `SxsLookupClrGuid`, which is fixed in this MR. -- v21: add testlib https://gitlab.winehq.org/wine/wine/-/merge_requests/9632

2 3