Two developers have released version 0.1 of an experimental IA-64 emulator that can boot Windows XP and Windows Server 2003 for Itanium—operating systems that until now were locked behind rare, power-hungry enterprise hardware. The emulator marks the first time in years that users can launch these obscure Windows editions on commodity x86-64 machines, though performance is extremely limited and many features remain incomplete.

A Glimpse of Itanium Windows on Your Desktop

The new emulator, built by Yufeng Gao and gdwnldsKSC, builds on the decades-old Ski instruction simulator originally developed by Intel. It targets an HP ZX2000-class workstation and attempts to reproduce enough of the platform—firmware, NVRAM, storage, and chipset—to boot unmodified Itanium operating systems. The project is in “very early alpha,” as the developers caution, but the fact that it can start Windows’ graphical setup is an achievement in itself.

The emulator operates as a command-line tool on a Linux host. Users feed it a firmware image, a raw disk file, and an ISO, then watch serial output scroll by as the guest struggles to life. There is no polished GUI, no installer script, and no guarantee the guest will reach a usable state. Yet for retrocomputing enthusiasts, IT historians, and the simply curious, it cracks open a door that had been sealed for more than a decade.

What the Emulator Can (and Cannot) Do Today

The compatibility list makes interesting reading. Gentoo Linux reaches its rescue shell if you provide a kernel 6.6 or earlier; later kernels removed IA-64 support entirely. FreeBSD almost gets to a login prompt before hanging. Ubuntu and Debian stall early in boot, likely due to missing chipset support or timing quirks.

For Windows users, the star attractions are Windows XP 64-Bit Edition for Itanium and Windows Server 2003 for Itanium. Both are reported to start setup successfully and even open a command shell. Installation is so slow that completing it in a single sitting is impractical, and the desktop environment is not yet usable, but the core CPU emulation is clearly sufficient to execute the Windows kernel and basic drivers. Intriguingly, Windows Server 2003—a release more strongly associated with Itanium’s enterprise niche—has been shown booting in developer demonstrations, providing the most visually striking proof of progress.

HP-UX and OpenVMS do not boot at all. That is a significant gap, since these operating systems were the architecture’s primary commercial raison d’être. The emulator’s developers acknowledge that substantial platform work lies ahead for those targets.

How We Got Here: The Itanium Odyssey

Intel and Hewlett-Packard conceived Itanium in the 1990s as a grand unification of high-end computing. Rather than extend the familiar x86 design, they pursued a radically different VLIW-inspired approach called EPIC. The compiler would find parallelism in advance and pack instructions into explicit bundles, freeing the processor from complex runtime scheduling hardware.

The idea was elegant on paper, but real-world code proved stubbornly unpredictable. By the time “Merced”—the first Itanium—arrived in 2001, it was late, slow, and abysmal at running existing x86 software. The nickname “Itanic” stuck. Still, HP (later HPE) kept Integrity servers alive, and Intel released updated generations through “Kittson,” eventually announcing discontinuation in 2019 with final shipments in 2020.

Microsoft supported Itanium from the start. Windows XP 64-Bit Edition for Itanium shipped in 2001, followed by a 2003 revision. Windows Server 2003 offered an Itanium edition that stood as the more strategically important product. These releases are often confused with the later “Windows XP Professional x64 Edition” for AMD64/Intel 64, but they are entirely distinct—different instruction sets, different boot environments (EFI vs. legacy BIOS), and different driver ecosystems.

For preservationists, the challenge was always hardware access. Second-hand Itanium workstations are expensive, finicky, and power-hungry. This emulator changes that equation, making these obscure Windows variants accessible from an ordinary PC.

What This Means for You

For home users and hobbyists, the emulator is a curiosity first. Imagine browsing a Windows XP control panel where every binary is a 64-bit IA-64 executable, not x86-64. You could inspect system files, compare service-pack behavior, or simply see a piece of Microsoft history that fewer than a handful of enthusiasts have ever touched. This isn’t a daily driver—it’s a museum exhibit you can interact with.

