Installing Windows NT 3.x in VirtualBox

All Windows NT 3.x versions can be used in VirtualBox, although they are not officially supported (unlike all following NT versions) and no Guest Additions are provided. Furthermore, for Windows NT 3.1 and 3.5, an extra step needs to be taken before installation.

In all cases, it’s best to start with a guest configured for NT 4. It is advisable to add a floppy drive and, if audio is desired, use SoundBlaster 16 emulation. USB may be turned off completely since there are no drivers, and the emulated network adapter must be left at AMD PCnet. SMP is not supported.

Unlike NT 4, the Windows NT 3.x installation CDs are not bootable. It may be easiest to start by installing DOS with CD-ROM drivers and running the DOS based installer from the CD. For NT 3.1 that is the only option due to lack of ATAPI CD-ROM drivers. For NT 3.5x it’s possible to boot from floppy images and continue installing from CD.

Windows NT 3.1 and 3.5 installers contain paranoid code which refuses to install the OS on an unknown processor family. The installer will fail if it finds a CPU which isn’t a 386, 486, or a Pentium:

This was a problem back in the mid-1990s when Pentium Pro CPUs came out. Back then the only recourse was editing two .INF files used by the installer by hand. That is possible with VirtualBox, but left as an exercise for the reader. An easier method is adjusting the CPUID information returned to the virtualized guest.

A comprehensive description of CPUID data may be found on Intel’s website as Application Note 485. The following text assumes basic familiarity with the CPUID mechanism.

CPUID leaf 1 contains the processor family and must be adjusted. Only the EAX register value needs to be changed, but VirtualBox overlays entire leaves. This is the command I used on a host with an Intel Core 2 processor:

VBoxManage modifyvm NT3.5 --cpuidset 1 00000543 00000800 00000209 078bf1bf

The VM was obviously named NT3.5. The first argument of –cpuidset is the leaf number, the other four are the values of registers EAX/EBX/ECX/EDX. The EAX value is the crucial one and is set here to 00000543, which corresponds to a Pentium MMX. The last three values were not modified and were taken from the VBox.log file. Near the beginning of the log file, there’s a section listing raw standard CPUID values. The interesting one in this case looked like this:

Gst: 00000001  000006fb 00000800 00000209 078bf1bf

The ‘Gst’ prefix indicates this is the value reported to the guest. The 000006fb value indicates a Core 2 CPU and is what upsets Windows NT 3.5. The rest doesn’t cause problems and needs no modification. Using the data for a Pentium MMX (for instance) would likewise achieve the desired result. The CPUID override is only strictly required during installation, but running the setup applet will still result in an invalid CPU error if the override is removed.

Windows NT 3.1 is the trickiest to install because it is so old (1993). It won’t recognize more than 64MB RAM, regardless of how much is configured for the VM. It does not come with drivers for PCnet adapter, although a PCnet driver for NT 3.x may be obtained from AMD. On top of that, the TCP/IP implementation does not support DHCP. As mentioned above, there are no ATAPI CD-ROM drivers shipped with the system. Again, third party drivers do exist.

Things are much better with Windows NT 3.5. The CPU overrides are still required for installation, but the OS comes with AMD PCnet drivers as well as ATAPI drivers, and the system supports DHCP. Even better, the installer supports floppy-less operation (WINNT /B).

Windows NT 3.51 is very similar to 3.5, but no longer requires the CPUID overrides. NT 3.51 was released around the same time as the Pentium Pro and the CPU family checks were clearly no longer useful. Because NT 3.51 properly supports PCI, it can be also optionally installed on the emulated BusLogic SCSI adapter in VirtualBox.

On the network, Windows NT 3.x can easily interoperate with newer Windows NT versions, OS/2 LAN Manager, or Microsoft and IBM DOS networking products.

This entry was posted in NT, VirtualBox, Virtualization. Bookmark the permalink.

