- Wine-GitLab - list.winehq.org

[PATCH v15 0/1] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v15: fix: extended-file-name support https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 1

[PATCH v2 0/3] MR10095: mf: Implement IMFTimer using a periodic callback.
by Brendan McGrath (＠redmcg) Feb. 27, 2026

Feb. 27, 2026

In preparation for adding the `IMFPresentationTimeSource` interface to SAR, this MR adds tests for `IMFPresentationClock` using a custom `IMFPresentationTimeSource`. These tests highlighted a couple of issues in wine: 1. Clock events are sent to a clock sink twice if it is also the presentation time source; and 2. The `IMFTimer::SetTimer` calls do not work correctly. This MR also addresses both of these issues. -- v2: mf: Implement IMFTimer using a periodic callback. mf: Don't async notify a sink that is also the time source. mf/tests: Test presentation clock with custom time source. https://gitlab.winehq.org/wine/wine/-/merge_requests/10095

3 9

[PATCH v2 0/2] MR10162: d2d1: Clamp opacity value for d2d_device_context_draw_bitmap().
by Zhiyi Zhang (＠zhiyi) Feb. 27, 2026

Feb. 27, 2026

Some applications call DrawBitmap() with the opacity value set to 255.0f and end up showing white in the end result. Tests show that the opacity value should be clamped to legitimate values. Command lists store the original opacity value according to tests. -- v2: d2d1: Clamp opacity value for brushes. d2d1/tests: Test brushes with out of range opacity values. https://gitlab.winehq.org/wine/wine/-/merge_requests/10162

3 4

[PATCH v14 0/1] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v14: fix: extended-file-name support https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 1

[PATCH v12 0/1] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v12: fix: extended-file-name support https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 1

[PATCH v4 0/1] MR10199: msvcrt: Fix no buffering detection in _fwrite_nolock().
by Paul Gofman (＠gofman) Feb. 27, 2026

Feb. 27, 2026

-- v4: msvcrt: Fix no buffering detection in _fwrite_nolock(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10199

3 3

[PATCH v11 0/13] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v11: Fix tests Debug 5 https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 13

[PATCH v10 0/12] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v10: Fix tests Debug 3 https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 12

[PATCH v9 0/11] MR10192: kernelbase: Handle \\?\ prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) Feb. 27, 2026

Feb. 27, 2026

