I've been trying to find more information about non-Intel versions of Windows NT regarding x86 emulation but found very little about it. There is one sentence about it in the Wikipedia page but the reference link is gone.

Was there any sort of x86 emulation on MIPS, PowerPC or Alpha versions of Windows NT?

1 Answer 1


There was x86 emulation on Windows NT, on MIPS, Alpha, and PowerPC — in fact, more than x86 emulation, PC emulation. The operating system itself ran natively, and applications could be built natively as well; but for a non-x86 port to be viable, it had to be able to run existing x86 programs.

The Alpha release of Windows NT was quite famous at the time for using a binary translator rather than a “plain” emulator, FX!32, developed by Digital; it would run x86 programs, keeping track of which parts of the binaries were actually used, and then translate them to Alpha instructions and store them in DLLs which were used the next time the programs were run. FX!32 was described in a fair amount of detail in various publications at the time, see this USENIX paper and this Digital Technical Journal article.

On MIPS and PowerPC (and Alpha for DOS x86 programs), NTVDM.EXE could emulate a PC as well, using a version of Insignia’s SoftPC (which was common on workstations at the time). This post on Virtually Fun looks at the MIPS version specifically.

The scope of these tools is different: FX!32 translates Win32-on-x86 to Win32-on-Alpha, whereas SoftPC emulates a complete 486-level PC. (Even though Alpha was always 64-bit, publicly-available versions of Windows NT were 32-bit only.)

  • 5
    After Intel bought the Alpha technology, FX!32 became the basis for the x86 emulation for IA-64, I believe. Interestingly, around the same time, Alpha technology showed up in both major vendors's products: AMD's new frontside bus at that time was based on the FSB of the canceled EV8. Jan 26, 2019 at 15:39
  • 3
    The comment about the alpha doing binary translation is not strictly true, unusually for a CPU, the alpha allowed the OS to load different microcode, and, at least some, of the x86 emulation was done in the CPU itself using this technique. The contemporaneous linux kernels have the gory details, if you're interested. Better still the Alpha boot rom (like the BIOS) could also use this feature so regular x86 option roms (like SCSI controllers, and video bioses) worked on an Alpha systems.
    – james
    Jan 26, 2019 at 20:24
  • 2
    @james are you referring to PALcode by any chance? As I understand it (and the last time I talked to an Alpha designer about this was twenty-odd years ago, so I might be wrong), PALcode is used to handle system initialisation, context switching, interrupt dispatching, cache management etc.; while it can take care of some instruction emulation, that’s intended for the optional instructions in the Alpha architecture, not for emulating a different architecture altogether. Jan 27, 2019 at 15:45
  • 1
    @StephenKitt - I spun up an old tape cartridge looking for the source of em86 and libem486.a but didn't find it (that was the linux helper binary that was syscall compatible with ia32) - I dimly remember a paper about how they'd cunningly added palcode instructions to do some of the x86 emulation, there are some alpha greybeards around here - I'll ask them.
    – james
    Jan 27, 2019 at 15:53
  • 4
    Just for what it's worth, FX!32 was effective enough that for a while, the fastest way to run some x86 Windows programs was under NT 4 on an Alpha (assisted, of course, by the Alpha's much higher clock speed). Mar 23, 2019 at 17:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .