- wine-gitlab - winehq.org

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

06 Dec '24

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) 06 Dec '24

06 Dec '24

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

[PATCH 0/2] MR6974: winex11: Listen to root window _NET_SUPPORTED property changes.
by Rémi Bernon (＠rbernon) 06 Dec '24

06 Dec '24

This might happen if the window manager is restarted or changed while a Wine window is opened. We should support that use case properly. Split from https://gitlab.winehq.org/wine/wine/-/merge_requests/6944 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6974

2 2

[PATCH v9 0/8] MR6800: mf: Handle unexpected media source shutdown in a media session.
by Conor McCarthy (＠cmccarthy) 06 Dec '24

06 Dec '24

-- v9: winegstreamer: Send media source shutdown notification via IMFMediaShutdownNotify. mf: Introduce IMFMediaShutdownNotify for notification of media source shutdown. https://gitlab.winehq.org/wine/wine/-/merge_requests/6800

4 11

[PATCH v12 0/7] MR4826: Mach vm operations improvements
by Marc-Aurel Zent (＠mzent) 05 Dec '24

05 Dec '24

For all mach vm operations this removes the task suspend and resume, which are not needed. This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4). The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is > [pointer to page aligned in array of bytes] An array of data to be written. (In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here). The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation > The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned. which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working). Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c -- v12: server: Work around macOS W^X limitations in write_process_memory. https://gitlab.winehq.org/wine/wine/-/merge_requests/4826

2 9

[PATCH v11 0/7] MR4826: Mach vm operations improvements
by Marc-Aurel Zent (＠mzent) 05 Dec '24

05 Dec '24

For all mach vm operations this removes the task suspend and resume, which are not needed. This uses `mach_vm_read_overwrite` to read into a caller-specified buffer, saving the `mach_vm_deallocate` call (bringing all read operations down to 1 syscall from 4). The only alignment restriction on `mach_vm_write` according to the original CMU documentation is that data is > [pointer to page aligned in array of bytes] An array of data to be written. (In practice it also works with arbitrary addresses on macOS, but it probably doesn't hurt to follow the original specifications here). The only other reference that these read/writes should be page-aligned is from the GNU Hurd documentation > The current implementation requires that address, data and data_count all be page-aligned. Otherwise, KERN_INVALID_ARGUMENT is returned. which I assume was the reason why this was originally done (plus it sounds to me like they will fix that in the future and 4fe19777 already broke GNU Hurd support anyways, if that was supposed to be working). Also this includes the missing mach part of 5b1f3b14, which was only applied to the ptrace backend, and together with the `write_process_memory` rework, this gets rid of all fixmes in mach.c -- v11: server: Work around macOS W^X limitations in write_process_memory. server: Do not page-align address in write_process_memory. server: Do not suspend mach task in write_process_memory. server: Use mach_vm_read_overwrite in get_selector_entry. server: Do not suspend mach task in get_selector_entry. server: Use mach_vm_read_overwrite in read_process_memory. server: Do not suspend mach task in read_process_memory. https://gitlab.winehq.org/wine/wine/-/merge_requests/4826

3 12

[PATCH 0/8] MR6973: quartz/dsoundrender: Several fixes.
by Elizabeth Figura (＠zfigura) 05 Dec '24

05 Dec '24

This is a more correct version of 6849, plus some other changes not included in 6849, and should supersede the remaining patches in that merge request. It is also a large and risky change and may not be suitable this close to code freeze. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/6973

3 9

Re: [PATCH v2 0/2] MR6970: jscript: Add support for deleting host properties. - approved
by Alexandre Julliard (＠julliard) 05 Dec '24

05 Dec '24

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

1 0

Re: [PATCH v2 0/3] MR6972: include: Add missing types. - approved
by Alexandre Julliard (＠julliard) 05 Dec '24

05 Dec '24

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

1 0

Re: [PATCH v2 0/1] MR6125: server: Ensure in pending delete on close that path to unlink are unique. - approved
by Alexandre Julliard (＠julliard) 05 Dec '24

05 Dec '24

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

1 0

2025

2024

2023

2022

wine-gitlab