Correctly handling keyboards (French, German...) which report right-alt
as ctrl+alt in VkKeyScan().

Splitting escape_test input tests into pure virtual keys on one hand,
and modified char key on the other.
Generating the virtual codes for the later instead of hardcoding the
results (bound to generic US keyboard).

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52980Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Some keyboards (French, German and some others) report the right alt key
(which is some cases the right-shift one) as ctrl+alt.
Add proper handling for ctrl+alt return from VkKeyScan().

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=52980Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>

This fixes stack overflows since
edecac8a.
Signed-off-by: Martin Storsjö <martin@martin.st>

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