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

[PATCH 0/1] MR10547: Increase the portability of unions
by Safocl Stollmannovic (＠safocl88) July 18, 2026

July 18, 2026

One special guarantee is made in order to simplify the use of unions: if a union contains several structures that share a common initial sequence (see below), and if the union object currently contains one of these structures, it is permitted to inspect the common initial part of any of them anywhere that a declaration of the complete type of the union is visible. Increase the portability of unions by using a common initial sequence. Also undefined behavior is fixed when the value of an object with automatic storage duration is used while it is indeterminate: ```c union U{ int i; struct {int i; int j;} s; }; U u; u.i = 42; // U::i is active member; u.s.j = 42; // U::s is the active member with initialized s.j, s.i is the indeterminate value; int i = u.s.i; // UB: accessing a value while it is indeterminate int i2 = u.i; // UB: U::i does not have the expected value, even if type-punning is supported ``` C-standart (ISO/IEC 9899:TC2 Committee Draft — May 6, 2005 WG14/N1124): > J.2 Undefined behavior > > — The value of an object with automatic storage duration is used while it is indeterminate (6.2.4, 6.7.8, 6.8). I'm not even sure that the original code would have type-punning behavior between a structure member (which is a member of a union) and a member of union of integer type. I also believe that not all compilers support this non-standard behavior, and while it's not undefined behavior in C, as it is in C++, it is unspecified behavior, which also makes it impossible to predict the program's behavior (the value of the data). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10547

3 5

[PATCH 0/1] MR11107: user32:Unify drop_target cleanup at end of drag_drop_drop to avoid spurious...
by zhou zhang (＠zhouzhang) July 17, 2026

July 17, 2026

user32:Unify drop_target cleanup at end of drag_drop_drop to avoid spurious DragLeave in next DnD session Change-Id: I1213239a7c7981c4d3f7cb56281e3687527c7885 Bug: drag_drop_drop calls IDropTarget_Drop but fails to Release+NULL drop_target. When the next XdndEnter arrives, drag_drop_enter releases the old data_object, whose destructor sees the stale drop_target is non-NULL,incorrectly calls IDropTarget_DragLeave, and interrupts the new drag session. Fix: Remove Release+NULL from the else-if branch, add a single Release+NULL after if (drop_file) as the sole cleanup point, avoiding double-release. Cannot reproduce in Wine tests: DoDragDrop API bypasses clipboard.c entirely and has no stale pointer issue; the X11 DnD path requires cross-process COM deferred Release timing, which cannot be simulated in a simple Wine test case. MSDN:https://learn.microsoft.com/en-us/windows/win32/api/oleidl/nf-oleidl-i… [drop_receiver.exe](/uploads/85f0571bc354238576bf9e50a62f12e2/drop_receiver.exe) [drop_receiver.c](/uploads/b409b8a12a352dae9dbd4dab5fa322d2/drop_receiver.c) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11107

2 3

[PATCH 0/2] MR8015: ntoskrnl.exe: Do not send IRP to get device instance ID.
by Alexander Morozov (＠amorozov) July 16, 2026

July 16, 2026

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

6 8

[PATCH v4 0/4] MR10535: mfreadwrite: Rescale video frames based on aspect ratio when processing is enabled.
by Yuxuan Shui (＠yshui) July 15, 2026

July 15, 2026

-- v4: mfreadwrite: Ensure output has a 1:1 pixel aspect ratio if processing is enabled. https://gitlab.winehq.org/wine/wine/-/merge_requests/10535

4 9

[PATCH v2 0/8] MR11263: ntoskrnl.exe: Various fixes around PDO behavior.
by Connor McAdams (＠cmcadams) July 14, 2026

July 14, 2026

This series of patches are prerequisites for changing how device instance IDs (and eventually container IDs) are assigned by the PnP manager. MR !8015 touched the same area, this should fix the same bug that MR intended to address. -- v2: ntoskrnl: Use cached device instance ID for DevicePropertyEnumeratorName. ntoskrnl: Cache device instance ID for PDOs. ntoskrnl: Add checks for DEVICE_OBJECTs passed into various PnP functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/11263

3 14

[PATCH 0/3] MR10998: gdi32/uniscribe: Reworking mark_invalid_combinations()
by समीरसिंह Sameer Singh (＠ss141309) July 13, 2026

July 13, 2026

