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
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v12: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Do not store debug message callback in kernel callback table.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
user.exe16: Move kernel callbacks to wow_callbacks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1302
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v11: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
Fixes an issue in GenoPro where existing data would be cleared whenever you went to edit it
--
v2: riched20: Don't emit EN_CHANGE events during window creation
riched20: Add test for EN_CHANGE events during window creation
riched20: Move test class creation to a helper function
https://gitlab.winehq.org/wine/wine/-/merge_requests/1280
Multiprocessing Services is very deprecated, it's hard to know if that call is still necessary or not but safer to keep it in (and suppress the warning).
kIOMasterPortDefault was replaced with kIOMainPortDefault in Monterey but they're both equivalent to NULL/0 (using NULL triggers a warning though).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1300
--
v2: mshtml: Add SVG and XHTML document information to the registry.
include/mshtml: Add CLSID_XHTMLDocument and CLSID_SVGDocument.
include/mshtml: Add IDOMParser interface, dispinterface, and coclass.
jscript: Convert filetime to date properly using unsigned division.
mshtml: Use nsIDOMDocument instead of nsIDOMHTMLDocument where possible.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1296
This is slightly different from dlltool but I think it should be compatible. The transition is done by first replacing dlltool with its bugs, and fixing them in separate changes.
I based the ARM / AARCH64 implementation on the existing code around, but I have no idea if it is correct, and dlltool also doesn't include any delay load implementation for ARM.
--
v6: winebuild: Put the delay import descriptor in data section.
winebuild: Fix import hint value for symbols imported by name.
winebuild: Implement delay import lib generation without dlltool.
winebuild: Enable unwind tables by default in PE files.
winebuild: Implement import lib generation without dlltool.
winebuild: Introduce a new --without-dlltool winebuild flag.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1001
... and fix output buffer allocation on the way.
I am not aware of any app which strictly depends on the ApplyControlToken / connection shutdown to be implemented. Yet I saw a few games calling ApplyToken to perform the connection shutdown (similar to what is described in [1]). I once implemented that while debugging something and probably it makes some sense support secure connection shutdown once the app tries to do so (which as I understand is now recommended to do before closing socket).
1. https://learn.microsoft.com/en-us/windows/win32/secauthn/shutting-down-an-s…
--
v2: secur32: Implement ApplyControlToken for SCHANNEL_SHUTDOWN.
secur32: Add semi-stub for ApplyControlToken (schannel).
secur32: Allocate buffer for either ISC_REQ_ALLOCATE_MEMORY or NULL output in schan_InitializeSecurityContextW().
secure32/tests: Add tests for ApplyControlToken (schannel).
https://gitlab.winehq.org/wine/wine/-/merge_requests/1286
Patch 1.
The tests on Windows show that when the timer callback is queued behind the clock time it is queued and executed quite soon with 0-15ms delay which corresponds to default timer granularity. The timeout tolerance in the test is quite bigger to avoid a flaky test. Wine currently may execute the callback right away or delay it indefinitely depending on the time difference and current system time.
Patch 2.
It turns out when the session is paused and then restarted and all the samples were delivered to sample grabber before restart, nothing is going to request the samples again when the session is restarted. I am attaching a test in a patch which hopefully confirms how that should work. I am not including that in the patches as the test involves delays (to make sure all the async events settle at certain points) and inherently flaky. Also, _
IMFStreamSink_GetEvent(stream, ...) in the test crashes on Win7 for some unknown reason.
[0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch](/uploads/58c1738d48b3392e7ec430a0757210d0/0001-mf-tests-Add-test-for-pausing-and-restarting-sample-.patch)
--
v6: mf/samplegrabber: Handle samples receieved in paused state.
mf/samplegrabber: Process samples in paused state in ignore_clock mode.
mf: Handle timer time behind clock time in present_clock_schedule_timer().
https://gitlab.winehq.org/wine/wine/-/merge_requests/574
Supersedes: https://gitlab.winehq.org/wine/wine/-/merge_requests/789
This MR, with patches from Rémi should fix the no sound issue in media engine and also the black screen issue with MfPlayer.exe.
--
v3: mf: Set media types for output nodes in the media session.
mf: Assume same up and downstream media type for copier creation.
mf/tests: Test for copier node in topology using evr.
mf: Add some topology source node checks in IMFMediaSession_SetTopology.
mf: Always enumerate branch source types for transform nodes.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1262
Some shlexec tests timeout on Windows10 (and generate errors as no
action has been executed).
Improve detection of timeout in child program (so that existing
workaround in shell_execute_ex can be triggered).
Signed-off-by: Eric Pouech <eric.pouech(a)gmail.com>
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1293
When `import_dll` function gets `STATUS_DLL_NOT_FOUND` from `load_dll()`, it has no way of distinguishing whether it's a dependency for the dll wasn't found, or the dll itself is missing.
That results in confusing ERR messages, where a dll is found, but wine
claims it isn't. Fix this by moving the print to the actual place that
is aware of whether it's the parent or the child dll haven't been found.
Log before:
0024:err:module:import_dll Library lib2.dll (which is needed by L"Z:\\tmp\\lib1.dll") not found
0024:err:module:import_dll Library lib1.dll (which is needed by L"Z:\\tmp\\a.exe") not found
Log after:
0024:err:module:load_dll Library L"lib2.dll" (which is needed by L"Z:\\tmp\\foo\\lib1.dll") not found
0024:err:module:import_dll Loading library lib2.dll (which is needed by L"Z:\\tmp\\foo\\lib1.dll") failed (error c0000135).
0024:err:module:import_dll Loading library lib1.dll (which is needed by L"Z:\\tmp\\foo\\a.exe") failed (error c0000135).
--------
While it's just about prints, but it costed me hours of wandering *(because if I know where to find the dependency dll, but I see that the main dll is also "not found" despite being "right there", I have to research the latter problem that looks more complicated. But given enough resources applied, it then turns out to be a faux)*.
As a fun fact, I am apparently not the only one to have stumbled upon. Here's a screenshot of a `#english` chat where I asked about a commit title correctness. It's the last place where you'd expect to find someone familiar with WINE, and yet here's a person that had to deal with that exact error as well:

