Recognize Win 8, 8.1 and 10. #795

Merged
merged 2 commits into from Aug 27, 2015

Projects

None yet

6 participants

@micove
Contributor
micove commented Aug 26, 2015

https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85).aspx

In Windows 8.1 and Windows 10, the GetVersion and GetVersionEx APIs have been deprecated and superseded by the Version Helper APIs. While you can still call the deprecated APIs, if your application does not specifically target Windows 8.1 or Windows 10, you will get Windows 8 version (6.2.0.0).
In order to target Windows 8.1 or Windows 10, you need to include the app manifest in the source file.

Before:

Host Machine Init:
    Operating System =  Microsoft  (build 9200), 64-bit

After, w/o the manifest:

Host Machine Init:
    Operating System =  Microsoft Windows 8 Pro (build 9200), 64-bit

After, with manifest:

Host Machine Init:
    Operating System =  Microsoft Windows 10 Pro (build 10240), 64-bit

Not sure if the manifest breaks the executable in Windows XP but it should work for Vista and up.

@micove micove Recognize Win 8, 8.1 and 10.
https://msdn.microsoft.com/en-us/library/windows/desktop/dn481241(v=vs.85).aspx
Windows 8.1 and 10 require a manifest file or they will be reported as
6.2 which is Windows 8.
.
Also add the information for Win 8, 8.1 and 10 in the WinMisc.cpp file.
45fc960
@ssakash
Member
ssakash commented Aug 26, 2015

LGTM 👍

@micove
Contributor
micove commented Aug 26, 2015

Did you test it in XP? If it fails the executable should fail to even run. It should work but I read one person in the MS site mentioning it failed on XP but I'm not sure if it was user error on his part.

@mirh
mirh commented Aug 26, 2015

Is there any purpose in.. recognizing newer Windows versions?

@micove
Contributor
micove commented Aug 26, 2015

Same purpose as recognizing the older versions? If it's only going to work for half of them might as well remove the feature.

It's probably useful for debugging OS specific issues when people paste their logs.

@ssakash
Member
ssakash commented Aug 26, 2015

Did you test it in XP? If it fails the executable should fail to even run.

I ran it through windows XP SP2 & SP3 (compatibility mode) and it worked fine. didn't test it on the real windows XP itself.

though on other note loading does take a bit while using through XP compatibility mode. while the same behavior wasn't on the stable version. maybe due to the WX upgrade ?

@avih
Member
avih commented Aug 26, 2015

Test on XP means test on XP (possibly in a virtual machine like VirtualBox or VMWare). Compatibility mode doesn't mean much.

@micove
Contributor
micove commented Aug 26, 2015

I installed XP here. For some reason I decided to do a Windows Update so I'm at 98 out of 123 updates done. I will check and see whenever that finishes.

Edit: Also what avih said.

@ssakash
Member
ssakash commented Aug 26, 2015

I don't think the manifest would affect XP according to the information provided on MS site.

Note that Windows XP and Windows Vista ignore this manifest section and it has no impact on them.

https://msdn.microsoft.com/en-us/library/windows/desktop/dd371711%28v=vs.85%29.aspx

There was a user at the comments section who said that it doesn't ignore the manifest, but it's highly likely to be false.

In any case, It'd be better to check either by installing XP on a BD (or) through a VM, CM isn't always reliable though as stated before.

@micove
Contributor
micove commented Aug 26, 2015

Yes, that is why I said that it should work but there was an user that said that it did not work. I also think that the commenter is wrong but it's better to confirm and get it over with.

XP just keeps giving me security updates after every restart. Also, I had forgotten how ugly IE 7 and 8 were.

@micove micove Fix Windows XP Home vs Pro detection.
VER_SUITE_PERSONAL is set for XP Home therefore the check was backwards.
f29dd8b
@micove
Contributor
micove commented Aug 26, 2015

That took longer than expected but it works. There was a bug that detected XP Pro as XP Home (and vice-versa) so I might as well fix that but no one complained in the 6+ years that it was there.

Before:

Host Machine Init:
    Operating System =  Microsoft Windows XP Home Edition Service Pack 3 (build 2600)

After:

Host Machine Init:
    Operating System =  Microsoft Windows XP Professional Service Pack 3 (build 2600)

I already tested it in Win10 and Win XP. I will merge it later if there are no complaints.

@willkuer
Contributor

Actually there was once a complain in the forum. Iirc by vsub or tsunami but everyone agreed that nobody cares for home vs professional.

Still nice that you fixed it.

@willkuer
Contributor
@micove
Contributor
micove commented Aug 26, 2015

Melchior must be happy since it will be fixed within a year of that thread.

@willkuer
Contributor

That's what I thought as well :D

@micove micove merged commit 287672d into PCSX2:master Aug 27, 2015
@micove micove deleted the micove:Recognize_Win8-10 branch Aug 27, 2015
@White-Tiger

There was a user at the comments section who said that it doesn't ignore the manifest, but it's highly likely to be false.

just to clarify. Those manifest files were actually introduced with Windows XP to get the XP Look & Feel
So it's so far correct to say it won't ignore them (as it's the one who added them in the first place)
But the Microsoft article was clearly talking about the compatibility section. Which got added by Windows 7 (which also means it's useless to include the Vista GUID... besides it'll default to Vista anyway if no matching GUID is to be found)

And since a manifest is just an XML file, "unknown" sections shouldn't matter which is why the "compatibility" section is ignored on XP and Vista.
Likewise the "trustInfo" section is only known since Vista because it's the first OS with UAC in place, and thus also ignored by XP

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment