NT's operating system services are divided into a number of discrete units, or subsystems. NT uses these subsystems to run applications written for different operating systems. The NT executive's virtual memory system makes sure that each subsystem runs in its own area of memory. This is so that processes are not able to interfere with one another and if an application fails, it won't affect the rest of the system. Subsystems that provide Application Program Interface (API) services for application are called environmental subsystems. There is also another type of subsystem called an integral subsystem, which performs necessary operating system tasks. Much of NT's security system is implemented as an integral subsystem. The executive subsystem provides kernel mode operating system support. The environment subsystem handles application's other requests itself. Applications and subsystems have a client \ server relationship. The subsystems (servers) provide the API services that applications (clients) use. NT subsystems are processes created by NT as required - for example, NT starts the POSIX subsystem when you attempt to run a POSIX application. The client requests a service by sending a message to the server. In this case a client may be another operating system component or an application program. The most important NT environment subsystem is the Win32 subsystem. It is the link between the user and the rest of the operating system. The Win32 subsystem provides NT's user interface. It handles all user input and application output no matter which application is running. It also makes the 32bit API available to application programs. Applications written for NT or Windows 95 are called Win32 applications. NT's Win32 subsystem serves these applications directly. Win32 based applications, as their name suggests, use 32bit addressing. In a multi-threaded application the programmer has to make sure that the different threads do not interfere with each other when accessing the same system resources. Each Win32 application runs in its own address space. So Win32 applications can't corrupt each others memory. NT 4.0 includes both standalone and network versions of Object Linking and Embedding (OLE). With OLE you can combine information from several applications in one compound document. (COM) Component Object Model allows software components on a single computer to interact with each other. NT 4.0 introduces Distributed Component Object Model (DCOM), which enables software components to interact with each other across a network or even across the Internet. DCOM is effectively a network version of OLE. Some applications that have OLE capabilities are : Clipboard viewer, MSPaint, Sound Recorder and WordPad. NT Supports OpenGL (Graphics Language), an industry standard software interface for producing two and three dimensional graphics. OpenGL allows applications to create high-quality color graphics. OpenGL images are independent of the windowing systems, operating systems, and hardware that display them. NT requires the following Dynamic Link Libraries (DLL) to support OpenGL applications: OPENGL32.DLL and GLU32.DLL. These two files are automatically installed under C:\winnt\system32 during setup.

MS-DOS based applications run in special Win32 application called Virtual Dos Machine (VDM) The VDM provides a simulated MS-DOS environment. NT allows any number of MS-DOS applications to run simultaneously. Each VDM runs a single thread of execution. Some MS-DOS applications will try to access hardware devices directly, without going through the VxD layer. When this happens, you get an error message. If you are committed to using the problem application, you must either run it natively under MS-DOS or request that the application vender supply a VxD for NT. When VDM starts, the two VDM configuration files autoexec.NT and config.NT are executed. These two files are stored in the C:\winnt\system32 directory.

NT supports Windows 3.x (16bit) applications by creating a suitable operating environment for them within a VDM. This 16bit windows operating environment is called Windows on Win32 (WOW) The WOW environment is essentially a multithreaded VDM, where each thread executes a 16bit Windows Application. Like a VDM, the WOW environment is a 32 bit user mode application executed by NT. The WOW environment imitates the behavior of 16 bit windows, in which all applications are single threaded and reside within the same address space. The WOW environment translates 16-bit API calls into 32-bit calls By default, all 16bit windows applications run in the same VDM. The 32bit window manger and GDI code are responsible for translating 16 bit segmented addresses into 32bit flat addresses. When addresses have been translated the 32 bit window manager and GDI code call the Win32 API to carry out the operation. When the Win32 subsystem returns its results, it takes the 32bit addresses back to 16 bit segmented addresses and returns the results to the application. When a Win16 application is configured to run in its own memory space, a new VDM is created when the application starts. The default VDM and WOW environments always remain loaded, even if no Win16 applications are started. But when an application that runs in its own memory space is closed, the VDM and WOW environments that support it are also closed. You can pre-emptive multi-task Win16 applications if they are in separate memory spaces. For each Win16 application that is started in its own memory space another VDM and WOW environment are started, so there is additional memory overhead. Windows NT uses copies of the WIN.INI and SYSTEM.INI files to modify the WOW environment and store 16 bit application configuration information.

The OS/2 subsystem in NT supports OS/2 1.X character based applications only. You can get an add-on component from Microsoft that enables NT to run OS/2 Presentation Manager (GUI-based) applications. On RISC based computers there in no OS/2 subsystem. However it is still possible to run OS/2 applications on an NT based system using a RISC processor. The OS/2 subsystem consists of three components OS2SS.exe, OS2SRV.exe and OS2.exe. OS2SS.exe is the main component of the OS/2 subsystem. OS2SRV.EXE launches the OS/2 application that you want to run. OS2.exe is a Win32 program that passes the name of the OS/2 application and any command-line parameters to OS2SRV.exe. To conserve memory, the OS/2 subsystem loads only when an OS/2 application is run. You can use FORCEDOS.EXE to force a bound application to run in a VDM. OS/2 subsystem configuration information is stored in the Registry. You can configure a regular OS/2 subsystem just as you would configure a config.sys file. Configuration changes do not take effect until shut down and restart NT.

The POSIX subsystem in Windows NT enables you to run POSIX compliant applications. POSIX is an acronym created from the phrase "Portable Operating System Interface based on UniX". POSIX is an IEEE standard that specifies a common set of operating system services. Applications that adhere to the POSIX standard can easily be ported from one system to another. The NT POSIX subsystem is designed to meet the requirements of the IEEE standard 1003.1. Like the OS/2 subsystem, POSIX subsystem supports character-based applications. The POSIX subsystem also supports applications with multiple threads of execution. The POSIX subsystem only loads when you load a POSIX compliant application. POSIX.1 is a library of functions consisting mainly of system calls. NTFS (NT File System) supports POSIX.1 requirements, and such as is a POSIX.1 -compliant file system. Two of the features required by POSIX.1 that are fulfilled by the NTFS file system are: case sensitive naming - NTFS preserves case for directory names and files. & hard links - these enable a file to have more than one name. The POSIX subsystem consists of the following components. PSXSS.exe, POSIX.EXE, and PSXDLL.DLL. PSXSS is the main component of the POSIX subsystem. It is started when the first POSIX compliant application is loaded. There is never more than one instance of PSXSS.exe running at one time. POSIX.exe is an NT 32bit program that handles communication between the POSIX subsystem and Windows NT Executive Services. A copy of POSIX.exe is loaded for each POSIX -compliant application started.

All MS-DOS and Windows 3.x applications contain non-portable 80x86 machine instructions. Win32 and POSIX are portable application programming interfaces. Applications written to these Application Programming Interfaces are source compatible across all NT platforms. This means that a different executable file is required to run the application on each platform. To run programs in their own memory space you include the /separate switch with the start command. For instance: C:\>start /separate notepad there are a number of parameters you can use with the start command to prioritize applications: eg. /LOW /NORMAL /HIGH /REALTIME.

Win32 applications are source compatible and will run only on the platform for which they were complied. If you cannot run an application, it is possible that one or more NT subsystem files have become damaged or corrupt. If this is the case, you can use the Emergency Repair Disk to verify and correct the problem.

MS-DOS based applications will not run if on an NT system if they communicate directly with the hardware. Win16 applications will not run if they require a virtual device driver and Win32 applications are platform specific at the binary level. Also OS/2 and POSIX -compliant applications will not run if they make calls to unsupported