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

[PATCH v4 0/9] MR3048: Media.speech improvements.
by eric pouech (＠epo) March 2, 2026

March 2, 2026

This series adds a couple of features to WinRT's media.speech: - IVoiceInformation, and synthetizer's options are present (mainly use to store information, not yet to make fully use of it) - add a dummy implementation (1 single voice); that should be extended in future series by using ISpVoice instead - add a couple of more tests to go with implementation (the serie should prevent MS Flight simulator to crash on first connection. Crash is due to exception handling of C# generated exceptions from E_NOTIMPL with some X11 related critical resources). A+ -- v4: windows.media.speech: Implement get/put voice on synthesizer. windows.media.speech: Select a default voice in synthesizer. windows.media.speech: Add more tests about default voice. windows.media.speech: Finish implementation of voice information view. windows.media.speech/tests: Add tests about vector view's content. windows.media.speech: Add basic implementation of IVoiceInformation. windows.media.speech: Add more tests about IVoiceInformation. windows.media.speech: Add basic implementation on synthesizer options. windows.media.speech: Add a couple of synthesizer's options tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/3048

2 1

Re: [PATCH v2 0/5] MR10208: winebth.sys part 15: Add support for reading/caching GATT characteristic values
by Elizabeth Figura (＠zfigura) March 2, 2026

March 2, 2026

On Sun Mar 1 11:59:02 2026 +0000, Vibhav Pant wrote: > Characteristics are how most IO in BLE is done, so I wanted to minimize > the roundtrips between PE and Unix as much as possible (given that the > wineserver IPC already going to make this slow). Plus, from my > understanding, most GATT services tend to limit the size of the values > to the default MTU (23 or so bytes). This way, most value reads should > be happening inline anyway. This, and a lot of things honestly, seem like premature optimization. Even if the cost of a Unix call weren't already small in comparison with the server I/O, or indeed the actual hardware I/O, I think it'd still be a mistake to be adding extra code to optimize before we have any evidence it matters. Same sort of thing about splitting up all the locks, which I've already talked about. It seems unlikely we need more than one; we don't _know_ we need more than one, and the extra complexity just makes things harder and risks deadlocks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10208#note_130970

1 0

[PATCH 0/1] MR10226: change vkb hidraw handling to catchall
by Ty (＠chaos) March 2, 2026

March 2, 2026

now supports new modular hardware and user custom pid reason: in consulting with a large number of vkb device users it was found their pid is arbitrary for modular items (pid gets xor'd for each component plugged in), and devices can be software modified to have different numbers of axis/buttons, or user modified pid's. vkb have no known (to me) VID collisions so should be safe to just catch-all. Contingency for failure: if a hypothetical future device existed from vkb that didnt want hidraw (xinput gamepad), an explicit exemption for that device pid would be the solution. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10226

2 2

[PATCH v9 0/3] MR10225: Draft: libs/xml2: Tolerate embedded XML declarations inside elements.
by lucas (＠luben93) March 2, 2026

March 2, 2026

Windows MSXML tolerates nested <?xml?> processing instructions inside elements, but libxml2 rejects them with XML_ERR_RESERVED_XML_NAME. When an embedded <?xml is encountered inside an element, consume everything up to the parent's closing tag and emit it via the SAX characters callback as a text node, matching Windows MSXML behavior where the content after the embedded <?xml?> is treated as text. This is needed for applications like Adobe Creative Cloud installer that use embedded XML declarations in their data. -- v9: libs/xml2, msxml3/tests: Improve embedded XML declaration handling and tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10225

3 2

[PATCH v8 0/3] MR10225: Draft: libs/xml2: Tolerate embedded XML declarations inside elements.
by lucas (＠luben93) March 2, 2026

March 2, 2026

Windows MSXML tolerates nested <?xml?> processing instructions inside elements, but libxml2 rejects them with XML_ERR_RESERVED_XML_NAME. When an embedded <?xml is encountered inside an element, consume everything up to the parent's closing tag and emit it via the SAX characters callback as a text node, matching Windows MSXML behavior where the content after the embedded <?xml?> is treated as text. This is needed for applications like Adobe Creative Cloud installer that use embedded XML declarations in their data. -- v8: libs/xml2, msxml3/tests: Improve embedded XML declaration handling and tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10225

1 0

[PATCH v7 0/3] MR10225: Draft: libs/xml2: Tolerate embedded XML declarations inside elements.
by lucas (＠luben93) March 2, 2026

March 2, 2026

Windows MSXML tolerates nested <?xml?> processing instructions inside elements, but libxml2 rejects them with XML_ERR_RESERVED_XML_NAME. When an embedded <?xml is encountered inside an element, consume everything up to the parent's closing tag and emit it via the SAX characters callback as a text node, matching Windows MSXML behavior where the content after the embedded <?xml?> is treated as text. This is needed for applications like Adobe Creative Cloud installer that use embedded XML declarations in their data. -- v7: libs/xml2, msxml3/tests: Improve embedded XML declaration handling and tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10225

3 2

[PATCH v6 0/3] MR10225: Draft: libs/xml2: Tolerate embedded XML declarations inside elements.
by lucas (＠luben93) March 2, 2026

March 2, 2026

Windows MSXML tolerates nested <?xml?> processing instructions inside elements, but libxml2 rejects them with XML_ERR_RESERVED_XML_NAME. When an embedded <?xml is encountered inside an element, consume everything up to the parent's closing tag and emit it via the SAX characters callback as a text node, matching Windows MSXML behavior where the content after the embedded <?xml?> is treated as text. This is needed for applications like Adobe Creative Cloud installer that use embedded XML declarations in their data. -- v6: libs/xml2, msxml3/tests: Improve embedded XML declaration handling and tests. https://gitlab.winehq.org/wine/wine/-/merge_requests/10225

3 3

[PATCH v5 0/2] MR10225: Draft: libs/xml2: Tolerate embedded XML declarations inside elements.
by lucas (＠luben93) March 2, 2026

March 2, 2026

Windows MSXML tolerates nested <?xml?> processing instructions inside elements, but libxml2 rejects them with XML_ERR_RESERVED_XML_NAME. When an embedded <?xml is encountered inside an element, consume everything up to the parent's closing tag and emit it via the SAX characters callback as a text node, matching Windows MSXML behavior where the content after the embedded <?xml?> is treated as text. This is needed for applications like Adobe Creative Cloud installer that use embedded XML declarations in their data. -- v5: msxml3/tests: Add tests for embedded XML declarations inside elements. libs/xml2: Tolerate embedded XML declarations inside elements. https://gitlab.winehq.org/wine/wine/-/merge_requests/10225

3 3

[PATCH v3 0/6] MR10204: cfgmgr32: Get rid of setupapi dependency in DevObject* implementation (2/2).
by Rémi Bernon March 2, 2026

March 2, 2026

-- v3: cfgmgr32: Enumerate the registry keys directly in enum_dev_objects. cfgmgr32: Return LSTATUS from enum_dev_objects callback. cfgmgr32: Use the new helpers to read device interface properties. cfgmgr32: Use the new helpers to get device interface property keys. cfgmgr32: Return BOOL from devprop_filter_matches_properties. cfgmgr32: Initialize device_interface structs in DEV_OBJECT functions. https://gitlab.winehq.org/wine/wine/-/merge_requests/10204

1 7

[PATCH v21 0/1] MR10192: Draft: kernelbase: Handle extended length path prefix in GetLongPathNameW
by Vishnunithyasoundhar S (＠svishnunithyasoundhar) March 2, 2026

March 2, 2026

``` Support the \\?\ prefix by skipping it during path resolution while preserving it in the output. Added specific handling for extended UNC paths (\\?\UNC\) to mirror standard UNC behavior, ensuring these paths are treated as network shares and not local devices. Some paths that use the extended length path were filtered out as UNC paths - but not all of them are UNC. There can be UNC path that use extended length path but not all extended lenght paths are UNC paths. ``` Signed-off-by: Vishnunithyasoundhar S svishnunithyasoundhar(a)gmail.com -- v21: fix: extended-file-name support https://gitlab.winehq.org/wine/wine/-/merge_requests/10192

2 1