Think of the operating system (OS) as being composed of two primary parts:
1) The "privileged" portion.
2) The "non-privileged" or "user" section.
Everything that goes into the privileged portion must match the "bitness" of that OS installation. In other words, if you install 32-bit Windows, only software whose privileged-mode componentry is also 32-bit can run on that machine. The same holds true for 64-bit; if an application contains one or more privileged components (drivers), they must be 64-bit to run on a 64-bit OS.
In the non-privileged "user" section the situation is a little more complex. A 32-bit OS installation will also support 16-bit user-mode code (old installers are sometimes 16-bit). A 64-bit OS will support 32-bit user-mode software, but not 16-bit.
The ability for any given app to run therefore hinges on whether it contains privileged code - a driver. If not, 32-bit apps will run on 64-bit OSs, but not vice versa. It's analogous to the way that a DVD drive can also read CDs, but an old CD drive wouldn't know what to make of a DVD.
32-bit and 64-bit software are fundamentally different in ways which go beyond the mere number of bits. When developing software, there is some additional overhead (work) required to produce both 32-bit and 64-bit versions. It also makes testing more complicated for the developer because they literally have at least twice as many scenarios to test. Hence, if a developer feels there is a market for their product in both 32-bit and 64-bit versions, they will build both. Otherwise, they stick to 32-bit for older and smaller apps, or they go exclusively 64-bit for larger and newer products.
The days of 32-bit software are numbered. Within a couple of years, it may become difficult to find any new applications shipping in 32-bit versions. 64-bit has every advantage from a technical point of view.
