Re: crfaker fix

Ok, I think I've fixed this problem.

I moved the declaration of the glim SPUDispatchTable into the 
NULLfuncs.c file where it can be initialized to point to the 
NULL/no-op functions.

So, calling a GL function before a rendering context is created/bound 
should no longer cause a segfault or anything.

-Brian

Greg Humphreys wrote:
> I agree with Brian -- the call to Viewport is meaningless since it is
> not bound to a context yet.
> 
> However, it's quite conceivable that code like this (that calls OpenGL
> before creating / making current to a context) behaves in a very bad
> way on Chromium (e.g., crashing instead of just doing nothing).
> 
> The "right" thing to do, it seems, is to have the faker have a set of
> "nop" functions that everything is bound to before any SPU has been
> loaded.
> 
> 
> ----- Original Message -----
> From: Ricky Uy <[email protected]>
> Date: Wed, 23 Jun 2004 11:51:57 -0700 (PDT)
> Subject: Re: [Chromium-dev] crfaker fix
> To: Ricky Uy <[email protected]>, Brian Paul <[email protected]>
> Cc: [email protected]
> 
> 
> 
> 
> OK, below is the output from the printspu of a working celestia in
> windows. As can be seen, glViewport is the very first call ever made.
> Putting a call to stubInit() before the jmp in the cr_glViewport in
> windows_exports.c seems to have worked, but I don't feel very good
> about leaving it there. I'm not sure how to resolve this issue, but I
> thought it should be known. There's a couple more apps that do the
> window setup a little sloppy like this, too, and this seems to fix
> those errors, too. I wonder, is glViewport the only gl command that an
> app would ever try to execute before calling any of the wgl
> commands...because then it might be ok to leave the stubInit call
> where it is...
> 
> Ricky
> 
> Viewport( 0, 0, 551, 411 )
> 
> CreateContext( 0012F9E4, 53 )
> 
> = 3000
> 
> CreateContext( 02A51C58, 53 )
> 
> = 3001
> 
> WindowCreate( 02A52100, 53 )
> 
> = 1
> 
> MakeCurrent( 1, -553578510, 3001 )
> 
> Viewport( 0, 0, 551, 411 )
> 
> Viewport( 0, 0, 551, 392 )
> 
> GetString( GL_EXTENSIONS )
> 
> GetIntegerv( GL_MAX_TEXTURE_UNITS, 0x011CD390 )
> 
> GenProgramsARB( 1, 00564928 )
> 
> GetError( )
> 
> 
> 
> Ricky Uy <[email protected]> wrote: 
> I tried putting the stubInit() in all the WGL calls like you
> suggested, but it doesn't resolve the issue. I also have all the wgl
> intercepted calls printing out to a file, and it appears that celestia
> is not calling any wgl functions before it calls ShowWindow() (and
> thus glViewport). Perhaps the celestia code is done a little sloppy
> with the window setup (like the way it calls choosepixelformat AFTER
> showwindow), but chromium _should_ still be able to handle this
> properly.
>  Ricky
> 
> Brian Paul <[email protected]> wrote:
> 
> There must be _some_ WGL function being called before glViewport. At 
> least wglMakeCurrent() must be called to bind a rendering context. 
> Otherwise, the glViewport call is invalid.
> 
> We can call stubInit() from all the wgl/glx functions in the faker. 
> It returns immediately if it's been called before.
> 
> -Brian
> 
> 
> Ricky Uy wrote:
> 
>>You're right, I found the article you mentioned on MSDN. But if that is 
>>the case, then are applications like Celestia doomed to be able to work 
>>on Chromium in their original, unmodified state? In it's unmodified 
>>state, stubInit() is never going to be called before the glViewport() 
>>call, and I don't see any other areas of the crfaker dll where the call 
>>to stubInit() would make sense. Celestia will just call glViewport and 
>>it will immediately get intercepted by windows_exports.c and try to jmp 
>>to an invalid location. I suppose checks could be made in the 
>>windows_exports file to see if stubInit has already been called or not, 
>>but it wouldn't be good to make function calls like that inside of NAKED 
>>functions. Do you know any other places that might be okay for it?
>>
>>*/Greg Humphreys /* wrote:
>>
>>If I recall correctly, this is (was?) explicitly documented in MSDN as
>>being illegal (manual loading of other DLL's within DLLMain). It USED
>>to be there, and then I discovered this, and moved it.
>>
>>--
>>Greg Humphreys, Assistant Professor
>>Department of Computer Science, University of Virginia
>>http://www.cs.virginia.edu/~humper/
>>
>>
>>On Jun 23, 2004, at 11:37 AM, Ricky Uy wrote:
>>
>>
>>>Hi,
>>>
>>>For the Windows version of this library, there should be a call to
>>>stubInit() just before the return in DLLMain() in load.c, and all
>>
>>the
>>
>>>calls to stubInit() should be removed from the wgl functions in
>>
>>wgl.c.
>>
>>>There were several applications that would bail out because of this,
>>>including Celestia for Windows. However with this patch, they all
>>>work.
>>>
>>>The problem was that some applications d on't call wgl functions
>>
>>before
>>
>>>trying to do other things. For example, especially in direct
>>
>>response
>>
>>>to Alicia's post, Celestia would try to call ShowWindow() before
>>>calling ChoosePixelFormat(). This caused a crash because ShowWindow
>>>makes a call to glViewport, and because stubInit() had not yet been
>>>called, the glim dispatch table was nulled out. So there was a
>>
>>crash.
>>
>>>By having stubInit() in DLLMain, issues like these are resolved.
>>>
>>>Now there was a comment above DLLMain saying that Windows didn't
>>
>>allow
>>
>>>the loading of other libraries in DLLMain, and I'm not sure what has
>>>happened since, but it works fine. Hope this helps some people with
>>>their applications.
>>>
>>>Ricky


-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - 
digital self defense, top technical experts, no vendor pitches, 
unmatched networking opportunities. Visit www.blackhat.com