Itanium was extraordinarily backwards incompatible. There's an enormous gulf between "runs software from the 80s" (which is something the PC platform only pretends to do anyway, because peripherals now are incompatible) and "can't run Windows at all". Breaking v8086 mode wouldn't prevent modern Windows from working (which is in fact why this bug wasn't noticed). You can't even enter it from long mode to begin with!

actually my windows 10 installation didn't used uefi. (I had a really old machine). Basically I upgrade/upgraded to ryzen. I don't think it will be easy to migrate to UEFI straight.

> Slight aside, there are a lot of reasons that Itanium failed, but certainly one of them was lack of backwards compatibility.

Itanium did not aim at the x86 market. The x86 translation layer was retrospectively seen as a mistake as well, because it wasn't relevant, but required transistors that limited the design's performance overall, which was relevant.

> Itanium did not aim at the x86 market.

Maybe not. But x86 certainly took over the market Itanium was aiming for.

x86 did not. x64 did.

You got it all backwards. AMD64 is a complete revamp which happens to support x86 in its legacy mode.

Server people care for 64-bit address spaces, and that's a feature introduced by AMD64 which is not available in x86.

This is also one of the main reasons why Mainframes still exist.

Backwards compatibility straight back to 1964 is a big deal, there's lots of 50+ year old code still in production at banks, insurers, and the like.

Pedantic point, but you couldn't really run an OS from 1990. It wouldn't support any modern peripheral buses required for normal operation.

But you certainly can natively run user-mode 16-bit DOS programs on a modern CPU.