there are a few differences between the two
One, the x64 version can handle more RAM. the 32 bit can handle ~3.5 GB while the theoretical limit for a 64 bit OS is around 64 GB (i think, but most motherboards can't handle more than 8)
So, some games will deff. benefit, especially if you have background tasks running taking up system resources
Two, the x64 is a little more secure, because malicious code needs to be written specifically for the x64 bit architecture.
To my knowledge, the 64 bit doesn't take up any more room than the 32 bit, and if it does, the space is negligible
The last big difference, is driver support. When vista first came out, there weren't allot of hardware drivers that worked w/ it, and even fewer w/ the x64 bit version. That issue is mainly gone now, but its still wise to make sure that your hardware will be supported on the 64 bit OS
I recommend the x64 bit version, as it allows you to have more RAM, which will be beneficial in the long run
The CPU reads the actual binary code, which is presented in the form of instructions. These instructions are the "x86" and "x64" that you read/hear about. Now, most people understand that an x86 Processor (pre~2003, 2004) can't run x64 code. That's because the newer standard has commands, syntax, instructions, and data sets that do not exist in the older one. BUT: Understand that the newer x64 instruction set includes everything in the x86 - So any x64 processor can and will fully handle anything that's x86. Indeed, if your processor is a Sempron, P4, or newer, it *is* an x64 processor.
Therefore, as long as the (game) was compiled to the x86 (32bit) standard, the CPU can fully understand and run it because they are still 'speaking' the same language. And the reverse isn't true: Imaging speaking to a grade school child with words and phrases an MBA can use. The kid (older standard) won't understand it. The MBA can fully understand the child, though.
On the side of the OS: There is a similar mechanic, though here it's called an "API" (Application Programming Interface). In very broad terms, it works like the instructions sent to a CPU: These are the commands and formats programmers use to talk to the Operating System, which they use to access system resources like memory and information on the hard drive. You can think of it like the teller window at the bank: It's your way to pass an instruction inside in order to get the result you want. When you go to the teller (API), you have to give her a message [/i](instruction)[/i] in the format that that she understands, right? The OS wants to see some Function (Withdrawl), the location required (Account #), and some data set (how much). If you give the teller (OS) that, then you'll get your twenty bucks.
As long as the program (game, whatever) follows the proper API's then it will run on the Operating System.
Therefore: As long as a given (32 bit) game is written to the proper Windows (Vista) API's, and compiled to run on an x86 processor, then it *will* run on 64 bit (Vista).
Generally speaking, when you hear about incompatibilities it's because the programmers who wrote a given application either did not adhere to the proper API spec when they wrote their code, or because they took short cuts (which may no longer work), or because the (new) Operating System's API set is different from the old one.
This is why that 10 year old game, or the printer, or whatever doesn't work any more. The rule "Dont run old sh*t on your new sh*t" exists for a reason, after all
**For Tom's Regulars - Yes: Like the memory one, I saved this into (another!!) local doc for easy reposting. And for the same reason.