Windows 2000 - 2003 - XP OS Architecture

Windows OS: Concepts and Fundamentals
WINDOWS OS: CONCEPTS AND FUNDAMENTALS....................................................................1 INTRODUCTION TO THE WINDOWS FAMILY.............................................................................2 FOUNDATION CONCEPTS AND TERMS.........................................................................................3 WINDOWS 2000 ARCHITECTURE: REQUIREMENTS AND DESIGN GOALS......................12 OPERATING SYSTEM MODEL........................................................................................................14 ARCHITECTURE OVERVIEW.........................................................................................................18 WINDOWS 2000/2003/ P PRODUCT PAC!AGING.....................................................................20 !EY SYSTEM COMPONENTS..........................................................................................................22 SUMMARY............................................................................................................................................41
In this chapter, we'll introduce the key Microsoft Windows NT 4.02000/200 /!" concepts and ter#s we'll $e usin% throu%hout this lecture series, such as the Microsoft Win 2 &"I, processes, threads, 'irtual #e#ory, kernel #ode and user #ode, o$(ects, handles, security, and the re%istry. )e sure that you understand e'erythin% in this chapter*the re#ainder of the course is written assu#in% that you do.
+ Copyright 2000-2007, Microsoft Corporation
I"#$%&'(#)%" #% #*+ W)"&%,- F./)01

The current fa#ily of Microsoft Windows operatin% syste#s ,-./ is di'ided into client side and ser'er 'ersions0 the for#er included Windows !" 1o#e, "rofessional, Media 2enter, 3ista ,forthco#in%/, Ta$let "2 and 445$it editions ,re#e#$er too the e#$edded Windows 26 -./, while the latter includes se'eral 'ersions, each ai#ed at ser'in% particular $usiness needs. The Microsoft Windows product we$pa%es will pro'ide you with a %ood o'er'iew of each -. and their salient features. The Windows .er'er 200 fa#ily includes the followin% products0 P$%&'(# D+-($)2#)%" Windows .er'er 200 , .tandard 6dition, is desi%ned for depart#ental and Windows .er'er 200 , standard workloads and deli'ers the followin% $enefits0 .tandard 6dition .upport for file and printer sharin%. More secure Internet connecti'ity. 2entrali7ed desktop application deploy#ent. )uilt for #ission5critical ser'er workloads, Windows .er'er 200 , Windows .er'er 200 , 6nterprise 6dition, is the platfor# of choice for applications, We$ ser'ices, and infrastructure. 8eli'erin% hi%h relia$ility, perfor#ance, and superior 6nterprise 6dition $usiness 'alue, Windows .er'er 200 , 6nterprise 6dition pro'ides these $enefits0 & full5function ser'er operatin% syste# that supports up to 9 processors. 6nterprise5class features, such as ei%ht5node clusterin% and support for up to 2 :) of #e#ory. .upport for Intel Itaniu#5$ased co#puters, &M8 -pteron processors, or Intel !eon processors. .upport for 445$it co#putin% platfor#s capa$le of supportin% 9 processors and 44 :) of ;&M with the 445$it 'ersion.
Windows .er'er 200 , 8atacenter 6dition, is $uilt for the hi%hest le'els of Windows .er'er 200 , scala$ility and relia$ility. -nly this platfor# offers the 8atacenter 1i%h &'aila$ility "ro%ra# of support and ser'ices. )enefits of Windows .er'er 8atacenter 6dition 200 , 8atacenter 6dition, include0 The #ost powerful and functional ser'er operatin% syste# Microsoft has e'er offered. .upport for up to 25way .M" and 44 :) of ;&M with the 25$it 'ersion. .upport for up to +295way #achines with indi'idual partitions of up to 44 processors and <+2 :) of ;&M with the 445$it 'ersion. )oth 95node clusterin% and load $alancin% ser'ices as standard features. Windows .yste# ;esource Mana%er to facilitate consolidation
2 Copyright 2000-2007, Microsoft Corporation
P$%&'(#
D+-($)2#)%"
and syste# #ana%e#ent.
Windows .er'er 200 , This was a new departure for Windows operatin% syste#s, as Windows We$ 6dition .er'er 200 We$ 6dition offers dedicated We$ ser'in% and hostin% as well as the followin% $enefits0 & platfor# for $uildin% and hostin% We$ applications, We$ pa%es, and !M= We$ .er'ices. & desi%n intended for use pri#arily as an II. 4.0 We$ ser'er. & platfor# for rapidly de'elopin% and deployin% !M= We$ ser'ices and applications that use &.".N6T technolo%y, a key part of the .N6T >ra#ework. 6ase of deploy#ent and #ana%e#ent.
Windows .#all )usiness .er'er 200
Windows .#all )usiness .er'er 200 pro'ides a co#plete $usiness ser'er solution for s#all $usinesses. The inte%rated suite of ser'er products ena$les co#panies to share infor#ation and resources safely and securely. .tandard 6dition includes Windows .er'er 200 , .tandard 6dition, Microsoft Windows .hare"oint .er'ices, Microsoft 6?chan%e .er'er 200 , and Microsoft .hared >a? .er'ice. "re#iu# 6dition includes Windows .er'er 200 , .tandard 6dition, Microsoft Windows .hare"oint .er'ices, Microsoft 6?chan%e .er'er 200 , Microsoft -ffice -utlook 200 , Microsoft .hared >a? .er'ice, Microsoft Internet .ecurity and &cceleration ,I.&/ .er'er, Microsoft .@= .er'er 2000, and Microsoft -ffice >ront"a%e 200 .
While we are focussin% chiefly on ser'er -., students should #ake the#sel'es fa#iliar with the application and features of the entire Windows fa#ily.
F%'"&.#)%" C%"(+2#- ."& T+$/In the course of this lecture series we'll $e referrin% to so#e structures and concepts that #i%ht $e unfa#iliar to so#e readers. In this section, we will define the ter#s we'll $e usin% throu%hout. Aou should $eco#e fa#iliar with the# $efore proceedin% to su$seBuent chapters.
Win32 API
The Win 2 application pro%ra##in% interface ,&"I/ is the pri#ary pro%ra##in% interface to the Microsoft Windows operatin% syste# fa#ily, includin% Windows 2000/200 , Windows C<, Windows C9, Windows Millenniu# 6dition, and Windows 26. -f course, the Win44 &"I will, o'er ti#e replace the Win 2, as it replaced the older WIN+4 &"I. Win 2 for 445$it
Copyright 2000-2007, Microsoft Corporation
Windows, also known as Win44, is the 'ersion of the &"I tar%eted for 445$it 'ersions of Windows * na#ely, Windows !" "rofessional ?44 6dition and Windows .er'er 200 ?44 6dition ,for &M844 processors/ and Windows !" 445$it 6dition and Windows .er'er 200 for Itaniu#5series. The 445$it 'ersions are (ust two #ore supported platfor#s within Windows NT architecture so $oth 25$it and 445$it 'ersions of an application can still $e co#piled fro# sin%le code $ase. &ll #e#ory pointers are 445$it $y default thou%h, so the source code has to $e checked for co#pati$ility with 445$it pointer arith#etic and rewritten as necessary. There are no new functions specific to 445$it 'ersions of Windows. &lthou%h we don't descri$e the Win 2 or Win44 &"I in this lecture series, we do e?plain the internal $eha'ior and i#ple#entation of key Win 2 &"I functions. 6ach Windows operatin% syste# i#ple#ents a different su$set of Win 2. >or the #ost part, Windows 200 is a superset of all Win 2 i#ple#entations. The specifics of which ser'ices are i#ple#ented on which platfor#s are included in the reference docu#entation for the Win 2 and Win44 &"Is. >or the purposes of this lecture series, the Win 2 &"I refers to the $ase set of functions that co'er areas such as processes, threads, #e#ory #ana%e#ent, security, I/-, windowin%, and %raphics. &lthou%h Windows 200 was desi%ned to support #ultiple pro%ra##in% interfaces, Win 2 is the pri#ary, or preferred, interface to the operatin% syste#. Win 2 has this position $ecause, of the three en'iron#ent su$syste#s ,Win 2, "-.I!, and -./2/, it pro'ides the %reatest access to the underlyin% Windows 2000/200 syste# ser'ices. The application pro%ra#s on Windows 2000 don't call nati'e Windows 2000 syste# ser'ices directly*rather, they #ust use one of the &"Is pro'ided $y an en'iron#ent su$syste#.
Services, Functions, and Routines

.e'eral ter#s in the Windows 2000 user and pro%ra##in% docu#entation ha'e different #eanin%s in different conte?ts. >or e?a#ple, the word service can refer to a calla$le routine in the operatin% syste#, a de'ice dri'er, or a ser'er process. The followin% list descri$es what certain ter#s #ean in this lecture series0

W)"32 API 3'"(#)%"- 8ocu#ented, calla$le su$routines in the Win 2 &"I. 6?a#ples include CreateProcess, CreateFile, and GetMessage. S1-#+/ -+$4)(+- 5%$ +6+('#)4+ -1-#+/ -+$4)(+-7 Nati'e functions in the Windows 2000 operatin% syste# that are calla$le fro# user #ode. >or e?a#ple, NtCreateProcess is the internal syste# ser'ice the Win 2 CreateProcess function calls to create a new process. !+$"+0 -'22%$# 3'"(#)%"- 5%$ $%'#)"+-7 .u$routines inside the kernel5#ode ,defined later in this chapter/ part of the Windows 2000 operatin% syste#. >or e?a#ple, ExAllocatePool is the routine that de'ice dri'ers call to allocate #e#ory fro# the Windows 2000 syste# heaps. W)"32 -+$4)(+- "rocesses started $y the Windows 2000 ser'ice control #ana%er. ,&lthou%h the re%istry defines Windows 2000 de'ice dri'ers as Dser'ices,D we don't refer to the# as such in this lecture series./ >or e?a#ple, the Task .cheduler ser'ice is a user5#ode process that supports the at co##and ,which is si#ilar to the ENI! co##ands at or cron/. DLL 5&1"./)(80)"9 0):$.$17 & set of calla$le su$routines linked to%ether as a $inary file that can $e dyna#ically loaded $y applications that use the su$routines. 6?a#ples include Ms'crt.dll ,the 2 run5ti#e li$rary/ and Fernel 2.dll ,one of the Win 2 &"I su$syste# li$raries/. Windows 2000 user5#ode co#ponents and applications use 8==s e?tensi'ely. The ad'anta%e 8==s pro'ide o'er static li$raries is that applications can share 8==s, and Windows 2000 ensures that there is only one in5 #e#ory copy of a 8=='s code a#on% the applications that are referencin% it.
Processes, Threads, and Jobs

&lthou%h pro%ra#s and processes appear si#ilar on the surface, they are funda#entally different. & program is a static seBuence of instructions, whereas a process is a container for a set of resources used $y the threads that e?ecute the instance of the pro%ra#. &t the hi%hest le'el of a$straction, a Windows 2000 process co#prises the followin%0

& pri'ate virtual address space, which is a set of 'irtual #e#ory addresses that the process can use &n e?ecuta$le pro%ra#, which defines initial code and data and is #apped into the process's 'irtual address space & list of open handles to 'arious syste# resources, such as se#aphores, co##unication ports, and files, that are accessi$le to all threads in the process & security conte?t called an access token that identifies the user, security %roups, and pri'ile%es associated with the process & uniBue identifier called a process ID ,internally called a client ID/ &t least one thread of e?ecution
& thread is the entity within a process that Windows 2000 schedules for e?ecution. Without it, the process's pro%ra# can't run. & thread includes the followin% essential co#ponents0

The contents of a set of 2"E re%isters representin% the state of the processor Two stacks, one for the thread to use while e?ecutin% in kernel #ode and one for e?ecutin% in user #ode & pri'ate stora%e area called thread5local stora%e ,T=./ for use $y su$syste#s, run5 ti#e li$raries, and 8==s & uniBue identifier called a thread ID ,also internally called a client ID*process I8s and thread I8s are %enerated out of the sa#e na#espace, so they ne'er o'erlap/ Threads so#eti#es ha'e their own security conte?t that is often used $y #ultithreaded ser'er applications that i#personate the security conte?t of the clients that they ser'e
The 'olatile re%isters, the stacks, and the pri'ate stora%e area are called the thread's context. )ecause this infor#ation is different for each #achine architecture that Windows 2000 runs on, this structure, $y necessity, is architecture5specific. In fact, the 2-NT6!T structure returned $y the Win 2 GetThreadContext function is the only pu$lic data structure in the Win 2 &"I that is #achine5dependent. &lthou%h threads ha'e their own e?ecution conte?t, e'ery thread within a process shares the process's 'irtual address space ,in addition to the rest of the resources $elon%in% to the process/, #eanin% that all the threads in a process can write to and read fro# each other's #e#ory. Threads can't reference the address space of another process, howe'er, unless the other process #akes a'aila$le part of its pri'ate address space as a shared memor section ,called a !ile mapping o"#ect in the Win 2 &"I/ or unless one process opens another process and uses the $eadProcessMemor and %riteProcessMemor functions. In addition to a pri'ate address space and one or #ore threads, each process has a security identification and a list of open handles to o$(ects such as files, shared #e#ory sections, or one of the synchroni7ation o$(ects such as #ute?es, e'ents, or se#aphores, as illustrated in >i%ure +5+.
< Copyright 2000-2007, Microsoft Corporation
F);'$+ 181 A process and its resources
6'ery process has a security conte?t that is stored in an o$(ect called an access to&en. The process access token contains the security identification and credentials for the process. )y default, threads don't ha'e their own access token, $ut they can o$tain one, thus allowin% indi'idual threads to i#personate the security conte?t of another process*includin% processes runnin% on a re#ote Windows 2000 syste#*without affectin% other threads in the process. The 'irtual address descriptors ,3&8s/ are data structures that the #e#ory #ana%er uses to keep track of the 'irtual addresses the process is usin%. Windows 2000 introduces an e?tension to the process #odel called a #o". & (o$ o$(ect's #ain function is to allow %roups of processes to $e #ana%ed and #anipulated as a unit. & (o$ o$(ect allows control of certain attri$utes and pro'ides li#its for the process or processes associated with the (o$. It also records $asic accountin% infor#ation for all processes associated with the (o$ and for all processes that were associated with the (o$ $ut ha'e since ter#inated. In so#e ways, the (o$ o$(ect co#pensates for the lack of a structured process tree in Windows 2000*yet in #any ways is #ore powerful than a ENI!5style process tree.
Virtual Memor
Windows 2000 i#ple#ents a 'irtual #e#ory syste# $ased on a flat ,linear/ 2$it address space. Thirty5two $its of address space translates into 4 :) of 'irtual #e#ory. -n #ost syste#s, Windows 2000 allocates half this address space ,the lower half of the 45:) 'irtual address space, fro# ?00000000 throu%h ?G>>>>>>>/ to processes for their uniBue pri'ate stora%e and uses the other half ,the upper half, addresses ?90000000 throu%h ?>>>>>>>>/ for its own protected operatin% syste# #e#ory utili7ation. The #appin%s of the lower half chan%e to reflect the 'irtual address space of the currently e?ecutin% process, $ut the #appin%s of the upper half always consist of the operatin% syste#'s 'irtual #e#ory. Windows 2000 &d'anced .er'er and 8atacenter .er'er support a $oot5ti#e option ,the / :) Bualifier in )oot.ini/ that %i'es processes runnin% specially #arked pro%ra#s ,the lar%e
address space aware fla% #ust $e set in the header of the e?ecuta$le i#a%e/ a 5:) pri'ate address space ,lea'in% + :) for the operatin% syste#/. This option allows applications such as data$ase ser'ers to keep lar%er portions of a data$ase in the process address space, thus reducin% the need to #ap su$set 'iews of the data$ase. >i%ure +52 shows the two 'irtual address space layouts supported $y Windows 2000.
F);'$+ 182 Address space la outs supported " %indo's ())) &lthou%h :) is $etter than 2 :), it's still not enou%h 'irtual address space to #ap 'ery lar%e ,#ulti%i%a$yte/ data$ases. To address this need, Windows 2000 has a new #echanis# called Address %indo'ing Extensions ,&W6/, which allows a 25$it application to allocate up to 44 :) of physical #e#ory and then #ap 'iews, or windows, into its 25:) 'irtual address space. &lthou%h usin% &W6 puts the $urden of #ana%in% #appin%s of 'irtual to physical #e#ory on the pro%ra##er, it does sol'e the i##ediate need of $ein% a$le to directly access #ore physical #e#ory than can $e #apped at any one ti#e in a 25$it process address space. The lon%5ter# solution to this address space li#itation is 445$it Windows. ;ecall that a process's 'irtual address space is the set of addresses a'aila$le for the process's threads to use. 3irtual #e#ory pro'ides a lo%ical 'iew of #e#ory that #i%ht not correspond to its physical layout. &t run ti#e the #e#ory #ana%er, with assistance fro# hardware, translates, or maps, the 'irtual addresses into physical addresses, where the data is actually stored. )y controllin% the protection and #appin%, the operatin% syste# can ensure that indi'idual processes don't $u#p into one another or o'erwrite operatin% syste# data. >i%ure +5 illustrates three 'irtually conti%uous pa%es #apped to three disconti%uous pa%es in physical #e#ory. )ecause #ost syste#s ha'e #uch less physical #e#ory than the total 'irtual #e#ory in use $y the runnin% processes ,2 :) or :) for each process/, the #e#ory #ana%er transfers, or pages, so#e of the #e#ory contents to disk. "a%in% data to disk frees physical #e#ory so that it can $e used for other processes or for the operatin% syste# itself. When a thread accesses a 'irtual address that has $een pa%ed to disk, the 'irtual #e#ory #ana%er loads the infor#ation $ack into #e#ory fro# disk. &pplications don't ha'e to $e altered in any way to take ad'anta%e of pa%in% $ecause hardware support ena$les the #e#ory #ana%er to pa%e without the knowled%e or assistance of processes or threads.
G Copyright 2000-2007, Microsoft Corporation
F);'$+ 183 Mapping virtual memor to ph sical memor
!ernel Mode vs" #ser Mode

