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 3eb944c0a7.
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=53277
Signed-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=53276
Signed-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>
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).
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=53403
Signed-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>
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=52152
Signed-off-by: Eric Pouech <eric.pouech@gmail.com>
This fixes a regression introduced by ebbcc10b05.
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
