From what I have read, for software which wasn't originally developed for Windows, especially if the code base is old enough, porting to 64-bit is harder on Windows than on other systems.

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.