- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/1] MR9924: include: Move intrinsic pragmas below function declarations. - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9924

1 0

Re: [PATCH v2 0/1] MR9925: msado15: Fix IDBProperties use after free in adoconstruct_WrapDSOandSession. - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9925

1 0

Re: [PATCH v2 0/1] MR9921: include: Add more DB_E_ defines - approved
by Alexandre Julliard (＠julliard) Jan. 19, 2026

Jan. 19, 2026

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9921

1 0

[PATCH v3 0/5] MR9651: dmsynth: More robust sink write and render scheduling
by Anton Baskanov (＠baskanov) Jan. 19, 2026

Jan. 19, 2026

-- v3: dmsynth: Clear the buffer notifications before closing the event handle. dmsynth: Estimate a continuously-advancing buffer position for a more precise timing. dmsynth: Call GetCurrentPosition from a separate thread. dmsynth: Simplify synth_sink_wait_play_end by making it similar to the main rendering loop. dmsynth: Try to maintain a fixed write latency by varying the wait time. https://gitlab.winehq.org/wine/wine/-/merge_requests/9651

3 8

[PATCH 0/1] MR9917: ntdll: Accept device paths in LdrAddDllDirectory.
by Alexandre Esteves (＠alexfmpe) Jan. 19, 2026

Jan. 19, 2026

This is needed to allow running Template Haskell inside Wine when cross-compiling as GHC uses device paths nowadays. Upstreaming from https://github.com/input-output-hk/haskell.nix/pull/2034/commits/44f2822afd… Similar to https://gitlab.winehq.org/wine/wine/-/merge_requests/6308 but only for AddDll as the GetDll part seems to already allow `RtlPathTypeLocalDevice` (old `DEVICE_PATH`). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9917

3 2

[PATCH 0/2] MR9916: win32u: Fixup Vulkan deviceName to match win32u GPU name.
by Paul Gofman (＠gofman) Jan. 19, 2026

Jan. 19, 2026

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

3 6

[PATCH v14 0/4] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) Jan. 19, 2026

Jan. 19, 2026

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. -- v14: crt: Run MSVC constructors and destructors. winecrt0: Add fallback initterm and initterm_e implementations. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

3 8

[PATCH v13 0/4] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) Jan. 19, 2026

Jan. 19, 2026

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. -- v13: crt: Run MSVC constructors and destructors. winecrt0: Add fallback initterm and initterm_e implementations. https://gitlab.winehq.org/wine/wine/-/merge_requests/9265

3 5

[PATCH v12 0/4] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) Jan. 19, 2026

Jan. 19, 2026

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. -- v12: crt: Run MSVC constructors and destructors. ntdll: Add initterm implementation to the import library. 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 v11 0/6] MR9265: crt: Run MSVC constructors and destructors
by Yuxuan Shui (＠yshui) Jan. 19, 2026

Jan. 19, 2026

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. -- v11: crt: Run MSVC constructors and destructors. ntdll: Add initterm implementation to the import library. makedep: Allow linking a module’s own static library object files into the module itself. makedep: Add ntdll to default imports too when -nodefaultlibs is used and ntdll is imported. 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

5 14