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.
Related
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 include a symbolic link from the source machine into Inno Setup. When running the installer on the target machine, it deploys a copy of the source file in place of the symbolic link. How do I make the installer preserve the symbolic links?
[Files]
Source: "c:\source path*"; Excludes:"*.log"; DestDir: "C:\destination path"; \
Flags: ignoreversion recursesubdirs createallsubdirs
You cannot "install" a symbolic link using the Files section. Inno Setup does not support symlinks.
You have to create the link explicitly on the target machine. For that, see How can I create a symbolic link with Inno Setup?
To avoid installing the symlinked file twice, you may need to exclude it from the installation using the Excludes parameter.
I'm using Inno Setup to make an installer for my program. I would like to run IIS Manager after installation. So, I'm using this code:
[Tasks]
Name: StartAfterInstall; Description: Run IIS after install;
[Run]
Filename: "C:\WINDOWS\system32\inetsrv\InetMgr.exe"; \
Description: "launching IIS prova"; \
Flags: postinstall nowait skipifsilent; Tasks: StartAfterInstall;
This should open IIS manager, but it doesn't work, returning me this error:
Could not execute file C:\WINDOWS\system32\inetsrv\InetMgr.exe
CreateProcessor failed, code 2 , file not found"
Using same code, but running other .exe file in a different path works. Does this depend on this specific path: C:\WINDOWS\system32\inetsrv?
There's probably only 64-bit version of the InetMgr.exe.
As Inno Setup in a 32-bit application, it by default gets redirected to C:\Windows\SysWOW64 (32-bit version of C:\Windows\System32). If there's no 32-bit version of InetMgr.exe in the C:\Windows\SysWOW64, Inno Setup cannot find it.
Add the Flags: 64bit to make Inno Setup find 64-bit version of the the InetMgr.exe.
Or use the 64-bit install mode.
Side note: Do not hard-code C:\Windows\System32, as that path can be different on some systems. Use {sys} constant.
[Run]
Filename: "{sys}\inetsrv\InetMgr.exe"; Flags: 64bit; ...
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 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.