The current implementation of GetLongPathNameW triggers a FIXME and returns the original path when it encounters a UNC prefix. While true network UNC paths remain unimplemented, this change allows extended-length local paths (starting with \\?\) to be resolved by stripping the prefix and processing the underlying local path. This fixes issues where applications (such as xalia) passing absolute paths with the extended-length prefix would fail to receive a normalized or resolved long path. ``` 881.036:00d4:00d8:fixme:file:GetLongPathNameW UNC pathname L"\\\\?\\Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" ``` Tested: After change with added debug log ``` 22272.558:00d4:00d8:fixme:file:GetLongPathNameW DEBUG: Success! Returning path: L"Z:\\home\\vishnunithyasoundhars\\.steam\\debian-installation\\compatibilitytools.d\\debug_build\\files\\share\\wine/../xalia/xalia.exe" (Length: 125) ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v9: Fix tests Debug 3 https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 11

Re: [PATCH v4 0/2] MR10193: dlls/comdlg32：Add the implementation of IServiceProvider_fnQueryService to obtain IFolderView2
by Esme Povirk (＠madewokherd) Feb. 27, 2026

Feb. 27, 2026

This needs to be rebased instead of merged, as Wine uses a linear history. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10193#note_130750

1 0

[PATCH v3 0/1] MR10199: msvcrt: Fix no buffering detection in _fwrite_nolock().
by Paul Gofman (＠gofman) Feb. 27, 2026

Feb. 27, 2026

-- v3: msvcrt: Fix no buffering detection in _fwrite_nolock(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10199

3 6

[PATCH v2 0/6] MR10209: kernelbase/loader.c: Include rudimentary support for multilanguage resource inclusion.
by Craig Schulstad (＠NoDakker) Feb. 27, 2026

Feb. 27, 2026

For programs that rely on language specific data for resources such as menus and text, attempt to search for and associated "mui" file. For example, if program "myapp.exe" is executed and resources are not found, and the user's language ID is "en-US", search for file "en-US/myapp.exe.mui", and if found, utilize that file for the source of resource data. -- v2: kernelbase/loader.c: Add rudimentary support for multiplanguage resource inclusion. https://gitlab.winehq.org/wine/wine/-/merge_requests/10209

2 7

[PATCH v2 0/1] MR10199: msvcrt: Fix no buffering detection in _fwrite_nolock().
by Paul Gofman (＠gofman) Feb. 27, 2026

Feb. 27, 2026

-- v2: msvcrt: Fix no buffering detection in _fwrite_nolock(). https://gitlab.winehq.org/wine/wine/-/merge_requests/10199

2 3

[PATCH 0/1] MR10199: msvcrt: Fix no buffering detection in _fwrite_nolock().
by Paul Gofman (＠gofman) Feb. 27, 2026

Feb. 27, 2026

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

3 5

[PATCH v2 0/3] MR10198: crypt32: Support importing cert-only PKCS12 blobs in PFXImportCertStore.
by Tatsuyuki Ishi (＠ishitatsuyuki) Feb. 27, 2026

Feb. 27, 2026

Fix https://bugs.winehq.org/show_bug.cgi?id=52330 by adding manual parsing logic that can deal with stores with no keys. Confirmed that authorization through the "Manual Authorization" option succeeds in iZotope Audiolens 1.5.0. Also add a drive-by fix to verify PKCS12 MAC. -- v2: crypt32: Verify MAC before parsing the store in PFXImportCertStore. crypt32/tests: Add tests for importing cert-only PKCS#12 blobs. crypt32: Support importing cert-only PKCS#12 blobs in PFXImportCertStore. https://gitlab.winehq.org/wine/wine/-/merge_requests/10198

3 5

Re: [PATCH v2 0/5] MR10203: comctl32/treeview: Multiple bugs fixed, implemented missing Windows XP level features - closed
by Piotr Pawłowski Feb. 27, 2026

Feb. 27, 2026

This merge request was closed by Piotr Pawłowski. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10203

1 0

Re: [PATCH v2 0/5] MR10203: comctl32/treeview: Multiple bugs fixed, implemented missing Windows XP level features
by Piotr Pawłowski Feb. 27, 2026

Feb. 27, 2026

Breaking MR apart due to failing tests. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10203#note_130716

1 0

Re: [PATCH v2 0/1] MR3360: shell32: Improve shell copy and delete items functions, notifications. - closed
by Huw Campbell (＠HuwCampbell) Feb. 27, 2026

Feb. 27, 2026

This merge request was closed by Huw Campbell. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3360

1 0

[PATCH v5 0/3] MR9874: wineandroid.drv: experimental bring-up fixes for Android 7.1.x
by Twaik Yont (＠twaik) Feb. 27, 2026

Feb. 27, 2026

Requires #10067, fixup/followup to e0d3683d8947cd9a3cb20acdf69091b183a90861 and 4b5311c7e02aa7ab2409f8fdcd22233f116dc4bc. #### Note on authorship and language This text was translated into English and structured with the assistance of ChatGPT. The author is not a native English speaker and may struggle with written technical English; any wording issues are unintentional. #### Description This merge request is an experimental attempt to bring wineandroid.drv back to a minimally functional state on Android 7.1.x. The current Android support appears to have bit-rotted over time, likely due to a combination of internal contract changes in Wine, toolchain and NDK evolution, and the absence of continuous Android testing. The changes proposed here aim to re-establish a working baseline and make the regressions more concrete and easier to reason about. #### Test environment and context All testing so far was performed on Android 7.1.2 x86 images from the Android-x86 project, published on osboxes.org ([link](https://www.osboxes.org/android-x86/)) The primary target is i386 Wine running on x86 Android userspace. Because no up-to-date official Android build scripts were available, Wine was built using Termux as an unsupported but convenient environment for rapid testing. The Java part (WineActivity and related glue code) was built with `sharedUserId = com.termux` purely for convenience (filesystem access and faster prototyping). **Termux is explicitly not considered a supported environment and is mentioned only to provide context for the testing setup.** The build uses Android NDK r29. Since the last known functional Android Wine builds, the NDK and linker behavior have changed multiple times, including symbol visibility and relocation handling. These changes appear to have directly affected several failure modes described below. There is also a known issue with wine-preloader producing excessively large binaries under recent toolchains; a workaround exists but is not included here and is mentioned only as additional context. #### Scope of changes This merge request currently modifies only Android-specific code: - `wineandroid.drv` (native code and Java glue, including WineActivity) - android-only paths in `dlls/ntdll/unix/loader.c` No non-Android platforms are affected. #### Summary of resolved issues 1) Desktop initialization ordering regression After recent `CreateDesktopW`-related changes, `ANDROID_CreateDesktop` started running before the DESKTOP window was created. The Java glue assumed the opposite order. The fix splits desktop initialization into two phases (view setup first, desktop window attachment later via an explicit is_desktop flag) and corrects the `ANDROID_CreateDesktop` success return value. 2) Rendering stalls and `USER lock assertion` Occasional crashes with: ``` err:system:user_check_not_lock BUG: holding USER lock ``` A full memory barrier was added in the dequeue path to avoid a likely memory ordering issue. Additionally, a guard was added for a `NULL` buffer returned on successful dequeue. 3) Early startup failure in `virtual_alloc_first_teb` Wine frequently failed with: ``` err:virtual:virtual_alloc_first_teb wine: failed to map the shared user data: c0000018 ``` `virtual_init()` is now called from `JNI_OnLoad()` to reduce the likelihood of the JVM reserving the required address range before Wine initializes its virtual memory subsystem. #### Remaining issues - Window focus handling is partially broken: windows receive focus on click, but are not always raised to the front. - Despite the available desktop area being larger (e.g. 1024x696), Wine consistently reports a display resolution of 800x600. #### Limitations Wine on Android stopped functioning entirely starting with Android 8. As a result, all testing so far has been limited to Android 7.1.x. No claims are made about behavior on newer Android versions. #### Out of scope This merge request intentionally does not attempt to: - redesign IPC mechanisms - introduce new Android integration models - address Android 8+ compatibility The sole goal is to re-establish a minimally working baseline on Android 7.1.x and enable informed discussion about what regressed and how to proceed. **This is my first contribution to Wine, and I am aware that some parts of this analysis or implementation may be flawed. I would be grateful for any review comments or suggestions.** <details> <summary>Also, the screenshot of the working prototype.</summary> ![image](/uploads/d2420de5d9b3b95b8f5184f8a60550d0/image.png){width=743 height=600} </details> -- v5: ntdll: call virtual_init from JNI_OnLoad to avoid early virtual_alloc_first_teb failure Wineandroid: Sanitize dequeueBuffer result and reject missing buffers. https://gitlab.winehq.org/wine/wine/-/merge_requests/9874

3 11

[PATCH 0/3] MR10198: crypt32: Support importing cert-only PKCS12 blobs in PFXImportCertStore.
by Tatsuyuki Ishi (＠ishitatsuyuki) Feb. 27, 2026

Feb. 27, 2026

Fix https://bugs.winehq.org/show_bug.cgi?id=52330 by adding manual parsing logic that can deal with stores with no keys. Confirmed that authorization through the "Manual Authorization" option succeeds in iZotope Audiolens 1.5.0. Also add a drive-by fix to verify PKCS12 MAC. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10198

3 5

[PATCH v3 0/2] MR10190: winu32: Try harder to replace the old drawable everywhere.
by Paul Gofman (＠gofman) Feb. 27, 2026

Feb. 27, 2026

-- v3: win32u: Also try to use DC own drawable in get_updated_drawable() when context is flushed. https://gitlab.winehq.org/wine/wine/-/merge_requests/10190

3 4

[PATCH v3 0/3] MR10175: winmm/tests: Test a curated list of wave formats.
by Giovanni Mascellani (＠giomasce) Feb. 27, 2026

Feb. 27, 2026

This has of course a lot of code in common with the mmdevapi tests, but I don't know what would be a good place to share it. Happy to take suggestions. -- v3: winmm/tests: Test a curated list of wave formats. https://gitlab.winehq.org/wine/wine/-/merge_requests/10175

3 5

[PATCH 0/5] MR10182: dsound: Speed up resampling, part 2
by Anton Baskanov (＠baskanov) Feb. 27, 2026

Feb. 27, 2026

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

4 7

[PATCH v17 0/1] MR10191: comctl32: Implement Tile view style
by Huw Campbell (＠HuwCampbell) Feb. 26, 2026

Feb. 26, 2026

The Tile View in common controls offers a compact and pretty nice way to show some additional context within the list view, without resorting to the full reports mode. It's used a lot in explorer like programs where things like the disk size and file type are shown. But, it's been sitting unimplemented in wine for a long time. I've just spent a few days implementing this by: - Building a small test program in windows to get a feel for how it works - Hacking just enough to get something displaying - Writing a test suite to try and understand the ownership model, getting, and setting, and the various messages passed by windows. - Fixing up the implementation. - Adjusting my program to use I_COLUMNCALLBACK in windows and testing that. - Fixing my implementation to match the behaviour observed. Full disclosure, I originally started this implementation within the ReactOS build system as I had that compiling installed on my Windows box (my Mac is an M1 so doesn't play very nicely with Wine). I've since spun up a Linux VM and continued the work there. All bugs and misunderstandings are my own; I used clean room techniques (read MSDN, write a test program, write tests, compare results, iterate). Interesting things: - I initially wrote layout code for tiling mode as well, but a few rounds of playing with my test program and various layouts and settings (things like `LVS_ALIGNTOP`, `LVS_AUTOARRANGE` and `LVS_ALIGNLEFT`) for both tile mode and icon mode convinced me that they same layout logic (or close enough to). - I noticed some differences in Wine's Icon mode layout as compared to Windows 10. - I didn't fix these, one thing at a time. - I noticed and fixed a bug in SetView, where `UpdateItemSize` was called _after_ `Arrange`; that doesn't work. - The Text colours are really odd, if set to black the sub items show up gray, but any other colour and they're the same as the main. - Layout is tricky, in windows it looks like the first item (file name for example) can flow to 2 lines, and subitems are restricted to 1 - But this is really subtle, using GetItemMetrics kind of assumes there's no 'interference' from other items. - If we're on subitem 2, I don't want to have to fetch 0 and 1 to render their sizes before calculating my own, it seems like an `O(N^2)` situation off the bat. - I used a sidechannel from DrawItems, I'm open to other ideas here. - I haven't tested message passing, many of the test failures for listview at the moment look like sequencing errors for messages. I didn't look into it. - The auto mode on Windows 10 looks quite sophisticated, in that it examines many (all) items before deciding the best size. I haven't done anything interesting for auto size mode. - Not really interesting, but the tabs vs spaces situation in this file is a mess. Next Steps ========== - ~~Test with image lists loaded as well~~ - Hope for feedback here (particularly for messages) - Think about auto sizing. - Think about vertical centering within the space. Windows seems to have this as an option, though I haven't discovered how that works just yet. If Merged ========= Now that I have a pretty good grasp of how this component works and lays things out, once this is merged I'll see if I can do Groups as well. Pictures: ======== ![image](/uploads/ce9ae8f09686182d84b399b8a8b0e2a4/image.png){width=400} ![image](/uploads/8c9d1eb4c362a07c74291b49989c4fd7/image.png){width=300} ![image](/uploads/81392817be792c2b95c962be83145a72/image.png){width=300} And Explorer++ ![image](/uploads/877966fc2ded1901cbb000c75f932719/image.png){width=400} Test Program =========== ```C #include <windows.h> #include <commctrl.h> HINSTANCE g_hInst; HWND g_hLV; static void AddItems(HWND hLV) { static UINT puColumns[2] = {1,2}; LVITEMW it = {0}; it.mask = LVIF_TEXT | LVIF_COLUMNS; it.cColumns = I_COLUMNSCALLBACK; it.iItem = 0; it.iSubItem = 0; it.pszText = LPSTR_TEXTCALLBACK; ListView_InsertItem(hLV, &it); ListView_SetItemText(hLV, 0, 1, L"Static"); ListView_SetItemText(hLV, 0, 2, L"1 KB"); ListView_SetItemText(hLV, 0, 3, L"2026-02-23 12:00"); it.cColumns = 2; it.puColumns = puColumns; it.iItem = 1; it.iSubItem = 0; it.pszText = L"bravo.txt"; ListView_InsertItem(hLV, &it); ListView_SetItemText(hLV, 1, 1, L"Text"); ListView_SetItemText(hLV, 1, 2, L"12 KB"); ListView_SetItemText(hLV, 1, 3, L"2026-02-22 09:30"); } static void AddColumns(HWND hLV) { LVCOLUMNW col = {0}; col.mask = LVCF_TEXT | LVCF_WIDTH; col.cx = 160; col.pszText = L"Name"; ListView_InsertColumn(hLV, 0, &col); col.cx = 140; col.pszText = L"Type"; ListView_InsertColumn(hLV, 1, &col); col.cx = 100; col.pszText = L"Size"; ListView_InsertColumn(hLV, 2, &col); col.cx = 180; col.pszText = L"Modified"; ListView_InsertColumn(hLV, 3, &col); } static void EnableTileView(HWND hLV) { SIZE size = { 100, 70 }; LVTILEVIEWINFO tileViewInfo = {0}; tileViewInfo.cbSize = sizeof(tileViewInfo); tileViewInfo.dwFlags = LVTVIF_FIXEDSIZE; tileViewInfo.dwMask = LVTVIM_COLUMNS | LVTVIM_TILESIZE; tileViewInfo.cLines = 3; tileViewInfo.sizeTile = size; ListView_SetTileViewInfo(hLV, &tileViewInfo); ListView_SetView(hLV, LV_VIEW_TILE); } static void OnGetDispInfo(NMLVDISPINFO* pnmv) { if (pnmv->item.iItem < 0) { return; } if (pnmv->item.mask & LVIF_TEXT) { // Demonstrates that Windows is passing us a size 20 buffer to write to. pnmv->item.pszText = pnmv->item.cColumns == 20 ? L"Yes" : L"No"; } if (pnmv->item.mask & LVIF_IMAGE) { pnmv->item.iImage = -1; } if (pnmv->item.mask & LVIF_STATE) { pnmv->item.state = 0; } if (pnmv->item.mask & LVIF_COLUMNS) { pnmv->item.cColumns = 2; pnmv->item.puColumns[0] = 1; pnmv->item.puColumns[1] = 2; } } static LRESULT OnNotify(WPARAM wParam, LPARAM lParam) { switch (((LPNMHDR)lParam)->code) { case LVN_GETDISPINFO: OnGetDispInfo((NMLVDISPINFO*) lParam); break; } return TRUE; } static LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_CREATE: { g_hLV = CreateWindowExW(WS_EX_CLIENTEDGE, WC_LISTVIEWW, L"", WS_CHILD | WS_VISIBLE | LVS_REPORT | LVS_ALIGNTOP | LVS_SINGLESEL | LVS_SHOWSELALWAYS | LVS_AUTOARRANGE, 0, 0, 0, 0, hWnd, (HMENU)1, g_hInst, NULL); ListView_SetExtendedListViewStyle(g_hLV, LVS_EX_DOUBLEBUFFER | LVS_EX_INFOTIP); AddColumns(g_hLV); AddItems(g_hLV); EnableTileView(g_hLV); return 0; } case WM_SIZE: if (g_hLV) MoveWindow(g_hLV, 0, 0, LOWORD(lParam), HIWORD(lParam), TRUE); return 0; case WM_DESTROY: PostQuitMessage(0); return 0; case WM_NOTIFY: OnNotify(wParam, lParam); return 0; } return DefWindowProcW(hWnd, msg, wParam, lParam); } int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { INITCOMMONCONTROLSEX iccx; g_hInst = hInstance; /* Initialize common controls */ iccx.dwSize = sizeof(iccx); iccx.dwICC = ICC_STANDARD_CLASSES | ICC_WIN95_CLASSES; InitCommonControlsEx(&iccx); WNDCLASSW wc = {0}; wc.lpfnWndProc = WndProc; wc.hInstance = hInstance; wc.lpszClassName = L"WineLvTileSmoke"; wc.hCursor = LoadCursor(NULL, IDC_ARROW); RegisterClassW(&wc); HWND hWnd = CreateWindowExW(0, wc.lpszClassName, L"ListView Tile puColumns Smoke Test", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 700, 450, NULL, NULL, hInstance, NULL); ShowWindow(hWnd, nCmdShow); MSG msg; while (GetMessageW(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessageW(&msg); } return (int)msg.wParam; } ``` -- v17: comctl32: Implement Tile view style https://gitlab.winehq.org/wine/wine/-/merge_requests/10191

