GLFW load functions - opengl

Question

From Opengl wiki:
There are two phases of OpenGL initialization. The first phase is the
creation of an OpenGL context; the second phase is to load all of the
necessary functions to use OpenGL.
This boilerplate work is done with various OpenGL loading libraries;
So I downloaded GLFW and compiled the demo tests in the library. But find out that the framework merge the windows creation and the context creation into one function call createWindow, in which it first create a window and a context, it then load a few extension functions by initWGLExtensions.
So the context is setup now, without loading any other gl functions. The simple demo then start a msg loop to draw.
int main(void)
{
GLFWwindow* window;
glfwSetErrorCallback(error_callback);
if (!glfwInit())
exit(EXIT_FAILURE);
window = glfwCreateWindow(640, 480, "Simple example", NULL, NULL);
if (!window)
{
glfwTerminate();
exit(EXIT_FAILURE);
}
glfwMakeContextCurrent(window);
glfwSwapInterval(1);
glfwSetKeyCallback(window, key_callback);
while (!glfwWindowShouldClose(window))
{
float ratio;
int width, height;
glfwGetFramebufferSize(window, &width, &height);
ratio = width / (float) height;
glViewport(0, 0, width, height);
glClear(GL_COLOR_BUFFER_BIT);
glMatrixMode(GL_PROJECTION);
glLoadIdentity();
glOrtho(-ratio, ratio, -1.f, 1.f, 1.f, -1.f);
glMatrixMode(GL_MODELVIEW);
glLoadIdentity();
glRotatef((float) glfwGetTime() * 50.f, 0.f, 0.f, 1.f);
glBegin(GL_TRIANGLES);
glColor3f(1.f, 0.f, 0.f);
glVertex3f(-0.6f, -0.4f, 0.f);
glColor3f(0.f, 1.f, 0.f);
glVertex3f(0.6f, -0.4f, 0.f);
glColor3f(0.f, 0.f, 1.f);
glVertex3f(0.f, 0.6f, 0.f);
glEnd();
glfwSwapBuffers(window);
glfwPollEvents();
}
glfwDestroyWindow(window);
glfwTerminate();
exit(EXIT_SUCCESS);
}
So all the rendering command functions comes on the fly? It actually declared in GL.h. So since the framework didn't load these functions from drivers. Where are these functions resident at?[Question]
And all the functions loaded by the GLFW is like
src\wgl_context.h(39):typedef PROC (WINAPI * WGLGETPROCADDRESS_T)(LPCSTR);
src\wgl_context.h(44):#define _glfw_wglGetProcAddress _glfw.wgl.opengl32.GetProcAddress
src\wgl_context.h(89): WGLGETPROCADDRESS_T GetProcAddress;
src\wgl_context.c(42): _glfw_wglGetProcAddress("wglGetExtensionsStringEXT");
src\wgl_context.c(44): _glfw_wglGetProcAddress("wglGetExtensionsStringARB");
src\wgl_context.c(48): _glfw_wglGetProcAddress("wglCreateContextAttribsARB");
src\wgl_context.c(52): _glfw_wglGetProcAddress("wglSwapIntervalEXT");
src\wgl_context.c(56): _glfw_wglGetProcAddress("wglGetPixelFormatAttribivARB");
src\wgl_context.c(289): _glfw.wgl.opengl32.GetProcAddress = (WGLGETPROCADDRESS_T)
src\wgl_context.c(290): GetProcAddress(_glfw.wgl.opengl32.instance, "wglGetProcAddress");
src\wgl_context.c(659): const GLFWglproc proc = (GLFWglproc) _glfw_wglGetProcAddress(procname);
Does this mean that I didn't need to load any other GL functions?[[Question]]
Just sort of confuse about the GL work flow.
UPDATE
Find out those gl function calls are linked to opengl32.lib. What does this mean? That I use the default 1.1 gl implementation by windows10? So, really I don't need to export these functions from a actually driver say nvoglv32.dll​, but use a static linked one in opengl32.lib?

Answer 1

That wording in the OpenGL wiki is a little bit unlucky. The details are a little bit more complicated. There are 3 things to a OpenGL environment:
the operating system ABI (application binary interface) contract
the OpenGL context
the window system integration
Historically the way OpenGL integrates with the OS is a crude hack, with a only poorly designed interface: Since OpenGL is an API designed to talk to the graphics driver it's not some kine of 3rd party library you could install. A certain set of its interfaces must be provided by the operating system. Which interfaces these are exactly are written down in the ABI contract. Of course each OS has it's own contract, and it may even change between versions.
To support newer versions of OpenGL the so called "extension mechanism" is defined, through which functions outside of the ABI contract can be loaded. Functions that are part of the ABI contract may or **may not* be available through this mechanism as well, so don't rely on that assumption.
In Windows (from Win-NT-4 and Win-95B onwards) the ABI contract assures, that a program will always find a conforming OpenGL-1.1 implementations. For sake of simplicity exactly the OpenGL-1.1 entry points are directly exposed by the interface stub library (opengl32.dll, with the symbol table being available through opengl32.lib), nothing less, nothing more. Device drivers then attach to that stub library with their end of the OpenGL implementation, that talks to the hardware. For all OpenGL contexts the OpenGL-1.1 stubs are invariant, i.e. they're the same for all contexts. Extended functionality OTOH are specific to each context. So for each OpenGL context that is created the extension function pointers have to be loaded individually and properly matched to the active context upon calling. It also means, that you first have to create a context (and make it active) before you can even attempt to load its extension functions.
In X11/GLX environments (e.g. Linux, the *BSDs, Solaris) the situation is as following: The ABI contract specifies that if OpenGL is available, then at least functions of OpenGL-1.2 must be exported by OpenGL implementation shared object. This is of particular note! While on Windows there's some vendor neutral stub, on X11/GLX the libGL.so your program dynamically loads is the implementation. Also the libGL.so may export far more symbols, potentially covering all the supported OpenGL features. As a programmer you should not rely on this though. Also in GLX it's asserted that all entry points are context invariant, i.e. you can load them once and reuse for all contexts.
On MacOS-X you get OpenGL through a framework. The ABI contract is per OS version, so the OpenGL functions available to a program are determined entirely by the specific OS version. There is an extension mechanism, but hardly serves any purpose; there are only a few Apple specific extensions exported, so don't even bother with it on the OS of Apple.