How does OpenGL find an implementation on Windows?

Question

I have a Java program using OpenGL via JOGL, and there are some errors that only appear on Windows that I would like to debug. For this purpose, I tried to create a backup computer with Windows, but ran into some strange problem when I went to debug my program:

When I run the program “normally” through Java Web Start, it works fine, but when I compiled the program and try to run it either using the java launcher command line or through NetBeans (which I suppose is the same), he, seems to be using a different and very primitive OpenGL implementation that doesn't support programmable shading or anything else.

When I investigate the problem, I allowed myself to understand that OpenGL programs running on Windows opengl32.dll , which, apparently, are the common library that comes with Windows (correct me if I'm wrong) and which, in turn, loads the "real" OpenGL implementation and redirects OpenGL functions to it. (It also looks somewhat wrong, as it actually loads into a 64-bit process at the base address, clearly above 2 ^32. )

Using Process Explorer, I see that when I run the program under Java Web Start (where it works), it loads the ig4icd64.dll library, which I consider to be the actual OpenGL implementation library for the Intel GPU driver; whereas when trying to run the program through java.exe opengl32.dll loaded, but ig4icd64.dll never loaded, which seems to confirm my suspicion that it uses a different OpenGL implementation.

So this leads to the main question, and then:. How does opengl32.dll choose an OpenGL implementation to use, and how can I influence this choice to ensure the correct download? What tools are available for debugging? (And what is different between the two contexts, what makes it choose different implementations? In both cases, 64-bit Java is used, so there should be no confusion between 32-bit or 64-bit implementations.)

Update: I found this page on a Microsoft website stating that OpenGL ICD was found by OpenGLDriverName in the registry key HKLM/System/CurrentControlSet/Control/Class/{Adapter GUID}/0000/ . This value does indeed contain ig4icd64.dll , however, and perhaps more oddly, using Process Monitor to monitor system calls (if this is the correct terminology for Windows) of the Java process shows that it never tries to access this key. I cannot say that I know that this means that the article is incorrect, either if I am using Process Monitor incorrectly, or if it is something else.

Answer 1

When I studied the problem, I allowed myself to understand that OpenGL programs running on Windows load opengl32.dll, which seems to be the general library that comes with Windows (correct me if I am wrong) and which, in turn, loads the "real" OpenGL implementation and redirects OpenGL functions to it.

Yes, that’s how it works. opengl32.dll acts as a channel between Installable Client Driver (ICD) and programs that use OpenGL.

So, this leads to the main question: whereas opengl32.dll selects the OpenGL implementation used, and how can I influence this choice to ensure the application loads correctly? What tools are available to debug this?

It selects based on the flags of the window class (this is not a Java class, but a set of parameters for the window as part of the Windows API, see https://msdn.microsoft.com/en-us/library/windows/desktop/ms633577(v=vs .85) .aspx ), the window style denotes the pixel format set for the window, the position of the window (which means on which screen and graphics device it is on) and context flags.

For example, if you have to run it as a service, then there is no graphic device to create a window at all. If you ran it in a remote desktop session, it would work on a headless implementation of the rasterizer software.

I don't know the specific details of how the java CLI interpreter differs from WebStart. But IIRC you use javaw (pay attention to additional w ) for graphic programs.

---

(It also looks somewhat wrong, as it actually loads into a 64-bit process at a base address clearly above 2 ^ 32.)

This is not just opengl32.dll , but all the Windows system DLLs that are named ... 32 even in a 64-bit environment, and they are even in \Windows\System32 to add to confustion. For a very simple reason: source code level backward compilation compatibility for 64 bits. If all library names were changed to ... 64, then to compile programs for a 64-bit environment, all string literals and library links would have to be renamed to ... 64.

If you feel better about naming, consider ... 32 as a version designation, not an architecture: the Win32 API was designed in parallel for Windows 9x and Windows NT 3, so just think that ... 32 is for the "version" API created for Windows NT 3.2. "