With VirtualBox 4.3, it is possible to install the oldest known pre-release of Windows NT directly from CD, the way Microsoft intended. This is the Fall ’91 Comdex preview which only supported the x86 architecture and a very short list of hardware devices. The pre-release was available only on CD-ROM and although it was possible to install it more or less manually from DOS, there was a graphical installer on the CD-ROM.
However, the hardware support being as limited as it was, the only supported storage controller was Adaptec AHA-1540 or compatible with a SCSI CD-ROM attached. Fortunately this is adequately emulated by the BusLogic SCSI HBA device in VirtualBox.
Successfully getting through the NT setup isn’t as trivial as it ought to be, so here are a few hints:
- The SCSI CD-ROM should use ID 2 so that the default device selected by boot floppy can be used without any intervention.
- The hard disk may be either SCSI or IDE. Smaller is better (about 500MB IDE, 1GB SCSI).
- The VM must have a serial port enabled, otherwise NT will refuse to boot.
- The VM must have at least 12MB RAM assigned, and preferably 16 or more, or NT will crash or hang in various interesting ways. Yes, NT was bloatware, requiring much more RAM than its closest competitor, OS/2.
- Most importantly, NT will crash if the hard disk isn’t formatted—this is probably a bug in the installer. NT insists on creating a swap file, even when the system has plenty of RAM. If there’s no C: drive with a FAT partition, NT will print an error message and then get into a bugcheck loop and finally crash.
If everything is to NT’s satisfaction, the graphical installer will start and present a nice step-by-step installation wizard. It would be interesting to know why Microsoft used a fully graphical install in the pre-release and a partially text-mode installer in the finished product.
The choices are quite limited, and the pre-release nature of this NT version clearly shows—for example in the filesystem selection dialog, FAT is the only available choice.
Another sign is the debugging support dialog; while released NT versions supported kernel debugging, debug support was not a user-visible choice in the standard installer user interface and so-called checked build were available separately.
That said, despite the very limited choices, the October 1991 pre-release of Windows NT is a fairly complete system with a GUI and optional networking. The hardware support was extremely limited, but the system was not intended for general consumption.
Once the installation completes and the system is rebooted, a familiar user interface is presented:
The GUI is a clone of Windows 3.x, with a mix of elements from Windows 3.0 and 3.1 (Windows 3.1 was released approximately half a year after the Oct ’91 NT pre-release).
Curiously, the installation disc also functioned as a kind of a live CD, a concept unheard of in 1991. All it takes is exiting the setup, which lands the user in an empty desktop with an empty Program Manager… from whence it is possible to start CMD.EXE and other programs. Unfortunately the installation CD was clearly not intended for this and the environment (especially PATH) needs to be manually adjusted.
The October 1991 pre-release of Windows NT is historically significant as the first semi-public version of NT. It significantly predates the eventual July 1993 release of Windows NT 3.1, and shows how far along the OS was after nearly 3 years of development, but also how much was still missing relative to the final product.
“Yes, NT was bloatware, requiring much more RAM than its closest competitor, OS/2.”
I think even MS never intended “NT OS/2” to replace OS/2 2.x at least initially.
I assume this means you can install Dec91 with the graphical installer aswell?
And use cdinstall.img in later builds, without modifications?
(I already patched the NT 3.1 RTM text setup so cdinstall.img would work with the Aztech NT 3.1 IDE CD-ROM driver: see here http://www.betaarchive.com/forum/viewtopic.php?f=61&t=28570 )
Yes, the Dec ’91 build works too. It’s not all that different.
There’s one build which doesn’t work out of the box, but unfortunately I forget which. The older Adaptec 154x driver works on both Adaptec and BusLogic HBAs. In the NT 3.1 release, there are separate BusLogic (buslogic.sys) and Adaptec 154x (aha154x.sys) drivers and the Adaptec one no longer works on BusLogics. In one beta build, there’s the updated manufacturer-specific Adaptec driver but no BusLogic driver yet. It’s possible to use the buslogic.sys driver from the following build.
There’s no need to modify the final NT 3.1 release, CD installation works with the original media using an emulated BusLogic SCSI HBA and a CD-ROM drive attached to it.
Mess now emulates the 3c503, so you could NetBUI on this as well. I also recall the GUI had a checkbox to install the soundblaster driver (you could also fool the installer by copying the CD onto the hard disk, and running the install from under NT. This is how I managed to install the 1991 pre-releases on HPFS volumes…
Before I went on my large trip, I ran the 1991 stuff on a Pentium, and even that was pokey. but I was able to have it mount a 3.51 fileserver well enough.
Is there any chance that you would share the CD images? Would be interesting to add to my NT collection 🙂
It’s strange that they’d get rid of the GUI installer. If anything you’d think it’d be the other way around, with a text based installed in the early release and a GUI installer for the final release.
I don’t think they came back to a GUI until Vista?
Yes, Longhorn/Vista was where the GUI installer came back. The only reason I can think of why they got rid of it is that it caused difficulties for floppy based booting/installation. Now that I think of that, I believe Vista (NT 6.0) was also the first version which could not boot from floppies at all.
Windows FLP was an XP-based build with a Vista-esque installer: WIM images and a graphical installer. That’s about 2005.
Is the GUI installer 16-bit win3.x code or 32-bit NT 3.1 code?
IIRC the installer for Win95 ran in a minimal Win3.x-ish environment.
Once NT were ported to other architecture the installer couldn’t reuse existing Win3.1 and dos and still beeing platform independent. Therefore I think it’s no surprise that the got rid of that specific gui installer.
The installer is all 32-bit. In fact I don’t think there’s NTVDM at all!
That said, for portability reasons, it’s quite possible that Microsoft did not want to rely on VGA-compatible hardware being always present.
Probably not related to this, but related to the buslogic/aha154x there used to install NT here, but can you give me a sample of scatter/gather code with 3 arguments (like uint32_t, void *, int or size_t) for read/write access in emulation please? The one in VBox GPL seems too tighted to the kernel drivers.
Also, how does VBox get the phase bus stuff right for the buslogic/aha154x implementation?
Thanks 🙂
I’m afraid I don’t understand either question. I also don’t know what “tighted” means.
If you’re asking about SCSI bus phases then VirtualBox does not care about that at all, it works on the SCSI command level, not SCSI bus level.
Ok thanks for the clarification.
Also, a thing that bothered me in my implementation of the aha154x (not buslogic though) for another emulator, the doc I have doesn’t mention where it does fetch/store the CDB. I know it is contained in the CCB + ID and LUN.
Is ye olde paranoide processor-detection code already present in the October 1991 builds?
No, it’s not. I’m not sure when they added it, but in Oct ’91 they most likely wouldn’t detect anything beyond the 486 I think.
One more question – at what point did the NT 3.1 betas switch from the full graphical installer to the one with the text-mode early setup?
I think only the 1991 pre-releases (Oct/Dec) had a graphical installer. The 1992 stuff looked much more like the released NT 3.1.
Ah, OK, thanx! 🙂
One more thing – what’s the name of the file that needs to be run to start the GUI installer? I’ve managed to get ahold of an ISO of the NT-10-91 installation media (thank you WinWorld!); I was able to successfully find and run the command-line installer, but as for the graphical installer, I can’t seem to find the blasted thing…
OK, disregard my previous message; I found out that running the GUI install requires first building a boot floppy using MAKEDISK.BAT, which I successfully managed to do. When I boot from the floppy onto the CD installer, however, it crashes in precisely the manner that you describe happening in instances where the C: drive isn’t already FAT-formatted. Except that the C: drive in this VM is FAT-formatted.
Configuration is a VM with the OS type set to Windows NT 4, with three storage controllers: a floppy controller with dual floppy drives (A: and B:), an IDE controller with a 500-MB virtual disk (C:) as the primary master and an optical drive (E:) as the primary slave, and a BusLogic SCSI controller with a 1-GB virtual disk (D:) on port 0 and an optical drive (don’t know the drive letter yet, since I haven’t managed to get NT-10-91 actually running yet and MSCDEX apparently can’t handle SCSI optical drives) on port 2. Currently, the boot floppy image created using MAKEDISK.BAT is in the A: drive and the installation ISO is in the SCSI optical drive. Both drives C: and D: are formatted as FAT (I first installed MS-DOS 6.22 on the C: drive, installed MSCDEX to get optical-drive support, inserted the NT-10-91 ISO in the E: drive and a blank floppy image in the A: drive, reformatted the A: image to get rid of any preexisting data, used MAKEDISK.BAT to make the A: image into the NT bootdisk, then ejected everything, inserted MS-DOS 6.22 setup floppy 1 into drive A:, and reformatted both the C: and D: drives before re-ejecting the MS-DOS floppy, inserting the NT bootdisk into drive A: and the installation ISO into the SCSI optical drive, and pressing “Start”).
When I boot from the MAKEDISK-generated floppy and select the SCSI port that has the optical drive with the installation ISO inserted, it immediately runs into a loop consisting of many, many repetitions of
“*** KeBugCheck( 0xF0000006 )
”
before crashing the VM itself (“crashing” as in “meditating holy man”) within a second or two.
Any ideas?
A few more things:
1. By turning video capture on and then watching the resulting video file, I was able to determine that it bluescreened and entered the bugcheck loop immediately after loading the file “scsi(0)cdrom(2)fdisk(0)\i386\nt\Driver\scsidisk.sys” from the installation ISO.
2. I tried tweaking various settings to see if anything helped; the only settings changes that did anything noticeable were
a) switching the chipset from PIIX3 to ICH9 (caused the system to pause immediately after entering the bluescreen and displaying the “Windows 32-bit Development Kit blah blah blah et cetera et cetera” lines of text at the top of said bluescreen, never actually starting the bugcheck loop);
b) turning on VT-x/AMD-V (caused the screen output to change to a garbled mess of black, grey, red, and pink special characters partway through the bugcheck loop rather than staying blue and texty, although the VM still crashed).
Let’s clear one misconception: MSCDEX does not handle SCSI optical drives. It doesn’t handle IDE/ATAPI or any other kind of optical drives either. MSCDEX talks to a low-level driver which provides a hardware-specific interface (SCSI, ATAPI, AHCI, old Sony/Panasonic/Mitsumi or whatever). MSCDEX implements the High Sierra/ISO 9660 filesystem, a DOS drive redirector, plus a number of audio CD related services, but does not directly touch any hardware. The BusLogic CD-ROM driver for use with MSCDEX is actually a set of two, BTDOSM.SYS and BTCDROM.SYS. Commonly found on Windows 98 SE bootable CDs, for example.
Here’s what works for me: A VM with 32 MB RAM; 500MB IDE hard disk, cleanly formatted by a DOS 5.0/6.x setup disk; BusLogic SCSI with CD-ROM on port 2; and 2 serial ports.
The scsidisk.sys driver is the last one loaded before starting the NT kernel, so unfortunately saying that the system crashes right after loading that driver doesn’t say much.
Very good to know:
All manufactureres of IDE/ATAPI CD’s made their own drivers which technically are compatible with each other, but in practise use their own CD-ROM-readers as a dongle for the drivers.
Compaq got fed up with this, and made a CPQIDECD.SYS that works with (almost?) every IDE/ATAPI CD/DVD ever made.
Put that driver on your DOS boot disks, instead of for example the enormous amount of drivers that some Win 9x boot disks ship with or instead of searching for the correct driver.
But of course as Michael already said, for the SCSI controller you need some controller specific drivers.
@Michal Necasek: Ah, got it – the driver I’m using must not have SCSI support.
Also, I set the settings to the same ones you listed off… and the VM still crashed, in exactly the same way as before. Could I possibly have a bad ISO?
Bad ISO is possible but that might not really be the case. This is very pre-release code and does not handle error conditions very well. So if anything unexpected happens, it’s likely to just crash.
@Michal Necasek: Any idea what sort of errors might be causing this?
Sorry, might be causing what exactly? I don’t see any reference to specific errors.
Thanks to Michal Necasek for another great article in computing history!
@Yuhong Bao says:
““Yes, NT was bloatware, requiring much more RAM than its closest competitor, OS/2.”
I think even MS never intended “NT OS/2” to replace OS/2 2.x at least initially.”
Yes, and no. It was probably not intended to compete with with OS/2 2.x, but to be the next big future release to replace it as OS/2 3.x.
I also think we have to give them some slack with the first versions. It usually takes a couple of version for most completely new software packages to get fully optimized.
It was much better performing already with the next version 3.5, and with the 3.51 release it was working well for me with only 8MB RAM on a 486DX2-66.
I never used IBM’s Power PC version of OS/2, but from what I have heard from people trying out the betas of it, it was actually more “bloatware” and less performing that NT 3.1 in it’s pre release versions.
I never used Win95 much (used OS/2 2.11, Warp 3, FreeBSD and different versions of NT), but from what I understand it maybe needed a little less memory than OS/2 Warp. NT in turn (for me) needed a little bit more memory than OS/2 (even in NT’s later more optimized 3.51 and 4.0 versions).
All needed more memory than DOS/Win 3.1x.
So compared to that OS combination you could probably call all other OSes “bloated”, including W95, OS/2, NT, *BSD, Linux, Solaris and NextStep.
For me (with at the time my 486 with 8MB) it was performing absolutely fine when it got to be NT 3.51 and forward. No complaint at all for all my general computing usage and needs (games was another matter not fully solved until later versions of NT4/2000).
It looks like the 1991 beta implementation had the Adaptec 154x driver linked into NTLDR. I imagine that SETUPLDR could in theory load arbitrary SCSI drivers the same way NTLDR does using NTBOOTDD.SYS then boot NT off the CD-ROM.
I assume it was a purely practical decision; there were not that many SCSI HBAs on the market, the 154x was widespread, and the 1991 pre-releases were not exactly meant for wide consumption. The 154x was one of the very few SCSI HBAs available when the NT development started (the WD7000-ASC might have been another).
It looks like NT 3.1 used SETUPAPP.EXE which ran directly from SETUPLDR. NT 3.5 used SETUPDD.SYS which ran after the NT kernel was booted from the second disk. The last version of NT that was shipped on floppies was NT 3.51.
For whoever having problems installing Oct91 NT using WinWorld’s ISO, don’t try it. That ISO doesn’t work on emulators. You need another ISO. Check the NT 3.1 Beta page on old-dos.ru for an ISO that will work.
Did you see that an earlier Sep ’91 build (build 196) surfaced in December?
https://archive.org/details/windows-nt-3.1-pdk-1.196-sept.-1991
I did, and I had a look at it, although it took me a while to get anything going since it’s clearly a very alpha build.