Windows NT protects all of its operating system code by locating it in either kernel mode (or Ring 0 of the Intel protection model) or in protected subsystems in user mode (or Ring 3), each of which runs in its own address space. Thus, all Windows NT operating system code and data are protected from applications.
Applications, which run in user mode, have access only to their own address spaces. To communicate with system services, an application must utilize specific application programming interfaces (APIs) to convert their threads from user to kernel mode. In order for the application to regain control of the threads, they must be converted back to user mode. Thus, applications have no access to the memory of the subsystems and cannot interfere with the operating system or its support of other applications.
For more information about kernel and user mode, see "Kernel Mode and User Mode" in Chapter 5, "Windows NT 4.0 Workstation Architecture."
Windows 95 locates most of its operating system components in kernel mode, but its system services DLLs (GDI, GDI32, KERNEL, KERNEL32, USER, USER32) run in user mode for the purposes of enhanced performance as well as for backward compatibility with MS-DOS and Windows 3.x applications and device driver software, etc. An ill-behaved application can gain access to and write to operating system memory and crash the system. For more information about Windows 95 architecture, see Windows 95 Resource Kit.
Both Windows 95 and Windows NT run Win16 and DOS applications along with the Win32 applications developed to run on Win32 operating systems. The two systems handle Win16 applications differently, and generally Windows NT is the recommended operating system for computers that run both types of applications.
Windows 95 uses cooperative multitasking with Win16 applications. Cooperative multitasking allows an application to voluntarily pass CPU access to another application when the message input queue is empty. Because of this, a Win16 application that fails to check the queue can halt the system for all Win16 applications. Win32 applications that are running should not be affected because the Win16 apps are preemptively multitasked with respect to other processes.
Windows 95 runs Win16 applications as a single multithreaded process in a shared address space. Windows 95 system services DLLs (GDI, GDI32, KERNEL, KERNEL32, USER, USER32) are mapped into the address space of each process. These components, as mentioned earlier, run in user mode. This makes the operating system vulnerable to applications which might write to memory belonging to the operating system.
The system services DLLs in Windows 95 each have a Win32 and a Win16 component. The system is designed to use Win32 code wherever it improves performance without sacrificing application compatibility and uses Win16 code where Win32 code would increase memory requirements without improving performance. Consequently, in Windows 95 both Win16 and Win32 applications require some thunking (translation) between 16-bit and 32-bit threads.
Additionally, the Win16 code in Windows 95 is nonreentrant, whereas Win32 code is reentrant. Reentrant code can be interrupted and resume unharmed, and it can be shared by different threads executing different lines of the same code. The nonreentrant code in Windows 95 would be vulnerable to Win32 threads, except for a flag (called Win16Mutex) that prevent threads from accessing code another thread is using to execute. Consequently, performance of even Win32 applications is slower when Win16 applications are running.
Windows NT can run each Win16 and MS-DOS application in its own private address space within a Win32 application called a Virtual DOS Machine (VDM), thus protecting it from other Win16 programs. This allows Windows NT to preemptively multitask all operating system services and all applications. For a more detailed description of preemptive multitasking and scheduling, see Chapter 5, "Windows NT Workstation Architecture."
DOS applications run well on both systems, running in separate VDMs, but in Windows 95—because some memory is available to all virtual machines—DOS applications can crash the system. In Windows NT, no operating system memory is available to processes outside of kernel mode.
For details about how Windows NT handles Win16 and MS-DOS applications, see "Implementation of the Subsystem" earlier in this chapter. For details about how Windows 95 handles Win16 applications, see the Windows 95 Resource Kit.