Does a 32 bit application running under WOW64 on a 64 bit version of windows still benefit from being compiled with the SAFESEH flag?
I understand this is irrelevant for 64 bit applications however I was unsure for 32 bit applications in the above context and have not been able to find an answer whilst googling.
TL;DR: Yes.
/SAFESEH is only valid when linking for x86 targets. /SAFESEH is not supported for platforms that already have the exception handlers noted. For example, on x64 and ARM, all exception handlers are noted in the PDATA
Even when running under WOW64 a 32-bit x86 app will still use the FS register to store the SEH chain and all the normal security issues apply. /SAFESEH will add a table of handlers to the PE file that is used in the exact same way as on a 32-bit version of Windows. SAFESEH is a compiler+OS feature (WinXP.SP2?) and the Windows part of it lives in NTDLL, not the kernel. If the OS component is missing (older Windows version) it would just act like normal SEH.
You can also think about it another way: You don't know ahead of time if the user is going to run you application on a 32 or 64 bit version of Windows.
Is it possible to make this library as 32bit? By default, this builds as 64bit.
How can i include this library in my 32bit application?
There's ways to cross-compile libraries, but it's usually easier to build from a 32 bit system if you don't know how. You can debootstrap a 32 bit userspace on your own system and use chroot to access it.
https://jblevins.org/log/ubuntu-chroot
It certainly is possible. Actually, one of gRPC's continuous tests is testing that the 32bit build works well.
We are using this 32bit dockerfile to build:
https://github.com/grpc/grpc/blob/5059fd195753d0c18e51efa930aebd7e0461ed51/tools/dockerfile/test/cxx_jessie_x86/Dockerfile
You can also crosscompile as others are mentioning above. You're not mentioning if you are building on linux, windows or macos, so I assumed you're on linux but building a 32bit grpc is possible on windows and macos too (and perhaps easier than on linux).
How do I know if the program I am writing in C++ will run properly in a 32-bit OS or not?
(without manually testing in one)
I am using Visual Studio and compiling in a 64-bit machine. Will that stop the program from working in other machines?
And what about the processor and Windows version? Will the binary be compatible with most Windows versions and processors, if the program just does a few simple things such as web requests and calculations, with a simple user interface?
My program doesn't have to be 64-bit. I would just like to create one binary that runs in most computers, like those I download every day on the Internet. How could I do that?
If you are building your code specifically for 64-bit Windows, you can't expect the binary to work on 32-bit Windows. That will require a separate build.
An executable compiled and linked for 64-bit will typically also require 64-bit libraries.
Use tools like the Dependency Walker to find out, if a given executable is refering to 32- or 64-bit libraries.
In Visual Studio, the "target platform" decides which CPU architecture you are targeting. It is perfectly feasible to create 64-bit executables on a 32-bit system, but you can't actually run them on such a machine.
You can do what's called cross-compiling i.e compiling on one machine for another. How to compile a 32-bit binary on a 64-bit linux machine with gcc/cmake This is what you're after if I read you correctly. There should be a Windows equivalent.
I am developing a cross-platform application and I need to determine whether machine B will be able to run the application that is compiled on machine A.
I am using Qt and I already understand that I need to either package the Qt libraries with the application or statically link against Qt itself.
I also understand that something compiled on Windows can't run on Linux.
However, there are still some other vectors that I'm not sure to what extent they matter. Here is the summary of my current understanding:
Affects Portability
Operating System (Windows, Mac, Linux)
Availability of third party libraries (Qt, static vs dynamic linking, etc)
May Affect Portability
Flavor of Linux (Ubuntu, Red Hat, Fedora)
Architecture (32 or 64-bit)
Version of Operating System (Windows 7 vs Windows XP, Rhel5 vs Rhel6)
Instruction type (i386, x64)
Of the May Affect Portability items, which ones actually do? Are there any that I am missing?
All. At least potentially.
If two different machines have no binary compatibility (e.g.
they run on different architectures, or interface to
incompatible systems), then it will be impossible to create
a single binary that will run on both. (Or... does running
a Windows program under Wine on Linux count?)
Otherwise, it depends. You mention third party libraries: if
they're dynamically loaded, they have to be there, but there's
always static linking, and there may be ways of deploying with
the dynamic library, so that it will be there.
The 32 bit vs. 64 bit is a difference in architectures: a 32 bit
program will not run in a 64 bit environment and vice versa.
But most modern systems will make both environments available
if they are on a 64 bit machine.
Issues like the flavor and version of the OS are more complex.
If you use any functions recently added to the OS, of course,
you won't be able to run on machines with an OS from before they
were added. Otherwise: the main reason why the low level system
libraries are dynamically loaded is to support forwards and
backwards compatibility; I've heard that it doesn't always work,
but I suspect that any problems involve some of the rarer
functions. (There are limits to this. Modern Windows programs
will not run under Windows95, and vice versa.)
There is also an issue as to whether various optional
packages are installed. Qt requires X Windows under Linux or
Solaris; I've worked on a lot of Linux and Solaris boxes where
it wasn't installed (and where there wasn't even a display
device).
And there is the issue whether it will run acceptably. It may
run on a smaller, older machine than the one on which you tested
it, but it could end up paging like crazy, to the point where it
becomes unusable.
If you compile an application on a 64-bit processor, it wouldn't by default run on a 32-bit processor. However, you can pass options to the compiler to have it compile code to run on a 32-bit processor. For example, if you're using GCC on a 64-bit machine, if you pass -m32, it will compile 32-bit code. 32-bit code by default can run on a 64-bit machine.
Sources
https://stackoverflow.com/a/3501880/193973
Different flavors of Linux or versions of operating systems may have different system libraries. For example, the GetModuleFileNameEx function is only available in Windows XP and up. As long as you watch what functions you use though, it shouldn't be too much of a problem.
The x64 architecture is backwards compatible with x86 ("32-bit"), so programs compiled for the x86 will run on x64 machines, but not vice versa. Note that there are other, less common architectures too, such as the ARM and PowerPC.
I can immediately think of three things that interfere with portability. But if your code is in a file format understood by both systems, an instruction set understood by both systems, and only makes system calls understood by both systems, then your code should probably run on both systems.
Executable File format
Windows understands PE, COFF, COM, PEF, .NET, and others
Linux by default ELF, OUT, and others
MaxOSX uses Mach-O
Linux has extensions to run the Windows/Mac formats too (Wine, Mono...)
Instruction set
Each processor is a little different, but
There is usually a "lowest common denominator" which can be targetted
Sometimes compilers will write code to do a function twice
one with the LCD set, one with a "faster" instruction set
and the code will pick the right one at runtime.
x64 can run 64bit and 32bit, but not 16bit.
x86 can run 32bit and 16bit, but no 64bit.
Operating System calls
Each OS usually has different calls
This can be avoided by using a dynamic library, instead of direct OS calls
Such as... the C runtime library.
Or the CLR for .Net.
I have Credential manager implemented in VC++ which captures credentials during login process. It works well in XP/Vista/Windows 7 32 bit env. But is not working in 64 bit.
Any idea ?
Thanks in advance for any help
If you want your DLL to be loaded by a 64-bit process, your DLL has to be compiled for 64 bits.
If you want your DLL to be loaded by a 32-bit process, your DLL has to be compiled for 32 bits. This is true on both 64-bit Windows systems and 32-bit Windows systems.
John gave you a useful link, even though John's wording is wrong. An application (exe) which is built for 32 bits will run in 64 bit Windows, but it can only load 32-bit DLLs.
Did you build for a 64-bit platform in Visual Studio?
A Visual C++ application which is build for a 32-bit environment won't work directly in a 64 bit environment. And although applications will work using the WOW64 compatibility layer, DLLs must be 64-bit if they are to be loaded by a 64-bit operating system.
Since that is indeed the case here, you need to build your project for a 64-bit platform (Visual Studio 2005 and later have a 64-bit compiler).
See the link http://msdn.microsoft.com/en-us/library/ms185328.aspx for more details.