April 2026 - Wine-GitLab - list.winehq.org

[PATCH v2 0/2] MR10680: scrrun: Implement IFile and IFolder Delete and Move methods.
by Francis De Brabandere (＠francisdb) April 16, 2026

April 16, 2026

file_Delete wraps DeleteFileW, honouring the Force flag by clearing readonly attributes. folder_Delete recursively removes contents via the existing delete_file/delete_folder helpers, then RemoveDirectoryW. Both Move methods wrap MoveFileW. -- v2: scrrun: Implement IFile::Move and IFolder::Move. scrrun: Implement IFile::Delete and IFolder::Delete. https://gitlab.winehq.org/wine/wine/-/merge_requests/10680

2 2

[PATCH 0/2] MR10662: d3dcompiler: Handle filenames with forward slashes in the default ID3DInclude implementation.
by Victor Chiletto (＠vitorhnn) April 16, 2026

April 16, 2026

Native's default ID3DInclude implementation treats forward slashes in filenames identically to backward slashes. Thought it was better to create a separate test function but I'm not 100% sure on that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10662

4 10

[PATCH 0/2] MR10684: quartz: Fix WaitForCompletion behavior when default handling is canceled.
by Akihiro Sagawa (＠sgwaki) April 16, 2026

April 16, 2026

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

3 3

[PATCH 0/6] MR10677: amstream: Test and fix media type enum on ddraw stream.
by Brendan McGrath (＠redmcg) April 16, 2026

April 16, 2026

This MR adds new tests and subsequent fixes for the type returned by `IEnumMediaTypes::Next` on the `IEnumMediaTypes` retrieved from the `IPin::EnumMediaTypes` function on the Direct Draw media stream. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10677

3 7

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Elizabeth Figura (＠zfigura) April 16, 2026

April 16, 2026

> Yes, it's just that the test videos I created are encoded with h264, and are decoded so the test is testing raw video (because this is the most straightforward way I thought). That's not going to test what you want; that goes through an IMFTransform on Windows. > And since you mentioned it I was thinking I shouldn't have started with h264 at all. I am thinking a custom media source that output raw RGB and use video processing in source reader to convert to yuv. That's not going to test what you want either. You want to encode raw video in an existing container and have the builtin demuxer deal with that. Most containers support raw video. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_136575

1 0

[PATCH v2 0/4] MR10683: wineandroid: startup and JNI fixes (part of !10569)
by Twaik Yont (＠twaik) April 16, 2026

April 16, 2026

This MR contains a subset of changes extracted from MR !10569 (first 4 commits after merge-base). Included changes: 1. Fix 64-bit crash in JNI setCursor call * Pass NULL instead of integer 0 for jobject argument in CallVoidMethod * Prevents invalid jobject usage and JNI abort on 64-bit platforms 2. Lower targetSdkVersion to 28 * Avoid Android 10 W^X restrictions (API 29+) affecting exec and memory mappings * Add Java 1.8 compile options required by the adjusted SDK level 3. Fix Wine loader path and library lookup * Update WINELOADER to match current Wine layout * Extend LD_LIBRARY_PATH to support loading libraries directly from APK * Restore correct startup on modern Android/Wine setups 4. Move environment setup to Java layer and simplify wine_init * Replace JNI environment passing with setenv() in WineActivity * Simplify native initialization and remove environment array handling * Preserve LD_LIBRARY_PATH update and WINEDEBUGLOG behavior Reason: This MR is split out from !10569 to simplify review by isolating Android startup and stability changes into a smaller, focused set. -- v2: wineandroid: move environment setup to Java and drop obsolete env vars https://gitlab.winehq.org/wine/wine/-/merge_requests/10683

2 5

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 16, 2026

April 16, 2026

On Thu Apr 16 18:40:33 2026 +0000, Yuxuan Shui wrote: > > I'm confused, wasn't the point here to fix raw video? > Yes, it's just that the test videos I created are encoded with h264, and > are decoded so the test is testing raw video (because this is the most > straightforward way I thought). And since you mentioned it I was > thinking I shouldn't have started with h264 at all. I am thinking a > custom media source that output raw RGB and use video processing in > source reader to convert to yuv. Oh and, although this is internal to wine, there are two pathways. Decoding h264 would go through wg_parser (or winedmo -> wg_transform if that's enabled); custom media source would go through media source -> wg_transform. And I wanted to specifically test wg_parser. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_136570

1 0

Re: [PATCH v2 0/4] MR10654: winegstreamer: Fix wg_parser/native video stride mismatch.
by Yuxuan Shui (＠yshui) April 16, 2026

April 16, 2026

> I'm confused, wasn't the point here to fix raw video? Yes, it's just that the test videos I created are encoded with h264, and are decoded so the test is testing raw video (because this is the most straightforward way I thought). And since you mentioned it I was thinking I shouldn't have started with h264 at all. I am thinking a custom media source that output raw RGB and use video processing in source reader to convert to yuv. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10654#note_136569

1 0

[PATCH v2 0/1] MR10660: uniscribe: Correct possible buffer over/under runs
by Aric Stewart (＠aricstewart) April 16, 2026

April 16, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59532 -- v2: uniscribe: Correct possible buffer over/under runs https://gitlab.winehq.org/wine/wine/-/merge_requests/10660

2 1

[PATCH v5 0/4] MR10104: user32/edit: set bCaptureState flag after SetCapture()
by Ivan Ivlev (＠iviv) April 16, 2026

April 16, 2026

Edit control does not release mouse capture after WM_LBUTTONDOWN has been processed two times in a row. This MR fixes this issue by releasing capture and setting it again on WM_LBUTTONDOWN if window was already captured. I have stumbled upon the app in which edit control process WM_LBUTTONDOWN twice on one mouse click. While in windows it causes no problem, wine edit does not release capture, so other buttons inside this app become unclickable. It happens because when WM_LBUTTONDOWN is processed twice, WM_CAPTURECHANGED is sent and bCaptureState is set to FALSE, then EDIT_WM_LButtonUp does not release capture because bCaptureState is already FALSE. Thing about tests: I have added test case for this problem to be visible. I also had to use todo_wine because SendMessageA for WM_LBUTTONDOWN and WM_LBUTTONUP returns 0 in wine and 1 in windows (which is not the case for combobox test, where SendMessageА for WM_LBUTTONDOWN also returns 1 in wine). -- v5: comctl32_v6/edit: set bCaptureState flag after SetCapture() user32/edit: set bCaptureState flag after SetCapture() comctl32/tests/edit.c: Test WM_LBUTTONDOWN processing user32/tests/edit.c: Test WM_LBUTTONDOWN processing https://gitlab.winehq.org/wine/wine/-/merge_requests/10104

2 5