Also it would be nice if opengl could similarly be loaded on the fly.
I am working on this right now... It's relatively easy for the OpenGL parts of the X11DRV (I will do as XRender), but I have two other problems :
1) what about opengl32.dll.so itself ? In that case, can I let direct OpenGL calls in there ? Thus if an application ever tries to load opengl32.dll on a non-libGL.so enabled system, the Wine library load will just fail due to a link failure and Wine will try to load the native (if any) OpenGL32.DLL.
This is much more easy than doing a complete 'dlsym'ing of all the various OpenGL calls that are thunked (although it could be done as I would have just to rework my thunk-generator Perl script)
But well, considering that the result will be anyway 'DLL cannot be loaded', I think that the 'ugly' solution is enough.
Comments :-) ?
2) the other bigger problem is the current DDraw code. There are a whole lot of OpenGL code directly called into it. This means that this Wine package won't have DDraw work on a non-libGL.so enabled box (even if the game is only a 2D game).
I am somehow reluctant to fix this as the Direct3D code is bound to have some rework soon (at least I hope :-) ) and I do not want to have thinks conflict uselessly or do a hacky solution now to replace it by something nicer later. One solution would be to completely remove the D3D code behind compilation flags (as it's non-functionnal anyway) and people wanting to play with it could always set them to 'ON' somewhere in a .h file.
For stuff like D3D8, it's the same as for OpenGL32.DLL as without libGL.so we will never support it anyway.
Lionel