I am trying to install drivers with Inno Setup and it looks like there are (at least) two ways to do this: add dpinst.exe to the or run rundll against the .inf file.
I know there is two different version of DPinst for x86 and x64. Are there different version depending on the OS (I need to support XP, Vista and 7)?
Do I need admin permission for these methods?
Which method is recommended?
You use the same DPInst version for all versions of the operating systems; the only distinction is 32-bit vs. 64-bit. The WDK comes with both 32-bit and 64-bit versions.
Personally, here's what I do (on InnoSetup):
[Files]
...
Source: ...\dpinst32.exe; DestDir: {#DpInstPath}; DestName: dpinst.exe; \
Check: not IsWin64; Flags: ignoreversion
Source: ...\dpinst64.exe; DestDir: {#DpInstPath}; DestName: dpinst.exe; \
Check: IsWin64; Flags: ignoreversion
Using run32dll setupapi.dll,InstallHinfSection ... is outdated and generally not recommended unless you have some very specific needs.
Related
To understand how I use the software:
When starting the installer, the user can choose whether to install or update the software. If he installs the software with the install option, then the software can also be uninstalled regularly via the uninstaller.
I now also misuse the installation function as an update function. Here let's distinguish between the normal upgrade function of Inno Setup and my created update option via code. The update option is nothing more than a normal installation. However, the user must specify any paths to the pre-installed software beforehand. This has to do with the fact that most of our users have already installed the software manually before. (Java, Tomcat and our web application).
The normal installation and my specially created update option work fine so far.
By means of registry entries set during installation or update, I can distinguish whether the software has been installed or updated using the "Installer" or "Updater" option.
If the user has now installed the software via the normal installation option, then it should be possible to uninstall it completely. This means that the (Inno Setup) Uninstaller should delete all files. However, this should not be the case if the user uses the update option. The update function works by backing up some files before the regular installation, deleting unnecessary files using DelTree, and then letting the installation recreate them.
Is it possible to set a condition so that the uninstaller does not delete these files in the Files section if the user has previously used the Update option?
Normally, of course, the uninstaller should delete these files if the user has previously installed the software using the install option. However, I would like these files not to be deleted if the user has previously selected the update option in the installer.
The following is a brief portion of my options:
[Setup]
UninstallFilesDir={code:UnInstallerPath}
[Files]
Source: "<source>\Tomcat9\*"; DestDir: "{code:GetTomcatSourcepath}"; Excludes: "webapps"; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "<source>\{#JAVA}\*"; DestDir: "{code:GetJAVAExtractpath}"; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "<source>\Tomcat9\webapps\ROOT\*"; DestDir: "{code:GetWebAppSourcepath}"; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "<source>\config\*"; DestDir: "{code:GetConfigInstallPath}"; Check: IsInstaller; Flags: ignoreversion recursesubdirs createallsubdirs
Source: "<source>\libraries\{#DLLFile}"; DestDir: "{code:GetConfigInstallPath}"; Flags: ignoreversion
[UninstallDelete]
Type: filesandordirs; Name: "{code:GetUninstallPath}"; Check: IsInstalledviaProgram;
Type: filesandordirs; Name: "{code:UnInstallerPath}";
So the uninstaller should not delete any files other than its own exe and the associated data file if the installer was only used for the update using my created update function.
Due to the fact that I want to be able to uninstall the application if it was previously installed by the installation option, I unfortunately cannot use the uninsneveruninstall flag.
For better understanding, you can see in the following picture the first page that is displayed after starting the installer.
All Check functions (including those in the UninstallDelete section are evaluated on install time. Not on uninstall time.
Based on the name of your IsInstalledviaProgram function, I guess that it is implemented in a way to work in the uninstaller (by checking the registry entries?). But it is actually executed during the installation. So you should check for the radio buttons, not the registry entries (whose state at the time the function is called likely do not correspond yet). Maybe the IsInstaller is the function you should use.
I currently have a device utilizing the libusb0.dll file, I use inno script to install the dll's into their respective folders, the 32bit version into the syswow64 and the 64bit version into the system32 since I am using a 64bit pc.
The problem I am having is that when the device is not plugged in and I run the installer created by inno script it installs the dll's into their correct location, although when I plug in the usb device suddenly the dll's are either modified or are switched. To me it looks as if now the 64bit dll is in the syswow64 and the 32bit dll is in the system32. So basically my exe for the usb device will run when the device is not plugged in but does not work when I plug in the device because the dll's get modified when the device gets plugged in. I am not sure why this is happening.
The 32bit dll is 66.0kb and the 64bit dll is 74.5kb. Which leads me to believe that the 32bit dll is being replaced with the 64bit dll, not sure if this is exactly what is happening though.
Before plugging in usb device:
After plugging in usb device:
I have tested this by manually moving the dll's back to their respective locations and everything works fine, but if I run the installer again, the same thing happens, I plug in the usb device and it fails to work again, I get this error from the exe when trying to open it. which I believe is just telling me that either the dll is missing or in the wrong location.
How I am putting the dlls into the 2 folders:
Source: ..\lib_usb_win32\libusb-win32-bin\bin\amd64\{#LibUSB_AMD64_DLL}; DestDir: {sys}; DestName: libusb0.dll; FLags: replacesameversion restartreplace uninsneveruninstall; Check: Is64BitInstallMode
Source: ..\lib_usb_win32\libusb-win32-bin\bin\x86\{#LibUSB_X86_DLL}; DestDir: {syswow64}; DestName: libusb0.dll; FLags: replacesameversion restartreplace uninsneveruninstall; Check: Is64BitInstallMode
Source: ..\lib_usb_win32\libusb-win32-bin\bin\x86\{#LibUSB_X86_DLL}; DestDir: {sys}; DestName: libusb0.dll; FLags: replacesameversion restartreplace uninsneveruninstall; Check: "Not Is64BitInstallMode"
I use inno script to install the dll's into their respective folders, the 32bit version into the syswow64 and the 64bit version into the system32 since I am using a 64bit pc.
That doesn't match the script in your question. In fact, the script exactly matches your symptom that they end up swapped.
Source: ..\lib_usb_win32\libusb-win32-bin\bin\amd64\{#LibUSB_AMD64_DLL}; DestDir: {syswow64}; DestName: libusb0.dll; FLags: replacesameversion restartreplace uninsneveruninstall; Check: Is64BitInstallMode
Is clearly putting the 64bit version into syswow64 where it doesn't belong.
Source: ..\lib_usb_win32\libusb-win32-bin\bin\x86\{#LibUSB_X86_DLL}; DestDir: {sys}; DestName: libusb0.dll; FLags: replacesameversion restartreplace uninsneveruninstall; Check: Is64BitInstallMode
Is clearly putting the 32bit version into system32 where it doesn't belong.
I actually was able to figure out a fix, it seems that it was a windows issue, originally the dll's were in the wrong spots, inno studio was putting the 32 bit dll in the system32 and the 64bit dll was in the syswow64. I had fixed this issue by having inno script studio move the dll's into the correct folders, although for some reason windows was still adding the dll's to the wrong folders every time I would connect the usb device, even after I would remove them (And even after a system reset). I'm assuming somewhere in the system the drivers still had there original settings even after fixing it. So I assumed there was an error, but there actually wasnt, because after reformatting the drive and reinstalling windows it worked. I reinstalled the drivers and the dll's would stay in the correct folder even after plugging in the device, and now the application was running. So I guess what I really should ask now is why does this happen with windows, you would think that after a system reset, the drivers would be completely removed, when in fact they weren't which made testing my issue very difficult. I shouldn't have to format a drive every time I make changes to the drivers.
I don't know why, but when I try to copy a file from my install directory to system32, it fails to do so although it reads as successfully installing in Inno Setup. Here is my code:
[Files]
; specifies what files will be included in the installation
Source: "{src}\..\elt.properties"; DestDir: "C:\elt"; Flags: ignoreversion
Source: "{src}\..\msvcr120.dll"; DestDir: {sys}; Flags: onlyifdoesntexist;
I also wanted to include my log output as I thought it was strange that the time was so off for the file, I am writing this around 11 am on July 8 2016
[11:49:36.526] -- File entry --
[11:49:36.528] Dest filename: C:\Windows\system32\msvcr120.dll
[11:49:36.529] Time stamp of our file: 2013-10-04 23:58:24.000
[11:49:36.530] Installing the file.
[11:49:36.566] Successfully installed the file.
By default the {sys} (system32) is redirected to {win}\SysWOW64 by the OS for 32-bit applications (like Inno Setup).
If your DLL is 32-bit, you actually want the redirection. The SysWOW64 is the System32 equivalent for Windows 32-bit emulation on Windows 64-bit. See also Inno Setup install to SysWOW64 in 32Bit mode.
If you do not want the redirection (because your DLL is 64-bit), you can override the redirect using the 64bit flag:
Source: "..."; DestDir: "{sys}"; Flags: 64bit
64bit: Causes the {sys} constant to map to the 64-bit System directory when used in the Source and DestDir parameters, .... This is the default behavior in a 64-bit mode install.
Or enable 64-bit mode install.
[Setup]
ArchitecturesInstallIn64BitMode=x64 ia64
In 64-bit mode:
The System32 path returned by the {sys} constant maps to the 64-bit System directory by default when used in the [Dirs], [Files], [InstallDelete], [Run], [UninstallDelete], and [UninstallRun] sections. This is because Setup/Uninstall temporarily disables WOW64 file system redirection when files/directories are accessed by those sections. Elsewhere, System32 and {sys} map to the 32-bit System directory, as is normal in a 32-bit process.
I would like to make my installer compatible under both x86/x64 windows, this means portable.
I did the innosetup installer only to expand an x86 CLI executable file, and I need to expand it to C:\windows\system32 directory even if the installer is running under a Windows x64 because otherwise if I expand it to C:\Windows\Syswow64 directory then the exe is not recognized under a Windows x64 CMD.
So how I should set this property to make it portable with the specified condition above?:
ArchitecturesInstallIn64BitMode= ???
And what flags I should use when expanding the file here?:
Source: {sys}\My_x86_application.exe; DestDir: {sys}; Flags: ???
I've played a little bit with some flags like 32Bit, 64Bit, and Is64BitInstallMode, but I can't get the expected result because if I know that restricted constants as {syswow64} throws an installation error under a Windows x86...
UPDATE
This is the relevant part of my installation script, but it is wrong, it should be compatible with x86 and x64 windows (portable) and only expand the Source: {sys}\* files to C:\Windows\System32 under both windows (using the constant {sys} to detect the dir path, of course).
[Setup]
DefaultDirName={pf32}\{#AppName}
ArchitecturesAllowed=x86 x64
ArchitecturesInstallIn64BitMode=x64
[Files]
Source: {app}\*; DestDir: {app}; Flags: ignoreversion
Source: {sys}\*; DestDir: {sys}; Flags: ignoreversion 64bit
Answered in parts like your question:
ArchitecturesInstallIn64BitMode
Valid values: One or more of the following, separated by spaces:
x64
ia64
Default value: (blank)
Description: Specifies the 64-bit processor architecture(s) on which Setup should install in 64-bit mode. If this directive is not specified or is blank, Setup will always install in 32-bit mode. Normally, you should not change this directive from its default value unless your application contains native 64-bit binaries.
You have a x86 exe binary so leave the field blank.
Source (Required)
Description: The name of the source file. The compiler will prepend the path of your installation's source directory if you do not specify a fully qualified pathname.
Example:
Source: "My_x86_application.EXE"
Leaving it without any path like the entry above might be optimal (for small projects, because it messes the files to be deployed with the setup script). Also, beware that Constants may only be used when the external flag is specified, because the compiler does not do any constant translating itself. So, the following entry:
Source: {sys}\My_x86_application.exe; DestDir: {sys}
actually expects to have the binary stored in the {sys} subfolder of a directory with the setup script. If that would not be so, the compilation fails.
DestDir (Required)
I think you can specify System32 always using {win}\System32. Since both x86 and x64 version of Windows contain the System32 directory.
For the Flags and further doubt clarification visit this page.
EDIT: Save the iss file in the same folder where your x86 exe binary exists. Then Run it.
I'd like to install a driver for a serial port using Inno Setup. I have the inf file, and I can install the driver manually through device manager, but I'd like to be able to include the driver in my installer so that users don't have to go through the trouble of installing the driver themselves.
See InstallHinfSection in Microsoft documentation. The documentation also mentions how to invoke an installation by calling Rundll32.exe. Probably you'll end up with something like this:
[Files]
..
Source: "driver\my_x86driver.inf"; DestDir: {app}\driver;
Source: "driver\my_x86driver.sys"; DestDir: {app}\driver;
[Run]
..
Filename: {sys}\rundll32.exe; \
Parameters: "setupapi,InstallHinfSection DefaultInstall 128 {app}\driver\my_x86driver.inf"; \
WorkingDir: {app}\driver; Flags: 32bit;
Note that you might need to run the setup in 64bit mode in 64bit systems to be able to install the driver:
[Setup]
..
ArchitecturesInstallIn64BitMode=x64
Also you can put checks as to run the version of .inf file depending on machine architecture (e.g. Check: Is64BitInstallMode).
I used dpinst like this:
[Files]
Source: "Source\dpinst\dpinst32.exe"; DestDir: "{app}\driver"; DestName: dpinst.exe; Check: not IsWin64; Flags: ignoreversion
Source: "Source\dpinst\dpinst64.exe"; DestDir: "{app}\driver"; DestName: dpinst.exe; Check: IsWin64; Flags: ignoreversion
[Run]
Filename: "{app}\driver\dpinst.exe"; Parameters: "/A /LM";
This is a better answer: Install drivers with rundll32 or dpinst in Inno Setup?
Using InstallHinfSection on Windows 7 and beyond seems to be either broken or fraught with difficulty. Making it work from a batch file is difficult, making it work from Inno Setup is even more difficult. dpinst seems preferable, and is simpler.