- Wine-GitLab - list.winehq.org

Re: [PATCH v2 0/2] MR10269: qcap: Fix Smart Tee negotiation and V4L WoW64 media type marshaling.
by Elizabeth Figura (＠zfigura) March 9, 2026

March 9, 2026

The merge request message here is apparently written with AI. That's not helpful. Was the code itself written with AI? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10269#note_131618

1 0

[PATCH 0/3] MR10275: windows.media.speech: Some smaller changes
by Bernhard Kölbl March 9, 2026

March 9, 2026

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

2 4

[PATCH 0/1] MR10276: ntdll/wineandroid: Redirect stdout/stderr to Android logcat in the Java startup path
by Twaik Yont (＠twaik) March 9, 2026

March 9, 2026

This change redirects Wine’s `stdout` and `stderr` to Android `logcat` when running through the Java entry point used by `wineandroid.drv`. Currently `WineActivity` writes debug output to a file via the `WINEDEBUGLOG` mechanism. In practice this is inconvenient to use: the file lives in the application's private storage and reading it on a device typically requires either a debug build or root access. Even when accessible, inspecting logs directly on the device is less practical than using Android’s standard logging tools. Android applications normally expose diagnostic output through logcat. This change forwards Wine’s `stdout` and `stderr` to `logcat` so that Wine debug output can be observed using standard Android tooling (`adb logcat`, Android Studio, etc.) without accessing the application’s internal storage. The implementation is intentionally simple and best-effort. A pipe is installed on `stdout` and `stderr` and a small detached thread forwards the output to `__android_log_write()`. Data is forwarded in chunks without reconstructing line boundaries; this is sufficient for diagnostic purposes and keeps the implementation minimal. The redirection is only enabled in the Android Java startup path, which corresponds to the environment used by `wineandroid`. In this configuration `stdout` and `stderr` are typically not visible to the user (commonly pointing to `/dev/null`), so redirecting them to logcat does not replace any usable diagnostics channel. It is also unlikely that Wine will be compiled directly on Android devices in practice. Android does not provide an official NDK toolchain that runs on-device, and mingw toolchains are not distributed for Android either. Building Wine therefore normally happens off-device using standard cross-compilation toolchains (android NDK, mingw, host toolchain). Because of this, the `logcat` forwarding is primarily intended for runtime diagnostics and debugging rather than build-time development directly on the device. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10276

3 4

[PATCH v3 0/2] MR9857: ntdll/unix: Reimplement fill_vm_counters() for macOS.
by Jactry Zeng (＠jactry) March 9, 2026

March 9, 2026

On Windows, PagefileUsage represents the total private memory committed by a process, includes both resident memory in RAM and pages swapped to the disk. On macOS, virtual_size is misleading as it represents the total reserved address space, which is often vastly larger than actual usage; for example, it can be 40+GB when a program was alloced about 4GB memory on a machine with 16GB RAM (tested on Intel macOS 15.7.2 and Apple Silicon macOS 26.2). In order to make it closer to the Windows metric, using the sum of TASK_VM_INFO.internal (resident private memory in RAM) and swapped pages (includes both compressed memory in RAM and pages that were swapped to the disk) from mach_vm_region_recurse() is more correct. I also use the sum of TASK_VM_INFO.internal and TASK_VM_INFO.compressed (compressed memory, and still in RAM) as a fallback when mach_vm_region_recurse() fails; however, this doesn't include that the memory has been compressed and swapped to the disk[0], but it is still correct relatively to the current implementation. [0] https://github.com/apple-oss-distributions/xnu/blob/f6217f/osfmk/kern/task.… -- v3: ntdll/tests: Test PagefileUsage with a large memory reservation. ntdll/unix: Reimplement fill_vm_counters() for macOS. https://gitlab.winehq.org/wine/wine/-/merge_requests/9857

2 3

[PATCH 0/1] MR10272: iphlpapi: Swap the order of address families in call_families to process IPv4...
by Zhao Yi (＠Zhaoyi) March 9, 2026

March 9, 2026

A Ruby application obtains network adapter IP information by calling the **Win32_NetworkAdapterConfiguration** class. However, the order of IPv4 and IPv6 addresses retrieved on Windows differs from that retrieved when running on Wine, which causes Ruby applications running on Wine to malfunction. A test demo was written that calls the **Win32_NetworkAdapterConfiguration** class to obtain network adapter information. It was run on Windows and on Wine respectively, and the results are as follows. The results of running on Windows： ![test-on-windows](/uploads/fa48781357a2b86e10fbb5a616ca25ad/test-on-windows.png){width=357 height=153} The results of running on Wine： ![test-on-wine](/uploads/79e0bffb5a41b529c5b3593c449121f4/test-on-wine.png){width=363 height=66} -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10272

4 3

[PATCH v8 0/3] MR10114: msi: Handle unusual installer files (padding, malformed strrefs)
by Theodoros Chatzigiannakis (＠TChatzigiannakis) March 9, 2026

March 9, 2026

This PR addresses two issues that I observed preventing the Native Instruments Kontakt Player MSI (and other MSI files from the same vendor) from successfully finishing: 1. Some installers contain padding for 4-byte alignment of table streams. * Proposed fix: We relax Wine's parsing to allow for such padding. 2. Some installers declare that they have 3-byte strrefs, but the data actually contains 2-byte strrefs. This looks like a malformed MSI to me, and Wine correctly rejects them currently. The regression tests in this PR indicate that Windows in CI (test-win10-21h2-\*) is reading garbage as well. However, NI ships these MSI files, which implies that somehow the installation successfully completes on Windows machines nevertheless. * Proposed fix: We explicitly detect and correct this particular mismatch at load time of the MSI, in order to be able to complete the installation under Wine as well. --- The above are technically separate issues, but they affect the same software in similar ways, so I opted for one PR. Please me know if I should split them. --- Quick repro hint: Native Instruments offers a program called Native Access (which acts as an installation hub on the user's machine). On user request, NA downloads and launches the affected MSI files in the background. If you try to repro, a couple of things to watch out for: 1. NA seems to always report a successful installation, even when the underlying MSI fails to complete (and therefore nothing is installed). This PR does nothing to address this false positive, as it is most likely a logic bug in the hub or installation orchestration. 2. To observe/examine the underlying MSI files (including the fix presented here), you'll need to grab them after NA downloads and extracts them on your machine (or find manual/direct downloads on the NI website, where applicable) --- _Disclaimers for reviewers:_ * _AI was used while tracking down the issues and coming up with fixes._ * _I am not affiliated with Native Instruments, I'm just a user._ -- v8: msi/tests: Add regression tests for table stream padding and mismatched string refs. https://gitlab.winehq.org/wine/wine/-/merge_requests/10114

2 4

Re: [PATCH v2 0/2] MR10269: qcap: Fix Smart Tee negotiation and V4L WoW64 media type marshaling.
by zhineng cao (＠LilFishyChan) March 9, 2026

March 9, 2026

There are 3 failures in tests. But it doesn't seem to have anything to do with my modifications? Is it Flaky Tests? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10269#note_131596

1 0

[PATCH 0/2] MR10269: qcap: Fix Smart Tee negotiation and V4L WoW64 media type marshaling.
by zhineng cao (＠LilFishyChan) March 9, 2026

March 9, 2026

## Summary This work started from a real-world regression: in VRChat, the camera could not be used. After investigation, VRChat was found to use DirectShow for camera capture/preview. The issue was then narrowed down to qcap behavior differences, and fixes were implemented in source code to align with native behavior. This MR includes: 1. Smart Tee preview RGB32 negotiation fix. 2. V4L wow64 media type marshaling fix. These changes are expected to resolve this class of DirectShow camera compatibility issues. ## Root cause and approach - Application symptom: VRChat camera path failed. - API path: DirectShow camera pipeline. - Scope narrowed to qcap Smart Tee preview negotiation and wow64 media-type marshaling in V4L backend. - Implemented behavior-aligned fixes and corresponding conformance tests. ## Validation - Native Windows behavior was probed and used as baseline during test alignment. - `qcap_test.exe smartteefilter`: **488 tests, 0 failures** (i386/x86_64) - `qcap_test.exe videocapture`: **754 tests, 0 failures** (i386/x86_64) - Functional app check: `AMCap.exe` preview opens camera successfully and image display is normal. ## Expected impact This MR is expected to fix/mitigate similar cases where DirectShow-based applications fail to initialize or preview camera streams under Wine. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10269

2 4

[PATCH 0/1] MR10274: winegcc: Remove unused libgcc variable.
by Sven Baars (＠sbaars) March 9, 2026

March 9, 2026

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

3 2

[PATCH 0/1] MR10265: winewayland: Implement support for min/max window size hints.
by Etaash Mathamsetty (＠etaash.mathamsetty) March 9, 2026

March 9, 2026

Ideally this would have something to check the previous state, but since set_min_size/set_max_size don't emit any configure events, this shouldn't be a problem. This is a prerequisite for implementations of server-side decorations to work well. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10265

2 2