This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
v2: server: Check wineserver privileges on init with -20
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
On Thu Nov 30 21:56:36 2023 +0000, Alfred Agrell wrote:
> Because WMV version 1 doesn't have codec data.
> ```
> $ gst-launch-1.0 -vvv filesrc location=dlls/wmvcore/tests/test.wmv !
> asfdemux ! avdec_wmv1 ! fakesink
> [...]
> /GstPipeline:pipeline0/avdec_wmv1:avdec_wmv1-0.GstPad:sink: caps =
> video/x-wmv, wmvversion=(int)1, width=(int)64, height=(int)48,
> pixel-aspect-ratio=(fraction)1/1, format=(string)WMV1
> $ gst-launch-1.0 -vvv filesrc location=waga.wmv ! asfdemux ! avdec_wmv3
> ! fakesink
> [...]
> /GstPipeline:pipeline0/avdec_wmv3:avdec_wmv3-0.GstPad:sink: caps =
> video/x-wmv, wmvversion=(int)3, format=(string)WMV3, width=(int)1280,
> height=(int)720, codec_data=(buffer)4ff1080100,
> pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)10000000/333333
> ```
> (Its absense is tested by the cbFormat check in compare_media_types().)
> But yes, certainly suboptimal. I'd be happy to test it if someone can
> find a suitable test file.
If you've tested manually, that's probably fine. My concern is primarily that we're actually translating formats correctly; GStreamer and DirectShow don't always store them in the same way, and it's too easy to make assumptions (cf. [1]).
[1] https://gitlab.winehq.org/wine/wine/-/merge_requests/3636#note_45288
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54471
Zebediah Figura (@zfigura) commented about dlls/wmvcore/tests/wmvcore.c:
> todo_wine
> ok(hr == E_UNEXPECTED, "Got hr %#lx.\n", hr);
>
> + if (winetest_platform_is_wine)
I don't think you need the if (winetest_platform_is_wine) here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54469
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wm_reader.c:
> parser = reader->wg_parser;
> LeaveCriticalSection(&reader->init_cs);
>
> + if (!parser)
> + {
> + Sleep(10);
> + continue;
> + }
> +
This is ugly. Either we should explicitly block the read thread, or shut it down and restart it. The latter is probably simpler.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54465
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/wm_reader.c:
>
> - reader->stream_count = wg_parser_get_stream_count(reader->wg_parser);
> -
> - if (!(reader->streams = calloc(reader->stream_count, sizeof(*reader->streams))))
> + if (!reader->streams)
> {
> - hr = E_OUTOFMEMORY;
> - goto out_disconnect_parser;
> + reader->stream_count = wg_parser_get_stream_count(reader->wg_parser);
> + if (!(reader->streams = calloc(reader->stream_count, sizeof(*reader->streams))))
> + {
> + hr = E_OUTOFMEMORY;
> + goto out_disconnect_parser;
> + }
> + for (i = 0; i < reader->stream_count; ++i)
> + reader->streams[i].selection = WMT_ON;
I don't like this pattern; in cases like this we should instead just split up the init_stream() helper to the part that's done on initialization and the part that's done on recreation. That said I would imagine more of this should be done on initialization...?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54466
Zebediah Figura (@zfigura) commented about dlls/winegstreamer/quartz_parser.c:
> else
> format->u.video_wmv.format = WG_WMV_VIDEO_FORMAT_UNKNOWN;
>
> + format->u.video_wmv.codec_data_len = mt->cbFormat - sizeof(VIDEOINFOHEADER);
> + if (format->u.video_wmv.codec_data_len > sizeof(format->u.video_wmv.codec_data))
> + {
> + WARN("Too big codec_data value (%u).\n", (UINT)format->u.video_wmv.codec_data_len);
This cast should be unnecessary. I'd also make this an ERR or FIXME.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54464
On Thu Nov 30 21:42:02 2023 +0000, Zebediah Figura wrote:
> The codec_data introduced in 1/6 isn't validated in the tests. Why is that?
Because WMV version 1 doesn't have codec data.
```
$ gst-launch-1.0 -vvv filesrc location=dlls/wmvcore/tests/test.wmv ! asfdemux ! avdec_wmv1 ! fakesink
[...]
/GstPipeline:pipeline0/avdec_wmv1:avdec_wmv1-0.GstPad:sink: caps = video/x-wmv, wmvversion=(int)1, width=(int)64, height=(int)48, pixel-aspect-ratio=(fraction)1/1, format=(string)WMV1
$ gst-launch-1.0 -vvv filesrc location=waga.wmv ! asfdemux ! avdec_wmv3 ! fakesink
[...]
/GstPipeline:pipeline0/avdec_wmv3:avdec_wmv3-0.GstPad:sink: caps = video/x-wmv, wmvversion=(int)3, format=(string)WMV3, width=(int)1280, height=(int)720, codec_data=(buffer)4ff1080100, pixel-aspect-ratio=(fraction)1/1, framerate=(fraction)10000000/333333
```
(Its absense is tested by the cbFormat check in compare_media_types().)
But yes, certainly suboptimal. I'd be happy to test it if someone can find a suitable test file.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4449#note_54462
This comes from behavioral study of Windows, which doesn't seem to check if the
lock is actually exclusively held, and just simply decrement the value stored
in the lock.
This fixes a dead lock which prevents WeCom from starting up.
--
v27: ntdll: allow SRWLOCKs to be quickly re-acquired
ntdll: An implementation of SRWLOCK that closer matches Windows'.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3504
Various new tests for CreateProcess showing a couple of issues
in current implementation.
--
v4: kernelbase: Reset std handles gotten by GetStartupInfo().
ntdll: Restrict cases for std handle inheritance in CreateProcess().
kernel32/tests: Add more tests about CreateProcess.
kernel32/tests: Enable CreateProcess() tests on 64bit compilation.
kernel32/tests: Introduce a new infrastructure for testing CreateProcess().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4441
--
v3: wined3d: Set d3d 1-9 textures in the state as SRVs.
d3d9: Use wined3d_texture_acquire_identity_srv().
wined3d: Introduce an API for creating an identity SRV on a texture.
wined3d: Release the view's resource after destroying the view.
wined3d: Explicitly bind 0 for a NULL SRV.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4436
When running wineserver under valgrind there is a bunch of uninitialised bytes warnings when sending the req_get_mapping_info reply.
This warning can easily be reproduced by running `valgrind wineserver -f` and then `winecfg`.
Tested using self compiled wine.
Reason is the `pe_image_info_t` struct having bitfields:
```
unsigned char contains_code : 1;
unsigned char wine_builtin : 1;
unsigned char wine_fakedll : 1;
```
The last 5 bits are never initialized. This MR fixes this by zeroing the entire struct before it is filled.
I hope "issues" like this are allowed to be fixed so valgrind has less false positives.
Valgrind message for reference:
```
==628662== 716 errors in context 3 of 3:
==628662== Syscall param writev(vector[1]) points to uninitialised byte(s)
==628662== at 0x49C3A87: writev (writev.c:26)
==628662== by 0x14C2F3: send_reply (request.c:268)
==628662== by 0x14C50F: call_req_handler (request.c:316)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Address 0x53ec56e is 62 bytes inside a block of size 88 alloc'd
==628662== at 0x48416D4: malloc (vg_replace_malloc.c:431)
==628662== by 0x1348D0: mem_alloc (object.c:119)
==628662== by 0x14BEB9: set_reply_data_size (request.c:160)
==628662== by 0x1301C1: req_get_mapping_info (mapping.c:1291)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
==628662== by 0x12CBE0: main (main.c:238)
==628662== Uninitialised value was created by a client request
==628662== at 0x134873: mark_block_uninitialized (object.c:110)
==628662== by 0x1348EA: mem_alloc (object.c:120)
==628662== by 0x134B87: alloc_object (object.c:199)
==628662== by 0x134F92: create_named_object (object.c:337)
==628662== by 0x12F12B: create_mapping (mapping.c:939)
==628662== by 0x12FFE9: req_create_mapping (mapping.c:1250)
==628662== by 0x14C494: call_req_handler (request.c:305)
==628662== by 0x14C5D2: read_request (request.c:339)
==628662== by 0x158F52: thread_poll_event (thread.c:388)
==628662== by 0x120FC9: fd_poll_event (fd.c:505)
==628662== by 0x1212A6: main_loop_epoll (fd.c:599)
==628662== by 0x121882: main_loop (fd.c:955)
```
--
v2: server: Fully initialize pe mapping struct to avoid uninitialized memory when sending req_get_mapping_info reply (valgrind)
https://gitlab.winehq.org/wine/wine/-/merge_requests/4414
On Thu Nov 30 19:20:58 2023 +0000, Piotr Caban wrote:
> I still don't get it - the same tests are failing on wine with the patch.
Yes, you're right, I'm sorry, I misread which tests are failing. Now things makes sense to me.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54434
On Thu Nov 30 19:20:58 2023 +0000, Zebediah Figura wrote:
> > I don't see such behavior. Could you please describe in more detail
> what have you tested (preferably attaching tests diff)? It's unlikely
> that native restores to initial environment in such case.
> I... seem to have drastically misread my results somehow.
> The attached diff does make some tests fail on Windows 10, though.
> [scratch.diff](/uploads/894d1ae22c846a46b60f74af79b0f1f7/scratch.diff)
I still don't get it - the same tests are failing on wine with the patch.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54428
> I don't see such behavior. Could you please describe in more detail what have you tested (preferably attaching tests diff)? It's unlikely that native restores to initial environment in such case.
I... seem to have drastically misread my results somehow.
The attached diff does make some tests fail on Windows 10, though.
[scratch.diff](/uploads/894d1ae22c846a46b60f74af79b0f1f7/scratch.diff)
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54426
I know this breaks Windows behavior but having apps print out
special debug messages to the terminal provides a good look
into the applications' development (for example I know that NFS
Underground has some "done" messages likely used for debugging).
I also don't want to keep another revert in my Wine tree just
for this one feature either so that's why I'm MR'ing this.
I considered adding a registry/winecfg entry for this behavior
but it would make this change much larger (and there's no good
place in winecfg to put this behavior in).
To enable this behavior, you can set WINEDEBUG=+unixcon variable
before launching an application.
Xkcd-Entry: https://xkcd.com/1172/
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55435
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4566
Nikolay Sivov (@nsivov) commented about dlls/comctl32/tab.c:
> - if (infoPtr->tabMinWidth < 0)
> - oldcx = DEFAULT_MIN_TAB_WIDTH;
> - else
> + if (infoPtr->tabMinWidth < 0) {
> + TEXTMETRICW text_metrics;
> + HDC hdc = GetDC(infoPtr->hwnd);
> + HFONT oldFont = SelectObject(hdc, infoPtr->hFont);
> + GetTextMetricsW(hdc, &text_metrics);
> + oldcx = text_metrics.tmAveCharWidth * MIN_CHAR_LENGTH + infoPtr->uHItemPadding * 2;
> + SelectObject(hdc, oldFont);
> + ReleaseDC(infoPtr->hwnd, hdc);
> + } else {
> oldcx = infoPtr->tabMinWidth;
> + }
> infoPtr->tabMinWidth = cx;
> TAB_SetItemBounds(infoPtr);
Could we move this segment to SetItemBounds()? It does exactly the same calculation. At the very least we should consider a helper. Or maybe we could return oldcx value from SetItemBounds()?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4484#note_54425
On Wed Nov 29 09:33:45 2023 +0000, Stefan Riesenberger wrote:
> Thanks for the quick answer!
> Yeah if everything diverged too much it makes no sense wasting time on rebasing.
> Looking forward to everything getting upstream then! I hope the road
> will be less bumpy next year as it has been this year.
looking forward for the mouselock support (you mean putting the cursor in the center I suppose)
basically all I need to switch to wine-wayland which is great
having support for wl-clipboard is appreciated since xwayland is broken
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522#note_54421
Various new tests for CreateProcess showing a couple of issues
in current implementation.
--
v3: kernelbase: Reset std handles gotten by GetStartupInfo().
ntdll,server: Revisit std handles inheritance.
kernel32/tests: Add more tests about CreateProcess.
kernel32/tests: Introduce a new infrastructure for testing CreateProcess().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4441
On Thu Nov 30 15:33:34 2023 +0000, Yona-TYT wrote:
> I did a little test with the Jagex Launcher to play oldrunescape, but in
> wayland the window is completely black.
> Even so, I was able to execute by guessing where the "Play" button was.
> [JagexLauncherInstaller.exe](https://cdn.jagex.com/Jagex%20Launcher%20Instal…
> x11:
> wayland
From a quick look, the launcher uses CEF (Chromium Embedded Framework). CEF typically uses cross-process rendering which is not supported in the upstream Wayland driver yet.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_54400
I did a little test with the Jagex Launcher to play oldrunescape, but in wayland the window is completely black.
Even so, I was able to execute by guessing where the "Play" button was.
[JagexLauncherInstaller.exe](https://cdn.jagex.com/Jagex%20Launcher%20Instal…
x11:
wayland
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_54398
On Thu Nov 30 11:03:15 2023 +0000, Zebediah Figura wrote:
> If you remove the line "_putenv("cat=")" from the test, it fails the
> same way on Windows. This implies that native is detecting when the
> environment has been modified *back* to its initial state and undoing
> the reallocation in that case. That strikes me as a little insane; do we
> care about implementing that behaviour?
I don't see such behavior. Could you please describe in more detail what have you tested (preferably attaching tests diff)? It's unlikely that native restores to initial environment in such case.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54383
Visual Studio's native tool command prompt uses rare for loop variables: %%1, %%2. This test covers this case.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55401
--
v4: cmd: added support of FOR loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
cmd: added support of FOR loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
* cmd: added support of FOR loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
cmd: added support of for loop's rare var names (%%1), fixed expansion of outer var loop name inside inner loop
cmd: added test for rare for loop vars
https://gitlab.winehq.org/wine/wine/-/merge_requests/4504
Detecting the host layout languages from their Xkb identifiers, and introducing a new driver interface using the KBDTABLES structure to translate them to Win32.
--
v7: winewayland.drv: Implement CAPLOK and SGCAPS in KBDTABLES.
win32u: Support SGCAPS attributes in KBDTABLES.
winewayland.drv: Add scan2vk tables for azerty, qwertz and dvorak.
winewayland.drv: Translate Xkb keyboard layouts to KBDTABLES.
win32u: Allow KBDTABLES conversion from CTRL + ALT to WCHAR.
win32u: Force US layout in ToUnicode when CTRL is pressed.
win32u: Avoid accessing NULL key name string pointer.
win32u: Introduce KbdLayerDescriptor user driver entry.
winewayland.drv: Enumerate Xkb layouts and create matching HKL.
winewayland.drv: Handle and parse Xkb keymap events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4455
Moving most systray code out of winex11, and removing the need for a custom export in winemac. Maybe winemac could perhaps later use that new interface as well but I didn't want to mess with it too much.
--
v2: explorer: Remove now unnecessary wine_notify_icon support.
winex11: Use the new SystrayDock driver interface.
explorer: Use layered windows for the docked systray icons.
win32u: Introduce new SystrayDock driver entry points.
winemac: Use the new NotifyIcon user driver interface.
win32u: Introduce a new NtUserSystemTrayCall message call.
explorer: Hide the standalone systray window on close.
explorer: Always set the systray icon tooltip text.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4540
The tests show that the first argument must not be null, that the handle
returned via the fourth argument is not an HTHEME, and that that handle
can be passed to CloseThemeFile without error.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4531
Conflicts with !450 but can probably go upstream before it since backend changes here are minimal.
--
v6: vkd3d-shader/dxil: Handle the DXIL SWITCH instruction.
vkd3d-shader: Rename shader_instruction_array_add_icb() to shader_instruction_array_add_opaque_param().
vkd3d-shader/dxil: Handle the DXIL PHI instruction.
vkd3d-shader/dxil: Handle the DXIL BR instruction conditional variant.
vkd3d-shader/dxil: Handle the DXIL BR instruction unconditional variant.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/491
push_dc_driver() places drivers based on their priorities, so the newly created driver is not
necessary on top. Thus in windrv_CreateDC(), find_dc_driver() should be used to find the dib
driver instead of assuming the dib driver is the top driver, which could be the path driver because
it has a higher priority.
--
v2: win32u: Find the correct DIB driver in windrv_CreateDC().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4374
If you remove the line "_putenv("cat=")" from the test, it fails the same way on Windows. This implies that native is detecting when the environment has been modified *back* to its initial state and undoing the reallocation in that case. That strikes me as a little insane; do we care about implementing that behaviour?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4552#note_54342
Detecting the host layout languages from their Xkb identifiers, and introducing a new driver interface using the KBDTABLES structure to translate them to Win32.
--
v6: winewayland.drv: Implement CAPLOK and SGCAPS in KBDTABLES.
win32u: Support SGCAPS attributes in KBDTABLES.
winewayland.drv: Add scan2vk tables for azerty, qwertz and dvorak.
winewayland.drv: Translate Xkb keyboard layouts to KBDTABLES.
win32u: Allow KBDTABLES conversion from CTRL + ALT to WCHAR.
win32u: Force US layout in ToUnicode when CTRL is pressed.
win32u: Avoid accessing NULL key name string pointer.
win32u: Introduce KbdLayerDescriptor user driver entry.
winewayland.drv: Enumerate Xkb layouts and create matching HKL.
winewayland.drv: Handle and parse Xkb keymap events.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4455
This is a slightly simplified version of a patch submitted by Michael Müller.
There are two major changes relative to that patch:
* The process name is taken from the initial argv, rather than the "normalized"
argv. In practice this means that the executable name may or may not have its
.exe extension, and the user of WINEDEBUG will have to guess. Unfortunately
using the normalized argv requires dbg_init() to be called later, which would
be somewhat unfortunate.
* The original patch had support for a syntax "-process.exe:+channel" that would
allow channels to be toggled for all process *except* one. Since the same can
be done almost as easily with "+channel,process.exe:-channel", I decided this
extra logic was unnecessary.
This proved useful when trying to debug the issue in 4552; I was able to do
WINEDEBUG=+pid,+seh,+msvcrt,wineboot.exe:+heap
whereas enabling +heap for all processes made the log too slow and large.
With that said, in retrospect it would also have been easy to simply hack
something specific and temporary into parse_options(), so if this patch set is
deemed unnecessary I won't care too much.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4553
This is the current proton thread priority implementation by @rbernon rebased for upstream with a few `#ifdef`s added since AFAIK Linux is the only operating system where threads have a unique PID which can be used to set niceness on.
I also ran `./tools/make_requests` on https://gitlab.winehq.org/mzent/wine/-/commit/6705d3481be0409f7e971c1d2c7a3… as well and `autoconf` on https://gitlab.winehq.org/mzent/wine/-/commit/d7bafe40c411753662b2ad97148a6… (which does blow up the line count a bit).
A few tiny changes (with the ready variable for example) are in anticipation for Part 2, which also adds Mach thread priorities and recalculates thread priorities on process priority change.
Since this is a rather large MR, I hope the split here is appropriate (with the second part being slightly smaller), but I think logically it makes the most sense here.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4551
This is the third (and last) part of the Wayland driver Vulkan subseries:
1. Implement `vkQueuePresentKHR` and support reporting `VK_ERROR_OUT_OF_DATE_KHR` and `VK_ERROR_SURFACE_LOST_KHR`.
2. Misc. enhancements/fixes to ensure the subsurface containing the vulkan rendering is displayed properly.
3. Implement a couple of remaining Vulkan functions.
With this MR you can start enjoying some of your games with the Wayland driver (either directly with Vulkan or with a D3D->Vulkan translation). Please note, however, that we don't currently support what's needed for mouselook (you will currently get erratic view movement), so most first-person 3D games are not playable yet.
Thanks!
--
v3: winewayland.drv: Implement vkGetPhysicalDevicePresentRectanglesKHR.
winewayland.drv: Implement vkGetDeviceGroupSurfacePresentModesKHR.
winewayland.drv: Apply client subsurface position on creation.
winewayland.drv: Ensure Vulkan parent surface is mapped with proper size.
winewayland.drv: Detect and report vkQueuePresentKHR errors.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4522
Starting with LLVM 17, having non-private labels between `.cfi_startproc`/`.cfi_endproc` triggers "invalid CFI advance_loc expression" errors when targeting Mach-O.
Use local labels instead, and store the pointer in `.data` so it can be read by `handle_syscall_trap()`.
Based on a patch by Jacek Caban.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=55863
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4547
Various new tests for CreateProcess showing a couple of issues
in current implementation.
--
v2: ntdll,server: Revisit std handles inheritance.
kernelbase: Reset std handles in startup_info when not requested.
kernel32/tests: Add more tests about CreateProcess.
kernel32/tests: Introduce a new infrastructure for testing CreateProcess().
https://gitlab.winehq.org/wine/wine/-/merge_requests/4441
Here's a list of usages of `base.outer_window` that may be impacted by the change and my analysis/fixes. Note that I specifically did not look for `document->outer_window` since that one was already holding it forever, so it's out of scope for this MR (whether it's correct or not, the behavior is the same after this MR).
I also didn't consider some cases that already **did not check** for it being NULL or not, because they would have crashed earlier before anyway (they'd still crash now if outer window gets killed, but it's out of scope of the MR as I said). For those that says "Handled" it means I've added checks so that the behavior is same as before, i.e. detached inner windows behave as if outer window is NULL.
* `htmldoc.c/HTMLDocument_get_mimeType`: Changed so it doesn't rely on outer window.
* `htmldoc.c/HTMLDocument7_get_defaultView`: This is actually fixed by these patches.
* `htmlform.c/HTMLFormElement_submit`: Handled.
* `htmlstorage.c/send_storage_event`: Fixed in a separate patch with tests, since it follows the outer window.
* `htmlwindow.c/check_target_origin`: This (along with many other methods) can't have it NULL anymore or detached, since the caller must hold a ref to the outer window, and they're not called from our objects holding ref to inner window only.
* `htmlwindow.c/HTMLWindowSP_QueryService`: This uses the outer window to obtain the browser and the doc obj, so it's fine.
* `mutation.c/set_document_mode`: Handled.
* `navigate.c/BindCallbackRedirect_Redirect`: Handled.
* `navigate.c/nsAsyncVerifyRedirectCallback_OnRedirectVerifyCallback`: Handled.
* `navigate.c/nsChannelBSC_init_bindinfo`: Uses the outer window to obtain the browser and doc obj to set a flag, so it's harmless and probably correct this way.
* `navigate.c/handle_navigation_error`: Handled.
* `navigate.c/handle_extern_mime_navigation`: Handled.
* `omnavigator.c/OmHistory_get_length`: This is actually fixed by these patches.
* `script.c/ActiveScriptSite_GetItemInfo`: Handled.
* `script.c/ActiveScriptSiteWindow_GetWindow`: Handled.
--
v5: mshtml/tests: Fix XHR leak in test_window_refs.
mshtml: Get rid of outer_window member in HTMLDocumentNode.
mshtml/tests: Improve the iframe navigation test.
mshtml: Remove the inner window ref from the doc only when it is actually
mshtml: Don't check for NULL outer_window from within HTMLWindow* methods.
mshtml: Don't attempt to send storage events after outer window is destroyed.
mshtml: Keep the inner window's outer_window pointer alive until it is
mshtml: Don't rely on the outer_window in document.mimeType.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380
Supersedes !482.
Instead of only storing the value that each variable's component has at
the moment of the instruction currently handled by copy-prop, we store
the trace of all the historic values with their timestamps, i.e. the
instruction index on which the value was stored.
This allow us to query the value that the variable's component had at the time of a swizzle's load instead of the swizzle instead, which also preempts copy-prop from getting stuck in an infinite loop, as which the added tests.
--
v5: vkd3d-shader/hlsl: Use values at the time of the swizzle's load in copy-propagation.
vkd3d-shader/hlsl: Record trace of stored values in copy-propagation.
vkd3d-shader/hlsl: Move index_instructions() up.
tests: Test current failure when propagating swizzles.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/487