Hi, while solving #59680 I noticed some discrepancies in the behaviour of mark_invalid_combinations in wine and in windows. In wine, combinations are only marked invalid when two adjacent characters shared the same context type, so for example a single arabic fatha `َ` will not be displayed with a dotted_circle under wine. This is not the case for windows. Thus in the game Path of Exile, the combination of latin+thai_mark, the single thai_mark is invisible, because the itemizer separates the latin and thai in two different runs, the thai mark is an isolated character with no base to be attached to, the game expects that this mark will appear with a base character. This can also be seen with this program: ```c #include <windows.h> #include <usp10.h> #include <stdio.h> #define MAKE_OPENTYPE_TAG(a,b,c,d) ((OPENTYPE_TAG)(a) | ((OPENTYPE_TAG)(b) << 8) | ((OPENTYPE_TAG)(c) << 16) | ((OPENTYPE_TAG)(d) << 24)) int dump_unicode_for_glyph(HDC hdc, WORD target_gid) { for (DWORD i = 0x0020; i <= 0xFFFF; i++) { WCHAR ch = (WCHAR)i; WORD gid = 0xFFFF; if (GetGlyphIndicesW(hdc, &ch, 1, &gid, GGI_MARK_NONEXISTING_GLYPHS) != GDI_ERROR) { if (gid == target_gid) return i; } } } void dump_shape_results(HDC hdc, const WCHAR *pwcChars, int cChars, const WORD *pwOutGlyphs, int cGlyphs, const WORD *pwLogClust, const SCRIPT_CHARPROP *pCharProps, const SCRIPT_GLYPHPROP *pGlyphProps) { printf("cChars=%d cGlyphs=%d\n\n", cChars, cGlyphs); printf("Input characters:\n"); for (int i = 0; i < cChars; i++) printf(" pwcChars[%d] = U+%04X LogClust=%d\n", i, pwcChars[i], pwLogClust[i]); printf("\nOutput glyphs:\n"); for (int i = 0; i < cGlyphs; i++) { printf(" glyph[%d] = %d (U+%04X) fDiacritic=%d fZeroWidth=%d\n", i, pwOutGlyphs[i], dump_unicode_for_glyph(hdc, pwOutGlyphs[i]), pGlyphProps[i].sva.fDiacritic, pGlyphProps[i].sva.fZeroWidth); } printf("\n\n"); } void test_shape(HDC hdc, const WCHAR *pwcChars, OPENTYPE_TAG tagScript) { SCRIPT_ITEM items[2]; int num_items = 0; ScriptItemize(pwcChars, 1, 2, NULL, NULL, items, &num_items); SCRIPT_CACHE sc = NULL; SCRIPT_ANALYSIS sa = items[0].a; WORD glyphs[8], log_clust[8]; SCRIPT_CHARPROP char_props[8]; SCRIPT_GLYPHPROP glyph_props[8]; int glyph_count = 0; ScriptShapeOpenType(hdc, &sc, &sa, tagScript, 0, NULL, NULL, 0, pwcChars, 1, 8, log_clust, char_props, glyphs, glyph_props, &glyph_count); dump_shape_results(hdc, pwcChars, 1, glyphs, glyph_count, log_clust, char_props, glyph_props); ScriptFreeCache(&sc); } int main(void) { WCHAR arabic_lone_mark[1] = { 0x064E }; OPENTYPE_TAG arabic_tag = MAKE_OPENTYPE_TAG('a', 'r', 'a', 'b'); HDC hdc = CreateCompatibleDC(NULL); HFONT arabic_font = CreateFontW(32, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, L"Noto Naskh Arabic"); HFONT old_font = SelectObject(hdc, arabic_font); printf("Shaping Arabic\n"); test_shape(hdc, arabic_lone_mark, arabic_tag); WCHAR thai_lone_mark[1] = { 0x0E4E }; OPENTYPE_TAG thai_tag = MAKE_OPENTYPE_TAG('t', 'h', 'a', 'i'); HFONT thai_font = CreateFontW(32, 0, 0, 0, FW_NORMAL, FALSE, FALSE, FALSE, DEFAULT_CHARSET, OUT_DEFAULT_PRECIS, CLIP_DEFAULT_PRECIS, DEFAULT_QUALITY, DEFAULT_PITCH, L"Kanit"); old_font = SelectObject(hdc, thai_font); printf("Shaping Thai\n"); test_shape(hdc, thai_lone_mark, thai_tag); DeleteObject(arabic_font); DeleteObject(thai_font); DeleteDC(hdc); return 0; } ``` When run under windows, the output is: ``` PS C:\Users\ss141309\Desktop\Shared> .\up32.exe Shaping Arabic cChars=1 cGlyphs=2 Input characters: pwcChars[0] = U+064E LogClust=1 Output glyphs: glyph[0] = 379 (U+064E) fDiacritic=1 fZeroWidth=1 glyph[1] = 235 (U+25CC) fDiacritic=0 fZeroWidth=0 Shaping Thai cChars=1 cGlyphs=2 Input characters: pwcChars[0] = U+0E4E LogClust=0 Output glyphs: glyph[0] = 593 (U+0020) fDiacritic=0 fZeroWidth=1 glyph[1] = 737 (U+0E4E) fDiacritic=1 fZeroWidth=1 ``` Even the microsoft documentation, does not mention that combining marks are only invalid when they are succeeded by the same class of mark. [See:](https://learn.microsoft.com/en-us/typography/script-development/arabi… > ## Handling Invalid Combining Marks > > Combining marks and signs that appear in text not in conjunction with a valid consonant base are considered _invalid._ Uniscribe displays these marks using the fallback rendering mechanism defined in the Unicode Standard (section 5.12, 'Rendering Non-Spacing Marks' of the Unicode Standard 3.1), i.e. positioned on a dotted circle. > > Please note that to render a sign standalone (in apparent isolation from any base) one should apply it on a space (see section 2.5 'Combining Marks' of Unicode Standard 3.1). Uniscribe requires a ZWJ to be placed between the space and a mark for them to combine into a standalone sign. > > For the fallback mechanism to work properly, an Arabic OTL font should contain a glyph for the dotted circle (U+25CC). In case this glyph is missing form the font, the invalid signs will be displayed on the missing glyph shape (white box). > > In addition to the 'dotted circle,' other Unicode code points that are recommended for inclusion in any Arabic font are: ZWNJ (zero width non-joiner; U+200C), ZWJ (zero width joiner U+200D), LTR (left to right mark; U+200E), and RTL (right to left mark; U+200F). The ZWNJ can be used between two letters to prevent them from forming a cursive connection. > > ![Illustration that shows suggested glyphs for the five Unicode code points.](https://learn.microsoft.com/en-us/typography/script-development/im… > > If an invalid combination is found, like two fathas on the same base character, the diacritic that causes the invalid state is placed on a dotted circle to indicate to the user the invalid combination. The shaping engine for non-OpenType fonts will cause invalid mark combinations to overstrike. This is the problem that inserting the dotted circle for the invalid base solves. It should also be noted that the dotted circle is not inserted into the application's backing store. This is a run-time insertion into the glyph array that is returned from the **ScriptShape** function. > > The invalid diacritic logic for Arabic is based on the classes listed below. There is a check to make sure more than one mark of a class is not placed on the same base. Additionally, DIAC1 and DIAC2 classes should not be applied on the same base character. So was there a historical reason for this behaviour? If I get a go ahead with this approach, I will fix the tests next. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10998

