OpenGL is legacy/deprecated on Windows?

[bbanelli]

Greetings to all,

I was skimming through Windows API Index and under "Deprecated or legacy APIs" you can find OpenGL.

Any particular reason (except for pushing D3D) for OGL being deprecated, and which exactly is it, legacy or deprecated? If any of those, how come did PB include OGL Gadget only very limited time ago? I couldn't find any relevant reference about OGL being expeled from Windows API in any particular time, if such reference exists in the first place.

With my best,

Bruno

[idle]

I'd guess it's meaning that the provided microsoft headers only support opengl 1.1 or something like that

[Danilo]

Do you refer to the following?

- Archive - Graphics - Legacy Graphics:

Legacy Graphics

• GDI
• GDI+
• Monitor Configuration
• OpenGL
• Picture Acquisition
• Windows Color System
• WPF Bitmap Effects

In this case it simply means this old technology will not be updated anymore. It is not removed and
will still be there for some time, for compatibility with old applications.

There are newer, more modern, APIs that replaced the old stuff:
- .NET and CLR with DirectX hardware-accelerated WPF GUI (and much more)
- Win 8 'Modern UI' apps based on Windows Runtime

In case of OpenGL, it depends on the installed driver. With a current OGL driver from a graphics card manifacturer
you can run/develop latest OGL stuff. It just may need external headers, like idle said already.

AFAIK 'Modern UI' apps are DX only (on Desktop, Tablets, Phones). Never heard about using OGL with it.
With Windows 8.x /ARM (Windows RT) and Windows Phone 8.x you use Windows Runtime exclusively. No WinAPI, OpenGL, GDI/GDI+, etc.

[luis]

I wouldn't worry about OpenGL on Windows, it's not going anywhere (for the foreseeable future, at least)

Microsoft Windows opengl32.dll shipped with the OS provides OpenGL support for versions ranging from 1.1 up to 1.4 (I think, going by memory) depending on the OS version. So it's outdated.

But no one ever use that alone. Even in late 90s for real accelerated OpenGL companies like 3dfx provided their own MiniGL implementation -> http://en.wikipedia.org/wiki/MiniGL

Today when you buy a graphic card with OpenGL capabilities you get an ICD (Installable Client Driver) and that one provides full hardware accelerated support for your card. Even if MS were to remove opengl32.dll (very unlikely), one could simply replace it with its own pointing to the stuff inside the ICD.

Programmatically you import from the Microsoft DLL the OpenGL functions up to 1.1, and some wgl_ (opposed to gl_) functions which are Windows specific and are used to select the pixel format to be used for your screen, create the rendering context, associate the context to your thread and most importantly you the get a wglGetProcAddress() which you will use the get the function pointers for the OpenGL commands >= 1.2 which resides in the ICD.
Actually not all wgl_ are inside the ICD, some are independent from the implementation and are inside the GDI, others are wrapped by opengl32.dll and are inside the ICD.
You don't need to know it, it's true, but helps when trying put all this mess together.

Unfortunately in practice it's even more complicated than how described here when you have to access extensions, select some particular pixelformats (see multisample), etc.
That's why most people use wrapper libraries which hides the specifics about gluing OpenGL to your OS and also imports all the stuff for you in the correct order. But someone still has to write them !