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