32/64 Bit Wars to cease in 2012.

Oh, and here's another interesting tidbit:

if a program is written in Java, it will work just fine on any platform, as long s the proper VM is installed; (you can install 32-bit java on a 64-bit windows system too, I think, but there isn't any compatibility issue as far as the java code goes (unless the programmer adds it).

Same story for .NET applications, but you cannot easily install the 32-bit version on a x64 system (the 32-bit version really comes with the 64-bit version anyway). And the program is compiled basically when you run it- if you have a 64-bit system, the result is a 64-bit program. If you have a 32-bit system, it's 32-bit, etc. Even applications written in C/C++ often have both the 32-bit version and 64-bit version in the same file; some good examples of that being tools like Process Monitor, Process Explorer, and so forth, which wrap a 64-bit executable within a 32-bit executable, and when it starts, it unpacks the 64-bit version and runs it if it detects the machine is x64, otherwise it runs the 32-bit version.

And at this point, the creation/compilation of a 64-bit version of a program is often just a compiler switch away. As I noted, the main issue is that many programs rely on other components that don't have 64-bit equivalents, which is often beyond their control. This throws a monkey wrench into the works even for .NET and java applications; many java applications reference third party libraries or make system calls using JNI for a better user experience; these system calls differ by version and java and .NET go to a lot of trouble to make the system you are running on "transparent"- which is to say there is no obvious way to tell, without trying to be clever (Such as measuring the size of a IntPtr).

Personally, this has had a rather large effect on me, and most of my applications are now "force" compiled to be x86. This is because of my game, BASeBlock, which naturally requires the use of sound. I chose BASS.NET for a sound library. Unfortunately, there is only a 32-bit assembly for that, and in order to reference a 32-bit assembly, your assembly must be 32-bit. But since a 32-bit assembly can only reference a 32-bit assembly, I also had to change my update library to be 32-bit; and since some of my other applications used that library, I had to change their compilation options as well, etc. None of them would really benefit from the additional advantages of x64 (they don't do any heavy data processing or use gobs of memory) but it is still a massive pain in the rear; not to mention if I merely overlooked a x64 version (of the sound library), I'd end up having to test everything twice; once as x64, and once as x86. And then again on Mono for the same platforms, which makes things even more painful.

This may be why a large number of applications aren't 64-bit; for the same reason a large number of applications weren't 32-bit earlier; they simply didn't need it, and since it's usually wise to target for a lowest common denominator, they simply settled on 16-bit. In much the same fashion, we have various developers who simply  can't be bothered with 64-bit, and since they want it to work on 32-bit and know that a 32-bit program will also run on windows x64, they simply make a 32-bit version and forget about it.

Once the majority of systems are running x64, and developers can look on 32-bit as a thing of the past, like 16-bit before it, 64-bit will become the commonplace "default" for any application. At this point the "default" is to make it 32-bit, and make a 64-bit version if possible. Eventually, it will switch to make a 64-bit version and a 32-bit version if possible.

Oh, and here's another interesting tidbit:
...
Once the majority of systems are running x64, and developers can look on 32-bit as a thing of the past, like 16-bit before it, 64-bit will become the commonplace "default" for any application. At this point the "default" is to make it 32-bit, and make a 64-bit version if possible. Eventually, it will switch to make a 64-bit version and a 32-bit version if possible.

a
Point well mad BC. 
The is a very simple mechanism where a compiler thing can do a 64 bit EXE file that will convert itself into 32 bit when appropriate at run time. Perhaps that is what you were talking about. Or maybe not. Anyway, developers should consider doing something like t that. As you said, that should work unless the programmer was making assumptions about the size of pointers. But even that can be fixed. You just pay the programmer's unemployment compensation.

The is a very simple mechanism where a compiler thing can do a 64 bit EXE file that will convert itself into 32 bit when appropriate at run time.

Not exactly. the logic still has to be written; the Sysinternals tools use a particular method to make it a single executable. All that logic is part of the codebase, not something baked in by the compiler.

As you said, that should work unless the programmer was making assumptions about the size of pointers.

Not exactly... it will work but only in VM languages like .NET or Java. in C and C++, where pointer arithmetic is commonplace, a lot of dependency on pointers being a specific size can be added without realizing it. For example, various built-in types can change size. Of course this can be fixed with typedefs, but at the same time, there is the issue of file formats with regard to those data types.

basically, from a programming standpoint, a migration has several pitfalls:

First, a lot of applications rely on other applications created by other vendors; for example, solutions created using VBA. At that point regardless of how well your application is written, the application you are working with might not work well as a 64-bit application, or there might be compatibility issues between the 32-bit version of that application and the 64-bit version. Prime example?  an Excel application that accesses eBay’s Web service for the purpose of automating sales. The 64-bit version of Excel isn’t completely compatible with the 32-bit version of Excel, so you encounter a host of unexpected problems with your application upgrade. It’s easy to miss a problem such as using a 32-bit number to hold a 64-bit handle, truncating it, and causing a crash because the handle isn’t valid.

Data access- which I touched on before, can introduce all sorts of problems to the migration of an existing codebase. One prevalent issue is that a 64-bit application that writes 32-bit values will write then as 64-bit values, because the data type used in the codebase is a different size. So when a 32-bit application accesses that data, it only gets 32-bits out of a full 64 bits, and when it saves it back it essentially truncates what the 64-bit version wrote, assuming it understands it at all. In most cases, the entire database becomes mangled before anybody even notices there is a marshaling problem. Sometimes it can be more subtle. Example being managed code such as Java or .NET calling into the Operating System. To the managed code, the value still appears to be 32-bits (because it is supposed to be platform independent), but to the operating system that handle is really 64-bits and is treated as such, introducing a subtle, difficult to reproduce once every while crash or intermittent issue. What ends up happening is one of the devs has to trace every data transaction to ensure what you think you're writing as data is what you're actually writing.

This issue extends of course to disk storage, as well as in memory. Many devs learn the hard way that data structes that work fine in a 32-bit environment- or even a 16-bit environment- no longer work in a 64-bit environment. There can be many causes, but the primary one is that a 64-bit environment packs data into structures differently, which can break assumptions made in various locations of the code as to how the structure is laid out in memory. even if all the data elements are the same size, they aren't in the same location in memory that might be expected. Of course this issue is exacerbated by the more widely known, basic issue regarding pointer size.

Add into this the common practice of using "clever" code (which typically only proves how stupid you are... but, I digress) using things like bitshifts and bit-wise OR and ANDs to achieve tasks that they wouldn't typically be used for. Many of these "tricks" rely on the size of the value being manipulated to be 32-bits, an assumption which of course fails when those values are suddenly 64-bits wide.

There is far more to the migration than merely dealing with bigger pointers. For new code it is of course easy to take account and avoid; but many developers are dealing with codebases that are several years old and it is unlikely that 64-bit was even considered during initial development.