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?

  • 57
    because stupid programmers keep assuming sizeof(int)==sizeof(void*) – ratchet freak Jan 3 '15 at 2:04
  • 16
    The topmost reason in our environment is the dependance on some third-party components which are not available as 64 bit. Do not know if that applies to Unity, too, but I would not be too astonished if that is the case. – Doc Brown Jan 3 '15 at 9:49
  • They can use typedef like int32,int64 for int ,float,pointer instead of assuming their size. Which might solve a lot problem. Many of problems start from the time we start assuming. – Kshitij Jan 3 '15 at 13:11
  • Which is in fact a perfectly reasonable assumption on flat architectures. Windows got it wrong deliberately to avoid breaking their own screw-ups. – Joshua Jan 3 '15 at 18:17
  • 3
    Why would that be a reasonable assumption? I'd expect to have a decent operator* for int, but pointers don't need that. Also, most Linux and Unix environments have int at 32 bits too. – MSalters Jan 3 '15 at 19:47

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.

  • 10
    Note that it's possible to write a bug that only manifests when an x86 binary is run on the 64 bit version of the OS. It's just harder ;-) – Steve Jessop Jan 3 '15 at 5:42
  • 6
    +1. I would like to add the following to the point of "release management": if my software relies on third-party components, even if there is a 32 and a 64 bit version of a specific component available, the additional effort for testing new releases should not be underrated. So IMHO release management should be the first point on that list, not just a side note. – Doc Brown Jan 3 '15 at 9:53
  • Could you elaborate on the int pointer size issue? Is it because in a 64bit environment, the memory space would be higher than what an int allows? – TankorSmash Jan 3 '15 at 17:21
  • 4
    @TankorSmash: on x86 normally 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. – Matteo Italia Jan 3 '15 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

  • 8
    The issues can go farther than just compilation, too; I have a muscian friend who can't use the available 64-bit FL Studio because they require many VSTi's that are only 32 bit; other dynamic-link based plugin architectures are simillarly affected. – StarWeaver Jan 3 '15 at 5:44
  • Thanks for the edit: I am normally VERY picky about grammar but made a few mistakes. And @StarWeaver I think I touched on that when I said the code might compile but have bugs. This still goes back to my point about writing clean code for whatever language and platform you are targeting. – user22815 Jan 3 '15 at 5:57
  • "have show-stopper bugs" The show stopper are obvious and "in your face" and can be dealt with. What I think is probably worse is all the problems that produce subtly incorrect results that will go unnoticed for a long time. – Burhan Ali Jun 18 '15 at 12:52

Not the answer you're looking for? Browse other questions tagged or ask your own question.