There is a bunch of info about the HD 3000 and other older Intel iGPUs and OpenGL support at this link.
The main takeaway is that Microsoft and Intel are both somewhat responsible for this.
The Intel OpenGL driver in ig4icd64.dll or ig4icd32.dll tries to check the Windows OS version and refuses to work if it finds a version number that it doesn’t expect.
Windows used to have version 5.0 for Windows 2000, 5.1 for XP, 6.0 for Vista, 6.1 for Windows 7, 6.2 for Windows 8, 6.3 for Windows 8.1. The driver checks the major version number, but only checks if it’s 5 or 6. If it’s any other number it returns with an error. It gets the version number via a GetVersionExA WinAPI call.
With Windows 10, Microsoft changed the version number to 10.0. However to maintain backward compatibility GetVersionExA still returned 6.3 unless the application explicitly declared itself Windows 10 compatible in the application manifest.
This presents the problem, when a newer application that declared Windows 10 compatibility loads an older DLL, if the DLL calls this WinAPI function it will get version 10.0 back. But an application that doesn’t declare itself Windows 10 compatible could load the same DLL and have the function return 6.3 on Windows 10.
The Intel DLLs check the Windows version number like this in assembly:
- get the major version number from Windows API
- subtract 5 from it, if it’s now zero assume Windows XP etc. legacy path
- if it wasn’t zero subtract one, if it’s now zero go to Vista, 7, 8, 8.1 path
- if it wasn’t zero this time either return with error, this happens on Win10
So here is the issue, if any modern application that declares Windows 10 compatibility in the manifest tries to load the Intel OpenGL DLL it will fail to load.
The first link talks about solution strategies like modifying the manifest file for applications, lying about the OS version via a compatibility layer etc.
You can also modify the DLL itself to fix Intel’s version check algorithm. The outline of this process can be found here in this github thread. You find the part in the DLL and then edit it in a hex editor.
One way to fix the DLLs for this driver version:
- for the ig4icd32.dll: Find the following hex string in the file: 48 75 DD A1 24 90 and change 75 DD to 33 C0
- for the ig4icd64.dll: Find the following hex string in the file: FF C8 75 DB 48 8B 05 86 and change FF C8 to 33 C0
This way the size of the file doesn’t change, offsets don’t change and this will make these DLLs accept any major Windows version 6 and above.
You can download these two DLLs for driver version 4229 here and 4459 here. These are modified as described above.
Here is what I am not sure about: how would driver signature enforcement work with these. In the latest released original Intel 4229 driver this DLL doesn’t have a digital signature, however in the 4459 version from Microsoft it is signed by Microsoft. I completely removed the signatures with Microsoft’s signtool on the 4459 versions as they become invalid due to the modification but can’t really test if that screws with anything, like SecureBoot.
The modified 4229 version DLL works on my Core i5 2467M equipped notebook under Win 10 64-bit as far as I can tell with some OpenGL extension tester programs (I used GPU Caps Viewer as it can actually display some 3D tests that use OpenGL 3.x functionality). It supports some limited set of extensions beyond 3.1 too although it reports 3.1 compatibility.
If you could confirm that this solves the OpenGL issues that would be great.