- Wine-GitLab - list.winehq.org

[PATCH v5 0/2] MR131: vkd3d: Persistently map host-visible heaps on creation.
by Zebediah Figura (＠zfigura) April 10, 2023

April 10, 2023

-- v5: tests: Add a test for readback map stability. vkd3d: Persistently map host-visible heaps on creation. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/131

4 3

[PATCH v4 0/4] MR2603: winecoreaudio: Move timer logic to unixlib, matching other drivers.
by Davide Beatrici (＠davidebeatrici) April 10, 2023

April 10, 2023

-- v4: winecoreaudio: Implement and call timer_loop in unixlib. winecoreaudio: Implement and call set_event_handle in unixlib. winecoreaudio: Store flags in unixlib. winecoreaudio: Retain precision when storing period in unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2603

3 5

[PATCH v3 0/1] MR2032: winex11: Allow replacing either context in wglShareLists.
by Alex Henrie (＠alexhenrie) April 10, 2023

April 10, 2023

The deleted test is a bad test: The behavior is different on different drivers, for example, the test fails on the Windows 10 and 11 testbot machines that have AMD video cards. Furthermore, MSDN does not say that the destination context "must not" have any display lists yet but rather that it "should not" have any.[1] The Khronos OpenGL Wiki similarly advises against calling wglShareLists after the source or destination context has at least one object, but if you do, it only says that "there is a chance that wglShareLists will fail", not that it will necessarily fail.[2] Since there's no clear "right" behavior here, we can adopt the more permissive behavior that some programs expect, as long as it doesn't corrupt the context. [1] https://learn.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-wglsha… [2] https://www.khronos.org/opengl/wiki/Platform_specifics:_Windows#wglShareLis… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=11436 -- v3: winex11: Allow replacing either context in wglShareLists. https://gitlab.winehq.org/wine/wine/-/merge_requests/2032

3 7

[PATCH 0/5] MR2621: Some IShellView improvements.
by Jactry Zeng (＠jactry) April 10, 2023

April 10, 2023

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

2 5

[PATCH 0/2] MR2620: include: Add windows.ui.composition.interop.idl file.
by Mohamad Al-Jaf (＠maljaf) April 10, 2023

April 10, 2023

Needed for mingw Firefox build. The WIDL error points to the wrong function, specifically the one after it. include/windows.ui.composition.interop.idl:35:63: error: parameter 'swapchain' of function 'CreateCompositionSurfaceForHandle' cannot derive from void * HRESULT CreateCompositionSurfaceForSwapChain([in] IUnknown *swapchain, [out, retval] ICompositionSurface **result); ^ make[1]: *** [Makefile:163749: include/windows.ui.composition.interop.h] Error 1 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2620

3 4

[PATCH v2 0/1] MR2619: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType().
by Nikolay Sivov (＠nsivov) April 9, 2023

April 9, 2023

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2619

2 1

[PATCH 0/1] MR2619: mfplat: Handle more video subtypes in MFInitMediaTypeFromAMMediaType().
by Nikolay Sivov (＠nsivov) April 9, 2023

April 9, 2023

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2619

3 2

[PATCH 0/1] MR2618: ntdll: Increment offset by len in build_clr_surrogate_section.
by Alex Henrie (＠alexhenrie) April 9, 2023

April 9, 2023

Instead of multiplying it by 2. I don't know how this ever worked. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54808 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2618

3 3

[PATCH v3 0/1] MR150: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops.
by Nikolay Sivov (＠nsivov) April 8, 2023

April 8, 2023

-- v3: vkd3d-shader/hlsl: Ignore "unroll" attribute for loops. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/150

3 2

Re: [PATCH v5 0/5] MR2555: Draft: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) April 8, 2023

April 8, 2023

