Patch for opengl32.dll.so

[Roderick Colenbrander]

> Roderick Colenbrander wrote:
> >> Roderick Colenbrander wrote :
> >>     
> >>>> On 11/1/06, Bertrand Coconnier <bcoconni at club-internet.fr> wrote:
> >>>>         
> >>>>> Hi,
> >>>>>
> >>>>> The last release of Wine 0.9.24 contains an error in the code of
> >>>>>           
> >>>> opengl32.dll.so
> >>>>         
> >>>>> under X11 : Wine tries to get the address of "wglGetIntegerv" (line
> >>>>>           
> >> 608
> >>     
> >>>> of
> >>>>         
> >>>>> dlls/opengl32/wgl.c) before the extensions of WGL have actually been
> >>>>>           
> >>>> loaded
> >>>>         
> >>>>> (i.e. before X11DRV_WineGL_LoadExtensions() is called). The reading
> of
> >>>>>           
> >>>> the
> >>>>         
> >>>>> wglGetIntegerv address fails and afterwards, whenever
> >>>>>           
> >>>> internal_glGetIntegerv()
> >>>>         
> >>>>> is called, wine_wgl.p_wglGetIntegerv is NULL and a Fatal Exception
> is
> >>>>>           
> >>>> raised.
> >>>>
> >>>>
> >>>> This is probably already fixed in the git tree.  See the commit:
> >>>> winex11.drv: Fixed the prototype of many OpenGL functions.
> >>>>
> >>>> Jesse
> >>>>         
> >>> Else if the problem still happens something strange is going as the
> >>>       
> >> extensions are registered at x11drv startup.
> >>     
> >>> Roderick
> >>>       
> >> Yes, the problem still happens because the function process_attach()
> (line
> >> 582 
> >> of dlls/opengl32/wgl.c) is called before the x11drv startup. The
> comment
> >> of 
> >> process_attach is very clear : "/* This is for brain-dead applications
> >> that use 
> >> OpenGL functions before even creating a rendering context.... */". It
> is
> >> clear 
> >> that process_attach is a workaround for *brain-dead* apps :) and among
> >> other 
> >> things it gets the address of wglGetIntegerv. This operation used to
> >> succeed as 
> >> long as GetProcAddress() was used but now since x11drv is needed to
> upload
> >> the 
> >> wglGetIntegerv address there is some kind of race condition and the
> >> operation 
> >> fails hence the bug.
> >>
> >> Bertrand.
> >>     
> >
> > Compared to 0.9.23 I changed the way wglGetIntegerv is loaded before it
> was directly loaded using GetProcAddress from winex11.drv now it is still
> loaded from winex11.drv but then using wglGetProcAddress from gdi32. At wine
> startup (I'm not sure at which stage but I believe directly when you use
> gdi stuff or perhaps even earlier) winex11.drv is initialized and during
> this initialization my opengl code is initialized aswell. I wonder what causes
> the race as I haven't seen it happening for other users yet. I want to
> avoid a patch like yours as I plan to do similar things for some other
> functions.
> >
> > Perhaps something goes wrong in wglGetProcAddress itself. Try running
> wine using: WINEDEBUG=+wgl,+opengl wine wow.exe -opengl &> log. If it is
> correct you'll see some opengl information (gl version, loading of extensions)
> before stuff happens in opengl32.dll.
> >
> > Roderick
> >   
> Hi Roderick, do you have a patch for this problem, since 0.23 a number 
> of wow users seem to be getting a crash at startup that didn't happen 
> before 0.23 or 0.22, can't remember which, only some users not all.
> 
> I just wondered if this is the fix for it, if we could try it out ?
> 
> Regards
> Nick

Hmm, if that is indeed the case this patch could work for them. The whole issue is new for me, I'll see what I can do about it. Right now there's some GLX code in opengl32 which creates an opengl context. I was planning to replace it with WGL code, that might help too (if I load the function pointers afterwards). Perhaps Alexandre has an idea how to correctly fight the race condition.

Roderick
-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer