April 2023 - wine-gitlab

[PATCH 0/1] MR2591: include: _InterlockedExchangePointer and _InterlockedCompareExchangePointer...
by Stefan Dösinger (＠stefan) 05 Apr '23

05 Apr '23

include: _InterlockedExchangePointer and _InterlockedCompareExchangePointer are intrinsics in x86 msvc. I fixed this issue in ad05f33d67, but a40973f20 regressed this again. I was carrying a patch for quite a while, feeling dejavu. The msvc ver of 1900 is taken from Boost's interlocked.hpp, which matches MSVC 2015 (toolset version v140). Boost has a comment that claims that in msvc 2012 those functions were defined in intrin.h, but those defines are broken with Microsoft's winnt.h. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2591

3 2

[PATCH 0/1] MR2590: setupapi: Use CRT functions for memory allocation where possible.
by Alex Henrie (＠alexhenrie) 05 Apr '23

05 Apr '23

The big win here is getting rid of the reimplementation of wcsdup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2590

2 1

Re: [PATCH v2 0/10] MR2520: imm32: More tests and being selecting the IME from ImmLockIMC.
by Rémi Bernon (＠rbernon) 05 Apr '23

05 Apr '23

On Wed Apr 5 09:07:47 2023 +0000, Byeongsik Jeon wrote: > I tested a bit of code, it appears that fdwInit is also cached during > IME switching. Yeah I'm thinking that the entire `INPUTCONTEXT` is probably switched and kept cached, to avoid sharing its contents with a different IME. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_29002

1 0

Re: [PATCH v2 0/10] MR2520: imm32: More tests and being selecting the IME from ImmLockIMC.
by Byeongsik Jeon (＠bsjeon) 05 Apr '23

05 Apr '23

On Tue Apr 4 20:55:46 2023 +0000, Rémi Bernon wrote: > I guess maybe we'd have to clear the `fdwInit` flag before calling > `ImeSelect`? As far as I could see in the tests, the `fdwConversion` and > `fdwSentence` fields aren't modified by imm32 and left for the IME to > reset or not. It caused some spurious failures before > 7d03937abe899db810c983779f2566b94d787e8a with the fields keeping the > values from the default (MS) IME. > The tests also suggest that the values are cached between different IME > selections, unlike what Wine is currently doing. I tested a bit of code, it appears that fdwInit is also cached during IME switching. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_29001

1 0

[PATCH v3 0/5] MR2486: D3D12 swapchain latency semaphore fixes
by Giovanni Mascellani (＠giomasce) 05 Apr '23

05 Apr '23

-- v3: dxgi/tests: Test the frame latency waitable more thoroughly. https://gitlab.winehq.org/wine/wine/-/merge_requests/2486

4 8

[PATCH 0/1] MR2580: psapi: Test FS redirection wrt. EnumProcessModulesEx.
by eric pouech (＠epo) 05 Apr '23

05 Apr '23

To make it short: redirection has no impact on EnumProcessModules*() behavior. Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2580

2 2

[PATCH 0/6] MR2588: winex11: More XIM integration cleanup.
by Rémi Bernon (＠rbernon) 05 Apr '23

05 Apr '23

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

2 6

[PATCH 0/1] MR2581: winedump: Fix out of bounds access (spotted by GCC13).
by eric pouech (＠epo) 05 Apr '23

05 Apr '23

Anyway, it's a pain that we have to maintain two MS symbols demanglers (this one and the one in dlls/msvcrt). Signed-off-by: Eric Pouech <epouech(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2581

2 2

[PATCH 0/4] MR2564: winex11: Preparatory IME cleanup.
by Rémi Bernon (＠rbernon) 05 Apr '23

05 Apr '23

Same as https://gitlab.winehq.org/wine/wine/-/merge_requests/2563 but on winex11 side. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2564

2 5

Re: [PATCH v2 0/10] MR2520: imm32: More tests and being selecting the IME from ImmLockIMC.
by Rémi Bernon (＠rbernon) 04 Apr '23

04 Apr '23

On Tue Apr 4 20:42:52 2023 +0000, Byeongsik Jeon wrote: > On a recent review, I realized that I hadn't analyzed this issue > properly, and the problem had already been fixed by another commit. > https://gitlab.winehq.org/wine/wine/-/commit/f6ddd4ca86672fe2739ea7d1701511… > The cause of the problem was that the wrong parameter value(new_context) > was being passed to ImeSelect(). Because of this, ImeSelect() didn't > work properly and kept the fdwConversion value of the wrong value (fdwConversionCaps). > For example, in ImeSelect(), fdwConversion is initialized in the > following routine: > ``` > if ( !( lpIMC->fdwInit & INIT_CONVERSION ) ) > { > lpIMC->fdwConversion = IME_CMODE_NATIVE; > lpIMC->fdwInit |= INIT_CONVERSION; > } > ``` > If the IME follows this initialization routine, the values of > fdwConversion, fdwSentence set in ime_select_ime() will be ignored. I guess maybe we'd have to clear the `fdwInit` flag before calling `ImeSelect`? As far as I could see in the tests, the `fdwConversion` and `fdwSentence` fields aren't modified by imm32 and left for the IME to reset or not. It caused some spurious failures before 7d03937abe899db810c983779f2566b94d787e8a with the fields keeping the values from the default (MS) IME. The tests also suggest that the values are cached between different IME selections, unlike what Wine is currently doing. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2520#note_28984

1 0

2025

2024

2023

2022

wine-gitlab April 2023