This question already has answers here:
File/DLL installed to {sys} does not appear in C:\Windows\system32
(1 answer)
How to add x86 and x64 VC++ 2019 Redistributables in single Inno Setup installer?
(1 answer)
Closed 11 months ago.
I have an executable (setup.exe) that is being created using inno studio. for the executable to run I have to install a certain dll, which is libusb0.dll. If the system is a 64 bit I have the 64 bit dll being installed inside the system32 folder, also if the application is a 32 bit, it is installed in the syswow64 folder. Now if the system is a 32 bit I have the directory set to install the 32 bit dll in the system32 folder accordingly .
Although there seems to be another case, for example if the system is 64 bit, but the installer is 32bit, will the installer be able to identify that the system is a 64 bit and install it in the correct directory, which would be the syswow64 folder to install the 32bit dlls, or will it still try and install the 32 bit dll into the system32 folder which would be incorrect since its for 64bit dlls on a 64 bit system? In which case the setup will fail to find the correct dll?
I hope this makes sense, it is a little confusing for me, but would be nice to get someone's opinion on it.
The way I have it implemented in inno studio, is that I'm using Check: Is64BitInstallMode so that it checks the system before placing the respective dlls in the system folders.
Related
I need to create a registry key pointing to a file located in the 32 Bit "Program Files" folder that works under both versions (i.e. x86 and x64) of Windows 7 (and higher), even if the accessing process is a 64Bit process in the x64 environment. This folder is:
C:\Program Files in 32Bit Windows
C:\Program Files (x86) in 64 Bit Windows
My problem currently is, that the %programfiles(x86)% variable is not set on 32 Bit windows. So I do not really know which unique variable I can use on both Windows systems to get to the 32 Bit Program Files folder. Any solution to this weird situation?
I'm creating an installer which only needs to install 32bit files, they work on both 64 and 32 bit machines.
I'm running the Inno Setup on a 64bit machine and even though the install mode is 32bit the files still end up in the SysWOW64 folder. The Dest directive sets to {sys}
Source: "C:\Users\Lablabla\Documents\Visual Studio 2013\Projects\Test\MyDll.dll"; DestDir: "{sys}"; Flags: 32bit
The weirder thing is that the log shows that the destination is system32 and installation mode as 32-bit
2015-04-12 01:04:14.046 64-bit Windows: Yes
2015-04-12 01:04:14.046 Processor architecture: x64
2015-04-12 01:04:14.046 User privileges: Administrative
2015-04-12 01:04:14.046 64-bit install mode: No
....
2015-04-12 01:04:20.237 Dest filename: C:\Windows\system32\MyDll.dll
But when the setup is done the file is in the SysWOW64 folder, even though the executable file is in the correct place of Program Files (x86)
This happens even when setting the specific 32bit flag to the dll file.
The installation is very simple, only this dll and an executable. No registry or anything more complex.
Anyone experienced such thing?
Thanks
The SysWOW64 folder is the correct place for a 32-bit installation on a 64-bit system, in the same way that the Program Files (x86) folder is the correct place. SysWOW64 is the System32 folder on a 'Windows on Windows 64-bit' installation.
Admittedly, Microsoft should have done a much better job at naming these consistently to avoid confusion! i.e. System32 on a 64-bit installation is really "System64" and SysWOW64 is "System32", just as the plain Program Files is really "Program Files (x64)" if you want to think of it that way. All 32-bit applications run in the WOW64 (Windows 32-bit on Windows 64-bit) emulator on 64-bit Windows.
I have a 32-bit application which also has a device driver. I am using the DIFXAPP support in WiX to install the driver. Is it OK on 64-bit windows to install the application and 64-bit driver files to a subdirectory of Program Files (x86) then have DIFX install the driver to the driver store from there? I believe that it's not allowed to run 64-bit code from the 32-bit Program Files directory but in this case I'm not running it, just asking DIFXAPP to copy it. The actual function used is DriverPackageInstall().
There is a convention to install programs 32-bit programs into the x86 tree, but it is not forbidden. It is legal to copy the DIFXAPP executable and accompanying files into a sub-directory in Program Files (x86) and start it from there.
I have an exe which depends on libeay32.dll. Both compiled for 32 bits.
I have copied the exe to C:\Program files (x86)\app\bin and the dll to C:\Program files (x86)\app\lib.
To ensure the correct working, i have added C:\Program files (x86)\app\lib to the path.
On Windows 7 64 bits, when i execute the exe, i got a libeay32.dll not found error.
Using dependency walker for 32 bits, the library is properly located at C:\Program files (x86)\app\lib.
Using sysinternal process explorer the app is executed properly.
Using cmd also works.
Using dependency walker for 64 bits, i can see the missing libraries.
Copying the two files toghether or dll to syswow64 also works perfectly.
If the application was compiled for 32 bits...
Why isnt windows looking for 32 bits libraries?
Why arent the libraries resolved if directory is already on path?
My guess is that w7 is ignoring the path, but according to this:
http://msdn.microsoft.com/en-us/library/ms682586%28v=vs.85%29.aspx
it shouldnt!.
Why i cant run my exe with dependencies located on path?
Should i register the library or something?
Any ideas will be much appreciated.
EDIT:
The program its correctly launched/executed when done from start menu->program, but not directly on the .exe...wtf?
Using procmon seems to be trying to open (note the lack of " "):
"C:\Program Files(x86)\myapp\Third-Party\openssl\LIBEAY32.dll"
but in the path its correct (rechecked: "C:\Program Files (x86)\myapp\Third-Party\openssl")
ANSWER?:
is there a know scenario/bug where setting "C:\Program Files (x86)" on path, lead windows try to load "C:\Program Files(x86)" instead????(see using procmon without ANY filter)
Windows 7 x64 bug?
You can mvoe the lib into the same directory, because there it always checks first. If its found, it is used.
On Windows 64 bit systems you can (not tried) also move the libs to the SystemWOW64 folder where the 32bit versions are stored, but I would recommend the first version.
Library Project compiles fine for ANY CPU in VS2008 running on Win 7 64 -bit.
Now in the post build following command fails when attemptiong to register library dll:
PS C:\Windows\Microsoft.NET\Framework64\v2.0.50727> .\installutil C:\path\Project.dll
Exception occurred while initializing the installation:
System.BadImageFormatException: Could not load file or assembly 'file:///C:\path\Project.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format..
Do I need to compile the project as x64 I was under impression that AnyCPU will take care of it.
Alo my library does have dependencies. Do they also need to be compiled as x64 bit?
Any help is appreciated.
On Windows 7 64 bit Powershell runs as 32 bit application and 64 bit application.
In the Snap-in project one must reference a 32-bit System.Management.Automation library which is located in C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll
if Snap-in is compiled to run under Powershell(x86) which is 32-bit.
Default library however is 64-bit and located in C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0\System.Management.Automation.dll
One cannot register 64-bit Powershell snap-in compiled library via C:\Windows\Microsoft.NET\Framework\v2.0.50727\installutil which is 32 -bit
and will get exceptions from installation utility and installation will be rolled-back.