Apparently, Microsoft has made quite a lot of changes to the Windows API in Windows 10 to all but officially encourage (AKA, to trick) software developers to create programs that work perfectly fine on Windows 10, but will break if you try to run them on Windows 7 or 8.
For example, I found this gem.
"When using WideCharToMultiByte, the behavior is not-so-obviously different on Windows 7 and Windows 10. If you're converting from WCHAR UTF-16LE to UTF-8, and you specify a default character, this will work perfectly fine on Windows 10. However, on Windows 7, this function will fail. One way is actually wrong. The documentation says this:
'For the CP_UTF7 and CP_UTF8 settings for CodePage, this parameter must be set to NULL. Otherwise, the function fails with ERROR_INVALID_PARAMETER.'
"So, if you're converting to UTF8, you need to set that parameter to NULL."
So, if you don't do this, the program will work as expected on Windows 10, but fail hideously on Windows 7 and 8, and if you do this, it works on all three.
But since many developers are now working exclusively on Windows 10 boxes, making a mistake like this and "It works on my system." means that you can release software that blows up when someone using Windows 7 goes to run it and not even figure out where the problem is when they come to complain about it, unless you care to find a Windows 7 box to test on or have an encyclopedic working knowledge of the very bloated Windows API and every inconsistent change Microsoft has made along the way. (Even different versions of Windows 10 might not act alike.)
Who knows where else the Windows 10 API has changed in inconsistent ways?
And we all know that Microsoft has done this intentionally so that Windows 7 users will get your program, can't run it, and the "obvious" thing to do is install Windows 10.
Lovely.