The problem is that, while the Unix-based world went the LP64 way (int is 32-bit, long and pointers are 64-bit), Windows went the LLP64 way (int and long are 32-bit, pointers are 64-bit). A lot of Unix programmers tended to behave as if "long" was the largest native type ("long long" on 32-bit uses a pair of registers). They have to scrub their whole code base for things like assuming an object's size or array index will always fit on a "long".

For software originally developed for Windows, LLP64 was supposed to make porting easier, since unlike on the Unix world (where "long" could be 32-bit or 64-bit), a lot of Windows programs assumed a LONG was always 32-bit, and that assumption was baked into file formats and IPC protocols.

Newly developed software has it easier; programmers nowadays keep in mind that there are relevant systems where sizeof(long) < sizeof(size_t), and since the C99 standard they have the stdint.h types to help (even on Windows with its pre-C99 compilers, since it's easy to find a working stdint.h for them).

----

As for Mac OS X, the porting problem is Carbon. If the code base is old enough, it'll be using Carbon, which AFAIK is not available for 64-bit.

Failing that, go to java.com and see what their check says.

5 years and 3 months after the issue was opened...

64-bit was important on Linux because the system libraries that Chrome uses were increasingly unavailable in 32-bit versions on 64-bit systems.

On other platforms, while there are advantages to 64-bit binaries, those advantages haven't outweighed the other useful things you could be spending engineering time on.