This series implements a couple of enhancements to symbol undecoration in
msvcrt:
- more C++ constructs are correctly supported (pointer to member,
constructors/destructors from template class,
non-type function pointer template parameter...)
- some internal cleanups & simplification (most of them based on
revamped helper to build up the undecorated C++ symbols)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/492
This will silently succeed, and incorrectly unmap chunks which are still in use.
v2: Add bug link.
--
v2: wined3d: Assert that the BO is mapped in unmap functions.
wined3d: Do not try to unmap already unmapped BOs in wined3d_texture_update_sub_resource().
wined3d: Do not try to unmap already unmapped BOs in wined3d_buffer_update_sub_resource().
https://gitlab.winehq.org/wine/wine/-/merge_requests/495
Some notes for the loaded/total props for ProgressEvent: they are todo_wine for `loadend` because wine-gecko returns them as 0 instead of their actual values. This is an issue in wine-gecko's nsXMLHttpRequest where OnProgress never gets called in some cases (such as our tests in xhr.js), so it needs a fix on gecko side.
[This MR](https://gitlab.winehq.org/wine/wine-gecko/-/merge_requests/7) in wine-gecko solves that issue (the first commit), but it needs to remain todo_wine until next release.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/487
win32u is mostly ready for using syscall interface (for functions not taking HDC as an argument), but using client callbacks from syscalls will affect ability to unwind exceptions in a number of cases. On Windows, depending on kernel version, there are three different behaviors:
(1) On 32-bit Windows kernels unwinding works across client callbacks.
(2) On early 64-bit Windows kernels exceptions from client callbacks are filtered and ignored.
(3) On recent Windows kernels exceptions from client callbacks are treated as unhandled exceptions.
(1) is tempting because that's closest to how our pre-syscall code works. I prototyped that and I think we could make it work, but it's an additional complication to syscall interface that didn't really feel worth comparing to other options.
ntdll part of this MR implements (2). I think we would ideally use (3) instead, but it's much more risky (and syscall conversion seems risky enough on its own). Microsoft incrementally transitioned from (2) to (3) with some compatibility mitigations involved.
On top of that, some user32 calls that have win32u counterpars are still unwindable, unlike win32u variants. For example, DispatchMessageW behaves identical to NtUserDispatchMessage, except that it allow unwinding through the call, which suggests that the final call to window proc is done directly by user32, without kernel->client callback. SendMessage is also sometimes unwindable, but only when doing trivial winproc calls (but things like installing hook change that).
--
v2: win32u: Get rid of no longer needed NtUserSetCallbacks.
win32u: Use syscall interface for NtUserMessageCall and NtUserTrackPopupMenuEx.
win32u: Use syscall interface for NtUserMsgWaitForMultipleObjectsEx.
win32u/tests: Add tests for catching exceptions from timer proc.
win32u: Use syscall interface for NtUserDispatchMessage.
ntdll: Suppress callback exceptions in KiUserCallbackDispatcher.
win32u: Avoid using client callbacks for NtUserSendMessage.
win32u: Remove no longer needed NtUserDispatchMessageA.
user32: Avoid using NtUserDispatchMessage in DispatchMessage.
https://gitlab.winehq.org/wine/wine/-/merge_requests/493