Windows NT 3.1 build 196

1.196

Build of Windows NT 3.1
Desktop with Program Manager
OS family	Windows NT
Version number	3.0
Build number	196
Architecture	x86
Compiled on	1991-09-17
About dialog

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. 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. They later obtained the disc in December 2020 and uploaded its contents onto the Internet Archive.

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

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

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

On compatible video cards 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

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

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

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

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

Bootloader

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.

• 

  Dual boot with OS/2

• 

  Dual boot with MS-DOS

• 

  OS2LDR.NT patched to display image info

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 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

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

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

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

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

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

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.

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:

• 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.

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

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

Expand

The README's contents:

Installation notes for ePDK (1.196)
-----------------------------------

This is an experimental build that can be used to see Windows NT as it
exists today. The system and development tools can be used to port your
existing Win 3.x applications to Win32. It is possible to edit, compile and
debug Win32 apps using self-hosted tools on Windows NT itself.

New Features Compared to Previous Builds
----------------------------------------

Security is enabled.  Logon as "SYSTEM", there is no password, for admin
level access to your computer.

Information for setting up NT as a workstation or server is discussed later
in this README file.

Program Manager is started and default groups are provided.

DOS and OS/2 dualboot installation support for NT

CTRL-ALT-DEL now supported (flushes disk cashes and notifies device
drivers before reboot).

Performance has improved especially when starting larger applications
such as the File Manager.

Wave form files are provided for systems equipped with a SoundBlaster
card.  Use the playsnd.exe applet to play wave forms on this
device.

Online help is provided for the command utilities such as xcopy,
attrib, mkdir, etc.  There is general help and help for specific
utilities

General Limitations
-------------------

The system is beta quality. NT employs disk caching which has been used
internally by the NT development group for many months.  However, since
this is a beta release, it is recommended that NT be installed on a test
machine (not a primary work machine).

The system only supports running Win32 apps (no DOS or Win 3.x apps). Later
releases will add DOS and Win 3.x support.  Additional limitations
listed below are temporary with full Windows NT being included in
subsequent releases.

There is not a final doc set available on all of the utilities, but sample
make files should be useful for getting started developing Win32 apps.

No support exists in the current system for floating point.  This support
will be added in the next several builds.

The debugger is NTSD and supports assembly and rudimentary C source code
debugging.

A separate debugging system is REQUIRED to communicate with the NT kernel
debugger to continue past exceptions, RIPs as well as to reboot the system.

Only the netbuei transport and the EtherLinkII network card is currently
supported.  The XNS support is present but has not been fully tested.

Unique Build Limitations
------------------------

Internal support for UB network controllers exists, but is not
being distributed until functionality is tested.

Logoff/Logon: Logging off and relogging on without rebooting is not
currently supported.  In the future, currently executing programs will
be automatically closed (with appropriate user input) when logoff
occurs.  Logging on with another account will provide user-specific
Program Manager groups, file permissions and other user-defined settings
(colors, network reconnections, etc.).

System Requirements
-------------------

NT does not currently support installation from floppy.  It is necessary
to pre-install MS-DOS (3.1 or later) or OS/2 1.21 or 1.3 before running
the NT setup program.

The boot partition (C:) must be FAT, but other partitions may be HPFS
and will be accessible from NT.

When installing on MS-DOS using SETUP.BAT, a DOS/NT dualboot system will be
created. Once installed, you will be prompted at boot time which system to
execute. The default time-out selects DOS.

When installing on OS/2 using SETUP.CMD, an OS2/NT dualboot system will be
created. Once installed, you will be prompted at boot time which system to
execute. The default time-out selects OS/2. This dualboot is not compatible
with the OS/2 1.21 dualboot implementation. Multiboot of OS/2, DOS and NT will
be supported later.

Do not run the setup procedures if you boot from a floppy. The setup procedures
(SETUP.BAT or SETUP.CMD) are run depending on the system booted (DOS or OS/2)
and always modify the boot info and loaders on C:, not the boot device.

Hardware Requirements
---------------------

Currently, Compaq hardware is primarily used to test NT.  Only Compaq
386 and 486 systems are supported.  386SX should work.	MCA (e.g. PS/2)
are not currently supported.  When MIPS systems become available, NT
versions for MIPS will be provided.  There is no support in the current
release for MIPS.

10M RAM minimum is needed to boot and run Win32 programs.  This will be
reduced to 6-8M RAM in later releases.

The NT system requries 12M for system files and 10M for a paging file.

If doing Win32 development, an additional 10M is needed for development
files.

Setting up Windows NT on a Network
----------------------------------

Windows NT's network support is currently limited to the Netbeui protocol
running over a 3Com EtherLink II card.	The following information is
temporary and will not apply in later Windows NT releases.

If your NT machine will not be on a network, log on using username SYSTEM
with no password.  You can make SYSTEM the default logon username by changing
the DefaultLogonUsername entry in the [Console] section of NTUSER.CFG.

For network use, you will need to edit the three configuration files in C:\NT
to specify your machine name, username, domain, and optionally a server to
confirm logons. Use your favorite editor's search and replace.

Edit C:\NT\MSV1_0.CFG to add your username to the local security system.
Replace MYUSERNAME with your username.

Edit C:\NT\NT.CFG to specify your domain name.	Replace MYDOMAIN with the
name of your domain.

Edit C:\NT\NTUSER.CFG to specify your machine name, your username, and your
optionally password server.  Replace each occurance of MYUSERNAME with your
username, and each occurance of MYMACHINENAME with the network name of your
machine.  If you want a network server to confirm the  username and password
at logon time, replace MYPASSWORDSERVER with the network name of the server
that will confirm logons.  Also uncomment the PasswordServer line near the
end of NTUSER.CFG.

Reboot your machine and logon with your network username and password.	You
should be able to connect to any network resource on servers running the
Netbeui protocol. NET USE and NET VIEW are both working.

Windows NT can run as a share-level server.  To enable the server, set up the
sharepoints in NTUSER.CFG.  The default NTUSER.CFG shares C:\PUBLIC as
PUBLIC.  To start the server, type NET START SERVER.  BEWARE:  There is
no security implemented for the server.  Every client has full access to each
share.

Currently you must be logged on as SYSTEM in order to change the system time
or run file system utilities FORMAT, CHKDSK, and RECOVER.
system utilities FORMAT, CHKDSK, and RECOVER.

Gallery

• 

  First stage boot screen

• 

  Second stage boot screen

• 

  Login screen

• 

  Empty desktop

Applications

System applications

• 

  Program Manager

• 

  File Manager

• 

  Control Panel

• 

  Command Prompt

• 

  Print Manager

• 

  Clipboard Viewer

• 

  Notepad

Accessories and games

• 

  Calendar

• 

  Clock

• 

  WinMine

• 

  Solitaire

SDK tools and samples

• 

  Dialog Editor

• 

  Image Editor

• 

  Mltithrd

• 

  Simple

• 

  WINBez

• 

  Performance Meter

• 

  PlaySnd

Media

• 

  x86 English CD