Search code examples
opengldirectoryinclude

Does OpenGL library include directory not need to be specified in settings in visual studio?

I have a OpenGL program that works and I just realised haven't even specified an include directory that contains the OpenGL library. How can this be? I heard "the OpenGL library comes with the Microsoft SDK", (I don't know what an SDK is) but does that mean that the "Microsoft SDK" is by default an additional include directory?

Solution

  • Unlike Vulkan (for the moment), OpenGL library landed to Windows system a long time ago, so that opengl32.dll is a system library and necessary development files (GL/gl.h and opengl32.lib) are shipped with Windows SDK, which is integral part of Visual Studio installation and development for Windows platform.

    So that indeed, normally you have nothing to install in addition to Windows SDK (previously called Platform SDK) to start using OpenGL. Note that unlike OpenGL, Direct3D development libraries were distributed separately via DirectX SDK for a long time, but they also become part of Windows SDK starting from Windows 8.

    If you will take a look into VS project settings, you will find variables like WindowsSDK_IncludePath: VC++ directories

    Normally, Visual Studio is installed with Windows SDK and automatically prepends necessary search paths to all projects. But it is also possible messing-up with these settings in local VS installation (or in specific project by overriding "inherit from parent or project defaults" checkboxes), or VS installer might mess up paths while installing several versions of VS in parallel and relying on different versions of Windows SDK.

    It should be noted, that opengl32.dll coming with Windows itself is nothing but a proxy DLL loading OpenGL libraries installed with GPU drivers.

    What help you might need are help files like glext.h providing definitions for OpenGL functions introduced in OpenGL 1.2+, as system headers and library expose only OpenGL 1.1 functions, while newer functions should be dynamically retrieved via wglGetProcAddress().

    This is similar in Android, where Android NDK is shipped together with OpenGL ES libraries and headers, but accompanied by glext.h of some revision, and it also has GLES 1/2/3, so that application might avoid loading functions dynamically if it will be used on new Android devices without backward compatibility.

    The same is with macOS/iOS SDKs, which also include OpenGL / OpenGL ES framework as part of platform SDK. Unlike other systems, macOS does not expose any GetProcAddress() for retrieving OpenGL function pointers, so that newer OpenGL versions require newer version of macOS itself or use macOS linker specific tricks. Although OpenGL was marked as deprecated in recent versions of macOS SDKs, so that in future macOS might abandon any means of open multi-platform APIs and push developers writing application exclusively for their platform using proprietary standards. It is still possible, though, that external OpenGL library developed on native macOS APIs will be introduced (like MoltenVK for Vulkan support).

    This is a little bit different for desktop Linux platforms, where OpenGL libraries are installed as separate development packages like libgl1-mesa-dev in Debian. They also expose definition of newer OpenGL versions, so that it is possible avoiding glXGetProcAddress()/eglGetProcAddress() in case if compatibility with old Linux versions is not required.