--
v6: dmime: Implement segment state repeat and looping.
dmime: Split segment_state_play_chunk helper.
dmsynth: Reset synthesizer defaults on MIDI_SYSTEM_RESET.
dmime: Send MIDI_SYSTEM_RESET message on performance reset.
dmime: Clear all pending messages in IDirectMusicPerformance_Stop.
dmime/tests: Test that IDirectMusicPerformance_Stop clears messages.
dmime/tests: Avoid discarding old notifications in test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4358
> Well, I target the parts where the folders are created, where else could I handle it? I currently don't see a better way to do this. Mind pointing me into the direction of a better design?
I don't mean the code, I mean the UI design.
As you point out, this can be configured from winecfg. So why do we need a separate mechanism, with an ad-hoc environment variable? Why is it only usable at prefix creation? Is there a way to unify the features, or make them easier to use? How is it different from `winetricks sandbox`? etc. etc.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52155
Add plumbing to server to prevent the server from making rawinput from INPUT_MOUSE and INPUT_KEYBOARD events so a graphics driver can inject its own INPUT_HARDWARE events. This will allow a graphics driver to be fully in charge of rawinput.
--
v6:
https://gitlab.winehq.org/wine/wine/-/merge_requests/4356
> What's the use case for configuring folders individually?
TBH, I just need all of them at once. But I figured I could also just make it fully configurable just in case someone needs that. I didn't see any harm in making it fully configurable from the start, just in case.
> How are we going to ensure that prefix updates to the right thing?
Sorry, I don't understand what you mean. Mind elaborating? The logic only runs when the folder doesn't exist. Unless I missed something, updates shouldn't be a problem.
> How can it be enabled/disabled after prefix creation?
The logic I changed only runs when the folder doesn't exist, you can always link/unlink the folders using winecfg.
> How is it going to handle inability to open Unix files (fonts etc.)
Well, it's not different from disabling the Z:\ link in winecfg. If someone doesn't know what they're doing, they can run into problems with that as well. This MR would only add on option to disable the link automatically when creating a new WINEPREFIX.
> This needs a lot more thought and a proper design.
Well, I target the parts where the folders are created, where else could I handle it? I currently don't see a better way to do this. Mind pointing me into the direction of a better design?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52152
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4380
This serie adds a couple of test for CreateProcess around
std handles inheritance, depending on several options (cui/gui,
use (or no use) of STARTF_USESTDHANDLES, type of handles...).
This requires revisiting the existing tests to allow for more
flexibility in implementing the new tests (and potentially
others if needed).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4378
On Mon Nov 13 14:56:51 2023 +0000, Yuxuan Shui wrote:
> > not supported
> not sure what you mean by that? I can build it fine with mingw-w64-g++
> and it runs.
> > cancellation does not work
> this is not true. callback could still be called after MFCancelWorkItem
> returns success, the
> [documentation](https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf…
> says as much.
> and the thing is, more than this "hit race" case, our current rtworkq
> implementation triggers a assert in threadpool that says exactly what i
> predicted (callback is running when you try to close it). and that's
> exactly the race I am trying to avoid here.
> what more proof do you want?
i hope you understand the problem here. the problem is not the assert, so doesn't matter if the TP implementation handles this case.
the problem is if the `scheduled_item_cancelable_callback` is running when we reaches `queue_cancel_item`, we will double release the work item.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52137
> not supported
not sure what you mean by that? I can build it fine with mingw-w64-g++ and it runs.
> cancellation does not work
this is not true. callback could still be called after MFCancelWorkItem returns success, the [documentation](https://learn.microsoft.com/en-us/windows/win32/api/mfapi/nf… says as much.
and the thing is, more than this "hit race" case, our current rtworkq implementation triggers a assert in threadpool that says exactly what i predicted (callback is running when you try to close it). and that's exactly the race I am trying to avoid here.
what more proof do you want?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52135
It's possible that a state object pointer not in the topology node collection gets passed to
session_get_node_object(). Instead of returning the last node when the object is not found, we
should return a NULL so that the state of the last node is not changed by mistake.
--
v9: mf/tests: Test IMFMediaSession::Start().
mf: Support seeking while a session is running.
mf/tests: Add a create_test_topology() helper.
mf: Add a session_flush_nodes() helper.
mf: Make session_get_node_object() more robust.
https://gitlab.winehq.org/wine/wine/-/merge_requests/3572
--
v8: vkd3d-shader/spirv: Avoid invalid bool-to-bool conversion in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459
Rémi Bernon (@rbernon) commented about dlls/dmsynth/synth.c:
> struct wave *wave;
> };
>
> +struct fixup
> +{
> + struct list entry;
> + int dst;
> + int src;
> + int flags;
> +
> + int fixup_dst;
> + float amount;
> +};
> +
Instead of a dynamic list, could we have just a simple structure like:
```c
struct gen_increments
{
float env_hold;
float env_decay;
float vol_hold;
float vol_decay;
};
```
Which we would pass around down to `add_mod_from_connection` which would set the needed adjustments (it's actually only needed there, `set_gen_from_connection` won't have to add increments), and then after the loops we would call `fluid_voice_gen_incr` for each of these?
Or do we need the generic version for more fixups that are not in this MR?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52124
--
v5: dmime: Implement segment state repeat and looping.
dmime: Split segment_state_play_chunk helper.
dmsynth: Reset synthesizer defaults on MIDI_SYSTEM_RESET.
dmime: Send MIDI_SYSTEM_RESET message on performance reset.
dmime: Clear all pending messages in IDirectMusicPerformance_Stop.
dmime/tests: Test that IDirectMusicPerformance_Stop clears messages.
dmime/tests: Avoid discarding old notifications in test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4358
Although they look fine, 20ab5954 (and ec219ce1 even more) cut some notes early in FF VIII intro.
Haven't really looked into the details but 0ff26da7 feels a bit complicated, I'm wondering if there's a better way to do this.
Regarding 2e226c26, is this what native does?
Fwiw I'm thinking that if we want to have a much more robust SF2 / DLS2 mapping, it may be a good thing to have more dmsynth tests. I already added one that does basic sample rendering without checking the output, but maybe we should extend it to compare the rendered samples with various input.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4375#note_52119
On Mon Nov 13 10:09:34 2023 +0000, Yuxuan Shui wrote:
> What errors are you getting?
> I don't think it needs special build instructions? I link it with
> mfplat, mf, ole32 and combase.
First thing is that it's not supported in current mingw-w64. And I'm not sure if building cpp stuff with it will work at all on windows.
The "hit race" condition is not really a race, isn't it? It means callback was called after item was cancelled. That could mean that cancellation does not work, but it's not a problem in call order I think. Regarding managing TP objects, does our rtworkq work correctly on Windows? Maybe we need to fix something on threadpool side.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52107
This serie:
- adds a couple of msvcrt env tests (mainly env block inheritance)
- introduces env tests for ucrtbase
- reimplement most of the env related functions to mimic native
behavior (basically when env is modified, native crt uses
a per-variable entry allocation block (instead of having
pointers inside a single chunk of memory).
This fixes programs which keep a pointer on returned getenv()
string and expect that pointer content is not modified when
other variables in env are modified.
@piotr: from previous version
- I dropped the synchronization of \_environ and \_wenviron
hence requiring the duplication of most of the code in
ansi/unicode versions
- I also tested the changes with unicode crt startup code
(you can find in [1] this MR extended with this test code
but I don't think we want to push it upstream)
- there are some init code changes because of ucrtbase tests
and unicode crt startup tests
[1] https://gitlab.winehq.org/epo/wine/-/tree/mr-crt-env-full?ref_type=heads
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4377
That's just an ad-hoc hack. What's the use case for configuring folders individually? How are we going to ensure that prefix updates to the right thing? How can it be enabled/disabled after prefix creation? How is it going to handle inability to open Unix files (fonts etc.)? This needs a lot more thought and a proper design.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259#note_52102
On Sun Nov 12 17:58:00 2023 +0000, Nikolay Sivov wrote:
> Thanks. How do I build this?
What errors are you getting?
I don't think it needs special build instructions? I link it with mfplat, mf, ole32 and combase.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4243#note_52101
--
v7: vkd3d-shader/spirv: Avoid invalid bool-to-bool conversion in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459
Goes atop !441. The last six commits belong to this MR.
--
v6: vkd3d-shader/spirv: Avoid invalid bool-to-bool conversion in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
tests/shader-runner: Introduce an sm6 condition for test directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459
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.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4374
Goes atop !441. The last six commits belong to this MR.
--
v4: vkd3d-shader/spirv: Avoid invalid bool-to-bool conversion in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
tests/shader-runner: Introduce an sm6 condition for test directives.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459
On Sun Nov 12 12:31:21 2023 +0000, Nikolay Sivov wrote:
> This obviously has problems. Just from looking at it, I see a couple of
> possible leaks. It also changes behaviour regarding error set on
> insufficient buffer size.
Turns out there is already big differences between Wine and Windows regrading error set. I pushed a rework, also fixed the leaks. Could you please take a look at this as well?
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045#note_52076
Recent versions of Native Instruments Kontakt 7 introduced some additional HiDPI features. To do this, Kontakt calls 2 functions in `user32.dll` that Wine hasn't implemented yet: `GetWindowDpiHostingBehavior` and `SetThreadDpiHostingBehavior`. This patch adds stubs for these 2 functions and apparently that's enough for Kontakt.
This is my first contribution to Wine, I'm not 100% sure if everything is like it should be.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4373
On Sun Nov 12 12:31:21 2023 +0000, Fabian Maurer wrote:
> Any news on this?
This obviously has problems. Just from looking at it, I see a couple of possible leaks. It also changes behaviour regarding error set on insufficient buffer size.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4045#note_52068
I'm aware that winecfg allows unlinking of symlinked folders, but this is very annoying when regularly recreating WINEPREFIXES. This change makes it easy to isolate those folders from the start.
--
v5: ntdll: Add environment variable to prevent symlinking dosdevices/z:
shell32: Add environment variable to prevent symlinking home folders
https://gitlab.winehq.org/wine/wine/-/merge_requests/3259
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`
--
v12: ntdll: Avoid writing to invalid memory in i386 unix dispatcher.
ntdll: Fix incorrect i386 call_user_mode_callback CFI.
ntdll: Avoid marking freed block header as undefined for valgrind.
ntdll: Force HEAP_TAIL_CHECKING_ENABLED flag with valgrind.
ntdll: Fix valgrind notifications from ntdll.so.
ntdll: Import valgrind headers for PE side ntdll.
loader: Implement SystemTap RTLD probes.
configure.ac: Check for systemtap sys/sdt.h header.
gitlab: Install systemtap-sdt-dev packages.
ntdll: Maintain a PE module link map and expose it to GDB.
loader: Expose a shadow copy of ld.so link map to GDB.
https://gitlab.winehq.org/wine/wine/-/merge_requests/1074
On Fri Nov 10 20:03:47 2023 +0000, Vixea wrote:
> It's probably because it's being software rendered so it takes a second
> to actually update the content of the window
> Side note: you can still see it on xWayland it's just less noticeable
> like I said it's noticable on wayland because of software rendering
Hi! This is a known issue, see https://gitlab.winehq.org/wine/wine/-/merge_requests/3686#note_43830 for a description of why this is happening more (but not exclusively) with the Wayland driver. The aforementioned comment describes the effect with motion events, but it's the same cause for sustained resize events. Unfortunately we don't have a good solution yet.
`regedit` is particularly prone to this, because it takes a surprisingly long time to render its contents.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_52024
glGetStringi() is not available before 3.0. We can't trust its
function pointer being NULL since the GL implementation is allowed to
return anything in this case (*cough* macOS's GL on Metal *cough*).
This probably regressed when fd92954df8cf12c61e08c7ef7acf172efb7c44ad
removed the "if (!disabled[0]) return FALSE;" exit from
filter_extensions(), although that simply exposed an existing issue.
--
v2: opengl32: Skip filter_extensions_index() on GL contexts < 3.0.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4365
glGetStringi() is not available before 3.0. We can't trust its
function pointer being NULL since the GL implementation is allowed to
return anything in this case (*cough* macOS's GL on Metal *cough*).
This probably regressed when fd92954df8cf12c61e08c7ef7acf172efb7c44ad
removed the "if (!disabled[0]) return FALSE;" exit from
filter_extensions(), although that simply exposed an existing issue.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4365
Since we don't have the bridge anymore, and as I understand it's not coming back (?), it's becoming very easy to miss windows tests regressions. This should at least make sure we get some direct visibility of tests running on Win10.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4362
--
v3: dmime: Implement segment state repeat and looping.
dmsynth: Reset synthesizer defaults on MIDI_SYSTEM_RESET.
dmime: Send MIDI_SYSTEM_RESET message on performance reset.
dmime: Clear all pending messages in IDirectMusicPerformance_Stop.
dmime/tests: Test that IDirectMusicPerformance_Stop clears messages.
dmime/tests: Avoid discarding old notifications in test.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4358
On Fri Nov 10 19:59:28 2023 +0000, darkblaze69 wrote:
> @afrantzis Sorry for bumping this, are you aware that resizing some apps
> windows happens with content distortion and flickering as compared to
> Xwayland experience? Should I file a bug?
> Here's illustration of `wine regedit`:
> Wayland:
> 
> Xwayland:
> 
It's probably because it's being software rendered so it takes a second to actually update the content of the window
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_51974
@afrantzis Sorry for bumping this, are you aware that resizing some apps windows happens with content distortion and flickering as compared to Xwayland experience? Should I file a bug?
Here's illustration of `wine regedit`:
Wayland:

Xwayland:

--
https://gitlab.winehq.org/wine/wine/-/merge_requests/3909#note_51972
Signed-off-by: Nikolay Sivov <nsivov(a)codeweavers.com>
--
v8: vkd3d-shader/tpf: Initial support for writing fx_4_0/fx_4_1 binaries.
vkd3d-shader: Add separate binary target type for effects.
vkd3d-shader/hlsl: Handle effect group statement.
vkd3d-shader/hlsl: Add variables for techniques.
vkd3d-shader/hlsl: Rename rule for top-level techniques.
vkd3d-shader/hlsl: Add 'fxgroup' token.
tests: Add some tests for effects groups syntax.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/443
This serie cleans up (partially) the builtin Wine programs/*
compiled as GUI but still outputing to unix console.
Starting with the low hanging fruits with cases where no
one should care for the output.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4361
* Major refactor for x11drv xinput2 (listen for events based on focus, use raw unaccelerated values for XI_RawMotion)
*
I have a version of this patch that is a minimal diff to the x11drv xinput2 handler (maybe I got carried away here...), but I think it might be better to focus on the send_hardware_message() plumbing to make sure it is good for other graphics drivers.
Tested on XWayland only with MouseTester.exe (https://github.com/microe1/MouseTester/releases) and Quake Live (ported this set of patches to proton).
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/4360
Currently we are not properly handling register(cX) reservations for SM1, this is one of the things required for the SNK shaders (CW Bug Bug 18092).
register(cX) reservations also change the offset in the $Globals buffer in SM4, so support for this is also included.
---
Patch 1/4 is required to specify:
```
[require]
shader model < 4.0
```
so that the tests that follow do not get run with the vulkan backend on SM4. I think nobody disagreed with that patch.
--
v2: vkd3d-shader/hlsl: Turn register(cX) reservations into buffer offset for SM4.
vkd3d-shader/hlsl: Make register(cX) reservations work for SM1.
tests: Test register(cX) reservations.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/458
This MR improves driver support for scaled HiDPI displays, by respecting the application/window DPI.
Since we don't support per-monitor DPI information and awareness modes yet, the user should set the Wine system DPI to match the DPI/scale of the display the app will be running on, for best results.
Here is how things look with a few scenarios:
1. Screen scaled at 2x, application at 96dpi (e.g., dpi unaware apps) => the compositor automatically scales the surface:

2. Screen scaled at 2x, application at 192dpi (dpi matches compositor scale) => no compositor scaling:

3. Screen scaled at 1x, application at 96dpi (dpi matches compositor scale) => no compositor scaling:

4. Screen scaled at 1x, application at 192dpi, not typically used, just wanted to show what happens with such a mismatch:

Thanks!
--
v3: winewayland.drv: Ignore spurious size hints.
winewayland.drv: Present cursors with the correct scale.
winewayland.drv: Refactor cursor code to prepare for scaling support.
winewayland.drv: Present surfaces with the correct scale.
winewayland.drv: Prepare to handle different coordinate spaces.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4203
This fixes some inconsistency issues when it comes to inner vs outer windows. On second patch I keep ref again to outer windows from the inner windows, and there are several reasons for this:
* It fixes the existing tests to match native IE.
* It simplifies the code (it's always valid now, no second-guessing or what-ifs needed) and gets rid of `outer_window` in HTMLDocumentNode.
* It **fixes** the `outer_window` in HTMLDocumentNode → it was basically prone to crashes in niche cases since it didn't hold a ref before. We can't couple it to the inner `window` field either, because that one gets detached, and that will fail *existing* tests. For example: `events.c:3224: Test failed: put_URL failed: 80004005`.
* Instead of having to keep outer window refs in specific objects, it's simpler to have it consistent everywhere.
For now only the external caller changes are kept and a leak fix.
--
v3: mshtml: Don't NULL out the doc's window when unlinking the window.
mshtml: Return outer window to external callers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4312
_(w)environ[] do have a distinct allocation chunk for each entry, so
that _(w)environ[i] pointer and (pointed) string don't change when
updating/deleting any other entry.
Proposed implementation still differs from native:
- allocation is done on process heap, while native uses msvcrt's heap
- first ANSI allocated _environ[] doesn't have per entry allocation.
This is only activated after a change (update/deletion) to _environ[]
is made.
--
v6: msvcrt: Fix getmainargs() family to return correct environment block.
msvcrt: Use msvcrt heap for allocating envionment data.
msvcrt: Test adding UNICODE env variables.
msvcrt/tests: Add tests about intricating kernel32 and msvcrt env calls.
msvcrt/tests: Add tests about allocation of environment entries.
msvcrt: Improve environment tests (initial conditions).
https://gitlab.winehq.org/wine/wine/-/merge_requests/4313
This fixes some inconsistency issues when it comes to inner vs outer windows. On second patch I keep ref again to outer windows from the inner windows, and there are several reasons for this:
* It fixes the existing tests to match native IE.
* It simplifies the code (it's always valid now, no second-guessing or what-ifs needed) and gets rid of `outer_window` in HTMLDocumentNode.
* It **fixes** the `outer_window` in HTMLDocumentNode → it was basically prone to crashes in niche cases since it didn't hold a ref before. We can't couple it to the inner `window` field either, because that one gets detached, and that will fail *existing* tests. For example: `events.c:3224: Test failed: put_URL failed: 80004005`.
* Instead of having to keep outer window refs in specific objects, it's simpler to have it consistent everywhere.
--
v2: 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: Keep the inner window's outer_window pointer alive until it is
mshtml: Don't NULL out the doc's window when unlinking the window.
mshtml: Return outer window to external callers.
https://gitlab.winehq.org/wine/wine/-/merge_requests/4312
_(w)environ[] do have a distinct allocation chunk for each entry, so
that _(w)environ[i] pointer and (pointed) string don't change when
updating/deleting any other entry.
Proposed implementation still differs from native:
- allocation is done on process heap, while native uses msvcrt's heap
- first ANSI allocated _environ[] doesn't have per entry allocation.
This is only activated after a change (update/deletion) to _environ[]
is made.
--
v5: msvcrt: Fix getmainargs() family to return correct environment block.
msvcrt: Use msvcrt heap for allocating envionment data.
msvcrt: Test adding UNICODE env variables.
msvcrt/tests: Add tests about intricating kernel32 and msvcrt env calls.
msvcrt/tests: Add tests about allocation of environment entries.
msvcrt: Improve environment tests (initial conditions).
https://gitlab.winehq.org/wine/wine/-/merge_requests/4313
Goes atop !441. The last six commits belong to this MR.
--
v3: vkd3d-shader/spirv: Avoid redundant bool-to-bool conversions in spirv_compiler_emit_movc().
vkd3d-shader/dxil: Implement the DXIL VSELECT instruction.
tests/shader-runner: Introduce an sm6 condition for test directives.
tests/shader-runner: Add tests for 64-bit casts.
vkd3d-shader/spirv: Return an error if an invalid handler is encountered.
tests/shader-runner: Add a test for float comparisons.
https://gitlab.winehq.org/wine/vkd3d/-/merge_requests/459