Is it possible to set up the compiler in such a way so it compiles the executable/DLL for both x86 and x64? I mean, one file suitable for both platforms.
I only know of a way to choose the platforms separately, but I want both.
Is it possible?
x86 executable is fully supported on x64 host. E.g. any EXE you compile in 32-bit mode will run without any problems on 32-bit and 64-bit host. If you don't know why you need 64-bit executable, you probably don't, so 32-bit executable alone will suffice.
However, with DLLs it is a different matter. The DLL's architecture (32-bit or 64-bit) must match the executable where the DLL is going to be used. E.g. if you're writing an Explorer extension for x64 Windows, explorer.exe is going to be 64-bit, so your DLL must also be 64-bit, otherwise it cannot be loaded.
There is no way to combine two different architectures into one DLL or EXE on Windows. So you're going to need two DLLs if you need to support both 32-bit and 64-bit hosts.
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 a 32-bit object file o.obj and want to use it in a project that uses a 64-bit library l.lib.
To make the .lib happy, the Visual Studio configuration needs to be set to x64. However, the linker then throws an error of error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'.
I went through Visual Studio's linker options, but nothing jumped out. Is there a way to resolve this error?
I was under the impression that any 32-bit code is also compatible with 64-bit systems, modulo libraries.
x86 executables (that is, object code compiled for 32-bit x86 processors) can be executed on x64 machines running 64-bit operating systems, through a special compatibility mode supported jointly by the processor and the operating system. This is feasible because the x86 instruction set is a subset of the x64 instruction set.
However, many elements of the ABI differ between x86 and x64 code, notably calling conventions and pointer size. The calling convention needs to match between the calling code and the called code, or things will screw up. Thus, there is no straightforward way to call 64-bit code from 32-bit code, or vice versa.
I have two installers - one for 64-bit Windows and another for 32-bit Windows. The 32-bit installer installs 32-bit executable and DLls, while the 64-bit installer installs 64-bit exes and dlls as well as the 32-bit ones. The 32-bit components are shared by both installers.
Does Windows Installer explicitly allow this scenario? Thanks.
Yes, this is supported. Just make sure that the 32-bit components have the same names and GUIDs in both installers. This way a reference count is used for them.
Is there any way to compile an EXE file, so that it will run natively in both x86 and x64? Something like: compile both codebases and pack them into a single executable.
I know .NET code could run in "any cpu" mode, but it is not what I want.
A 32-bit executable will run natively on 32-bit and x64 Windows machines. The only way you're going to get x64 execution within a 32-bit PE file is by using an undocumented gate, which I highly doubt anyone uses in practice because it's highly version dependent (and undocumented).
Then again you make it so the 32-bit binary will execute a 64-bit version of the binary and exit if it detects a 64-bit CPU...
You could take the Process Explorer approach. In your 32-bit binary embed the 64-bit binary as a resource. If the 32-bit binary is launched on a 64-bit machine, extract the 64-bit binary and launch that.
I've got a Win32 process that is compiled and packaged in both 32-bit (x86) and 64-bit (x64) variants. I'd like the x86 variant to refuse to run on a 64-bit version of Windows (i.e. WOW64).
Is there any way to do this by setting linker flags? If not, what do I need to do?
You can check whether you're running under emulation by calling IsWow64Process.
Note, that you may need to load the function dynamically if you want to support older versions the OS.