- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR10642: shcore: Handle 64-bit position in file stream Seek().
by Nikolay Sivov (＠nsivov) April 12, 2026

April 12, 2026

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=59643 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10642

2 1

[PATCH v8 0/8] MR10569: wineandroid: move ioctl handling to dedicated Java-only thread
by Twaik Yont (＠twaik) April 12, 2026

April 12, 2026

Move ioctl handling out of the Wine APC/unixlib execution path into a dedicated Java-only thread without Wine context. On Android 10+ a number of syscalls are restricted inside the activity process via seccomp, while processes started via fork/exec are not subject to the same limitations. Decoupling ioctl handling from the Wine context is required to eventually run this code outside of the activity process. This change introduces a new transport and execution model where ioctl dispatch no longer depends on Wine thread state, preparing for moving the Android backend into a separate process. The refactor is intentionally split into multiple bisect-safe commits to keep intermediate states functional while gradually migrating the dispatch path. Since this is a fairly large chunk of work, I’d like to make sure we’re aligned before continuing. -- v8: wineandroid: drop dlsym for ntdll globals wineandroid: remove legacy unixlib ioctl backend wineandroid: drop old ioctl backend startup and switch to socket transport wineandroid: add socket-based ioctl backend (unused) wineandroid: add reply_fd plumbing to ioctl handlers wineandroid: move native window registration to surface_changed wineandroid: migrate ioctl dispatch logging to Android log https://gitlab.winehq.org/wine/wine/-/merge_requests/10569

2 9

[PATCH v3 0/1] MR10452: comctl32/tests: Print id field of logged/expected messages on failure
by Piotr Pawłowski (＠DEATH) April 12, 2026

April 12, 2026

Makes debugging of WM_NOTIFY message sequence errors much easier. -- v3: comctl32/tests: Print id field of logged/expected messages on failure https://gitlab.winehq.org/wine/wine/-/merge_requests/10452

3 3

[PATCH 0/5] MR10641: user32/tests: Refactor keyboard navigation tests out of the monolithic check test.
by James Hawkins (＠truiken) April 12, 2026

April 12, 2026

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

2 5

[PATCH v4 0/3] MR10634: kernel32: Fix application restart and recovery API stubs.
by 徐世恩 (＠san65384) April 12, 2026

April 12, 2026

-- v4: kernel32: Fix application restart and recovery API stubs. kernel32/tests: Add tests for application restart and recovery APIs. https://gitlab.winehq.org/wine/wine/-/merge_requests/10634

2 3

[PATCH v3 0/3] MR10634: kernel32: Fix application restart and recovery API stubs.
by 徐世恩 (＠san65384) April 12, 2026

April 12, 2026

-- v3: kernel32: Fix application restart and recovery API stubs. kernel32/tests: Add tests for application restart and recovery APIs. https://gitlab.winehq.org/wine/wine/-/merge_requests/10634

2 3

[PATCH v2 0/3] MR10634: kernel32: Fix application restart and recovery API stubs.
by 徐世恩 (＠san65384) April 12, 2026

April 12, 2026

-- v2: kernel32/tests: Add tests for application restart and recovery APIs. https://gitlab.winehq.org/wine/wine/-/merge_requests/10634

2 3

Re: [PATCH v2 0/3] MR10298: mfreadwrite: Implement sample encoding.
by Ziqing Hui (＠zhui) April 12, 2026

April 12, 2026

> This one is confusing. Why would be do encode_sample() more than once? Is it possible to have multiple encoders one after another? Or is the helper name simply misleading and it means "process" in general, instead of "encode"? Sorry for the misleading name. Yes, it means "process" instead of "encode". It is used for transform processing in general, not only for encoding. > What is the idea behind next_transform? It looks like this code allows two transforms at maximum, is there a limit to this chain on Windows? next_transform is for the converter -> encoder case. We support at most two transforms: one converter and one encoder. As far as I now, there is no longer transform chain on Windows. We have 2 cases for the next_transform: 1. next_transform is NULL, in this case, there is only one transform for the stream, or we have already handled converter and we are passing converter output to encoder. 2. next_transform is a encoder, in this case we have converter -> encoder. Having the next_transform parameter makes us be able to handle each case in one single helper function. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10298#note_135891

1 0

Re: [PATCH v2 0/3] MR10298: mfreadwrite: Implement sample encoding.
by Ziqing Hui (＠zhui) April 12, 2026

April 12, 2026

On Sun Apr 12 01:30:25 2026 +0000, Nikolay Sivov wrote: > I would merge last two commits, because the second one does not do > anything on its own. OK, I'll merge last 2 commits in new version. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10298#note_135890

1 0

Re: [PATCH v2 0/4] MR10604: setupapi, ntoskrnl: Implement CM_Get_Parent with device tree properties
by Jan Robert Gerigk (＠RgSg86) April 12, 2026

April 12, 2026

On Thu Apr 9 01:29:48 2026 +0000, Jan Robert Gerigk wrote: > Great detailed feedback, thanks! That is a lot to work through, I think > it will take me a while. I think I have addressed all feedback points: ntoskrnl: Removed the unnecessary comment and the if (parent_device) check. enumerate_new_device now receives the parent device object directly (no original_parent field). Uses wcslen/malloc instead of lstrlenW/HeapAlloc. Removed error handling gymnastics for get_device_instance_id, if it fails there's no point proceeding. Children and Siblings are stored in separate commits, comments removed. Removed unnecessary if (relations-\>Count \> 0) check. Siblings moved out to their own block. cfgmgr32: CM_Get_Parent implemented in cfgmgr32, setupapi forwards to it. Tests: Simplified CM_Get_Parent error check to CR_SUCCESS || CR_NO_SUCH_DEVNODE. Kept the if (ret == CR_SUCCESS) guard before CM_Get_Device_IDA. The test device is created manually via SetupDiCreateDeviceInfoW, not through bus enumeration, so DEVPKEY_Device_Parent is never stored for it. CM_Get_Parent returns CR_NO_SUCH_DEVNODE in this case, and calling CM_Get_Device_IDA on an uninitialized devnode would crash. Added ok() check for SetupDiRemoveDevice. New commit: cfgmgr32: Fix reading device properties stored as registry subkeys. While switching to cfgmgr32 s internal APIs (devnode_get_device + get_device_property), I found that query_property cannot read properties stored by SetupDiSetDevicePropertyW. It tries to read them as flat value names, but setupapi stores them as registry subkey hierarchies (Properties{GUID}\\XXXX with the data in the default value). Added a fallback to open the property subkey when the flat lookup fails. The final version has been tested locally with a freshly compiled Wine build including all these patches. All tests pass on my local maschine. (26430 ntoskrnl, 4366 setupapi devinst, 235 shcore, 0 failures). Also verified again with my real use-case, CM_Get_Parent correctly returns the USB parent device. The USB license dongle is correctly detected and used by the software. That was incredibly complex for me, I hope I did not miss anything. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10604#note_135887

1 0