- wine-gitlab - winehq.org

Re: [PATCH v2 0/2] MR6328: winevulkan: Add video interfaces. - approved
by Alexandre Julliard (＠julliard) 21 Aug '24

21 Aug '24

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6328

1 0

Re: [PATCH v20 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

On Wed Aug 21 14:09:17 2024 +0000, Vibhav Pant wrote: > I have renamed it to `device_notification_details_with_notify`, is that better? Eh. I don't like "notify" as a noun, it's still kind of misleading. I guess "handle" is also ambiguous for that matter. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79507

1 0

Re: [PATCH v20 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

On Wed Aug 21 14:12:47 2024 +0000, Vibhav Pant wrote: > Yup, moved it. However, I haven't inlined it, as I wanted to also add a > log entry whenever `device_notify_proc` matches an incoming event > against a registered notification filter, just before the `struct > device_broadcast` object is dispatched to the corresponding callback. > Would that be too noisy? If yes, I'll go ahead and inline it. I can only speak for myself, but I don't imagine I would find a TRACE like that too noisy. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79506

1 0

Re: [PATCH v20 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

On Wed Aug 21 13:01:35 2024 +0000, Vibhav Pant wrote: > > Note that if you're using DWORD (and you could just as easily use > "unsigned int" instead) you probably want "%lu" rather than casting to int. > Yeah, I was a little confused if there's a format specification > convention used by Wine for unsigned type variables used for storing > size. Except for `%#Ix` used to `SIZE_T`, I could only see `ULONG`s > being cast to int and then being printed with `%d`, so that's what I > went with to be safe. But yeah, `%lu` makes more sense. I think %u/%d vs %#x is mostly a matter of "best judgement", but in general you should use the right signed variant, and in PE code you shouldn't need to cast to get the right length specifier (though it may require a bit of extra knowledge: %d for int, %ld for long [which is always 32-bit on Windows], %Id for anything pointer-size, %I64d for 64-bit types [note that 'long long' is always 64-bit, but can't be used.]) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79505

1 0

Re: [PATCH v20 0/4] MR6315: plugplay: Rework how PnP notifications are sent over RPC to support DBT_DEVTYP_HANDLE events.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

On Wed Aug 21 14:08:25 2024 +0000, Vibhav Pant wrote: > changed this line in [version 15 of the diff](/wine/wine/-/merge_requests/6315/diffs?diff_id=127699&start_sha=200a214bfb66f40ec311b78086abe9c3b95ba36a#c24d5a128c8e2e7df00647f30fabed6de6e42a52_2_0) Hmm indeed. I'm not sure there's any reason we shouldn't do something like the attached patch in general, but that's for another merge request. [scratch.diff](/uploads/36b496a0f6da14780df7bf853560835a/scratch.diff) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6315#note_79504

1 0

[PATCH v10 0/2] MR6130: shell32: Added stubs for the EnumerableObjectCollection COM class.
by Kevin Martinez (＠kevinrmartinez) 21 Aug '24

21 Aug '24

Stub added for the IEnumObjects and IObjectCollection interfaces, so that programs won't crash when calling it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53620 Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56891 -- v10: shell32: Added stub for IObjectCollection interface. shell32: Added stub for IEnumObjects interface. https://gitlab.winehq.org/wine/wine/-/merge_requests/6130

4 5

[PATCH 0/2] MR6322: jscript: eval and JSON fixes
by Gabriel Ivăncescu (＠insn) 21 Aug '24

21 Aug '24

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

3 8

[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

[PATCH v18 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…. -- v18: plugplay: Broadcast PnP events on a dedicated thread. plugplay: Rewrite RPC interface to send and receive events using the newly introduced DEVICE_BROADCAST types. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

2 4

[PATCH 0/2] MR6328: winevulkan: Add video interfaces.
by Elizabeth Figura (＠zfigura) 21 Aug '24

21 Aug '24

Tested with win32 ffmpeg. This merge request basically passes video.xml (and its parsed form) as an extra argument where vk.xml is passed. While this is ad-hoc and not very future-proof, there is no indication that Khronos will fragment its XMLs any further, and it does not seem worthwhile to me to try to generalize the parsing logic in that respect as long as only two XMLs are used. However, if the maintainers feel differently, I will endeavour to do so. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6328

3 3

[PATCH v3 0/24] MR6323: Draft: winewayland: Support GL/VK rendering in child windows (alt).
by Rémi Bernon (＠rbernon) 21 Aug '24

21 Aug '24

-- v3: winewayland: Use subsurfaces for unmanaged windows. winewayland: Introduce a new update_wayland_surface_state_toplevel helper. winewayland: Introduce a new wayland_surface_reconfigure_xdg helper. winewayland: Introduce a new wayland_surface role enumeration. winewayland: Call wayland_surface_clear_role in wayland_surface_destroy. winewayland: Move surface title change to wayland_surface_make_toplevel. winewayland: Attach client client surfaces to their toplevel surface. winewayland: Use WindowPosChanged swp_flags to decide if a window is visible. winewayland: Use the wayland_win_data client rect for child GL windows. winewayland: Split wayland_win_data_update_wayland_surface helper. winewayland: Call ensure_window_surface_contents with the toplevel window. win32u: Update children window state when the parent state changes. winewayland: Get rid of window_surface reference from wayland_win_data. winewayland: Move client surface to wayland_win_data struct. winewayland: Get rid of the window surface individual locks. winewayland: Introduce a new wayland_client_surface_create helper. 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. winewayland: Store all window rects in wayland_win_data. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/wine/-/merge_requests/6323

1 1

[PATCH v14 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…. -- v14: plugplay: Broadcast PnP events on a dedicated thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/6315

4 23

[PATCH v2 0/4] MR6332: win32u: Move visible rect computation out of the drivers.
by Rémi Bernon (＠rbernon) 21 Aug '24

21 Aug '24

Using a new GetWindowStyleMasks driver entry to get the style masks to be used to mask out non-client decorations which are hidden by the host decorations. This is done after WindowPosChanging, as winex11 needs to update its managed flag before computing the visible rect, this means that the visible rect might change between WindowPosChanging and WindowPosChanged. It should hopefully be fine. -- v2: winex11: Use the driver rects to convert from host visible to window rect. winex11: Keep a window_rects struct in the driver window data. win32u: Move visible rect computation out of the drivers. win32u: Keep SetIMECompositionWindowPos with other IME entries. https://gitlab.winehq.org/wine/wine/-/merge_requests/6332

2 6

[PATCH v2 0/4] MR4457: Add tests and implementation of FILE_{RENAME,LINK}_POSIX_SEMANTICS.
by Joel Holdsworth (＠jhol) 21 Aug '24

21 Aug '24

Signed-off-by: Joel Holdsworth <joel(a)airwebreathe.org.uk> -- v2: ntdll: Add support for FILE_{RENAME,LINK}_POSIX_SEMANTICS. ntdll: Factor out get_inode_open_sharing. ntdll/test: Add tests for FILE_LINK_POSIX_SEMANTICS. ntdll/test: Add tests for FILE_RENAME_POSIX_SEMANTICS. https://gitlab.winehq.org/wine/wine/-/merge_requests/4457

4 10

Re: [PATCH v2 0/16] MR6323: Draft: winewayland: Support GL/VK rendering in child windows (alt).
by Alexandros Frantzis (＠afrantzis) 21 Aug '24

21 Aug '24

Thanks for the proposal! I have made [a couple of additional changes](https://gitlab.winehq.org/afrantzis/wine/-/commits/wip/wayland-chi… to this branch, to improve the behavior in some nested and visibility scenarios. The locking simplification changes look very nice, and perhaps it would be good to land them independently of whatever child accel. rendering design we go with. Concerning the child. accel design proposed, I am not sure if I find it less complex, but rather differently complex. !6107 centralizes the complexity in the `wayland_surface` update logic, but then other parts of the code can just use it without caring about most of the details. This MR has simpler parts, but then spreads out the complexity, since other parts need to care about `wayland_surface` vs `wayland_client_surface` etc. I am sure this perception about complexity is affected by my mind being used to the other design, though, and there are certainly benefits to this MR (e.g., avoiding an intermediate `wl_surface` when doing child accel. rendering). However, note that a big part of the design and complexity of !6107 is due to wanting to provide a more general mechanism for using subsurfaces for any kind of window. This makes is very easy to support popup positioning over !6107, doing something like https://gitlab.winehq.org/afrantzis/wine/-/commit/63baaec4379fb3222a08aae01…. This MR doesn't deal with that (which is fine), but then it's not clear to me how an approach based on this design would evolve and how complex it would become to support the popup positioning scenarios we want (and whether it would then be worth it over !6107). I think this may need a bit more exploration to get a more complete picture (or perhaps you already have a good idea of how this would look like?). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6323#note_79403

1 0

[PATCH 0/2] MR6326: msi: Fix row index calculation when stringtable contains empty slots.
by Piotr Caban (＠piotr) 21 Aug '24

21 Aug '24

Native msi deletes strings if no longer used. It's possible to create string table with empty slots this way. In such case we may add new row at incorrect index causing the table to be not sorted by primary key. This affects 3ds Max 2024 installers that contain such string table. I don't see how to add a test case for that without adding precreated MSI file. In order to create such file in tests we will need to implement strings refcounting (that is currently mostly missing). It looks like a big task that will likely introduce regressions. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6326

3 5

2025

2024

2023

2022

wine-gitlab