Today, the image_unlock() helper function has a data race due to
non-atomic write to GpImage's 'busy' flag which is accessible by other
threads.  Also, it lacks a release fence, which means that other threads
can observe the unlocked (busy = 0) state too early when the current
thread unlocks the image; specifically, the write to the 'busy' field of
the GpImage can be reordered before the last read/write to any other
fields of the same GpImage.

Fix this by replacing the 'busy' field of GpImage with SRWLOCK.

The 'busy' field in GpImage is used as an atomic variable.  The C11
standard (§5.1.2.4, paragraph 25) states that two conflicting actions to
a memory location shall be both atomic operations, or otherwise properly
synchronized; otherwise, it constitutes a data race.

However, select_frame_wic() performs a non-atomic access to the 'busy'
field on a GpImage that is potentially accessible by other threads.
This happens when select_frame_wic() copies new_image to the old image
object.  Although it does attempt to preserve the value of the 'busy'
field by setting new_image->busy = image->busy first, thereby
effectively assigning an identical value to the field, it is unclear
that this does not actually constitute a theoretical, if not practical,
data race.  This also prevents replacing the busy flag with a mutex or
other synchronization primitives.

Therefore, skip the 'busy' field when copying fields from the new image
to the original image object.

GdipImageRotateFlip() calls GdipBitmapLockBits() while holding the image
lock, resulting in a recursive lock.

Since GdipImageRotateFlip() uses GdipBitmapLockBits() only to obtain
Scan0 and Stride, replace them with equivalent fields from GpBitmap
itself.

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

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

Signed-off-by: Anton Baskanov <baskanov@gmail.com>

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

Windows versions 10v1507 and below classify a provider as an HWND
provider if it returns a value for UIA_NativeWindowHandle. By ignoring
this property, we get more consistent behavior in tests between all
Windows versions.
Signed-off-by: Connor McAdams <cmcadams@codeweavers.com>

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

Instead of silently leaking no longer used chunks.
Be more robust to OOM conditions.
Introducing pool_realloc().
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Create a dedicated heap for each module (as it was done for the
private home grown pools).
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

We can only get a successful status that way. This matches sock_recv().

Also combine the if (alerted) blocks. Unlike the previous commits, this cannot
be separated, as it causes warnings with some versions of gcc.

There is no need to release the async_fileio structure before calling set_async_direct_result().

We can only get a successful status that way. This matches sock_recv().

There is no need to release the async_fileio structure before calling set_async_direct_result().

We can only get a successful status that way. This avoids an uninitialized variable warning with gcc 12.2.

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