And one more little thing:
1>SlimDX - 0 error(s), 32551 warning(s)
Windows, OpenGL Versions, and Extensions
Something I've noticed any number of times is that many people are quite vague on how OpenGL works on Windows. This causes a lot of confusion about exactly what the limitations on Windows are with respect to versions, and people tend to say things that don't make sense. The most common misunderstanding is that Windows is limited to OpenGL 1.1. It's time to clear things up.
First, let's start by dissecting the basic OpenGL architecture on Windows. When you build your OpenGL based program, you link to opengl32.lib. This file from the Platform SDK is a companion to the opengl32.dll that ships with Windows. The GL/gl.h header you use matches these two files. When your code runs, some behind the scenes work happens that loads up the functions out of opengl32.dll. However, opengl32.dll is a purely software implementation of OpenGL 1.1, and it's probably not what you want to be using. What you want to be using is the real OpenGL DLL, for example nvoglnt.dll. This file is installed with your video driver.
This is where magic starts to happen. Your calls to opengl32.dll will be redirected to the actual driver specific DLL, which exports at least all the functions in opengl32.dll. The trick is, it also exports a lot more than that. The entire OpenGL API for the version that it supports will be exported, along with all the extensions. Calls to wglGetProcAddress become GetProcAddress calls on the OpenGL DLL that came from the driver. This isn't limited to extensions; you can use it on regular non-extension functions as long as the video driver supports a version of OpenGL that includes them.
The problem here is that, depending on the manufacturer of your video driver and the version, the real DLL that implements OpenGL could be anywhere. Windows provides opengl32.dll as a common place to go to, instead of having to figure out what DLL you need at runtime. That DLL also servves the dual purpose of providing the basic software implementation. That's why it's nearly never been updated; adding new OpenGL functions would mean writing code to implement all of that in software. In Vista they decided to provide a new version built on D3D instead of software, so applications using the Vista headers and libraries can get a baseline of OpenGL 1.4 statically.
All that an extension loader does, then, is to automate the tedious process of making the dozens or hundreds of GetProcAddress calls to retrieve the functions that aren't statically linked and forwarded. Again, these functions don't have to be extensions. You can wglGetProcAddress for glMapBuffer, not just glMapBufferARB. There's no question of what Windows supports. It doesn't matter. The only function you actually need from Windows is wglGetProcAddress, which is your key to accessing the real OpenGL DLL. The rest of the interface is just a convenience in that you don't have to go out and get the addresses for the OpenGL 1.1 functions, since they're already being redirected for you. And since modern extension loaders are machine generated systems that automatically look up everything, it's less relevant than ever before.
[grin]