In my short time programming, it has been trivial to compile any of my C++, Java, etc. for either a 32 or 64 bit machine so long as I have the full source for the program.
But a lot of software is not released 64bit. Most annoyingly, there isn't yet a 64bit release of the Unity engine.
What makes it difficult to compile some programs for 64 bit machines?
The general problem is that it’s very easy to encode undocumented assumptions in a program, and very hard to find places where those assumptions were made. High-level languages tend to insulate us from these concerns somewhat, but in lower-level languages used for implementing platforms and services, it’s easy to do things that are not necessarily portable across architectures:
Assuming that int is large enough to store a pointer
Assuming properties of the representation of pointers, e.g., for pointer tagging
Assuming that data pointers and code pointers have the same size
There is also the practical concern of release management. If I only make an x86 build, it will still run on x86-64, albeit perhaps more slowly due to the limited availability of registers. Whereas if I build for both x86 and x86-64, I must now test on both architectures and deal with bugs that may only arise on one architecture, increasing the cost of shipping a new release.
sizeof(int) == sizeof(void *) (they are both 32 bit); on x86_64, it's normal to keep int 32 bit (it remains compatible with x86 and avoids wasting space in memory), but pointers have to be 64 bit (since the virtual address space goes up to 2^64), so they can be no longer shoved into an int or unsigned int.
Commented
Jan 3, 2015 at 18:14
Most software will work the same when compiled for both the 32 and 64 bit Intel/AMD architectures. However, some software will not. Aside from laziness, or reaching a larger audience, there are some specific reasons why recompiling as 64 bit will not work.
Software may use unsafe pointer operations. Perhaps a program puts a pointer into an int, which is generally 32 bit for most C and C++ compilers. Pointers are 64 bits in a 64 bit program. That does not work.
Bit shift operations may produce different results if the integer type being used is a different size. This may be an issue when using a regular data type instead of a standard typedef such as int32_t
A data type used in a union may change sizes, changing the behavior of the union.
Software may rely on libraries that are 32-bit only. In general, a 64 bit program will only work with 64 bit libraries due to assumptions about the stack, pointers, etc.
The difficulty you ask about in your question is simply that in some code bases there may be millions of lines of code that perform unsafe operations, make unsafe assumptions, have shortcuts and clever "optimizations" put in by developers. The code will either not compile in a 64 bit environment, or it will compile but have show-stopper bugs. It may take a long time to fix all the issues. Maybe a company will fix them over time until it is possible to release a 64 bit version. Maybe a company will develop a "version 2" alongside current maintenance releases because a total rewrite is necessary.
The moral of the story is to write clean code and do not try to second-guess the compiler or add clever optimizations that are not needed, can break the software, and probably do not help anyway.
This article goes into far more detail than I could hope to include in this answer: 20 issues of porting C++ code on the 64-bit platform
sizeof(int)==sizeof(void*)operator*forint, but pointers don't need that. Also, most Linux and Unix environments haveintat 32 bits too.