> [...] most of the time, staying with 32-bit and reducing the amount of memory being consumed will have a much larger impact for both the application and the operating systems as a whole.
Given you mentioned Steam, Kerbal Space Program is a great example here. They initially released a 64-bit edition due to community pressure.
It was full of bugs and crashed a lot, and all they got were complaints about a lack of QA. There were mod authors who actually introduced checks and had their mods refuse to run on a 64 bit build, because they didn't want their mods running on unreliable systems.
Ok. But what do you mean, that 64-bits programs are more buggy that 32-bits ones ? Or that company/developers are not yet confortable with releasing 64-bits versions of a program ? Or something else :-)
100% of 64-bit computers run 32-bit programs. The vast majority of users never know or care what arch is installed. The only time most people care about bit-ness (word?) is if they are 64-bit trying to run an ancient 16-bit program.
This isn't VHS vs Bluray; it's much harder to explain why there is an advantage when it can't be seen. The 64 not version isn't 35% faster, or has dozens of new features. It's mainly just compiled differently, and it is hard to explain memory limits and instruction sets to people.
But, does a program can use more than 4GB of RAM if it's compiled in 32-bit and executed into a 64-bit environnement (with more than 4GB of memory)?
I imagine that the answer is between yes and no.
I imagine that you, as developer, can choose between limiting your program not to use more than 4GB or let the system (host) do the memory re-mapping job for you...
https://www.infoq.com/news/2016/01/VS-64-bit