On Windows RegEnumValueA() is buggy such that when the value name
buffer is too small, it may way overestimate the required data buffer
size, sometimes returning more than the sufficiently large buffer it was
provided, in which case that buffer is untouched and thus not
NUL-terminated.
So modify the tests to accept this broken result and avoid checking
out-of-bounds data.
Wine-Bug: https://bugs.winehq.org//show_bug.cgi?id=53172
When using nulldrv, there's no module to call __wine_set_user_driver and
the user driver is still lazy_load_driver when get_display_driver gets
called during desktop windows creation.
Then, load_desktop_driver fails as it cannot find the not-yet-created
desktop window atom, and fails later explorer.exe window creations such
as the systray window.
Other processes don't suffer from this as they wait for the desktop
window to be fully created, and its atom will be eventually set.
This change makes sure that we succeed in the case nulldrv was selected
by explorer.exe, while still failing in case of error with another user
driver as it would fail to open the right display device GUID.
To match d3d8.
The original patch [1] claims
"WM_SIZE(SIZE_MAXIMIZED) is reliable here. The unreliable behavior
occured only with NOWINDOWCHANGES."
but this doesn't match my testing. Probably when that patch was submitted, this
very fix was applied to the d3d8 tests but forgotten for the d3d9 tests, and
then the wrong conclusions were drawn.
[1] https://www.winehq.org/pipermail/wine-patches/2014-December/135964.html
Test the current date to ensure broad coverage, and specifically test a
February date because, in the French locale, it shows that
SHFormatDateTimeA() uses the CP_ACP code page, not the locale's default
one.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149
In particular, February dates contain an e-acute in French, the
representation of which depends on the code page being used, which in
SHFormatDateTimeA() is CP_ACP.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=54149
ZusiDisplay sometimes loads the same font file into two different
PrivateFontCollections using two threads, so there is a race condition
when the file is opened without the FILE_SHARE_READ sharing mode. The
second call to GdipPrivateAddFontFile() might fail if the first one
hasn't closed the file handle yet.
This patch addresses an issue in Second Life and potentially other
multi-threaded applications which process WM_KEYDOWN in one thread
and then verify that the key is "still down" with GetAsyncKeyState
from another thread. Wine uses a per-thread key cache, resulting
in inconsistent views of key status. Caches are now invalidated
when an input event is injected by the driver or via SendInput.