On Sat Apr 8 12:22:23 2023 +0000, Nikolay Sivov wrote: > As I recall, for original fix to accept a range of resource IDs the > question was how are those different from each other, meaning if there > are multiple resources, when one should be used but not another. >From Micrsoft documentation, [Using Side-by-Side Assemblies as a Resource][sxs-rsrc] outlines the significance of each reserved manifest resource ID. Further investigation reveals the following: 1. `CREATEPROCESS_MANIFEST_RESOURCE_ID` (value: `1`): This is used for process-wide initial (`NULL`) activation context. - **Usage documentation**: [Enabling an Assembly in an Application Without Extensions](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-… - **Intended container module type**: EXE only. - **Lifetime of the associated activation context**: Alive until the process is terminated. Owned by system (NTDLL). - **Isolation-aware**: No. 2. `ISOLATIONAWARE_MANIFEST_RESOURCE_ID` (value: `2`): This is used to specify the assembly manifest that the loader (Ldr) uses to resolve static imports. Also, this is used by isolation-aware wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [Enabling an Assembly in an Application Hosting a DLL, Extension, or Control Panel](https://learn.microsoft.com/en-us/windows/win32/sbscs/enabling-an-as… - **Intended container module type**: EXE and DLL. - **Lifetime of the associated activation context**: Alive until the module is unloaded (e.g., via `FreeLibrary`). Owned by system (NTDLL). - **Isolation-aware**: Yes. 3. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` (value: `3`): Ignored by the loader when resolving static imports. This is used by isolation-aware API wrappers defined in `*.inl` files included in the Windows SDK (`include\um`) when the `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value. - **Usage documentation**: [IsolationAwareCleanup function][IsolationAwareCleanup] - **Intended container module type**: EXE and DLL. - **Lifetime of the associated activation context**: Alive until the application calls [`IsolationAwareCleanup`][IsolationAwareCleanup][^ia-cleanup-note]. Owned by the isolation-aware API wrapper library (part of the Windows SDK, rather than being a system DLL). - **Isolation-aware**: Yes. The `ISOLATION_AWARE_ENABLED` macro is documented in [Isolating Components][sxs-ic] as well as [Specifying a Default Activation Context][sxs-def-actctx]. When `ISOLATION_AWARE_ENABLED` macro is defined as a nonzero value, then the isolation-aware API wrapper library is enabled. The isolation-aware API wrapper library is responsible for: - Creating (lazily) and destroying activation context (in `IsolationAwareCleanup`), if the manifest resource ID is `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID`.[^actctx-lifetime-remark] - Note: the isolation-aware API wrapper library does not manage the activation context's lifetime and delegates the responsibility to the system loader if the manifest resource ID is `ISOLATIONAWARE_MANIFEST_RESOURCE_ID`. - Intercepting Win32 API calls for automatic activation context activation. Each API wrapper activates the "isolation-aware" activation context (obtaining one if it did not exist) before calling the original procedure, and deactivates it before returning. The isolation-aware wrappers may be either be defined inline, or compiled into static libraries that are linked into the final application executable. >From the information above as well as the tests included in this merge request, we can infer the following: 1. Although side-by-side awareness is a cross-cutting concern, the *activation* of activation contexts itself is *not* usually performed automatically by the system for the application (with the sole exception of process-wide activation context associated with `CREATEPROCESS_MANIFEST_RESOURCE_ID`, and static import resolution). 2. `ISOLATIONAWARE_NOSTATICIMPORT_MANIFEST_RESOURCE_ID` is treated like any other resource ID (from `0x0002` to `0xffff`) as far as the loader is concerned. 3. The resource ID of the manifest only concerns how the module containing the manifest intends to use the manifest. In fact, for DLLs that do not *statically* import symbols from side-by-side assemblies, the three resource IDs above are basically equivalent. A DLL can elect not to use manifest resources at all, and manage activation context and library loading by itself. This is why I believe that this merge request is sufficient in completing the isolation-aware component support in Wine; the heavy lifting is done in the application side, not the system. **EDIT**: Fix a few typos and unclear wording. --- [^ia-cleanup-note]: According to the documentation, the application is presumably responsible for calling `IsolationAwareCleanup` from `DllMain` on `fdwReason = DLL_PROCESS_DETACH`. [^actctx-lifetime-remark]: [IsolationAwareCleanup § Remarks](https://learn.microsoft.com/en-us/previous-versions/windows/deskto…, from Microsoft documentation. [sxs-rsrc]: https://learn.microsoft.com/en-us/windows/win32/sbscs/using-side-by-side-as… [IsolationAwareCleanup]: https://learn.microsoft.com/en-us/previous-versions/windows/desktop/legacy/… [sxs-ic]: https://learn.microsoft.com/en-us/windows/win32/sbscs/isolating-components [sxs-def-actctx]: https://learn.microsoft.com/en-us/windows/win32/sbscs/specifying-a-default-… -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2555#note_29411

1 0