May 2023 - wine-gitlab

[PATCH v2 0/7] MR2856: ntdll: Support VM placeholders (part 1 of 2)
by Paul Gofman (＠gofman) 24 May '23

24 May '23

-- v2: ntdll/tests: Add more tests for placeholders. ntdll: Support MEM_PRESERVE_PLACEHOLDER in NtFreeVirtualMemory(). ntdll: Support MEM_REPLACE_PLACEHOLDER in NtAllocateVirtualMemoryEx(). ntdll: Support MEM_REPLACE_PLACEHOLDER in map_view(). ntdll: Support MEM_RESERVE_PLACEHOLDER in NtAllocateVirtualMemoryEx(). ntdll: Pass allocation type to map_view(). ntdll: Handle NULL process handle in MapViewOfFile3(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2856

2 8

[PATCH v9 0/5] MR2555: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) 24 May '23

24 May '23

From Microsoft 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 `0x0004` 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-… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18889 -- v9: ntdll: Don't hard-code DLL manifest resource ID when looking up dependency assembly. kernel32/tests: Test loading assembly manifest resource inside dependencies. https://gitlab.winehq.org/wine/wine/-/merge_requests/2555

3 8

[PATCH 0/1] MR2889: winegstreamer: Implement Flush for WMV decoder DMO.
by Ziqing Hui (＠zhui) 24 May '23

24 May '23

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

3 5

[PATCH v2 0/4] MR2884: uiautomationcore: Add support for creating/destroying HUIAEVENTs.
by Connor McAdams (＠cmcadams) 24 May '23

24 May '23

-- v2: uiautomationcore: Add support for advising providers of events being added/removed. uiautomationcore: Implement UiaRemoveEvent. uiautomationcore: Implement UiaAddEvent. uiautomationcore/tests: Add tests for non-nested node events. https://gitlab.winehq.org/wine/wine/-/merge_requests/2884

3 11

[PATCH 0/4] MR2778: mfmediaengine: Add support for video effects.
by Bernhard Kölbl (＠besentv) 24 May '23

24 May '23

The test has a little inspiration from the SDK samples. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2778

4 22

[PATCH v8 0/5] MR2555: ntdll: Support ISOLATIONAWARE_MANIFEST_RESOURCE_ID (#18889)
by Jinoh Kang (＠iamahuman) 24 May '23

24 May '23

From Microsoft 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 `0x0004` 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-… Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=18889 -- v8: ntdll: Don't hard-code DLL manifest resource ID when looking up dependency assembly. kernel32/tests: Test loading assembly manifest resource inside dependencies. ntdll: Move ACTCTX lpResourceName validation to RtlCreateActivationContext. kernel32/tests: Test setting lpResourceName to NULL for CreateActCtxW. kernel32/tests: Remove test for ACTCTX_FLAG_HMODULE_VALID with hModule = NULL case. https://gitlab.winehq.org/wine/wine/-/merge_requests/2555

3 11

[PATCH v4 0/5] MR206: vkd3d-shader/hlsl: Implement SampleCmp() method.
by Nikolay Sivov (＠nsivov) 24 May '23

24 May '23

-- v4: vkd3d-shader/tpf: Write out comparison mode sampler declarations and corresponding sampling instruction. vkd3d-shader/hlsl: Parse SampleCmp() method. vkd3d-shader/hlsl: Parse SamplerComparisonState objects. vkd3d-shader/hlsl: Use a function table for object methods handlers. vkd3d-shader/hlsl: Move object type checks to methods handlers. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/206

2 5

[PATCH v3 0/2] MR208: vkd3d-shader/hlsl: Fix liveness of temps within loops.
by Francisco Casas (＠fcasas) 24 May '23

24 May '23

Otherwise, it is possible that the register used by the temp is overridden by a subsequent instruction within the same loop. -- v3: vkd3d-shader/hlsl: Extend the liveness of nodes produced outside loops. tests: Add minimal tests for temp lifetimes within a loop. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/208

3 3

[PATCH v2 0/3] MR2888: wine{alsa,coreaudio,oss}: Move stream mode and period/duration initialization logic into unixlib.
by Davide Beatrici (＠davidebeatrici) 24 May '23

24 May '23

-- v2: wineoss: Move stream mode and period/duration initialization logic into unixlib. winecoreaudio: Move stream mode and period/duration initialization logic into unixlib. winealsa: Move stream mode and period/duration initialization logic into unixlib. https://gitlab.winehq.org/wine/wine/-/merge_requests/2888

3 8

[PATCH 0/1] MR2890: nsiproxy.sys: Detect PPP interface type from flags on Linux.
by Paul Gofman (＠gofman) 24 May '23

24 May '23

Unfortunately VPN interfaces I am observing here don't expose any definite type in ifr_hwaddr.sa_data (having ARPHRD_NONE). But the flags from SIOCGIFFLAGS have IFF_POINTOPOINT for such interfaces, so it is probably nothing wrong in guessing the iface type as PPP if the flag is set. Fixes Creativerse hanging on creating local game when there is a VPN interface. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2890

4 5

2025

2024

2023

2022

wine-gitlab May 2023