May 2024 - wine-gitlab

[PATCH 0/4] MR5759: comctl32 & user32: Mark radio buttons at selected when focused
by Fabian Maurer (＠DarkShadow44) 30 May '24

30 May '24

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=56109 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5759

4 8

[PATCH 0/1] MR5758: ntdll: On macOS, check for xattr existence before calling getxattr.
by Brendan Shanks (＠bshanks) 30 May '24

30 May '24

On macOS, getxattr() is surprisingly slow, several times slower than running listxattr on the same file. (It seems like getxattr() is doing security checks before determining whether the xattr exists or not). On macOS 14.5, timing for 30000 calls to the following functions (the target file contains no xattrs): ``` lstat: 29729459 ns getxattr: 110323334 ns listxattr: 14672500 ns ``` And a Wine test that calls FindFirstFile 2500 times with a path of "C:\\windows\\system32\\*.nonexistent": ``` currently: 12119 ms with this patch: 5580 ms ``` -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5758

2 1

Re: [PATCH v5 0/3] MR5740: Inlcude updates - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v2 0/5] MR5751: wined3d: Remove miscellaneous unused definitions, part 4/4. - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v2 0/1] MR5755: vkd3d: Import upstream release 1.12. - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v3 0/7] MR5753: win32u: Introduce a helper to set the window surface clipping region. - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v4 0/6] MR5564: mmdevapi: Adjust timing in AudioClient_Initialize, removing related code from drivers. - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v2 0/1] MR5750: ntdll: Add stub RtlLookupGenericTableAvl function. - approved
by Alexandre Julliard (＠julliard) 30 May '24

30 May '24

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

1 0

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Gabriel Ivăncescu (＠insn) 30 May '24

30 May '24

> There is a difference between C/C++ and JS that we need to cover one way or another. C implementation is bound to a specific object type, which makes using `impl_from_*` possible. To keep that possibility in hooks, they need to be bound to a specific object type as well. More idiomatically: hooks are a part of C implementation of JS functions and C implementations are specific to object instance type. Well yes, of course they check for the object type compatibility, but in the end they should still preserve their "function identity" instead of being looked up from the object everytime, even if it's completely detached from it. > Do you have a branch where I could see it in action? I need to fix a couple things but I will update the branch tomorrow with the prototype chains most likely. (it's probably not 100% perfectly designed but I mean the general idea) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71825

1 0

Re: [PATCH v8 0/11] MR5444: jscript: Do not allocate dispex_prop_t for indexed props.
by Jacek Caban (＠jacek) 30 May '24

30 May '24

> But this `func_info_t` (rather than IID) is used for storing/creating the function object itself (like create_builtin_function but for proxies), not tied to any object, and such function object contains all the "code" of the function not just the signature, so isn't that actually more correct, idiomatically at least? There is a difference between C/C++ and JS that we need to cover one way or another. C implementation is bound to a specific object type, which makes using `impl_from_*` possible. To keep that possibility in hooks, they need to be bound to a specific object type as well. More idiomatically: hooks are a part of C implementation of JS functions and C implementations are specific to object instance type. > There are no interfaces added to deal with prototype chains, unless you mean the new method I added for `func_info_t`? Do you have a branch where I could see it in action? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71824

1 0

2025

2024

2023

2022

wine-gitlab May 2024