I'd suggest moving some of the existing code into helper functions first. It's already hard to follow and these changes to it aren't making it any simpler.
Also, ten commits per MR is rather too many (especially when they're non trivial). Try sending the first five or so.
If you want to show where it's going, then include a link to a branch which contains the finished set.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/969#note_10582
--
v3: mshtml: Don't create dynamic prop before checking if elem prop even exists.
mshtml: Allow accessing some document elements as props via id.
mshtml: Expose props via element name only for specific element types.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1031
With this series it's now possible to run and pass `user32:monitor` and `user32:sysparams` tests with nulldrv, and so most `user32` tests (except for a few desktop cursor position tests). This still requires some prefix configuration to enable the nulldrv driver, or a change like https://gitlab.winehq.org/rbernon/wine/-/commit/753368ad0ec52f03f8d6e78ca79… to enable it when `DISPLAY` environment variable is unset.
This then shows that some of the user32 tests are failing with winex11 but passing with nulldrv, as in https://gitlab.winehq.org/rbernon/wine/-/commit/6d5f4109a514a0dc266899fcacf….
--
v9: win32u: Read mode from the registry if GetCurrentDisplaySettings fails.
win32u: Write display settings to the registry in apply_display_settings.
win32u: Lock display devices while applying display settings.
win32u: Use an internal WINE_DM_PRIMARY_DEVICE flag on primary adapter modes.
win32u: Remove the device name parameter from GetCurrentDisplaySettings.
win32u: Force update display cache after NtUserChangeDisplaySettingsEx.
win32u: Add a BOOL force parameter to update_display_cache.
https://gitlab.winehq.org/wine/wine/-/merge_requests/551
I used the following test program (compiled with MSVC with /MD):
```
#include <windows.h>
#include <stdio.h>
typedef void** (__cdecl *pcurrent_exception)(void);
int main()
{
HMODULE hvcr = LoadLibraryA("vcruntime140.dll");
HMODULE ucrtb = LoadLibraryA("ucrtbase.dll");
pcurrent_exception p__current_exception1, p__current_exception2;
p__current_exception1 = (pcurrent_exception)GetProcAddress(hvcr, "__current_exception");
p__current_exception2 = (pcurrent_exception)GetProcAddress(ucrtb, "__current_exception");
try
{
throw("ex1");
}
catch (const char *s)
{
EXCEPTION_RECORD* rec1 = (EXCEPTION_RECORD *)*p__current_exception1();
EXCEPTION_RECORD* rec2 = (EXCEPTION_RECORD *)*p__current_exception2();
printf("Exception %s, rec1 %p (code %#lx), rec2 %p.\n", s, rec1, rec1->ExceptionCode, rec2);
}
}
```
This outputs the following on Windows:
```
Exception ex1, rec1 00000089CAF9F990 (code 0xe06d7363), rec2 0000000000000000.
```
So I think that confirms that:
1. vcruntime140 and ucrtbase have distinct local data (or at least current exception data) on Windows;
2. vcruntime140_1 links to vcruntime140.
3. msvcp140 should link to vcruntime140's exception data too as it is apparently able to get the correct current exception in ?__ExceptionPtrCurrentException@@YAXPEAX@Z.
These patches allow the current exception to be correctly located when there are mixed builtin and native VC runtime 140.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/1047