November 2022 - Wine-GitLab

[PATCH v11 0/6] MR42: vkd3d-shader/hlsl: Some fixes.
by Francisco Casas (＠fcasas) Nov. 9, 2022

Nov. 9, 2022

A mix of a miscellaneous fixes: * Fixes to failed asserts I have stumbled upon when implementing other features. * Checks required for properly supporting object components. * A couple of code improvements. -- v11: vkd3d-shader/hlsl: Use reg_size as component count when allocating a single register. vkd3d-shader/hlsl: Use the base type of the array elements in write_sm1_type(). vkd3d-shader/hlsl: Validate that statics don't contain both resources and numerics. vkd3d-shader/hlsl: Validate that extern structs don't contain objects SM < 5. vkd3d-shader/hlsl: Don't allocate object types as constant registers. vkd3d-shader/hlsl: Properly free new store node memory if init_deref() fails. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42

4 8

[PATCH v5 0/6] MR1025: ntdll: Support memory address requirements in NtAllocateVirtualMemoryEx()
by Paul Gofman (＠gofman) Nov. 9, 2022

Nov. 9, 2022

Various notes: - LowestStartingAddress is still unsupported; - Patch 5 ("wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent") is fixing existing WOW issue: NtAllocateVirtualMemoryEx() called from wow64 currently does not constraing the allocation to 32 bit address space (wow64_NtAllocateVirtualMemory() passes zero_bits for that). - I initially thought of using a single inter process APC but added a different one due to zero_bits handling which is easier to convert in the target process. -- v5: wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent. wow64: Support MEM_ADDRESS_REQUIREMENTS in wow64_NtAllocateVirtualMemoryEx(). ntdll/tests: Add tests for memory address requiements. ntdll: Support HighestEndingAddress in NtAllocateVirtualMemoryEx(). ntdll: Factor out allocate_virtual_memory(). ntdll: Pass limit instead of zero_bits to map_view(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1025

2 7

[PATCH v4 0/8] MR1025: ntdll: Support memory address requirements in NtAllocateVirtualMemoryEx()
by Paul Gofman (＠gofman) Nov. 9, 2022

Nov. 9, 2022

Various notes: - LowestStartingAddress is still unsupported; - Patch 5 ("wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent") is fixing existing WOW issue: NtAllocateVirtualMemoryEx() called from wow64 currently does not constraing the allocation to 32 bit address space (wow64_NtAllocateVirtualMemory() passes zero_bits for that). - I initially thought of using a single inter process APC but added a different one due to zero_bits handling which is easier to convert in the target process. -- v4: ntdll: Support specified alignment in NtAllocateVirtualMemoryEx(). ntdll: Pass alignemnt mask to map_view(). wow64: Set HighestEndingAddress in wow64_NtAllocateVirtualMemoryEx() if it is absent. wow64: Support MEM_ADDRESS_REQUIREMENTS in wow64_NtAllocateVirtualMemoryEx(). ntdll/tests: Add tests for memory address requiements. ntdll: Support HighestEndingAddress in NtAllocateVirtualMemoryEx(). ntdll: Factor out allocate_virtual_memory(). ntdll: Pass limit instead of zero_bits to map_view(). https://gitlab.winehq.org/wine/wine/-/merge_requests/1025

5 18

[PATCH v5 0/4] MR1297: Draft: gdiplus: Add GdipSetCustomLineCapBaseCap implementation.
by Bartosz Kosiorek (＠gang65) Nov. 9, 2022

Nov. 9, 2022

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=45273 -- v5: gdiplus: Add support for widen path with GpCustomLineCap. https://gitlab.winehq.org/wine/wine/-/merge_requests/1297

2 4

[PATCH v10 0/6] MR42: vkd3d-shader/hlsl: Some fixes.
by Francisco Casas (＠fcasas) Nov. 9, 2022

Nov. 9, 2022

A mix of a miscellaneous fixes: * Fixes to failed asserts I have stumbled upon when implementing other features. * Checks required for properly supporting object components. * A couple of code improvements. -- v10: vkd3d-shader/hlsl: Use reg_size as component count when allocating a single register. vkd3d-shader/hlsl: Use the base type of the array elements in write_sm1_type(). vkd3d-shader/hlsl: Validate that statics don't contain both resources and numerics. vkd3d-shader/hlsl: Validate that extern structs don't contain objects SM < 5. vkd3d-shader/hlsl: Don't allocate object types as constant registers. vkd3d-shader/hlsl: Properly free new store node memory if init_deref() fails. https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42

2 7

[PATCH 0/1] MR1318: ntdll: Write ret_len with the right size in user_mode_callback_return on arm64
by Martin Storsjö Nov. 9, 2022

Nov. 9, 2022

This fixes a regression since 4069a8b384c15a90a7af66636ec5650eeb53b391. This is the same fix as in !1308, but for arm64. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1318

2 2

Re: [PATCH v4 0/2] MR352: cmd: Don't loop infinitely on NUL.
by Arek Hiler (＠ivyl) Nov. 9, 2022

Nov. 9, 2022

Just a rebase because it was sitting here for quite a while. I've included your changes from the linked bug the previous time. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/352#note_13858

1 0

[PATCH 0/1] MR1308: ntdll: Fix incorrectly sized mov in user_mode_callback_return.
by Torge Matthies (＠tmatthies) Nov. 9, 2022

Nov. 9, 2022

This caused non-interactible windows in my Wine builds, where in win32u `dispatch_win_proc_params` got inlined into `call_window_proc` and this mov overwrote the lower 32 bits of `result`, causing WM_NCHITTEST messages to always return 0 or 0xffffffff00000000 (correct result was -1 in that case). -- https://gitlab.winehq.org/wine/wine/-/merge_requests/1308

3 2

[PATCH v3 0/4] MR1088: ntdll: Avoid calling pthread_exit on thread exit.
by Rémi Bernon Nov. 9, 2022

Nov. 9, 2022

Using a dedicated exit jmpbuf and removing the need for assembly routines. When Wine handles an exception in unix code, we return to user mode by jumping to the last syscall frame. This can leave some pthread cancel cleanups registered, in the pthread internal linked list, and at the same time later overwrite the stack frame they were registered for. In the same way, jumping to the exit frame on thread exit or abort, can also leave some cleanup handlers registered for invalid stack frames. Depending on the implementation, calling pthread_exit will cause all the registered pthread cleanup handlers to be called, possibly jumping back to now overwritten stack frames and causing segmentation faults. Exiting a pthread normally, by returning from its procedure, or calling exit(0) for the main thread doesn't run pthread_exit and doesn't call cleanup handlers, avoiding that situation. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213 ### Additional note: For robustness, we should probably try to execute these cleanup handlers when unwinding the stack frames, as we would otherwise leave pthread objects in a potential problematic state (like a mutex locked, etc). It is however hard to do so when the handlers are registered from some C code: pthread C implementation is done by calling some internal pthread functions to register the handlers, and they aren't registered as standard unwind handlers. Only pthread_cancel and pthread_exit can unwind and call / unregister the C handlers, but interrupting that procedure, for instance calling setjmp / longjmp from withing our own handler isn't supported. >From C++ code, pthread cleanup handlers are registered through C++ class constructors / destructors, and it would then be possible to partially unwind and call them at the same time. -- v3: ntdll: Remove unnecessary signal_start_thread register spilling. ntdll: Remove unnecessary arch specific exit frame pointer. ntdll: Avoid calling pthread_exit on thread exit. ntdll: Create a pthread for the main thread. https://gitlab.winehq.org/wine/wine/-/merge_requests/1088

3 14

[PATCH v3 0/3] MR1302: wow64: Handle regions extending pass the address limit in NtQueryVirtualMemory.
by Tim Clem (＠tclem) Nov. 9, 2022

Nov. 9, 2022

There are regions of virtual memory that start below the WoW user address limit but end beyond it (e.g. a large empty region between the end of 32-bit allocations and 64-bit ntdll). When queried from WoW via `NtQueryVirtualMemory(MemoryBasicInformation)`, the returned struct for such a region will have `BaseAddress + RegionSize` past the highest user address (or even worse - it may overflow 32 bits). These patches make WoW `NtQueryVirtualMemory` report a truncated size for such regions, so that they appear to end exactly at the highest user address. This fixes programs that, e.g., walk their address space using iterated calls to `VirtualQuery`. Also, make `MemoryRegionInformation` queries return `STATUS_INVALID_PARAMETER` when passed an address beyond the user address limit, like `MemoryBasicInformation` already does. -- v3: wow64: Truncate too-large regions from NtQueryVirtualMemory(MemoryRegionInformation). wow64: Return error from NtQueryVirtualMemory(MemoryRegionInformation) for a too-large address. wow64: Truncate too-large regions from NtQueryVirtualMemory(MemoryBasicInformation). https://gitlab.winehq.org/wine/wine/-/merge_requests/1302

2 3