Bug #69642 [Fbk]: Windows 10 reported as Windows 8 in phpinfo()

From: Date: Sat, 30 May 2015 21:19:11 +0000
Subject: Bug #69642 [Fbk]: Windows 10 reported as Windows 8 in phpinfo()
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-193018@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=69642&edit=1 ID: 69642 Updated by: wenz@php.net Reported by: wenz@php.net Summary: Windows 10 reported as Windows 8 in phpinfo() Status: Feedback Type: Bug Package: PHP options/info functions Operating System: Windows 10 PHP Version: master-Git-2015-05-15 (Git) Assigned To: ab Block user comment: N Private report: N New Comment: gone all weekend ... will do so early next week! Previous Comments: ------------------------------------------------------------------------ [2015-05-30 20:09:26] ab@php.net @wenz maybe you have time, you could at least test the bins in http://windows.php.net/downloads/snaps/ostc/69642/manifest_test.zip (just run test.bat and post here). Thanks. ------------------------------------------------------------------------ [2015-05-28 23:36:26] ab@php.net @wenz, ahoi :) I came further with this subject. In short - for win10 a manifest is required. You can write it big. It's not like the previous change on win 8.1 where without manifest it would deliver 6.2 but one could trick it with an additional check. win10 would always deliver 6.2 without manifest. even for the version helper API. The changes are landed in master now. Please take a look at https://github.com/php/php-src/compare/0a173501c86a426f3387c3d7229420b721743dfc...7ab99ed4b0a4eeded1c684631a8a65bd9cd85bcd . One note to this - manifests, even if embedded into some dll, it won't have any effect when the exe which loads them doesn't have manifest. This is really hard linked to the fact that "manifest is required for win10". It is not for win 8.1 because of the workaround we have. However now when the manifest is embedded, I get the orderly 6.3 on win 8.1, so how it should be. But with Apache builds which don't have it, it will be 6.2. So any exe which wants to read the version is required to have a proper manifest. It would be great if you could test the current master branch. I've added yet basic conditions to recognize win10, so that should be shown as well. To test it with Apache, it's simple. Just run the mt command I mentioned in the previous post targeting your httpd.exe . Please use vc14 for your builds. If the test went clean, we will need to backport this into PHP5. Besides that - the GetVersionEx is still available with win10. Despite deprecated, I don't see any reason to go for the version helpers. GetVersion, as it's still available, will serve for years. After that, only the holy "shoot me dead" can say what happens to that version API. You know what i mean :) Thanks. ------------------------------------------------------------------------ [2015-05-27 23:18:06] ab@php.net Pah, I've managed a simple snippet now to work with manifest. Look: ================= getversionex.c ================= #include <windows.h> #include <stdio.h> void main() { OSVERSIONINFO osvi; BOOL bIsWindowsXPorLater; ZeroMemory(&osvi, sizeof(OSVERSIONINFO)); osvi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO); GetVersionEx(&osvi); bIsWindowsXPorLater = ( (osvi.dwMajorVersion > 5) || ( (osvi.dwMajorVersion == 5) && (osvi.dwMinorVersion >= 1) )); printf("major=%d minor=%d\n", osvi.dwMajorVersion, osvi.dwMinorVersion); } ================= getversionex.c ================= ==================== my.manifest ======================== <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3" > <asmv3:application> <asmv3:windowsSettings xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings"> <dpiAware>True/PM</dpiAware> </asmv3:windowsSettings> </asmv3:application> <compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"> <application> <!-- Windows Vista --> <supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/> <!-- Windows 7 --> <supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/> <!-- Windows 8 --> <supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/> <!-- Windows 8.1 --> <supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/> <!-- Windows 10 --> <supportedOS Id="{8e0f7a12-bfb3-4fe8-b9a5-48fd50a15a9a}"/> </application> </compatibility> </assembly> ==================== my.manifest ======================== Then the following commands: cl getversionex.c mt -manifest my.manifest -outputresource:getversionex.exe;1 And, we already have a mechanism in the makefile to run the latter command. So what i do think now - we should dig into this, probably use the default manifest if an extension/sapi doesn't supply one. I also haven't checked how it behaves when say it's a dll which is loaded in the exe without embedded manifest, should be checked yet. But if it works, we should use GetVersionEx - it's available in all the Windows versions including win10. If it's disappeared somewhen - well, then it needs to be changed. It should be also better from the performance side. If GetVersionEx did disappear somewhen, so maybe also dont use a CRT which doesn't fully support the version helper stuff. What do you think? Thanks. ------------------------------------------------------------------------ [2015-05-27 20:14:03] ab@php.net Thanks for checking anyway. I'm going to continue investigating on the manifest stuff, if that didn't worked - will probably go your way integrating the file version reading. Thanks. ------------------------------------------------------------------------ [2015-05-27 19:01:56] wenz@php.net yeah, standalone it works, but (as far as I understand it) the GetVersionInfoSize and GetVersionInfo functions are only available if I pull them out of version.dll using GetProcAddress(), and that's what somehow doesn't work in my patch. Or I am missing something trivial, which might very well be possible with my rusty C. ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69642 -- Edit this bug report at https://bugs.php.net/bug.php?id=69642&edit=1

« previous php.bugs (#193018) next »