Download cis620-12

CIS 620
Advanced Operating
Systems
Lecture 12 – Windows Architecture
Prof. Timothy Arndt
BU 331
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 runs 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
Applications
Logon
Process
OS/2
Client
Win32
Client
POSIX
Client
OS/2
Subsystem
Protected
Subsystems
POSIX
Subsystem
Security
Subsystem
Win32
Subsystem
User Mode
Kernel Mode
System Services
NT Executiv e
Object
Manager
Security
Reference
Monitor
Process
Manager
LPC
Facility
Virtual
Memory
Manager
I/O Manager
File Systems
Cache Manager
Device Drivers
Network Drivers
Microkernel
Hardware Abstraction Layer (HAL)
Hardware
Message Passing
System Trap
Hardware Manipulation
Windows NT 4.0 Architecture
Unix Architecture
Application
X-Windows
User Mode
Kernel Mode
System Services
Device Drivers
Process Mgmt., Memory Mgmt, etc.
Hardware Dependent Code
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 inodes.
 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 realtime (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
 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 is 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 kernelmode portion of the address space.
Memory Management
• Some versions of NT (e.g., NT Server 4.0,
Enterprise Edition) support 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 demandpaged 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 leastrecently-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 dataintensive applications like DB servers.
Security
 NT’s security capabilities have earned it a C2capable 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
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 (Xterminals) 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 is supported in 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