Suggested by Piotr Caban.
Signed-off-by: Arkadiusz Hiler <ahiler@codeweavers.com>
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit f3f948a5a3)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
Signed-off-by: David White <dwhite@codeweavers.com>
Signed-off-by: Jacek Caban <jacek@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit 67e7f6cd56)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
This fixes a regression in running MSVC 2010 in wine, when reading
.def files (regressed in b0ab1b7602).
Signed-off-by: Martin Storsjo <martin@martin.st>
Signed-off-by: Piotr Caban <piotr@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit fb0fa9aacf)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
Fixes an Apple Silicon issue where CGDisplayIOServicePort() returns
a fake AMD GPU "compatibility" node rather than the real GPU node.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit ae319caa3b)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
This is especially important for M1 GPUs as they don't support the 24/8 format.
Signed-off-by: Jan Sikorski <jsikorski@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit 88220e0ee4)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
This reduce the time to run the monitor test from 6 minutes to 25 seconds.
Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=50086
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit cad102465d)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
Fix a possible test failure on Win10 2009.
Signed-off-by: Zhiyi Zhang <zzhang@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit a11ffeec96)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
xlib6g-dev on Debian and XFree86-devel on Red Hat no longer exist.
Replaced with: xorg-dev (Debian) and libX11-devel (Red Hat)
Signed-off-by: Floris Renaud <jkfloris@dds.nl>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit 8c65205d22)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
On Apple Silicon, Rosetta allocates memory starting at 0x100000000
(the 4GB line) before the preloader runs.
The .NET 3.5 installer and DirectX Jun2010 redistributable both contain
non-relocatable EXEs with that base address, which fail to run.
The workaround is to create an empty linker section at that address,
which is mapped by the kernel before Rosetta runs and forces Rosetta's
allocations higher in memory.
The linker section runs from 0x100000000-0x114000000.
Rosetta's allocations are ~132MB, and should end below 0x120000000.
This is not an exact science: a non-relocatable EXE with base address
between 0x114000000-0x120000000 will fail to run. If one is discovered,
the section size will need to be changed.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit 307f5d00f1)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
On Apple Silicon, Rosetta's shared cache starts at 0x7ffe00000000 and
the runtime is mapped below that.
Put the top-down allocation area below the runtime with plenty of room
to spare.
Signed-off-by: Brendan Shanks <bshanks@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit 720611e28e)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
It may otherwise trigger a nasty race condition, where:
1) For explorer.exe to register the CLSID_ShellWindows classes, it
needs RpcSS service to be started,
2) services.exe may start WinePlugPlay service group first, waiting for
its startup to complete,
3) during startup and early device enumeration, hidclass.sys may call
IoSetDeviceInterfaceState, which calls plugplay_send_event [1],
4) plugplay_send_event tries to broadcast a WM_DEVICECHANGE message with
BSF_QUERY, waiting for the individual threads to reply,
5) which times-out because window threads are waiting on explorer.exe
to create its desktop window and reply to the WM_NULL SendMessage.
This happens more likely as there is threads with message queues
being started, each waiting on the desktop window to reply. Usually
explorer.exe is able to reply to some messages with the implicit
message processing while creating its window, but not all of them.
[1] Not completely sure how, it looks like some RPC too, but before
RpcSs is started?
Signed-off-by: Rémi Bernon <rbernon@codeweavers.com>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
(cherry picked from commit f5ca06016d)
Signed-off-by: Michael Stefaniuc <mstefani@winehq.org>
Arkadiusz Hiler