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

[PATCH v8 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) March 27, 2025

March 27, 2025

Follow-up of !2786, which appears to have been abandoned. -- v8: ws2_32/tests: Add test for AF_UNIX sockets. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

3 8

[PATCH v7 0/6] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) March 27, 2025

March 27, 2025

Follow-up of !2786, which appears to have been abandoned. -- v7: ws2_32/tests: Add test for AF_UNIX sockets. server: Fix getsockname() and accept() on AF_UNIX sockets. server: Introduce error when attempting to create a SOCK_DGRAM AF_UNIX socket. server: Allow for deletion of socket files. https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

2 6

[PATCH v6 0/7] MR7650: Add support for AF_UNIX sockets (followup)
by Ralf Habacker (＠rhabacker) March 27, 2025

March 27, 2025

Follow-up of !2786, which appears to have been abandoned. -- v6: Fixup deletion of socket files https://gitlab.winehq.org/wine/wine/-/merge_requests/7650

4 8

[PATCH 0/4] MR7680: PDB rewrite #5.
by eric pouech (＠epo) March 27, 2025

March 27, 2025

This serie (#5 in PDB rewrite) actually starts the implementation of the i "new" PDB reader. Basically, during the phase of migration from the "old" to the "new" PDB reader, both readers will be used at the same time (for every loaded module with PDB information). So: - be ready to expect an increase in memory usage (as both will handle their own information), - in the process of migration, when possible, parts of the "old" reader will be disabled not to consume too much memory nor time, Default will be to use the "new" reader. If you really want to use the "old" reader, set the WINE\_DBGHELP\_OLD\_PDB env variable. The integration of the "new" PDB reader is done through a set of methods attached to each debug format (1). This serie: - sets the foundations of the "new" PDB reader (in a new pdb.c file), - use it to support the access to PFO unwinding information in PDB files (and this allows to unmap the PDB file, used by the all reader, when all information have been read by "old" reader), - introduces the methods vtable for each debug format. Note 1: - "new" PDB reader will not support as many PDB variations as the "old" reader, - actually, PDB files come into two forms. The second form became the CL.EXE default in MSVC version 8, something like 30 years ago, (first format was very limited in the potential size of the PDB file), - also, the CodeView records in the PDB files exist in 3 versions: + V1: 2^16 types per image, identifiers as pascal string, 255 char max, + V2: 2^32 types per image, identifiers as pascal string, 255 char max, + V3: 2^32 types per image, identifiers as C-strings ("unlimited"), - for now, only support for the V3 CodeView records is included - I don't plan to add all the other variations as they are very obsolete, - for the record, this is aligned with clang design decisions for their PDB implementation, Note 2: - "old" reader maps the whole PDB file in memory, then allocate memory chunks for each internal stream and reconstructs the stream by copying from the filemap into the stream buffer), - "new" reader access the PDB file through ReadFile, [1] dwarf4/5 is a candidate to be moved to this new interface for the same reasons as PDB (not to load every debug information at module loading in dbghelp), -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7680

2 4

[PATCH v15 0/3] MR7542: ws2_32: Implement WSALookupService for Bluetooth device discovery.
by Vibhav Pant (＠vibhavp) March 27, 2025

March 27, 2025

This MR adds an initial implementation of the winsock `WSALookupsService*` methods for performing Bluetooth device discovery (`LUP_CONTAINERS`). Pending !7472, the code will also eventually support performing device inquiry scans. -- v15: ws2_32: Implement WSALookupServiceNext for Bluetooth device discovery. ws2_32: Implement WSALookupServiceBegin for Bluetooth device discovery. ws2_32/tests: Add tests for the Bluetooth namespace (NS_BTH) in WSALookupServiceBegin/Next. https://gitlab.winehq.org/wine/wine/-/merge_requests/7542

2 3

[PATCH v2 0/2] MR7678: winewayland: Use system cursor shapes when possible.
by Alexandros Frantzis (＠afrantzis) March 27, 2025

March 27, 2025

This MR uses the cursor-shapes-v1 protocol to tell the compositor which system cursor shape to use. If a shape match is not found (or cursor-shapes-v1 is not available) we fall back to setting the cursor buffer from the Windows cursor data as before. The second commit implements support for a "UseSystemCursors" driver option, similar to what winex11 has. Since this is the first winewayland driver option we also introduce all the related registry reading code. -- Side note: The registry code is a copy from winex11, and is the third copy in the codebase (x11, mac, wayland). Perhaps it's worth introducing a common ntuser function to perform the option reading for the drivers, something like `NtUserGetDriverOption("X11 Driver", buffer, buffer_size, TRUE /* whether to read app specific option if present */)`. With such a function there is the concern about each call reopening the registry, but we can see if that's actually a problem and how a different API (or some sort of caching) may help. -- v2: winewayland: Support "UseSystemCursors" driver option. winewayland: Use system cursor shapes when possible. https://gitlab.winehq.org/wine/wine/-/merge_requests/7678

2 3

[PATCH v2 0/1] MR7674: makedep: Fix a compilation warning.
by Sven Baars (＠sbaars) March 27, 2025

March 27, 2025

-- v2: makedep: Fix a compilation warning. https://gitlab.winehq.org/wine/wine/-/merge_requests/7674

2 1

[PATCH 0/1] MR7674: makedep: Fix a compilation warning.
by Sven Baars (＠sbaars) March 27, 2025

March 27, 2025

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

3 2

[PATCH v9 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) March 27, 2025

March 27, 2025

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)) which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- v9: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. bluetoothapis: Implement BluetoothRegisterForAuthenticationEx and BluetoothUnregisterForAuthentication. winebth.sys: Implement IOCTL_WINEBTH_AUTH_REGISTER. winebth.sys: Broadcast a WINEBTH_AUTHENTICATION_REQUEST PnP event on receiving a RequestConfirmation request from BlueZ. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5

