Installing drivers from NSIS installer in x64 system - 64-bit

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'

Related

Can we build install shield - Install script / Install script MSI project to generate 64-bit setup.exe?

I want to know whether it is possible to create setup.exe (64-bit) from install shield.
I have read following things to do this, but nothing worked :
https://community.flexera.com/t5/InstallShield-Forum/64-bit-Setup-Isntallation/m-p/55761#M33183
http://www.installationdeveloper.com/2169/how-to-create-a-pure-64-bit-installation-in-installshield/
Actually I'm not able to load the 64-bit dll into 32-bit installer(using UseDLL() ), following is the reason for that, so I want to build 64-bit setup.exe, which might load my 64-bit dll.
https://community.flexera.com/t5/InstallShield-Knowledge/Can-I-Load-64-bit-DLL-Files-in-InstallScript/ta-p/3819
Thanks in advance.
UseDLL is part of InstallScript. InstallShield Installscript engine supports only 32 bit dlls as of now. So, UseDLL does not load x64 DLLs.
Install Script Project is still 32-bit(in Install Shield 2020), They are supporting MSI project as 64-bit (from Install Shield 2020). So we can not build installer as 64-bit from Installer script Project.

Install to "Program Files (x86)" on 64bit host

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.

Two .exe versions for different operating systems

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

How do I uninstall Java ME SDK from Windows 7 x64?

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.

How to make a simple Wine-based installer for Windows application

My Windows application runs under Wine, but the installation is a bit of a headache for laymen, and the wrappers I've seen online (PlayOnLinux, Wine Doors) require even more packages to be installed. Is there a way to make a package that will install Wine if the user needs it to be installed, install the application and shortcuts, all with minimal user hassle?
I don't believe there's any pre-made way to do this, but you could probably make a Debian package pretty easily that would depend on Wine, copy an MSI onto the machine, then run Wine's msiexec /i /q as the post-install script
Edit: Make sure to think about the uninstall case too! I.e. in the pre-uninstall script, run msiexec again as well.
You can bundle Wine -- that's what Picasa does -- or you can just make your package list Wine as a dependency; then the user's package manager will automatically install Wine for the user when they install your package.
Ideally your Linux package wouldn't run the Windows installer, but rather have all the files already unpacked.
The trick is to arrange for the files your package installs in /usr to show up in each user's .wine directory. You can look at how Picasa does this, but really the Wine community needs to document how to do this much better.
As always, ask at winehq.org if you need more info.
If you'd like to target the Mac OS, you can use WineBottler:
http://winebottler.kronenberg.org/
This project exists just for bundling Wine into a native Mac .app bundle in a way that's fairly hidden from the user.
Answer is simple:
Create Elf installer.
Pack Elf installer onto Exe installer resources.
Exe installer should unpack Elf installer on startup.
Exe installer must tries to run Elf installer after unpack (system call or some think).
If operation fail, we do normal install.
If operation didn't fail, we close Exe installer.

Resources