To protect user applications fro# accessin% and/or #odifyin% critical operatin% syste# data, Windows 2000 uses two processor access modes ,e'en if the processor on which Windows 2000 is runnin% supports #ore than two/0 user mode and &ernel mode. Eser application code runs in user #ode, whereas operatin% syste# code ,such as syste# ser'ices and de'ice dri'ers/ runs in kernel #ode. Fernel #ode refers to a #ode of e?ecution in a processor that %rants access to all syste# #e#ory and all 2"E instructions. )y pro'idin% the operatin% syste# software with a hi%her pri'ile%e le'el than the application software has, the processor pro'ides a necessary foundation for operatin% syste# desi%ners to ensure that a #is$eha'in% application can't disrupt the sta$ility of the syste# as a whole.
Rin$s o% Protection and !ernel&#ser Modes

The architecture of the Intel ?94 processor defines four pri'ile%e le'els, or rings, to protect syste# code and data fro# $ein% o'erwritten either inad'ertently or #aliciously $y code of lesser pri'ile%e. Windows 2000 uses pri'ile%e le'el 0 ,or rin% 0/ for kernel #ode and pri'ile%e le'el ,or rin% / for user #ode. The reason Windows 200 uses only two le'els is that so#e of the hardware architectures that were supported in the past ,such as 2o#paB &lpha and .ilicon :raphics MI"./ i#ple#ented only two pri'ile%e le'els. &lthou%h each Win 2 process has its own pri'ate #e#ory space, kernel5#ode operatin% syste# and de'ice dri'er code share a sin%le 'irtual address space. 6ach pa%e in 'irtual #e#ory is ta%%ed as to what access #ode the processor #ust $e in to read and/or write the pa%e. "a%es in syste# space can $e accessed only fro# kernel #ode, whereas all pa%es in the user address space are accessi$le fro# user #ode. ;ead5only pa%es ,such as those that contain e?ecuta$le code/ are not writa$le fro# any #ode. Windows 200 doesn't pro'ide any protection to pri'ate read/write syste# #e#ory $ein% used $y co#ponents runnin% in kernel #ode. In other words, once in kernel #ode, operatin% syste# and de'ice dri'er code has co#plete access to syste# space #e#ory and can $ypass
Windows 200 security to access o$(ects. )ecause the $ulk of the Windows 2000 operatin% syste# code runs in kernel #ode, it is 'ital that co#ponents that run in kernel #ode $e carefully desi%ned and tested to ensure that they don't 'iolate syste# security. This lack of protection also e#phasi7es the need to take care when loadin% a third5party de'ice dri'er, $ecause once in kernel #ode the software has co#plete access to all operatin% syste# data. This 'ulnera$ility was one of the reasons $ehind the dri'er5si%nin% #echanis# introduced in Windows 2000, which warns the user if an atte#pt is #ade to add an unauthori7ed ,unsi%ned/ dri'er. &lso, a #echanis# called 8ri'er 3erifier helps de'ice dri'er writers to find $u%s ,such as #e#ory leaks/. T.:0+ 181 Mode*$elated Per!ormance Counters O:<+(#: C%'"#+$ "rocessor0 "ri'ile%ed Ti#e F'"(#)%" H "ercenta%e of ti#e that an indi'idual 2"E ,or all 2"Es/ has run in kernel #ode durin% a specified inter'al
"rocessor0 H Eser "ercenta%e of ti#e that an indi'idual 2"E ,or all 2"Es/ has run Ti#e in user #ode durin% a specified inter'al "rocess0 H "ri'ile%ed "ercenta%e of ti#e that the threads in a process ha'e run in kernel Ti#e #ode durin% a specified inter'al "rocess0 Ti#e H Eser "ercenta%e of ti#e that the threads in a process ha'e run in user #ode durin% a specified inter'al
Thread0 H "ri'ile%ed "ercenta%e of ti#e that a thread has run in kernel #ode durin% a Ti#e specified inter'al Thread0 H Eser Ti#e "ercenta%e of ti#e that a thread has run in user #ode durin% a specified inter'al
Eser applications switch fro# user #ode to kernel #ode when they #ake a syste# ser'ice call. >or e?a#ple, a Win 2 $eadFile function e'entually needs to call the internal Windows 2000 routine that actually handles readin% data fro# a file. That routine, $ecause it accesses internal syste# data structures, #ust run in kernel #ode. The transition fro# user #ode to kernel #ode is acco#plished $y the use of a special processor instruction that causes the processor to switch to kernel #ode. The operatin% syste# traps this instruction, notices that a syste# ser'ice is $ein% reBuested, 'alidates the ar%u#ents the thread passed to the syste# function, and then e?ecutes the internal function. )efore returnin% control to the user thread, the processor #ode is switched $ack to user #ode. In this way, the operatin% syste# protects itself and its data fro# perusal and #odification $y user processes. NOTE & transition fro# user #ode to kernel #ode ,and $ack/ does not affect thread schedulin% per se*a #ode transition is not a conte?t switch. Thus, it's nor#al for a user thread to spend part of its ti#e e?ecutin% in user #ode and part in kernel #ode. In fact, $ecause the $ulk of the %raphics and windowin% syste# also runs in kernel #ode, %raphics5intensi'e applications spend #ore of their ti#e in kernel #ode than in user #ode. &n easy way to test this is to run a %raphics5intensi'e application such as Microsoft "aint or Microsoft "in$all and watch the ti#e split $etween user #ode and kernel #ode usin% one of the perfor#ance counters listed in Ta$le +5+.
C Copyright 2000-2007, Microsoft Corporation
'b(ects and )andles

In the Windows 2000 operatin% syste#, an o"#ect is a sin%le, run5ti#e instance of a statically defined o$(ect type. &n o"#ect t pe co#prises a syste#5defined data type, functions that operate on instances of the data type, and a set of o$(ect attri$utes. If you write Win 2 applications, you #i%ht encounter process, thread, file, and e'ent o$(ects, to na#e (ust a few e?a#ples. These o$(ects are $ased on lower5le'el o$(ects that Windows 2000 creates and #ana%es. In Windows 2000, a process is an instance of the process o$(ect type, a file is an instance of the file o$(ect type, and so on. &n o"#ect attri"ute is a field of data in an o$(ect that partially defines the o$(ect's state. &n o$(ect of type process, for e?a#ple, would ha'e attri$utes that include the process I8, a $ase schedulin% priority, and a pointer to an access token o$(ect. +"#ect methods, the #eans for #anipulatin% o$(ects, usually read or chan%e the o$(ect attri$utes. >or e?a#ple, the open #ethod for a process would accept a process identifier as input and return a pointer to the o$(ect as output. NOTE &lthou%h there is a para#eter na#ed +"#ectAttri"utes that a caller supplies when creatin% an o$(ect usin% either the Win 2 &"I or nati'e o$(ect ser'ices, that para#eter shouldn't $e confused with the #ore %eneral #eanin% of the ter# as used in this lecture series. The #ost funda#ental difference $etween an o$(ect and an ordinary data structure is that the internal structure of an o$(ect is hidden. Aou #ust call an o$(ect ser'ice to %et data out of an o$(ect or to put data into it. Aou can't directly read or chan%e data inside an o$(ect. This difference separates the underlyin% i#ple#entation of the o$(ect fro# code that #erely uses it, a techniBue that allows o$(ect i#ple#entations to $e chan%ed easily o'er ti#e. -$(ects pro'ide a con'enient #eans for acco#plishin% the followin% four i#portant operatin% syste# tasks0

"ro'idin% hu#an5reada$le na#es for syste# resources .harin% resources and data a#on% processes "rotectin% resources fro# unauthori7ed access ;eference trackin%, which allows the syste# to know when an o$(ect is no lon%er in use so that it can $e auto#atically deallocated
Not all data structures in the Windows 2000 operatin% syste# are o$(ects. -nly data that needs to $e shared, protected, na#ed, or #ade 'isi$le to user5#ode pro%ra#s ,'ia syste# ser'ices/ is placed in o$(ects. .tructures used $y only one co#ponent of the operatin% syste# to i#ple#ent internal functions are not o$(ects.
Securit
Windows 2000 supports 225le'el security as defined $y the E... 8epart#ent of 8efense Trusted 2o#puter .yste# 6'aluation 2riteria ,8o8 <200.295.T8, 8ece#$er +C9</. This standard includes discretionary ,need5to5know/ protection for all sharea$le syste# o$(ects ,such as files, directories, processes, threads, and so forth/, security auditin% ,for accounta$ility of su$(ects, or users, and the actions they initiate/, password authentication at lo%on, and the pre'ention of one user fro# accessin% uninitiali7ed resources ,such as free #e#ory or disk space/ that another user has deallocated.
+0 Copyright 2000-2007, Microsoft Corporation
Windows NT 4 was for#ally e'aluated at the 22 le'el and is on the E... %o'ern#ent 6'aluated "roducts =ist. ,Windows 2000 is still in the e'aluation process./ &lso, Windows NT 4 has #et the 6uropean or%ani7ation IT.62 ,IT .ecurity 6'aluation 2riteria/ at the >22/6 ,functional le'el 22 and assurance le'el 6 , so#ethin% nor#ally associated only with )5le'el syste#s/ security le'el. &chie'in% a %o'ern#ent5appro'ed security ratin% allows an operatin% syste# to co#pete in that arena. -f course, #any of these reBuired capa$ilities are ad'anta%eous features for any #ultiuser syste#. Windows 2000 has two for#s of access control o'er o$(ects. The first for#*discretionary access control*is the protection #echanis# that #ost people think of when they think of protection under Windows 2000. It's the #ethod $y which owners of o$(ects ,such as files or printers/ %rant or deny access to others. When users lo% in, they are %i'en a set of security credentials, or a security conte?t. When they atte#pt to access o$(ects, their security conte?t is co#pared to the access control list on the o$(ect they are tryin% to access to deter#ine whether they ha'e per#ission to perfor# the reBuested operation. "ri'ile%ed access control is necessary for those ti#es when discretionary access control isn't enou%h. It's a #ethod of ensurin% that so#eone can %et to protected o$(ects if the owner isn't a'aila$le. >or e?a#ple, if an e#ployee lea'es a co#pany, the ad#inistrator needs a way to %ain access to files that #i%ht ha'e $een accessi$le only to that e#ployee. In that case, under Windows 2000, the ad#inistrator can ta&e o'nership of the file so that you can #ana%e its ri%hts as necessary. .ecurity per'ades the interface of the Win 2 &"I. The Win 2 su$syste# i#ple#ents o$(ect5 $ased security in the sa#e way the operatin% syste# doesI the Win 2 su$syste# protects shared Windows o$(ects fro# unauthori7ed access $y placin% Windows 2000 security descriptors on the#. The first ti#e an application tries to access a shared o$(ect, the Win 2 su$syste# 'erifies the application's ri%ht to do so. If the security check succeeds, the Win 2 su$syste# allows the application to proceed. The Win 2 su$syste# i#ple#ents o$(ect security on a nu#$er of shared o$(ects, so#e of which were $uilt on top of nati'e Windows 2000 o$(ects. The Win 2 o$(ects include desktop o$(ects, window o$(ects, #enu o$(ects, files, processes, threads, and se'eral synchroni7ation o$(ects.
Re$istr
Aou can't talk #uch a$out Windows 2000/200 internals without referrin% to the re%istry $ecause it is the syste# data$ase that contains the infor#ation reBuired to $oot and confi%ure the syste#, syste#5wide software settin%s that control the operation of Windows 2000/200 , the security data$ase, and per5user confi%uration settin%s ,such as which screen sa'er to use/. In addition, the re%istry is a window into in5#e#ory 'olatile data, such as the current hardware state of the syste# ,what de'ice dri'ers are loaded, the resources they are usin%, and so on/ as well as the Windows 2000 perfor#ance counters. The perfor#ance counters, which aren't actually DinD the re%istry, are accessed throu%h the re%istry functions. &lthou%h #any Windows !"/200 users and ad#inistrators will ne'er need to look directly into the re%istry ,since you can 'iew or chan%e #ost of the confi%uration settin%s with standard ad#inistrati'e utilities/, it is still a useful source of Windows 2000 internals infor#ation $ecause it contains #any settin%s that affect syste# perfor#ance and $eha'ior. ,If you decide to directly chan%e re%istry settin%s, you #ust e?ercise e?tre#e cautionI any chan%es #i%ht ad'ersely affect syste# perfor#ance or, worse, cause the syste# to fail to $oot successfully./ Aou'll find references to indi'idual re%istry keys throu%hout this lecture series
++ Copyright 2000-2007, Microsoft Corporation
as they pertain to the co#ponent $ein% descri$ed. Most re%istry keys referred to in this lecture series are under 1F6AJ=-2&=JM&21IN6, which we'll a$$re'iate throu%hout as 1F=M.
#nicode
Windows 2000/200 differs fro# #ost other operatin% syste#s in that #ost internal te?t strin%s are stored and processed as +45$it5wide Enicode characters. Enicode is an international character set standard that defines uniBue +45$it 'alues for #ost of the world's known character sets. ,>or #ore infor#ation a$out Enicode, see ''',unicode,org as well as the pro%ra##in% docu#entation in the M.8N =i$rary./ )ecause #any applications deal with 95$it ,sin%le5$yte/ &N.I character strin%s, Win 2 functions that accept strin% para#eters ha'e two entry points0 a Enicode ,wide, +45$it/ and an &N.I ,narrow, 95$it/ 'ersion. The Windows C<, Windows C9, and Windows Millenniu# 6dition i#ple#entations of Win 2 don't i#ple#ent all the Enicode interfaces to all the Win 2 functions, so applications desi%ned to run on one of these operatin% syste#s as well as Windows 2000 typically use the narrow 'ersions. If you call the narrow 'ersion of a Win 2 function, input strin% para#eters are con'erted to Enicode $efore $ein% processed $y the syste# and output para#eters are con'erted fro# Enicode to &N.I $efore $ein% returned to the application. Thus, if you ha'e an older ser'ice or piece of code that you need to run on Windows 2000 $ut this code is written usin% &N.I character te?t strin%s, Windows 2000 will con'ert the &N.I characters into Enicode for its own use. 1owe'er, Windows 2000 ne'er con'erts the data inside files*it's up to the application to decide whether to store data as Enicode or as &N.I. In pre'ious editions of Windows NT, &sian and Middle 6ast editions were a superset of the core E... and 6uropean editions and contained additional Win 2 functions to handle #ore co#ple? te?t input and layout reBuire#ents ,such as ri%ht to left te?t input/. In Windows 2000, all lan%ua%e editions contain the sa#e Win 2 functions. Instead of ha'in% separate lan%ua%e 'ersions, Windows 2000 has a sin%le worldwide $inary so that a sin%le installation can support #ultiple lan%ua%es ,$y addin% 'arious lan%ua%e packs/. &pplications can also take ad'anta%e of Win 2 functions that allow sin%le worldwide application $inaries that can support #ultiple lan%ua%es.
W)"&%,- 2000 A$(*)#+(#'$+: R+=')$+/+"#- ."& D+-);" G%.0The followin% reBuire#ents dro'e the specification of Windows NT $ack in +C9C0

"ro'ide a true 25$it, pree#pti'e, reentrant, 'irtual #e#ory operatin% syste# ;un on #ultiple hardware architectures and platfor#s ;un and scale well on sy##etric #ultiprocessin% syste#s )e a %reat distri$uted co#putin% platfor#, $oth as a network client and as a ser'er ;un #ost e?istin% +45$it M.58-. and Microsoft Windows .+ applications Meet %o'ern#ent reBuire#ents for "-.I! +00 .+ co#pliance Meet %o'ern#ent and industry reBuire#ents for operatin% syste# security )e easily adapta$le to the %lo$al #arket $y supportin% Enicode
To %uide the thousands of decisions that had to $e #ade to create a syste# that #et these reBuire#ents, the Windows NT desi%n tea# adopted the followin% desi%n %oals at the $e%innin% of the pro(ect0
E6#+"-):)0)#1 The code #ust $e written to co#forta$ly %row and chan%e as #arket reBuire#ents chan%e. P%$#.:)0)#1 The syste# #ust $e a$le to run on #ultiple hardware architectures and #ust $e a$le to #o'e with relati'e ease to new ones as #arket de#ands dictate. R+0).:)0)#1 ."& $%:'-#"+-- The syste# should protect itself fro# $oth internal #alfunction and e?ternal ta#perin%. &pplications should not $e a$le to har# the operatin% syste# or other applications. C%/2.#):)0)#1 &lthou%h Windows NT should e?tend e?istin% technolo%y, its user interface and &"Is should $e co#pati$le with older 'ersions of Windows and with M.58-.. It should also interoperate well with other syste#s such as ENI!, -./2, and NetWare. P+$3%$/."(+ Within the constraints of the other desi%n %oals, the syste# should $e as fast and responsi'e as possi$le on each hardware platfor#.
&s we e?plore the details of the internal structure and operation of Windows 2000, you'll see how these ori%inal desi%n %oals and #arket reBuire#ents were wo'en successfully into the construction of the syste#. )ut $efore we start that e?ploration, let's e?a#ine the o'erall desi%n #odel for Windows 2000 and co#pare it with other #odern operatin% syste#s. W)"&%,- 2000/2003 4-. C%"-'/+$ W)"&%,Windows 2000/200 "rofessional/!" and 2onsu#er Windows ,Windows C<, Windows C9, and Windows Millenniu# 6dition/ are part of the DWindows fa#ily of operatin% syste#s,D sharin% a co##on su$set &"I ,Win 2 and 2-M/ and in so#e cases operatin% syste# code. Windows 2000/200 , Windows C9, and Windows Millenniu# 6dition also shared a co##on su$set de'ice dri'er #odel called the Windows 8ri'er Model ,W8M/. >ro# the initial announce#ent of Windows NT, Microsoft has always #ade it clear that this operatin% syste# was to $e the strate%ic platfor# for the future*not (ust for ser'ers and $usiness desktops $ut e'entually for consu#er syste#s as well. The followin% list hi%hli%hts so#e of the architectural differences and ad'anta%es that Windows 2000 has o'er 2onsu#er Windows0

Windows 2000/200 /!" supports #ultiprocessor syste#s*2onsu#er Windows doesn't. The Windows 2000/200 /!" file syste# supports security ,such as discretionary access control/. The 2onsu#er Windows file syste# doesn't. Windows 2000/200 /!" are fully 25$it operatin% syste#s*they contain no +45$it code, other than support code for runnin% +45$it Windows applications. 2onsu#er Windows contains a lar%e a#ount of old +45$it code fro# its predecessors, Windows .+ and M.58-.. Windows 2000/200 /!" is fully reentrant*si%nificant parts of 2onsu#er Windows are nonreentrant ,#ainly the +45$it code taken fro# Windows .+/. This nonreentrant code includes the #a(ority of the %raphics and window #ana%e#ent functions ,:8I and E.6;/. When a 25$it application on 2onsu#er Windows atte#pts to call a syste# ser'ice i#ple#ented in nonreentrant +45$it code, the application #ust first o$tain a syste#wide lock ,or #ute?/ to $lock other threads fro# enterin% the nonreentrant code $ase. &nd e'en worse, a +45$it application holds this lock 'hile running. &s a result, althou%h the core of 2onsu#er Windows contains a pree#pti'e 25$it #ultithreaded scheduler, applications often run sin%le threaded $ecause so #uch of the syste# is still i#ple#ented in nonreentrant code. Windows 2000/200 /!" pro'ides an option to run +45$it Windows applications in their own address space*2onsu#er Windows always runs
+45$it Windows applications in a shared address space, in which they can corrupt ,and han%/ each other. .hared #e#ory on Windows 2000/200 /!" is 'isi$le only to the processes that are #appin% the sa#e shared #e#ory section. ,In the Win 2 &"I, a shared #e#ory section is called a !ile mapping o"#ect./ -n 2onsu#er Windows, all shared #e#ory is 'isi$le and writa$le fro# all processes. Thus, any process can write to any file #appin% o$(ect. 2onsu#er Windows has so#e critical operatin% syste# pa%es that are writa$le fro# user #ode, thus allowin% a user application to corrupt or crash the syste#.
The one thin% 2onsu#er Windows can do that Windows 2000/200 /!" will ne'er do is run all older M.58-. and Windows .+ applications ,nota$ly applications that reBuire direct hardware access/ as well as +4$it M.58-. de'ice dri'ers. Whereas +00 percent co#pati$ility with M.58-. and Windows .+ was a #andatory %oal for Windows C<, the ori%inal %oal for Windows NT was to run most e?istin% +45$it applications while preser'in% the inte%rity and relia$ility of the syste#.
O2+$.#)"; S1-#+/ M%&+0

In #ost #ultiuser operatin% syste#s, applications are separated fro# the operatin% syste# itself*the operatin% syste# code runs in a pri'ile%ed processor #ode ,referred to as &ernel mode in this lecture series/, with access to syste# data and to the hardwareI application code runs in a nonpri'ile%ed processor #ode ,called user mode/, with a li#ited set of interfaces a'aila$le, li#ited access to syste# data, and no direct access to hardware. When a user5#ode pro%ra# calls a syste# ser'ice, the processor traps the call and then switches the callin% thread to kernel #ode. When the syste# ser'ice co#pletes, the operatin% syste# switches the thread conte?t $ack to user #ode and allows the caller to continue. Windows 2000 is si#ilar to #ost ENI! syste#s in that it's a #onolithic operatin% syste# in the sense that the $ulk of the operatin% syste# and de'ice dri'er code shares the sa#e kernel5 #ode protected #e#ory space. This #eans that any operatin% syste# co#ponent or de'ice dri'er can potentially corrupt data $ein% used $y other operatin% syste# co#ponents. I- W)"&%,- 2000/2003/ P . M)($%9+$"+08>.-+& S1-#+/? &lthou%h so#e clai# it as such, Windows 2000/200 /!" is not a #icrokernel5$ased operatin% syste# in the classic definition of #icrokernels, where the principal operatin% syste# co#ponents ,such as the #e#ory #ana%er, process #ana%er, and I/- #ana%er/ run as separate processes in their own pri'ate address spaces, layered on a pri#iti'e set of ser'ices the #icrokernel pro'ides. >or e?a#ple, the 2arne%ie Mellon Eni'ersity Mach operatin% syste#, a conte#porary e?a#ple of a #icrokernel architecture, i#ple#ents a #ini#al kernel that co#prises thread schedulin%, #essa%e passin%, 'irtual #e#ory, and de'ice dri'ers. 6'erythin% else, includin% 'arious &"Is, file syste#s, and networkin%, runs in user #ode. 1owe'er, co##ercial i#ple#entations of the Mach #icrokernel operatin% syste# typically run at least all file syste#, networkin%, and #e#ory #ana%e#ent code in kernel #ode. The reason is si#ple0 the pure #icrokernel desi%n is co##ercially i#practical $ecause it's too inefficient. 8oes the fact that so #uch of Windows 2000/200 /!" runs in kernel #ode #ean that it's #ore suscepti$le to crashes than a true #icrokernel operatin% syste#K Not at all. 2onsider the followin% scenario. .uppose the file syste# code of an operatin% syste# has a $u% that causes it to crash fro# ti#e to ti#e. In a traditional operatin% syste# or a #odified #icrokernel
operatin% syste#, a $u% in kernel5#ode code such as the #e#ory #ana%er or the file syste# would likely crash the entire operatin% syste#. In a pure #icrokernel operatin% syste#, such co#ponents run in user #ode, so theoretically a $u% would si#ply #ean that the co#ponent's process e?its. )ut in practical ter#s, the syste# would crash $ecause reco'erin% fro# the failure of such a critical process would likely $e i#possi$le. &ll these operatin% syste# co#ponents are, of course, fully protected fro# errant applications $ecause applications don't ha'e direct access to the code and data of the pri'ile%ed part of the operatin% syste# ,thou%h they can Buickly call other kernel ser'ices/. This protection is one of the reasons that Windows 2000/200 /!" has the reputation for $ein% $oth ro$ust and sta$le as an application ser'er and as a workstation platfor# yet fast and ni#$le fro# the perspecti'e of core operatin% syste# ser'ices, such as 'irtual #e#ory #ana%e#ent, file I/-, networkin%, and file and print sharin%. The kernel5#ode co#ponents of Windows 2000 also e#$ody $asic o$(ect5oriented desi%n principles. >or e?a#ple, they don't reach into one another's data structures to access infor#ation #aintained $y indi'idual co#ponents. Instead, they use for#al interfaces to pass para#eters and access and/or #odify data structures. 8espite its per'asi'e use of o$(ects to represent shared syste# resources, Windows 2000 is not an o$(ect5oriented syste# in the strict sense. Most of the operatin% syste# code is written in 2 for porta$ility and $ecause 2 de'elop#ent tools are widely a'aila$le. 2 doesn't directly support o$(ect5oriented constructs, such as dyna#ic $indin% of data types, poly#orphic functions, or class inheritance. Therefore, the 25$ased i#ple#entation of o$(ects in Windows 2000 $orrows fro#, $ut doesn't depend on, features of particular o$(ect5oriented lan%ua%es.
Portabilit
Windows 2000 was desi%ned to run on a 'ariety of hardware architectures, includin% Intel5 $ased 2I.2 syste#s as well as ;I.2 syste#s. The initial release of Windows NT supported the ?94 and MI". architecture. .upport for the 8i%ital 6Buip#ent 2orporation ,862/ &lpha &!" was added shortly thereafter. .upport for a fourth processor architecture, the Motorola "ower"2, was added in Windows NT .<+. )ecause of chan%in% #arket de#ands, howe'er, support for the MI". and "ower"2 architectures was dropped $efore de'elop#ent $e%an on Windows 2000. =ater 2o#paB withdrew support for the &lpha &!" architecture, resultin% in Windows 2000 $ein% supported only on the ?94 architecture. NOTE Windows 200 supports the new Intel Itaniu# processor fa#ily, the first i#ple#entation of the 445$it architecture fa#ily was (ointly de'eloped $y Intel and 1ewlett5"ackard and called I&544 ,for Intel &rchitecture 44/. The 445$it 'ersion of Windows will pro'ide a #uch lar%er address space for $oth user processes and the syste#. &lthou%h this is a #a(or enhance#ent that e?tends the scala$ility of the syste# si%nificantly, to date, #o'in% Windows 2000 to a 445$it platfor# hasn't necessitated #a(or chan%es in the kernel architecture of the syste# ,other than the support in the #e#ory #ana%er, of course/.
Windows 2000/200 achie'es porta$ility across hardware architectures and platfor#s in two pri#ary ways0
Windows 2000/200 has a layered desi%n, with low5le'el portions of the syste# that are processor5architecture5specific or platfor#5specific isolated into separate #odules so that upper layers of the syste# can $e shielded fro# the differences $etween +< Copyright 2000-2007, Microsoft Corporation
architectures and a#on% hardware platfor#s. The two key co#ponents that pro'ide operatin% syste# porta$ility are the kernel ,contained in Ntoskrnl.e?e/ and the hardware a$straction layer ,contained in 1al.dll/. ,)oth these co#ponents are descri$ed in #ore detail later in this chapter./ >unctions that are architecture5specific ,such as thread conte?t switchin% and trap dispatchin%/ are i#ple#ented in the kernel. >unctions that can differ a#on% syste#s within the sa#e architecture ,for e?a#ple, different #other$oards/ are i#ple#ented in the 1&=.
The 'ast #a(ority of Windows 2000/200 is written in 2, with so#e portions in 2LL. &sse#$ly lan%ua%e is used only for those parts of the operatin% syste# that need to co##unicate directly with syste# hardware ,such as the interrupt trap handler/ or that are e?tre#ely perfor#ance5sensiti'e ,such as conte?t switchin%/. &sse#$ly lan%ua%e code e?ists not only in the kernel and the 1&= $ut also in a few other places within the core operatin% syste# ,such as the routines that i#ple#ent interlocked instructions as well as one #odule in the local procedure call facility/, in the kernel5 #ode part of the Win 2 su$syste#, and e'en in so#e user5#ode li$raries, such as the process startup code in Ntdll.dll ,a syste# li$rary e?plained later in this chapter/.
S mmetric Multi*rocessin$
Multitas&ing is the operatin% syste# techniBue for sharin% a sin%le processor a#on% #ultiple threads of e?ecution. When a co#puter has #ore than one processor, howe'er, it can e?ecute two threads si#ultaneously. Thus, whereas a #ultitaskin% operatin% syste# only appears to e?ecute #ultiple threads at the sa#e ti#e, a #ultiprocessin% operatin% syste# actually does it, e?ecutin% one thread on each of its processors. &s #entioned at the $e%innin% of this chapter, one of the key desi%n %oals for Windows NT was that it had to run well on #ultiprocessor co#puter syste#s. Windows 2000 is also a s mmetric multiprocessing ,.M"/ operatin% syste#. There is no #aster processor*the operatin% syste# as well as user threads can $e scheduled to run on any processor. &lso, all the processors share (ust one #e#ory space. This #odel contrasts with as mmetric multiprocessing ,&.M"/, in which the operatin% syste# typically selects one processor to e?ecute operatin% syste# code while other processors run only user code. The differences in the two #ultiprocessin% #odels are illustrated in >i%ure +5<.
F);'$+ 18@ - mmetric vs, as mmetric multiprocessing &lthou%h Windows NT/2000/200 was ori%inally desi%ned to support up to 2 processors, nothin% inherent in the #ultiprocessor desi%n li#its the nu#$er of processors to 2*that nu#$er is si#ply an o$'ious and con'enient li#it $ecause 2 processors can easily $e represented as a $it #ask usin% a nati'e 25$it data type. The actual nu#$er of supported processors depends on the edition of Windows 2000/200 $ein% used. This nu#$er is stored in the re%istry 'alue 1F=MM.A.T6MM2urrent2ontrol.etM 2ontrolM.essionMMana%erM=icensed "rocessors. Feep in #ind that ta#perin% with that data is a 'iolation of the software license and will likely result in a syste# crash upon re$ootin% $ecause #odifyin% the re%istry to allow use of #ore processors in'ol'es #ore than (ust chan%in% this 'alue.
Scalabilit
-ne of the key issues with #ultiprocessor syste#s is scala"ilit . To run correctly on an .M" syste#, operatin% syste# code #ust adhere to strict %uidelines and rules. ;esource contention and other perfor#ance issues are #ore co#plicated in #ultiprocessin% syste#s than in uniprocessor syste#s and #ust $e accounted for in the syste#'s desi%n. Windows 2000 incorporates se'eral features that are crucial to its success as a #ultiprocessor operatin% syste#0