[PATCH v8 0/5] MR7630: winebth.sys part 7: Introduce support for authentication/pairing.
by Vibhav Pant (＠vibhavp) March 27, 2025

March 27, 2025

Introduce infrastructure necessary to support receiving, sending and replying (to) Bluetooth authentication/pairing requests: - During startup, the Bluetooth driver now creates a "pairing agent" and registers it with BlueZ. The pairing agent is a DBus object implementing the `org.bluez.Agent1` interface (documented [here](https://github.com/bluez/bluez/blob/master/doc/org.bluez.Agent.rst)) which receives authentication requests from BlueZ. The pairing agent then forwards the request data to the PE driver, in form of a `WINEBLUETOOTH_EVENT_AUTH_EVENT` event. The agent is unregistered during driver shutdown. - Right now, the agent only supports Numeric Comparison pairing requests. - Create a new auxiliary device, `\??\WINEBTHAUTH` during driver startup. This device handles authentication functionality that is independent of radio PDOs on the system, which allows the userspace APIs to not track individual Bluetooth radio objects to implement authentication. `WINEBTHAUTH` right now serves two purposes: - Serve as the device object for which `GUID_WINEBTH_AUTHENTICATION_REQUEST` PnP events are broadcasted. This event is sent whenever the Bluetooth event loop in (`bluetooth_event_loop_thread_proc`) receives `WINEBLUETOOTH_EVENT_AUTH_EVENT`. The event's buffer contains a `struct winebth_authentication_request` value, which contains data relevant to the incoming auth request. - Handle the `IOCTL_WINEBTH_AUTH_REGISTER` IOCTL. This simply calls the [`RequestDefaultAgent` BlueZ method](https://github.com/bluez/bluez/blob/master/doc/org.bluez.AgentManag… right now, which asks BlueZ to send all incoming Bluetooth authentication requests to Wine's pairing agent (described above). This is not always strictly necessary, but is useful if there already is a default pairing agent set. - `WINEBTHAUTH` will also ultimately be in charge of responding to authentication requests, which I'll be adding in the next-ish MR(s). - Implement `BluetoothRegisterForAuthenticationEx` and `BluetoothUnregisterAuthentication`. Registration is done by invoking `IOCTL_WINEBTH_AUTH_REGISTER`, and then listening for `GUID_WINEBTH_AUTHENTICATION_REQUEST` events on a `HANDLE` to `\??\WINEBTHAUTH` using the newly added `CM_Register_Notifications`. To keep the MR from getting any larger, I have not included support for `BluetoothSendAuthenticationResponseEx`. That will likely be introduced in the future. -- v8: bluetoothapis/tests: Add tests for BluetoothRegisterForAuthenticationEx and BluetoothUnregisterAuthentication. https://gitlab.winehq.org/wine/wine/-/merge_requests/7630

2 5