Windows NT 3.1 build 196

1.196
Build of Windows NT 3.1
Screenshot
Desktop with Program Manager
OS familyWindows NT
Version number3.0
Build number196
Architecturex86
Compiled on1991-09-17
About dialog
1.196.1 Winver.png
TCB.png TCBGallery.png

Windows NT 3.1 build 196 is an early build of Windows NT 3.1, which was compiled and sent out to a limited number of developers in mid-September 1991 as a part of a trial that took place prior to the release of the Fall COMDEX 1991 build.[1] Compared to the COMDEX build, this build is noticeably less stable and tends to hang even during common tasks such as opening new windows. Many of the hangs are caused by the system breaking to the debugger following an unsatisfied assertion condition. It is also sensitive to fragmentation of its boot files, with the system freezing on boot if the boot loader is not stored contiguously.

This build has several differences compared to later builds, such as an older bootloader with a primitive dual boot menu which supports either an MS-DOS or OS/2 install on the same disk as NT, a primitive version of the Portable Executable format, or the lack of a self-hosted installer. According to the documentation included with the build, this is also one of the first builds to implement security. The system already has a concept of privileged and non-privileged users, with privileged users being able to do tasks such as running CHKDSK, FORMAT, or RECOVER which require direct disk access. Curiously enough, the login screen includes a "Privileged" checkbox, although it does not appear to exhibit any noticeable change.

The build predates the introduction of the four-colored Windows flag logo and uses the large circular window graphic from Windows 3.1 builds 026 and 034f in its place. However, the disc print contains the same logo that is used by the About dialog in Windows 3.1 build 043d from August 1991, which suggests that the NT shell last integrated upstream changes in early summer. This build is also rather inconsistent with the rest of its branding, as it identifies as "NT 1.0" in configuration files, "NT 32-bit Windows" on the desktop watermark, "NT-386" while booting, "NT Windows" in the Print Manager, and "Windows NT Version 3.2" in the Command Prompt.

A picture of a disc containing this checked/debug build was first shown by BetaArchive member ReflectiaX in September 2018.[2] They later obtained the disc in December 2020 and uploaded its contents onto the Internet Archive.[3]

On README.TXT, there is a New Features Compared to Previous Builds section, suggesting that Microsoft likely released to developers at least one build of Windows NT prior to this build.

System requirements[edit | edit source]

According to README.TXT, this build requires:

  • A Compaq computer with an 80386 or 80486 processor.
    • MCA computers (such as IBM PS/2) are not yet supported.
  • At least 10MB of memory.
  • At least 12MB of free space.

Despite the official requirement of a Compaq computer, this build can be installed on any computer with an 80386 or 80486 processor. It is also possible that "Compaq" in this context meant "standard PC" based on the ISA, EISA or VLB buses, as opposed to the not-entirely-PC-compatible Micro Channel-based PS/2 (which is explicitly called out as unsupported), as at this time Compaq was generally considered to be the leader of the section of the PC industry opposed to IBM's attempt to seize back control of the industry using the PS/2.

Setup[edit | edit source]

This build does not include any setup utility, but instead relies on a batch file to copy system files to the hard disk and write the boot loader to the bootsector. The process requires a pre-installed copy of MS-DOS (version 3.1 or later) or OS/2 1.21 or 1.3. The boot partition on which DOS or OS/2 is installed must be a FAT partition on an ATA/IDE hard disk, while any additional partitions can also be HPFS and on SCSI disks. For both DOS and OS/2, CHKDSK.EXE should be in a directory that's listed in the %PATH% variable. For DOS, DEBUG.EXE must also be accessible through %PATH%, as it is used to install the boot loader.

The disc contains SETUP.BAT file designed for installing next to MS-DOS 3.1 or later, and SETUP.CMD designed for installing next to OS/2 1.2 and 1.3. The installation is initiated by changing to the CD drive and typing setup i386 in a command prompt. Adding mstools to the command will also install the developer tools. Under OS/2, the setup also accepts the newdbg parameter to install a new OS/2 based debugger and the corresponding kernel, however, it has no effect in this build.

Upon installing this build, the setup also runs CHKDSK to check if the boot files have been stored in contiguous blocks. If they are not, it is required to defragment the boot drive in order to boot to NT.

Super VGA support[edit | edit source]

On compatible video cards[a] it is possible to achieve 800x600 resolution with 16 colors by replacing the default VGA.DLL driver in C:\NT\DLL with VGA800.dll found in the same directory and rebooting. The driver appears to use a non-standard way to switch to the resolution by directly setting the video card registers, which has been confirmed to work with multiple emulators, however, it is currently unknown whether it is functional on real hardware or which cards are supported. VirtualBox (and presumably other hypervisors as well) is not compatible with the driver and the mentioned file replacement will result in corrupted screen output after boot.

