- Wine-GitLab - list.winehq.org

[PATCH v2 0/5] MR10255: dsound: Speed up resampling, part 4
by Anton Baskanov (＠baskanov) March 20, 2026

March 20, 2026

-- v2: dsound: Premultiply the input value by firgain and the interpolation weights in downsample. dsound: Transpose the FIR array to make the element access sequential. dsound: Calculate firgain more accurately. dsound: Swap around the two nested loops in downsample. dsound: Calculate required_input more accurately. https://gitlab.winehq.org/wine/wine/-/merge_requests/10255

4 13

Re: [PATCH v4 0/2] MR10245: ole32: Relax COM initialization check in RegisterDragDrop. - approved
by Huw Davies (＠huw) March 20, 2026

March 20, 2026

This merge request was approved by Huw Davies. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10245

1 0

[PATCH 0/1] MR10400: vbscript: Map DISP_E_DIVBYZERO to VBScript error 11.
by Francis De Brabandere (＠francisdb) March 20, 2026

March 20, 2026

Add the missing DISP_E_DIVBYZERO mapping in map_vbs_exception() so that division by zero errors report Err.Number = 11 with the correct description "Division by zero", matching native behavior. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=42400 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10400

2 1

Re: [PATCH v31 0/1] MR10192: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Akihiro Sagawa (＠sgwaki) March 20, 2026

March 20, 2026

It looks like a test case was dropped somewhere during your Git operations. To make the intent clearer, could you add a todo_wine-style test in addition to the fix. Also, please use a module name prefix in your commit subject. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10192#note_132984

1 0

[PATCH v2 0/1] MR10326: Draft: mmdevapi: Avoid copying more memory than reserved in validate_fmt (ASan).
by Bernhard Übelacker March 20, 2026

March 20, 2026

The function `validate_fmt` may receive a pointer which got just reserved memory for the `WAVEFORMATEX`. Unfortunately the assignment `fmt2 = *fmt` always copies the size of `WAVEFORMATEXTENSIBLE`. CC: @giomasce (I currently cannot point to a specific commit, but this may also be related to the recent changes?) <details> <summary>ASan details [gitlab CI](https://gitlab.winehq.org/bernhardu/wine/-/jobs/237050#L2464)</summary> ``` ==qcap_test.exe==728==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0022c122 at pc 0x785f4342 bp 0x0022bf4c sp 0x0022bb1c READ of size 40 at 0x0022c122 thread T0 #0 0x785f4341 in __asan_memcpy /home/runner/work/llvm-mingw/llvm-mingw/llvm-project/compiler-rt/lib/asan/asan_interceptors_memintrinsics.cpp:65:3 #1 0x778957a5 in validate_fmt /builds/bernhardu/wine/build64/../dlls/mmdevapi/client.c:363:33 #2 0x77896d1e in client_IsFormatSupported /builds/bernhardu/wine/build64/../dlls/mmdevapi/client.c:881:10 #3 0x783e3624 in IAudioClient_IsFormatSupported /builds/bernhardu/wine/build64/include/audioclient.h:406:12 #4 0x783e5cd7 in WINMM_TestFormat /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:454:10 #5 0x783e5928 in WINMM_GetSupportedFormats /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:504:14 #6 0x783e553b in WINMM_InitMMDevice /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:524:35 #7 0x783e4e9b in WINMM_EnumDevices /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:610:17 #8 0x783d30e8 in WINMM_InitMMDevices /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:856:10 #9 0x7be4a996 in RtlRunOnceExecuteOnce /builds/bernhardu/wine/build64/../dlls/ntdll/sync.c:462:10 ... Address 0x0022c122 is located in stack of thread T0 at offset 34 in frame #0 0x783e5c0f in WINMM_TestFormat /builds/bernhardu/wine/build64/../dlls/winmm/waveform.c:442 This frame has 2 object(s): [16, 34) 'fmt' (line 443) <== Memory access at offset 34 overflows this variable [80, 84) 'junk' (line 443) 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/mmdevapi/client.c:363:33 in validate_fmt ``` </details> -- v2: mmdevapi: Avoid copying more memory than reserved in validate_fmt (ASan). https://gitlab.winehq.org/wine/wine/-/merge_requests/10326

2 5

[PATCH 0/1] MR10397: dbghelp: {dwarf} Properly ignore Dwarf-5 compilation units.
by eric pouech (＠epo) March 20, 2026

March 20, 2026

Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10397

2 1

[PATCH 0/1] MR10395: crypt32: Don't access CERT_CHAIN_ENGINE_CONFIG::dwExclusiveFlags without checking size.
by Yuxuan Shui (＠yshui) March 20, 2026

March 20, 2026

Found by ASan. Example in test `crypt32:chain`, `testCreateCertChainEngine`. Pointer to a `CERT_CHAIN_ENGINE_CONFIG_NO_EXCLUSIVE_ROOT` is passed to `CertCreateCertificateChainEngine`. Accessing `dwExclusiveFlags` unconditionally is out-of-bound. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10395

3 3

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) March 20, 2026

March 20, 2026

> we simply cannot know whether they are supposed to add new commands or token or not. Specs for most of them are available, so we know they don't add new commands. They are just not a part of the official registry. > I also didn't see GL_EXT_demote_to_helper_invocation among them. It seems to be Mesa specific, and looks wrong to me. The extension is actually a shader extension, and I don't think it's supposed to be in the GL extension string, but rather included in GLSL #extension? It is part of the extension strings exposed by Mesa. In any case, we could filter it if there is an actual benefit, but I do not see why we would need to. What exactly looks wrong to you? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_132976

1 0

Re: [PATCH v2 0/14] MR10349: opengl32: Implement wglGetProcAddress on the client side.
by Jacek Caban (＠jacek) March 20, 2026

March 20, 2026

On Thu Mar 19 19:57:12 2026 +0000, Rémi Bernon wrote: > Why is this useful? None of the GL_ANGLE_ extensions are exposed by > native drivers, except for GL_ANGLE_texture_compression_dxt3 / > GL_ANGLE_texture_compression_dxt5 by Mesa (which is not a very common > driver on Windows), and these two are mostly the same as > GL_EXT_texture_compression_dxt1 / GL_EXT_texture_compression_s3tc anyway. Yes, it's about those two extensions mostly. I could maybe disable others, but why? They are well handled by make_opengl. I also don't see how being similar to other extensions changes anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10349#note_132975

1 0

[PATCH v2 0/1] MR10396: Draft: vbscript: Implement IActiveScriptError::GetSourceLineText.
by Francis De Brabandere (＠francisdb) March 20, 2026

March 20, 2026

Extract the error source line in report_script_error() and store it in VBScriptError so that GetSourceLineText can return it. Also fix a memory leak in VBScriptError_Release where EXCEPINFO BSTRs were not freed. -- v2: vbscript: Implement IActiveScriptError::GetSourceLineText. https://gitlab.winehq.org/wine/wine/-/merge_requests/10396

2 1