Many 3D applications crashed with 'WineD3D fake window' msgbox
if they were used in VirtualBox with graphics driver
'VBoxDisp.sys from VM guest additions + installed 3D acceleration'
That was a regression of SVN r75847 == git
3d13ed394e
Contrary we had no such issues with the SW emulation.
The reason for the bug is that
VBoxDisp only supports OpenGL 2.1 (GLSL 120) and WineD3D
tried to use shaders for OpenGL 3.2 (GLSL 150).
This workaround disables the usage in a hard-coded way for
all graphics adapters. Should be ok for now, as ros does not
really support any modern GPU drivers yet.
Proper working runtime detection would be better ofc.
Thx to Doug Lyons & Fabian Maurer
cherry picked from commit 0.4.14-dev-113-g
082f230ac7
This brings us back to before guilty commit 0.4.10-dev-55-g
7af3969e9f
and therefore downgrades
dll/directx/wine/
D3D8,D3D9,DDRAW,D3DCOMPILER_43
to WineStaging 3.3 for this rls.
Also downgrades related header sdk/include/reactos/wine/wined3d.h
and for the first time also media/doc/README.WINE
Same versions of these dlls we had in every ros rls since 0.4.10rls.
Purpose of this revert is to fix crashes when Ddraw apps switch
into fullscreen with VBEMP and inbuilt Mesa.
I tested, before:
DxDiag crashed when switching to fullscreen (CORE-14955),
Diablo II crashed immediately (CORE-15652),
Monster-Truck-Madness 2 demo crashed after main menu
Afterwards all of these apps do run.
DXTN does still work after that, even with VBEMP and inbuilt Mesa.
This will be the interim fix, which I will keep for rls at least
until someone manages to fix CORE-14955 properly in master with current Wine.
analog to 0.4.10-RC-17-g
bb4c55d650
There is no need to compile our DLLs as shared libraries since we are
managing symbols exports and imports through spec files.
On my system, this reduces the configure-time by a factor of two.
Spinning here is supposed to improve performance by avoiding scheduling
overhead, but because ReactOS's Win32 subsystem does not deal with this well,
it causes the system to freeze on ROS.
As a workaround, we disable spinning and jump directly to the wait.
It should become obvious when this starts actually causing performance issues
again and it's time to undo.
