Windows NT on Alpha and FX!32 Binary Translation

For a few years in the mid-1990s, you could buy a Windows NT workstation that was not an x86 machine at all, and the fastest of them ran on Alpha. This is the story of NT on Alpha, the firmware that booted it, the clever FX!32 translator that ran x86 software on it, and why the whole effort stopped in 1999.

A portable operating system with a real second architecture

Windows NT was designed from the start to be portable. Its kernel sat on a hardware abstraction layer, most of the system was written in C, and the first release, NT 3.1 in 1993, shipped for x86 and MIPS, with an Alpha version following within a few months. PowerPC followed a little later. By the time NT 4.0 appeared in 1996, the non-x86 field had thinned, and Alpha was the one alternative architecture with real commercial momentum behind it, largely because Digital pushed it hard as a workstation and departmental server platform.

It is worth being precise about what "NT on Alpha" meant technically. The Alpha was a 64-bit processor, but NT on Alpha was a 32-bit operating system. Pointers were 32 bits wide and sign-extended into the 64-bit registers, so the address space looked exactly like the x86 version to applications. That kept source portability high: most Win32 code needed a recompile rather than a rewrite. It also meant the 64-bit capabilities of the chip were largely idle under NT, a point that mattered later.

AlphaBIOS: firmware that looked like a PC setup screen

Alpha machines traditionally booted from the SRM console, the command-line firmware used by OpenVMS and Digital UNIX. NT did not use SRM. Its boot path expected ARC-style firmware, and Digital's early NT machines shipped with a fairly spartan ARC console. That was replaced by AlphaBIOS, a menu-driven setup utility that deliberately resembled a PC BIOS screen: disk setup, boot selections, date and time, and hardware configuration, all with the arrow keys.

Many Alpha systems carried both SRM and AlphaBIOS in flash and could switch between them, which is why hobbyists today still need to know which one a board is set to before it will boot anything. API's UP1000 and UP2000 boards were sold into both the NT and Linux markets and their firmware options reflected that. Our SRM, AlphaBIOS and MILO primer covers the switching mechanics in detail.

The application gap

NT's portability solved the operating system problem, but not the software catalogue problem. Microsoft shipped native Alpha builds of its own server products and a handful of desktop applications, and some engineering vendors produced Alpha ports of CAD, simulation and database software. Popular shrink-wrapped Windows software, however, was almost entirely x86-only. A buyer considering an Alpha workstation had to ask not just "is it faster?" but "will my tools run on it at all?"

Digital's answer had several layers:

• Native ports of important applications, often subsidised or assisted by Digital engineers.
• Built-in 16-bit x86 emulation in NT itself, which handled older DOS and Windows 3.x software, slowly.
• FX!32, a system for running unmodified 32-bit x86 Win32 applications with performance that could approach, and occasionally exceed, contemporary x86 machines.

How FX!32 worked: translate, cache, improve

FX!32 appeared around 1996 and 1997 and is still one of the more elegant binary translation designs of its era. Rather than translating an entire program up front, or interpreting it forever, it combined the two over time.

1. First run: emulate and profile. When an x86 program was launched, FX!32 ran it under an emulator. As it did so it recorded a profile: which routines were executed, which branches were taken, where indirect calls went.
2. Background translation. After the program exited, typically when the machine was idle, a separate translator process used that profile to compile the hot x86 code into native Alpha code, applying optimisations that a pure on-the-fly translator could not afford.
3. Cache the result. The translated code was stored in a database on disk, keyed to the original executable and DLL images.
4. Subsequent runs. Next time the program launched, translated routines ran natively and only newly discovered code paths went through the emulator, which in turn extended the profile for the next translation pass.

This design had a useful property: the more you used an application, the faster it got. It also meant the translator could spend real time on optimisation because it was not on the critical path of the user's interaction. Win32 API calls were intercepted and routed to native Alpha versions of the system libraries, so time spent inside the operating system ran at full native speed.

Published performance claims varied widely by workload, and should be read with the usual caution. As a rough guide, well-translated integer code on a fast Alpha could land in the neighbourhood of a contemporary mid-range Pentium Pro or Pentium II, while floating-point-heavy code sometimes did better. Programs with lots of self-modifying code, unusual calling conventions or heavy use of undocumented tricks fared worse.

Why Windows 2000 for Alpha never shipped

Through 1998 and into 1999, Windows 2000 (originally NT 5.0) was being developed for Alpha alongside x86, and beta and release candidate builds for Alpha did circulate. Then, in the late summer of 1999, Compaq, which had acquired Digital in 1998, announced it would stop supporting 32-bit Windows NT and Windows 2000 on Alpha. Microsoft ended its 32-bit Alpha work shortly afterward, and Windows 2000 shipped in early 2000 for x86 only.

Several factors, some documented and some fairly speculative, pushed toward that outcome:

• Sales volume. NT on Alpha had loyal customers but was a small fraction of the NT market, while requiring a parallel engineering, testing and support effort at both companies.
• Compaq's priorities. Compaq was a major x86 server vendor. Alpha's strategic home inside Compaq was increasingly Tru64 UNIX, OpenVMS and high-end technical computing, not Windows.
• The 64-bit question. The industry's 64-bit Windows future was being tied to Intel's IA-64. A 32-bit NT on a 64-bit Alpha was a transitional product at best. (Flagged speculation: Alpha hardware reportedly remained useful internally as a development vehicle for early 64-bit Windows work for a while after the 32-bit product was cancelled.)
• Application pull. Without broad native software, Alpha NT depended on FX!32, and it was hard to argue for a premium platform whose best-selling feature was running someone else's binaries.

The December 1999 statement on Alpha strategy from Compaq, API and Samsung, archived here, is best read in this light: the partners were repositioning Alpha around Linux, Tru64 and high-performance technical computing precisely as the Windows door closed.

What it meant for API and for collectors

For Alpha Processor, Inc., the loss of Windows 2000 sharpened a shift that was already under way. API's boards and systems leaned increasingly on Linux, clusters and the high-performance computing market, which is where most of the later press releases on this archive sit.

For collectors in 2026, NT 4.0 on Alpha is an entertaining period installation: the last service packs for Alpha, AlphaBIOS on a supported machine, and FX!32 loaded with a few 1990s x86 utilities make a genuinely unusual desktop. Keep install media and service pack images archived carefully; they are much harder to find than Alpha Linux distributions.

Further reading on this archive

• Collector's guide to Alpha hardware: which machines make good NT 4.0 period builds.
• Running Linux on Alpha hardware today: the other half of the post-1999 story.
• API corporate pages: the company's own description of its role in the Alpha ecosystem.