- wine-gitlab - winehq.org

[PATCH v6 0/5] MR8174: winebth.sys part 12: Introduce support for Low Energy GATT services
by Vibhav Pant (＠vibhavp) 12 Jun '25

12 Jun '25

Generic ATTribute Profile (GATT) is a protocol used by BLE devices for data exchange. Broadly, every LE device contains one or more GATT services, with each service having multiple characteristics, which contain the actual piece of data to be exchanged. The Win32 BLE api is defined in [`bluetoothleapis.h`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/), and operates on `HANDLE`s to PDOs created by the driver to remote devices and services, using the `GUID_BLUETOOTHLE_DEVICE_INTERFACE` and `GUID_BLUETOOTH_GATT_SERVICE_DEVICE_INTERFACE` class interfaces respectively. This MR introduces initial support for accessing GATT services on LE devices: * Create PDOs for remote devices that we discover GATT services on, and enabling `GUID_BLUETOOTHLE_DEVICE_INTERFACE` for them. * Because the driver also creates PDOs for bluetooth radios, a tagged union is used to distinguish between device extension values to dispatch IOCTL and PnP IRPs appropriately. * Enumerate through all `org.bluez.GattService1` objects on BlueZ, and store them on the PE driver inside the associated devices. * Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES for device PDOs. * Use the newly added IOCTL to implement [`BluetoothGATTGetServices`](https://learn.microsoft.com/en-us/windows/win32/api/bluetoothleapis/nf-bluetoothleapis-bluetoothgattgetservices). -- v6: bluetoothapis/tests: Add tests for BluetoothGATTGetServices. bluetoothapis: Implement BluetoothGATTGetServices. winebth.sys: Implement IOCTL_WINEBTH_LE_DEVICE_GET_GATT_SERVICES. winebth.sys: Store a list of GATT services discovered on LE devices. winebth.sys: Create PDOs for remote Bluetooth devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/8174

2 9

[PATCH 0/1] MR8296: msi/tests: Fix wrong character count for RegSetValueExA.
by Yuxuan Shui (＠yshui) 12 Jun '25

12 Jun '25

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

2 1

[PATCH 0/1] MR8275: wined3d/vk: Use the XY11 fixup for SNORM formats only for legacy d3d.
by Elizabeth Figura (＠zfigura) 12 Jun '25

12 Jun '25

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

4 5

[PATCH v3 0/1] MR8274: wined3d/spirv: Limit parameters to the relevant shader versions.
by Elizabeth Figura (＠zfigura) 12 Jun '25

12 Jun '25

-- v3: wined3d/spirv: Limit parameters to the relevant shader versions. https://gitlab.winehq.org/wine/wine/-/merge_requests/8274

3 2

[PATCH 0/1] MR8256: include: vsnprintf should always write a null terminator.
by Yuxuan Shui (＠yshui) 12 Jun '25

12 Jun '25

Microsoft's documentation says: > The `vsnprintf` function always writes a null terminator, even if it truncates the output. When you use `_vsnprintf` and `_vsnwprintf`, the buffer is null-terminated only if there's room at the end (that is, if the number of characters to write is less than count). For `_UCRT` and `_MSVCR_VER >= 140`, `vsnprintf` calls `__stdio_common_vsprintf` with `_CRT_INTERNAL_PRINTF_STANDARD_SNPRINTF_BEHAVIOR`, and everything works, a null byte is appended, everything is fine. If not, `vsnprintf` calls `_vsnprintf` directly and no null byte will be added if the buffer is not big enough. This happens in, for example, kernel32. And this breaks `wine_dbg_vsprintf`, which passes result of `vsnprintf` to `strlen` and goes out-of-bound. In msvcrt.spec, we also have `vsnprintf` as an alias of `_vsnprintf`, I didn't touch that since I don't know if that's deliberate. But this alias _is_ used (by e.g. winecrt0, i think?), if this one is also wrong then it might break other things. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8256

4 3

[PATCH 0/1] MR8284: d3dx9/tests: Add a few tests for technique/pass access with the effect compiler API.
by Nikolay Sivov (＠nsivov) 12 Jun '25

12 Jun '25

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8284

3 2

[PATCH v2 0/2] MR8245: d3dcompiler_43: Implement D3DCreateLinker().
by Zhiyi Zhang (＠zhiyi) 12 Jun '25

12 Jun '25

For React Native. React Native applications use HLSL shader linking extensively. Obviously, these two functions are not enough because they are just stubs. But I think it's good to get them in the tree so they don't get lost. Currently, React Native applications need to rely on the bundled native d3dcompiler. -- v2: d3dcompiler_47: Implement D3DCreateFunctionLinkingGraph(). d3dcompiler_47: Implement D3DCreateLinker(). https://gitlab.winehq.org/wine/wine/-/merge_requests/8245

3 4

[PATCH 0/2] MR8226: d3dx9: Replace libtxc_dxtn.
by Connor McAdams (＠cmcadams) 12 Jun '25

12 Jun '25

These patches replace the existing libtxc_dxtn texture compression/decompression source files with new libraries that can handle more formats. This is will be helpful when we begin to share code with d3dx10/d3dx11, as we will be able to use bcdec to decode all supported compressed formats, and stb_dxt to compress BC1-BC5. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8226

3 8

[PATCH v4 0/1] MR8228: mshtml: Fix misuse of IWinInetHttpInfo_QueryInfo.
by Yuxuan Shui (＠yshui) 12 Jun '25

12 Jun '25

IWinInetHttpInfo_QueryInfo returns a multibyte string, not a wide string. We were also wrongly expecting it to have a NUL terminator. * * * this one doesn't feel good. IWinInetHttpInfo_QueryInfo calls HttpInfo_QueryInfo (urlmon), which calls HttpQueryInfoA (wininet), so it returns char*. but inside, HttpQueryInfoA is calling HttpQueryInfoW and does charset conversion. so we are converting the string to multibyte and back. maybe there's an API that returns wchar* i don't know about. -- v4: mshtml: Fix misuse of IWinInetHttpInfo_QueryInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/8228

2 1

[PATCH v3 0/1] MR8228: mshtml: Fix misuse of IWinInetHttpInfo_QueryInfo.
by Yuxuan Shui (＠yshui) 12 Jun '25

12 Jun '25

IWinInetHttpInfo_QueryInfo returns a multibyte string, not a wide string. We were also wrongly expecting it to have a NUL terminator. * * * this one doesn't feel good. IWinInetHttpInfo_QueryInfo calls HttpInfo_QueryInfo (urlmon), which calls HttpQueryInfoA (wininet), so it returns char*. but inside, HttpQueryInfoA is calling HttpQueryInfoW and does charset conversion. so we are converting the string to multibyte and back. maybe there's an API that returns wchar* i don't know about. -- v3: mshtml: Fix misuse of IWinInetHttpInfo_QueryInfo. https://gitlab.winehq.org/wine/wine/-/merge_requests/8228

2 2

Re: [PATCH v3 0/1] MR8242: libs/musl: Force built-in rint for i386.
by Piotr Caban (＠piotr) 12 Jun '25

12 Jun '25

I think it's not possible to implement it correctly using floating point operations when 24bit precision is used. We would either need to implement it without floating point operations (I'll look into that) or set the precision. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8242#note_106331

