- Wine-GitLab - list.winehq.org

[PATCH 0/5] MR9879: wined3d: Various.
by Elizabeth Figura (＠zfigura) Jan. 14, 2026

Jan. 14, 2026

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

2 5

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

Jan. 14, 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. -- v10: crt: Run MSVC constructors and destructors. winecrtend: New staticlib hosting fallbacks of initterm and initterm_e. 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 11

Re: [PATCH v2 0/1] MR9757: mfsrcsnk: Use stream_map for index value on stream start. - approved
by Rémi Bernon Jan. 13, 2026

Jan. 13, 2026

This merge request was approved by Rémi Bernon. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9757

1 0

Re: [PATCH v2 0/1] MR9719: mfmediaengine/tests: Test we receive a frame before calling Play.
by Brendan McGrath (＠redmcg) Jan. 13, 2026

Jan. 13, 2026

v3: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9719#note_126873

1 0

Re: [PATCH v7 0/13] MR9489: mf: Fix seeking within sample grabber.
by Brendan McGrath (＠redmcg) Jan. 13, 2026

Jan. 13, 2026

v7: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9489#note_126872

1 0

Re: [PATCH v6 0/5] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 13, 2026

Jan. 13, 2026

v6: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9646#note_126871

1 0

Re: [PATCH v2 0/1] MR9757: mfsrcsnk: Use stream_map for index value on stream start.
by Brendan McGrath (＠redmcg) Jan. 13, 2026

Jan. 13, 2026

version 2: - rebase to master -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9757#note_126870

1 0

[PATCH 0/2] MR9877: include: Add more *scanf function declarations.
by Jacek Caban (＠jacek) Jan. 13, 2026

Jan. 13, 2026

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

2 2

[PATCH 0/1] MR9876: win32u: Use surfaces for client area if the backend doesn't support PutImage.
by Rémi Bernon Jan. 13, 2026

Jan. 13, 2026

This is the case on macOS and some other drivers. It will not change anything on X11 which supports drawing to the window directly. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9876

1 1

[PATCH v5 0/1] MR9858: qasf: Fix use-after-free of filter in reader callback.
by Yuxuan Shui (＠yshui) Jan. 13, 2026

Jan. 13, 2026

If a asf reader callback is invoked after its corresponding reader has been destroyed, it will still try to use the reader via asf_callback->filter, resulting in use-after-free. This commits sets asf_callback->filter to NULL when the reader is destroyed, and adds NULL checks to reader callback functions to make them no-op after the reader is destroyed. Fixes: Bug 59159 -- v5: qasf: Don't start a stopped stream in media_seeking_ChangeCurrent. https://gitlab.winehq.org/wine/wine/-/merge_requests/9858

3 4

