Talk:Platform specifics: Windows
This webpage is casual, unprofessional, very old, and full of bias against Windows. Today is in the middle of year 2018, so this webpage should be rewritten and overhauled by a Windows developer in order to have an accurate and technically objective replacement.
The wiki page says this:
--- Note: It has been reported that wglGetProcAddress fails for functions that are already present in opengl32.dll. Do not try to get a function pointer for glVertex3f, glBegin, glBindTexture, glEnable and the many other GL 1.0 and 1.1 functions. It has also been reported that GetProcAddress works on the GL 1.0/1.1 functions.
Could we please hear more on this issue? I can't find any reliable sources to back up this advice about not loading 1.1 functions via wglGetProcAddress. This wiki page doesn't even mention why exactly 1.1 functions shouldn't be loaded via wglGetProcAddress, so the whole thing feels rather unsettling. Could it just be that these reports come from a few users with obscure and broken graphics drivers who are sitting in the middle of some uninhabited wasteland, and who most developers probably don't care about anyway? GLEE and GLEW both seem to follow this advice of loading 1.1 functions by means other than wglGetProcAddress, but their comments and documentation fail to mention why. I've scowered the internet, but the information this issue is almost non-existent.
And please, don't tell me to hush up and just use GLEW or GLEE. I very much want to get to the bottom of this, just out of curiosity.
- There is no "why"; wglGetProcAddress will not return valid pointers for 1.0 or 1.1 core functions. It won't. There's no explanation for it, there's no justification for it. It simply will not do it. Therefore, all GL extension loading software on Windows has to find some way around it. Alfonse 16:04, 6 August 2011 (PDT)