Correct me if I'm wrong, but there is an exact case of where 32bit windows on x86 directly influenced 64bit. This is what I'm talking about when I talk about other 64bit platforms may not behave the way Microsoft expects. And this directly influences c/c++ register allocation.
Though I will state, what Microsoft did for its fastcall on 32bit windows and 64bit is rather ingenious in that the same call can work on both platforms.
Right, being mainly an extension the x64 is hugely influenced by x86. The 64-bit Win32 ABI is obviously influenced too, to the point that on x64, 32-bit process is largely just a native 64-bit process with 32-bit modules loaded.
Most of the time, the differences are hidden by abstractions in the Win32 C API. The calling conventions do a pretty good job of this (especially the 64-bit ones). Still, there is a nontrivial amount of software that does need to use a few (or many) assembly instructions or interact with the CPU in low-level ways. Windows is a relatively friendly OS for applications that rely on non-standard behavior.
You can't "just port" an antivirus package. Certainly many malware samples won't run on ARM either, but many will (like .vbs). It will take time to sort all that out. In the meantime, many companies simply won't deploy Windows without AV.
