August 2024 - wine-gitlab

[PATCH v3 0/1] MR6316: netutils: Forward some exports to netapi32.
by Etaash Mathamsetty (＠etaash.mathamsetty) 21 Aug '24

21 Aug '24

Fixes Lineage 2 -- v3: netapi32: Move some implementations to netutils. https://gitlab.winehq.org/wine/wine/-/merge_requests/6316

4 3

Re: [PATCH v4 0/1] MR2378: kernelbase: Trick V8's CHECK(old_protection == PAGE_READWRITE).
by Aida Jonikienė (＠DodoGTA) 21 Aug '24

21 Aug '24

> I think it's being worked on by someone else anyway Is there a public branch for that work (or is that work too WIP to publish it)? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_79485

1 0

[PATCH v6 0/4] MR6304: comctl32/edit: Fix incorrect size for format rect.
by Jacob Czekalla (＠JacobCzekalla) 21 Aug '24

21 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56873 -- v6: comctl32/edit: Fix incorrect size for format rect when it is smaller than text. https://gitlab.winehq.org/wine/wine/-/merge_requests/6304

3 5

Re: [PATCH v4 0/1] MR2378: kernelbase: Trick V8's CHECK(old_protection == PAGE_READWRITE).
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

> Reworking the ntdll-WRITECOPY wine-staging patchset would be a good start That's not really helpful advice by itself. The wine-staging patch set is fundamentally not workable as an approach. There is at this point a more or less specific idea of what needs to be done to properly implement WRITECOPY support, basically involving IOCTL_PAGEMAP_SCAN, and I think it's being worked on by someone else anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2378#note_79484

1 0

[PATCH v2 0/2] MR6317: comctl32: handle large tooltip icons
by Cherser-s (＠Cherser-s) 21 Aug '24

21 Aug '24

Added 32x32 icons for TTI_INFO_LARGE, TTI_WARNING_LARGE and TTI_ERROR_LARGE. User-defined icons passed through TTM_SETTITLE message are still drawn as 16x16 icons. -- v2: explorer.exe: fix handling ballon icon flags comctl32: handle large tooltip icons https://gitlab.winehq.org/wine/wine/-/merge_requests/6317

4 7

[PATCH v22 0/2] MR5909: comctl32/tests: Add LVM_GETNEXTITEM test.
by Ilia Docin (＠IDocin) 21 Aug '24

21 Aug '24

-- v22: comctl32/listview: Do not return items count on getting next item for last one. comctl32/tests: Add LVM_GETNEXTITEM test. https://gitlab.winehq.org/wine/wine/-/merge_requests/5909

3 5

[PATCH v19 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 21 Aug '24

21 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v19: plugplay: Broadcast PnP events on a dedicated thread. plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

2 4

[PATCH v16 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 21 Aug '24

21 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v16: plugplay: Broadcast PnP events on a dedicated thread. plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. include/wine/plugplay: Separate device broadcast event types into their own structs. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 5

[PATCH v15 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Vibhav Pant (＠vibhavp) 21 Aug '24

21 Aug '24

PnP device notifications/events are currently sent and received from the `plugplay` service as the raw-bytes for the `DBT_DEVTYP_DEVICEINTERFACE` struct that needs to be sent from the PnP code in `ntoskrnl.exe`. While simple, it does not support sending `DBT_DEVTYP_HANDLE` events, as they also include a `HANDLE` to the device the event comes from, which cannot simply be sent as raw bytes. This MR reworks how notifications are sent and received from the `plugplay` service, by: 1. Introducing new structs `DEVICE_BROADCAST_HANDLE` and `DEVICE_BROADCAST_DEVICEINTERFACE` in `plugplay.idl`. The structs are similar to their counterparts in `dbt.h` without the `devicetype` and `size` fields added for the header. 2. Re-write `plugplay_{send,get}_event` to use the newly added union `DEVICE_BROADCAST`, which uses the `devicetype` value as the discriminant. A deep copy of this union is then appended to the event queue of every registered listener. 3. Re-write `I_ScRegisterDeviceNotification` and `device_notify_proc` in `sechost/service.c` to use the newly added types instead. Additionally, add support for registering for `DBT_DEVTYPE_HANDLE` notifications, for which the `OBJECT_NAME_INFORMATION` value for the device `HANDLE` is used to filter notifications in order to correctly dispatch them to their registered callbacks. 4. Re-write the callbacks in `user32/input.c` to accept the `DEVICE_BROADCAST` union instead, and construct the appropriate `DEV_BROADCAST_*` struct from it, which gets sent to `SendMessageTimeoutW` as usual. Support for `DBT_DEVTYP_HANDLE` is needed for the Bluetooth driver stack I have been working on recently, which uses `DBT_DEVTYP_HANDLE` events to notify userspace about newly found Bluetooth devices during discovery and incoming authentication requests, as documented by MS [here](https://learn.microsoft.com/en-us/windows/win32/bluetooth/bluetooth-a…. -- v15: plugplay: Broadcast PnP events on a dedicated thread. plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. include/wine: Add header dbt.h. include/wine/plugplay: Separate device broadcast event types into their own structs. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

3 8

[PATCH v5 0/4] MR6304: comctl32/edit: Fix incorrect size for format rect.
by Jacob Czekalla (＠JacobCzekalla) 21 Aug '24

21 Aug '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56873 -- v5: comctl32/edit: Fix incorrect size for format rect when it is smaller than text. comctl32/tests: Add test for edit control format rect size. https://gitlab.winehq.org/wine/wine/-/merge_requests/6304

3 5

2025

2024

2023

2022

wine-gitlab August 2024