2 4

[PATCH 0/1] MR9649: dlls/hhctrl.ocx：no need to set WS_VISSIBLE to Select Topic window
by pan hui (＠panhui) July 13, 2026

July 13, 2026

After creating the Select Topic window, it was first displayed and then hidden, causing the user to see a black window appear and disappear, affecting their experience; There is no need to set WS_VISSIBLE to display the Select Topic window first. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9649

3 2

[PATCH 0/1] MR11189: setupapi: Implement SPDRP_ENUMERATOR_NAME and fix missing error codes in...
by Yue Zhang (＠YueZhang) July 10, 2026

July 10, 2026

SPDRP_ENUMERATOR_NAME was unmapped in PropertyMap, causing the function to return FALSE without setting any error code. Extract the enumerator name from the device instance ID for both A/W variants. Also set ERROR_INVALID_DATA for unknown properties instead of returning with stale error codes, which fixes infinite retry loops in some driver installers (e.g., vivo pcsuite). Tests added for both A and W variants: * SPDRP_UNUSED0 returns ERROR_INVALID_DATA * SPDRP_ENUMERATOR_NAME returns correct enumerator name (e.g. "ROOT") * PropertyRegDataType set to REG_SZ * RequiredSize correctly reported when probing with NULL buffer * ERROR_INSUFFICIENT_BUFFER when buffer too small or NULL with size=0 * Failure when PropertyBuffer is NULL but PropertyBufferSize \> 0 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11189

3 4

[PATCH 0/2] MR11154: dsound: Add conversions to 7.1 audio.
by Arek Hiler (＠ivyl) July 10, 2026

July 10, 2026

Found with Portal 2. In settings you can set it to 2 speakers, 4 speakers or 5.1 audio. 7.1 setups are popular with home cinema and soundbars. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/11154

4 8

[PATCH v7 0/2] MR10340: comctl32/tooltips: suppress icon and title when title is NULL or empty.
by Larry Starr (＠starrl) July 9, 2026

July 9, 2026

Per MSDN, TTM_SETTITLE with a NULL or empty title string should suppress both the title row and any associated icon. Previously an empty string was treated the same as a non-empty title, causing the icon to still be displayed and the tooltip to be incorrectly sized. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=58236 Signed-off-by: Larry Starr <Larry_A_Starr(a)yahoo.com> -- v7: comctl32/tooltips: suppress icon and title when title is NULL or empty. comctl32/tooltips/tests: add regression test for TTM_SETTITLE with NULL or empty title. https://gitlab.winehq.org/wine/wine/-/merge_requests/10340

4 5