Windows NT 3.1

Windows NT 3.1x is the first release of Microsoft's Windows NT line of server and business desktop operating systems, and was released to manufacturing on July 27, 1993. The version number was chosen to match the one of Windows 3.1, the then-latest operating environment from Microsoft, on account of the similar visual appearance of the user interface. Two editions of NT 3.1 were made available, Windows NT 3.1 and Windows NT Advanced Server. It was succeeded by Windows 3.5 in September 1994.

It could run on Intel x86, DEC Alpha, and MIPS R4000 CPUs.

The basic OS kernel introduced in NT 3.1 remains in use today for the 32-bit version of Windows 7 and (in an extended form) the 64-bit version, as well as the NTFS file system.

Development
Development of Windows NT started in November 1988, after Microsoft hired a group of developers from Digital Equipment Corporation led by Dave Cutler. Many elements of the design reflect earlier DEC experience with VMS and RSX-11. The operating system was designed to run on multiple instruction set architectures and multiple hardware platforms within each architecture. The platform dependencies are largely hidden from the rest of the system by a kernel mode module called the HAL.Windows NT was originally intended to be OS/2 3.0, the third version of the operating system developed jointly by Microsoft and IBM. When Windows 3.0 was released in May 1990, it was so successful that Microsoft decided to change the primary application programming interface for the still-unreleased NT OS/2 (as it was then known) from an extended OS/2 API to an extended Windows API. This decision caused tension between Microsoft and IBM, and the collaboration ultimately fell apart. IBM continued OS/2 development alone, while Microsoft continued work on the newly-renamed Windows NT.

The first public demonstration of Windows NT, at the time called "Windows Advanced Server for LAN Manager", was at a developer conference in August 1991, and the product was formally announced at the Spring 1993 COMDEX in Atlanta, Georgia.

Application programming interfaces in Windows NT are implemented as subsystems atop the undocumented Native API; it was this that allowed the late adoption of the Windows API. Windows NT was the first operating system by Microsoft to use UCS-2 internally. Windows NT introduced the Win32 API, a 32-bit implementation of the 16-bit Windows API. Most 16-bit Windows applications could be ported to the new system with minimal changes and a recompile. Win32 also provided native API support for many new features, such as networking and multithreading.

The project had a codename of just "NTOS", which is preserved in the filename of the Windows NT kernel, ntoskrnl.exe. Since it was targeted to become the next version of OS/2, a more official name of the project was "NT OS/2". This name is preserved up to now in some Windows NT driver development kit files.

System support
NT was designed from the ground up to be portable to other platforms. All kernel and subsystem code was written in C and C++. Any differences in core hardware architecture that could not be resolved by a simple recompile (e.g., memory architecture, multi/uniprocessor support) were offloaded to the HAL.

Also, NT's boot architecture borrowed heavily from the ARC initiative, particularly on non-x86 platforms.

i860
Originally, NT was targeted at the Intel i860 CPU, codenamed N10 (or "N-Ten"). However, the i860 was "horribly behind schedule", so the NT team used an emulator before i860 prototype systems designed in-house (code-named Dazzle) were available. Support for the other platforms followed later and no public release of NT for i860 systems was made. The rationale for targeting the i860 first was to improve portability and avoid producing an x86-centric design.

x86
NT 3.1 supported the Intel x86 32-bit family (80386 and later). Compared to 16-bit Windows 3.x, NT's driver support was somewhat limited. While Windows 9x could use Windows 3.x drivers, NT could use neither 9x or 3.x ones. Windows NT 3.1 is the only version of Windows NT that supports multiprocessor 386-based machines.

MIPS
Windows NT also supported the MIPS R4000 processor; specifically MIPS systems following the Advanced RISC Computing (ARC) specification.

Alpha
Early in the NT beta cycle, support was added for the DEC Alpha processor. However, because the Alpha itself was delayed, Microsoft's developers did not have access to production Alpha machines to develop on until shortly before NT shipped. Consequently, NT did not initially ship with Alpha support out of the box: the first packages of NT included a mail-in coupon to receive a free CD of NT 3.1 with Alpha support.

16-bit Windows
NT introduced the so-called NTVDM, an environment for running 16-bit applications. It provides an emulation of the Windows 3.x OS subsystem running in standard (286) mode. Apps that rely on low-level hardware access will not run, and they also may not use the Windows swap file. Microsoft stated that NT was compatible with all 16-bit applications that followed their official programming guidelines (generally not a problem with commercial software titles).

In NT 3.1, all 16-bit applications ran within a single WOW process. This meant that a single badly behaving 16-bit application could shut down the WOW session (and any other 16-bit applications running). However, the operating system itself was insulated, so the WOW process could simply be killed and restarted &mdash; a significant step forward for Windows' stability.

DOS was replaced in NT by a command prompt system known as CMD.EXE, which would generally run anything that did not attempt low-level hardware access (which however was very common in DOS programming and rendered many things unusable). It used the CPU's virtual 8086 mode just like Windows 3.x and Windows 9x for running DOS applications.

The NTVDM/WOW environment remained mostly unchanged in all 32-bit versions of Windows NT. It was removed from 64-bit versions of Windows because the CPU does not support 16-bit operations or virtual 8086 in long mode.

Windows 95 introduced long file names (which were not a feature of NT until version 4.0), but 16-bit applications cannot use them. Moreover, in 95 and up, they also use the old-style Windows 3.x Load/Save File menu box.

32-bit Windows
NT also introduced Win32, a 32-bit implementation of the Windows API. This permitted many 16-bit Windows applications to be recompiled for the system with minimal changes. Win32 also allowed the growing body of 16-bit Windows programmers to leverage their skills on the new system. The Win32 API was maintained (with some modifications) with Windows 95, further solidifying its role as Microsoft transitioned users off of the 16-bit platform.

Win32 is a comprehensive API, offering OS services ranging from memory management to UI access. NT prevents all user-level applications from directly accessing hardware. This increases system reliability, at the cost of performance. However, this also means that virtually all Win32 applications relied exclusively on the C/C++ Win32 API; the upshot is that porting such an application to another NT-supported system architecture (e.g., moving from x86 NT to MIPS NT) usually required no more than a recompile (some applications might require minor tweaking, such as if assumptions were made in code about endianness).

OS/2
Though "NT OS/2" was finally released as "Windows NT", it is largely compatible with HPFS disk volumes and the x86 version supports character-mode 16-bit OS/2 applications. Many of the OS/2 APIs (particularly NetBIOS/LANMan networking APIs) already existed in almost identical forms in both 16-bit OS/2 and DOS/Windows, so these were incorporated into the Win32 API. For most 16-bit OS/2 programs, minimal code changes were necessary to recompile as NT console applications.

OS/2 and Windows also share the concept of Dynamic-Link Libraries (DLLs). Although the implementation varies somewhat between Windows and OS/2 DLLs, this additional similarity meant that even complex OS/2 applications could usually be converted to NT with little change to the overall design.

Available separately from Microsoft is the Windows NT Add-On Subsystem for Presentation Manager, which also allowed graphical OS/2 applications to run.

POSIX
Windows NT 3.1 included a subsystem that was minimally POSIX-compatible. This was added largely to help spur sales in US government contracts, as many government agencies mandated POSIX compatibility for consideration.

Note that POSIX compatibility is an API-level requirement. That is, one POSIX operating system won't necessarily be able to execute binary files compiled for a different system, even though both are POSIX compliant. POSIX simply specifies that the source code should compile correctly for each system.

The POSIX subsystem in NT 3.1 primarily provided support for UNIX-style file system permissions and long filenames (including permitting filename characters that are otherwise illegal for Windows files, and denying some that are normally legal).

Internet Explorer
Microsoft offered Internet Explorer 2. Also, a IE 1.5 supported NT, but this patch was actually released after IE2 came out.

Editions

 * Windows NT 3.1 Workstation
 * Windows NT 3.1 Advanced Server
 * Windows NT 3.1J (Support for Japanese language)
 * Windows NT for Workgroups 3.1

Networking
NT 3.1 included support for three network protocols: NBF (using the NetBEUI API), TCP/IP, and DLC.

NetBIOS Frames protocol
At the time of NT's release, NetBIOS Frames protocol (NBF) was the most common protocol on Microsoft LAN Manager/IBM LAN Server networks. In NT 3.1, it was the only supported protocol for networking with legacy LAN Manager networks, as well as other NT systems. Using NBF, NT could participate in file/print sharing, and NT Advanced Server could act as a Domain Controller (even sharing DC duties with OS/2 LAN Manager servers). NT Advanced Server could also join an existing domain, but it could not function as a stand-alone (Workgroup) Server.

TCP/IP
Windows NT 3.1 was the first Windows operating system to include TCP/IP support as standard. The TCP/IP stack used was SpiderTCP, developed by Spider Systems. This was replaced in NT 3.5 with a new stack developed in-house.

The TCP/IP stack included WinSock and STREAMS support, but it was not supported for networking among Microsoft LAN Manager or NT systems. Also, DHCP was not available, so IP addresses had to be manually configured. Support for NBT, DHCP, and WINS was added in Windows 3.5.

Data Link Control
Data Link Control (DLC) was supported as a transport protocol for the purpose of communicating with network printers, such as those using an HP JetDirect interface. It could also be used by Microsoft SNA Server for communication with IBM mainframe systems.