2 1

[PATCH v15 0/2] MR10191: Draft: comctl32: Implement Tile view style
by Huw Campbell (＠HuwCampbell) Feb. 26, 2026

Feb. 26, 2026

The Tile View in common controls offers a compact and pretty nice way to show some additional context within the list view, without resorting to the full reports mode. It's used a lot in explorer like programs where things like the disk size and file type are shown. But, it's been sitting unimplemented in wine for a long time. I've just spent a few days implementing this by: - Building a small test program in windows to get a feel for how it works - Hacking just enough to get something displaying - Writing a test suite to try and understand the ownership model, getting, and setting, and the various messages passed by windows. - Fixing up the implementation. - Adjusting my program to use I_COLUMNCALLBACK in windows and testing that. - Fixing my implementation to match the behaviour observed. Full disclosure, I wrote this implementation within the ReactOS build system then copied back the diff as I had that compiling already on my Windows box, and my Mac is an M1 so doesn't play very nicely with Wine. So while I built this code on my Mac in Wine, I can't actually run it there. I'll install a Linux virtual machine at some point and do some testing there too. All bugs and misunderstandings are my own; I used clean room techniques (read MSDN, write a test program, write tests, compare results, iterate). Interesting things: - I initially wrote layout code for tiling mode as well, but a few rounds of playing with my test program and various layouts and settings (things like `LVS_ALIGNTOP`, `LVS_AUTOARRANGE` and `LVS_ALIGNLEFT`) for both tile mode and icon mode convinced me that they same layout logic (or close enough to). - I noticed some differences in Wine's Icon mode layout as compared to Windows 10. - I didn't fix these, one thing at a time. - I noticed and fixed a bug in SetView, where `UpdateItemSize` was called _after_ `Arrange`; that doesn't work. - The Text colours are really odd, if set to black the sub items show up gray, but any other colour and they're the same as the main. - Layout is tricky, in windows it looks like the first item (file name for example) can flow to 2 lines, and subitems are restricted to 1 - But this is really subtle, using GetItemMetrics kind of assumes there's no 'interference' from other items. - If we're on subitem 2, I don't want to have to fetch 0 and 1 to render their sizes before calculating my own, it seems like an `O(N^2)` situation off the bat. - I used a sidechannel from DrawItems, I'm open to other ideas here. - I haven't tested message passing, many of the test failures for listview at the moment look like sequencing errors for messages. I didn't look into it. - The auto mode on Windows 10 looks quite sophisticated, in that it examines many (all) items before deciding the best size. I haven't done anything interesting for auto size mode. - Not really interesting, but the tabs vs spaces situation in this file is a mess. Next Steps ========== - ~~Test with image lists loaded as well~~ - Test properly in Linux - Hope for feedback here (particularly for messages) - Think about auto sizing. If Merged ========= Now that I have a pretty good grasp of how this component works and lays things out, once this is merged I'll see if I can do Groups as well. Pictures: ======== ![image](/uploads/ce9ae8f09686182d84b399b8a8b0e2a4/image.png){width=400} ![image](/uploads/8c9d1eb4c362a07c74291b49989c4fd7/image.png){width=300} Test Program =========== ```C #include <windows.h> #include <commctrl.h> HINSTANCE g_hInst; HWND g_hLV; static void AddItems(HWND hLV) { static UINT puColumns[2] = {1,2}; LVITEMW it = {0}; it.mask = LVIF_TEXT | LVIF_COLUMNS; it.cColumns = I_COLUMNSCALLBACK; it.iItem = 0; it.iSubItem = 0; it.pszText = LPSTR_TEXTCALLBACK; ListView_InsertItem(hLV, &it); ListView_SetItemText(hLV, 0, 1, L"Static"); ListView_SetItemText(hLV, 0, 2, L"1 KB"); ListView_SetItemText(hLV, 0, 3, L"2026-02-23 12:00"); it.cColumns = 2; it.puColumns = puColumns; it.iItem = 1; it.iSubItem = 0; it.pszText = L"bravo.txt"; ListView_InsertItem(hLV, &it); ListView_SetItemText(hLV, 1, 1, L"Text"); ListView_SetItemText(hLV, 1, 2, L"12 KB"); ListView_SetItemText(hLV, 1, 3, L"2026-02-22 09:30"); } static void AddColumns(HWND hLV) { LVCOLUMNW col = {0}; col.mask = LVCF_TEXT | LVCF_WIDTH; col.cx = 160; col.pszText = L"Name"; ListView_InsertColumn(hLV, 0, &col); col.cx = 140; col.pszText = L"Type"; ListView_InsertColumn(hLV, 1, &col); col.cx = 100; col.pszText = L"Size"; ListView_InsertColumn(hLV, 2, &col); col.cx = 180; col.pszText = L"Modified"; ListView_InsertColumn(hLV, 3, &col); } static void EnableTileView(HWND hLV) { SIZE size = { 100, 70 }; LVTILEVIEWINFO tileViewInfo = {0}; tileViewInfo.cbSize = sizeof(tileViewInfo); tileViewInfo.dwFlags = LVTVIF_FIXEDSIZE; tileViewInfo.dwMask = LVTVIM_COLUMNS | LVTVIM_TILESIZE; tileViewInfo.cLines = 3; tileViewInfo.sizeTile = size; ListView_SetTileViewInfo(hLV, &tileViewInfo); ListView_SetView(hLV, LV_VIEW_TILE); } static void OnGetDispInfo(NMLVDISPINFO* pnmv) { if (pnmv->item.iItem < 0) { return; } if (pnmv->item.mask & LVIF_TEXT) { // Demonstrates that Windows is passing us a size 20 buffer to write to. pnmv->item.pszText = pnmv->item.cColumns == 20 ? L"Yes" : L"No"; } if (pnmv->item.mask & LVIF_IMAGE) { pnmv->item.iImage = -1; } if (pnmv->item.mask & LVIF_STATE) { pnmv->item.state = 0; } if (pnmv->item.mask & LVIF_COLUMNS) { pnmv->item.cColumns = 2; pnmv->item.puColumns[0] = 1; pnmv->item.puColumns[1] = 2; } } static LRESULT OnNotify(WPARAM wParam, LPARAM lParam) { switch (((LPNMHDR)lParam)->code) { case LVN_GETDISPINFO: OnGetDispInfo((NMLVDISPINFO*) lParam); break; } return TRUE; } static LRESULT CALLBACK WndProc(HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam) { switch (msg) { case WM_CREATE: { g_hLV = CreateWindowExW(WS_EX_CLIENTEDGE, WC_LISTVIEWW, L"", WS_CHILD | WS_VISIBLE | LVS_REPORT | LVS_ALIGNTOP | LVS_SINGLESEL | LVS_SHOWSELALWAYS | LVS_AUTOARRANGE, 0, 0, 0, 0, hWnd, (HMENU)1, g_hInst, NULL); ListView_SetExtendedListViewStyle(g_hLV, LVS_EX_DOUBLEBUFFER | LVS_EX_INFOTIP); AddColumns(g_hLV); AddItems(g_hLV); EnableTileView(g_hLV); return 0; } case WM_SIZE: if (g_hLV) MoveWindow(g_hLV, 0, 0, LOWORD(lParam), HIWORD(lParam), TRUE); return 0; case WM_DESTROY: PostQuitMessage(0); return 0; case WM_NOTIFY: OnNotify(wParam, lParam); return 0; } return DefWindowProcW(hWnd, msg, wParam, lParam); } int WINAPI wWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPWSTR lpCmdLine, int nCmdShow) { INITCOMMONCONTROLSEX iccx; g_hInst = hInstance; /* Initialize common controls */ iccx.dwSize = sizeof(iccx); iccx.dwICC = ICC_STANDARD_CLASSES | ICC_WIN95_CLASSES; InitCommonControlsEx(&iccx); WNDCLASSW wc = {0}; wc.lpfnWndProc = WndProc; wc.hInstance = hInstance; wc.lpszClassName = L"WineLvTileSmoke"; wc.hCursor = LoadCursor(NULL, IDC_ARROW); RegisterClassW(&wc); HWND hWnd = CreateWindowExW(0, wc.lpszClassName, L"ListView Tile puColumns Smoke Test", WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT, 700, 450, NULL, NULL, hInstance, NULL); ShowWindow(hWnd, nCmdShow); MSG msg; while (GetMessageW(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessageW(&msg); } return (int)msg.wParam; } ``` -- v15: Fixup rendering with Images and tidy up focus selector. https://gitlab.winehq.org/wine/wine/-/merge_requests/10191

2 2