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
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
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
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
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
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
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
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.
--
v8: 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.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/42
--
v2: winevulkan: Use generated thunks for VkPipelineCreationFeedback conversion.
winevulkan: Convert struct chain conversions for all structs that need it.
winevulkan: Use const types in conversion function declarations.
winevulkan: Use generated thunks for vkGetImageSparseMemoryRequirements(2) conversion.
winevulkan: Support pointer dynamic array lenghts.
winevulkan: Store parent in VkVariable.
winevulkan: Always fill output in fill_luid_property.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1303
I was watching some random YouTube stream and then heard a voice telling me to do this.
This can run wglgears on wow, though there's plenty of missing pieces which I don't have any idea how to fix (like buffer mapping, etc.). Opening it as a draft for now to show the whole thing, if it seems alright I'll send it in batches.
--
v4: opengl32: Implement wow64 thunks for glMapBuffer (et al.).
opengl32: Use manual win32 thunks for glMapBuffer (et al.).
opengl32: Implement wow64 thunks for GLsizeiptr/GLintptr arrays.
opengl32: Implement wow64 thunks for glFenceSync (et al.).
opengl32: Implement wow64 thunks for input pointer arrays.
opengl32: Implement wow64 thunk for wglGetPbufferDCARB.
opengl32: Implement wow64 thunk for wglCreatePbufferARB.
opengl32: Implement wow64 thunk for wglCreateContextAttribsARB.
opengl32: Implement wow64 thunk for wglMakeCurrent (et al.).
opengl32: Implement wow64 thunk for glGetString (et al.).
opengl32: Implement wow64 thunk for wglGetProcAddress.
opengl32: Generate stub wow64 params mapping.
opengl32: Manually write glPathGlyphIndexRangeNV wow64 thunk.
opengl32: Generate wow64 thunks.
opengl32: Use RtlSetLastWin32Error instead of SetLastError.
opengl32: Use msvcrt allocation functions.
opengl32: Build with msvcrt.
opengl32: Use ntdll registry functions to read disabled extensions.
opengl32: Avoid recursively entering WGL critical section.
opengl32: Split opengl_ext.h into private.h and unix_private.h.
opengl32: Use glReserved1[0] and glReserved1[1] for draw and read DCs.
opengl32: Avoid calling back the wglMakeCurrent win32 thunk.
This merge request has too many patches to be relayed via email.
Please visit the URL below to see the contents of the merge request.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1010