http://bugs.winehq.org/show_bug.cgi?id=17193
--- Comment #2 from Robert Millan rmh@aybabtu.com 2009-02-02 16:28:34 --- (In reply to comment #1)
(In reply to comment #0)
- The pointers in GLINFO_LOCATION are set to NULL when a WGL function is not
present (this was only done for GL ones).
When wglGetProcAddress fails it is guaranteed to return NULL. This is opposed to glXGetProcAddress which isn't required to return NULL. Setting function pointers to NULL is explicitly done for GL extensions because in case of wine we have some evil code where 'pwglGetProcAddress' is directly forwarded to glXGetProcAddress.
Ah, ok.
- Code paths exist to fail gracefully when either wglGetExtensionsStringARB or
wglGetPixelFormatAttribivARB are unimplemented, disabling the functionality associated with them.
(This situation was found when using WineD3D with Chromium OpenGL as implemented in VirtualBox OSE 2.1)
At this point our pixel format code requires WGL_ARB_pixel_format. I could add extra code for a legacy PFD backend but I think it is better to fix Chromium because this extension is very common and basically any serious or modern OpenGL program uses it.
It seems the pixelformat stuff is there, just not being exported (this was known to be the case for GetExtensionsString already, which VBox folks fixed in http://www.virtualbox.org/changeset/16220). But looking at the code in HEAD, wglGetPixelFormatAttribivEXT is exported there:
src/VBox/Additions/WINNT/Graphics/crOpenGL/getprocaddress.py: if (!crStrcmp( name, "wglGetPixelFormatAttribivEXT" )) return (CR_PROC) wglGetPixelFormatAttribivEXT;
So I guess newer builds won't have this problem (I don't have the environment to build this myself).
There's also the question on whether you want to bother supporting previous releases of VirtualBox. If you'd rather not do that, then I guess this bug can be closed.