- Wine-gitlab - list.winehq.org

[PATCH v11 0/2] MR841: ntoskrnl.exe: processor change callback stubs
by Etaash Mathamsetty (＠etaash.mathamsetty) 21 Nov '22

21 Nov '22

required for mrac anti cheat -- v11: ntoskrnl.exe: Add KeDeregisterProcessorChangeCallback stub. ntoskrnl.exe: Add KeRegisterProcessorChangeCallback stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/841

3 3

[PATCH v10 0/2] MR841: ntoskrnl.exe: processor change callback stubs
by Etaash Mathamsetty (＠etaash.mathamsetty) 21 Nov '22

21 Nov '22

required for mrac anti cheat -- v10: ntoskrnl.exe: Add KeDeregisterProcessorChangeCallback stub. ntoskrnl.exe: Add KeRegisterProcessorChangeCallback stub. https://gitlab.winehq.org/wine/wine/-/merge_requests/841

3 3

Re: [PATCH v3 0/1] MR1456: imm32: Prevent deadlock on unload
by Fabian Maurer (＠DarkShadow44) 21 Nov '22

21 Nov '22

Sorry, forget about the last versions, I mistook where the WM_DESTROY is coming from. It's not coming from imm32 DllMain. That means it simply ignores the deinitialization... Sorry about that. This is a new approach that should also fix the issue, this time preventing the loader lock that causes the issue in the first place. Not 100% sure if that's the right way to go about it, though. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1456#note_16584

1 0

[PATCH v6 0/3] MR1343: windows.media: Add WinRT Closed Captioning interface.
by Mohamad Al-Jaf (＠maljaf) 21 Nov '22

21 Nov '22

This is my first time implementing an interface so thorough feedback would be appreciated. -- v6: windows.media: Implement IClosedCaptionPropertiesStatics interface. include/windowscontracts: Bump contractversion to 14. windows.media: Add stub DLL. https://gitlab.winehq.org/wine/wine/-/merge_requests/1343

3 7

[PATCH v2 0/1] MR1456: imm32: Prevent deadlock on unload
by Fabian Maurer (＠DarkShadow44) 20 Nov '22

20 Nov '22

We need to make sure all (important) cleanup is finished when we exit DllMain, otherwise we might already unload krnl386 and deadlock Since we can't have a synchronous DestroyWindow, use an extra message Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511 Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> Code flow is like follows: - DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread - acquire loader lock - send DLL_THREAD_DETACH to imm32 - - calls DestroyWindow on its window - - WM_DESTROY is handled asynchonously! - send DLL_THREAD_DETACH to krnl386.exe - - TASK_ExitTask - - try get win16 lock, is blocked by ime32 meanwhile, at ime32 - handles WM_DESTROY - already have win16 lock from user32 - __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy - LdrGetProcedureAddress (want CoRevokeInitializeSpy) - try get loader_lock, is blocked Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished. -- v2: imm32: Prevent deadlock on unload https://gitlab.winehq.org/wine/wine/-/merge_requests/1456

3 2

Re: [PATCH v2 0/1] MR1444: kernel32: Unstub MoveFileTransactedW, Use MoveFileWithProgressW
by James McDonnell (＠ElementalWarrior) 20 Nov '22

20 Nov '22

On Sat Nov 19 18:56:07 2022 +0000, Etaash Mathamsetty wrote: > instead of saving the return value to a temp variable and returning the > temp variable, I think you could moving the FIXME before the call and > just return MoveFileWithProgressA, thus removing the need of the variable I thought about it. But having the fixme after provides feedback in the event something goes wrong inside of MoveFile... Although maybe that is no with the memory allocation thats going to be held onto for the life the the call. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1444#note_16564

1 0

[PATCH 0/1] MR1456: imm32: Prevent deadlock on unload
by Fabian Maurer (＠DarkShadow44) 20 Nov '22

20 Nov '22

We need to make sure all (important) cleanup is finished when we exit DllMain, otherwise we might already unload krnl386 and deadlock Since we can't have a synchronous DestroyWindow, use an extra message Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52511 Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> Code flow is like follows: - DOSVM_Exit -> RtlExitUserThread -> LdrShutdownThread - acquire loader lock - send DLL_THREAD_DETACH to imm32 - - calls DestroyWindow on its window - - WM_DESTROY is handled asynchonously! - send DLL_THREAD_DETACH to krnl386.exe - - TASK_ExitTask - - try get win16 lock, is blocked by ime32 meanwhile, at ime32 - handles WM_DESTROY - already have win16 lock from user32 - __wine_ime_wnd_proc (WM_DESTROY) -> imm_couninit_thread -> CoRevokeInitializeSpy - LdrGetProcedureAddress (want CoRevokeInitializeSpy) - try get loader_lock, is blocked Solution is to wait in ime32 DllMain until the cleanup as happened, aka CoRevokeInitializeSpy has finished. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1456

3 3

[PATCH 0/1] MR1455: dinput: Wait on event instead of thread on stop
by Fabian Maurer (＠DarkShadow44) 20 Nov '22

20 Nov '22

Since we stop the thread in DllMain, we always haev the loaderlock. Thread shutdown also requires the loader lock, so we will always time out So just wait until all cleanup is done, the thread itself can exit later Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52314 Signed-off-by: Fabian Maurer <dark.shadow4(a)web.de> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1455

3 2

[PATCH v2 0/1] MR1451: kernelbase: Add SetProcessInformation().
by Nikolay Sivov (＠nsivov) 20 Nov '22

20 Nov '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53954 Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- v2: kernelbase: Add SetProcessInformation(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1451

2 1

[PATCH v2 0/2] MR1448: hid: parser and HidP_SetUsageValue fix
by Matthew Tran (＠0e4ef622) 20 Nov '22

20 Nov '22

This fixes two things: * HID report descriptor parser enum for local items. Close inspection of page 40 of [Device Class Definition for HID 1.11](https://www.usb.org/document-library/device-class-definition-hid-111) reveals a jump between Designator Maximum (0101) and String Index (0111). This caused a controller of mine to not get recognized. * HidP_SetUsageValue for items that define multiple controls (with Report Count > 1). Attempting to set one value would result in HIDP_STATUS_BUFFER_TOO_SMALL. -- v2: hid: Fix HidP_SetUsageValue for usage ranges https://gitlab.winehq.org/wine/wine/-/merge_requests/1448

4 4