After submitting the patches last night, I got some feedback on IRC. It seems that adding new exports to gdi32.dll is bad (it apparently tends to break applications, those using safedisc2 seem to be good candidates), so I had to look for another solution.
Everything that follows here is under the assumption that we want to move all access to the native opengl library to x11drv. But that's the impression I got from Alexandre in the other mail regarding new escape codes (http://www.winehq.org/pipermail/wine-devel/2006-May/047539.html).
If the above assumption is true then opengl32.dll needs access to the low-level driver (eg. x11drv) where all the WGL functions are implemented. And if adding new gdi32.dll exports is not an option then ExtEscape() or some other Escape function is the only way to go. Someone told me that even in Windows Vista opengl uses an escape function to talk to the low-level driver.
So my new approach is this: - one new gdi driver function: WineGL_getDispatchTable => returns the dispatch table for the basic WGL functions. - two new ExtEscape() codes: => WINEGL_GET_DISPATCH: returns dispatch table as returned by the new driver function => WINEGL_GET_PRIVATE: returns physDev for the given HDC. - opengl32.dll gets the dispatch table using the new escape code when it is loaded. - in x11drv, opengl.c is replaced by various winegl_??? files.
Why is WINEGL_GET_PRIVATE needed? The question really is: where do we want to have the WGL extension entry points? I'd recommend to have them in x11drv, why? If they were in opengl32.dll, we'd have to update the dispatch table whenever we would add a new extension. And because the application calls the functions which are entirely implemented in x11drv and not called through wrappers (which don't really exist in my patchset anyway) and the functions still need access to the physDev structure... well, hence the second escape code.
I've removed all opengl related #ifdefs, I'd like to have configure set WINEGLFILES to either 'winegl_noop.c', which implements noop functions when opengl isn't supported, or a list with all the required winegl files when all required headers are present. And there is no need to check for linGL.so, too, (at least not for opengl32 and x11drv) because all functions are loaded using wine_dlsym() or glXGetProcAddress(). What is needed at compilation time are the three opengl header files gl.h, glx.h and glu.h. I'm not a configure expert and this big script scares me. That's why the configure patch is king of a hack, but should work when someone uses --without-opengl.
The WGL related code is mostly copied over from opengl32/wgl.c and opengl32/wgl_ext.c, I've formatted it a bit to look nicer and changed what was needed to embed it into x11drv. For example 'get_dispay()' is gone as we now have direct access to the display through 'gdi_display'. The only thing that I've disabled is the WGL_ARB_render_texture extension (nvidia drivers don't support it and there is a good chance that no application relies explicitly on this extension, however, the extension can be enabled by uncommenting one line in x11drv/winegl_extensions.c).
I've put all the patches, eleven to be precise, on my server: http://dbservice.com/ftpdir/tom/wine/
up until patch number 10, it should not introduce any regression as it only makes the necessary changes to gdi to support the new GDI driver function (but doesn't use it yet) and adds the winegl files to x11drv. Patch number 10 is a bit large, it changes configure to compile the winegl files, removes x11drv/opengl.c and updates gdi32.DescribePixelFormat and friends to use the functions from the dispatch table. Patch number 11 seems big but it basically only replaces functions with wrapper functions that call the function pointer from the dispatch table. It also removes the now unnecessary wgl_ext.[c|h] functions and updates the Makefile.
tom