This is a polymorphism and versioning problem.
On Windows (and any other multitasking capable OS for that matter), there can be multiple OpenGL applications running, each in their separate windows, on different physical display devices (both graphics cards and monitors), with different pixel formats.
There absolutely needs to be a ‘glue’ to bind this to the operating system, so that the gl calls can be dispatched to the correct implementation, i.e. the one that drives the monitor where the context is visible.
Or to offer a more serious issue, what happens to a window that spans two monitors, each driven by a different graphics card (maybe even based on different chips from different manufacturers)?
So you see, there is no “the” GL implementation. As such there is no way around the glue that selects the correct one. Even if you use a single monitor and a single graphics card, there are still cases where a software fallback is necessary (when the pixel format can’t be accelerated, eg stencil buffering in 16 bpp on a Geforce 2MX or something).
This glue is Opengl32.dll, provided by Microsoft, and it’s been in hiatus for a hundred years or so. This is the cause of all our pain, because it’s stuck at a prehistoric GL version and as such can neither offer entry points for GL1.5 functions, nor can it act as a software rendering fallback for GL1.5.
However, replacing it isn’t as easy as it may seem, because it touches OS turf (window positions, screen modes, hardware enumeration).
Don’t get me wrong, it would be great if there was a major update to this DLL. But IMO - to keep it clean - it must be sanctioned by Microsoft if it happens, and this just isn’t going to happen. You’d better learn your way around this sooner rather than later.