How to detect Windows 8 ?

alex0001
4th July 2013 15:56 UTC

How to detect Windows 8 ?
Hello,
can somebody please tell me how can i detect if a NSIS 2.46 setup file is running under Windows 8 ?

I have made a context menu dll for the windows explorer and want to install the Visual C++ 2012 redistributable packages only if Windows 8 is installed.

I know the rest,i simply do not know how to detect the version of Windows.

Thank you !

aerDNA
4th July 2013 18:50 UTC

Use WinVer.nsh. The documentation and usage examples are included in the header. But the one that comes with v2.46 doesn't support Win 8 so replace it with the updated version linked here (Ansi; tell me if you need the version for Unicode NSIS):
http://forums.winamp.com/showpost.ph...7&postcount=71

jmichae3
6th July 2013 00:03 UTC

the windows version should be 6.3 for 8.1 and 6.2 for 8 I think, and 6.1 for 7.

th_mi
7th July 2013 16:29 UTC

Originally posted by jmichae3
the windows version should be 6.3 for 8.1 and 6.2 for 8 I think, and 6.1 for 7.

That is correct, but NSIS will not detect Windows 8.1 as version 6.3. The problem is a missing compatibility manifest in the executable.

See here:
http://msdn.microsoft.com/en-us/libr.../dn302074.aspx

Without this manifest GetVersion(Ex) will return version 6.2.2900 and not 6.3.9431 that is the version for the current public preview version.

aerDNA
7th July 2013 19:02 UTC

I already compile my scripts with code that adds Win 8 compatibility to the manifest. With 8.1 added, it's:

!define ExecutionLevel requireAdministrator # ...|asInvoker|highestAvailable
!tempfile CustomManifest
!appendfile "${CustomManifest}" '<?xml version="1.0" encoding="UTF-8" standalone="yes"?><assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"><assemblyIdentity version="1.0.0.0" processorArchitecture="X86" name="Nullsoft.NSIS.exehead" type="win32"/><description>Nullsoft Install System ${NSIS_VERSION}</description><dependency><dependentAssembly><assemblyIdentity type="win32" name="Microsoft.Windows.Common-Controls" version="6.0.0.0" processorArchitecture="X86" publicKeyToken="6595b64144ccf1df" language="*" /></dependentAssembly></dependency><trustInfo xmlns="urn:schemas-microsoft-com:asm.v3"><security><requestedPrivileges><requestedExecutionLevel level="${ExecutionLevel}" uiAccess="false"/></requestedPrivileges></security></trustInfo><compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1"><application><supportedOS Id="{1f676c76-80e1-4239-95bb-83d0f6d0da78}"/><supportedOS Id="{4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}"/><supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/><supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/></application></compatibility></assembly>'
!packhdr "$%TEMP%\exehead.tmp" '"%ProgramFiles%\Resource Hacker\ResHacker.exe" -addoverwrite "%TEMP%\exehead.tmp", "%TEMP%\exehead.tmp", "${CustomManifest}", 24,1,1033'

I also updated WinVer.nsh. Now if only someone would actually test this. :D

Anders
8th July 2013 04:34 UTC

You can add whatever GUID you want to the manifest in the alpha and the next alpha version has "real" support

th_mi
8th July 2013 06:34 UTC

Originally posted by aerDNA
I already compile my scripts with code that adds Win 8 compatibility to the manifest. With 8.1 added, it's:
...
I also updated WinVer.nsh. Now if only someone would actually test this. :D

Nice idea, I never notices this possibility on manipulating the contained ressources this way. Thanks for sharing this :up: I'll check the attached scripts today on a 8.1 preview system... :)

Originally posted by Anders
You can add whatever GUID you want to the manifest in the alpha and the next alpha version has "real" support

At all good to see this will be done in NSIS 3. But for productive setups it is not recommended using Alpha versions. Therefore I'm still @2.46.

th_mi
8th July 2013 17:41 UTC

Originally posted by th_mi
I'll check the attached scripts today on a 8.1 preview system... :)

For me it works :) Thx

aerDNA
8th July 2013 18:20 UTC

Lovely jubbly. Thanks for testing and for pointing out the issue in the first place.

Anders
10th July 2013 22:48 UTC

Originally posted by th_mi
At all good to see this will be done in NSIS 3. But for productive setups it is not recommended using Alpha versions. Therefore I'm still @2.46.

The exehead/stubs and plugins have not changed that much, mostly a merge of the Unicode fork. Most of the changes are related to the compiler and build system...

aerDNA
11th July 2013 17:29 UTC

You're seeing it from NSIS dev perspective. His is that of a person who uses NSIS to package products. Alpha/beta suffix is a scarecrow for users who take their business seriously. 3.0a may be perfectly stable but it won't really matter until it's officially released as such.

kolorowy
1st August 2013 20:36 UTC

ReadRegStr $R0 HKLM "SOFTWARE\Microsoft\Windows NT\CurrentVersion" CurrentVersion

Seam to do the trick from me.