There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.

This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
  content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).

It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.

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

As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

There are cases in Windows10+ where the WM_PASTE message doesn't paste
the content of the clipboard.

This appeared in testing:
- almost always just after (for a couple of milliseconds) setting new
  content into the clipboard and closing it.
- in some unrelated rare occasions (like once for 400 runs).

It looks like another (installed) process had opened the clipboard and
forbids the paste command.
As WM_PASTE doesn't return success/error status, workaround it by
wrapping the WM_PASTE command into a helper, and retry when the
clipboard's content hasn't been pasted.

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

As the clipboard is a shared resource, we cannot expect that
no other app hasn't openeded it.
So wrap clipboard access with a retry feature in case of failure.
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

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

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

Using EnumDisplaySettings() directly to query display depth has a high overhead when using the
XRandR 1.0 display device handler on some NVIDIA setups.

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

Cherry-picked from upstream commit 16f86bffec36b6e82e5c93d5f04ebc4ee4f980ab.

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

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

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

The pSignatureSettings field was not unitilized so it got a random value from
the stack causing a later crash when it was dereferenced in Wintrust
(SoftPubloadSignature).

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

An improvement of 5f0dcf79,
which, depending on theme, had an issue with
drawing the top border clipped inside the header.

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

I was unable to write tests for this; it seems it doesn't consistently work on
Windows. However, Rayman 3 seems to rely on it; it maps the same buffer twice
immediately after creation, with DISCARD flags on both maps, and expects the
same address to be returned.

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

The code originally intended to achieve this by simply waiting on flushing_cs,
and having the application thread hold flushing_cs while seeking. Unfortunately,
this can result in starvation of the application thread, since the streaming
thread always reacquires flushing_cs immediately after releasing it. Avoid this
by using a separate condition variable.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=53403Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

The code previously relied on inherent atomicity of atomic types, but atomicity
doesn't imply the right memory ordering. Be explicit about the threading model
we want.
Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

Avoid using the pronouns "u", "uw", "je" and "jouw".
Signed-off-by: Floris Renaud <jkfloris@dds.nl>

Starting with Win10, height of multiline edit controls no longer seems
to be hardwired to a multiple of the font height (when larger than
font height).

- Adapt the tests accordingly (detecting how to compute the expected
  height of a control).
- Extend the ranges of the tested heights.

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

Already fixed in user32/tests/edit.c by
614b7d74

Apply same fix for equivalent test on comctl32/tests/edit.c

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

Return WHEEL_DELTA for the granularity of the mouse z-axis.

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

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

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