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.
Related
When I started the installer for VS 2017 the default installation directory was set to Program Files (x86). I am using Windows 10 x64 OS on a 64 bit machine.
I downloaded from this link https://www.visualstudio.com/downloads/. I just want make sure I am installing the right thing before proceeding.
This happens when the program is a 32-bit version, and you have a 64-bit version of Windows.
You have downloaded the 32-bit version and that's why its going to that folder. If you were to download a 64-bit version of Visual Studio(a), it would be placed (by default) in to "Program Files".
(a) Unfortunately no such beast exists, so VS will always end up in the x86 variant unless you explicitly put it elsewhere. In other words, what you're seeing is totally normal.
I have an add in for Microsoft Word, if I launch it from Visual Studio it open and run correctly but when I try to build and install the .msi on a 64 bit windows 7 I have a problem.
The installation end fine but when I try to open the add in, Word raise an error because it search for the add in in x64 programs file and not in x86 folder. I want that the add in is installed only in x86 programs file and I have specified as Target platform x86 and defaultLocation [ProgramFilesFolder][Manufacturer][ProductName].
What is the error?
There are 32-bit and 64-bit versions of Office, so the most likely cause of this issue is that the user has installed 64-bit Office. That means that it must look in the 64-bit locations because a 64-bit process cannot load a 32-bit Dll. You're referring to the x86 locations, so I'm assuming that your code is 32-bit.
If you don't want to support 64-bit Office then you'll need to detect when there is a 64-bit Word or Office on the system and stop the installation. If you do want to support 32 and 64-bit Office then build your 32-bit one, and then build another MSI with 64-bit target location, 64-bit code, and 64-bit folders such as ProgramFiles64Folder. Your users install the appropriate one for their Office architecture version.
I have Visual Studio 2010 in a 32-bit Windows 7. I need to compile my created vb.net program (lets call it myprogram.exe) to be able to run in a 64-bit Windows 7 environment.
I have set my VS2010 project to "Any CPU" and even so myprogram.exe doesn't run on a 64-bit Windows 7. However, it does on a 32-bit Windows 7.
Could be possible it's because I'm using System.Data.OracleClient for database connection?
Error message in 64-bit Windows 7:
"The version of this file is not compatible with the version of Windows you're running. Check your computer's system information to see whether you need an x86 (32-bit) or x64 (64-bit) version of the program, and then contact the software publisher"
The 64-bit Windows 7 has Framework v2 installed. I attach some picture to show that.
Supposedly, WOW64 should run automatically but will not work on all applications.
In this case, should I install on my 64-bit Windows 7 some "Windows virtual PC"?
EDIT:
My VS2010 Premium is in a 32-bit Windows7 environment, and only see "Any CPU" option available. I don't see any other one else.
Should I install in the 64-bit Windows7 PC some "32-bit virtual Windows7 "? Which one would you recommend?
If you compile your program with the target platform set to AnyCPU then, when you run you executable on a 64bit OS the JIT compiler emits code for 64bit systems and, on 32bit OS, code for 32bit systems.
From your error it is clear that something between your references is a 32bit only library and thus cannot be called from 64bit code.
You could switch back to 32bit setting the x86 target platform in your Build Configuration or try to identify the library responsible and check if a 64bit version exists.
However, if you don't have specific reasons to use AnyCPU then you could still use x86 because in some cases the performances are better than 64bit code
You could read about the PROS and CONS of AnyCPU in this a little old, but still valuable, article
Try instead setting it from "Any CPU" to "x86" to force it to run on the 32-bit architecture. The problem might be that your program is relying on DLLs that aren't supported on the 64-bit architecture.
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
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.