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

From: Date: Wed, 03 Jun 2015 09:57:56 +0000
Subject: Bug #69642 [Com]: Windows 10 reported as Windows 8 in phpinfo()
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-193083@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 Comment 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: I have now tested both the manifest test binaries you sent and manually built CLI versions for the 5.5, 5.6, and master branches on these systems (fresh OS installations in all cases): - Windows 7 -> 6.1 - Windows 8 -> 6.2 - Windows 8.1 -> 6.3 - Windows Server 2012 R2 -> 6.3 - Windows 10 (Tech Preview 2, including the new update from the weekend) -> 10.0 - Windows Server 2016 (TP 2) -> 10.0 The only situation where the code failed was when I tried your binaries on 2012 R2 (application can not be used on your system) - I was using the 32bit edition though, so that may be the reason. The manually compiled versions did work as expected. I am also +1 for keeping my clumpsy 8.1 workaround in, for the reasons you stated. The only thing I did notice was that a SKU was reported incorrectly, but I need to doublecheck with MSDN whether that is really true or if I am too confused by the many different names and versions. I'll create another bug report and patch once I come to that. Thank you so much for getting this fixed! I still don't understand why my attempts to add a manifest all failed ... :-( I'll do some more tests with Apache installations (the way I understand it, httpd.exe needs a manifest there), and if that's the case I'lltry to talk to the XAMPP people to maybe add this to their distribution, since I guess they are reponsible for a great chunk of WAMP-Installations. Previous Comments: ------------------------------------------------------------------------ [2015-05-31 19:52:51] ab@php.net Now it's ported into the PHP5 tree. Please start with it, maybe right with 5.5, when you come to it. I've added basic code to recognize win10 and server 2016, as well as to properly recognize the win 8.1 servrer 2012. Now you can also check with further product types. But please don't remove the workaround for 8.1, it's still important fe if mod_php is loaded under httpd.exe which has no proper manifest. Thanks. ------------------------------------------------------------------------ [2015-05-30 21:19:11] wenz@php.net gone all weekend ... will do so early next week! ------------------------------------------------------------------------ [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. ------------------------------------------------------------------------ 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 (#193083) next »