CS 620 Advanced Operating Systems Lecture 6 – Windows Architecture Professor Timothy Arndt BU 331

Windows Architecture The current version of Windows (Windows 7), as well as Vista, XP and 2000 are based on the Windows NT kernel  This lecture describes the Windows NT architecture  Previous versions of Windows (ME, 98, 95, 3.1) are based on a different (less advanced) kernel which was an extension of MS-DOS

Windows NT Design Goals Windows NT had a number of design goals:  Compatibility: Windows 95 interface, support for the FAT file system, MS-DOS, OS/2, Windows 3.x and POSIX applications and for a wide variety of devices and networks.  Portability: Windows NT ran on both CISC and RISC processors.  Scalability: NT takes full advantage of symmetric multiprocessing (SMP) hardware. The Microkernel can run on any processor.

Windows NT Design Goals  Security: Windows NT has a uniform security architecture designed to provide a safe environment to run mission-critical applications. It has met the requirements for C2 level security.  Distributed Processing: NT is designed with networking built into the base OS. NT supports a number of transport protocols and named pipes, remote procedure calls (RPCs), and Windows Sockets.

Windows NT Design Goals  Reliability and Robustness: this means that the architecture must protect the OS and applications from damage. Applications cannot read or write outside of their own address space. The OS is isolated from applications.  Localization: NT is offered in many countries around the world, in local languages, and supports Unicode.  Extensibility: the modular design of NT allows modules to be added to all levels of the OS.

Windows NT Architectural Modules  Windows NT 4.0 architecture is divided into two main sections: user mode and kernel mode. Kernel mode is a highly privileged mode of operation in which the code has direct access to all hardware and all memory, including the address spaces of all user processes. The part of Windows NT running in kernel mode is called the Windows NT Executive. It includes the the Hardware Abstraction Layer (HAL), Microkernel, and the Windows NT Executive Service Modules.

Windows NT Architectural Modules User mode is a less privileged processor mode with no direct access to hardware. Code running in user mode acts directly only in its own address space. It uses well-defined operating system application program interfaces (APIs) to request system services. The environment and integral subsystems run in user mode. In Windows NT 4.0, the Windows Manager, the Graphics Device Interface (GDI), and graphics device drivers have been moved from the Win32 subsystem to the Windows NT Executive. This was done to improve performance, but it reduces the reliability of the system.

Windows NT Architectural Modules  Windows NT 4.0 moves further away from a pure microkernel architecture.  Pure microkernel architectures are modular, and they keep the number of components running in kernel mode to a minimum.  These architectures are inherently more reliable, but they may suffer from performance problems due to constant context switches.  Windows NT is a modified microkernel architecture.

Windows NT 3.51 Architecture

Windows NT 4.0 Architecture

Unix Architecture Application X-Windows User Mode Kernel Mode Device Drivers Process Mgmt., Memory Mgmt, etc. Hardware Dependent Code System Services

Namespace and Object Management  An OS namespace gives applications the ability to identify and share resources. The file-system namespace is a well known part. Other resources include synchronization resources and shared memory.  NT’s Object Manager subsystem implements NT’s namespace. The Object Manager is a collection of kernel functions that provide uniform resource tracking, naming, and security to applications and other kernel-mode subsystems.

Namespace and Object Management Kernel subsystems define Object Manager objects to represent the subsystem’s resource types, and rely on the Object Manager’s support routines for naming and security. Processes are represented as process objects, files as file objects, etc. The Object Manager notifies subsystems that own an object when applications close, open, or query the object. This is done via method functions registered when the object type is defined. In response, subsystems can perform actions particular to the object type.

Namespace and Object Management  UNIX’s object-tracking mechanism is not as formal as NT’s. It is based on i-nodes.  Remember that files represent devices and sockets as well as “normal” files.  The kernel notifies file system drivers of actions that applications perform on i-nodes.  This is done by calling functions registered in a table that the file system associates with i- nodes.  Both namespaces are hierarchical.

Process Management  NT and UNIX are time-sharing OSs that try to divide CPU time fairly between applications competing for the CPU.  Neither OS is suitable for a “hard” real-time environment.  NT defines an application using a process object, which serves as a container for all information about the application. Includes a memory space definition that contains the application’s code and data, a table of resources, and one or more threads of execution.

Process Management  The NT scheduler divides time between threads (not between applications). Applications can create additional threads, and all of an application’s threads share resources and memory space.  The scheduler attempts to give CPU time to the highest-priority thread available.  There are two classes of threads: dynamic (with a priority value of between 1 and 15) and real- time (with values between 16 and 31).

Process Management  Real-time priority values are fixed; the scheduler does not adjust those priority values. Typically, only a few OS-owned threads execute in the real-time range.  Same priority threads are scheduled in a preemptive, round-robin manner.  The NT scheduler can also preempt the kernel. Further, multiple threads can execute kernel code on separate CPUs. These two features allow for SMP.