Sound[edit | edit source]

This build includes a Sound Blaster driver (SOUND.SYS), together with sample wave files to play. It expects a Sound Blaster 1.0 or 1.5 (with DSP version equal to 2.0) on I/O port 0x260 (hardcoded in kernel) and IRQ 7 (hardcoded in the driver). Card parameters would not be configurable until build 297.1.

Network[edit | edit source]

The kernel attempts to load a variety of network card drivers, although only one is actually included: ELNKII.SYS for the 3Com EtherLink II and only supports the NetBEUI protocol. According to the README, Xerox Network Systems (XNS) support has been implemented, although not officially tested by Microsoft.

Applications[edit | edit source]

Compared to the October 1991 build, this build lacks several of the standard utilities and accessories typically included with classic Windows at the time. Program Manager, File Manager, Control Panel, Clipboard Viewer, Notepad, Calendar, Clock, Reversi, Solitaire and Minesweeper are included. These applications appear functionally close to their Windows 3.0, or contemporary Windows 3.1 pre-release versions. This suggests they were not kept up-to-date with the Windows 3.1 source tree consistently. Additionally, a Windows NT-specific Command Prompt (CMD.EXE) is also included, which is based on its OS/2 counterpart.

The developer tools of this build include several demo applications, many of which have been taken from the Windows 3.0 SDK. Unlike later builds, there are no binaries provided, and therefore it is required to build them first by launching the Win32Dev shortcut, changing to C:\NT\MSTOOLS\SAMPLES and running MAKEALL.CMD. After the build process, a compiled executable should be present in each of the subdirectories.

Noteworthy applications include:

  • Print Manager, which has been rebuilt from scratch for NT, intended to replace both the original Print Manager and the Printers control panel from Windows 3.x. This version calls itself "NT Print Manager" in the title bar and uses the Print Manager icon from Windows 3.0.
  • WINBez, which demonstrates the graphic abilities of NT. Compared to the version found in the October build, it is more primitive and calls itself "Kent's Window Test Application" in the about box.
  • Performance Meter. Has no visible differences from the October build, although strangely enough, the version in this build reports itself as 1.1, whereas the one found in the October build reports as 0.5.
  • PlaySnd, which tests the sound capabilities of the operating system. This application is similar to PlayIt found in the October 1991 build.
  • Mltithrd shows off the ability to execute multiple threads within the same process at the same time. This is more or less the same as the version found in the October 1991 build.
  • Simple, which merely prints out "Win32, it's happenin'!" to the console when executed.

Architectural differences[edit | edit source]

This build has several interesting architectural differences from most later builds of Windows NT.

Bootloader[edit | edit source]

This build uses an older bootloader, which is noticeably more primitive than NTLDR introduced in later builds. Notably, it requires all of its stages to be stored contiguously, otherwise the system will hang at boot. The boot sector appears to be taken from OS/2 and loads OS2LDR, which by default contains a rudimentary dual boot menu. This build supports dual boot with either OS/2 1.2-1.3 or MS-DOS, the latter of which appears to be introduced shortly before the release of this build. The loader makes no attempt to detect the other operating system, instead relying on the Setup to install the correct loader variant: the DOS-based setup copies OS2LDR.DOS, while the OS/2-based setup copies OS2LDR.DUL instead. When dual booting, the OS/2 variant merely chainloads the original OS2LDR (now renamed to OS2LDR.OS2), while the DOS variant replicates the behavior of the DOS boot sector.

The actual NT loader is stored in OS2LDR.NT, which brings up a 80x50 text mode screen with black text on a gray background, prints out version information and displays a progress bar made out of dots as it is loading the kernel. The bootloader identifies itself during this stage as "PDK Bootloader v1.9" with a 1990 copyright date, with strange spacing around the "PDK" part that suggests this string might have been hastily edited before release. Upon loading the kernel, it carries out basic checks to ensure that the kernel is for the correct architecture, and also attempts to load a kernel debugger and symbols. Afterwards, it blanks the screen and prints a row of equals signs in the bottom of the screen before jumping to the kernel entry point.

It is possible to remove the dual boot menu by renaming OS2LDR.NT to OS2LDR, which will make the system boot straight to NT at all times.

Directory layout[edit | edit source]

