Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.

Thanks. I believe there are two issues:

1. IIRC, the WINVER is there for a good reason--namely, HiDPI support breaks without it on newer versions of Windows. I will recheck it though.
2. OPENGL=1 is deprecated and will be removed as soon as any major work happens on the rendering backend. Ideally, ANGLE would be built with D3D9 suport only, although IIRC there is some build system work necessary. That said, it's not a blocker.

1. WINVER only controls which parts of the Win32 API are exposed by the Windows SDK headers. By setting it and _WIN32_WINNT to 0x0501 one simply restricts the API level to Windows XP, thus causing compilation errors if one tries to use newer functions or defines. This helps keep the resulting application compatible with the particular Windows version.

That is why I had to #define some of the already used Win7 level macros in guiwin.cpp (this is not optimal but works is this case).

Changing the define should not change the resulting binary. To prove this I just did an experiment by using

        -DWINVER=0x0502
        -D_WIN32_WINNT=0x0502

instead of 0x0501 (0x502 is Windows Server 2003 https://docs.microsoft.com/en-us/cpp/porting/modifying-winver-and-win32-winnt?view=vs-2019) and recompiling .
The resulting binary differs by only four bytes in the header and runs just fine on XP.

Of course the high DPI API is Win7+ (and thus I had to define USER_DEFAULT_SCREEN_DPI 96), but in this case it does not break anything and the resulting binary should work fine on HiDPI monitors under Win7 (but I have no system to test this on).

2. It is understandable that maintaining two rendering front ends is a PITA and extra work. I also understand the porting advantages of using Angle. So I will understand if you eventually deprecate OPENGL=1 and allow rendergl1.cpp to "rot" - that is why I did not change the option in CMakeLists.txt.

However for now it works and I am happy that I can use Solvespace master HEAD under XP again.

By the way Firefox until version 52.9.0 ERS does work with Angle under XP (it is not easy to figure out how exactly they configured it) so this proves that your Angle approach is feasible.

I looked at it again and it's a reasonable workaround. Thanks.

By the way Firefox until version 52.9.0 ERS does work with Angle under XP (it is not easy to figure out how exactly they configured it) so this proves that your Angle approach is feasible.

The problem is that the way ANGLE is built right now always pulls in D3D11 headers. I think I didn't translate its build system to CMake correctly, but I never found time to investigate.

Thanks for merging it!