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.
They need to be handled separately because they are blocked by sync XHRs
for the given window.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
And get rid of default_task_destr since it's only used in one place anyway. It
was already confusing and leaking in some cases.
Signed-off-by: Gabriel Ivăncescu <gabrielopcode@gmail.com>
Without this fix, the font cache was filling up with lots of duplicate entries,
and getting cache misses, thereby causing font-intensive applications
to be very slow (e.g. AvalonEdit).
This fix provides 30x speed increase when processing glyphs.