So, I think it's kinda serious problem.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1166
This was observed in ReactOS, when 'Debug Page Heap'[^1] was enabled:
- Start renaming a file in a shell view
- Cancel the renaming
[^1]: DPH is modeled after 'Windows Page Heap Verification'
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1207
Overwatch 2 verifies that every kernel callback that is run, lives in user32. Introduce a callback in user32 that just forwards to the other modules' callbacks.
--
v10: user32: Remove NtUserDriverCallback* kernel callbacks.
winex11.drv: Route kernel callbacks through user32.
winex11.drv: Pass a struct to x11drv_ime_set_result.
winex11.drv: Pass a struct to x11drv_dnd_post_drop.
winemac.drv: Route kernel callbacks through user32.
wineandroid.drv: Route kernel callbacks through user32.
opengl32: Do not store debug message callback in kernel callback table.
winevulkan: Route kernel callbacks through user32.
user32: Add NtUserDispatchCallback kernel callback.
user.exe16: Move kernel callbacks to wow_callbacks.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1180
The function is implemented by setting cache file pointer to fill
read_buf. Consequently, when HTTPREQ_ReadFile is called, it will try
reading data from cache after read_buf is depleted, before continuing
reading from http stream.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=26570
--
v4: wininet: Partially implement InternetSetFilePointer
wininet/tests: Add InternetSetFilePointer tests.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1268
... and fix output buffer allocation on the way.
I am not aware of any app which strictly depends on the ApplyControlToken / connection shutdown to be implemented. Yet I saw a few games calling ApplyToken to perform the connection shutdown (similar to what is described in [1]). I once implemented that while debugging something and probably it makes some sense support secure connection shutdown once the app tries to do so (which as I understand is now recommended to do before closing socket).
1. https://learn.microsoft.com/en-us/windows/win32/secauthn/shutting-down-an-s…
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1286
Valgrind support requires a fork, which I've published to https://gitlab.winehq.org/rbernon/valgrind. The fork implements loading DWARF debug info from PE files, instead of the old and broken upstream PDB support. I've tried to upstream these changes a long time ago but didn't receive any feedback.
I think we could maybe consider keeping a fork, which I'm happy to maintain, as the changes aren't too large. We may want to investigate adding 32-on-64 support, which may require a bit more changes (to VEX specifically, because its amd64 guest doesn't support segment register manipulation).
The changes here are not all related to Valgrind, and I'll create separate MR for those which may make sense independently from Valgrind / GDB.
Also included is a suppression file to silent some annoying false positives, many of which are coming from the cross-stack accesses during syscalls, which are confusing Valgrind's stack heuristics. One can try this out with something like:
`WINELOADERNOEXEC=1 valgrind --suppressions=tools/valgrind.supp wine64/loader/wine64 wine64/programs/winecfg/winecfg.exe`
--
v2: ntdll: Fix call_user_mode_callback cfi.
ntdll: Tweak KeUserModeCallback to please Valgrind and GDB.
ntdll: Introduce a new ntdll_dispatch_syscall helper.
tools: Add suppressions from third party libraries.
ntdll: Fix valgrind notifications from ntdll.so.
ntdll: Import valgrind headers for PE side ntdll.
ntdll: Allocate a truly separate stack for the kernel stack.
winebuild: Enable unwind tables by default in PE files.
ntdll: Maintain a PE module link map and expose it to GDB.
loader: Expose a shadow copy of ld.so link map to GDB.
ntdll: Add .cfi_signal_frame to __wine_syscall_dispatcher.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1074
Showing that only non-volatile registers are reliably saved. Volatile
registers are only saved by NtGetContextThread whenever it interrupts
a thread in user space, and are otherwise returned from some previous,
possibly outdated, state.
@jacek Unless I'm missing something, I think this shows that we do not
have to save the full context in syscalls in general, and instead only
the non-volatile XMM registers?
NtGetContextThread syscall still probably needs to save the full context
and it should probably be using a specific code path.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1244