On Sat Aug 31 17:49:29 2024 +0000, Rémi Bernon wrote:
> > 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.
I have re-written this series to use `dbch_reserved` and implement `IoReportTargetDeviceChange` here, so I'll close this MR: https://gitlab.winehq.org/wine/wine/-/merge_requests/6437
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_80855
On Tue Sep 3 11:03:31 2024 +0000, Ostap Brehin wrote:
> @Alcaro Thanks! I changed it back to `CALLBACK` now, it was a typo on my side.
Current SDK has is with WINAPI, and so do mingw-w64 headers. Which again, won't make any difference in practice.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6425#note_80851
The OpenKiosk MSI installer specifies "x64" for PID_TEMPLATE in its summary information stream, which is rejected by Wine at package open time. While the examples of valid template strings in MSDN suggest that a semicolon is mandatory in a template string, tests of template string validation show that a platform may be specified in a template without the semicolon delimiter.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52687
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/6429
(From https://gitlab.winehq.org/wine/wine/-/merge_requests/6323)
--
v3: winewayland: Get rid of the window surface individual locks.
winewayland: Introduce a new wayland_client_surface_create helper.
winewayland: Get rid of window_surface reference from wayland_win_data.
winewayland: Get rid of wayland_surface reference from window_surface.
winewayland: Move window contents buffer to wayland_win_data struct.
winewayland: Reset the buffer damage region immediately after copy.
winewayland: Introduce a new get_window_surface_contents helper.
winewayland: Introduce a new set_window_surface_contents helper.
winewayland: Introduce a new ensure_window_surface_contents helper.
winewayland: Post WM_WAYLAND_CONFIGURE outside of the surface lock.
https://gitlab.winehq.org/wine/wine/-/merge_requests/6374