15 Responses to Installing Windows NT 3.x in VirtualBox

  1. Yuhong Bao says:

    “SMP is not supported.”
    SMP is supported on NT 3.5 and later with it’s Intel MPS support.

  2. michaln says:

    You’re right, except you’re wrong. Windows NT of course supported SMP ever since the first 3.1 release, with Intel MPS being one of the supported SMP variants since version 3.5.

    However, the text you quoted rather clearly applies to NT in the context of VirtualBox. And in VirtualBox, SMP for NT 3.x is not supported. If you can get it working, please let me know–I’d love to know how you did it.

  3. Yuhong Bao says:

    Why isn’t it supported on VirtualBox, BTW?

  4. kinokijuf says:

    Because VirtualBox only supports MPS 1.4, and NT 3.x only support MPS 1.1.

  5. michaln says:

    The MPS 1.1 requirement is true for NT 3.5, but I don’t think it’s true for NT 3.51. At any rate, there’s more to it than the MPS version.

  6. Pingback: Why Windows NT from October 1992 refuses to install on modern CPUs | OS/2 Museum

  7. Pingback: Windows NT 3.1 (and OS/2) Memory Detection | OS/2 Museum

  8. Sean McDonough says:

    >Unlike NT 4, the Windows NT 3.x installation CDs are not bootable. It may be easiest to start by installing DOS with CD-ROM drivers and running the DOS based installer from the CD. For NT 3.1 that is the only option due to lack of ATAPI CD-ROM drivers. For NT 3.5x it’s possible to boot from floppy images and continue installing from CD.<

    It actually isn’t the only option for NT 3.1; if you add a SCSI controller to the VM, set the type to BusLogic, attach an optical drive to the controller, and insert the ISO into that, NT 3.1 will happily boot from floppy and install from CD (at least on VirtualBox 5.1.28; I don’t know if SCSI emulation was possibly not as good in earlier releases). Can confirm as the proud owner of a smoothly-running NT 3.1 VM installed in this way.

    Sidenote: I have floppy images and an ISO for NT 3.5, but whenever I try to install it in a VM, it gets as far as formatting the virtual disk before informing me that I needed to have run the MS-DOS-based portion of Setup first; however, looking through both the floppies and the ISO in an MS-DOS 6.22 with CD drivers VM, I’ve been unable to find any such Setup application (or, at least, none that’ll run from MS-DOS 6.22, even with the CD drivers). Can you help with this? :-S

  9. Sean McDonough says:

    (Sorry about the six-year necro, but I felt like I needed to correct said incorrect information.)

  10. Michal Necasek says:

    I’m pretty sure when the article was written, the BusLogic SCSI emulation in VirtualBox wasn’t working with NT 3.1. You are right that now it does, and it’s entirely possible to install from CD.

    Re NT 3.5, is it possibly complaining about the CPU model? Anyway the DOS-based setup is winnt.exe. I don’t think I’ve had trouble installing NT 3.5, but it’s been a while.

  11. Michal Necasek says:

    When the article is talking about something that’s already quarter of a century old, a few years here or there don’t matter much 🙂

  12. Sean McDonough says:

    It doesn’t say anything about the processor; it just says that I should have run Setup from MS-DOS first. If the first image in the article is anything to go by, the CPU-check game-over happens early in the graphical stage of the install, whereas my attempted installation aborted during text mode, after it asked me how I wanted to format the disk but before actually formatting it (I think, at least – I’ll have to try again when I get home). This is having the effect of making NT 3.1 ”easier” for me to install in VirtualBox than NT 3.5!

    Also, no offence meant – I wasn’t trying to imply that you were wrong at the time the article was written (although, looking at my post, I can see how it would have come across that way; I probably should have worded that better!), but rather merely to note that what you said then is no longer true now.

  13. Sean McDonough says:

    Although, now that I look back at it again, it actually looks like I might have intended to say (to paraphrase) “I was right and you were wrong”; in that case, you have my sincerest apologies!

  14. Michal Necasek says:

    Yes, the CPU check happens in the graphical install phase, so that’s not it. If you tell me exactly what you’re doing and what error you get, I can try to reproduce it locally.

    No offense taken.

  15. Sean McDonough says:

    Actually, I think I’ve gotten past the problem; I simply had to look for winnt.exe in the i386 folder rather than in the CD’s root directory. *facepalm* Silly me…

Leave a Reply

Your email address will not be published. Required fields are marked *