- Wine-GitLab - list.winehq.org

[PATCH 0/1] MR2187: imm32: Disable cross thread access for ImmSetCompositionString().
by Paul Gofman (＠gofman) Feb. 14, 2023

Feb. 14, 2023

Fixes deadlock in a game. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2187

2 1

[PATCH v2 0/3] MR2107: dxgi: Implement IDXGIResource::GetUsage().
by Zebediah Figura (＠zfigura) Feb. 14, 2023

Feb. 14, 2023

-- v2: d3d11: Expand tests for IDXGIResource. dxgi: Implement IDXGIResource::GetUsage(). wined3d: Introduce wined3d_texture_get_swapchain(). https://gitlab.winehq.org/wine/wine/-/merge_requests/2107

3 4

[PATCH v10 0/2] MR821: Replace obsolete RtlUniform tests that no longer work (currently skipped) since Windows Vista; update RtlUniform impl.
by Jinoh Kang (＠iamahuman) Feb. 14, 2023

Feb. 14, 2023

Today, test_RtlUniform() skips almost all of its tests on Windows Vista or later. The skipped tests only succeed in Windows XP, and fail on Windows Vista or later. This is because RtlUniform()'s behavior has changed, presumably due to a bug fix shipped in Windows Vista. It appears that RtlUniform, a linear congruential generator, could overflow before computing the modulo in WindoWs XP. This is no longer the case in Windows Vista or later. Meanwhile, we no longer support Windows XP behavior and thus do not test for it regularly; therefore, the tests are obsolete as of 2023. Remove obsolete tests that no longer work with any of the Windows versions actively tested by WineHQ (as of 2023), and replace them with updated tests that works in the Windows versions from Vista up to 10. Also, fix Wine's RtlUniform() to match the new behavior accordingly. -- v10: ntdll: Fix integer overflow in RtlUniform. https://gitlab.winehq.org/wine/wine/-/merge_requests/821

3 4

[PATCH v6 0/1] MR2175: oleaut32: fix VarAbs function for BSTR with positive values
by Jason Millard (＠jsm174) Feb. 14, 2023

Feb. 14, 2023

While working in vbscript, I noticed abs on a `BSTR` value with a positive number would come back with an invalid value. Given the following script: ``` Dim x x = "30000" Debug.Print "x" & "=" & abs(x) ``` Outputs: ``` Script.Print 'x=3.08221696253945E-314' ``` After debugging, `pVarIn` gets the R8 value but is never shallow copied into `pVarOut`. I'm not sure how to write a test case in `oleaut32`, so I included a test case in `vbscript`. -- v6: oleaut32: fix VarAbs function for BSTR with positive values https://gitlab.winehq.org/wine/wine/-/merge_requests/2175

3 3

Re: [PATCH v3 0/4] MR2072: d3d pixel format tests - approved
by Jan Sikorski (＠jsikorski) Feb. 14, 2023

Feb. 14, 2023

This merge request was approved by Jan Sikorski. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2072

1 0

Re: [PATCH v9 0/2] MR821: Replace obsolete RtlUniform tests that no longer work (currently skipped) since Windows Vista; update RtlUniform impl.
by Jinoh Kang (＠iamahuman) Feb. 14, 2023

Feb. 14, 2023

On Tue Feb 14 14:55:14 2023 +0000, Huw Davies wrote: > The optimization below doesn't seem to be worth it. On x86_64 I > couldn't measure a difference between the algorithm above and the > optimization below. On i386, while the optimization was about 10% > faster, the algorithm above matched native's performance, so there seems > little point in adding the complexity. > If you really need the optimization, you could potentially introduce it > in a later MR. It was an attempt to implement it in an unusual way so that there was low likelihood that the algorithm matched any particular existing implementation. I'll switch to the modulo one anyway. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/821#note_24060

1 0

Re: [PATCH v9 0/2] MR821: Replace obsolete RtlUniform tests that no longer work (currently skipped) since Windows Vista; update RtlUniform impl.
by Huw Davies (＠huw) Feb. 14, 2023

Feb. 14, 2023

Huw Davies (@huw) commented about dlls/ntdll/rtl.c: > - result = *seed * 0xffffffed + 0x7fffffc3; > - if (result == 0xffffffff || result == 0x7ffffffe) { > - result = (result + 2) & MAXLONG; > - } else if (result == 0x7fffffff) { > - result = 0; > - } else if ((result & 0x80000000) == 0) { > - result = result + (~result & 1); > - } else { > - result = (result + (result & 1)) & MAXLONG; > - } /* if */ > + /* The algorithm below is equivalent to the following expression: > + * > + * result = ((ULONGLONG)*seed * 0x7fffffed + 0x7fffffc3) % 0x7fffffff; > + * return (*seed = result); > + */ > + The optimization below doesn't seem to be worth it. On x86_64 I couldn't measure a difference between the algorithm above and the optimization below. On i386, while the optimization was about 10% faster, the algorithm above matched native's performance, so there seems little point in adding the complexity. If you really need the optimization, you could potentially introduce it in a later MR. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/821#note_24059

1 0

[PATCH v2 0/3] MR2173: user32/tests: Fix WM_CHAR tests to use the input codepage.
by Akihiro Sagawa (＠sgwaki) Feb. 14, 2023

Feb. 14, 2023

User32 uses the input codepage in Unicode edit control. However, it uses ANSI codepage, i.e. CP_ACP, in ANSI version control. Comctl32 is different from user32. It doesn't have A-W duality and uses the input codepage in it. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54424 -- v2: comctl32/tests: Add WM_CHAR tests for edit control. user32/edit: Use CP_ACP for WM_CHAR convresion in ANSI version control. user32/tests: Fix WM_CHAR tests to use the input codepage. https://gitlab.winehq.org/wine/wine/-/merge_requests/2173

3 4

[PATCH 0/3] MR2173: user32/tests: Fix WM_CHAR tests to use the input codepage.
by Akihiro Sagawa (＠sgwaki) Feb. 14, 2023

Feb. 14, 2023

User32 uses the input codepage in Unicode edit control. However, it uses ANSI codepage, i.e. CP_ACP, in ANSI version control. Comctl32 is different from user32. It uses the input codepage in both ANSI and Unicode edit controls. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54424 -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2173

3 5

[PATCH 0/5] MR2186: Fix EnumProcessModules.
by eric pouech (＠epo) Feb. 14, 2023

Feb. 14, 2023

This serie is to move Wine's implementation of EnumProcessModules closer to Windows' behavior. Wine's current implementation is broken for a wow64 process enumerated from a 64bit bit process: - it returns the list of 32bit modules, while Windows returns the main module (32bit) and the 64bit modules (in wow64 process). This series: - adds tests to demonstrate that discrepancy - fix all caller's to EnumProcessModules in Wine source tree which require the 32bit bit modules (thanks to EnumProcessModulesEx) - fortunately, a couple of callers only require the first (main) module and don't need to be changed. - re-implement EnumProcessModules on top of EnumProcessModulesEx (to mimic Window's results) - shows also that Wine's implementation returns loaded modules from a different directory than Windows. Also tested on Win10, the returned paths from EnumProcessModules+GetModuleFileNameEx are the same as the ones stored in LDR_DATA. So, there's still more work to do after this serie: - with loader's path for wow64 processes - fix dbghelp to handle the conversions: information from EnumProcessModules, debug events reports from system32, while dbghelp (SymEnumerateModules, SymRefreshModules and the like) report from syswow64! (except ntdll) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/2186

2 5