Stefan Dösinger wrote:
Our d3d implementation works pretty well on Windows(well, as good as it
does
on Wine), with the exception of directdraw. The problem with ddraw is
that
ddraw.dll needs wined3d.dll, which loads opengl32.dll, and Microsoft's opengl32.dll loads ddraw.dll. Oops.
Currently we have no real attacking point to this issue.
Is there any good reason for the windows opengl32.dll to be loading ddraw.dll? Might it load it without actually using it? Seems odd that the 3D acceleration API would want to hook into the legacy 2D one.
The software opengl32 renderer is implemented using directdraw these days and that causes the issues when I experimented with wine's ddraw on windows a while ago. It is possible to work around this (if you declare the number of adapters to 1 before wined3d loads opengl32.dll) from what I remember. It is able to load the functions then but when making GL calls it crashed. Perhaps my radeon9000 drivers had a bug.
Roderick