[PATCH v8 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Alex Schwartz (＠alexschwartz01) Jan. 13, 2026

Jan. 13, 2026

Currently, it will stop the app that is running that has a non-square icon This PR fixes that -- v8: winewayland: Fix non-square icons with xdg-toplevel-icon protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/9868

3 5

[PATCH 0/2] MR9875: Implement InterruptTimeBias and use it in RtlQueryUnbiasedInterruptTime.
by Marc-Aurel Zent (＠mzent) Jan. 13, 2026

Jan. 13, 2026

After https://gitlab.winehq.org/wine/wine/-/merge_requests/8916 `RtlQueryUnbiasedInterruptTime` now includes suspend time as well when it shouldn't. This fixes this and also allows other components like winevulkan to use `RtlQueryUnbiasedInterruptTime`, if that kind of tick count is necessary there. Since calculating the bias is relatively expensive, this is done together with the timezone bias update every second in such a way that it can only monotonically increase. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9875

5 8

[PATCH 0/1] MR9872: qasf: Protect against unconnected pins in media_seeking_ChangeCurrent.
by Yuxuan Shui (＠yshui) Jan. 12, 2026

Jan. 12, 2026

Invoking IMediaSeeking_SetPositions on an asf reader with no pins connected crashes. This doesn't happen on native. Found while working on !9858 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9872

3 3

[PATCH 0/1] MR9866: Revert "ntdll: Switch to CLOCK_BOOTTIME for monotonic counters when available."
by Rémi Bernon Jan. 12, 2026

Jan. 12, 2026

This reverts commit 3d373e452388b60bea9dca6d5c4cf3f8b20a0c54. CLOCK_MONOTONIC_RAW is used in vulkan to correlate QPC timestamps, and there's no equivalent of CLOCK_BOOTTIME there. Using CLOCK_BOOTTIME for QPC breaks the vulkan side with no proper way to fix it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9866

2 3

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Matteo Bruni (＠Mystral) Jan. 12, 2026

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Anton Baskanov wrote: > Thanks for the detailed explanation. > > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. > I studied the code of the openal-soft sinc resampler, and I think that > our resampler is theoretically better: > - Our upsampling window width is 65.89 samples, which is much wider than > openal-soft's 24. This should result in a sharper pass-band to stop-band > transition, which means less aliasing. > - openal-soft's downsampling window is limited to 48 samples, whereas we > don’t have such a limit. > - The way openal-soft expands the upsampling window by linearly > interpolating between windows of different sizes is a bit questionable. > We expand the window by varying `dsbfirstep`, which should provide a > smoother transition. > > The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. > It shouldn't be too hard to change the window function in `make_fir`. > > Additionally, the position computation (`total_fir_steps`, `rem`) > using floats wasn't exact, which in turn caused some mid-high frequency distortion. > This can be easily fixed by using integer arithmetic: > <details> > <summary>Click to expand</summary> > ```diff > diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c > index b50d9f3a8c8..fe1c8a70db3 100644 > --- a/dlls/dsound/mixer.c > +++ b/dlls/dsound/mixer.c > @@ -365,12 +365,12 @@ static UINT > cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * > } > > for(i = 0; i < count; ++i) { > - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * > dsbfirstep / dsb->freqAdjustDen; > - float total_fir_steps = (freqAcc_start + i * > dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; > + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) > * dsbfirstep; > + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; > UINT ipos = int_fir_steps / dsbfirstep; > > UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; > - float rem = int_fir_steps + 1.0 - total_fir_steps; > + float rem = 1.0 - (fir_steps_num - int_fir_steps * > dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; > > int fir_used = 0; > while (idx < fir_len - 1) { > ``` > </details> > I also did some experiments, and I was able to make our resampler 5 > times faster without sacrificing the quality by rearranging the FIR > array and using SSE. Maybe we should give it a try. I'll try to come up > with a draft MR. I'm curious about your changes. All things being equal it would be preferable to improve the existing resampler rather than introducing a different one. The problem is that I'm not sure we can make it fast enough without effectively rewriting it from scratch. When I wrote this MR I felt like the current resampler might be hopelessly too complex for realtime resampling of 100+ sound buffers (which is what Fallout 3 and New Vegas can end up with on occasion). I benchmarked Wine's dsound resampling and compared the performance to Windows. I also tested plugging resamplers from other common libraries (speexdsp and libsamplerate, before openal-soft) into Wine's dsound, and that kinda reinforced my view. The fastest fsinc implementation I tried (which is from openal-soft) is still about half as fast as Win 10 / 11's, IIRC. I can go look at the actual numbers but I'm pretty sure a 5x improvement when using explicit SSE does not quite cut it. I'll mention that, since I wrote this MR, I have prepared a few more patches to improve on other pieces of the dsound mixer, which become the bottleneck once the resampler itself gets fast enough. You can find it at https://gitlab.winehq.org/Mystral/wine/-/commits/dsound-perf (I cleaned the patches up locally since I pushed all that to gitlab, but the gist should be there already). For reference, these are the changes: - Prepare all the input samples and store all the generated output samples in one go instead of doing it sample-by-sample - Don't use indirect function calls for sample conversion - Don't use indirect function calls for channel interleaving - Interleave channels after mixing - Mix and apply volume at the same time - SSE mixing These patches give some incremental performance improvements. It's possible that the combination of these and an improved version of the current resampler gets us where we want, although I'm not super hopeful... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126630

1 0

Re: [PATCH v2 0/5] MR9588: dsound: Introduce a cubic spline interpolation resampler.
by Anton Baskanov (＠baskanov) Jan. 12, 2026

Jan. 12, 2026

On Mon Jan 12 10:50:32 2026 +0000, Matteo Bruni wrote: > I should have mentioned it together with a few more things, but I forgot > :sweat_smile: > This is basically a C port of the default resampler from openal-soft. > It's MUCH faster while not being much worse in theoretical quality > compared to the old FIR resampler. In practice the old resampler had a > couple of shortcomings that lowered the effective quality[*], so I don't > think this is much a downgrade quality-wise. > Otherwise we could bring in the sinc resampler, which is theoretically > very solid and still quite a bit faster than the old FIR resampler. It > is sensibly slower than this one though, and slower than Windows 10 / 11 > dsound's resampler. I'm not opposed to having it as an option; I did in > fact try to make the surrounding code somewhat generic to facilitate that. > The SSE2 version gives about a 2x speedup for me. For the records it > makes even more of a difference in openal-soft, most likely because we > start running into performance limitations in our dsound outside of the > resampler proper; I should have a few more patches to improve on that. > The SSE2 version is effectively always enabled on (x86) 64-bit. To > compile the SSE2 version on 32-bit you need to have `-msse2` in > `i386_CFLAGS`, or some other option that includes it (e.g. the typical > `-march=nocona` will do that). > [*]: The FIR resampler used a fixed Gaussian window instead of the > parametrized Kaiser that's customarily used for audio resampling. That > can introduce some aliasing or some distortion depending on the input > signal. Additionally, the position computation (`total_fir_steps`, > `rem`) using floats wasn't exact, which in turn caused some mid-high > frequency distortion. In fact I had originally preserved it when porting > the cubic resampler and I did see the same kind of distortion in the new > output, so I ended up using fixed point for that, which is also what > openal-soft does. Thanks for the detailed explanation. > Otherwise we could bring in the sinc resampler, which is theoretically very solid and still quite a bit faster than the old FIR resampler. I studied the code of the openal-soft sinc resampler, and I think that our resampler is theoretically better: - Our upsampling window width is 65.89 samples, which is much wider than openal-soft's 24. This should result in a sharper pass-band to stop-band transition, which means less aliasing. - openal-soft's downsampling window is limited to 48 samples, whereas we don’t have such a limit. - The way openal-soft expands the upsampling window by linearly interpolating between windows of different sizes is a bit questionable. We expand the window by varying `dsbfirstep`, which should provide a smoother transition. > The FIR resampler used a fixed Gaussian window instead of the parametrized Kaiser that's customarily used for audio resampling. It shouldn't be too hard to change the window function in `make_fir`. > Additionally, the position computation (`total_fir_steps`, `rem`) using floats wasn't exact, which in turn caused some mid-high frequency distortion. This can be easily fixed by using integer arithmetic: <details> <summary>Click to expand</summary> ```diff diff --git a/dlls/dsound/mixer.c b/dlls/dsound/mixer.c index b50d9f3a8c8..fe1c8a70db3 100644 --- a/dlls/dsound/mixer.c +++ b/dlls/dsound/mixer.c @@ -365,12 +365,12 @@ static UINT cp_fields_resample(IDirectSoundBufferImpl *dsb, UINT count, LONG64 * } for(i = 0; i < count; ++i) { - UINT int_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / dsb->freqAdjustDen; - float total_fir_steps = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep / (float)dsb->freqAdjustDen; + LONG64 fir_steps_num = (freqAcc_start + i * dsb->freqAdjustNum) * dsbfirstep; + UINT int_fir_steps = fir_steps_num / dsb->freqAdjustDen; UINT ipos = int_fir_steps / dsbfirstep; UINT idx = (ipos + 1) * dsbfirstep - int_fir_steps - 1; - float rem = int_fir_steps + 1.0 - total_fir_steps; + float rem = 1.0 - (fir_steps_num - int_fir_steps * dsb->freqAdjustDen) / (float)dsb->freqAdjustDen; int fir_used = 0; while (idx < fir_len - 1) { ``` </details> I also did some experiments, and I was able to make our resampler 5 times faster without sacrificing the quality by rearranging the FIR array and using SSE. Maybe we should give it a try. I'll try to come up with a draft MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9588#note_126626

1 0

[PATCH v5 0/5] MR9646: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 12, 2026

Jan. 12, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v5: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 6

[PATCH v4 0/5] MR9646: Draft: mf/tests: Scrubbing tests
by Brendan McGrath (＠redmcg) Jan. 12, 2026

Jan. 12, 2026

This MR adds tests for how scrubbing and rate changes work within the Media Session. -- v4: mf/tests: Check that Rate change in PLAY state is ignored. mf/tests: Test that there is no pre-roll during scrubbing. mf/tests: Fix leaks in test source. mf/tests: Add ClockStateSink to test media sink. mf/tests: Modify test_seek_clock_sink to be ref counted. https://gitlab.winehq.org/wine/wine/-/merge_requests/9646

2 7

[PATCH 0/1] MR4709: winedbg: Show all loaded modules in automatic backtrace.
by Bernhard Übelacker Jan. 10, 2026

Jan. 10, 2026

This patch should change the module list in the automatic backtraces from "info share" to "info wow share". That way all loaded modules should get listed instead of just the process native ones. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4709

3 5

[PATCH 0/1] MR9861: ntdll/unix/file.c: added new xattr for marking directories as readonly
by Rayan Halder (＠rayanh) Jan. 10, 2026

Jan. 10, 2026

On Windows, directories marked as readonly do not behave as readonly directories on linux. Readonly has no effect on windows but on querying for attributes, windows shows the directory to be readonly. To simulate this behaviour, an xattribute is being used to mark a directory as readonly. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50772 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9861

3 7

[PATCH v4 0/1] MR9858: qasf: Fix use-after-free of filter in reader callback.
by Yuxuan Shui (＠yshui) Jan. 10, 2026

Jan. 10, 2026

If a asf reader callback is invoked after its corresponding reader has been destroyed, it will still try to use the reader via asf_callback->filter, resulting in use-after-free. This commits sets asf_callback->filter to NULL when the reader is destroyed, and adds NULL checks to reader callback functions to make them no-op after the reader is destroyed. Fixes: Bug 59159 -- v4: qasf: Stop the WMReader first in asf_reader_destroy. https://gitlab.winehq.org/wine/wine/-/merge_requests/9858

3 8

[PATCH 0/1] MR9870: iccvid/tests: Reserve enough memory for input in test_formats (ASan).
by Bernhard Übelacker Jan. 10, 2026

Jan. 10, 2026

ASan got triggered by the new iccvid test. In `ICCVID_DecompressGetFormat` the input pointer gets read 484 (40+111*4) bytes, but variable `in` gets just the size of `BITMAPINFOHEADER`, 40 bytes allocated. CC: @zfigura [Testbot run with this patch](https://testbot.winehq.org/JobDetails.pl?Key=161448) <details> <summary>ASan details [link](https://gitlab.winehq.org/bernhardu/wine/-/jobs/220743#L5427-L5452)</summary> ``` ==iccvid_test.exe==1720==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0022f8e8 at pc 0x784543e2 bp 0x0022f1f0 sp 0x0022edc0 READ of size 484 at 0x0022f8e8 thread T0 #0 0x784543e1 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x77fd22aa in ICCVID_DecompressGetFormat /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:836:9 #2 0x77fd1351 in ICCVID_DriverProc /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:1015:16 #3 0x78e92cf3 in DRIVER_SendMessage /builds/bernhardu/wine/build64/../dlls/winmm/driver.c:130:11 #4 0x78e92ba8 in SendDriverMessage /builds/bernhardu/wine/build64/../dlls/winmm/driver.c:150:11 #5 0x7902d7e0 in MSVIDEO_SendMessage /builds/bernhardu/wine/build64/../dlls/msvfw32/msvideo_main.c:198:15 #6 0x7902db20 in ICSendMessage /builds/bernhardu/wine/build64/../dlls/msvfw32/msvideo_main.c:1163:12 #7 0x0040190d in test_formats /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:62:11 #8 0x004010d9 in func_iccvid /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:196:5 #9 0x00404f51 in run_test /builds/bernhardu/wine/build64/../include/wine/test.h:780:5 #10 0x00404a6b in main /builds/bernhardu/wine/build64/../include/wine/test.h #11 0x00405f05 in mainCRTStartup /builds/bernhardu/wine/build64/../dlls/msvcrt/crt_main.c:62:11 #12 0x7bcd367f in BaseThreadInitThunk (C:\windows\system32\kernel32.dll+0x7b82367f) #13 0x7be4680a in call_thread_func_wrapper (C:\windows\system32\ntdll.dll+0x7bc4680a) #14 0x7be4717a in call_thread_func /builds/bernhardu/wine/build64/../dlls/ntdll/signal_i386.c:503:9 Address 0x0022f8e8 is located in stack of thread T0 at offset 1256 in frame #0 0x0040149f in test_formats /builds/bernhardu/wine/build64/../dlls/iccvid/tests/iccvid.c:25 This frame has 3 object(s): [16, 1080) 'buffer' (line 26) [1216, 1256) 'in' (line 27) [1296, 1864) 'info' (line 30) <== Memory access at offset 1256 partially underflows this variable HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork (longjmp, SEH and C++ exceptions *are* supported) SUMMARY: AddressSanitizer: stack-buffer-overflow /builds/bernhardu/wine/build64/../dlls/iccvid/iccvid.c:836:9 in ICCVID_DecompressGetFormat ``` </details> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9870

1 1

[PATCH v7 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Alex Schwartz (＠alexschwartz01) Jan. 9, 2026

Jan. 9, 2026

Currently, it will stop the app that is running that has a non-square icon This PR fixes that -- v7: winewayland: Fix non-square icons with xdg-toplevel-icon protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/9868

3 2

Re: [PATCH v29 0/1] MR9414: shlwapi: Handling of "C:\...xx" in PathCanonicalize[AW].
by Thomas Csovcsity (＠thc13) Jan. 9, 2026

Jan. 9, 2026

On Wed Jan 7 16:03:26 2026 +0000, Yuxuan Shui wrote: > Are we worried about backing up over a device letter in this case? i.e. `C:\\..\\something` Good catch, will have a look -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9414#note_126588

1 0

[PATCH v6 0/1] MR9868: winewayland: Fix non-square icons with xdg-toplevel-icon protocol.
by Alex Schwartz (＠alexschwartz01) Jan. 9, 2026

Jan. 9, 2026

Currently, it will stop the app that is running that has a non-square icon This PR fixes that -- v6: winewayland: Fix non-square icons with xdg-toplevel-icon protocol. https://gitlab.winehq.org/wine/wine/-/merge_requests/9868

2 1