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
GCC Linux build had no issues with the last commit but
MSVC x86 & x64 v18.0.31101.0 choked on it with
error C4133: 'function' : incompatible types - from 'D3D_PRIMITIVE *' to 'DWORD *'
and similar.
I could not retest with that exact version of MSVC, but the mentioned problems
vanished for me when compiling locally with MSVC 16.0.40219.1 x86.
Fingers crossed, that this makes the builders happy again!
Avoid regressions CORE-14955 "Ddraw fullscreen crashes" and CORE-15652
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,WINED3D
to WineStaging 3.3.
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.
Amine Khaldi agreed to perform this revert also for master now.
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.
squashed commit of 0.4.13-RC-2-g
67dd70e5ef
and 0.4.13-RC-3-g
9f1e2cd172
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.