For system administrators and IT professionals, the value lies in documentation and recovery. Organizations that still have Itanium-born applications might use the emulator to research migration paths or extract configuration data without firing up decommissioned Integrity servers. But let’s be clear: this alpha build is not a supported disaster-recovery platform. It cannot replace a Hyper-V or VMware replica of a live server.

Developers interested in emulation or platform preservation will find the project a rich debugging environment. Because Linux has open-source kernels, it provides an invaluable testbed for fixing CPU bugs before tackling proprietary Windows binaries. The fact that Linux 6.6 is the cut-off point—after which mainstream kernels dropped IA-64—means this build captures a critical snapshot of architecture-specific code that may never be revived upstream.

Getting Started: A Developer’s Workflow

If you want to try the emulator, prepare for a command-line grind. The only documented test environment so far is Ubuntu 24.04, and the process goes something like this:

  1. Acquire firmware legally. The emulator requires an EFI-based boot image designed for Itanium workstations. These files are not freely redistributable; you’ll need to extract them from a physical machine or obtain them through proper channels.
  2. Prepare disk images. Use dd or similar tools to create blank raw images for the virtual hard drive.
  3. Generate NVRAM. The emulator expects a persistent firmware settings file. The --nvram option creates one, but if the guest goes blank, you may have to delete and recreate it.
  4. Launch with specific parameters. A typical command line specifies the ZX2000 model, firmware binary, guest RAM (say 512 MB), CD-ROM ISO, and disk image. Serial output is directed to your terminal.
  5. Monitor and wait. Boot times are measured in hours, not minutes. Keep a log of serial messages; if the guest hangs, that log is your primary diagnostic tool.
  6. Keep the system offline. Windows XP and Server 2003 no longer receive security patches. Even running them in an emulator, isolate them from any network you care about.

Remember that the emulator interprets every IA-64 instruction on your x86-64 CPU—there is no hardware acceleration. The developers candidly estimate performance as comparable to a 486-class machine when running on a modern Ryzen 5000 host. That means a Windows installation designed for a workstation-class Itanium becomes an exercise in patience.

Limitations and Caveats

This is version 0.1. Screenshots of desktop screens are impressive, but they do not mean every instruction, device, or edge case works correctly. Storage can corrupt, timers can drift, and race conditions can lurk silently. A bug in predicate handling might not crash the system until millions of instructions later, making debugging a nightmare.

Firmware and operating-system licensing add legal thicket. Commercial media for HP-UX, OpenVMS, and Windows cannot be downloaded freely just because the hardware is obsolete. Emulation does not erase copyright obligations. Users must bring their own legitimately owned installation sources.

Additionally, certain platform features remain reverse-engineering puzzles. HP’s management processors, proprietary I/O bridges, and firmware quirks are poorly documented publicly. Until they are replicated, some operating systems will refuse to pass early boot stages.

Looking Ahead

The next milestones are clear: a complete Windows XP or Server 2003 installation that survives reboots and reaches a stable desktop; a reproducible Linux boot script using the last IA-64-supporting kernel line; and the first signs of life from HP-UX or OpenVMS. Each will demand weeks of trace analysis and incremental fixes.

Performance must eventually improve. Options include migrating from interpretation to dynamic binary translation and smarter caching of translated code blocks. But correctness comes first—a fast emulator that silently corrupts data is useless for preservation.

Longer term, a reusable IA-64 CPU core could be separated and integrated into broader emulation frameworks like QEMU. That would lower the barrier for new contributors and open the door to multiprocessing, snapshotting, and networking.

Itanium will never fulfill the future Intel once imagined for it, but with this emulator it need not vanish entirely. The Windows editions it hosted—so often mythologized, so rarely seen—may finally find a permanent home inside the portable software museums that keep computing history running.