I am trying to use "x64.nsh" to set default installation directory to PROGRAMFILES64 if on 64bit host. The installer script looks similar to this:
!include x64.nsh
# set to default here, override in .onInit if on 64bit
InstallDir "$PROGRAMFILES\AppName"
function .onInit
${If} ${RunningX64}
SetRegView 64
StrCpy $INSTDIR "$PROGRAMFILES64\AppName"
${EndIf}
functionEnd
but it stubbornly installs to c:\Program Files\AppName.
I've seen a few examples (this one in particular) but none of them seems to work for me. Is there any full example?
Is it related to the fact that nsis creates a 32-bit installer (PE32 executable (GUI) Intel 80386), even when packing 64bit code on 64bit OS?
EDIT: I actually don't mind having a 64-bit-only installer, since there is (and likely won't be) a 32bit build. But I can't seem to get Program Files (x86) from the $PROGRAMFILES64 variable.
As pointed out by #leppie, it is correct to install 64bit binaries into c:\Program Files (not c:
Program Files (x86) as I believed based installation of some other 64bit software. A 64bit-only installer can use $PROGRAMFILES64 directly.
Related
I cannot get my welcome page (or finished page) to appear in an NSIS installer.
Other pages appear fine. I've even compiled and run WelcomeFinish.nsi with the same result.
I am running Windows 7 (64 bit)
The real solution is to uninstall McAfee but as a workaround you can try this:
Function .onInit
UnsafeStrCpy $pluginsdir "$LocalAppData\MyCompany\Temp" ; NSIS v3+
CreateDirectory $pluginsdir
FunctionEnd
I have created EXE using nsis script.currently I have set the install directory this path
InstallDir "$PROGRAMFILES\myapp.
I have run exe file in windows xp,windows 7 32 bit and win7 64 bit.
Installation directory may change xp and window 7.
How to find if the os is window 7 or window xp?
How to select installation directory based on os?
Selecting the destination based on the OS is not usually something you should do but if you really want to you can use WinVer.nsh:
!include WinVer.nsh
Function .onInit
${If} ${AtLeastWinVista}
StrCpy $InstDir "c:\VistaAndLater"
${Else}
StrCpy $InstDir "c:\Win95To2003"
${EndIf}
FunctionEnd
If you want to change it based on x86 vs AMD64, use x64.nsh
My NSIS based installer deploys a certain .exe file into the target folder for all windows platforms. We recently discovered we need to deploy a slightly different version of that .exe file if we are installing on windows 8.
We don't want to have two installers.
we'd rather have one installer that "holds" the two .exe files, and deploys the right one for windows8 and the other .exe for the rest.
Any pointers on How do we achieve that? detecting windows8 at install time, copying over a different version of the .exe file when we do detect it?
Thanks.
You can test quite precisely the platform by including the LogicLib.nsh and WinVer.nsh scripts that are provided with NSIS.
Here is a function that I am using where I make some sanity checks before installing an application:
Function CheckUnsupportedPlatform
${if} ${AtLeastWin95}
${AndIf} ${AtMostWinME}
;NT4 and W95 use the same version number, we can use ${IsNT} if we need precise identification
MessageBox MB_OK|MB_ICONEXCLAMATION "Sorry, but your version of Windows is unsupported platform.$\n\
Supported platforms are currently 2000 / XP / 2003 / Vista / Seven$\n \
Cannot continue the installation." /SD IDOK
abort
${elseIf} ${isWin2008}
${orIf} ${AtLeastWin2008R2}
MessageBox MB_OK|MB_ICONINFORMATION "Please note that support for Windows 2008 and Windows 8 is in beta stage.$\n\
Supported platforms are currently 2000 / XP / 2003 / Vista / Seven" /SD IDOK
${endif}
FunctionEnd
There are many more possibilities, take a look in the header of WinVer.nsh for more examples.
I had a similar problem with nsis, detecting different Windows versions. I just wrote a three line C++ app to call the Windows API to find out OS version, then wrote console output as a string. From nsis, you can read this output into a variable and then switch based on the value of this variable.
I know this is quite old, but in case someone is having the problem with the File command, this is the expected syntax:
!include "WinVer.nsh"
...
; The stuff to install
Section "MyProgram (required)"
${If} ${AtMostWin2003}
File /oname=MyFile.exe "MyFile2003.exe"
${Else}
File "MyFile.exe"
${EndIf}
SectionEnd
I try to uninstall Java ME SDK from Windows 7 x64, but it doesn't work for me.
If I choose Uninstall I get a progress bar, then it goes away, but the Software is still there.
On the first few times I did this, I got the same error message as in I need help UNINSTALLING Java ME SDK:
... show message dialog
title: Critical Error
message: Cannot load native library from path: native/jmesdk/windows/windows-x86.dll
Exception:
java.lang.UnsatisfiedLinkError:
C:\Users\Jonas\AppData\Local\Temp\nbi-8367277139934329064.tmp: Can't load IA 32-bit .dll on a AMD 64-bit platform
In ref to getting the uninstaller to use the 32-bit JRE, the config I attempted that failed to work:
a) Set the PATH environmental variable to point to the 32-bit JRE
b) Windows registry edits in HKEY_LOCAL_MACHINE\SOFTWARE\JavaSoft\Java Runtime Environment\1.6 to point to the 32-bit JRE.
In a last ditch effort I renamed \Program Files\Java to Java2, and the uninstaller must have searched to find \Program Files (x86)\Java, the 32-bit JRE, and the uninstall worked.
Seriously, Sun/Oracle. Test your products.
I had the exact same problem and I figured it out. :)
It's because you have the 64-bit JRE installed. Either uninstall it or somehow redirect the J2ME uninstaller to use the 32-bit JRE on your system, so that the 32-bit uninstaller can run instead of the 64-bit uninstaller.
I had the same problem and figured the solution out. As mentioned above you need to make sure J2ME unnistaller only recognizes Java x86. The simplest way I found, instead of unnistalling Java x64, you only have to temporarily rename your Java x64 installation folder to anything you want. That is, rename the folder C:\Program Files\Java to, e.g, C:\Program Files\JavaTEMP.
Now run unnistaller. When finished rename the folder back it's previous name.
That's all.
Hope I helped.
Just perform the following steps and you will be done:
1) Click on the link below and click on any of the ...i586.exe link according to your system
http://www.oracle.com/technetwork/java/javase/downloads/jre8-downloads-2133155.html
2)Install the software without changing default settings.
3)Run cmd command and type the following:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "C:\Program Files (x86)\Java\jre8"
4)[optional] uninstall java 8 from control panel which you downloaded to uninstall the above software.
Congratulations.. You just did it!!
Thank you for reading.. Any suggestions or aprreciation is welcomed..
Turns out I had exactly the same problem, uninstall java (TM) 7 64bit and locate the 32-bit java installer bone this download uninstall it and try to install the Sun Java Wireless Toolkit and uninstalled correctly.
Just run this command:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "32-bit jre location"
Rather than temporarily moving the x64 JRE out of the way, just tell the J2ME SDK uninstaller to use the 32bit JRE:
C:\Java_ME_platform_SDK_3.0\uninstall.exe --javahome "C:\Program Files (x86)\Java\jre7"
Note that this provides the path to a JRE within the "Program Files (x86)" directory, which is the 32bit variant. I only had a Java 7 JRE, but this ought to work with a Java 6 JRE, also.
I want to add support for x64 OSes to my NSIS installer. One of the installer's task is drivers installation. I've written a special NSIS plugin for this task. This plugin uses Driver Install Frameworks API (DIFxAPI) to install drivers.
The problem is that this API does not work in WOW64.
Is there any way to create x64 installer application with NSIS? Has anybody solved similar problem with NSIS?
P.S.: The only solution I can see now is to run another application from the installer. This will be x64 executable that installs drivers. But this way seems somewhat harder to me. So, I'm interested in other solutions.
I am encountering a similar problem and I think that the only solution at the moment is to run something else (64bit) via CreateProcess.
This doc appears to have a solution using DPInst (http://www.microsoft.com/whdc/driver/install/32-64bit_install.mspx) though I have not tried it myself yet.
Will add anything else I find.
Additional:
Have now got it to work, boils down to
Download Windows Driver Kit Version 7.1.0
Mount the ISO and install Full Development Environment->Tools to C:\
Copy C:\WinDDK\7600.16385.1\redist\DIFx/dpinst/EngMui/amd64/dpinst.exe
to myApp/drivers/dpinst64.exe
Copy C:\WinDDK\7600.16385.1\redist\DIFx/dpinst/EngMui/x86/dpinst.exe to myApp/drivers/dpinst32.exe
Copy your driver package (inf file etc.) to myApp/drivers
To the top of myApp.nsi add !include "x64.nsh"
And somewhere in the install section in myApp.nsi add:
${If} ${RunningX64}
ExecWait '"$INSTDIR\drivers\dpinst64.exe" /c /q /sa /sw /PATH
"$INSTDIR\drivers"'
${Else}
ExecWait '"$INSTDIR\drivers\dpinst32.exe" /c /q /sa /sw /PATH
"$INSTDIR\drivers"'
${EndIf}
Just for reference: https://bitbucket.org/dgolub/nsis64
A native x64 version of NSIS is in the planning stages at best, so you will have to create something custom, either a new helper application, or a 64-bit version rundll32 + some sort of helper DLL file.
I'm specifically trying to install a file system filter driver on x64 from the NSIS installer using an INF file.
On 32 bit I can quite happily call:
ExecWait '$SYSDIR\RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 132 $INSTDIR\<myinf>.inf'
But... on x64 even with the file redirection turned off using ${DisableX64FSRedirection} it still does a WOW64 thing...
I found that to get RUNDLL32.EXE to work properly on x64 from NSIS, you need to also set the registry view to be 64 as well:
${If} ${RunningX64}
${DisableX64FSRedirection}
SetRegView 64
${EndIf}
ExecWait '$SYSDIR\RUNDLL32.EXE SETUPAPI.DLL,InstallHinfSection DefaultInstall 132 $INSTDIR\<myinf>.inf'