October 2024 - wine-gitlab

[PATCH 0/8] MR6568: d3dx9: Pixel format handling changes, part 2.
by Connor McAdams (＠cmcadams) 07 Oct '24

07 Oct '24

These patches are the last big changes to the pixel_format_desc structure. Patch 2 of this feels like it might be a bit big, but I couldn't really come up with a clean way to split it. :) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6568

4 17

[PATCH 0/1] MR6624: msiexec: Remove quotes from all filenames.
by Hans Leidekker (＠hans) 07 Oct '24

07 Oct '24

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

2 1

[PATCH 0/5] MR6619: dplayx: Open() part 7.
by Anton Baskanov (＠baskanov) 06 Oct '24

06 Oct '24

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

4 7

[PATCH v5 0/11] MR6621: winebth.sys: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 06 Oct '24

06 Oct '24

This MR is the first of at least three MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v5: winebth.sys: Implement IOCTL_WINEBTH_SEND_AUTH_RESPONSE. winebth.sys: Add support for receiving authentication requests/events. winebth.sys: Add support for BLUETOOTH_RADIO_IN_RANGE events (WM_DEVICECHANGE). winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_SET_FLAG and IOCTL_WINEBTH_RADIO_UNSET_FLAG. winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_START_DISCOVERY and IOCTL_WINEBTH_RADIO_STOP_DISCOVERY. winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO for radio devices. winebth.sys: Update radio PDO properties when BlueZ sends us a PropertiesChanged for an adapter. winebth.sys: Create PDOs for Bluetooth services discovered on remote devices. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 11

[PATCH v4 0/11] MR6621: winebth.sys: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 06 Oct '24

06 Oct '24

This MR is the first of at least three MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v4: winebth.sys: Implement IOCTL_WINEBTH_SEND_AUTH_RESPONSE. winebth.sys: Add support for receiving authentication requests/events. winebth.sys: Add support for BLUETOOTH_RADIO_IN_RANGE events (WM_DEVICECHANGE). winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_SET_FLAG and IOCTL_WINEBTH_RADIO_UNSET_FLAG. winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_START_DISCOVERY and IOCTL_WINEBTH_RADIO_STOP_DISCOVERY. winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO for radio devices. winebth.sys: Update radio PDO properties when BlueZ sends us a PropertiesChanged for an adapter. winebth.sys: Create PDOs for Bluetooth services discovered on remote devices. winebth.sys: Create PDOs for newly discovered remote Bluetooth devices. winebth.sys: Create PDOs for newly discovered Bluetooth radios. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

2 11

[PATCH v2 0/4] MR6623: Draft: include/winnt.h: Add support for thread safety annotation attributes.
by Vibhav Pant (＠vibhavp) 06 Oct '24

06 Oct '24