Unlike later builds, which have adopted the Windows 3.0 directory layout with minor adjustments, this build uses a layout more similar to Unix or OS/2 with separated binary, library and data folders. The setup copies the kernel to the root of the disk and the rest of the operating system to the C:\NT directory. The boot loader is hardcoded to look for the kernel in the root directory of the system disk and likewise the kernel assumes the system is installed in the NT directory.

  • C:\ - Root of the system disk. Contains the boot loader and the kernel image
    • C:\NT - Configuration files, localization data, page file and readme
      • C:\NT\BIN - Non-GUI executables
      • C:\NT\DRIVERS - Kernel drivers
      • C:\NT\DLL - Libraries
      • C:\NT\MSTOOLS - Development kit (if installed)
      • C:\NT\TMP - Temporary files (gets created at runtime)
      • C:\NT\WAV - System sounds
      • C:\NT\WINDOWS - Windows GUI executables, configuration and data
        • C:\NT\WINDOWS\FONTS - Fonts
        • C:\NT\WINDOWS\SYSTEM - Empty by default; exists presumably for compatibility purposes
        • C:\NT\WINDOWS\WINSPOOL - Printer configuration and drivers
    • C:\REGISTRY - Created at runtime; exact usage unknown as of now

Executable format[edit | edit source]

This build uses an even earlier version of the Portable Executable format than the October 1991 build, resulting in executables built for this build of Windows NT completely failing to start on newer builds of the OS; this also results in disassembly tools such as IDA Pro failing to disassemble the file without a custom loader, making analysis significantly more difficult.

Subsystem numbers are different between the early and final versions:

ID Subsystem
0 Unknown
1 OS/2
2 Windows
3 Undefined
4 Native
5 POSIX

Windows GUI and console applications use the same subsystem number. The distinction between the two is instead made in the module flags field.

Kernel and drivers are pure COFF executables similar to the October 1991 build.

Configuration[edit | edit source]

The registry does not exist yet at this point. The system is configured using the NT.CFG, NTUSER.CFG and MSV1_0.CFG configuration files stored in C:\NT, and WIN.INI in C:\NT\WINDOWS. A directory tree reminiscent of the registry structure is also created in C:\REGISTRY upon first launch, however, no files are stored in there, therefore its purpose is currently unclear. It seems this may be used to store security-related data when a domain is set up.

Static linking[edit | edit source]

Many components that would later be individual binaries are statically linked into the kernel image in this build. This includes the HAL, several boot-critical drivers, including the ATA/IDE hard disk driver (ATDISK.SYS) and the FAT16 filesystem support code, and a rudimentary version of NTVDM that only supports real-mode DOS apps.

The Service Control Manager is statically linked into each service executable rather than being a standalone executable file as it is in most later builds.

Kernel[edit | edit source]

This build lacks the blue screen of death; KeBugCheckEx is nonexistent in this build while KeBugCheck has a simplistic implementation that prints a string to an attached kernel debugger and then, in an infinite loop, causes a breakpoint. Without a debugger attached, this would be perceived as a hang, and nothing is shown on-screen to indicate that anything happened. It is possible that this is only a result of this being a debug build, while regular builds would have had a visible representation of a bug check.

NtCurrentTeb is an exported function in this build rather than a macro.

Security[edit | edit source]

The README implies that this was one of the earliest builds to have any semblance of user security implemented, and this is evident by the extremely rudimentary nature of the user account system. While privileged and nonprivileged users are implemented, they only affect changing the system time and usage of a few commands such as FORMAT, CHKDSK, and RECOVER, and the user can access an application by checking a checkbox in order to get administrative privileges. The README also advises that the user should log into the SYSTEM account — which has no password. Indeed, there are only four security-related exports in the kernel, compared to NT 3.1's eighteen.

User accounts and groups are stored in C:\NT\MSV1_0.CFG. An "Admin" account is predefined there, and logging in as "Workstation Manager" (hardcoded in MSV1_0.DLL) also works.

Subsystems[edit | edit source]

Session Manager command line

The only functional subsystem is the Windows subsystem, Win32Gui, which is defined in NT.CFG and is configured to launch on startup in NTUSER.CFG. Although Win32Char is also defined, it is presumably just a leftover from older builds with separate GUI and console subsystems, while they were already combined into a single subsystem as of this build. The build also includes the OS/2 subsystem (OS2SS.EXE) seemingly based on an early version of OS/2 2.0, however, it is incomplete and trying to launch any OS/2 applications using the OS2.EXE launcher breaks into the debugger, resulting in a system hang. NT.CFG also includes a subsystem entry for the POSIX subsystem, although its executables are not included.

If the Session Manager (SMSS.EXE) fails to load any subsystems automatically, it will drop to a rudimentary command-line interface accessible via a debugger, which supports process management, debugging user mode NT processes, managing environment variables, and probing system parameters. Without an attached debugger, this appears as a system hang as the only thing displayed is a blank gray screen with a blinking text mode cursor and a row of equal sign characters at the bottom. According to the NT Design Workbook, this command line interface only appears on debug builds, while regular builds would crash with a bug check.[4]

