'64-bit extended systems' refers basically to systems which boot up in the old x86 real mode and which support AMD's new 'long mode' of operation. '64-bit' is normally reserved for systems which actually boot up in a 64-bit mode and therefore require an entirely new BIOS and boot code. Aside: Intel calls this Extended Memory 64-Bit Technology, EM64T. I think this is a tacit admission that in fact their 64-bit support is entirely in microcode, or rather in the translation from x64 instructions to the P4/Xeon Netburst core's internal instruction set. Particularly I don't think Intel have actually widened the internal registers to 64-bit, nor widened the ALU to 64-bits. Conversely I think AMD actually have produced processors with 64-bit registers and ALUs. It doesn't seem like the kind of thing you can do in a stepping change - I'd expect it to need a new architecture. From a developer's standpoint you need a compiler that's compatible with the native 64-bit instruction set of the target processor, if you want to target 64-bit code. Both x64 and the Itanium family support existing 32-bit code, although the Itanium's hardware support is rather slow - it has pretty simple one-to-one mappings of x86 instructions to native instructions, and doesn't reorder instructions in the way that modern x86 processors do. I'm not sure if current Windows-on-Itanium releases use the IA32EL driver - a software JIT compiler for x86 instructions which actually ends up faster than the processor's hardware support. If you're a driver developer, you need to ensure that your device drivers can accept 64-bit addresses. You should have done this already for Processor Address Extensions mode on x86. You also need to make sure you're not using any x87 floating point operations in your device drivers as Windows-x64 doesn't preserve the x87 floating point registers across interrupts. Neither 64-bit environment supports 16-bit code. The Itanium has no support at all, while the x64 processors only support it in 32-bit emulation mode, i.e. when running a 32-bit x86 operating system. In long mode, no 16-bit support is enabled. Microsoft withdrawing Windows XP support for Itanium 2 is pretty inconsequential. A few people who bought workstations will be inconvenienced; the rest of us will never have to care about porting desktop software to the Itanium Processor Family. Of course the server editions are still supported. In some ways it's a shame because Itanium had a lot of potential. If Intel had managed to make it mass-market rather