November 2022 - Wine-gitlab

Re: [PATCH v2 0/1] MR1483: explorer: Put the calling convention inside the function pointer parentheses. - approved
by Alexandre Julliard (＠julliard) 22 Nov '22

22 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1483

1 0

Re: [PATCH v2 0/1] MR1484: kernel32/tests: Avoid using GCC's typeof extension. - approved
by Alexandre Julliard (＠julliard) 22 Nov '22

22 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1484

1 0

Re: [PATCH v2 0/1] MR1480: dinput/tests: Put the calling convention inside the function pointer parentheses. - approved
by Alexandre Julliard (＠julliard) 22 Nov '22

22 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1480

1 0

Re: [PATCH v2 0/1] MR1488: webservices: Remove unused function heap_realloc_zero. - approved
by Alexandre Julliard (＠julliard) 22 Nov '22

22 Nov '22

This merge request was approved by Alexandre Julliard. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1488

1 0

[PATCH 0/7] MR1490: comctl32: Use CRT allocation functions.
by Nikolay Sivov (＠nsivov) 22 Nov '22

22 Nov '22

Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com> -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1490

4 9

[PATCH 0/1] MR1509: ntdll: Make init_builtin_dll return a value on FreeBSD
by Gerald Pfeifer (＠gerald) 22 Nov '22

22 Nov '22

With commit 1d1690782b167f3ea24990c260665f71a0e70d1c init_builtin_dll gained a return value, alas the FreeBSD-specific code (under #ifdef) was not adjusted and still returned void. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1509

2 1

[PATCH v2 0/1] MR1442: Draft: vbscript: Handle CP_UTF8 in Chr()/Asc().
by Nikolay Sivov (＠nsivov) 22 Nov '22

22 Nov '22

-- v2: vbscript: Handle CP_UTF8 in Chr()/Asc(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1442

4 3

[PATCH v14 0/7] MR1297: gdiplus: Add CustomLineCap implementation (including displaying).
by Bartosz Kosiorek (＠gang65) 22 Nov '22

22 Nov '22

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45273 -- v14: gdiplus: Add GdipSetCustomLineCapStrokeCaps implementation and usage. gdiplus: fix shape of CustomLineCap created by GdipCreateAdjustableArrowCap. gdiplus: Add support for widen path with GpCustomLineCap. gdiplus: use GpPointF for drawing in widen_closed_figure https://gitlab.winehq.org/wine/wine/-/merge_requests/1297

3 8

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

22 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. -- v8: imm32: Prevent deadlock on unload https://gitlab.winehq.org/wine/wine/-/merge_requests/1456

3 5

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

22 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. -- v7: imm32: Prevent deadlock on unload https://gitlab.winehq.org/wine/wine/-/merge_requests/1456

3 4