June 2025 - Wine-gitlab - list.winehq.org

Re: [PATCH v10 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Zhiyi Zhang (＠zhiyi) 18 Jun '25

18 Jun '25

On Wed Jun 18 08:29:18 2025 +0000, Nikolay Sivov wrote: > This will change behavior for all the tests. We can create this file > dynamically as an external manifest, then restart as a child process. Right. That would be better. Let's do that. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7540#note_106999

1 0

Re: [PATCH v10 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Nikolay Sivov (＠nsivov) 18 Jun '25

18 Jun '25

On Wed Jun 18 08:27:27 2025 +0000, Zhiyi Zhang wrote: > I see. In that case, you can leave it and keep the longPathAware > manifest in the kernel32 test resource. This will change behavior for all the tests. We can create this file dynamically as an external manifest, then restart as a child process. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7540#note_106998

1 0

Re: [PATCH v10 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Zhiyi Zhang (＠zhiyi) 18 Jun '25

18 Jun '25

On Wed Jun 18 08:25:18 2025 +0000, Yongjie Yao wrote: > When testing on windows 11, handle=CreateActCtxW() -> > ActivateActCtx(handle) -> QueryActCtxSettingsW(handle), the value of the > longPathAware is true, but CopyFileExA still can't support long path. > When I create a file with kernel32_test.exe.manifest as filename and > test again, CopyFileExA can support long path. So I guess it is just > checked at process startup. I see. In that case, you can leave it and keep the longPathAware manifest in the kernel32 test resource. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7540#note_106997

1 0

[PATCH 0/1] MR8359: include: Add APP_LOCAL_DEVICE_ID definition.
by Rémi Bernon 18 Jun '25

18 Jun '25

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

1 1

Re: [PATCH v10 0/5] MR7540: kernel32/tests: Add tests for maximum path length limitation.
by Yongjie Yao (＠yaoyongjie) 18 Jun '25

18 Jun '25

On Mon Jun 16 10:56:00 2025 +0000, Zhiyi Zhang wrote: > Please test if activating the longPathAware manifest dynamically sets > IsLongPathAwareProcess, or if it is just checked at process startup. > MSDN says the LongPathsEnabled registry value is cached. However, it > doesn't say if the manifest is cached. This could be a local test. When testing on windows 11, handle=CreateActCtxW() -> ActivateActCtx(handle) -> QueryActCtxSettingsW(handle), the value of the longPathAware is true, but CopyFileExA still can't support long path. When I create a file with kernel32_test.exe.manifest and test again, CopyFileExA can support long path. So I guess it is just checked at process startup. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/7540#note_106996

1 0

[PATCH v3 0/6] MR8326: ntdll: Implement RtlActivateActivationContextUnsafeFast().
by Zhiyi Zhang (＠zhiyi) 18 Jun '25

18 Jun '25

For React Native. -- v3: kernel32/tests: Add tests for RtlActivateActivationContextUnsafe() and RtlDeactivateActivationContextUnsafeFast(). ntdll: Implement RtlDeactivateActivationContextUnsafeFast(). ntdll: Implement RtlActivateActivationContextUnsafeFast(). ntdll: Set and check 0x8 flag for activation context stack frames. kernel32/tests: Add tests for normal activation context stack frame flags. ntdll: Use explicit ACTIVATION_CONTEXT type instead of HANDLE. https://gitlab.winehq.org/wine/wine/-/merge_requests/8326

2 7

[PATCH 0/1] MR8350: crypt32: Handle missing attributes in CDecodeSignedMsg_GetParam.
by Yuxuan Shui (＠yshui) 18 Jun '25

18 Jun '25

* * * While investigating another problem, I found we are handling empty attributes list differently compared native. But the actual problem is this, shouldn't `CRYPT_SizeOfAttributes` add `sizeof(CRYPT_ATTRIBUTES)` to `size`? Basically we return `size == 0` when the attributes list is empty, so the caller allocates zero bytes and call `GetParam` again, and we write out-of-bound trying to `out->cAttrs = in->cAttrs` in `CRYPT_ConstructAttributes`. (Of course with this MR this problem no longer show up, but the question still stands.) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8350

4 3

[PATCH 0/1] MR8128: winex11.drv: Reconfigure window even if the new rectangle equals to the old one.
by Zhiyi Zhang (＠zhiyi) 18 Jun '25

18 Jun '25

CW* masks in window_set_config() are from comparing against the old rect from data->pending_state.rect, not the actual X11 window rectangle. So it's still possible that after removing __NET_WM_STATE_FULLSCREEN, WM moves the window behind Wine's back. Then window_set_config() calculates CW* masks and calls XReconfigureWMWindow(), assuming the old rect is still the actual X11 window rect. As the result, some rectangle updates might be missed. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8128

3 5

[PATCH 0/6] MR8357: win32u: Allocate GL drawables on behalf of the drivers.
by Rémi Bernon 18 Jun '25

18 Jun '25

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

1 6

Re: [PATCH v2 0/1] MR8316: shell32/tests: Add missing double null termination in shlfileop.
by Rémi Bernon 18 Jun '25

18 Jun '25

This broke the tests on windows: https://test.winehq.org/data/patterns.html#shell32:shlfileop -- https://gitlab.winehq.org/wine/wine/-/merge_requests/8316#note_106983

1 0