The a$ility to run operatin% syste# code on any a'aila$le processor and on #ultiple processors at the sa#e ti#e Multiple threads of e?ecution within a sin%le process, each of which can e?ecute si#ultaneously on different processors
+G Copyright 2000-2007, Microsoft Corporation
>ine5%rained synchroni7ation within the kernel as well as within de'ice dri'ers and ser'er processes, which allows #ore co#ponents to run concurrently on #ultiple processors
In addition, Windows 2000 pro'ides #echanis#s ,such as I/- co#pletion ports/ that facilitate the efficient i#ple#entation of #ultithreaded ser'er processes that can scale well on #ultiprocessor syste#s.
A$(*)#+(#'$+ O4+$4)+,
With this $rief o'er'iew of the desi%n %oals and packa%in% of Windows 2000/200 /!", we can now take a look at the key syste# co#ponents that co#prise its architecture. & si#plified 'ersion of this architecture is shown in >i%ure +54. Feep in #ind that this dia%ra# is $asic*it doesn't show e'erythin%. The 'arious co#ponents of Windows 2000 are co'ered in detail later in this chapter.
F);'$+ 184 -impli!ied %indo's ()).())/ architecture In >i%ure +54 first notice the line di'idin% the user5#ode and kernel5#ode parts of the Windows 2000/200 operatin% syste#. The $o?es a$o'e the line represent user5#ode processes, and the co#ponents $elow the line are kernel5#ode operatin% syste# ser'ices. &s #entioned earlier, user5#ode threads e?ecute in a protected process address space ,althou%h while they are e?ecutin% in kernel #ode, they ha'e access to syste# space/. Thus, syste# support processes, ser'ice processes, user applications, and en'iron#ent su$syste#s each ha'e their own pri'ate process address space. The four $asic types of user5#ode processes are descri$ed as follows0
>i?ed ,or hardwired/ s stem support processes, such as the lo%on process and the session #ana%er, that are not Windows 2000/200 /!" ser'ices ,that is, not started $y the ser'ice control #ana%er/. -ervice processes that host Win 2 ser'ices, such as the Task .cheduler and .pooler ser'ices. Many Windows 2000/200 ser'er applications, such as Microsoft .@= .er'er and Microsoft 6?chan%e .er'er, also include co#ponents that run as ser'ices. 0ser applications, which can $e one of fi'e types0 Win 2, Windows .+, M.58-., "-.I!, or -./2 +.2. Environment su"s stems, which e?pose the nati'e operatin% syste# ser'ices to user applications throu%h a set of calla$le functions, thus pro'idin% an operatin% syste# +9 Copyright 2000-2007, Microsoft Corporation
environment, or personality. Windows 2000 ships with three en'iron#ent su$syste#s0 Win 2, "-.I!, and -./2. In >i%ure +54, notice the D.u$syste# 8==sD $o? $elow the D.er'ice processesD and DEser applicationsD $o?es. Ender Windows 2000/200 /!", user applications don't call the nati'e Windows 2000/200 /!" operatin% syste# ser'ices directlyI rather, they %o throu%h one or #ore su"s stem d namic*lin& li"raries ,8==s/. The role of the su$syste# 8==s is to translate a docu#ented function into the appropriate internal ,and undocu#ented/ Windows 2000 syste# ser'ice calls. This translation #i%ht or #i%ht not in'ol'e sendin% a #essa%e to the en'iron#ent su$syste# process that is ser'in% the user application. The kernel5#ode co#ponents of Windows 2000/200 /!" include the followin%0
The Windows 2000/200 /!" executive contains the $ase operatin% syste# ser'ices, such as #e#ory #ana%e#ent, process and thread #ana%e#ent, security, I/-, and interprocess co##unication. The Windows 2000/200 /!" &ernel consists of low5le'el operatin% syste# functions, such as thread schedulin%, interrupt and e?ception dispatchin%, and #ultiprocessor synchroni7ation. It also pro'ides a set of routines and $asic o$(ects that the rest of the e?ecuti'e uses to i#ple#ent hi%her5le'el constructs. Device drivers include $oth hardware de'ice dri'ers that translate user I/- function calls into specific hardware de'ice I/- reBuests as well as file syste# and network dri'ers. The hard'are a"straction la er ,1&=/ is a layer of code that isolates the kernel, de'ice dri'ers, and the rest of the Windows 2000/200 /!" e?ecuti'e fro# platfor#5 specific hardware differences ,such as differences $etween #other$oards/. The 'indo'ing and graphics s stem i#ple#ents the %raphical user interface ,:EI/ functions ,$etter known as the Win 2 E.6; and :8I functions/, such as dealin% with windows, user interface controls, and drawin%.
T.:0+ 182 Core %indo's ())).())/.1P - stem Files F)0+"./+ Ntoskrnl.e?e Ntkrnlpa.e?e 1al.dll Win 2k.sys Ntdll.dll 6?ecuti'e and kernel 6?ecuti'e and kernel with support for "hysical &ddress 6?tension ,"&6/, which allows addressin% of up to 44 :) of physical #e#ory 1ardware a$straction layer Fernel5#ode part of the Win 2 su$syste# Internal support functions and syste# ser'ice dispatch stu$s to e?ecuti'e functions C%/2%"+"#-
Fernel 2.dll, 2ore Win 2 su$syste# 8==s &d'api 2.dll, Eser 2.dll, :di 2.dll Ta$le +52 lists the filena#es of the core Windows 2000/200 /!" operatin% syste# co#ponents. ,Aou'll need to know these filena#es $ecause we'll $e referrin% to so#e syste# files $y na#e./ 6ach of these co#ponents is co'ered in %reater detail $oth later in this chapter and in the chapters that follow. )efore we di% into the details of these syste# co#ponents,
+C Copyright 2000-2007, Microsoft Corporation
thou%h, let's e?a#ine the differences $etween Windows 2000/!" "rofessional and the 'arious editions of Windows 2000/200 .er'er.
W)"&%,- 2000/2003/ P P$%&'(# P.(9.;)";

There are se'eral editions of Windows 2000/200 , as descri$ed earlier. These editions differ $y0

The nu#$er of processors supported The a#ount of physical #e#ory supported The nu#$er of concurrent network connections supported =ayered ser'ices that co#e with .er'er editions that don't co#e with the "rofessional edition, and so on.
What is not different $etween the 'arious fla'ors of Windows 2000/200 /!" are the core syste# files0 the kernel i#a%e, Ntoskrnl.e?e ,and the "&6 'ersion, Ntkrnlpa.e?e/I the 1&= li$rariesI the de'ice dri'ersI and the $ase syste# utilities and 8==s. &ll these files are the sa#e for all editions of Windows 2000/200 /!". >or e?a#ple, there are no special ser'er 'ersions of the 1&=. 1owe'er, a nu#$er of these co#ponents operate differently dependin% on which edition is runnin%. Windows 2000/200 .er'er syste#s are opti#i7ed for syste# throu%hput as hi%h5 perfor#ance application ser'ers, whereas Windows 2000/200 /!" "rofessional, althou%h it has ser'er capa$ilities, is opti#i7ed for response ti#e for interacti'e desktop use. >or e?a#ple, $ased on the product type, se'eral resource allocation decisions are #ade differently at syste# $oot ti#e, such as the si7e and nu#$er of operatin% syste# heaps ,or pools/, the nu#$er of internal syste# worker threads, and the si7e of the syste# data cache. &lso, run5 ti#e policy decisions, such as the way the #e#ory #ana%er trades off syste# and process #e#ory de#ands, differ $etween the Windows 2000/200 /!" .er'er editions and Windows 2000/200 /!" "rofessional. 6'en so#e thread5schedulin% details ha'e different default $eha'ior in the two edition fa#ilies. Where there are si%nificant operational differences in the two products, these are hi%hli%hted in the pertinent chapters throu%hout the rest of this lecture series. Enless otherwise noted, e'erythin% in this lecture series applies to $oth the Windows 2000/200 /!" .er'er editions as well as Windows 2000/200 /!" "rofessional. If the kernel i#a%e is the sa#e across the 'arious product editions of Windows 2000/200 /!" ,how does the syste# know which edition is $ootedK )y Bueryin% the re%istry 'alues "roductType and "roduct.uite under the 1F=MM.A.T6MM2urrent2ontrol.et M2ontrolM"roduct-ptions key. "roductType is used to distin%uish whether the syste# is a Windows 2000/!" "rofessional or a Windows 2000/200 .er'er syste# ,any edition/. The result is stored in the syste# %lo$al 'aria$le MmProductT pe, which can $e Bueried fro# a de'ice dri'er usin% the kernel5#ode support function MmIsThisAnNtAs- stem, docu#ented in the Windows 2000/200 /!" 88F. & different re%istry 'alue, "roduct.uite, distin%uishes Windows 2000/200 .er'er, 6nterprise .er'er, and 8atacenter .er'er as well as whether Ter#inal .er'ices ha'e $een installed ,.er'er syste#s only/. -n Windows 2000/200 /!" "rofessional syste#s, this 'alue is $lank. If user pro%ra#s need to deter#ine which edition of Windows 2000/200 /!" is runnin%, they can call the Win 2 2eri! 2ersionIn!o function, docu#ented in the "latfor# .8F. 8e'ice dri'ers can call the kernel5#ode function $tlGet2ersion, docu#ented in the Windows 2000/200 /!" 88F.
+hec,ed -uild
There is a special de$u% 'ersion of Windows called the chec&ed "uild. This 'ersion is a'aila$le only with the M.8N "rofessional ,or Eni'ersal/ 28 su$scription. It is pro'ided to aid de'ice dri'er de'elopers*the checked $uild perfor#s #ore strin%ent error checkin% on kernel5#ode functions called $y de'ice dri'ers or other syste# code. >or e?a#ple, if a dri'er ,or so#e other piece of kernel5#ode code/ #akes an in'alid call to a syste# function that is checkin% para#eters ,such as acBuirin% a spinlock at the wron% interrupt le'el/, the syste# will stop e?ecution when the pro$le# is detected rather than allow so#e data structure to $e corrupted and the syste# to possi$ly crash at a later ti#e. The checked $uild is a reco#pilation of the Windows 2000/200 /!" source code with the co#pile5ti#e fla% 86)E: set to T;E6. Much of the additional code in the checked5$uild $inaries is a result of usin% the &..6;T #acro, which is defined in the 88F header file Ntddk.h and docu#ented in the 88F docu#entation. This #acro tests a condition ,such as the 'alidity of a data structure or para#eter/, and if the e?pression e'aluates to >&=.6, the #acro calls the kernel5#ode function $tlAssert, which calls D"gPrint to pass the te?t of the de$u% #essa%e to a kernel de$u%%er ,if one is attached/ to $e displayed and then pro#pts the user for what to do ,$reakpoint, i%nore, ter#inate process, or ter#inate thread/. If the syste# wasn't $ooted with the kernel de$u%%er ,usin% the /86)E: switch in )oot.ini/ and no kernel de$u%%er is currently attached, failure of an &..6;T test will crash the syste#. &lthou%h Microsoft doesn't supply a checked5$uild 'ersion of Windows 2000/200 /!" .er'er, &d'anced .er'er, or 8atacenter .er'er, you can #anually copy the checked ,de$u%/ 'ersion of the kernel i#a%e onto a Windows 2000/200 /!" .er'er syste#, re$oot, and run with a checked kernel. ,Aou could also do this for other syste# files, $ut #ost de'elopers who use the checked $uild really only need the checked 'ersion of the kernel i#a%e*not the checked 'ersions of e'ery de'ice dri'er, utility, and 8==./
Multi*rocessor.S*eci%ic S stem Files

