Why NSIS installer read environment variable incorrectly?
Hi
Why NSIS installer read environment variable incorrectly?
I read processor_architecture variable on Windows x64 and installer returns x86 instead of AMD64. Why?
Archive: Why NSIS installer read environment variable incorrectly?
Why NSIS installer read environment variable incorrectly?
Hi
Why NSIS installer read environment variable incorrectly?
I read processor_architecture variable on Windows x64 and installer returns x86 instead of AMD64. Why?
From what I was able to gather from Google searches was that a 32-bit process returns "x86", while a 64-bit process will return "AMD64" or "IA64". (and as you may have guessed by now, NSIS is 32-bit.)
This is explained better here:
http://msdn.microsoft.com/en-us/libr...74(VS.85).aspx
use x64.nsh
Re: Why NSIS installer read environment variable incorrectly?
Hello Comperio, Anders!
Thank you for your replays!
NSIS is installer and the only reason for getting processor_architecture variable is to know in what environmen it is executed, so NSIS installer must returns correct value according to OS type.
It is not inportant how windows changes variables, installer must allways return correct values.
I do not want to use x64.nsh, because it require adding of additional libraries/plug-ins to installer, for something so simple and natural for any installer.
There a lot of indirect ways OS type to be detected, so I do not need x64.nsh, but installer, must report variables accordingly, so this is bug that must be fixed!
what "bug"? The link I provided from MS indicates that this problem happens on ANY 32-bit app.
The only solution therefore would be to create a 64-bit version of NSIS. Unfortunately, converting NSIS to native 64-bit is not an easy task.
Simple and natural? Reading environment variables is never the best way to get info, since you know, THE USER CAN CHANGE THEM. x64.nsh is part of the default nsis install, you should consider it as a part of NSIS (If you are using Modern UI, you are already using a plugin)
If for whatever reason you still don't want to use the proper method, on Vista, %windir%\Sysnative redirects to the 64 bit system folder, you can use IfFileExist to check it's content and tell if you are on 64 bit or not
Hello Anders, Comperio!
Thank you for your replays!
Replays of both of you I evaluate as useful.
I need a most simple way to detect OS type, so I now use PROCESSOR_ARCHITEW6432 variable to check OS type.
I call this bug because we talk for installer, but not for text editor. If NSIS is installer it must provide predefined constants as $sysdir and $windir, that to return OS version and type by simply reading them. Why I need to write code to get OS type or version, when this are parameters that are related to any setup and everyone need them by one or other reason.
OS type and version as so natural and important to installer constants as directory constants, even more, because I can get folders paths from registry, but not and OS type
I do not need native 64bit version of installer, because 32bit version is doing the job perfectly, while 64bit version cannot run on 32bit OS, and obviously I need it to run as on 32bit as well on 64bit, and this is why I need to detect OS type
That information is provided, as Anders mentioned, in functions defined in x64.nsh. Further functions for version detection are available in WinVer.nsh.
You might want to try this to get the native cpu architecture. Google GetNativeSystemInfo to get the meaning of the result returned on the stack.
Function GetCPUArchitecture
Push $2
Push $1
System::Alloc 36 ; new SYSTEM_INFO
Pop $1 ; $1 = new SYSTEM_INFO
System::Call "Kernel32::GetNativeSystemInfo(i r1)" ; GetNativeSystemInfo($1)
System::Call "*$1(&i2.r2)" ; $2 = ((WORD*)$1)[0], which is the wProcessorArchitecture field
System::Free $1 ; delete $1
Pop $1
Exch $2 ;so the register $1 and $2 are preserved and the result is on the top of the stack
FunctionEnd