August 2022 - wine-gitlab

[PATCH 0/5] MR657: wined3d: Managed texture patches.
by Zebediah Figura (＠zfigura) 13 Sep '22

13 Sep '22

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

6 12

[PATCH 0/1] MR688: ntdll: Introduce "WINEWOW64" environment variable, to enable new WoW64 behavior.
by Davide Beatrici (＠davidebeatrici) 13 Sep '22

13 Sep '22

https://www.winehq.org/pipermail/wine-devel/2022-April/213620.html -- https://gitlab.winehq.org/wine/wine/-/merge_requests/688

7 10

[PATCH 0/5] MR502: winusb: Add WinUsb_Free stub.
by Mohamad Al-Jaf (＠maljaf) 12 Sep '22

12 Sep '22

The program REVELPROG_IS runs with this patchset. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52677 Signed-off-by: Mohamad Al-Jaf <mohamadaljaf(a)gmail.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/502

3 10

[PATCH 0/3] MR698: d2d1: Implement transform graph.
by Ziqing Hui (＠zhui) 08 Sep '22

08 Sep '22

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

3 9

[PATCH v2 0/8] MR695: winegstreamer: Initial fixes and refactor of the WM async reader.
by Rémi Bernon (＠rbernon) 06 Sep '22

06 Sep '22

This includes some fixes for obvious mistakes as well as initial cleanup of the WM async reader, in preparation for implementing proper threading support. I'm planning on doing some more refactoring first, ultimately implementing the async reader on top of the sync reader, and removing the need for a private interface. I've checked that it can indeed work on Windows too, and it'll make the code simpler overall. -- v2: winegstreamer: Query IWMReaderCallbackAdvanced interface in Open. winegstreamer: Avoid waiting for callback thread on allocation failure. winegstreamer: Release callback and context in async_reader_close. winegstreamer: Move open_stream / close_stream helpers around. winegstreamer: Leave async reader callback_cs on calloc error. winegstreamer: Leave WM reader CS on invalid output format. winegstreamer: Avoid leaking async ops on release or multiple close. winegstreamer: Rename async reader stream_thread to callback_thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/695

3 10

[PATCH v3 0/1] MR726: msvfw32: Use string comparison to determine class name equality.
by Alexandros Frantzis (＠afrantzis) 05 Sep '22

05 Sep '22

The current version of the code incorrectly assumes that the lpszClass member of CREATESTRUCT passed with WM_CREATE will point to the same memory used for the CreateWindowEx class name parameter, and uses a pointer comparison to check for class name equality. As a side effect of commit e41c255be6ba66d1eec7affe674b8cc7699226b8 "win32u: Use send_message_timeout for WM_CREATE and WM_NCCREATE" the CREATESTRUCT lpszClass member started pointing to different memory, breaking the current implementation of MCIWND_Create(). This commit fixes the problem by performing a proper, case-insensitive string comparison to determine class name equality. Wine-bug: https://bugs.winehq.org/show_bug.cgi?id=53578 -- v3: msvfw32: Use string comparison to determine class name equality. https://gitlab.winehq.org/wine/wine/-/merge_requests/726

4 14

[PATCH 0/3] MR10: Move Wine headers to a wine/ subdirectory
by Alexandre Julliard (＠julliard) 03 Sep '22

03 Sep '22

This reduces the diff with the Wine bundled version. It should also make it clearer that these are Wine headers that should ideally be changed upstream first and then re-imported. -- https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/10

4 11

[PATCH 0/1] MR741: Draft: ntdll: Implement NtFlushProcessWriteBuffers.
by Torge Matthies (＠tmatthies) 02 Sep '22

02 Sep '22

Based on [a patch](https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.or… by Jinoh Kang (@iamahuman) from February 2022. I removed the need for the event object and implemented fast paths for Linux. On Linux 4.16+ `membarrier(MEMBARRIER_CMD_GLOBAL_EXPEDITED, ...)` is used. On x86 Linux <= 4.15 `madvise(..., MADV_DONTNEED)` is used, which sends IPIs to all cores causing them to do a memory barrier. On non-x86 Linux 4.3+ `membarrier(MEMBARRIER_CMD_SHARED, ...)` is used. On Linux <= 4.2 and on other platforms the fallback path using APCs is used. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/741

4 8

[PATCH v3 0/8] MR711: mf: Add some media session event tests for SetTopology and media type initialization.
by Rémi Bernon (＠rbernon) 02 Sep '22

02 Sep '22

-- v3: mf: Initialize output media types when binding session output nodes. mf/tests: Test that IMFMediaSession_SetTopology should set media types. mf/tests: Test some IMFMediaSession_SetTopology error cases. mf/tests: Test that IMFTopoLoader_Load doesn't call SetCurrentMediaType. mf/tests: Add helpers to wait and check media session events. mf/tests: Allocate test callbacks dynamically and check refcounts. mf/tests: Keep a presentation descriptor in the test source. mf/tests: Move and split some helper code around. https://gitlab.winehq.org/wine/wine/-/merge_requests/711

3 10

[PATCH v2 0/1] MR752: winecrt0: run C++ object destructors in DLL_PROCESS_DETACH.
by Kevin Puetz (＠puetzk) 01 Sep '22

01 Sep '22

Run C++ global/static destructors during DLL_PROCESS_DETACH while other other dllimport functions they may want to call are still viable. While windows imposes many restrictions on what may be done in such destructors (given that the run inside the loader lock), there are lots of legal and useful kernel32 functions like DestroyCriticalSection, DeleteAtom, TlsFree, etc that are both useful and legal. Currently this does not work for builtin modules because all the Win32 structures are discarded well before NtUnmapViewOfSection finally does the dlllose. Even for a winelib .dll.so module, it would be preferable for destructors to execute during process_detach (before wine tears down the MODREF and detaches dependant dlls), rather than be left until after the last NtUnmapViewOfSection (when we finally reach dlclose) Therefore, winegcc now always uses the DllMainCRTStartup entry point unless you specify your own --entry=func. Previously it did this only for PE modules using msvcrt. Making this default consistent matches cl.exe, which also always defaults to _DllMainCRTStartup unless overridden by /entry:foo https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symb… The ELF version of winecrt0.a now provides a DllMainCRTStartup which, per the Itanium ABI that is in practice what is used by gcc and clang, performs this this destruction by calling __cxa_finalize(&__dso_handle).. This libc function is required to be idempotent, so it's OK that dlclose still calls it again later (there will just be no further work to do). Multiple calls to __cxa_finalize shall not result in calling termination function entries multiple times; the implementation may either remove entries or mark them finished. https://itanium-cxx-abi.github.io/cxx-abi/abi.html#dso-dtor-runtime-api This has two main effects; it moves ELF destructors earlier (before imports are unmapped), and it moves them inside the Nt loader lock. Being earlier was the intended goal, and moving them inside the lock seems fine. Any Win32 API calls in destructors are just being subjected to the same lock hierarchy rules as usual on windows (MSVC also runs destructors from DllMainCrtStartup) https://docs.microsoft.com/en-us/cpp/build/run-time-library-behavior?view=m… And any purely-ELF destructors that happen to also run earlier should never call functions exported from wine (and thus don't care about ntdll's locks). -- v2: winecrt0: run C++ object destructors in DLL_PROCESS_DETACH. https://gitlab.winehq.org/wine/wine/-/merge_requests/752

2 4

2025

2024

2023

2022

wine-gitlab August 2022