1 0

[PATCH v3 0/2] MR8216: server: prevent division by zero in coordinate mapping
by Wei Xie (＠wayne) 12 Jun '25

12 Jun '25

Wine applications crash in VNC/headless environments due to invalid all-zero monitor coordinates. The root cause is: - Environment Issue: VNC systems report all displays as RR_Disconnected - Faulty Fallback: Wine incorrectly reverts to legacy XRandR 1.0 API when no "connected" displays are detected - API Incompatibility: Modern XRandR 1.6 doesn't support Wine's XRandR 1.0 implementation, causing XRRSizes() to return empty display modes - Uninitialized Data: This leaves critical display fields (dmPelsWidth/Height) at initialization value 0 -- v3: winex11: handle fallback display modes when XRandR fails https://gitlab.winehq.org/wine/wine/-/merge_requests/8216

3 11

Re: [PATCH v15 0/3] MR8200: cmd: COPY should output file names as they are copied.
by eric pouech (＠epo) 12 Jun '25

12 Jun '25

eric pouech (@epo) commented about programs/cmd/wcmdmain.c: > * Otherwise, parse the buffer to find the last parameter in the buffer, > * where tab was pressed. > */ > - if (len && inputBuffer[len-1] == L' ') { you should support the same parameters as below likely you'd better have the {cc=len; } body when parameter_with_delims() fails -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106328

1 0

Re: [PATCH v15 0/3] MR8200: cmd: COPY should output file names as they are copied.
by eric pouech (＠epo) 12 Jun '25

12 Jun '25

eric pouech (@epo) commented about programs/cmd/wcmdmain.c: > /* Handle paths here. Find last '\\'. > * If '\\' isn't found then insert pos is the same as search pos. > */ > - while (cc > sc->search_pos && inputBuffer[cc] != L'\\') { ditto is there a reason to not handle the other delimiters here? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106327

1 0

Re: [PATCH v15 0/3] MR8200: cmd: COPY should output file names as they are copied.
by eric pouech (＠epo) 12 Jun '25

12 Jun '25

eric pouech (@epo) commented about programs/cmd/builtins.c: > } > } > > + if (numcopied) { > + WCHAR* string; > + string = WCMD_format_string(WCMD_LoadMessage(WCMD_NUMCOPIED), numcopied); nitpick: `WCMD_output(WCMD_LoadMessage... `would be simpler -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8200#note_106326

1 0

[PATCH v4 0/1] MR8288: msvcrt: Don't release io memory in msvcrt_free_io.
by Yuxuan Shui (＠yshui) 12 Jun '25

12 Jun '25

In kernel32/tests/loader.c, child_process will try to write to stdout after calling LdrShutdownProcess. LdrShutdownProcess calls DLL_PROCESS_DETACH on msvcrt, which calls msvcrt_free_io, which frees the ioinfo blocks. So to prevent use after free in this case, we don't free them. * * * Supersedes !8273 -- v4: msvcrt: Don't release io memory in msvcrt_free_io during shutdown. https://gitlab.winehq.org/wine/wine/-/merge_requests/8288

4 4

[PATCH 0/2] MR8293: kernelbase: SetFileInformationByHandle pass FileRenameInfoEx to NtSetInformationFile
by Michael Stopa (＠stomy) 12 Jun '25

12 Jun '25

FileRenameInfoEx is already handled by NtSetInformationFile, SetFileInformationByHandle need only pass it through correctly. As of version 5.3, Apple's Metal Developer Tools are dependent on SetFileInformationByHandle to handle FileRenameInfoEx in this fashion. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8293

3 5

[PATCH v2 0/5] MR8291: winex11: Drop pixmap-based child window workaround.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

Updating the GL drawables on/offscreen dynamically, similarly to how we do it for Vulkan, and in order to ultimately converge and factor both GL and VK client surfaces. -- v2: winex11: Rename context drawables to draw / read. winex11: Drop pixmap-based child window workaround. winex11: Update drawable size and offscreen when presenting. winex11: Update every window GL drawable on resize / reparent. winex11: Update GL drawable offscreen status instead of recreating. https://gitlab.winehq.org/wine/wine/-/merge_requests/8291

2 6

[PATCH v3 0/6] MR8254: msi: Fix installing 64 bit library from 32 bit installer if 32 bit version of it is loaded into installer.
by Paul Gofman (＠gofman) 12 Jun '25

12 Jun '25

-- v3: msi: Fix getting version info for library loaded into wow64 process. https://gitlab.winehq.org/wine/wine/-/merge_requests/8254

3 8

[PATCH 0/5] MR8291: winex11: Drop pixmap-based child window workaround.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

Updating the GL drawables on/offscreen dynamically, similarly to how we do it for Vulkan, and in order to ultimately converge and factor both GL and VK client surfaces. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8291

2 5

[PATCH 0/1] MR8290: secur32/tests: Fix test failure on Windows 11.
by Hans Leidekker (＠hans) 12 Jun '25

12 Jun '25

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

2 1

[PATCH v5 0/4] MR8210: win32u: Use a pbuffer instead of OSmesa for memory DCs GL.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

OSmesa is deprecated and has been removed from latest mesa releases, this replaces it with pbuffer rendering and flushing of the surface onto the bitmap at some specific sync points. The tests show that this is roughly how Windows seem to behave anyway, instead of rendering directly to the memory as OSmesa does. -- v5: win32u: Remove now unnecessary context and pbuffer funcs. win32u: Drop now unnecessary OSMesa dependency. win32u: Use a pbuffer to implement GL on memory DCs. opengl32: Flush the contexts on gl(Draw|Read)Pixels and glViewport. https://gitlab.winehq.org/wine/wine/-/merge_requests/8210

2 5

[PATCH 0/1] MR8289: win32u: Fix copy of vulkan surfaces list on window destruction.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

Fixes: 5e4d40dddc3492bd48c6f0b042c581022d4ca9fc This actually manifested with a timeout in the quartz:filtergraph 32bit tests which I overlooked. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8289

2 1

Re: [PATCH v2 0/5] MR8281: amstream: More fallout from dynamic format change.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

Fwiw this breaks the tests on Windows: https://test.winehq.org/data/patterns.html#amstream:amstream -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8281#note_106304

1 0

[PATCH 0/3] MR8248: widl: Always write WinRT enum type definitions.
by Rémi Bernon (＠rbernon) 12 Jun '25

12 Jun '25

MSVC supports enum type forward declarations and doesn't complain if the enum is only defined in a later included file, but GCC requires enums to be defined before being used in parameters or fields. This emits every WinRT enum definition, unlike MIDL, before any typedef, so that the generated headers then work with GCC. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8248

3 5

2025

2024

2023

2022

wine-gitlab