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):
http://forums.winamp.com/showpost.ph...7&postcount=71

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.

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

code:
!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

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

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

For me it works :) Thx

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

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.