February 2024 - Wine-GitLab

[PATCH v4 0/1] MR364: kernel32/tests: Test module refcounting with forwarded exports.
by Jinoh Kang (＠iamahuman) Feb. 19, 2024

Feb. 19, 2024

Test module references created by resolving forwarded exports. The following diagram explains what happens in bug #52094 under the hood: ```mermaid graph TB subgraph state_00["Initial"] direction LR s00_ida[ida64.dll] ~~~ s00_idapy[idapython64.dll] ~~~ s00_py3[python3.dll] -. "(forwards to)" .-> s00_py311[python311.dll] end state_00 -. "1. <code>LoadLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_01 subgraph state_01["python311.dll loaded"] direction LR s01_ida[ida64.dll] ~~~ s01_idapy[idapython64.dll] ~~~ s01_py3[python3.dll] -. "(forwards to)" .-> s01_py311[python311.dll] s01_ida -- "dynamic ref" --> s01_py311 end state_01 -. "2. <code>LoadLibrary("</code>idapython64.dll<code>")</code>" .-> state_02 subgraph state_02["idapython64.dll loaded"] direction LR s02_ida[ida64.dll] -- "dynamic ref" --> s02_idapy[idapython64.dll] -- "static ref" --> s02_py3[python3.dll] -. "(forwards to)" .-> s02_py311[python311.dll] s02_ida -- "dynamic ref" --> s02_py311 s02_idapy -- "static forwarded ref" --> s02_py311 end state_02 -. "3. <code>FreeLibrary("</code>configured Python version (e.g., python311.dll)<code>")</code>" .-> state_03 subgraph state_03["python311.dll reference removed"] direction LR style s03_py311 color:#f00,stroke:#f00 s03_ida[ida64.dll] -- "dynamic ref" --> s03_idapy[idapython64.dll] -- "static ref" --> s03_py3[python3.dll] -. "(forwards to)" .-> s03_py311[python311.dll] s03_ida -. "<del>dynamic ref (deleted)</del>" .-> s03_py311 s03_idapy -- "static forwarded ref" --> s03_py311 end ``` On Windows, the static forwarded ref keeps `python3.dll` from being unloaded; however, Wine is missing this behavior, causing it to be unloaded and cause segfault immediately (since further initialization happens just after FreeLibrary). The tests aim to reproduce this condition. -- v4: kernel32/tests: Test module refcounting with forwarded exports. https://gitlab.winehq.org/wine/wine/-/merge_requests/364

4 10

[PATCH v6 0/3] MR3876: Zero-width character handling in GetTextExtentExPoint[AWI]
by Torge Matthies (＠tmatthies) Feb. 19, 2024

Feb. 19, 2024

Certain characters are considered by GetTextExtentExPointA/W/I to have no width, even if they have a non-zero width and a shape in the font. This MR attempts to bring Wine's implementation of these functions closer to native behavior. One remaining difference is caused by GetGlyphIndicesA/W returning 0 instead of 0xffff for some characters, for some reason. This also affects the handling by GetTextExtentExPointA/W/I of affected characters. I have compared this with both Uniscribe and DWrite behavior and neither of them match this behavior, so it seems to be a peculiarity of these older functions. Remaining differences are probably caused by differences in the fallback fonts used when a character is missing from the selected font. Notably, on my system there doesn't seem to be a fallback font for `\t`/`\n`/`\r` that marks those characters as zero-width, and since applications are likely to depend on the metrics of those characters (I know of at least one), I have opted to explicitly make them zero-width in this MR, even though that is technically not what Windows does. -- v6: win32u: Handle glyphs that are marked by the font as zero-width in GetTextExtentExPoint[AWI]. win32u: Use maximum of (A, A+C, A+C+B) width for character fit test in GetTextExtentExPoint[AWI]. gdi32/tests: Add test for width of carriage return and line feed. https://gitlab.winehq.org/wine/wine/-/merge_requests/3876

3 4

Re: [PATCH v12 0/5] MR3572: mf: Make session_get_node_object() more robust.
by Zhiyi Zhang (＠zhiyi) Feb. 19, 2024

Feb. 19, 2024

On Mon Feb 19 09:21:14 2024 +0000, Rémi Bernon wrote: > Fwiw this, and more specifically the test in > 6b853a9354dfe62df838b255b4af33b423e74642, triggers an assertion in > threadpool. It somehow doesn't make the test report a failure but I > think it can cause some spurious failures like in > https://gitlab.winehq.org/rbernon/wine/-/jobs/56730#L1220 which doesn't > seem related to the H264 decoder changes from the corresponding MR. I will take a look. Thanks. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_61850

1 0

Re: [PATCH v12 0/5] MR3572: mf: Make session_get_node_object() more robust.
by Rémi Bernon Feb. 19, 2024

Feb. 19, 2024

Fwiw this, and more specifically the test in 6b853a9354dfe62df838b255b4af33b423e74642, triggers an assertion in threadpool. It somehow doesn't make the test report a failure but I think it can cause some spurious failures like in https://gitlab.winehq.org/rbernon/wine/-/jobs/56730#L1220 which doesn't seem related to the H264 decoder changes from the corresponding MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/3572#note_61846

1 0

Re: [PATCH v2 0/2] MR5080: oleaut32: Use scientific notation only for larger numbers in VarBstrFromR[48].
by Rémi Bernon Feb. 19, 2024

Feb. 19, 2024

Fwiw, this broke the tests on Linux (the pipeline was already failing here). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5080#note_61845

1 0

[PATCH 0/1] MR5109: include: Annotate NdrGetBuffer with __WINE_(ALLOC_SIZE|MALLOC).
by Alex Henrie (＠alexhenrie) Feb. 19, 2024

Feb. 19, 2024

It would be nice to annotate it with __WINE_DEALLOC(NdrFreeBuffer) too, but that causes a bunch of spurious -Wfree-nonheap-object warnings. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5109

2 1

[PATCH 0/5] MR5108: win32u: Don't assume that the primary adapter is always first.
by Rémi Bernon Feb. 19, 2024

Feb. 19, 2024

In preparation for some virtual desktop refactor for display mode emulation (https://gitlab.winehq.org/wine/wine/-/merge_requests/5057) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/5108

1 5

[PATCH v14 0/191] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) Feb. 19, 2024

Feb. 19, 2024

-- v14: vkd3d-shader/dxil: Bitcast the result of image atomic ops if necessary. vkd3d-shader/dxil: Emit an error for mesh, amplification and library shaders. vkd3d-shader/dxil: Support SV_ShadingRate. vkd3d-shader/dxil: Support the barycentrics register type. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/648

1 0

[PATCH v13 0/187] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) Feb. 18, 2024

Feb. 18, 2024

-- v13: vkd3d-shader/spirv: Support 64-bit UAV atomics. vkd3d-shader/dxil: Implement DX intrinsic WaveQuadReadLaneAt. vkd3d-shader/dxil: Implement DX intrinsic WavePrefixOp. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/648

1 0

[PATCH v12 0/184] MR648: Draft: vkd3d-shader: [Test] SM 6.
by Conor McCarthy (＠cmccarthy) Feb. 18, 2024

Feb. 18, 2024

-- v12: vkd3d-shader/dxil: Ignore "llvm.lifetime.*" intrinsics. vkd3d-shader/dxil: Implement DX intrinsic AnnotateHandle. vkd3d-shader/dxil: Implement DX intrinsic CreateHandleFromBinding. This merge request has too many patches to be relayed via email. Please visit the URL below to see the contents of the merge request. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/648

1 0