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 !

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):

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

Originally Posted by jmichae3 View Post

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:


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.

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. 😁

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

Originally Posted by aerDNA View Post

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. 😁

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

Originally Posted by Anders View Post

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.

Originally Posted by th_mi View Post

I'll check the attached scripts today on a 8.1 preview system... 🙂

For me it works 🙂 Thx

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

Originally Posted by th_mi View Post

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...

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.

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

Seam to do the trick from me.