I create a x86 process under WindowsServer2003 x64, ok, it work fine!
but I try creating a x86 process under VISTA x64.
it's failed with error code = 216. (ERROR_EXE_MACHINE_TYPE_MISMATCH).
anything difference between 2003x64 and VISTAx64?
I was debugging on a client's PC.
There is a 16-bit setup or 16-bit program or some 16-bit code in the product you are using.
This happens when you run a 16-bit EXE from CreateProcess (or CreateProcessEx) in an x64 machine.
Suggestions are
to contact the vendor of the software, tell them to upgrade their Innosetup to latest version (e.g., 16-bit Innosetup) or InstallShield to latest version (e.g., 16-bit InstallShield) and provide you with a new installer package.
If the product contains DOS or MS-DOS legacy EXE or COM files, you need to ask the vendor for Win32 or Win64 command-line based version.
run a copy of Windows Vista (32-bit), Windows 7 (32-bit) inside a VM. Those 16-bit utilities will function as normal.
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 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.