Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

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

Signed-off-by: Eric Pouech <eric.pouech@gmail.com>

To ensure a seamless transition between value names, we try loading the
registry value from FontFamily first and FontPitchFamily second.

Any changes to the console font family are saved to the new value name.

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

Based on mingw-w64.

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

SetWindowIcon can pass an icon as a parameter, but in that case
NtUserGetIconInfo is never called, so the icon info is never filled.

Fixes a regression introduced by 3eb944c0.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@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=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>