upvote
The problem was in the early 2000s it was basically accepted x86 was a dead end whose days were numbered.

Itanium was the heir apparent but importantly basically vaporware. How do you develop software NOW and more importantly sell and ship software NOW that'll work on a CPU you don't have access to and for which good compilers don't really exist yet? I remind you in the days where online updates were a luxury at best.

Processor agnostic CIL/JIT code was the prescribed solution at the time. Java had lit the way, and it was the only "clear" path forward for better or worse.

Little did we know Itanium would implode, and x86-64 would rise and give 20+ more years of binary compatibility.

reply
They were recovering from all of the security fiascos of software that wasn’t being updated. So they pushed as much as they could into the core libraries and forced only one version to be installed at a time- so they could easily push security fixes.

This led to one of the trickiest things for early .NET consumer apps- getting the latest runtime installed.

reply