This MR introduces support for [thread safety annotations,](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#conditi… currently supported by Clang. The feature is similar to `__WINE_MALLOC` attributes, allowing functions, data members and global variables to be optionally annotated with synchronization details. As a proof of concept, I have successfully annotated `dlls/ntdll` code, and it should build without any warnings. Because the feature was designed as a C++ extension first, a bit of stubbing is required to annotate struct fields about what lock they are guarded by. The macros `WINE_DECLARE_LOCK_FIELD_STUB` and `WINE_DEFINE_LOCK_FIELD_STUB` take care of that. For instance, in `dlls/ntdll/threadpool.c`: ```c WINE_DECLARE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs); struct threadpool_group { LONG refcount; BOOL shutdown; CRITICAL_SECTION cs; /* list of group members, locked via .cs */ struct list members __WINE_FIELD_GUARDED_BY(threadpool_group, cs); }; WINE_DEFINE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs); ``` Clang will therefore warn if `members` is accessed without holding `cs`. Note that the analyzer does not support conditional locking. For that reason, functions that hold and release a lock conditionally have been marked with `__WINE_NO_THREAD_SAFETY_ANALYSIS` to pre-empt false positives from Clang. -- v2: ntdll: Add thread safety annotations. configure: Enable -Wthread-safety-analysis, -Wthread-safety-attributes warnings. include/winternl.h: Add thread safety annotations to several NT synchronization primitives. include/winnt.h: Add macros for thread safety annotations. https://gitlab.winehq.org/wine/wine/-/merge_requests/6623

3 6

[PATCH 0/4] MR6623: include/winnt.h: Add support for thread safety annotation attributes.
by Vibhav Pant (＠vibhavp) 06 Oct '24

06 Oct '24

This MR introduces support for [thread safety annotations,](https://clang.llvm.org/docs/ThreadSafetyAnalysis.html#conditi… currently supported by Clang. The feature is similar to `__WINE_MALLOC` attributes, allowing functions, data members and global variables to be optionally annotated with synchronization details. As a proof of concept, I have successfully annotated `dlls/ntdll` code, and it should build without any warnings. Because the feature was designed as a C++ extension first, a bit of stubbing is required to annotate struct fields about what lock they are guarded by. The macros `WINE_DECLARE_LOCK_FIELD_STUB` and `WINE_DEFINE_LOCK_FIELD_STUB` take care of that. For instance, in `dlls/ntdll/threadpool.c`: ```c WINE_DECLARE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs); struct threadpool_group { LONG refcount; BOOL shutdown; CRITICAL_SECTION cs; /* list of group members, locked via .cs */ struct list members __WINE_FIELD_GUARDED_BY(threadpool_group, cs); }; WINE_DEFINE_LOCK_FIELD_STUB(threadpool_group, CRITICAL_SECTION, cs); ``` Clang will therefore warn if `members` is accessed without holding `cs`. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6623

3 5

[PATCH v3 0/11] MR6621: winebth.sys: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 06 Oct '24

06 Oct '24

This MR is the first of at least three MRs adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two "sub" drivers: `winebth.sys`: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. `bthenum`: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. The unix code is split between dbus.c, unixlib.c and winebluetooth.c, where winebluetooth is a simple wrapper around unixlib for the sake of organization. -- v3: winebth.sys: Implement IOCTL_WINEBTH_SEND_AUTH_RESPONSE. winebth.sys: Add support for receiving authentication requests/events. winebth.sys: Add support for BLUETOOTH_RADIO_IN_RANGE events (WM_DEVICECHANGE). winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_SET_FLAG and IOCTL_WINEBTH_RADIO_UNSET_FLAG. winebth.sys: Implement IOCTL commands IOCTL_WINEBTH_RADIO_START_DISCOVERY and IOCTL_WINEBTH_RADIO_STOP_DISCOVERY. winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO for radio devices. winebth.sys: Update radio PDO properties when BlueZ sends us a PropertiesChanged for an adapter. winebth.sys: Create PDOs for Bluetooth services discovered on remote devices. winebth.sys: Create PDOs for newly discovered remote Bluetooth devices. winebth.sys: Create PDOs for newly discovered Bluetooth radios. https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 12

Re: [PATCH v2 0/11] MR6621: winebth.sys: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 05 Oct '24

05 Oct '24

This MR does not include SDP related IOCTLs needed to get winsock support working, as they require some changes to wineserver. I plan to introduce them in separate MRs. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6621#note_84120

1 0

[PATCH 0/11] MR6621: winebth.sys: Introduce Bluetooth driver.
by Vibhav Pant (＠vibhavp) 05 Oct '24

05 Oct '24

This MR should be the first of at least three MRs, adding support for the Bluetooth stack API in Wine: 1. The winebth.sys driver, which talks to BlueZ and implements several key IOCTLs for communicating with Bluetooth devices and radios. 2. A bthserv service, which is responsible for keeping track of the authentication agent, and relaying authentication requests and responses to and from the driver. 3. Userspace APIs (bluetoothapis.dll, bthprops.cpl, Windows.Devices.Bluetooth, etc). winebth.sys is split into two drivers: winebth.sys: The main entrypoint, loaded by winedevice. It listens for changes to Bluetooth devices and radios and authentication events on BlueZ, passing them on the bthenum. It also handles most IOCTL operations on Bluetooth radio PDOs. bthenum: Responsible for creating nodes for discovered Bluetooth devices and associated services. It also tries to validate any IOCTLs relating to bluetooth devices before passing them to winebth.sys. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6621

3 12

2025

2024

2023

2022

wine-gitlab October 2024