Windows subsystem[edit | edit source]

The Windows subsystem is laid out differently compared to later builds. Notably, each subset of the Windows API is implemented using its own pair of client and server DLLs:

  • BASE.DLL and BASESRV.DLL for the Base API (equivalent to KERNEL.EXE in 16-bit Windows)
  • CONSOLE.DLL and CONSRV.DLL for the Console API (newly introduced in Win32)
  • GDI.DLL and GDISRV.DLL for the Graphical Device Interface API
  • USER.DLL and USERSRV.DLL for the User API

32-bit Windows libraries also have not yet adopted the "32" suffix in their filenames to differentiate them from their 16-bit counterparts. Later on, the Base and Console clients would be combined to form KERNEL32.DLL, while the Console, GDI and User servers would be merged into a single Windows server (WINSRV.DLL).

On startup, CSRSS.EXE parses the values of several later deprecated command line arguments, including Windows, which when set to a value other than On skips some initialization procedures and which was likely used to prevent double initialization of the Windows API in a dual GUI/console subsystem setup. SubSystemType is used to determine the subsystem type to register with the Session Manager and is by default set to Windows, although it also accepts Posix, Os2, Native or a user specified integer. This is a leftover of the original design where CSRSS.EXE was intended to be a generic subsystem server, which would take on the personality specified on its command line.

This build also includes a second, unused set of console client/server DLLs, CCONSRV.DLL and CCONSOLE.DLL, which are presumably the leftovers of a text mode only Win32 subsystem. The text mode console server appears to be built from a different source tree directory and includes a console login prompt and a task manager, while the client is exactly the same as its normal counterpart except for the timestamp in the executable header and depends on functionality that is not present in CCONSRV.DLL, making it impossible to boot into a text mode Win32 environment. The console server also attempts to launch the Local Security Authority subsystem (LSASS.EXE) in its initialization code, which fails, as it is a Win32 console application in this build and the environment subsystem hasn't been fully initialized at this point of startup. It is likely that LSASS.EXE used to be a Native application in older builds, as further suggested by the NT Design Workbook.[5]

Bugs and quirks[edit | edit source]

This build is generally unstable and can easily hang on certain tasks. It can be as simple as launching an application, pressing certain keys on the keyboard such as function keys, or even leaving the system alone for a couple of seconds. The triggers for these hangs can vary significantly from one installation to the next, and at least some of them may be hardware-related. Using the debugger reveals a lot of the hangs are related to GDI and USER problems. In possible relation to this, fonts appear to be broken in this build, with many places using the System font in place of the expected Helv (Microsoft Sans Serif) font, such as the About dialogs and the File Manager.

Mouse and keyboard input are unreliable in this build, with reports of serial mice not working with some configurations and keyboard input having the tendency to randomly stop working until a reboot. It is recommended to use a PS/2 or bus mouse to prevent any issues. This build only supports PS/2 keyboard scan code set 3, which must also be supported by the hardware (real or emulated) to work properly, otherwise the keys are not mapped correctly and keyboard input becomes unpredictable as a result.

Additional minor bugs include:

  • CD-ROM drives do not appear in File Manager, however, they can be accessed from a command prompt.
  • Directories may incorrectly show up as empty or incomplete in the File Manager. The missing entries can be forced to appear by updating their last modification date.
  • The Select All keyboard shortcut (Ctrl+A) does not work in Notepad.
  • Creating a new file in Notepad may result in garbage being placed inside the new text file.

Documentation[edit | edit source]

A README.TXT document is included inside the installation contents, which contains information such as installation instructions, technical limitations and documentation on new features.

The README's contents:

Gallery[edit | edit source]

Applications[edit | edit source]

System applications[edit | edit source]

Accessories and games[edit | edit source]

SDK tools and samples[edit | edit source]

Media[edit | edit source]

Notes[edit | edit source]

  1. Confirmed to work on 86Box with most VGA compatible cards, as well as on QEMU with the -vga cirrus option.

References[edit | edit source]

  1. Pascal, Zachary G. Showstopper: The Breakneck Race to Create Windows NT and the Next Generation at Microsoft. 1994. New York: Free Press, Maxwell Macmillan International. ISBN 9780029356715.
  2. https://www.betaarchive.com/forum/viewtopic.php?t=38906
  3. https://archive.org/details/windows-nt-3.1-pdk-1.196-sept.-1991
  4. NT OS/2 System Startup Design Note, p. 1
  5. NT OS Base Product Content, p. 11