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

This fixes a regression introduced by ebbcc10b.
Prior to that commit, buffers which were not CPU-accessible would not have the
WINED3D_BUFFER_USE_BO flag set, and accordingly
buffer_resource_sub_resource_map() would simply return the SYSMEM location,
ignoring the DISCARD and NOOVERWRITE flags.

However, the "accelerated" path in wined3d_cs_map_upload_bo() only checks for
the DISCARD flag, assuming that it is only set for dynamic GPU-accessible
buffers, and would subsequently try to allocate non-mappable memory and then map
it.

This commit avoids the accelerated path for such buffers, once again matching
our old behaviour. According to [1], this also matches Windows: DISCARD on
SYSTEMMEM buffers is ignored on both AMD and NVidia, and NOOVERWRITE is ignored
on NVidia (but not AMD).

[1] https://www.winehq.org/mailman3/hyperkitty/list/wine-devel@winehq.org/message/XACSAVAGYTJUZDFLX4JWO665VTB6M7LX/

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

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

Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

Signed-off-by: Zebediah Figura <zfigura@codeweavers.com>

DISCARD maps on deferred contexts do not seem to offer the same synchronization
guarantees as do DISCARD maps on the immediate context, at least not with
respect to subsequent NOOVERWRITE maps on the immediate context. This is not
particularly surprising, seeing as it is probably far more usual to only map a
resource on one kind of context or the other.

The test currently fails on Windows 11 on NVidia drivers, but it also fails on
Mesa, for what I think are the same reasons.

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

By backporting the corresponding window management tweaks from the
d3d8:device test.

Split the check_rt_color() function to allow conditional todos.

It fails on the Gitlab CI.