August 2024 - wine-gitlab

[PATCH v10 0/1] MR6131: Extend bcp47langs.dll with GetUserLanguages
by Marius Schiffer (＠MariusSchiffer) 04 Sep '24

04 Sep '24

This is an undocumented API used by some programs to fetch the user's selected languages. Example is Fusion360 (during its login process). Signature currently taken from here: https://stackoverflow.com/questions/63877075/what-is-the-right-way-to-get-t… (Maybe that stackoverflow answer is also why Fusion has implemented this...) -- v10: bcp47langs: Implement GetUserLanguages https://gitlab.winehq.org/wine/wine/-/merge_requests/6131

4 14

[PATCH 0/2] MR6401: uxtheme: Optimize drawing by avoiding unneeded TransparentBlt().
by Paul Gofman (＠gofman) 03 Sep '24

03 Sep '24

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

4 13

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

02 Sep '24

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

4 6

[PATCH 0/3] MR5756: comdlg32: Fix a few issues with color dialog
by Fabian Maurer (＠DarkShadow44) 02 Sep '24

02 Sep '24

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

3 14

[PATCH 0/2] MR6421: d3d10/effect: Rename some variable array fields to better reflect their meaning.
by Nikolay Sivov (＠nsivov) 02 Sep '24

02 Sep '24

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

3 3

[PATCH v2 0/1] MR6409: vkd3d: Import upstream release 1.13.
by Alexandre Julliard (＠julliard) 02 Sep '24

02 Sep '24

-- v2: vkd3d: Import upstream release 1.13. https://gitlab.winehq.org/wine/wine/-/merge_requests/6409

3 2

[PATCH 0/6] MR6396: win32u: Stop setting DPI_PER_MONITOR_AWARE by default.
by Rémi Bernon (＠rbernon) 02 Sep '24

02 Sep '24

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

4 10

[PATCH v12 0/2] MR5761: comclt32: Allow ctrl-tab and tab hotkeys for propsheets
by Fabian Maurer (＠DarkShadow44) 02 Sep '24

02 Sep '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56103 -- v12: comclt32: Allow hotkeys for propsheet navigation. comctl32/tests: Add test for propsheet hotkey navigation. https://gitlab.winehq.org/wine/wine/-/merge_requests/5761

3 4

Re: [PATCH v32 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Rémi Bernon (＠rbernon) 31 Aug '24

31 Aug '24

> If you're referring to the new RPC structs, I understand. That being said, my one concern is whether stuffing the file path into `dbch_data` could potentially break some code out there that uses `dbch_size` to guess which event is being sent (something like `if (n->dbch_size == (sizeof(DEV_BROADCAST_HANDLE) + sizeof(BTH_RADIO_IN_RANGE)`). It is an extremely stupid way to check for the event, but I'm not sure whether someone doing this can be safely discounted. I'll write some test code to see if this can be done on Windows to begin with. But as far as I understand, as `plugplay_send_event` is completely non-standard, these structs are only ever sent internally? So you don't really need to bother about abusing some fields or size for the internal notification, you even considered using custom structs which you would convert back and forth on both sides. Simply put whatever you need in the DEV_BROADCAST_HANDLE struct you send, using any unused field, or some other way, to put the device path in it if you need that, and just make sure you fix it up to a correct DEV_BROADCAST_HANDLE struct before calling the notification callback? Although I don't feel like it's even worth it you could even use a custom DEV_BROADCAST_HDR based struct, or extend DEV_BROADCAST_HANDLE with a custom derived struct which has an explicit device path, for the internal messages. I just don't think you need to change the DEV_BROADCAST_HDR base, or change the DEV_BROADCAST_DEVICEINTERFACE code in any significant way for this. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80622

1 0

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

31 Aug '24

On Sat Aug 31 16:30:43 2024 +0000, Elizabeth Figura wrote: > Sorry it's taken me so long to get to this, but 3/4 seems suspicious. > I'd think BroadcastDeviceNotification() [or SendMessageNotify() or > whatever it calls internally] should be making a copy of the message > data itself. Are we not doing that? Should we be doing that instead? Yeah, I might be wrong here. A quick inspection of the code does suggest that we do make copies in `(un)pack_message`. MSDN's documentation for `SendNotifyMessageW`\[1\] warned that messages containing pointers could not be sent as they would result in access to a dangling reference, which is what prompted me to write 3/4. However, `DEV_BROADCAST_DEVICEINTERFACE` messages don't contain any pointers, so this doesn't apply here. \[1\] https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-send… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80621

1 0

2025

2024

2023

2022

wine-gitlab August 2024