Where OpenGL 2.1 located in the driver package

Hi everyone,

I have installed a driver for GT9400 card. But there is no opengl32.lib in the Program Files/NVIdia Corporation/ directory. Where it is located? I want to link my program to a newer opengl version.
Os is Windows XP

This is not how OpenGL under Windows works.

The opengl32.dll and opengl32.lib come from Microsoft and you need to link against that.
The DLL contains Microsoft’s software OpenGL 1.1 implementation as well as the mechanism to load OpenGL “Installable Client Drivers” (ICD) which get installed on your system along with the display drivers for your graphics board. These vendor specific ICDs implement newer OpenGL versions for your GPU.

What you do inside your application is to link against Microsoft’s opengl32.lib which loads the opengl32.dll which then loads the GPU vendor’s installable client driver at runtime.
Everything from then on is a matter of enumerating the OpenGL pixelformats and selecting the one which uses the OpenGL implementation you want your application to run on.

Additionally using any functionality beyond OpenGL 1.1 under Windows requires to get the OpenGL entry point function pointers added to these versions. Similarly for OpenGL extensions.
To ease that work there are utility libraries like GLEW http://glew.sourceforge.net/ which take care of getting all available entry point function pointers with a few calls in your application.

Thanks a lot for an descriptive answer. I have faced a problem with my simple OPenGL application.
It behaves strange on Windows XP. But ok on Win7. What is the best place to ask about that issue?

Just ask here.

Describe what problem you’re experiencing when doing what exactly in your application and what you did to analyze or correct the issue.

It’s possible to do implementation dependent errors in an OpenGL application which would result in failures under Windows XP but work under Vista and up. Most of these are in the area of how OpenGL’s pixel ownership test or SwapBuffers work.

If you compare the behavior on two different OSes, provide the system information for both, esp. installed GPUs and display driver versions.

I have simple OpenGL application. It is written using pure WinAPI. It creates a simple window and colors it with black color.
There is the code below. I’m processing WM_PAINT and WM_SIZE messages.
The problem is the following:
I launch this application and the window is on upon a desktop. No other windows are opened.
When i hover cursor over start button or over the close cross the toolltip appear. The window is got repainted with the desktop color. Blue in my case. Some icons from desktop are painted in my window.
The strange thing is that windows receives no messages during repaint. I sniffed it with Spy++ program.
I have absolutely no idea what can cause such problem.
If you don’t understand what is going on i can make a short video clip of what is going on.

#include <stdio.h>
#include <windows.h>
#include <gl\gl.h>
#include <gl\glu.h>

HDC hDC=NULL;
HGLRC hRC=NULL;
HWND hWnd=NULL;
HINSTANCE hInstance;

bool keys[256];
bool active=TRUE;
bool fullscreen=TRUE;

LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);

GLvoid ReSizeGLScene(GLsizei width, GLsizei height)
{
    if (height==0)height=1;

    glViewport(0,0,width,height);
    glMatrixMode(GL_PROJECTION);
    glLoadIdentity();
    gluPerspective(45.0f,(GLfloat)width/(GLfloat)height,0.1f,100.0f);
    glMatrixMode(GL_MODELVIEW);
    glLoadIdentity();
}

int InitGL(GLvoid)
{
    glShadeModel(GL_SMOOTH);
    glClearColor(0.0f, 0.0f, 0.0f, 0.5f);
    glClearDepth(1.0f);
    glEnable(GL_DEPTH_TEST);
    glDepthFunc(GL_LEQUAL);
    glHint(GL_PERSPECTIVE_CORRECTION_HINT, GL_NICEST);
    return TRUE;
}

int DrawGLScene(GLvoid)
{
    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
    glLoadIdentity();
    return TRUE;
}

BOOL CreateGLWindow(char* title, int width, int height, int bits, bool fullscreenflag)
{
    GLuint PixelFormat;
    WNDCLASS wc;
    DWORD dwExStyle;
    DWORD dwStyle;
    RECT WindowRect;
    WindowRect.left=(long)0;
    WindowRect.right=(long)width;
    WindowRect.top=(long)0;
    WindowRect.bottom=(long)height;
    fullscreen=fullscreenflag;

    hInstance = GetModuleHandle(NULL);
    wc.style = CS_HREDRAW | CS_VREDRAW | CS_OWNDC;
    wc.lpfnWndProc = (WNDPROC) WndProc;
    wc.cbClsExtra = 0;
    wc.cbWndExtra = 0;
    wc.hInstance = hInstance;
    wc.hIcon = LoadIcon(NULL, IDI_WINLOGO);
    wc.hCursor = LoadCursor(NULL, IDC_ARROW);
    wc.hbrBackground = NULL;
    wc.lpszMenuName = NULL;
    wc.lpszClassName = "OpenGL";

    if (!RegisterClass(&wc))
    {
        MessageBox(NULL,"Failed To Register The Window Class.","ERROR",MB_OK|MB_ICONEXCLAMATION);
        return FALSE;
    }

    dwExStyle=WS_EX_APPWINDOW | WS_EX_WINDOWEDGE;
    dwStyle=WS_OVERLAPPEDWINDOW;

    AdjustWindowRectEx(&WindowRect, dwStyle, FALSE, dwExStyle);

    // Create The Window
    if (!(hWnd=CreateWindowEx( dwExStyle,"OpenGL", title,dwStyle |
        WS_CLIPSIBLINGS |WS_CLIPCHILDREN,0, 0,WindowRect.right-WindowRect.left,
        WindowRect.bottom-
        WindowRect.top,NULL,NULL,hInstance,NULL)))return FALSE;

    static PIXELFORMATDESCRIPTOR pfd=
    {
        sizeof(PIXELFORMATDESCRIPTOR),
        1,
        PFD_DRAW_TO_WINDOW |
        PFD_SUPPORT_OPENGL |
        PFD_DOUBLEBUFFER,
        PFD_TYPE_RGBA,
        bits,
        0, 0, 0, 0, 0, 0,
        0,
        0,
        0,
        0, 0, 0, 0,
        16,
        0,
        0,
        PFD_MAIN_PLANE,
        0,
        0, 0, 0
    };

    if (!(hDC=GetDC(hWnd))) return FALSE;
    if (!(PixelFormat=ChoosePixelFormat(hDC,&pfd))) return FALSE;
    if(!SetPixelFormat(hDC,PixelFormat,&pfd))return FALSE;
    if (!(hRC=wglCreateContext(hDC)))return FALSE;
    if(!wglMakeCurrent(hDC,hRC))return FALSE;
    ShowWindow(hWnd,SW_SHOW);
    SetForegroundWindow(hWnd);
    SetFocus(hWnd);
    ReSizeGLScene(width, height);
    if (!InitGL())return FALSE;
    return TRUE;
}

LRESULT CALLBACK WndProc( HWND hWnd, UINT uMsg, WPARAM wParam, LPARAM lParam)
{
    wchar_t buffer[256];
    swprintf(buffer,L"message is: %d\n");
    OutputDebugStringW(buffer);
    switch (uMsg)
    {
    case WM_SIZE:
        {
            ReSizeGLScene(LOWORD(lParam),HIWORD(lParam));
            return 0;
        }
    case WM_PAINT:
        {
            DrawGLScene();
            SwapBuffers(hDC);
            RECT rect;
            GetClientRect(hWnd,&rect);
            ValidateRect(hWnd,&rect);
            return 0;
        }
    }
    return DefWindowProc(hWnd,uMsg,wParam,lParam);
}

int WINAPI WinMain( HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nCmdShow)
{
    MSG msg;
    BOOL done=FALSE;
    fullscreen=FALSE;
    CreateGLWindow("NeHe's OpenGL Framework",640,480,16,fullscreen);
    while(GetMessage(&msg,NULL,0,0))
    {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }

    return 0;
}

No need for a video. There is nothing wrong with your OpenGL program.

Possible display driver bugs aside, this is mainly a Windows XP issue:
The tooltips and other temporary window elements (menu shadows, etc.) are implemented as “sprites” in Windows XP. These sprites save and restore the 2D windows region below the area they draw on into a temporary 2D image and when they close, the background gets restored from that temporary 2D image without any additional repaint events, and that’s exactly the problem.

This mechanism doesn’t know of any OpenGL buffers! It only uses the Windows desktop image data. Means it’s even worse for quad-buffered stereo.

For example, if your application renders with OpenGL while such a sprite is displayed, the data “below” that tooltip would need to change but doesn’t after it got restored because the temporarily stored data is from an older frame.
“Below” is in quotation marks, because an OpenGL implementation wouldn’t even need to render in these areas because the pixel ownership test fails for these regions. Means a repaint is a must there! The sprite mechanism on such windows is broken by design.

This happens for example with any of the animated menus, menu shadows, and some more fancy (performance reducing) eye-candy effects in Windows XP.
What gets restored is a matter of where that sprite takes its 2D image data from. Normally that should be the currently displayed desktop.
Sometimes it’s enough to disable these fancy menu animations and shadow effects.

In the case where an OpenGL program is continuously animating and menus restore an old frame, this solves itself in the next repaint. Applications which are more clever about their repaint behavior can run into this OS issue anyway.

Windows Vista and up don’t have this problem while running the desktop compositor because that repaints things from unclipped offscreen buffers which contain the current data. I think that sprites issue might happen there as well if you disable the compositor.

It’s unclear why the restore mechanism picks some data which is not displayed on the current desktop in your case. But even if there is a driver issue you’re out of luck with Windows XP and/or that old graphics board.

If you’re really still using Windows XP although it’s not supported anymore, try to disable all fancy display effects like sliding menus, menu shadows, windows shadows, mouse shadows, use a monochrome mouse cursor (hardware cursor), no trailing mouse cursors and other windows animation effects. That will improve UI performance and reduce the potential for this sprite restore error.
Or change your application to repaint more often.

Thanks a lot,
I googled a lot about that but found nothing.
There is one more thing that i don’t really understand.
I have an old MFC application which uses GDI to draw inside the window.
It doesn’t have this effect. Does that means that WinXP processes GDI buffers correct when dealing with sprites?

That’s Windows display driver engineering knowledge from before WDDM times.
This is part of the functionality involved: https://msdn.microsoft.com/en-us/library/windows/hardware/ff564193%28v=vs.85%29.aspx

GDI works because that normally renders into the desktop front buffer and doesn’t know about back, depth, stencil or right buffers like OpenGL. The sprites concept is designed for that GDI usage.

I think that this should generally work with applications which have presented their OpenGL contents to the Windows XP desktop (front buffer) and are not animating. In case of possible driver bugs in your specific configuration you could only try the latest available display driver which is 340.52 from July 29, 2014.

Thanks