I Cannot find entry point for GLGENBUFFERS for OPENGL32.DLL

OpenGL OpenGL: Basic Coding
1

I Cannot find entry point for GLGENBUFFERS for OPENGL32.DLL

my graphics card is NVIDIA GFORCE GTX1060 (6GB), using the latest version of 375.70.
Should be able to support OPENGL 4.4.

2

Opengl32.dll is the Microsoft OpenGL 1.1 implementation. You won’t be able to find your function here.

Use glew in order to get the newer functionalities.

3

how can I fix this ?

4

As just said, use glew. This will fix it.

5

Note that what GLEW is doing under the hood is essentially:


PFNGLGENBUFFERSPROC *glGenBuffers;
...
    glGenBuffers = wglGetProcAddress("glGenBuffers");

opengl32.dll only exports the OpenGL 1.1 API. For any other function, you need to use wglGetProcAddress() to obtain a pointer to the function from the driver, or have a library such as GLEW do it for you.

If you only need a few such functions, it may be simpler to query pointers manually. If you need many such functions, or you need cross-platform compatibility, you’re better off using GLEW (even if getting it working is more awkward than it should be).

6

Yes, but it might even be a bit more complicated. The OP will then need an updated version of glext.h and certainly an updated version of gl.h. Or to define himself what PFNGLGENBUFFERSPROC is (and same for any other functions) and the same for all enums and so on…

7

Just to clarify, calling GetProcAddress on the builtin Windows opengl32.dll will never give you any functionality higher than OpenGL 1.1; because this DLL does not contain any sugh higher functionality.

This DLL is not your GL implementation; your GL implementation is provided by your GPU driver. This DLL is a software implementation that can be used as a fallback in the absence of a GPU driver, but otherwise all that it does is (1) determine what the real OpenGL DLL used by your GPU driver is, and (2) route GL calls to that real DLL.

In order to access higher functionality you must use the extension loading mechanism, which is not the same thing as using extensions. In practice this means doing a bunch of wglGetProcAddress calls - this is different to standard GetProcAddress in that the call is handled by opengl32.dll and routed to the correct GL driver for your GPU. That’s why calling GetProcAddress on opengl32.dll won’t work - because you don’t have knowledge of what the correct driver DLL is.

And no, it’s not good enough to dive into the registry and find it for yourself - use the correct loading mechanism instead, and that way your program will continue to work even if the underlying platform archiecture is changed in a future version of Windows.

All this is a load of busy work with little in the way of payoff, which is why people always advise to use something like GLEW instead.

8

True. It can however remove some ugliness and bug-like coding with glew functions I can seldom see people having here and there.

9

One situation where you may need to do it the hard way is if you’re dealing with multiple displays. The function pointers returned by wglGetProcAddress() can be different for different contexts. In practice, they’ll only be different if the contexts use different drivers, i.e. you have multiple displays using different video hardware and you’re using both in the same program.

In that situation, you can’t just store the pointers in global variables, but need to use per-display structures. But in that situation, the function pointers are the least of the issues, as the OpenGL version, supported extensions etc can vary between displays, and contexts on different displays can’t share data (textures, buffers, programs, etc).