- 01 Dec, 2020 40 commits
-
-
Piotr Caban authored
Signed-off-by:
Piotr Caban <piotr@codeweavers.com> Signed-off-by:
Alexandre Julliard <julliard@winehq.org>
-
Piotr Caban authored
Signed-off-by:
-
Piotr Caban authored
This reverts commit 873a90e6. It's no longer needed. Signed-off-by:
-
Piotr Caban authored
Signed-off-by:
-
Piotr Caban authored
Signed-off-by:
-
Piotr Caban authored
Signed-off-by:
-
Akihiro Sagawa authored
Otherwise, another UTC+9 timezone matches to the timezone. Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50213Signed-off-by:
Akihiro Sagawa <sagawa.aki@gmail.com> Signed-off-by:
-
Gabriel Ivăncescu authored
A window without a minimize or maximize box can still be programmatically minimized by the Windows API. However, some WMs will refuse to change the state and not allow it to be maximized again, despite it being minimized, due to lacking those functions, thus not sending WM_STATE change notifications when clicking the minimized window on the taskbar. Heroes of Might and Magic V does this, for example, when losing focus. It minimizes itself. When maximizing it by clicking on the taskbar it won't send a WM_STATE change notification (since it was never changed) and fail to maximize properly, showing a black screen (the game will still think it is minimized). Signed-off-by:
Gabriel Ivăncescu <gabrielopcode@gmail.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
Nikolay Sivov <nsivov@codeweavers.com> Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Nikolay Sivov authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
Rémi Bernon <rbernon@codeweavers.com> Signed-off-by:
-
Austin English authored
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50206Signed-off-by:
Austin English <austinenglish@gmail.com> Signed-off-by:
-
Daniel Lehman authored
Signed-off-by:
Daniel Lehman <dlehman25@gmail.com> Signed-off-by:
-
Rémi Bernon authored
And load system fonts outside of the global font mutex. We now only use the mutex to protect the registry fonts initialization. Signed-off-by:
Huw Davies <huw@codeweavers.com> Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
Signed-off-by:
-
Rémi Bernon authored
This fixes an issue when, if an external font path was modified in the Windows key, it was then not considered as external anymore, but still present in the external key, and then dropped from both on update. This now forcefully updates the font path in both keys if needed. Signed-off-by:
-
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Alexandre Julliard authored
Signed-off-by: -
Zebediah Figura authored
We don't grab stream_cs to change any variables checked here, except to reset flush_event, and that cannot result in a deadlock. The only possible deadlocks here are: (1) between this function and EndOfStream(), which is correct, as the two should presumably be serialized; (2) between this function and EndFlush(); however, in that case we expect BeginFlush() first, which will unblock the streaming thread. Signed-off-by:Zebediah Figura <z.figura12@gmail.com> Signed-off-by:
-
Zebediah Figura authored
We don't grab stream_cs to change any variables checked here, except to reset flush_event, and that cannot result in a deadlock. The only possible deadlocks here are: (1) between this function and EndOfStream(), which is correct, as the two should presumably be serialized; (2) between this function and EndFlush(); however, in that case we expect BeginFlush() first, which will unblock the streaming thread. Signed-off-by: -
Zebediah Figura authored
We don't grab stream_cs to change any variables checked here, except to reset flush_event, and that cannot result in a deadlock. The only possible deadlocks here are: (1) between this function and EndOfStream(), which is correct, as the two should presumably be serialized; (2) between this function and EndFlush(); however, in that case we expect BeginFlush() first, which will unblock the streaming thread. Signed-off-by: -
Zebediah Figura authored
We don't grab stream_cs to change any variables checked here, except to reset flush_event, and that cannot result in a deadlock. The only possible deadlocks here are: (1) between this function and Receive(), which is correct, as the two should presumably be serialized; (2) between this function and EndFlush(); however, in that case we expect BeginFlush() first, which will unblock the streaming thread. Signed-off-by:
-
