Windows NT 3.1 build 196

Windows NT 3.1 build 196 is the earliest publicly released build of Windows NT 3.1, which was compiled and sent out to a limited number of developers in mid-September 1991 as a trial before the Fall COMDEX 1991 build. Compared to the COMDEX build, this build is noticeably less stable and has the tendency 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 a MS-DOS or OS/2 install on the same disk as NT, an early 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  or , which require direct disk access. Curiously enough, the login screen includes a "Privileged" checkbox, however, it does not seem to do anything.

The build predates the introduction of the four-colored Windows flag logo and uses the large circular window graphic also used by Windows 3.1 build 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 branding, as it identifies as NT 1.0 in configuration files, "NT 32-bit Windows" on the desktop watermark, "NT-386" (with "NT-MIPS" likely being the MIPS equivalent) 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 build was first provided by BetaArchive member ReflectiaX in 2018. On 18 December 2020, he obtained the disc and proceeded to share its contents.

Setup
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. 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,  should be in a directory that's listed in the   variable. For DOS,  must also be accessible through , as it is used to install the boot loader.

The disc contains  file designed for installing next to MS-DOS 3.1 or later, and   designed for installing next to OS/2 1.2 and 1.3. The installation is initiated by changing to the CD drive and typing  in a command prompt. Adding  to the command will also install the developer tools. Under OS/2, the setup also accepts the  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  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
On compatible video cards it is possible to achieve 800x600 resolution with 16 colors by replacing the default  driver in   with   found in the same directory and rebooting. Based on references from newer builds, the 800x600 driver is primarily intended to work with Video 7 video cards, however, it has been found to work with other cards from the same era as well. On the other side, 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 reboot.

Sound
This build includes a Sound Blaster driver, 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
The kernel attempts to load a variety of network card drivers, although only one is actually included:  for the 3Com EtherLink II.

Applications
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, Windows 3.1 build 026, Windows 3.1 build 034f or Windows 3.1 build 043e 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 is also included, likely 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, they are no binaries provided, and therefore it is required to build them first by launching the Win32Dev shortcut, changing to  and running. 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
This build has several interesting architectural differences from most later builds of Windows NT.

Bootloader
This build uses an older bootloader from the NT OS/2 era of the NT project, which is noticeably more primitive than  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, 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, while the OS/2-based setup copies   instead. When dual booting, the OS/2 variant merely chainloads the original  (now renamed to  ), while the DOS variant replicates the behavior of the DOS boot sector.

The actual NT loader is stored in, 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  to , which will make the system boot straight to NT at all times.

Directory layout
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  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  directory.

PE Format
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.

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

Registry
The registry does not appear to exist yet at this point. The system is configured using the,   and   configuration files stored in  , and   in. A directory tree reminiscent of the registry structure is also created in  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
Many components that would later be individual binaries are statically linked into  in this build. This includes the HAL, several boot-critical drivers, including the ATA/IDE hard disk driver  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
This build lacks the blue screen of death;  is nonexistant in this build while   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. is an exported function rather than a macro.

Security
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 usage of a few commands, and you can simply check a checkbox in order to get administrative privileges. The README also advises you to log in as 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. An "Admin" account is predefined there, and logging in as "Workstation Manager" (hardcoded in ) also works.

Subsystems
The only functional subsystem is the Windows subsystem,, which is defined in   and is configured to launch on startup in. Although  is also defined, it is assumably a leftover from older builds with separate GUI and console subsystems, while they have already been combined into a single subsystem as of this build. The build also includes the OS/2 subsystem 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   launcher breaks into the debugger, resulting in a system hang. also includes a subsystem entry for the POSIX subsystem, although its executables are not included.

Windows subsystem
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: 32-bit Windows libraries also do not use 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, while the Console, GDI and User servers would be merged into a single Windows server.
 * and  for the Base API (equivalent to   in 16-bit Windows)
 * and  for the Console API (newly introduced in Win32)
 * and  for the Graphical Device Interface API
 * and  for the User API

On startup,  parses the values of several later deprecated command line arguments, including , which skips some initialization procedures and which was likely used to prevent double initialization of the Windows API in a dual GUI/console subsystem setup. is used to determine the subsystem type to register with the Session Manager and is by default set to, although it also accepts  ,  ,   or a user specified integer. This suggests that the CSR subsystem was initially 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,  and , which are assumably the remainders 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, making it impossible to boot into a text mode Win32 environment. The console server also attempts to launch  in its initialization code, which fails as it is a Win32 console application in this build, however, it may mean that the security subsystem could have earlier been implemented using the Native API.

Session Manager
If the Session Manager 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. From this point it is possible to continue system startup manually by initializing a subsystem server via a debugger.

Bugs and quirks
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.

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 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
A  document is included inside the installation contents, which contains information about certain things, such as how to install this build and new features compared to the previous build. The README's contents: