We've got an ancient of days VB6 app which sometimes needs to be updated and installed on our user's machines. We've begun using Inno, and especially InnoIDE, to make the setup.exe, to get this onto our user's PCs. However, I'm wondering about 64-bit Windows, and Inno setups. We've got a couple of machines in-house, which are 64-bit versions of Windows 7 Professional. I've successfully installed our app, using the setup from Inno, onto a 32-bit Windows XP machine. Can I use the same setup on our 64-bit Windows 7 machines? Will it put the .exe into the C:\Program Files (x86)\ directory structure automatically, or do I have to make allowances for 64-bit versions of Windows?
If your app is only 32-bit, then Inno will automatically take care of doing everything correctly.
Only if your app is mixed or 64-bit do you need to do anything special as rushman says.
There is a very good section in the help file that explains the changes needed.
If you're installing any 64-bit device drivers, the calls to most newdev and setupapi entry points will fail with error code 0xE0000235 (ERROR_IN_WOW64). Those calls only work when invoked from 64-bit code, and Inno doesn't compile 64-bit installers yet. You may work around by using pnputil.exe, by adding a 64-bit stub executable, or by switching to WiX.
For 64-bit INNO intallations you generally only need to add one setup section directive and, obviously, add the 64-bit versions of DLL's and EXE's to the compiled installer.
The setup section directive is:
ArchitecturesInstallIn64BitMode=x64
Related
Alright so my idea was some way to bind both 64-bit and 32-bit Windows executables into one application so if it doesn't run the 64-bit version it would then try the 32-bit one.
I was reading up about PE's and learned a little about MS-DOS Real Mode Stub and it says how it invokes an application (usually an error message). But every time I tried to do research about MS-DOS Real Mode Stub it seemed to only show error messages. So my idea was to overwrite the STUB with my 32-bit application.
My self being naive figured when the 32-bit operating system would run the the 64-bit executable it would fail and then run the stub file.
Is there any way to make my executable 32-bit/64-bit independent?
You could not create a single executable file, containing both x86 and x64 code. However you could create separate 32bit and 64bit applications, pack x64 app into the x86 app resources. On the program start you could check, that you are running x64 environment using IsWow64Process then if needed, unpack your x64 version and run it instead
There are fat binaries in MacOS, Linux and DOS (or hybrid DOS-Windows) but not 32 and 64-bit Windows
You can simply compile separate versions of the program, distribute both and then select the required version at run time by a script or another executable
Another way is installing only the desired version at install time. This is used by many programs like CCleaner. The installer is a 32-bit app or a universal one like .NET so that it can run anywhere. If it detects 64-bit Windows then it only installs the 64-bit version, and in the other case only the 32-bit version.
Read more:
Universal binary
Windows 8 fat binary (exe for x86 & ARM)
Windows NT has always been a multi-platform OS, but the binaries are not
I am a non-admin user on a Windows 7 (32 bit) computer, and also an admin user on a Windows 7 64-bit computer. I am trying to build the Vim text editor from source code to install on the 32-bit machine (to a place I have access, like C:\Vim).
Now, I have successfully built both a 64-bit and 32-bit version of Vim on my 64-bit computer. Both of them run fine on the 64-bit computer. I can verify with "dumpbin.exe" as detailed here that the 32-bit build really actually is a 32-bit build. Doing ":version" within Vim while running the 32-bit build also confirms this.
But when I try running that same executable on the 32-bit machine, I see "This version of gvim.exe is not compatible with the version of Windows you're running. Check you computer's system information to see whether you need a x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher." For kicks, I tried the 64-bit build of Vim and got the same message. I tried setting compatibility mode on the executable before running it, but get the same result. Additionally, only "Windows Server 2008" and a few version of "Windows Vista" appear in the list of compatibility modes: I was going to try Windows XP but it does not appear in the list.
Now, when I download an installer from cream.sf.net instead of trying to build my own Vim, Vim installs fine and then launches fine. I can see the full list I originally expected in the compatibility mode list of the installed executable. So I must be doing something wrong when I build.
The only difference I can think of, is that I'm compiling on a 64-bit machine, and using Visual Studio 2010 rather than Cygwin to build. But it is very strange that neither the 32-bit nor the 64-bit build works; I would always expect at least one of them to work! What could I be doing wrong?
It's not related to Vim. Recent versions of MSVC use a new format for 32-bit binaries, which is not compatible with XP. You can change back to the old format in MSVC with a flag/config option. I'm certain this works with VS 2013 (compiling on a 64-bit machine) and 2012 SP1. According to this post it's also possible with 2010 if you define NTDDI_<version> and _WIN32_WINNT.
I have a windows form application which is being installed on client pc by using msi file trough active directories, application is a 32bit app which is being deployed to a 32 bit and 64 bit windows systems and as we know application folder names are different between 32 and 64 bit systems, Program Files and Program Files(x86), also during installation application shortcut is placed in startup folder so app will be started when PC us powered up.
Question: Is there a chance to build msi by Windows Installer provided by Visual Studion in such a way that it will check what operating system its being installed at and place the shortcut in to start up folder with correct URI, to Program Files\Applicaiton\ or Program Files(x86)\Applicaiton?
Thank you!
Windows Installer packages are platform aware (x86, x64 ). Windows Installer doesn't support 64bit packages running on 32bit platforms or 32bit packages writing to 64bit ProgramFiles.
You can compile your EXE as AnyCPU and even though it's installed as 32bit it'll execute as 64bit. Although the Visual Studio team has moved away from that and compile as x86 by default in recent versions of Visual Studio.
Upon initialization, the Windows Installer gathers information about the operating system and automatically sets properties that can be used in optional conditional statements used by the setup application, such as VersionNT64 and "System Folder Properties"
In cases where it is necessary for the setup to know this information, it is preferred practice to allow the Windows Installer service to determine folder locations rather than try to hard-code this information into the package.
I have seen that some programs which were written by me and assembled for x86 using ml.exe run fine on my Win 7 x64. I believe this is because of Wow technology.
However, there are some programs (not written by me) which don't run. They give the error that:
The version of this file is not compatible with the version of Windows you're running. Check you computer system infromation to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher
Is there any way I can modify the EXE of these programs to make it run on Win 7 x64. What is the fundamental difference in these programs which make it different from other programs which run transparently.
They're actually 8- or 16-bit programs. Windows x64 runs in Long Mode, which does not support Virtual 8086 Mode, required for such programs. There is no way to make them work short of recompiling them from source or running them in a virtual machine.
One reason can be combination of .NET and native libraries. .NET libraries are compiled in runtime as x64 (if you don't specify explicitly x86) and native libraries run in x86 mode. it cannot run togehther.
Another reason is access to registry. Depending on used API, x86app in wow64 mode can be forwarded to another part of registry. If the registry access API is inconsistent, it can make a problem.
Is there some list of .dll files that are available on the various freshly-installed Windows platforms (or at least, the recent ones like Win XP and Win 7)? I am looking for a list similar to this one for Windows 2000.
(I am compiling a python app with py2exe, and the application reports which dlls are required for potential distribution with the compiled application, but unfortunately it doesn't tell me which ones are installed by default)
I think this is what you're after (at least for Windows 7).
And here's the Windows XP version.
If you are targeting different windows versions with your application, it is a really good idea to set up a virtual test environment for each of the primary target platforms, for example, using VMware, MS Virtual PC or Oracle Virtual Box. If you then still need the list of all available DLLs, just look in the windows folders after a fresh install in the virtual machine by yourself.
By the way, having a look on the py2exe tutorial site, the example shows up ADVAPI32.dll,
USER32.dll,SHELL32.dll and KERNEL32.dll as DLLs on which the generated files depend. AFAIK those DLLs are primary windows components, not to be deployed by your program, and available under all Windows versions I had to deal with the last 15 years.