.i? syste# filesN are different on a #ultiprocessor syste# than on a uniprocessor syste#. ,.ee Ta$le +5 ./ &t installation ti#e, the appropriate file is selected and copied to the local MWinntM.yste# 2 directory. To deter#ine which files were copied, see the file MWinntM;epairM.etup.lo%, which ite#i7es all the files that were copied to the local syste# disk and where they ca#e fro# off the distri$ution #edia. T.:0+ 183 Multiprocessor*-peci!ic vs, 0niprocessor*-peci!ic - stem Files N./+ %3 F)0+ %" S1-#+/ D)-9 Ntoskrnl.e?e Ntkrnlpa.e?e 1al.dll Win 2k.sys Ntdll.dll Fernel 2.dll N./+ %3 U")2$%(+--%$ V+$-)%" %" CD MI 94MNtoskrnl.e?e Ntkrnlpa.e?e in MI 94M8ri'er.ca$ 8epends on syste# type MI 94MENI";-2MWin 2k.sys MI 94MENI";-2MNtdll.dll MI 94MENI";-2MFernel 2.dll N./+ %3 M'0#)2$%(+--%$ V+$-)%" %" CD MI 94MNtkrnl#p.e?e Ntkrpa#p.e?e MI 94M8ri'er.ca$ 8epends on syste# type Win 2k.sys MI 94M8ri'er.ca$ MI 94MNtdll.dll MI 94MFernel 2.dll in in
2+ Copyright 2000-2007, Microsoft Corporation
The reason for ha'in% uniprocessor 'ersions of these key syste# files is perfor#ance* #ultiprocessor synchroni7ation is inherently #ore co#ple? and ti#e consu#in% than the use of a sin%le processor, so $y ha'in% special uniprocessor 'ersions of the key syste# files, this o'erhead is a'oided on uniprocessor syste#s ,which constitute the 'ast #a(ority of syste#s runnin% Windows 2000/200 /!" /. Interestin%ly, althou%h the uniprocessor and #ultiprocessor 'ersions of Ntoskrnl are %enerated usin% conditionally co#piled source code, the uniprocessor 'ersions of Ntdll.dll and Fernel 2.dll are created $y patchin% the ?94 =-2F and EN=-2F instructions, which are used to synchroni7e #ultiple threads with no5operation ,N-"/ instructions ,which do nothin%/. The rest of the syste# files that co#prise Windows 2000/200 /!" ,includin% all utilities, li$raries, and de'ice dri'ers/ ha'e the sa#e 'ersion on $oth uniprocessor and #ultiprocessor syste#s ,that is, they handle #ultiprocessor synchroni7ation issues correctly/. Aou should use this approach on any software you $uild, whether it is a Win 2 application or a de'ice dri'er *keep #ultiprocessor synchroni7ation issues in #ind when you desi%n your software, and test the software on $oth uniprocessor and #ultiprocessor syste#s. -n the checked $uild 28, if you co#pare Ntoskrnl.e?e and Ntkrnl#p.e?e or Ntkrnlpa.e?e and Ntkrpa#p.e?e, you'll find that they are identical*they are all #ultiprocessor 'ersions of the sa#e files. In other words, there is no de$u% uniprocessor 'ersion of the kernel i#a%es pro'ided with the checked $uild.
!+1 S1-#+/ C%/2%"+"#Now that we''e looked at the hi%h5le'el architecture of Windows 2000/200 /!" , let's del'e deeper into the internal structure and the role each of the key operatin% syste# co#ponents plays. >i%ure +5G is a #ore detailed and co#plete dia%ra# of the Windows 2000/200 /!" syste# architecture and co#ponents than was shown earlier in the chapter ,in >i%ure +5G/.
The %ollo/in$ sections elaborate on each ma(or element o% this dia$ram" 0nvironment Subs stems and Subs stem 122s
&s shown in >i%ure +5G, Windows 2000/200 /!" has three en'iron#ent su$syste#s0 -./2, "-.I!, and Win 2. &s we'll e?plain shortly, of the three, the Win 2 su$syste# is special in that Windows 2000/200 /!" can't run without it. ,It owns the key$oard, #ouse, and display, and it is reBuired to $e present e'en on ser'er syste#s with no interacti'e users lo%%ed in./ In fact, the other two su$syste#s are confi%ured to start on de#and, whereas the Win 2 su$syste# #ust always $e runnin%. The su$syste# startup infor#ation is stored under the re%istry key 1F=MM.A.T6MM2urrent2ontrol.etM2ontrolM.ession Mana%erM.u$.yste#s. >i%ure +59 shows the 'alues under this key.
F);'$+ 18A %indo's ())).())/.1P architecture
F);'$+ 188 $egistr Editor sho'ing %indo's ())).())/.1P startup in!ormation The ;eBuired 'alue lists the su$syste#s that load when the syste# $oots. The 'alue has two strin%s0 Windows and 8e$u%. The Windows 'alue contains the file specification of the Win 2 su$syste#, 2srss.e?e, which stands for 2lient/.er'er ;un5Ti#e .u$syste#. 8e$u% is $lank ,it's used for internal testin%/ and therefore does nothin%. The -ptional 'alue indicates that the -./2 and "-.I! su$syste#s will $e started on de#and. The re%istry 'alue F#ode contains
the filena#e of the kernel5#ode portion of the Win 2 su$syste#, Win 2k.sys ,e?plained later in this chapter/. The role of an en'iron#ent su$syste# is to e?pose so#e su$set of the $ase Windows 2000/200 /!" e?ecuti'e syste# ser'ices to application pro%ra#s. 6ach su$syste# can pro'ide access to different su$sets of the nati'e ser'ices in Windows 2000/200 /!". That #eans that so#e thin%s can $e done fro# an application $uilt on one su$syste# that can't $e done $y an application $uilt on another su$syste#. >or e?a#ple, a Win 2 application can't use the "-.I! !or& function. 6ach e?ecuta$le i#a%e ,.e?e/ is $ound to one and only one su$syste#. When an i#a%e is run, the process creation code e?a#ines the su$syste# type code in the i#a%e header so that it can notify the proper su$syste# of the new process. This type code is specified with the /.E).A.T6M Bualifier of the lin& co##and in Microsoft 3isual 2LL and can $e 'iewed with the 6?etype tool in the Windows 2000/200 /!" resource kits. >unction calls can't $e #i?ed $etween su$syste#s. In other words, a "-.I! application can call only ser'ices e?ported $y the "-.I! su$syste#, and a Win 2 application can call only ser'ices e?ported $y the Win 2 su$syste#. &s you'll see later, this restriction is the reason that the "-.I! su$syste#, which i#ple#ents a 'ery li#ited set of functions ,only "-.I! +00 .+/, isn't a useful en'iron#ent for portin% ENI! applications. &s #entioned earlier, user applications don't call Windows 2000/200 /!" syste# ser'ices directly. Instead, they %o throu%h one or #ore su$syste# 8==s. These li$raries e?port the docu#ented interface that the pro%ra#s linked to that su$syste# can call. >or e?a#ple, the Win 2 su$syste# 8==s ,such as Fernel 2.dll, &d'api 2.dll, Eser 2.dll, and :di 2.dll/ i#ple#ent the Win 2 &"I functions. The "-.I! su$syste# 8== i#ple#ents the "-.I! +00 .+ &"I. When an application calls a function in a su$syste# 8==, one of three thin%s can occur0
The function is entirely i#ple#ented in user #ode inside the su$syste# 8==. In other words, no #essa%e is sent to the en'iron#ent su$syste# process, and no Windows 2000/200 /!" e?ecuti'e syste# ser'ices are called. The function is perfor#ed in user #ode, and the results are returned to the caller. 6?a#ples of such functions include GetCurrentProcess ,which always returns 5+, a 'alue that is defined to refer to the current process in all process5related functions/ and GetCurrentProcessId ,the process I8 doesn't chan%e for a runnin% process, so this I8 is retrie'ed fro# a cached location, thus a'oidin% the need to call into the kernel/. The function reBuires one or #ore calls to the Windows 2000/200 /!" e?ecuti'e. >or e?a#ple, the Win 2 $eadFile and %riteFile functions in'ol'e callin% the underlyin% internal ,and undocu#ented/ Windows 2000/200 /!" I/- syste# ser'ices Nt$eadFile and Nt%riteFile, respecti'ely. The function reBuires so#e work to $e done in the en'iron#ent su$syste# process. ,The en'iron#ent su$syste# processes, runnin% in user #ode, are responsi$le for #aintainin% the state of the client applications runnin% under their control./ In this case, a client/ser'er reBuest is #ade to the en'iron#ent su$syste# 'ia a #essa%e sent to the su$syste# to perfor# so#e operation. The su$syste# 8== then waits for a reply $efore returnin% to the caller.
.o#e functions can $e a co#$ination of the second and third ite#s a$o'e, such as the Win 2 CreateProcess and CreateThread functions.
&lthou%h Windows 2000/200 /!" was desi%ned to support #ultiple, independent en'iron#ent su$syste#s, fro# a practical perspecti'e, ha'in% each su$syste# i#ple#ent all the code to handle windowin% and display I/- would result in a lar%e a#ount of duplication of syste# functions that, ulti#ately, would ha'e ne%ati'ely affected $oth syste# si7e and perfor#ance. )ecause Win 2 was the pri#ary su$syste#, the Windows 2000/200 /!" desi%ners decided to locate these $asic functions there and ha'e the other su$syste#s call on the Win 2 su$syste# to perfor# display I/-. Thus, the "-.I! and -./2 su$syste#s call ser'ices in the Win 2 su$syste# to perfor# display I/-. ,In fact, if you e?a#ine the su$syste# type for these i#a%es, you'll see that they are Win 2 e?ecuta$les./ =et's take a closer look at each of the en'iron#ent su$syste#s.
Win32 Subsystem
The Win 2 su$syste# consists of the followin% #a(or co#ponents0
The en'iron#ent su$syste# process ,2srss.e?e/ contains support for0 o 2onsole ,te?t/ windows o 2reatin% and deletin% processes and threads o "ortions of the support for +45$it 'irtual 8-. #achine ,38M/ processes o -ther #iscellaneous functions, such as GetTempFile, De!ineDosDevice, Exit%indo'sEx, and se'eral natural lan%ua%e support functions The kernel5#ode de'ice dri'er ,Win 2k.sys/ contains0 The window #ana%er, which controls window displaysI #ana%es screen outputI collects input fro# key$oard, #ouse, and other de'icesI and passes user #essa%es to applications. o The :raphics 8e'ice Interface ,:8I/, which is a li$rary of functions for %raphics output de'ices. It includes functions for line, te?t, and fi%ure drawin% and for %raphics #anipulation. .u$syste# 8==s ,such as Fernel 2.dll, &d'api 2.dll, Eser 2.dll, and :di 2.dll/ translate docu#ented Win 2 &"I functions into the appropriate undocu#ented kernel5#ode syste# ser'ice calls to Ntoskrnl.e?e and Win 2k.sys. :raphics de'ice dri'ers are hardware5dependent %raphics display dri'ers, printer dri'ers, and 'ideo #iniport dri'ers.
o
&pplications call the standard E.6; functions to create user interface controls, such as windows and $uttons, on the display. The window #ana%er co##unicates these reBuests to the :8I, which passes the# to the %raphics de'ice dri'ers, where they are for#atted for the display de'ice. & display dri'er is paired with a 'ideo #iniport dri'er to co#plete 'ideo display support. The :8I pro'ides a set of standard two5di#ensional functions that let applications co##unicate with %raphics de'ices without knowin% anythin% a$out the de'ices. :8I functions #ediate $etween applications and %raphics de'ices such as display dri'ers and printer dri'ers. The :8I interprets application reBuests for %raphic output and sends the reBuests to %raphics display dri'ers. It also pro'ides a standard interface for applications to use 'aryin% %raphics output de'ices. This interface ena$les application code to $e independent of the hardware de'ices and their dri'ers. The :8I tailors its #essa%es to the capa$ilities of the de'ice, often di'idin% the reBuest into #ana%ea$le parts. >or e?a#ple, so#e de'ices can understand directions to draw an ellipseI others reBuire the :8I to interpret the co##and as a series of pi?els placed at certain coordinates. >or #ore infor#ation a$out
2< Copyright 2000-2007, Microsoft Corporation
the %raphics and 'ideo dri'er architecture, see the Design Guide section of the lecture series Graphics Drivers in the Windows 2000/200 /!" 88F. "rior to Windows NT 4, the window #ana%er and %raphics ser'ices were part of the user5 #ode Win 2 su$syste# process. In Windows NT 4, the $ulk of the windowin% and %raphics code was #o'ed fro# runnin% in the conte?t of the Win 2 su$syste# process to a set of calla$le ser'ices runnin% in kernel #ode ,in the file Win 2k.sys/. The pri#ary reason for this shift was to i#pro'e o'erall syste# perfor#ance. 1a'in% a separate ser'er process that contains the Win 2 %raphics su$syste# reBuired #ultiple thread and process conte?t switches, which consu#ed considera$le 2"E cycles and #e#ory resources e'en thou%h the ori%inal desi%n was hi%hly opti#i7ed. >or e?a#ple, for each thread on the client side there was a dedicated, paired ser'er thread in the Win 2 su$syste# process waitin% on the client thread for reBuests. & special interprocess co##unication facility called !ast 3PC was used to send #essa%es $etween these threads. Enlike nor#al thread conte?t switches, transitions $etween paired threads 'ia fast ="2 don't cause a reschedulin% e'ent in the kernel, there$y ena$lin% the ser'er thread to run for the re#ainin% ti#e slice of the client thread $efore ha'in% to take its turn in the kernel's pree#pti'e thread scheduler. Moreo'er, shared #e#ory $uffers were used to allow fast passin% of lar%e data structures, such as $it#aps, and clients had direct $ut read5only access to key ser'er data structures to #ini#i7e the need for thread/process transitions $etween clients and the Win 2 ser'er. &lso, :8I operations were ,and still are/ $atched. 4atching #eans that a series of %raphics calls $y a Win 2 application aren't DpushedD o'er to the ser'er and drawn on the output de'ice until a :8I $atchin% Bueue is filled. Aou can set the si7e of the Bueue $y usin% the Win 2 Gdi-et4atch3imit function, and you can flush the Bueue at any ti#e with GdiFlush. 2on'ersely, read5only properties and data structures of :8I, once they were o$tained fro# the Win 2 su$syste# process, were cached on the client side for fast su$seBuent access. 8espite these opti#i7ations, howe'er, the o'erall syste# perfor#ance was still not adeBuate for %raphics5intensi'e applications. The o$'ious solution was to eli#inate the need for the additional threads and resultin% conte?t switches $y #o'in% the windowin% and %raphics syste# into kernel #ode. &lso, once applications ha'e called into the window #ana%er and the :8I, those su$syste#s can access other Windows 2000/200 /!" e?ecuti'e co#ponents directly without the cost of user5#ode or kernel5#ode transitions. This direct access is especially i#portant in the case of the :8I callin% throu%h 'ideo dri'ers, a process that in'ol'es interaction with 'ideo hardware at hi%h freBuencies and hi%h $andwidths.
Is Windows 2000/2003/XP Less Stable wit Win32 !S"# and $%I in &e'nel (ode)
.o#e people wondered whether #o'in% this #uch code into kernel #ode would su$stantially affect syste# sta$ility. The reason the i#pact on syste# sta$ility has $een #ini#al is that prior to Windows NT 4 ,and this is still true today/, a $u% ,such as an access 'iolation/ in the user5#ode Win 2 su$syste# process ,2srss.e?e/ resulted in a syste# crash. This crash occurs $ecause the parent process of 2srss ,the session #ana%er, .#ss, which is descri$ed in the section D.ession Mana%er ,.#ss/D/ does a wait operation on the process handle to 2srss, and if the wait e'er returns, .#ss crashes the syste#*$ecause the Win 2 su$syste# process was ,and still is/ a 'ital process to the runnin% of the syste#. )ecause it was the process that contained the data structures that descri$ed the windows on the display, the death of that process would kill the user interface. 1owe'er, e'en a Windows 2000/200 /!" syste# operatin% as a ser'er, with no interacti'e processes, can't run without this process, since ser'er processes #i%ht $e usin% window #essa%in% to dri'e the internal state of the application. With Windows 2000/200 /!" , an access 'iolation in the sa#e code now runnin%
in kernel #ode si#ply crashes the syste# #ore Buickly, since e?ceptions in kernel #ode result in a syste# crash. There is, howe'er, one additional theoretical dan%er that didn't e?ist prior to #o'in% the windowin% and %raphics syste# into kernel #ode. )ecause this $ody of code is now runnin% in kernel #ode, a $u% ,such as the use of a $ad pointer/ could result in corruptin% kernel5 #ode protected data structures. "rior to Windows NT 4, such references would ha'e caused an access 'iolation $ecause kernel5#ode pa%es aren't writa$le fro# user #ode. )ut a syste# crash would ha'e then resulted, as descri$ed earlier. With the code now runnin% in kernel #ode, a $ad pointer reference that caused a write operation to so#e kernel5#ode pa%e #i%ht not i##ediately cause a syste# crash, $ut if it corrupted so#e data structure, a crash would likely result soon after. There is a s#all chance, howe'er, that such a reference could corrupt a #e#ory $uffer ,rather than a data structure/, possi$ly resultin% in returnin% corrupt data to a user pro%ra# or writin% $ad data to the disk. &nother area of possi$le i#pact can co#e fro# the #o'e of the %raphics dri'ers into kernel #ode. "re'iously, so#e portions of a %raphics dri'er ran within 2srss, and others ran in kernel #ode. Now, the entire dri'er runs in kernel #ode. &lthou%h Microsoft doesn't de'elop all of the %raphics de'ice dri'ers supported in Windows 2000/200 /!", it does work directly with hardware #anufacturers to help ensure that they are a$le to produce relia$le and efficient dri'ers. &ll dri'ers shipped with the syste# are su$#itted to the sa#e ri%orous testin% as other e?ecuti'e co#ponents. >inally, it's i#portant to understand that this desi%n ,runnin% the windowin% and %raphics su$syste# in kernel #ode/ is not funda#entally risky. It is identical to the approaches #any other de'ice dri'ers use ,for e?a#ple, network card dri'ers and hard disk dri'ers/. &ll these dri'ers ha'e $een operatin% in kernel #ode since the inception of Windows NT with a hi%h de%ree of relia$ility. .o#e people speculated that the #o'e of the window #ana%er and the :8I into kernel #ode would hurt the pree#pti'e #ultitaskin% capa$ility of Windows 2000/200 /!" . The theory was that with all the additional Win 2 processin% ti#e spent in kernel #ode, other threads would ha'e less opportunity to $e run pree#pti'ely. This 'iew was $ased on a #isunderstandin% of the Windows 2000/200 /!" architecture. It is true that in #any other no#inally pree#pti'e operatin% syste#s, e?ecutin% in kernel #ode is ne'er pree#pted $y the operatin% syste# scheduler*or is pree#pted only at a certain li#ited nu#$er of predefined points of kernel reentrancy. In Windows 2000/200 /!", howe'er, threads runnin% anywhere in the e?ecuti'e are pree#pted and scheduled alon%side threads runnin% in user #ode, and all code within the e?ecuti'e is fully reentrant. &#on% other reasons, this capa$ility is necessary to achie'e a hi%h de%ree of syste# scala$ility on .M" hardware. &nother line of speculation was that .M" scalin% would $e hurt $y this chan%e. The theory went like this0 "re'iously, an interaction $etween an application and the window #ana%er or the :8I in'ol'ed two threads, one in the application and one in 2srss.e?e. Therefore, on an .M" syste#, the two threads could run in parallel, thus i#pro'in% throu%hput. This analysis shows a #isunderstandin% of how Windows NT technolo%y worked prior to Windows NT 4. In #ost cases, calls fro# a client application to the Win 2 su$syste# process run synchronouslyI that is, the client thread entirely $locks waitin% on the ser'er thread and $e%ins to run a%ain only when the ser'er thread has co#pleted the call. Therefore, no parallelis# on .M" hardware can e'er $e achie'ed. This pheno#enon is easily o$ser'a$le with a $usy %raphics application usin% the "erfor#ance tool on an .M" syste#. The o$ser'er will disco'er that on a two5processor syste# each processor is appro?i#ately <0 percent loaded, and it's relati'ely easy to find the sin%le 2srss thread that is paired off with the $usy application thread. Indeed, $ecause the two threads are fairly inti#ate with each other and
2G Copyright 2000-2007, Microsoft Corporation
sharin% state, the processors' caches #ust $e flushed constantly to #aintain coherency. This constant flushin% is the reason that with Windows NT .<+ a sin%le5threaded %raphics application typically runs sli%htly slower on an .M" #achine than on a sin%le processor syste#. &s a result, the chan%es in Windows NT 4 increased .M" throu%hput of applications that #ake hea'y use of the window #ana%er and the :8I, especially when #ore than one application thread is $usy. When two application threads are $usy on a two5processor Windows NT .<+5$ased #achine, a total of four threads ,two in the application plus two in 2srss/ are $attlin% for ti#e on the two processors. &lthou%h only two are typically ready to run at any %i'en ti#e, the lack of a consistent pattern in which threads run results in a loss of locality of reference and cache coherency. This loss occurs $ecause the $usy threads are likely to %et shuffled fro# one processor to another. In the Windows NT 4 desi%n, each of the two application threads essentially has its own processor, and the auto#atic thread affinity of Windows 2000/200 /!" tends to run the sa#e thread on the sa#e processor indefinitely, thus #a?i#i7in% locality of reference and #ini#i7in% the need to synchroni7e the pri'ate per5 processor #e#ory caches. .o in su##ary, #o'in% the window #ana%er and the :8I fro# user #ode to kernel #ode has pro'ided i#pro'ed perfor#ance without any si%nificant decrease in syste# sta$ility or relia$ility.
Win32 Subsystem !se'*mode P'ocesses

