Re: crfaker fix

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
> >
> > Do you Yahoo!?
> > New and Improved Yahoo! Mail - Send 10MB messages!
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email sponsored by Black Hat Brief ings & 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
> _______________________________________________
> Chromium-dev mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/chromium-dev
> 
> ------------------------------------------------------------------------
> Do you Yahoo!?
> New and Improved Yahoo! Mail 
> 
> - Send 10MB messages!



-------------------------------------------------------
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
_______________________________________________
Chromium-dev mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/chromium-dev


---------------------------------
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.

		
---------------------------------
Do you Yahoo!?
Read only the mail you want - Yahoo! Mail SpamGuard.