December 2024 - Wine-GitLab

[PATCH v15 0/3] MR6737: comctl32/toolbar: forward WM_NOTIFY CBEN_ENDEDITW
by Alanas Tebuev (＠BZZZZ) Dec. 6, 2024

Dec. 6, 2024

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=57178 This makes [7-zip file manager](https://www.7-zip.org/) pressing enter while editing path work: * before: * [Icon near path becomes dark (7-zip file manager doesn't go to path).](https://old.reddit.com/r/winehq/comments/16ah3ze/7zip_cant_enter_pa…) * after: * 7-zip file manager goes to path. * Path input displays incorrect path (shouldn't happen, bug in wine's comboboxex unrelated to toolbar). -- v15: comctl32/toolbar: Forward WM_NOTIFY CBEN_ENDEDITW. comctl32: Move WM_NOTIFY unicode to ansi conversion code from pager.c to commctrl.c. comctl32/tests: Test WM_NOTIFY CBEN_ENDEDITW conversion and forwarding in toolbar. https://gitlab.winehq.org/wine/wine/-/merge_requests/6737

3 5

Re: [PATCH v2 0/2] MR6970: jscript: Add support for deleting host properties.
by Gabriel Ivăncescu Dec. 6, 2024

Dec. 6, 2024

On Fri Dec 6 10:42:56 2024 +0000, Jacek Caban wrote: > Thanks. This intentionally doesn't touch `PROP_EXTERN`, as deleting > those requires interaction with the host object. For all jscript knows, > the host may choose to ignore the delete. Fixing accessor and function > properties should cover everything prototypes currently need, so those > should be in good shape for the code freeze. > It could be useful to allow external properties to opt into this delete > mechanism for cases where host-owned properties should always behave > like regular ones. Examples include `constructor`, `prototype`, and > possibly constants like `Node.TEXT_NODE`. > For cases like document and window, we might introduce a flag in > `property_info` to modify name lookup. Jscript could continue searching > the prototype chain and use returned info only if the search fails. > Storage properties seem more complicated. None of the solutions that > come to mind feel ideal, but this is a very niche corner case. I doubt > any reasonable code depends on it, so it seems safe to ignore for now. > It also doesn't seem like something Proton needs to worry about. Well Typed Arrays will need something similar (they override all input indices, and override defineProperty), when I made the first dispex revamp with them, it wasn't clear how it would interact with the host object implementation. Well, it's clear now that we need a way to override them, I guess. And btw Typed Arrays really need that DISPID optimization as well (or my original hack, which didn't cover enums only) to skip DISPID for every element. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6970#note_89973

1 0

[PATCH v5 0/5] MR6936: winebth.sys part 2: Add support for Bluetooth radio properties.
by Vibhav Pant (＠vibhavp) Dec. 6, 2024

Dec. 6, 2024

This MR adds support for getting a Bluetooth adapter's properties from its corresponding `org.bluez.Adapter1` object, and making them available to userspace via device properties and the `IOCTL_BTH_GET_LOCAL_INFO` ioctl, updating these properties whenever a `PropertiesChanged` signal is received for the adapter. It also adds code for creating and removing radio PDOs on receiving `InterafacesAdded` and `InterfacesRemoved` signals from BlueZ, respectively. -- v5: winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO. https://gitlab.winehq.org/wine/wine/-/merge_requests/6936

2 5

[PATCH v4 0/5] MR6936: winebth.sys part 2: Add support for Bluetooth radio properties.
by Vibhav Pant (＠vibhavp) Dec. 6, 2024

Dec. 6, 2024

This MR adds support for getting a Bluetooth adapter's properties from its corresponding `org.bluez.Adapter1` object, and making them available to userspace via device properties and the `IOCTL_BTH_GET_LOCAL_INFO` ioctl, updating these properties whenever a `PropertiesChanged` signal is received for the adapter. It also adds code for creating and removing radio PDOs on receiving `InterafacesAdded` and `InterfacesRemoved` signals from BlueZ, respectively. -- v4: winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO. winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. https://gitlab.winehq.org/wine/wine/-/merge_requests/6936

4 8

[PATCH v5 0/3] MR6904: ntdll.dll: Update NtQueryDirectoryFile to align with current Windows behaviour
by Eugene McArdle (＠eugenemcardle) Dec. 6, 2024

Dec. 6, 2024

This PR updates the behaviour of `NtQueryDirectoryFile`, bringing it in line with current Windows behaviour. The need for this update was discovered when attempting to build the Unreal Engine with MSVC under Wine. In certain cases conditional include statements do not behave as expected, due to MSVC depending on undocumented behaviour of `NtQueryDirectoryFile`. We ran tests on multiple versions of Windows, and discovered that the behaviour has changed since the original Wine implementation, but the documentation has not. The source code for our test tool, and a set of results can be found [here](https://github.com/TensorWorks/NtQueryDirectoryFile-Test). As of Windows 8, calling `NtQueryDirectoryFile` with a re-used handle, a new mask, and setting the `RestartScan` flag to True, causes the cached results to be erased and a new scan to be performed with the updated mask. Currently, Wine performs as did earlier versions of Windows, where the changed mask is ignored, and the cache is reused. This can cause `NtQueryDirectoryFile` under Wine to falsely report that files exist, when they do not. This PR corrects this behaviour, invalidating the cache when required. Implementing this exposed further undocumented behaviour of `NtQueryDirectoryFile`, where a search for a non-existent file will return either `STATUS_NO_MORE_FILES` or `STATUS_NO_SUCH_FILE`, depending on whether or not the handle had been previously used regardless of the value of `RestartScan`. This was reflected in a `winetest` which allowed for the response to be either `STATUS_SUCCESS` or `STATUS_NO_MORE_FILES`. This test has been updated to only allow current Windows behaviour, and `NtQueryDirectoryFile` will return either `STATUS_NO_MORE_FILES` or `STATUS_NO_SUCH_FILE` as appropriate. This patch also adds unit tests for the new behaviour of `NtQueryDirectoryFile`. These tests pass when running `winetest` under Windows, and under Wine with these changes in place, but they will fail under older versions of Wine. -- v5: ntdll: Add tests to confirm filemasks are tied to handles and not directories https://gitlab.winehq.org/wine/wine/-/merge_requests/6904

4 6

[PATCH 0/1] MR6976: ucrtbase: Always use CP_ACP when converting environment block.
by Piotr Caban (＠piotr) Dec. 6, 2024

Dec. 6, 2024

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

2 1

[PATCH 0/1] MR6975: winedbg: Add support for dynamic debug channel.
by eric pouech (＠epo) Dec. 6, 2024

Dec. 6, 2024

Updating also strategy to get back to Wine's ntdll settings. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6975

3 2

[PATCH v3 0/5] MR6936: winebth.sys part 2: Add support for Bluetooth radio properties.
by Vibhav Pant (＠vibhavp) Dec. 6, 2024

Dec. 6, 2024

This MR adds support for getting a Bluetooth adapter's properties from its corresponding `org.bluez.Adapter1` object, and making them available to userspace via device properties and the `IOCTL_BTH_GET_LOCAL_INFO` ioctl, updating these properties whenever a `PropertiesChanged` signal is received for the adapter. It also adds code for creating and removing radio PDOs on receiving `InterafacesAdded` and `InterfacesRemoved` signals from BlueZ, respectively. -- v3: winebth.sys: Implement IOCTL_BTH_GET_LOCAL_INFO. winebth.sys: Update radio PDO properties on receiving PropertiesChanged for an org.bluez.Adapter1 object. winebth.sys: Remove the corresponding radio PDO on receiving InterfacesRemoved for a org.bluez.Adapter1 object. winebth.sys: Create new radio PDOs on receiving InterfacesAdded for objects that implement org.bluez.Adapter1. winebth.sys: Set radio PDO properties from the device's corresponding org.bluez.Adapter1 object properties. https://gitlab.winehq.org/wine/wine/-/merge_requests/6936

5 15

Re: [PATCH v8 0/1] MR4174: shell32: Add Internet Explorer toolbar icons.
by Jacek Caban (＠jacek) Dec. 6, 2024

Dec. 6, 2024

Sorry for the delay, I'm not sure what to think about it. If it's dropped in modern Windows, it's not clear if we want it. I guess it wouldn't hurt... We usually add SVGs so that maintainer mode can generate binary blobs. It seems that Tango theme repo contains SVGs, could we use them? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/4174#note_89955

1 0

Re: [PATCH v2 0/2] MR6970: jscript: Add support for deleting host properties.
by Jacek Caban (＠jacek) Dec. 6, 2024

Dec. 6, 2024

On Fri Dec 6 10:42:56 2024 +0000, Gabriel Ivăncescu wrote: > This looks fine for now, pretty neat way to fix it. > But I still don't think we can escape a revamp at some point. The 2 > "largest" volatile objects I tested before were the storage, and > doc/window, and they function differently. On doc and window, the > volatile props (stuff like accessing DOM elements via props) are looked > up after the prototypes, while on storage, they are looked up first, > before even the prop on the object. > For example: > - localStorage.getItem("test") returns null (no volatile item). > - Object.defineProperty(localStorage, "test", ...) creates normal prop > on it. > - localStorage.setItem("test", "blah") now it is `blah` (only way to > retrieve the defined prop underneat is getOwnPropertyDescriptor) > - localStorage.removeItem("test") now reveals the original defined prop > Worse is that it also hijacks deletion, so delete acts like removeItem, > but if you call delete now, it won't delete the defineProperty prop > (since there's no setItem so nothing to remove). > For doc and window it's the opposite and if anything in the prototype > chain has the name of an element id, it will be returned instead. Thanks. This intentionally doesn't touch `PROP_EXTERN`, as deleting those requires interaction with the host object. For all jscript knows, the host may choose to ignore the delete. Fixing accessor and function properties should cover everything prototypes currently need, so those should be in good shape for the code freeze. It could be useful to allow external properties to opt into this delete mechanism for cases where host-owned properties should always behave like regular ones. Examples include `constructor`, `prototype`, and possibly constants like `Node.TEXT_NODE`. For cases like document and window, we might introduce a flag in `property_info` to modify name lookup. Jscript could continue searching the prototype chain and use returned info only if the search fails. Storage properties seem more complicated. None of the solutions that come to mind feel ideal, but this is a very niche corner case. I doubt any reasonable code depends on it, so it seems safe to ignore for now. It also doesn't seem like something Proton needs to worry about. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6970#note_89951

1 0