.o, what re#ains in the user5#ode process part of the Win 2 su$syste#K &ll the drawin% and updatin% for console or te?t windows are handled $y it, since console applications ha'e no notion of repaintin% a window. It's easy to see this acti'ity*si#ply open a co##and pro#pt and dra% another window o'er it, and you'll see the Win 2 su$syste# process runnin% like cra7y as it repaints the console window. )ut other than console window support, only a few Win 2 functions result in sendin% a #essa%e to the Win 2 su$syste# process any#ore0 process and thread creation and ter#ination, network dri'e letter #appin%, and creation of te#porary files. In %eneral, a runnin% Win 2 application won't $e causin% #any, if any, conte?t switches to the Win 2 su$syste# process.
POSIX Subsystem
"-.I!, an acrony# loosely defined as Da porta$le operatin% syste# interface $ased on ENI!,D refers to a collection of international standards for ENI!5style operatin% syste# interfaces. The "-.I! standards encoura%e 'endors i#ple#entin% ENI!5style interfaces to #ake the# co#pati$le so that pro%ra##ers can #o'e their applications easily fro# one syste# to another. Windows 2000/200 i#ple#ents only one of the #any "-.I! standards, "-.I!.+, for#ally known as I.-/I62 CC4<5+0+CC0 or I666 "-.I! standard +00 .+5+CC0. This standard was included pri#arily to #eet E... %o'ern#ent procure#ent reBuire#ents set in the #id5to5late +C90s that #andated "-.I!.+ co#pliance as specified in >ederal Infor#ation "rocessin% .tandard ,>I"./ +<+52, de'eloped $y the National Institute of .tandards and Technolo%y. Windows NT .<, .<+, and 4 ha'e $een for#ally tested and certified accordin% to >I". +<+5 2. )ecause "-.I!.+ co#pliance was a #andatory %oal for Windows 2000/200 , the operatin% syste# was desi%ned to ensure that the reBuired $ase syste# support was present to allow for the i#ple#entation of a "-.I!.+ su$syste# ,such as the !or& function, which is i#ple#ented
in the Windows 2000/200 e?ecuti'e, and the support for hard file links in the Windows 2000/200 file syste#/. 1owe'er, $ecause "-.I!.+ defines a li#ited set of ser'ices ,such as process control, interprocess co##unication, si#ple character cell I/-, and so on/, the "-.I! su$syste# that co#es with Windows 2000/200 /!" isn't a co#plete pro%ra##in% en'iron#ent. &nd $ecause applications can't #i? calls $etween su$syste#s on Windows 2000/200 $y default, "-.I! applications are li#ited to the strict set of ser'ices defined in "-.I!.+. This restriction #eans that a "-.I! e?ecuta$le on Windows 2000/200 can't create a thread or a window or use re#ote procedure calls ,;"2s/ or sockets. To address this li#itation, Microsoft pro'ides a product called Interi?, which includes an enhanced "-.I! su$syste# en'iron#ent that pro'ides nearly 2000/200 ENI! functions and 00 ENI!5like tools and utilities. With this enhance#ent, it is #ore 'ia$le to port ENI! applications to the "-.I! su$syste#. 1owe'er, $ecause the pro%ra#s are still linked as "-.I! e?ecuta$les, they cannot call Win 2 functions. To port ENI! applications to Windows 2000/200 and allow the use of Win 2 functions, you can purchase a ENI!5to5Win 2 portin% li$rary, such as the one included with the MF. NuT2;&2F6; "rofessional product a'aila$le fro# Mortice Fern .yste#s Inc. ,''',m&s,com/. With this approach, a ENI! application can $e reco#piled and relinked as a Win 2 e?ecuta$le and can slowly start to inte%rate calls to nati'e Win 2 functions. To co#pile and link a "-.I! application in Windows 2000/200 reBuires the "-.I! headers and li$raries fro# the "latfor# .8F. "-.I! e?ecuta$les are linked a%ainst the "-.I! su$syste# li$rary, "s?dll.dll. )ecause $y default Windows 2000/200 is confi%ured to start the "-.I! su$syste# on de#and, the first ti#e you run a "-.I! application, the "-.I! su$syste# process ,"s?ss.e?e/ #ust $e started. It re#ains runnin% until the syste# re$oots. ,If you kill the "-.I! su$syste# process, you won't $e a$le to run #ore "-.I! applications until you re$oot./ The "-.I! i#a%e itself isn't run directly*instead, a special support i#a%e called "osi?.e?e is launched, which in turn creates a child process to run the "-.I! application. >or #ore infor#ation a$out the "-.I! su$syste# and a$out portin% ENI! applications to Windows 2000/200 , do a search for "-.I! and ENI! in M.8N =i$rary.
OS/2 Subsystem
The -./2 en'iron#ent su$syste#, like the $uilt5in "-.I! su$syste#, is fairly li#ited in usefulness in that it supports only -./2 +.2 +45$it character5$ased or 'ideo I/- ,3I-/ applications. &lthou%h Microsoft did sell a replace#ent -./2 +.2 "resentation Mana%er su$syste# for Windows NT 4, it didn't support -./2 2. x ,or later/ applications ,and it isn't a'aila$le for Windows 2000/200 /. &lso, $ecause Windows 2000/200 doesn't allow direct hardware access $y user applications, -./2 pro%ra#s that contain I/- pri'ile%e se%#ents that atte#pt to perfor# IN/-ET instructions ,to access so#e hardware de'ice/ as well as ad'anced 'ideo I/- ,&3I-/ aren't supported. &pplications that use the 2=I/.TI instructions are supported*$ut all the other -./2 applications in the syste# and all the other threads in the -./2 process issuin% the 2=I instructions are suspended until an .TI instruction is e?ecuted. &lso worth notin% is the special support for callin% 25$it 8==s fro# -./2 +45$it applications on Windows 2000/200 , which can $e useful in portin% pro%ra#s. The +45M) #e#ory li#itation on nati'e -./2 +.2 doesn't apply to Windows 2000/200 *the -./2 su$syste# uses the 25$it 'irtual address space of Windows 2000/200 /!" to pro'ide up to <+2 M) of #e#ory to -./2 +.2 applications, as illustrated in >i%ure +59. 2C Copyright 2000-2007, Microsoft Corporation
F);'$+ 188 +-.( su"s stem virtual memor la out The tiled area is <+2 M) of 'irtual address space that is reser'ed up front and then co##itted or deco##itted when +45$it applications need se%#ents. The -./2 su$syste# #aintains a local descriptor ta$le ,=8T/ for each process, with shared #e#ory se%#ents at the sa#e =8T slot for all -./2 processes. Threads are the ele#ents of a pro%ra# that e?ecute, and as such they #ust $e scheduled for processor ti#e. &lthou%h Windows 2000/200 priority le'els ran%e fro# 0 throu%h +, the 44 -./2 priority le'els ,0 throu%h 4 / are #apped to Windows 2000/200 dyna#ic priorities + throu%h +<. -./2 threads ne'er recei'e Windows 2000/200 real5ti#e priorities +4 throu%h +. &s with the "-.I! su$syste#, the -./2 su$syste# starts auto#atically the first ti#e you acti'ate a co#pati$le -./2 i#a%e. It re#ains runnin% until the syste# is re$ooted.
3tdll"dll
Ntdll.dll is a special syste# support li$rary pri#arily for the use of su$syste# 8==s. It contains two types of functions0

.yste# ser'ice dispatch stu$s to Windows 2000/200 /!" e?ecuti'e syste# ser'ices Internal support functions used $y su$syste#s, su$syste# 8==s, and other nati'e i#a%es
The first %roup of functions pro'ides the interface to the Windows 2000/200 /!" e?ecuti'e syste# ser'ices that can $e called fro# user #ode. There are #ore than 200 such functions, 0 Copyright 2000-2007, Microsoft Corporation
such as NtCreateFile, Nt-etEvent, and so on. &s noted earlier, #ost of the capa$ilities of these functions are accessi$le throu%h the Win 2 &"I. ,& nu#$er are not, howe'er, and are for Microsoft internal use only./ >or each of these functions, Ntdll contains an entry point with the sa#e na#e. The code inside the function contains the architecture5specific instruction that causes a transition into kernel #ode to in'oke the syste# ser'ice dispatcher, which after 'erifyin% so#e para#eters, calls the actual kernel5#ode syste# ser'ice that contains the real code inside Ntoskrnl.e?e. Ntdll also contains #any support functions, such as the i#a%e loader ,functions that start with 3dr/, the heap #ana%er, and Win 2 su$syste# process co##unication functions ,functions that start with Csr/, as well as %eneral run5ti#e li$rary routines ,functions that start with $tl/. It also contains the user5#ode asynchronous procedure call ,&"2/ dispatcher and e?ception dispatcher.
04ecutive
The Windows 2000/200 /!" e?ecuti'e is the upper layer of Ntoskrnl.e?e. ,The kernel is the lower layer./ The e?ecuti'e includes the followin% types of functions0
>unctions that are e?ported and calla$le fro# user #ode. These functions are called s stem services and are e?ported 'ia Ntdll. Most of the ser'ices are accessi$le throu%h the Win 2 &"I or the &"Is of another en'iron#ent su$syste#. & few ser'ices, howe'er, aren't a'aila$le throu%h any docu#ented su$syste# function. ,6?a#ples include ="2s and 'arious Buery functions such as Nt5uer In!ormationxxx, speciali7ed functions such as NtCreatePagingFile, and so on./ >unctions that can $e called only fro# kernel #ode that are e?ported and docu#ented in the Windows 2000/200 /!" 88F or Windows 2000/200 /!" Installa$le >ile .yste# ,I>./ Fit. ,>or infor#ation on the Windows 2000/200 /!" I>. Fit, %o to ''',microso!t,com.dd&.i!s&it./ >unctions that are e?ported and calla$le fro# kernel #ode $ut are not docu#ented in the Windows 2000/200 /!" 88F or I>. Fit ,such as the functions called $y the $oot 'ideo dri'er, which start with In"v/. >unctions that are defined as %lo$al sy#$ols $ut are not e?ported. These would include internal support functions called within Ntoskrnl, such as those that start with Iop ,internal I/- #ana%er support functions/ or Mi ,internal #e#ory #ana%e#ent support functions/. >unctions that are internal to a #odule that are not defined as %lo$al sy#$ols.
The e?ecuti'e contains the followin% #a(or co#ponents0

