First, my 2 cents: I'd imagine that any os compiled for the 64 bit chips (itanium or hammer) would feature a 32bit application layer (much as win98, win95, and win3.1 all featured application layers to their predecesors). This slows down things not running in 64 bit mode, but it's still compatible, which is a vast improvement.
Secondly, while I agree with
<< Actually it's not rewritten at all (well for the most part), it's just recompiled for that target because the OS is written in a higher language like C. They may have to recode parts of it to deal with things like endian changes (not sure if IA32 and IA64 are the same or not) and just plain 64-bit'dness vs 32-bit'dness, but most of it will work fine. >>
, I'll point out thatmore likely than not, the "endianess" of the chips have not changed (intel/amd has always been notoriously backwards in this, I doubt they would have modified this in their latest processors), but other small porting issues such as variable types, memory reads, etc, have to be modified. (Endianness, for those who aren't familiar, is the order of bytes in memory: most significant first is termed 'big endian' while least significan first is termed 'little endian' - the importance of this is typically seen in network communications - sending a short across the wire in little endian form usually causes problems if the host on the other side expects it in big endian form - ie: sending to a non-x86 machine - thus, there is a standard form for all network communcation. Realistically, since the OS changes everything to this standard form before sending it, even IF the byte order changed on the chip, all that would be modified is a simple include/header file that modifies the conversion from host-order to network order).