Process Management

 Process management in modern UNIX systems is similar to NT process management.  UNIX schedulers usually implement three priority classes - realtime, system, and dynamic - that span priority numbers from 0 to 100.  The kernels of most UNIX implementations are fully preemptible and reentrant. Several varieties of UNIX (HP-UX, AIX, Solaris) run on large SMPs with 32 or more CPUs, some run on asymmetric multiprocessors. NT 4.0 was limited to 8 CPU SMPs.

Memory Management  An OSs memory manager is responsible for defining virtual address spaces for application code and data, and for sharing the physical memory resource of the computer among applications.  NT’s Memory Manager defines a 32-bit virtual address map for 4GB of virtual memory. Usually, NT assigns the low 2GB to the user mode and the upper 2GB to the kernel mode. Applications do not have direct access to the kernel- mode portion of the address space.

Memory Management Some versions of NT (e.g., NT Server 4.0, Enterprise Edition) supported a switch that changes the virtual address space division to 3GB for user space and 1GB for kernel space. The kernel space permanently maps the NT kernel and device drivers, but user-space mapping changes to reflect the map of the currently executing thread.  NT’s Memory Manager implements demand- paged virtual memory, in which the Memory Manager brings code and data into physical memory as an application accesses the code and data.

Virtual Memory

Memory Management  The Memory Manager implements the features of a modern OS Applications can share portions of their address map with other applications. Copy-on-write is enabled, for efficient implementation of shared memory when changes to shared memory need to remain private. Memory mapped files are enabled (changes to the mapped file automatically reflect back on the file’s on-disk image).

Memory Management  NT assigns each application an upper and lower limit on physical memory. NT calls this amount of physical memory the application’s working set.  When an application reaches its working set’s upper limit and accesses more code or data, the Memory Manager uses a least-recently-used algorithm to find data in the working set to replace.  Most UNIX memory managers are similar.

Memory Management  Some define an even split between user and kernel space and some give the majority to applications, leaving only a few hundred MB for the kernel. UNIX memory managers differ from NT in that they manage memory globally - they do not constrain applications to upper and lower limits. The least- recently-used algorithm is applied to all applications. This can lead to thrashing. Several versions of UNIX support a 64-bit address space. Using 64-bit address spaces can help data- intensive applications like DB servers.

Security  NT’s security capabilities have earned it a C2- capable rating (as a standalone non-networked system).  The NT Object Manager’s centralized security support means that the Object Manager can implement any object - including synchronization objects, shared memory, and files - with security.  NT can audit successful and failed attempts to access an object.

Security

 The traditional UNIX security model is much less powerful.  The lack of ACLs and auditing prevent traditional UNIX from achieving a C2-capable security rating. Major UNIX vendors have implemented proprietary versions which implement these features. Some UNIX variants carry a B2 rating which is higher than that of NT

Thin-Client Computing  UNIX has supported thin-client computing (X- terminals) for many years. Until recently, however, NT was a single user system.  Thin-client systems allow a terminal to display applications that run on a server somewhere on the network.  Citrix modified NT Server 3.51 to let multiple user sessions run on one server: A properly equipped server can run as many as 60 to 100 NT sessions.

Thin-Client Computing  Citrix developed the Independent Computing Architecture (ICA) protocol to allow clients to communicate with the server.  A portion of the RAM and disk are allocated to each session. The OS keeps track of individual user’s activity.  The OS transmits screen output using ICA to the client. The client’s keyboard input is transmitted to the server. A portion of an application is shared among sessions and another portion is not.

Thin-Client Computing  In 1997, Microsoft licensed ICA technology from Citrix. Microsoft developed another protocol called Remote Desktop Protocol (RDP).  RDP runs on Windows CE-based terminals and Windows-based PCs.  ICA supports Windows-based PCs and other thin-client devices.  RDP was supported starting with Windows NT Server 4.0, Terminal Server Edition, released in June 1998.

Thin-Client Computing  The Object Manager and Virtual Memory manager have been modified to perform in a multi-user environment. Every object name created within a session is appended with a unique identifier number associated with the individual session that created it (SessionID).  The fact that all processes share the kernel address space resulted in kernel resource limitations when supporting multiple interactive sessions on a single server.

Thin-Client Computing  In Windows NT Server 4.0, Terminal Server Edition, these limitations were addressed by creating a special address range in the kernel, called "SessionSpace," that can be mapped on a per-session basis.  A new Windows NT service called “Terminal Server” is the controlling process in the Terminal Server architecture. It is primarily responsible for session management, initiation, and termination of user sessions and session event notification.

Session Space

Thin-Client Computing  The Terminal Server service is entirely protocol-independent, so it can function using RDP or a third-party add-on protocol such as Citrix’s ICA.  A user mode protocol extension provides assistance to the Terminal Server service. It is the responsibility of this component to provide protocol-specific functions and services, such as licensing, session shadowing, client font enumeration, and so forth.

Terminal Server Architecture