The con!iguration manager is responsi$le for i#ple#entin% and #ana%in% the syste# re%istry. The process and thread manager creates and ter#inates processes and threads. The underlyin% support for processes and threads is i#ple#ented in the Windows 2000/200 /!" kernelI the e?ecuti'e adds additional se#antics and functions to these lower5le'el o$(ects. The securit re!erence monitor enforces security policies on the local co#puter. It %uards operatin% syste# resources, perfor#in% run5ti#e o$(ect protection and auditin%. The I.+ manager i#ple#ents de'ice5independent I/- and is responsi$le for dispatchin% to the appropriate de'ice dri'ers for further processin%.
+ Copyright 2000-2007, Microsoft Corporation
The Plug and Pla ,"n"/ manager deter#ines which dri'ers are reBuired to support a particular de'ice and loads those dri'ers. It retrie'es the hardware resource reBuire#ents for each de'ice durin% enu#eration. )ased on the resource reBuire#ents of each de'ice, the "n" #ana%er assi%ns the appropriate hardware resources such as I/- ports, I;@s, 8M& channels, and #e#ory locations. It is also responsi$le for sendin% proper e'ent notification for de'ice chan%es ,addition or re#o'al of a de'ice/ on the syste#. The po'er manager coordinates power e'ents and %enerates power #ana%e#ent I/notifications to de'ice dri'ers. When the syste# is idle, the power #ana%er can $e confi%ured to reduce power consu#ption $y puttin% the 2"E to sleep. 2han%es in power consu#ption $y indi'idual de'ices are handled $y de'ice dri'ers $ut are coordinated $y the power #ana%er. The %DM %indo's Management Instrumentation routines ena$le de'ice dri'ers to pu$lish perfor#ance and confi%uration infor#ation and recei'e co##ands fro# the user5#ode WMI ser'ice. 2onsu#ers of WMI infor#ation can $e on the local #achine or re#ote across the network. The cache manager i#pro'es the perfor#ance of file5$ased I/- $y causin% recently referenced disk data to reside in #ain #e#ory for Buick access ,and $y deferrin% disk writes $y holdin% the updates in #e#ory for a short ti#e $efore sendin% the# to the disk/. &s you'll see, it does this $y usin% the #e#ory #ana%er's support for #apped files. The virtual memor manager i#ple#ents virtual memor , a #e#ory #ana%e#ent sche#e that pro'ides a lar%e, pri'ate address space for each process that can e?ceed a'aila$le physical #e#ory. The #e#ory #ana%er also pro'ides the underlyin% support for the cache #ana%er.
In addition, the e?ecuti'e contains four #ain %roups of support functions that are used $y the e?ecuti'e co#ponents (ust listed. &$out a third of these support functions are docu#ented in the 88F $ecause de'ice dri'ers also use the#. These are the four cate%ories of support functions0
The o"#ect manager, which creates, #ana%es, and deletes Windows 2000/200 /!" e?ecuti'e o$(ects and a$stract data types that are used to represent operatin% syste# resources such as processes, threads, and the 'arious synchroni7ation o$(ects. The 3PC !acilit passes #essa%es $etween a client process and a ser'er process on the sa#e co#puter. ="2 is a fle?i$le, opti#i7ed 'ersion of remote procedure call ,;"2/, an industry5standard co##unication facility for client and ser'er processes across a network. & $road set of co##on run*time li"rar functions, such as strin% processin%, arith#etic operations, data type con'ersion, and security structure processin%. Executive support routines, such as syste# #e#ory allocation ,pa%ed and nonpa%ed pool/, interlocked #e#ory access, as well as two special types of synchroni7ation o$(ects0 resources and fast #ute?es.
!ernel
The kernel consists of a set of functions in Ntoskrnl.e?e that pro'ide funda#ental #echanis#s ,such as thread schedulin% and synchroni7ation ser'ices/ used $y the e?ecuti'e co#ponents, as well as low5le'el hardware architecture5dependent support ,such as interrupt and e?ception dispatchin%/, that are different on each processor architecture. The kernel code is written pri#arily in 2, with asse#$ly code reser'ed for those tasks that reBuire access to speciali7ed processor instructions and re%isters not easily accessi$le fro# 2.
&e'nel Ob+ects
The kernel pro'ides a low5le'el $ase of well5defined, predicta$le operatin% syste# pri#iti'es and #echanis#s that allow hi%her5le'el co#ponents of the e?ecuti'e to do what they need to do. The kernel separates itself fro# the rest of the e?ecuti'e $y i#ple#entin% operatin% syste# #echanis#s and a'oidin% policy #akin%. It lea'es nearly all policy decisions to the e?ecuti'e, with the e?ception of thread schedulin% and dispatchin%, which the kernel i#ple#ents. -utside the kernel, the e?ecuti'e represents threads and other sharea$le resources as o$(ects. These o$(ects reBuire so#e policy o'erhead, such as o$(ect handles to #anipulate the#, security checks to protect the#, and resource Buotas to $e deducted when they are created. This o'erhead is eli#inated in the kernel, which i#ple#ents a set of si#pler o$(ects, called &ernel o"#ects, that help the kernel control central processin% and support the creation of e?ecuti'e o$(ects. Most e?ecuti'e5le'el o$(ects encapsulate one or #ore kernel o$(ects, incorporatin% their kernel5defined attri$utes. -ne set of kernel o$(ects, called control o"#ects, esta$lishes se#antics for controllin% 'arious operatin% syste# functions. This set includes the &"2 o$(ect, the de!erred procedure call ,8"2/o$(ect, and se'eral o$(ects the I/- #ana%er uses, such as the interrupt o$(ect. &nother set of kernel o$(ects, known as dispatcher o"#ects, incorporates synchroni7ation capa$ilities that alter or affect thread schedulin%. The dispatcher o$(ects include the kernel thread, #ute? ,called mutant internally/, e'ent, kernel e'ent pair, se#aphore, ti#er, and waita$le ti#er. The e?ecuti'e uses kernel functions to create instances of kernel o$(ects, to #anipulate the#, and to construct the #ore co#ple? o$(ects it pro'ides to user #ode.
,a'dwa'e Suppo't
The other #a(or (o$ of the kernel is to a$stract or isolate the e?ecuti'e and de'ice dri'ers fro# 'ariations $etween the hardware architectures supported $y Windows 2000/200 /!" . This (o$ includes handlin% 'ariations in functions such as interrupt handlin%, e?ception dispatchin%, and #ultiprocessor synchroni7ation. 6'en for these hardware5related functions, the desi%n of the kernel atte#pts to #a?i#i7e the a#ount of co##on code. The kernel supports a set of interfaces that are porta$le and se#antically identical across architectures. Most of the code that i#ple#ents this porta$le interface is also identical across architectures. .o#e of these interfaces are i#ple#ented differently on different architectures, howe'er, or so#e of the interfaces are partially i#ple#ented with architecture5specific code. These architecturally independent interfaces can $e called on any #achine, and the se#antics of the interface will $e the sa#e whether or not the code 'aries $y architecture. .o#e kernel interfaces ,such as spinlock routines/ are actually i#ple#ented in the 1&= ,descri$ed in the ne?t section/ $ecause their i#ple#entation can 'ary for syste#s within the sa#e architecture fa#ily. The kernel also contains a s#all a#ount of code with ?945specific interfaces needed to support old M.58-. pro%ra#s. These ?94 interfaces aren't porta$le in the sense that they can't $e called on a #achine $ased on any other architectureI they won't $e present. This ?945 specific code, for e?a#ple, supports calls to #anipulate %lo$al descriptor ta$les ,:8Ts/ and =8Ts, hardware features of the ?94.
-ther e?a#ples of architecture5specific code in the kernel include the interface to pro'ide translation $uffer and 2"E cache support. This support reBuires different code for the different architectures $ecause of the way caches are i#ple#ented. &nother e?a#ple is conte?t switchin%. &lthou%h at a hi%h le'el the sa#e al%orith# is used for thread selection and conte?t switchin% ,the conte?t of the pre'ious thread is sa'ed, the conte?t of the new thread is loaded, and the new thread is started/, there are architectural differences a#on% the i#ple#entations on different processors. )ecause the conte?t is descri$ed $y the processor state ,re%isters and so on/, what is sa'ed and loaded 'aries dependin% on the architecture.
)ard/are Abstraction 2a er 5)A26

&s #entioned at the $e%innin% of this chapter, one of the crucial ele#ents of the Windows 2000/200 /!" desi%n is its porta$ility across a 'ariety of hardware platfor#s. The 1&= is a key part of #akin% this porta$ility possi$le. The 1&= is a loada$le kernel5#ode #odule ,1al.dll/ that pro'ides the low5le'el interface to the hardware platfor# on which Windows 2000/200 /!" is runnin%. It hides hardware5dependent details such as I/- interfaces, interrupt controllers, and #ultiprocessor co##unication #echanis#s*any functions that are $oth architecture5specific and #achine5dependent. .o rather than access hardware directly, Windows 2000/200 /!" internal co#ponents as well as user5written de'ice dri'ers #aintain porta$ility $y callin% the 1&= routines when they need platfor#5dependent infor#ation. >or this reason, the 1&= routines are docu#ented in the Windows 2000/200 /!" 88F. To find out #ore a$out the 1&= and its use $y de'ice dri'ers, refer to the 88F. &lthou%h se'eral 1&=s are included on the Windows 2000/200 28s ,see Ta$le +54/, only one is chosen at installation ti#e and copied to the syste# disk with the filena#e 1al.dll. ,-ther operatin% syste#s, such as 3M., select the eBui'alent of the 1&= at syste# $oot ti#e./ Therefore, you can't assu#e that a syste# disk fro# one ?94 installation will $oot on a different processor if the 1&= that supports the other processor is different. T.:0+ +54 3ist o! 6A3s HAL F)0+ N./+ 1al.dll 1alacpi.dll 1alapic.dll 1alaacpi.dll 1al#ps.dll 1al#acpi.dll 1al$or%.dll 1alsp.dll .tandard "2s &d'anced 2onfi%uration and "ower Interface ,&2"I/ "2s &d'anced "ro%ra##a$le Interrupt 2ontroller ,&"I2/ "2s &"I2 &2"I "2s Multiprocessor "2s Multiprocessor &2"I "2s .ilicon :raphics Workstation ,no lon%er #arketed/ 2o#paB .yste#"ro ,no lon%er #arketed/ S1-#+/- S'22%$#+&
1evice 1rivers
8e'ice dri'ers are loada$le kernel5#ode #odules ,typically endin% in .sys/ that interface $etween the I/- #ana%er and the rele'ant hardware. They run in kernel #ode in one of three conte?ts0

In the conte?t of the user thread that initiated an I/- function In the conte?t of a kernel5#ode syste# thread &s a result of an interrupt ,and therefore not in the conte?t of any particular process or thread*whiche'er process or thread was current when the interrupt occurred/
&s stated in the precedin% section, de'ice dri'ers in Windows 2000/200 /!" don't #anipulate hardware directly, $ut rather they call functions in the 1&= to interface with the hardware. 8ri'ers are typically written in 2 ,so#eti#es 2LL/ and therefore, with proper use of 1&= routines, can $e source code porta$le across the 2"E architectures supported $y Windows 2000/200 /!" and $inary porta$le within an architecture fa#ily. There are se'eral types of de'ice dri'ers0
6ard'are device drivers #anipulate hardware ,usin% the 1&=/ to write output to or retrie'e input fro# a physical de'ice or network. There are #any types of hardware de'ice dri'ers, such as $us dri'ers, hu#an interface dri'ers, #ass stora%e dri'ers, and so on. File s stem drivers are Windows 2000/200 /!" dri'ers that accept file5oriented I/reBuests and translate the# into I/- reBuests $ound for a particular de'ice. File s stem !ilter drivers, such as those that perfor# disk #irrorin% and encryption, intercept I/-s and perfor# so#e added5'alue processin% $efore passin% the I/- to the ne?t layer. Net'or& redirectors and servers are file syste# dri'ers that trans#it file syste# I/reBuests to a #achine on the network and recei'e such reBuests, respecti'ely. Protocol drivers i#ple#ent a networkin% protocol such as T2"/I", Net)6EI, and I"!/."!. 7ernel streaming !ilter drivers are chained to%ether to perfor# si%nal processin% on data strea#s, such as recordin% or displayin% audio and 'ideo.
)ecause installin% a de'ice dri'er is the only way to add user5written kernel5#ode code to the syste#, so#e pro%ra##ers ha'e written de'ice dri'ers si#ply as a way to access internal operatin% syste# functions or data structures that are not accessi$le fro# user #ode ,$ut that are docu#ented and supported in the 88F/. >or e?a#ple, #any of the utilities fro# ''',s sinternals,com co#$ine a Win 2 :EI application and a de'ice dri'er that is used to %ather internal syste# state not accessi$le fro# the Win 2 &"I.
Windows 2000/2003/XP %e-ice %'i-e' "n ancements

Windows 2000/200 /!" adds support for "lu% and "lay, "ower -ptions, and an e?tension to the Windows NT dri'er #odel called the Windows 8ri'er Model ,W8M/. Windows 2000/200 /!" can run le%acy Windows NT 4 dri'ers, $ut $ecause these don't support "lu% and "lay and "ower -ptions, syste#s runnin% these dri'ers will ha'e reduced capa$ilities in these two areas. >ro# the W8M perspecti'e, there are three kinds of dri'ers0
< Copyright 2000-2007, Microsoft Corporation
& "us driver ser'ices a $us controller, adapter, $rid%e, or any de'ice that has child de'ices. )us dri'ers are reBuired dri'ers, and Microsoft %enerally pro'ides the#I each type of $us ,such as "2I, "2M2I&, and E.)/ on a syste# has one $us dri'er. Third parties can write $us dri'ers to pro'ide support for new $uses, such as 3M6$us, Multi$us, and >uture$us. & !unction driver is the #ain de'ice dri'er and pro'ides the operational interface for its de'ice. It is a reBuired dri'er unless the de'ice is used raw ,an i#ple#entation in which I/- is done $y the $us dri'er and any $us filter dri'ers, such as .2.I "assThru/. & function dri'er is $y definition the dri'er that knows the #ost a$out a particular de'ice, and it is usually the only dri'er that accesses de'ice5specific re%isters. & !ilter driver is used to add functionality to a de'ice ,or e?istin% dri'er/ or to #odify I/- reBuests or responses fro# other dri'ers ,often used to fi? hardware that pro'ides incorrect infor#ation a$out its hardware resource reBuire#ents/. >ilter dri'ers are optional and can e?ist in any nu#$er, placed a$o'e or $elow a function dri'er and a$o'e a $us dri'er. Esually, syste# ori%inal eBuip#ent #anufacturers ,-6Ms/ or independent hardware 'endors ,I13s/ supply filter dri'ers.
In the W8M dri'er en'iron#ent, no sin%le dri'er controls all aspects of a de'ice0 a $us dri'er is concerned with reportin% the de'ices on its $us to the "n" #ana%er, while a function dri'er #anipulates the de'ice. In #ost cases, lower5le'el filter dri'ers #odify the $eha'ior of de'ice hardware. >or e?a#ple, if a de'ice reports to its $us dri'er that it reBuires four I/- ports when it actually reBuires +4 I/- ports, a lower5le'el de'ice5specific function filter dri'er could intercept the list of hardware resources reported $y the $us dri'er to the "n" #ana%er, and update the count of I/- ports. Epper5le'el filter dri'ers usually pro'ide added5'alue features for a de'ice. >or e?a#ple, an upper5le'el de'ice filter dri'er for a key$oard can enforce additional security checks.
Peerin$ into #ndocumented Inter%aces

Oust e?a#inin% the na#es of the e?ported or %lo$al sy#$ols in key syste# i#a%es ,such as Ntoskrnl.e?e, 1al.dll, or Ntdll.dll/ can $e enli%htenin%*you can %et an idea of the kinds of thin%s Windows 2000/200 /!" can do 'ersus what happens to $e docu#ented and supported today. -f course, (ust $ecause you know the na#es of these functions doesn't #ean that you can or should call the#*the interfaces are undocu#ented and are su$(ect to chan%e. We su%%est that you look at these functions purely to %ain #ore insi%ht into the kinds of internal functions Windows 2000/200 /!" perfor#s, not to $ypass supported interfaces. >or e?a#ple, lookin% at the list of functions in Ntdll.dll %i'es you the list of all the syste# ser'ices that Windows 2000/200 /!" pro'ides to user5#ode su$syste# 8==s 'ersus the su$set that each su$syste# e?poses. &lthou%h #any of these functions #ap clearly to docu#ented and supported Win 2 functions, se'eral are not e?posed 'ia the Win 2 &"I. 2on'ersely, it's also interestin% to e?a#ine the i#ports of Win 2 su$syste# 8==s ,such as Fernel 2.dll or &d'api 2.dll/ and which functions they call in Ntdll. &nother interestin% i#a%e to du#p is Ntoskrnl.e?e*althou%h #any of the e?ported routines that kernel5#ode de'ice dri'ers use are docu#ented in the Windows 2000/200 88F, Buite a few are not. Aou #i%ht also find it interestin% to take a look at the i#port ta$le for Ntoskrnl and the 1&=I this ta$le shows the list of functions in the 1&= that Ntoskrnl uses and 'ice 'ersa.
S stem Processes
The followin% syste# processes appear on e'ery Windows 2000/200 /!" syste#. ,Two of these*Idle and .yste#*are not full processes, as they are not runnin% a user5#ode e?ecuta$le./

