zlacker

I think this was because at the time of picking the name, Windows with a working 65-bit Windows-on-Windows subsystem only ran on x86 and x64, so the naming made sense. DEC builds weren't relevant at the time and ARM was still far away from gaining 64-bit support. There was a 64 bit version of XP for Itanium but that couldn't run x86 code natively.

It'll be interesting to see what Microsoft will do if Windows on ARM actually takes off. As far as I know, the current translation layer can't execute amd64 on ARM, only x86. Will we see Program Files, Program Files (x64) and Program File (x86)? It would make sense; have the redirection system ready to go and the naming scheme would also make perfect sense. ARM doesn't need a special 32-bit folder because there's no notable 32-bit vs 64-bit clash; nobody is migrating upgrading their Windows CE device to Windows 11, after all.

>>jeroen+(OP)
x64 emulation for Windows on arm Already exists. It is not based on WOW style technology. Furthermore 32 bit arm programs do exist on modern Windows on ARM, using a version of WOW64 very similar to WOW64 on x64 cpus. But they also have x86 WOW64, based on the Itanium version, that had to do binary translation.

- "C:\Program Files" <- ARM64 programs go here, as do x64 programs! - "C:\Program Files (Arm)" <- ARM32 programs go here - "C:\Program Files (x86)" <- x86 programs go here

I'm not sure how things like "Common Files" work in C:\program files, unless they made mixing arm64 dlls with x64 exes and vice versa just work. Which they probably did. I'm guessing they did not want another WOW version, since it was already bad enough to have to ship 3 different copies of certain system components, and they did not want to need to include a 4th copy, especially as ARM devices are often a bit light on storage space.