PDA

View Full Version : opengl32.dll patch for debug



amanieux
08-25-2003, 12:07 AM
I am also trying to write my own window opengl32.dll in order to help debugging my
apps, I am exporting all the original opengl32.dll functions and I
implemented all functions like this:

void APIENTRY glBegin (GLenum mode)
{
if (!hDLL) hDLL = LoadLibrary(OPENGL32_PATH);
lp_glBegin func = (lp_glBegin)GetProcAddress(hDLL,"glBegin");
DEBUG_TEXT1("glBegin")
func(mode);
}

When I put my new opengl32.dll in a test application's folder, the program
runs fine (it loads my DLL which correctly loads the original DLL and all
the opengl functions are called, and passed thru to the original. It works with a great number of windows versions and graphic cards but with nvidia cards under NT4 or with ati rage cards un win2000 there is no crashing or anything.. but my program's window remains gray(or transparant = no pixels drawn on the screen over the desktop )!
The program really runs, because i can see my debug info normally.. but the window remains gray(or transparant)!

anybody ever done this or had similar problems?

evanGLizr
08-25-2003, 05:29 AM
Originally posted by amanieux:

I am also trying to write my own window opengl32.dll in order to help debugging my
apps, I am exporting all the original opengl32.dll functions and I
implemented all functions like this:

void APIENTRY glBegin (GLenum mode)
{
if (!hDLL) hDLL = LoadLibrary(OPENGL32_PATH);
lp_glBegin func = (lp_glBegin)GetProcAddress(hDLL,"glBegin");
DEBUG_TEXT1("glBegin")
func(mode);
}

[...]

anybody ever done this or had similar problems?

You can check glTrace (http://www.hawksoft.com/gltrace/) for a working opengl32.dll wrapper. My guess is that your wrapper is not passing the parameters properly to some initialisation function.

You don't need to check hDLL on each call, either, just load it at DLL startup time (checking dwReason parameter in DllMain function).

[This message has been edited by evanGLizr (edited 08-25-2003).]

al_bob
08-25-2003, 11:26 AM
You don't need to check hDLL on each call, either, just load it at DLL startup time (checking dwReason parameter in DllMain function).
You can't do that though.

From http://msdn.microsoft.com/library/en-us/dllproc/base/dllmain.asp :

Warning The entry-point function should perform only simple initialization or termination tasks. It must not call the LoadLibrary or LoadLibraryEx function (or a function that calls these functions), because this may create dependency loops in the DLL load order. This can result in a DLL being used before the system has executed its initialization code.

Edit: Fixed UBB

[This message has been edited by al_bob (edited 08-25-2003).]

Overmind
08-25-2003, 11:38 AM
You should not doesn't mean that you can't.

This is simply a warning that you can seriously crash windows when calling LoadLibrary in a library initialisation function AND you have a circular dependency. But since you know that your DLL is only loaded by an application and not by another DLL (because it is not in the win32/system directory), it should be safe to do it.

al_bob
08-25-2003, 11:45 AM
Can you garantee that opengl32.dll that you'll load won't itself load other DLLs which might cause problems? Can you garentee the driver won't do that? There's a lot of unknown code you're sitting on.

rgpc
08-25-2003, 09:13 PM
Q2 used LoadLibrary to ensure the correct driver was loaded and it seemed to work OK...

al_bob
08-25-2003, 09:14 PM
Q2 most likely does not use LoadLibrary() inside DllMain().

*Aaron*
08-26-2003, 08:10 AM
Assuming you have the source of the programs you're debugging, you can just call LoadLibrary at the beginning of your program and assign the result to a global HINSTANCE. While you're at it, you might as well load all the OpenGL entry points you plan to use at this time. It might make your debugging code a bit faster.

rgpc
08-26-2003, 06:43 PM
Originally posted by al_bob:
Q2 most likely does not use LoadLibrary() inside DllMain().

You're right. Silly me...

knackered
08-27-2003, 01:01 AM
what are you talking about? so long as he doesn't load a DLL that directly or indirectly loads his own DLL again, then there will be no problem.

amanieux
08-27-2003, 07:28 AM
thank you for the idea of gltrace but they have the same problem : when opengl32 is patched with their dll, even the basic rendering of a single triangle in a windows stop workings !! (i recall that this problem only occurs with NT4 + nvidia) - there must be a problem with nvidia NT4 ICD (nvoglnt.dll).

evanGLizr
08-27-2003, 08:35 AM
Originally posted by amanieux:
thank you for the idea of gltrace but they have the same problem : when opengl32 is patched with their dll, even the basic rendering of a single triangle in a windows stop workings !! (i recall that this problem only occurs with NT4 + nvidia) - there must be a problem with nvidia NT4 ICD (nvoglnt.dll).

I guess there's some function called by GDI in NT that is not implemented in gltrace's/your OpenGL32.dll wrapper, look at opengl32.dll in NT and see if they export some extra function.

Another possibility is that the ordinal export scheme varies between the wrapper and the original DLL (GDI in NT could be trying to import from opengl32.dll by ordinal).

wintal
08-27-2003, 09:28 PM
Originally posted by Overmind:
You should not doesn't mean that you can't.

This is simply a warning that you can seriously crash windows when calling LoadLibrary in a library initialisation function AND you have a circular dependency. But since you know that your DLL is only loaded by an application and not by another DLL (because it is not in the win32/system directory), it should be safe to do it.

Actually, this is not true. Something about an OS loader global lock. Apparently anything using managed and unmanaged code can cause this due to bugs in the .NET framework startup stuff http://www.opengl.org/discussion_boards/ubb/wink.gif

Check out: http://blogs.gotdotnet.com/cbrumme/





[This message has been edited by wintal (edited 08-27-2003).]

amanieux
08-28-2003, 12:20 AM
>Another possibility is that the ordinal export scheme varies between the wrapper and the original DLL (GDI in NT could be trying to import from opengl32.dll by ordinal).

i exported everything even the undocumented function like glDegugEntry()and it was done with the same ordinal !

as i can't find any explaination i am thinking of connecting my dll patch between the real ms opengl32.dll and the IHV opengl ICD (nvoglnt.dll or Atio9xxx.dll) has anyone got info on the ICD mechanism ?(the principle is described here : http://www.asus.com.tw/support/english/techref/opengl/index.aspx)

thanks

matt_weird
08-28-2003, 10:21 AM
..maybe this would ring a bell http://www.opengl.org/discussion_boards/ubb/wink.gif :


5.200 Why does my code produce a black screen under Windows NT or 2000 but run fine under 9x?

Incorrect mixing of GDI and wgl functions may result in OpenGL functioning correctly under Windows 95 and not functioning correctly under Windows NT/2000. Incorrect functioning will result in a black OpenGL window under Windows NT/2000.


5.190 What do I need to know about mixing WGL and GDI calls?

On the Win32 platform a number of platform specific function calls are duplicated in the OpenGL ICD mechanism and the GDI. This may cause confusion as they appear to be functionally identical, the only difference being whether wgl precedes the rest of the function name. To ensure correct operation of OpenGL use ChoosePixelformat, DescribePixelformat, GetPixelformat, SetPixelformat, and SwapBuffers, instead of the wgl equivalents, wglChoosePixelformat, wglDescribePixelformat, wglGetPixelformat, wglSetPixelformat, and wglSwapBuffers. In all other cases use the wgl function where available. Using the five wgl functions is only of interest to developers run-time linking to an OpenGL driver. Not using the functions as described may result in a black OpenGL window, or a correctly functioning application in Windows 9x that produces a black OpenGL window on Windows NT/2000.

http://www.opengl.org/developers/faqs/technical/mswindows.htm

V-man
08-29-2003, 10:04 AM
I should say that when you call the GDI lookalikes, they eventually call the wgl ones. I`m not sure if this is true for all of them, since I didn`t test them all.

In my opinion, MS has made some odd design decisions here. Anyone know why there are the GDI functions and also the wgl lookalikes?

matt_weird
08-29-2003, 11:56 AM
Originally posted by V-man:
I should say that when you call the GDI lookalikes, they eventually call the wgl ones.

Quite contrary, i must say: wgl functions are wrappers for GDI functions, to provide system dependent tasks that wgl cannot have any idea how to handle. (at least, that is the way opengl32.dll is implemented http://www.opengl.org/discussion_boards/ubb/wink.gif)


Originally posted by V-man:
In my opinion, MS has made some odd design decisions here. Anyone know why there are the GDI functions and also the wgl lookalikes?

i suppose wgl lookalikes are provided for the standart compatibility reason. Even though wgl are extensions to the standard, they make it easier to provide platform dependent code. You could use GDI ones for a rendering context creation and management in win32, but that would take some additional workaround -- which is already done for you in opengl32.dll http://www.opengl.org/discussion_boards/ubb/smile.gif

Here's a good source that explains the problem of run-time linking to the ICD, why GDI API does make troubles there, plus it points out that problem with NT/2000 described in this thread:
http://www.hardwidge.pwp.blueyonder.co.uk/html/features/tutorials/tutorial2.htm


The OpenGL API on the Windows platform is comprised of OpenGL functions and system specific extensions to the standard. These extensions are allowed by the OpenGL specification, as OpenGL itself does not have any functions for Window creation or initialisation. When using the Windows ICD mechanism, a number of these extensions go through another part of the OS, known as the GDI, prior to arriving at the driver. This creates a situation where linking to the Windows OpenGL ICD mechanism must be handled differently from direct linking to another API implementation. If the Windows OpenGL ICD mechanism is not handled correctly, OpenGL may not function correctly across all Win32 platforms. At the time of writing it is known that an incorrect implementation may function on Windows 9x, and not on Windows NT and Windows 2000. In addition, the Windows font extensions to the OpenGL standard are also implemented differently, dependent on whether compilation occurs on a unicode or non-unicode platform.

[This message has been edited by matt_weird (edited 08-29-2003).]