Idle process ,contains one thread per 2"E to account for idle 2"E ti#e/ .yste# process ,contains the #a(ority of the kernel5#ode syste# threads/ .ession #ana%er ,.#ss.e?e/ Win 2 su$syste# ,2srss.e?e/ =o%on process ,Winlo%on.e?e/ .er'ice control #ana%er ,.er'ices.e?e/ and the child ser'ice processes it creates =ocal security authentication ser'er ,=sass.e?e/
To help you understand the relationship of these processes, use the tlist .t co##and in the Windows 2000/200 /!" .upport Tools to display the process Dtree,D that is, the parent/child relationship $etween processes. 1ere is a partial annotated output fro# tlist .t0
System Process (0) System (8) threads) smss.exe (144) csrss.exe (1 !) %inlogon.exe (1&!) +ice) ser+ices.exe (!!0) s+chost.exe (#84) spools+.exe (480) regs+c.exe (-#-) mstas/.exe (--4) lsass.exe (!#!) Idle process System process (default home for system Session Manager "in#! su$system process 'ogon process (also contains (et))* ser Ser+ice control manager ,eneric ser+ice host image Spooler ser+ice .emote registry ser+ice 0as/ Scheduler ser+ice 'ocal security authentication ser+er
The ne?t sections e?plain the key syste# processes shown in this output. T.:0+ 18< Names !or Process ID ) in 2arious 0tilities U#)0)#1 Task Mana%er "rocess 3iewer ,"'iewer.e?e/ "rocess .tatus ,"stat.e?e/ "rocess 6?plode ,"'iew.e?e/ Task =ist ,Tlist.e?e/ @uick.lice ,@slice.e?e/ N./+ 3%$ P$%(+-- ID 0 .yste# Idle "rocess Idle Idle "rocess .yste# "rocess .yste# "rocess .yste#process
Idle P'ocess
8espite the na#e shown, the first process listed in the precedin% sa#ple tlist .t output ,process I8 0/ is actually the .yste# Idle process. "rocesses are identified $y their i#a%e na#e. 1owe'er, this process ,as well as process I8 9, na#ed .yste#/ isn't runnin% a real user5#ode i#a%e. 1ence, the na#es shown $y the 'arious syste# display utilities differ fro#
G Copyright 2000-2007, Microsoft Corporation
utility to utility. &lthou%h #ost utilities call process I8 9 D.yste#,D not all do. Ta$le +5< lists se'eral of the na#es %i'en to the Idle process ,process I8 0/. Now let's look at syste# threads and the purpose of each of the syste# processes that are runnin% real i#a%es.
System P'ocess and System . 'eads

The .yste# process ,always process I8 9/ is the ho#e for a special kind of thread that runs only in kernel #ode0 a &ernel*mode s stem thread. .yste# threads ha'e all the attri$utes and conte?ts of re%ular user5#ode threads ,such as a hardware conte?t, priority, and so on/ $ut are different in that they run only in kernel5#ode e?ecutin% code loaded in syste# space, whether that is in Ntoskrnl.e?e or in any other loaded de'ice dri'er. In addition, syste# threads don't ha'e a user process address space and hence #ust allocate any dyna#ic stora%e fro# operatin% syste# #e#ory heaps, such as pa%ed or nonpa%ed pool. .yste# threads are created $y the PsCreate- stemThread function ,docu#ented in the 88F/, which can $e called only fro# kernel #ode. Windows 2000/200 /!" as well as 'arious de'ice dri'ers create syste# threads durin% syste# initiali7ation to perfor# operations that reBuire thread conte?t, such as issuin% and waitin% for I/-s or other o$(ects or pollin% a de'ice. >or e?a#ple, the #e#ory #ana%er uses syste# threads to i#ple#ent such functions as writin% dirty pa%es to the pa%e file or #apped files, swappin% processes in and out of #e#ory, and so forth. The kernel creates a syste# thread called the "alance set manager that wakes up once per second to possi$ly initiate 'arious schedulin% and #e#ory #ana%e#ent5 related e'ents. The cache #ana%er also uses syste# threads to i#ple#ent $oth read5ahead and write5$ehind I/-s. The file ser'er de'ice dri'er ,.r'.sys/ uses syste# threads to respond to network I/- reBuests for file data on disk partitions shared to the network. 6'en the floppy dri'er has a syste# thread to poll the floppy de'ice ,pollin% is #ore efficient in this case $ecause an interrupt5dri'en floppy dri'er consu#es a lar%e a#ount of syste# resources/. >urther infor#ation on specific syste# threads is included in the chapters in which the co#ponent is descri$ed. )y default, syste# threads are owned $y the .yste# process, $ut a de'ice dri'er can create a syste# thread in any process. >or e?a#ple, the Win 2 su$syste# de'ice dri'er ,Win 2k.sys/ creates syste# threads in the Win 2 su$syste# process ,2srss.e?e/ so that they can easily access data in the user5#ode address space of that process. When you're trou$leshootin% or %oin% throu%h a syste# analysis, it's useful to $e a$le to #ap the e?ecution of indi'idual syste# threads $ack to the dri'er or e'en to the su$routine that contains the code. >or e?a#ple, on a hea'ily loaded file ser'er, the .yste# process will likely $e consu#in% considera$le 2"E ti#e. )ut the knowled%e that when the .yste# process is runnin% Dso#e syste# threadD is runnin% isn't enou%h to deter#ine which de'ice dri'er or operatin% syste# co#ponent is runnin%. .o if the .yste# process is runnin%, look at the e?ecution of the threads within that process ,for e?a#ple, with the "erfor#ance tool/. -nce you find the thread ,or threads/ that is runnin%, look up in which dri'er the syste# thread $e%an e?ecution ,which at least tells you which dri'er likely created the thread/ or e?a#ine the call stack ,or at least the current address/ of the thread in Buestion, which would indicate where the thread is currently e?ecutin%.
Session (ana/e' 0Smss1

The .ession Mana%er ,MWinntM.yste# 2M.#ss.e?e/ is the first user5#ode process created in the syste#. The kernel5#ode syste# thread that perfor#s the final phase of the initiali7ation of the e?ecuti'e and kernel creates the actual .#ss process. The .ession Mana%er is responsi$le for a nu#$er of i#portant steps in startin% Windows 2000/200 /!" , such as openin% additional pa%e files, perfor#in% delayed file rena#e and delete operations, and creatin% syste# en'iron#ent 'aria$les. It also launches the su$syste# processes ,nor#ally (ust 2srss.e?e/ and the Winlo%on process, which in turn creates the rest of the syste# processes. Much of the confi%uration infor#ation in the re%istry that dri'es the initiali7ation steps of .#ss can $e found under 1F=MM.A.T6MM2urrent2ontrol.etM2ontrolM.ession Mana%er. Aou'll find it interestin% to e?a#ine the kinds of data stored there. ,>or a description of the keys and 'alues, see the ;e%istry 6ntries help file, ;e%entry.ch#, in the Windows 2000/200 resource kits./ &fter perfor#in% these initiali7ation steps, the #ain thread in .#ss waits fore'er on the process handles to 2srss and Winlo%on. If either of these processes ter#inates une?pectedly, .#ss crashes the syste#, since Windows 2000/200 /!" elies on their e?istence. Meanwhile, .#ss waits for reBuests to load su$syste#s, new su$syste#s startin% up, and de$u% e'ents. It also acts as a switch and #onitor $etween applications and de$u%%ers.
Lo/on 0Winlo/on1
The Windows 2000/200 /!" lo%on process ,MWinntM.yste# 2MWinlo%on.e?e/ handles interacti'e user lo%ons and lo%offs. Winlo%on is notified of a user lo%on reBuest when the secure attention se8uence ,.&./ keystroke co#$ination is entered. The default .&. on Windows 2000/200 /!" is the co#$ination 2trlL&ltL8elete. The reason for the .&. is to protect users fro# password5capture pro%ra#s that si#ulate the lo%on process. -nce the userna#e and password ha'e $een captured, they are sent to the local security authentication ser'er process ,descri$ed in the ne?t section/ to $e 'alidated. If they #atch, Winlo%on e?tracts the 'alue of the Eserinit re%istry 'alue under the re%istry key 1F=MM.->TW&;6MMicrosoftMWindows NTM2urrent3ersionMWinlo%on and creates a process to run each e?ecuta$le i#a%e listed in that 'alue. The default is to run a process na#ed Eserinit.e?e. This process perfor#s so#e initiali7ation of the user en'iron#ent ,such as restorin% #apped dri'e letters, runnin% the lo%in script, and applyin% %roup policies/ and then looks in the re%istry at the .hell 'alue ,under the sa#e Winlo%on key referred to pre'iously/ and creates a process to run the syste#5defined shell ,$y default, 6?plorer.e?e/. Then Eserinit e?its. This is the reason 6?plorer.e?e is shown with no parent*its parent has e?ited, and as e?plained earlier, tlist left5(ustifies processes whose parent isn't runnin%. ,&nother way of lookin% at it is that 6?plorer is the %randchild of Winlo%on./ The identification and authentication aspects of the lo%on process are i#ple#ented in a replacea$le 8== na#ed :IN& ,:raphical Identification and &uthentication/. The standard Windows 2000/200 /!" :IN&, Ms%ina.dll, i#ple#ents the default Windows 2000/200 /!" lo%on interface. 1owe'er, de'elopers can pro'ide their own :IN& 8== to i#ple#ent other identification and authentication #echanis#s in place of the standard Windows 2000/200 /!" userna#e/password #ethod ,such as one $ased on a 'oice print/. In addition, Winlo%on can load additional network pro'ider 8==s that need to perfor# secondary
C Copyright 2000-2007, Microsoft Corporation
authentication. This capa$ility allows #ultiple network pro'iders to %ather identification and authentication infor#ation all at one ti#e durin% nor#al lo%on. Winlo%on is acti'e not only durin% user lo%on and lo%off $ut also whene'er it intercepts the .&. fro# the key$oard. >or e?a#ple, when you press 2trlL&ltL8elete while lo%%ed in, the Windows .ecurity dialo% $o? co#es up, pro'idin% the options to lo% off, start the Task Mana%er, lock the workstation, shut down the syste#, and so forth. Winlo%on is the process that handles this interaction.
Local Secu'ity 2ut entication Se'-e' 0LS2SS1

The local security authentication ser'er process ,MWinntM.yste# 2M=sass.e?e/ recei'es authentication reBuests fro# Winlo%on and calls the appropriate authentication packa%e ,i#ple#ented as a 8==/ to perfor# the actual 'erification, such as checkin% whether a password #atches what is stored in the acti'e directory or the .&M ,the part of the re%istry that contains the definition of the users and %roups/. Epon a successful authentication, =sass %enerates an access token o$(ect that contains the user's security profile. Winlo%on then uses this access token to create the initial shell process. "rocesses launched fro# the shell then $y default inherit this access token.
Se'-ice Cont'ol (ana/e' 0SC(1

;ecall fro# earlier in the chapter that Dser'icesD on Windows 2000/200 /!" can refer either to a ser'er process or to a de'ice dri'er. This section deals with ser'ices that are user5#ode processes. .er'ices are like ENI! Ddae#on processesD or 3M. Ddetached processesD in that they can $e confi%ured to start auto#atically at syste# $oot ti#e without reBuirin% an interacti'e lo%on. They can also $e started #anually ,such as $y runnin% the .er'ices ad#inistrati'e tool or $y callin% the Win 2 -tart-ervice function/. Typically, ser'ices do not interact with the lo%%ed on user, thou%h there are special conditions when this is possi$le. The ser'ice control #ana%er is a special syste# process runnin% the i#a%e MWinntM.yste# 2M.er'ices.e?e that is responsi$le for startin%, stoppin%, and interactin% with ser'ice processes. .er'ice pro%ra#s are really (ust Win 2 i#a%es that call special Win 2 functions to interact with the ser'ice control #ana%er to perfor# such actions as re%isterin% the ser'ice's successful startup, respondin% to status reBuests, or pausin% or shuttin% down the ser'ice. .er'ices are defined in the re%istry under 1F=MM.A.T6MM2urrent2ontrol.et M.er'ices. The resource kit ;e%istry 6ntries help file ,;e%entry.ch#/ docu#ents the su$keys and 'alues for ser'ices. Feep in #ind that ser'ices ha'e three na#es0 the process na#e you see runnin% on the syste#, the internal na#e in the re%istry, and the display na#e shown in the .er'ices ad#inistrati'e tool. ,Not all ser'ices ha'e a display na#e*if a ser'ice doesn't ha'e a display na#e, the internal na#e is shown./ With Windows 2000/200 /!" , ser'ices can also ha'e a description field that can contain up to +024 characters that further detail what the ser'ice does. To #ap a ser'ice process to the ser'ices contained in that process, use the tlist .s co##and. Note that there isn't always one5to5one #appin% $etween ser'ice process and runnin% ser'ices, howe'er, $ecause so#e ser'ices share a process with other ser'ices. In the re%istry, the type code indicates whether the ser'ice runs in its own process or shares a process with other ser'ices in the i#a%e.
& nu#$er of Windows 2000/200 /!" co#ponents are i#ple#ented as ser'ices, such as the spooler, 6'ent =o%, Task .cheduler, and 'arious other networkin% co#ponents.
S'//.$1
.o far, we''e taken a $road look at the o'erall syste# architecture of Windows 2000/200 /!" operatin% syste#. We''e e?a#ined the key co#ponents of Windows 2000/200 /!" and seen how they interrelate. Ne?t, wePll e?a#ine the =inu? architecture and key co#ponents.
4+ Copyright 2000-2007, Microsoft Corporation

Windows 2000 - 2003 - XP OS Architecture

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Windows 2000 - 2003 - XP OS Architecture

Uploaded by

Copyright:

Available Formats

Windows OS: Concepts and Fundamentals

+ Copyright 2000-2007, Microsoft Corporation

I"#$%&'(#)%" #% #*+ W)"&%,- F./)01

2 Copyright 2000-2007, Microsoft Corporation

and syste# #ana%e#ent.

Windows .#all )usiness .er'er 200

Copyright 2000-2007, Microsoft Corporation

Services, Functions, and Routines

4 Copyright 2000-2007, Microsoft Corporation

Processes, Threads, and Jobs

< Copyright 2000-2007, Microsoft Corporation

F);'$+ 181 A process and its resources

4 Copyright 2000-2007, Microsoft Corporation

G Copyright 2000-2007, Microsoft Corporation

F);'$+ 183 Mapping virtual memor to ph sical memor

!ernel Mode vs" #ser Mode

Rin$s o% Protection and !ernel&#ser Modes

9 Copyright 2000-2007, Microsoft Corporation

C Copyright 2000-2007, Microsoft Corporation

'b(ects and )andles

+0 Copyright 2000-2007, Microsoft Corporation

++ Copyright 2000-2007, Microsoft Corporation

+2 Copyright 2000-2007, Microsoft Corporation

Copyright 2000-2007, Microsoft Corporation

O2+$.#)"; S1-#+/ M%&+0

+4 Copyright 2000-2007, Microsoft Corporation

+4 Copyright 2000-2007, Microsoft Corporation

+G Copyright 2000-2007, Microsoft Corporation

+C Copyright 2000-2007, Microsoft Corporation

W)"&%,- 2000/2003/ P P$%&'(# P.(9.;)";

20 Copyright 2000-2007, Microsoft Corporation

Multi*rocessor.S*eci%ic S stem Files

2+ Copyright 2000-2007, Microsoft Corporation

22 Copyright 2000-2007, Microsoft Corporation

F);'$+ 18A %indo's ())).())/.1P architecture

Copyright 2000-2007, Microsoft Corporation

24 Copyright 2000-2007, Microsoft Corporation

2< Copyright 2000-2007, Microsoft Corporation

24 Copyright 2000-2007, Microsoft Corporation

2G Copyright 2000-2007, Microsoft Corporation

Win32 Subsystem !se'*mode P'ocesses

29 Copyright 2000-2007, Microsoft Corporation

The e?ecuti'e contains the followin% #a(or co#ponents0

+ Copyright 2000-2007, Microsoft Corporation

2 Copyright 2000-2007, Microsoft Corporation

Copyright 2000-2007, Microsoft Corporation

)ard/are Abstraction 2a er 5)A26

4 Copyright 2000-2007, Microsoft Corporation

Windows 2000/2003/XP %e-ice %'i-e' "n ancements

< Copyright 2000-2007, Microsoft Corporation

Peerin$ into #ndocumented Inter%aces

4 Copyright 2000-2007, Microsoft Corporation

G Copyright 2000-2007, Microsoft Corporation

System P'ocess and System . 'eads

9 Copyright 2000-2007, Microsoft Corporation

Session (ana/e' 0Smss1

C Copyright 2000-2007, Microsoft Corporation

Local Secu'ity 2ut entication Se'-e' 0LS2SS1

Se'-ice Cont'ol (ana/e' 0SC(1

40 Copyright 2000-2007, Microsoft Corporation

4+ Copyright 2000-2007, Microsoft Corporation

You might also like

Multirocessor.Seci%ic S stem Files