I raised this question up because I have seen Windows 7 64 bits able to run several 32 bits program without any problem; of course, some run with problems and some refuse to run at all.
I am not sure why some 32 bits program can run just fine on 64 bits, but for us, in the future, say, if we have a 128 bit architecture and OS released in the future, what can we do in term of programming if we want our program to be able to run in a different bit architecture? Or is it not a programmer's job?
I've yet to see a mature application that does not end up with implicit assumptions about bit size. It creeps in whatever you do.
Also you cannot predict what the OS supplier will do to mess up their API either. At best you can only wrap and hide the external API into your own libraries.
Macroizing or typedefing the basic types doesn't work because people will invariably use the macros or typedefs for everything, and you are back to the same position you were originally where you can't differentiate what should be the new int size and what really does need to be 64 or 32 bits.
What you can do is save numeric values in ascii that does fix some of the file format issues.
There's two possible questions here: what to do to allow the binary to run, and what to do to allow the source to compile and run.
There isn't that much you can do to make the binary future-proof. Go strictly by the published API, and avoid using anything undocumented. It will run if the future system supports it, and the future system is far more likely to support the standard API than anything undocumented. This was the problem with many early Macintosh programs: instead of using the API (which was clumsy for some things early on), they used shortcuts that worked in OS 5 or whatever, and didn't in OS 7.
This advice is mostly for C and C++, as languages like Java define things much better. Any pure Java program should run fine on any later JVM. (Yes, this has its own costs.)
Abstract out all the architecture-dependent stuff you can. Use types like size_t and ptrdiff_t in C and C++, rather than any type of integer.
When you need a type of a particular bit size, don't give it a type like int or long. Use typedefs. There's a C99 header with useful typedefs for the purpose, but you can always have something like typedef int int32_t and change the int later, as needed, in one obvious place rather than scattered around the program in hard-to-find places.
Try to encapsulate OS calls, since those could change in a future architecture. If you must do anything with an undocumented OS feature, document it very noticeably.
If your program has anything to do with networking, assume nothing about the byte order. Networking byte order is unlikely to change, but your program might wind up on a chip with a different architecture (cf. the Macintosh, which has used three different architectures in its time).
In general, assume as little as you can get away with. Use types specifically designated for machine-dependent things, and use them consistently. Do everything outside the program as written in the most formal, standard, and documented way possible.
In this particular situation, is not up to you as developer to provide binary compatibility but that's up to the OS manufacturer.
The manufacturer can ignore this compatibility need and your program won't run anymore. But everyone will hate him.
So that's not a programmer task.
What you can do to minimize the risk ( furthermore when you're targeting different platforms ) is to use standard libraries and/or choose a cross platform programming language like Java.
Things you can do to keep your software running in any new platform:
About why 32bit application can run unmodified in 64bit systems, assuming you're talking about AMD64, it's because the HW architects had that in mind and provided a legacy mode.