Otherwise, script56.chm's javascript will keep reloading the image and
triggering onload events non-stop. It protects against this using a variable
"noReentry", which is only set temporarily while setting the source, so it
expects it to be triggered synchronously.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53927Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53999Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Also fixes a segmentation fault on exit of winedevice.exe.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52213

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53678Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

This effectively reverts 2be9b0ff, which
incorrectly removed the flag, when the reallocation failures the tests
showed were coming from an underlying LFH in-place reallocation failure.

Thus, it restores todo_wine where appropriate while removing other todos
for sizes outside of the LFH block size range.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53996

In place reallocation is possible, although it depends on the underlying
heap strategy. The LFH heap usually fails as it doesn't blocks to grow
or shrink out of their size class. Larger block (LFH is limited to 16K
blocks), more often allow in-place reallocation, and some native DLLs
depend on this.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53996

Making the GlobalReAlloc tests more sensible, as they fail to reallocate
when the block was allocated with the LFH and the new size wouldn't.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54012

Either resizing a block in place, or reallocating through RtlHeap calls.

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

And get rid of the typedef for that struct.

Avoids adding an invalid style reference to the list with subsequent
crash on release.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53941

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53941

This avoids triggering a Mesa slowpath introduced
by Mesa commit e7f3a8d6959c74f63c877dd8776fe519d54f946f.

Additionally, it helps applications using multiple swapchains and
queries (e.g. the one in bug 43773) by not requiring extra context
switches when polling queries. For the records, the actual issue from
bug 43773 was probably fixed a long time ago, maybe already by
7b62a970 or thereabouts.

The downside of this change is that we'll now end up calling
glFinish() when there are multiple threads using the same device when
CSMT is disabled. That's a non-default setting and one that should
only be used for troubleshooting purposes at this point, so it
shouldn't be too bad of an issue. It might also make sense to just get
rid of that glFinish() entirely, it's never going to be a complete
fix.

wined3d_stream_info_from_declaration() doesn't update elements of the
stream_info structure that are not used by the current vertex
declaration. That means that there might be obsolete buffer references
in stream_info, possibly to buffers that have since been destroyed.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53950

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53964Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=46649Signed-off-by: Nikolay Sivov <nsivov@codeweavers.com>

This prevents a deadlock between the window data lock and the ntdll loader lock because
sync_window_cursor() eventually may grab the ntdll loader lock. So if another thread already
grabbed the ntdll loader lock and wants to enter the same window data critical section, it will
deadlock.

Fix Youropa (SteamID: 640120) OpenGL launch option launching to a black screen.