May 2024 - wine-gitlab

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

[PATCH v7 0/1] MR5373: shell32: Implement FCIDM_SHVIEW_CREATELINK
by Aric Stewart (＠aricstewart) 30 May '24

30 May '24

Presently the wine file explorer has a create shortcut entry that does nothing. This implements the FCIDM_SHVIEW_CREATELINK command. This is a patch that was first submitted in 2017 and I unfortunately let the revision request fall unimplemented. -- v7: shell32: Implement FCIDM_SHVIEW_CREATELINK https://gitlab.winehq.org/wine/wine/-/merge_requests/5373

3 3

[PATCH v6 0/1] MR5373: shell32: Implement FCIDM_SHVIEW_CREATELINK
by Aric Stewart (＠aricstewart) 30 May '24

30 May '24

Presently the wine file explorer has a create shortcut entry that does nothing. This implements the FCIDM_SHVIEW_CREATELINK command. This is a patch that was first submitted in 2017 and I unfortunately let the revision request fall unimplemented. -- v6: shell32: Implement FCIDM_SHVIEW_CREATELINK https://gitlab.winehq.org/wine/wine/-/merge_requests/5373

2 1

[PATCH v2 0/1] MR5752: msvcrt: [PR53960] Fix ucrt has different struct layout than msvcrt
by cqwrteur (＠trcrsired) 30 May '24

30 May '24

UCRT's FILE struct and fd struct have different layouts, and their locks are different. Implementation in Wine does not match UCRT in Windows, causing ABI issues. see: https://bugs.winehq.org/show_bug.cgi?id=53960 -- v2: msvcrt: [PR53960] Fix ucrt has different struct layout than msvcrt https://gitlab.winehq.org/wine/wine/-/merge_requests/5752

3 3

[PATCH 0/5] MR5751: wined3d: Remove miscellaneous unused definitions, part 4/4.
by Elizabeth Figura (＠zfigura) 30 May '24

30 May '24

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

3 6

[PATCH v3 0/7] MR5666: d3dx9: Introduce d3dx_resource structures for use in code sharing.
by Connor McAdams (＠cmcadams) 30 May '24

30 May '24

This series of patches introduces a new set of structures and functions that will enable code to be re-used across various functions in d3dx9, and eventually d3dx10-d3dx11. It might be possible to split this further, but I feel like this initial set gives better context as to where things are heading. I have a [branch](https://gitlab.winehq.org/cmcadams/wine/-/commits/WIP/d3dx-shared-s… that uses these structures and functions in d3dx10 if further context would be useful. There are a lot of changes here, but after playing around with different approaches this was the best/cleanest way I could come up with for code sharing. I'm sure there will be things I missed or potentially ways to improve this, I'm open to suggestions of course. :) -- v3: d3dx9: Use d3dx_load_pixels_from_pixels() in D3DXLoadVolumeFromMemory(). d3dx9: Use d3dx_pixels structure in decompression helper function. d3dx9: Introduce d3dx_load_pixels_from_pixels() helper function. d3dx9: Use d3dx_image structure in D3DXLoadSurfaceFromFileInMemory(). d3dx9: Introduce d3dx_image structure for use in D3DXGetImageInfoFromFileInMemory(). d3dx9: Refactor WIC image info retrieval code in D3DXGetImageInfoFromFileInMemory(). d3dx9: Refactor WIC GUID to D3DXIMAGE_FILEFORMAT conversion code. https://gitlab.winehq.org/wine/wine/-/merge_requests/5666

2 15

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

> Meantime, I noticed that we could prepare MSHTML for the change better by completing dispex refactoring (and document objects split), see https://gitlab.winehq.org/jacek/wine/-/commits/mshtml-dispex/ for a draft. Unfortunately, it needs a few more vtbl entries, but the unification seems worth to me. On top of that, you wouldn't need to have a dedicated new interface implementation for document node and the window variant should be easier as it could be just a forwarder. What do you think? Looks fine to me. I'm not a fan of all the new vtbl methods, but it's better than what we have currently, so it's fine. This will definitely simplify it, but at the same time, I still want to know if is there something wrong with this MR I should change? I'd like to get it moving, considering it doesn't have much to do with this, these changes would come later ofc. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5444#note_71791

1 0

2025

2024

2023

2022

wine-gitlab May 2024