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