INTRODUCTION A modem computer consists of one or more processors, some main memory, disks, printers, a keyboard, a mouse, a display, network interfaces, and various other input/output devices All in all, a complex system If every application pro­ grammer had to understand how all these things work in detail, no code would ever get written Furthermore, managing all these components and using them optimally is an exceedingly challenging job For this reason, computers are equipped with a layer of software called the operating system, whose job is to provide user programs with a better, simpler, cleaner, model of the computer and to handle managing all the resources just mentioned These systems are the sub­ ject of this book Most readers will have had some experience with an operating system such as Windows, Linux, FreeBSD, or Max OS X, but appearances can be deceiving The program that users interact with, usually called the shell when it is text based and the GUI (Graphical User Interface)-which is pronounced "gooey"- when it uses icons, is actually not part of the operating system although it uses the operat­ ing system to get its work done A simple overview of the main components under discussion here is given in Fig 1-1 Here we see the hardware at the bottom The hardware consists of chips, boards, disks, a keyboard, a monitor, and similar physical objects On top of the hardware is the software Most computers have two modes of operation: kernel mode and user mode The operating system is the most fundamental piece of soft­ ware and runs in kernel mode (also called supervisor mode) In this mode it has INTRODUCTION CHAP complete access to all the hardware and can execute any instruction the machine is capable of executing The rest of the software runs in user mode, in which only a subset of the machine instructions is available In particular, those instructions that affect control of the machine or 1/0 (Input/Output) are forbidden to user­ mode programs We will come back to the difference between kernel mode and user mode repeatedly throughout this book E-mail reader Music player User mode Software Kernel mode { Figure 1-1 Where the operating system fits in The user interface program, shell or GUI, is the lowest level of user-mode software, and allows the user to start other programs, such as a Web browser, e­ mail reader, or music player These programs, too, make heavy use of the operat­ ing system The placement of the operating system is shown in Fig 1-1 It runs on the bare hardware and provides the base for all the other software An important distinction between the operating system and normal (user­ mode) software is that if a user does not like a particular e-mail reader, het is free to get a different one or write his own if he so chooses; he is not free to write his own clock interrupt handler, which is part of the operating system and is protected by hardware against attempts by users to modify it This distinction, however, is sometimes blurred in embedded systems (which may not have kernel mode) or interpreted systems (such as Java-based operating systems that use interpretation, not hardware, to separate the components) Also, in many systems there are programs that run in user mode but which help the operating system or perform privileged functions For example, there is often a program that allows users to change their passwords This program is not part of the operating system and does not run in kernel mode, but it clearly carries out a sensitive function and has to be protected in a special way In some sys­ tems, this idea is carried to an extreme form, and pieces of what is traditionally t "He" should be read as "he or she" throughout the book SEC 1.1 WHAT IS AN OPERATING SYSTEM? considered to be the operating system (such as the file system) run in user space In such systems, it is difficult to draw a clear boundary Everything running in kernel mode is clearly part of the operating system, but some programs running outside it are arguably also part of it, or at least closely associated with it Operating systems differ from user (i.e., application) programs in ways other than where they reside In particular, they are huge, complex, and long-lived The source code of an operating system like Linux or Windows is on the order of five million lines of code To conceive of what this means, think of printing out five million lines in book form, with 50 lines per page and 1000 pages per volume (larger than this book) It would take 100 volumes to list an operating system of this size-essent ially an entire bookcase Can you imagine getting a job ma intain­ ing an operating system and on the first day having your boss bring you to a book case with the code and say: "Go learn that." And this is only for the part that runs in the kernel User programs like the GUI, libraries, and basic application soft­ ware (things like Windows Explorer) can easily run to 10 or 20 times that amount It should be clear now why operat ing systems live a long time-they are very hard to write, and having written one, the owner is loath to throw it out and start again Instead, they evolve over long periods of time Windows 95/98/Me was basically one operating system and Windows NT/2000/XPNista is a different one They look similar to the users because Microsoft made very sure that the user interface of Windows 2000/XP was quite similar to the system it was replacing, mostly Windows 98 Nevertheless, there were very good reasons why Microsoft got rid of Windows 98 and we will come to these when we study Windows in de­ tail in Chap 1 The other main example we will use throughout this book (besides Windows) is UNIX and its variants and clones It, too, has evolved over the years, with ver­ sions like System V, Solaris, and FreeBSD being derived from the original sys­ tem, whereas Linux is a fresh code base, although very closely modeled on UNIX and highly compatible with it We will use examples from UNIX throughout this book and look at Linux in detail in Chap 10 In this chapter we will touch on a number of key aspects of operating systems, briefly, including what they are, their history, what kinds are around, some of the basic concepts, and their structure We will come back to many of these impor­ tant topics in later chapters in more detail 1.1 WHAT IS AN OPERATING SYSTEM? It is hard to pin down what an operat ing system is other than saying it is the software that runs in kernel mode-and even that is not always true Part of the problem is that operating systems perform two basically unrelated funct ions: pro­ viding applicat ion programmers (and application programs, naturally) a clean abstract set of resources instead of the messy hardware ones and managing these INTRODUCTION CHAP hardware resources Depending on who is doing the talking, you might hear mostly about one function or the other Let us now look at both 1.1.1 The Operating System as an Extended Machine The architecture (instruction set, memory organizat ion, 1/0, and bus struc­ ture) of most computers at the machine language level is primitive and awkward to program, especially for input/output To make this point more concrete, con­ sider how floppy disk 1/0 is done using the NEC PD765 compatible controller chips used on most Intel-based personal computers (Throughout this book we will use the terms "floppy disk" and "diskette" interchangeably.) We use the floppy disk as an example, because, although it is obsolete, it is much simpler than a modem hard disk The PD765 has 16 commands, each specified by loading between and bytes into a device register These commands are for reading and writing data, moving the disk arm, and formatt ing tracks, as well as initializing, sensing, resetting, and recalibrating the controller and the drives The most basic commands are read and write, each of which requires 13 pa­ rameters, packed into bytes These parameters specify such items as the address of the disk block to be read, the number of sectors per track, the recording mode used on the physical medium, the intersector gap spacing, and what to with a deleted-data-address-mark If you not understand this mumbo jumbo, not worry; that is precisely the point-it is rather esoteric When the operation is com­ pleted, the controller chip returns 23 status and error fields pack into bytes ed As if this were not enough, the floppy disk programmer must also be constantly aware of whether the motor is on or off If the motor is off, it must be turned on (with a long startup delay) before data can be read or written The motor cannot be left on too long, however, or the floppy disk will wear out The programmer is thus forced to deal with the trade-off between long startup delays versus wearing out floppy disks (and losing the data on them) Without going into the real deta ils, it should be clear that the average pro­ grammer probably does not want to get too intimately involved with the pro­ gramming of floppy disks (or hard disks, which are worse) Instead, what the pro­ grammer wants is a simple, high-level abstraction to deal with In the case of disks, a typical abstraction would be that the disk contains a collection of named files Each file can be opened for reading or writing, then read or written, and fi­ nally closed Details such as whether or not recording should use modified fre­ quency modulation and what the current state of the motor is should not appear in the abstraction presented to the applicat programmer ion Abstraction is the key to managing complexity Good abstractions turn a nearly impossible task into two manageable ones The first one of these is defm­ ing and implementing the abstractions The second one is using these abstractions to solve the problem at hand One abstraction that almost every computer user understands is the file It is a useful piece of information, such as a digital photo, SEC 1.1 WHAT IS AN OPERATING SYSTEM? saved e-mail message, or Web page Dealing with photos, e-mails, and Web pages is easier than the details of disks, such as the floppy disk described above The job of the operating system is to create good abstractions and then implement and manage the abstract objects thus created In this book, we will talk a lot about ab­ stractions They are one of the keys to understanding operating systems This point is so important that it is worth repeating in different words With all due respect to the industrial engineers who designed the Macintosh, hardware is ugly Real processors, memories, disks, and other devices are very complicated and present difficult, awkward, idiosyncratic, and inconsistent interfaces to the people who have to write software to use them Sometimes this is due to the need for backward compatibility with older hardware, sometimes due to a desire to save money, but sometimes the hardware designers not realize (or care) how much trouble they are causing for the software One of the major tasks of the op­ erating system is to hide the hardware and present programs (and their pro­ grammers) with nice, clean, elegant, consistent, abstractions to work with instead Operating systems turn the ugly into the beautiful, as shown in Fig 1-2 Application programs Operating system Hardware Figure 1-2 Operating systems turn ugly hardware into beaut iful abstract ions It should be noted that the operating system's real customers are the applica­ tion programs (via the application programmers, of course) They are the ones who deal directly with the operating system and its abstractions In contrast, end users deal with the abstractions provided by the user interface, either a command­ line shell or a graphical interface While the abstractions at the user interface may be similar to the ones provided by the operating system, this is not always the case To make this point clearer, consider the normal Windows desktop and the line-oriented command prompt Both are programs running on the Windows oper­ ating system and use the abstractions Windows provides, but they offer very dif­ ferent user interfaces Similarly, a Linux user running Gnome or KDE sees a very different interface than a Linux user working directly on top of the underlying (text-oriented) X Window System, but the underlying operating system abstrac­ tions are the same in both cases INTRODUCTION CHAP In this book, we will study the abstractions provided to application programs in great detail, but say rather little about user interfaces That is a large and impor­ tant subject, but one only peripherally related to operating systems 1.1.2 The Operating System as a Resource Manager The concept of an operating system as primarily providing abstractions to ap­ plication programs is a top-down view A n alternative, bottom-up, view holds that the operating system is there to manage all the pieces of a complex system Modern computers consist of processors, memories, timers, disks, mice, network interfaces, printers, and a wide variety of other devices In the alternative view, the job of the operating system is to provide for an orderly and controlled alloca­ tion of the processors, memories, and I/0 devices among the various programs competing for them Modem operating systems allow multiple programs to run at the same time Imagine what would happen if three programs running on some computer all tried to print their output simultaneously on the same printer The first few lines of printout might be from program 1, the next few from program 2, then some from program 3, and so forth The result would be chaos The operating system can bring order to the potential chaos by buffering all the output destined for the print­ er on the disk When one program is finished, the operating system can then copy its output from the disk file where it has been stored for the printer, while at the same time the other program can continue generating more output, oblivious to the fact that the output is not really going to the printer (yet) When a computer (or network) has multiple users, the need for managing and protecting the memory, 110 devices, and other resources is even greater, since the users might otherwise interfere with one another In addition, users often need to share not only hardware, but information (files, databases, etc.) as well In short, this view of the operating system holds that its primary task is to keep track of which programs are using which resource, to grant resource requests, to account for usage, and to mediate conflicting requests from different programs and users Resource management includes multiplexing (sharing) resources in two dif­ ferent ways: in time and in space When a resource is time multiplexed, different programs or users take turns using it First one of them gets to use the resource, then another, and so on For example, with only one CPU and multiple programs that want to run on it, the operating system first allocates the CPU to one program, then, after i t has run long enough, another one gets to use the CPU, then another, and then eventually the first one again Determining how the resource is time mul­ tiplexed-who goes next and for how long-is the task of the operating system Another example of time multiplexing is sharing the printer When multiple print jobs are queued up for printing on a single printer, a decision has to be made about which one is to be printed next SEC 1.1 WHAT IS AN OPERATING SYSTEM? The other kind of multiplexing is space multiplexing Instead of the customers taking turns, each one gets part of the resource For example, main memory is normally divided up among several running programs, so each one can be resident at the same time (for example, in order to take turns using the CPU) Assuming there is enough memory to hold multiple programs, it is more efficient to hold several programs in memory at once rather than give one of them all of it, espe­ cially if it only needs a small fraction of the total Of course, this raises issues of fairness, protection, and so on, and it is up to the operating system to solve them Another resource that is space multiplexed is the (hard) disk In many systems a single disk can hold files from many users at the same time Allocating disk space and keeping track of who is using which disk blocks is a typical operating system resource management task 1.2 HISTORY OF OPERATING SYSTEMS Operating systems have been evolving through the years In the following sections we will briefly look at a few of the highlights Since operating systems have historically been closely tied to the architecture of the computers on which they run, we will look at successive generations of computers to see what their op­ erating systems were like This mapping of operating system generations to com­ puter generations is crude, but it does provide some structure where there would otherwise be none The progression given below is largely chronological, but it has been a bumpy ride Each development did not wait until the previous one nicely finished before getting started There was a lot of overlap, not to mention many false starts and dead ends Take this as a guide, not as the last word The first true digital computer was designed by the English mathematician Charles Babbage (1792-1871 ) Although Babbage spent most of his life and for­ tune trying to build his "analytical engine," he never got it working properly be­ cause it was purely mechanical, and the technology of his day could not produce the required wheels, gears, and cogs to the high precision that he needed Need­ less to say, the analytical engine did not have an operating system As an interesting historical aside, Babbage realized that he would need soft­ ware for his analytical engine, so he hired a young woman named Ada Lovelace, who was the daughter of the famed British poet Lord Byron, as the world's first ® programmer The programming language Ada is named after her 1.2.1 The First Generation (1945-55) Vacuum Tubes After Babbage's unsuccessful efforts, little progress was made in constructing digital computers until World War II, which stimulated an explosion of activity Prof John Atanasoff and his graduate student Clifford Berry built what is now INTRODUCTION CHAP regarded as the first funct ioning digital computer at Iowa State University It used 300 vacuum tubes At about the same t ime, Komad Zuse in Berlin built the Z3 computer out of relays In 1944, the Colossus was built by a group at Bletchley Park, England, the Mark I was built by Howard Aiken at Harvard, and the ENIAC was built by William Mauchley and his graduate student J Presper Eckert at the University of Pennsylvania Some were binary, some used vacuum tubes, some were programmable, but all were very primitive and took seconds to perform even the simplest calculation In these early days, a single group of people (usually engineers) designed, built, programmed, operated, and maintained each machine All programming was done in absolute machine language, or even worse yet, by wiring up electrical cir­ cuits by connecting thousands of cables to plugboards to control the machine's basic functions Programming languages were unknown (even assembly language was unknown) Operating systems were unheard of The usual mode of operation was for the programmer to sign up for a block of time using the signup sheet on the wall, then come down to the machine room, insert his or her plugboard into the computer, and spend the next few hours hoping that none of the 20,000 or so vacuum tubes would bum out during the run Virtually all the problems were sim­ ple straightforward numerical calculations, such as grinding out tables of sines, cosines, and logarithms By the early 1950s, the routine had improved somewhat with the introduct ion of punched cards It was now possible to write programs on cards and read them in instead of using plugboards; otherwise, the procedure was the same 1.2.2 The Second Generation (1955-65) Transistors and Batch Systems The introduction of the transistor in the mid-1950s changed the picture radi­ cally Computers became reliable enough that they could be manufactured and sold to paying customers with the expectation that they would continue to func­ tion long enough to get some useful work done For the frrst t ime, there was a clear separat ion between designers, builders, operators, programmers, and ma inte­ nance personnel These machines, now called mainframes, were locked away in specially air­ condit ioned computer rooms, with staffs of professional operators to run them Only large corporat ions or major government agencies or universit could afford ies the multimillion-dollar price tag To run a job (i.e., a program or set of pro­ grams), a programmer would first write the program on paper (in FORTRAN or assembler), then punch it on cards He would then bring the card deck down to the input room and hand it to one of the operators and go drink coffee unt the il output was ready When the computer finished whatever job it was currently running, an opera­ tor would go over to the printer and tear off the output and carry it over to the out­ put room, so that the programmer could collect it later Then he would take one of SEC 1.2 HISTORY OF OPERATING SYSTEMS the card decks that had been brought from the input room and read it in If the FORTRAN compiler was needed, the operator would have to get it from a file cabinet and read it in Much computer time was wasted while operators were walking around the machine room Given the high cost of the equipment, it is not surprising that people quickly looked for ways to reduce the wasted time The solution generally adopted was the batch system The idea behind it was to collect a tray full of jobs in the input room and then read them onto a magnetic tape using a small (relatively) inexpen­ sive computer, such as the IBM 1401, which was quite good at reading cards, copying tapes, and printing output, but not at all good at numerical calculations Other, much more expensive machines, such as the IBM 7094, were used for the real comput ing This situation is shown in Fig 1-3 card reader System tape Tape drive �m § § § r -1 liiiiiiA = Y 1111111111111111111111 � 0 : (b) 0 : 0 1111111111111111111111 1401 (a) Output tape 0 : "'\ 1401 7094 (c) (d) (e) (f) Figure 1-3 An early batch system (a) Programmers bring cards to 1401 (b) 1401 reads batch of jobs onto tape (c) Operator carries input tape to 7094 (d) 7094 does computing (e) Operator carries output tape to 1401 (f) 1401 prints output After about an hour of collecting a batch of jobs, the cards were read onto a magnetic tape, which was carried into the machine room, where it was mounted on a tape drive The operator then loaded a special program (the ancestor of today's operating system), which read the first job from tape and ran it The out­ put was written onto a second tape, instead of being printed After each job fm­ ished, the operating system automatically read the next job from the tape and began running it When the whole batch was done, the operator removed the input and output tapes, replaced the input tape with the next batch, and brought the out­ put tape to a 1401 for printing off line (i.e., not connected to the main computer) The structure of a typical input job is shown in Fig 1-4 It started out with a $JOB card, specifying the maximum run time in minutes, the account number to be charged, and the programmer' s name Then came a $FORTRAN card, telling the operating system to load the FORTRAN compiler from the system tape It was directly followed by the program to be compiled, and then a $LOAD card, di­ rect ing the operating system to load the object program just compiled (Compiled INDEX 1062 Multiprocessor operating Mounting, 58 Mouse software, 399 MP3 (see MPEG audio layer 3) MPEG (see Motion Picture Experts Group) MPEG audio layer 3, 484 487 MPEG standard, 481 484 MPI (see Message-Passing Interface) MS-DOS (see MkroSoft Disk Operating System) system types, 534-538 Multiprocessor sc heduling 542-548 , Multiprocessor synchronization, 538-54 Multiprogramming, 12, 84-86 modeling, 93-95 Multisession CD-ROM, 372 Multistage swi tc hing network, 529-531 Multithreaded code, J 4-J J MS-DOS 1.0, 814 Multithreading, 22, 10 I MS-DOS-based Windows, 815 Murphy's law, 1 MS-DOS file system, 8-321 Mutation engine, 698 Multicomputer, 548-568 Mutex, 130-134 Multicomputer hardware, 549-553 Mutexes in Pthreads, 132 Multicomputer scheduling, 565 Mutual exclusion, 1 Multicore chip, 22-23, 533, 579-580, 999-1000 busy waiting, 22 MULTICS (see MULTiplexed Information disabling interrupts, I 20-121 and Computing Service) lock variable, Multilevel page table, 198-200 Peterson' s solution, 123-124 Multilevel security, 634-636 priority inversion, 126 Multimedia, 467-518, 1001 sleep and wakeup, 125-126 Multimedia caching, 510-513 Multimedia disk scheduling, 513-516 Multimedia file placement, 499-5 10 Multimedia file system, 493-5 near video on demand, 504-506 organization, 499-504 Multimedia files, 472 478 Multimedia in Symbian, 937 spin lock, 122 alternation, 12 1-122 busy waiting, 120-125 Mythical man month, 994 strict with N Multimedia operating systems, 467-5 18 audio encoding, 484 487 Naming, 977 introduction, 468 72 Naming transparency, 593-594 process scheduling, 487 493 Nanokernel, Symbian, 935 research, 51 6-5 17 Nanothread, Symbian, 938-939 video encoding, 473 476 Narrow striping, Multimedia scheduling, 487 493 NC-NUMA Multimedia server, 494 Near video on demand, 496 499 Multiple-processor system research, 604-605 Network device, 778 Multiple queue scheduling, 156-158 Network file system, 290, 796-802 MULTiplexed (see N Cache NUMA multiprocessor) o lnformation and Computing Service, architecture, 797 13-15, 49, 238-242, 720 Multiplexing, 6-7 Multiprocessor, 84, 526-548 Multiprocessor hardware, 526-534 Multiprocessor operating system, 34-35, 534-548 implementation, 800-802 protocol s, 797-800 version 4, 802 Network hardware, 583-586 Network interface, 551-553 Network operating system, 18 1063 INDEX Network processor, 553 Object file, 74 Network protocol, 587, 587-589 Ob ject manager, 824 Network service, 586-587 Networking, 1000-1001 Vista, 842 Object name space, Vista, 852-858 Linux, 773-775 Object orientation, Symbian, 933-934 Symbian, 936 Object request broker, 596 New technology file system, 906-9 18 Off-line operation, New technology operating system, 820 Omega network, 529 Next fit algorithm, 186 One-shot mode, 389 NFS (see Network File System) One-time password, 649-650 NFU (see Not Frequently Used algorithm) One-way function, 619 No cache NUMA multiprocessor, 531 One-way hash cha 649 in, No silver bullet, 998 Ontogeny recapitulates phylogeny, 46-49 Nonblocking call, 555-558 Open file descript ion table, L inux, 794 Nonblocking network, 528 Operat ing system, Noncanonical mode, 396 as a resource manager, 6-7 Nonpreemptable resource, 434-435 as extended machine, 4-5 Nonpreempt ive scheduling, 148 Berkeley UNIX, 723-724 Nonresident attribute, NTFS, 910 BSD, 13 Nonuniform memory access, 876 FreeBSD, 18 Nonuniform memory access multiprocessor, history, 7-18 531-533 Linux, 5, 15, 19-806 Nonvolat RAM, 387 ile �INIX, 14, 65-67, 7256 Not frequently used algorithm, 207-208 PDP-1 UNIX, 721-722 Not recently used algorithm, 203-204 Portable UNIX, 722-723 Notification event, 870 Standard UNIX, 724-725 Notification object, 841 UNIX, 18 NRU (see Not Recently Used algorithm) Windows 2000, 17, 3, 817 NT (see Windows NT) Windows 2003, 818 NT-based Windows, 815-818 Windows 3.0, 816 NT namespace, 824 Windows 95, 3, 815 NTFS (see New Technology File System) Windows 98, 3, 815 NTOS (see New Technology Operating System) Windows �e, 17, 3, 815 NUMA multiprocessor (see Nonuniform Windows NT, 17, memory access multiprocessor) Nyquist theorem, 477 Windows NT 4.0, 817 Windows server 2008, 813 Windows Vista, 3, 813-926 Windows XP, 17, 3, 817 Operat ing system concepts, 37-49 Operat ing system design, 959-1003 brute force, 985-986 Object, 596, 625, 824, 842, 848, 852, 853, 854, 855, 856, 857 caching, 991-992 error checking, 986 Object adapter, 597 exploiting locality, 993 Object-based rniddleware, 596-597 goals, 960-961 Object cache, Linux, 767 hiding the hardware, 981-984 1064 INDEX Operating system design (continued) hints, 992-993 Page directory, 245 Symbian, 943 implementation, 971-986 Page fault, 191 interfaces, 963-970 Page fault frequency algorithm, 217-218 paradigms, 965-968 Page-fault handling, 228-229 performance optimization, 987-994 principles, 963-965 reentrancy, 985 Linux, 768-771 Vista, 886-890 Page frame, 190 space-time tradeoffs, 988-991 Page frame number database, Vista, 891 trends, 998-1003 Page frame reclaiming algorithm, 768-771 why i s it hard?, 961-963 Page replacement algorithm, 201-216, 769 Operat ing system structure, 62-72 aging, 208 client-server, 67 clock, 205-206 layered, 63-64 first-in first-out, 204 microkemel, 64-67 global, 216-217 monolithic, 62-63 least recently used, 206-207 virtual machine, 67-71 Linux, 768-771 Optimal page replacement algorithm, 202-203 local, 216-217 Optimization, goals, 988 not frequently used, 207-208 Optimizing the common case, 993 not recently used, 203-204 Orange book, 371 optimal, 202-203 ORB (see Object Request Broker) page fault frequency, 217-218 Organ-pipe algorithm, 507 second-chance, 204-205 Orthogonality, 976-977 summary of, 215-216 OS/2, 815 Vista, 890-891 OS/360, 11-12 working set, 209-213 Ostrich algorithm, 441 WSclock, 213-214 Output software, 399-414 Page size, 19-220 Overlapped seek, 361 Page table, 192-194 Overlay, 188 Overview of Linux, 728-739 Overwriting virus, 674 inverted, 200-201 multilevel, 198-200 Page table, large memory, 198 Page table entry, 193-194 Pagefile, Vista, 881-883 Paging, 189-192 p copy-on-write, 223 implementation, 227-234 instruct ion backup, 229-230 P operation, 128 locking pages, 230-231 P1003.1 , 724 optimizat ion, 194-198 Packet sniffer, 646 separation of policy and mechanism, 233-234 PAE (see Physical Address Extension) shared pages, 221-223 Page, 188-192 Paging daemon, 226 Page allocator, 766 Paging in Linux, 768-771 Page daemon, 769 Paging systems, design issues, 216-227 Page descriptor, Linux, 763 Parallel systems, 1001 1065 INDEX Parasitic virus, 675 Pipe symbol, 733 Paravirt ops, 576 Pipeline, 20-21, 734 Paravirtualizat ion, 71, 574-576 Pit, CD-ROM, 367-368 Parent process, 740 Pixel, 475 Partit ion, 12, 33, 58, 231, 288, 312, 319, 320, PKI (see Public Key Infrastructure) 379, 677, 769, 790 Plaintext, 617 Password, 263, 626, 642-653, 657, 658 Play point, 498 Password security, UNIX, 647-648 Plug and play, 32, 843, 897 Paterson, Tim, 16 Pointer, in C, 72-73 Path name, 42, 269-272 POLA (see Principle of Least Authority) absolute, 269 relative, 270 Policy vs mechanism, 67, 161-162, 233-234, 975-976 Payload, virus, 673 Polling, 346 PCI bus, Polymorphic virus, 698 PCI Express, Pop-up thread, 12-114, 558 PDA (see Personal Digital Assistant) Port, 646 PDP- 1, 14 Portable C compiler, 722 PDP- 1 , 721, 722 Portable UNIX, 722-723 PDP- 1 UNIX, 721-722 Port number, 694 PEB (see Process Environment Block) Port scan, 646 Pentium, 17 Position-independent code, 225 Pentium, segmentation, 242-237 POSIX, 14, 50-59, 724 Perceptual coding, 484 POSIX threads, 104-106 Perfect shuffle, 529 Power management, 417-425 Performance, 987-994 application issues, 424-425 Per iodic real-time system, 161 battery, 423-424 Peripheral component interconnect, CPU, 421-422 Personal computer operating system, 35 disk, 420-421 Personal digital assistant, 35 display, 419-420 Personal firewall, 695 hardware issues, 418-419 Peterson, G.L., 123 memory, 422 Peterson's solution, 123 operating system issues, 419 PFF (see Page fault frequency algorithm) thermal, 423 PFN database (see Page Frame Number database) PFRA (see Page Frame Reclaiming Algorithm) wireless communication, 422-423 Power manager, Vista, 905 PowerShell, 830 Preamble, 332 Physical address extension, 767, 888 Precise interrupt, 341-342 Physical dump, 300 Preemptable resource, 434-435 Physical memory management, Preemptive scheduling, 149 Linux, 762-766 Prepaging, 210, 886, 889 Vista, 891-894 Present/absent bit, 191 PID (see Process IDentifier) Primary volume descriptor, 313 Pidgin Pascal, 136-138 Principal, 625, 78 Pinned page, 230-231, 763 Principle ofieast authority, 623 Pipe, 43, 741 Printer daemon, 1 1066 Priority inversion, 126, 878 INDEX Project management, 994-998 Priority scheduling, 155-156 bad-news diode, 996 Privacy, 614 chief programmer team, 996 Privilege escalation attack, 667 mythical man month, 994 Privileged instruct ion, 571 no silver bullet, 998 Process, 38-40,83-170, 91-93 role of experience, 997 compute-bound, 147 second-system effect, 997 implementation in Linux, 745-752 team structure, 995-997 input/output-bound, 147 IPC Linux, 739-757 Prompt, 45 shell, 732 IPC Symbian, 936, 937-941 Proportionality, IPC Vista, 861-879, 862-863 Protection, 44 Process behavior, 147-148 Protection command, 633 Process control block, 91 Protection domain, 622-624 Process creation, 86-88 Protection hardware, 47-48 Process environment block, Vista, 862 Protection mechanism, 613, 622-64 Process group, 741 Protection ring, 246 Process hierarchy, 89 Protocol, 587 Process ID, 54 BFS, 798 Process identifier, 740 communication, 458 Process management, Linux, 741-745 Symbian, 955-956 Process manager, Vista, 843 Protocol stack, 588 Process model, 84-86 PRT module, Symbian, 956 Process scheduling, Linux, 752-755 Pseudoparallelism, 84 multimedia, 487-493 Psion, 930-93 Process state, 90 PSW, 20 Process switch, 154 Psychoacoustics, 484 Process table, 38, 91 Pthreads, 104-106, 132-134 Process termination, 88-89 Public-key cryptography, 618-619 Processor, 19-23 Public key infrastructure, 621 Processor allocation algorithm, 566 Publish/subscribe, 600, 601 graph-theoretic, 566-567 Publish/Subscribe system, 600 601 receiver-init iated, 568 Pull server, multimedia, 494 sender-initiated, 567-568 Pulse code modulation, 477 Processor sharing, 172 Push server, multimedia, 494 Producer-consumer problem, 126 with Java, 139-141 with message passing, 142-144 with monitors, 137-139 with Pthreads, 135 with semaphores, 129-130 Q Quality of service, 471, 586 Program counter, 20 Quantization, 479 Program status word, 20 Quantization noise, 477 Programmed input/output, 344-346 Quantum, 154 Programming Vista, 819-831 Quick-fit algorithm, 187 Progressive video, 475 Quota, 297, 298, 850 1067 INDEX R Rendezvous, 144 Reparse point, Vista, 908, 1 , 915 R-node, 801 NFS, 801 Replication, 563 Request matrix, 444 Race condition, 117-119, 127 Request-reply service, 587 RAID (see Redundant Array of Research, Inexpensive Disks) deadlock, 461 RAM (see Random Access Memory) file system, 324 Random access file, 262 input/output, 425-426 Random access memory, 25 memory management, 247 Rate monotonic scheduling, 490-49 multimedia operating system, 516-517 Raw block file, Linux, 778 multiple-processor system, 604-605 Raw mode, 396 operating systems in general, 76-77 Read ahead, 310 processes and threads, 168-169 NFS, 802 security, 71 1-712 Read-only memory, 25 Reserved page, Vista, 881 Readers and writers problem, 167-168 Resource, 404, 434-437 Readyboost, Vista, 896 nonpreemptable, 434-435 Readyboot, Vista, 896 preemptable, 434-435 Real time, 390 Resource acquisition, 435-437 Real-time operating system, 36-37 Resource deadlock, 437-438 Real-time scheduling, 160-163, 488-493 Resource trajectories, 449-450 Recovery console, Vista, 848 Response time, 151 Recovery from deadlock, 447-448 Restricted token, Vista, 863 through killing processes, 448 Return to libc attack, 664-665 through preemption, 447 Reusability, 984-985 through rollback, 447-448 Right, 622 Recycle bin, 299 RMS (see Rate Monotonic Scheduling) Red book, CD-ROM, 367 Rock ridge extensions, 316-317 Redundant array of inexpensive disks, Role, 626 363-367 Role of experience, 997 Reed-Solomon code, 370 Root, 804 Reentrancy, 985 Root directory, 42, 268 Reentrant device driver, 352 Root file system, 42 Reference monitor, 708 Rootkit, 688-692 Referenced pointer, 850 Sony, 691-692 Regedit, 830 types, 688-689 Registry, Windows, 829 Rootkit detection, 689-691 Regular flle, 260 Round, 513 Reincarnation server, 66 Round robin scheduling, 154-155 Relative path, 781 Router, 459, 585 Relative path name, 270 RPC (see Remote Procedure Call) Remote access model, 591-592 RSA (Rivest-Shamir-Adelman) algorithm, 619 Remote procedure call, 558-560 Run time for C programs, 75 implementation, 559-560 Removable media, Symbian, 948 Runqueue, Linux, 753 RWX bits, 44 1068 INDEX s Scheduling mechanism, 161 SACL (see System Access Control List) Script kiddy, 647 Safe-boot, Vista, 847 SCSI (see Small Computer System Interface) Safe state, 450-451 Second-chance algorithm, 204-205 Salt, 648 Second-generation computer, Scheduling policy, 161 Sandboxing, 706-708 Second-system effect, 997 SATA disk (see Serial ATA disk) Secret-key cryptography, 617-618 Scan code, 395 Sect ion, 823 Scan-EDF algorithm, 515 Secure hash algorithm- I, 620 Schedulable real-time system, 161 Secure hash algorithrn-256, 620 Scheduler, 145 Secure hash algorithm-512, 620 Linux disk, 778-779 Secure system, formal model, 632-634 Scheduler activations, 1 1-112 Secure virtual machine, 571 Scheduling, when to do, 148-149 Security, 611-713 Scheduling algorithm, 145-163 affinity, 545 batch system, 149-150, 152-154 Linux, 803-806 Symbian, 949-953 Vista, 91 8-924 categories, 149 Security by obscurity, 617 earliest-deadline-first, 491-493 Secur descriptor, Vista, 823, 920 ity fair-share, 160 Security identifier, 919 first-come first-served, 152-153 Security in Symbian, 950-953 gang, 546-548 Secur in Vista, 918-924 ity goals, 150-152 Secur reference monitor, Vista, 844 ity guaranteed, 158-159 Security research, 71 1-712 interact ive system, 150-15 , 154-160 Security system calls, introduction, 145-152 Linux, 805 Linux, 752-755 Vista, 921-922 lottery, 159 Segment, 235 multicomputer, 565 data, 55-56 multimedia, 487-493 stack, 55-56 multiple-queue, 156-158 text, 55-56 multiprocessor, 542-548 nonpreemptive, 149 preemptive, 149 Segmentation, 234-246 implementation, 237-238 Segmentation with paging, 238-247, priority, 155-156 MULTICS 238-242 rate-monotonic, 490-49 Pentium, 242-247 real-time, 150, 152, 160-163, 488-493 Self-map, Vista, 872, 889 round-robin, 154-155 Semant ics of file sharing, 594-596 shortest-job-first, 153-154 Semaphore, 128-130 shortest-process-next, 158 binary, 129 shortest-remaining-time-next, 154 Send and receive primit ives, 555 smart, 544 Sensitive instruct ion, 571 thread, 162-163 Sensor node, 1003 two-level, 545 Sensor node operating system, 36 Vista, 874-879 Separate instruction and data space, 221 1069 INDEX Separation of policy and mechanism, 233-234 Smart card, 651-653 Sequential access, 262 Smart card operating system, 37 Sequential consistency, 564-565, 594 Smart scheduling, 544 Sequential process, 84 SMP (see Symmetric MultiProcessor) Serial ATA disk, 361 Snooping, 533 Server, 67 Socket, 773, 868 Server operating system, 34 Symbian, 940-941 Server stub, 559 Soft fault, Vista, 881, 889 Session, CD-ROM, 372 Soft real time, 160 Session semantics, 595 Soft real-time operating system, 36-37 Set-top box, 470 Soft timer, 393-394 SETUID bit, 804 Sony rootkit, 691-692 SHA-1 (see Secure Hash Algorithm- I) Source code virus, 679-680 SHA-256 (see Secure Hash Algorithm-256) Space sharing, 545 SHA-512 (see Secure Hash Algorithm-5 12) Space-time trade-offs, 988-991 Shadow page table, 577 Sparse file, Vista, 912 Shared file, 283-285 Special file, 43 Shared hosting, 69 Special file, Linux, 772 Shared library, 223-225 Spin lock, 122, 539 Shared lock, 784 Spinning vs switching, 541-542 Shared-memory multiprocessor, 526-548 Spooler directory, 117-118 Shared page, 221-223 Spooling, 12, 359 Shared text segment, 60 Spooling directory, 359 Shell, 38, 1, 44-46, 731-734 Spyware, 684-688 Shell script, 734 Shellcode, 664 actions taken, 687-688 Square-wave mode, 389 Short name, Vista, 910 Stable storage, 385-388 Shortest-job-first scheduling, 153-154 Stack pointer, 20 Shortest-process-next, 158 Stack segment, 55-56 Shortest-remaining-time-next scheduling, 154 Standard error, 733 Shortest-seek-first algorithm, 380 Standard input, 733 SID (see Security Identifier) Standard output, 733 Side-by-side versions, Vista, 860 Standard UNIX, 724-725 Side-channel, 653 Standby list, Vista, 882 Signal, 741 Standby mode, Vista, 906 Signals, in mult ithreaded code, 1 Star property, 635 Signature block, 620 Starvation, 165,461 Simple security property, 635 Stateful firewall, 695 Single-indirect block, 322, 795 Stateful server, 802 Single-interleaved disk, 378 Stateless firewall, 694 Single large expensive disk, 363 Stateless server, 799 Single-level directory system, 268 Static disk scheduling, multimedia, 513-515 Skeleton, 596 Static relocation, 179 SLED (see Single Large Expensive Disk) Static vs dynamic structures, 979-980 Sleep and wakeup, 125-126 Steganography, 639-641 Small computer system interface, 32 Storage allocation, Vista, 12-9 15 1070 INDEX Store-and-forward packet switching, 550 Symmetric-key cryptography, 617-618 Stored value card, 651 Symmetric multiprocessor, 536-538 Strict alternation, 121-122 Synchronization, 130 Striping, disk, 364 barrier, 144-145 Structure, operat ing system, 971-975 Stub, 559,560,596 Vista, 869-871 Synchronization event, 870 Subject, 625 Synchronization object, 841 Superblock, 274, 789 Synchronized method, java, 139 Linux, 790 Synchronous call, 555-558 Superfetch, Vista, 886 Synchronous input/output, 344 Superscalar CPU, 20-21 System access control list, 920 Superuser, 39, 804 System availability, 614 Supervisor mode, System call, 21 Svchost.exe, 861 directory management, 57-59 SVID (see System V Interface Definit ion) file management, 56 SVM (see Secure Virtual Machine) Linux file system, 785-788 Swap area, 769 Linux input/output, 775-779 Swapper process, 768 Linux memory management, 761-762 Swappiness, 770 Linux process management, 741-745 Swapping, 181-184 Linux security, 805-806 Symbian, 929-1003 miscellaneous, 58-59 history, 930-932 process management, 52-56 overview, 932-937 Vista input/output, 898-900 Symbian active object, 939-940 Vista memory management, 884-885 Symbian application engine, 930 Vista process management, 869-871 Symbian communication, 937, 953-957 Vista security, 921-922 Symbian device driver, 945-946 System call interface, 968-970 Symbian DMA, 946-947 System calls, 49-61 Symbian features, 936-937 System on a chip, 534 Symbian file system, 936, 948-953 System process, Vista, 866 Symbian handle, 933 System structure, 971-975 Symbian history, 930-932 System V, 14 Symbian input/output, 945-948 System V interface definition, 724 Symbian kernel layer, 935 Symbian memory management, 937, 941-945 Symbian microkernel, 934 Symbian modules, 955-956 T Symbian multimedia, 937 Symbian nanokernel, 935 Tagged architecture, 628 Symbian nanothread, 938-939 Tape, 27 Symbian networking, 936 Task, Linux, 746 Symbian object orientation, 933-934 TCB (see Trusted Computing Base) Symbian process, 936, 937-941 TCP (see Transmission Control Protocol) Symbian security, 950-953 TCP/IP, 724 Symbian thread, 938-939 Team structure, 995-997 Symbolic link, 273, 283 TEB (see Thread Environment Block) 1071 INDEX Template, Linda, 599 Transmission control protocol, 588, 774 Temporal masking, 486 Transparency, Termcap, 400 location, 593-594 Terminal, 394 naming, 593-594 Text segment, 55-56, 758 Trap, 21-22, 657 Text window, 400 Trap door, 657 Thermal management, 423 TRAP instruction, 51-52 Thin client, 415-417 Trends in operating system design, 998-1003 THINC (see THIN Client) distributed systems, 1001 Third generation computer, 10-15 embedded systems, 1002 Thompson, Ken, 14 large address spaces, 1000 Thrashing, 209 mobile devices, 1002 Thread environment block, Vista, 862 multicore chips, 999-1000 Thread local storage, Vista, 862 multimedia, 1001 Thread model, classical, 100-104 networking, 1000-1001 Thread scheduling, 162 parallel systems, 1001 Thread usage, 95-100 sensors, 1003 Threads, 95-117 virtualization, 999 hybrid implementation, 10-1 1 Triple-indirect block, 322, 795 kernel space implementation, 109-110 Trojan horse, 670-672 Linux, 748-752 Trusted computing base, 631-632 POSIX, 104-106 Trusted platform module, 621 Symbian, 938-939 Trusted system, 630-63 user space implementation, 106-109 TSL instruct ion, 124-125 Vista, 864-879 Threat, 613-614 TSY module, Symbian, 956 TTBR (see Translat ion Table Base Register) Throughput, 151 Tuple, 598-599 Tightly coupled system, 525 Tuple space, 598-599 Time bomb, 657 Turnaround time, 151 Time-space tradeoffs, 988-991 Two-level scheduling, 545 Timer, 388-394 Two-Phase locking, 457-458 Timesharing, 12-14 Type hypervisor, 570, 571-572 multiprocessor, 543-545 Type hypervisor, 570, 572-573 TLB (see Translation Lookaside Buffer) Token, 828 Top-Down implementation, 980-981 TPM (see Trusted Platform Module) u Transactional memory, 863 Transfer model, 591-592 remote access model, 591-592 upload/download model, 591 Translation lookaside buffer, 195-197, 196, 197-198, 885 hard miss, 198 soft miss, 198 Translation table base register, 943 UAC (see User Account Control) UDF (see Universal Disk Format) UDP (see User Datagram Protocol) UID (see User ID) UMA multiprocessor, bus-based, 526-527 crossbar switched, 527-529 with multistage switching, 529-531 1072 INDEX UMA multiprocessor (see Uniform Memory Access multiprocessor) VAD (see Virtual Address Descriptor) Vampire tap, 583 UMDF (see User-Mode Driver Framework) VCR Control Functions, 494 Unbuffered input/output, Vista, 895 VFS (see Virtual File System) Undefined external, 223 Video compression, 478-484 Unicode, 824 Video decoding, 478 UNICS, 720-721, 721 FONT Video encoding, 473-476, 478-484 Uniform memory access mult iprocessor, Video on demand, 468 526-531 Video RAM, 406 Uniform naming, 343 Video server, 469 Uniform resource locator, 590-591 Virtual address, 189-192 Universal coordinated time, 389 Virtual address allocation, Vista, 881 Universal disk format, 276 Virtual address descriptor, 885 Universal serial bus, 32 Virtual address space, 189-192 UNIX, (see also Linux) Berkeley, 723-724 history, 721-725 FONT ON ALL UNIX PDP- 1 , 721-722 portable, 722-723 standard, 724-725 UNIX Password Security, 647-648 UNIX V7 File system, 321 Unsafe state, 450-45 Upcall, 112 Upload/download model, 591-592 URL (see Uniform Resource Locator) USB (see Universal Serial Bus) User account control, 923 User datagram protocol, 774 User-friendly system, User ID, 39 Linux, 803 User interface paradigms, 965 User mode, User-mode driver framework, 901 User shared data, Vista, 862 UTC (see Universal Coordinated Time) Linux, 767-768 Virtual appliance, 579 Virtual disk, 573 Virtual file system, 288 Linux, 788-789 Virtual kernel mode, 571 Virtual machine, 570, 67-71 rediscovery, 69-71 Virtual machine interface, 575 Virtual machine monitor, 68-70, 570 Virtual memory, 26-27, 49, 182, 88-247 design issues, 216-227 MULTICS, 238-242 page replacement algorithms, 201-216 paging, 189-192 Pent ium, 242-247 Virtual memory interface, 226-227 Virtualizat ion, 568-580, 999 input/output, 578-579 licensing issues, 580 memory, 576-577 requirements, 570-571 Virtualization technology, 571 Virus, 672 boot sector, 677-678 cavity, 676 v companion, 673 device driver, 678-679 executable program, 674-676 V-node, 290, 801 macro, 679 V-node, NFS, 800 memory resident, 676-677 V operation, 128 operation of, 673 1073 INDEX Virus (continued) NtCreateProcess, 821, 823, 853, 867 overwriting, 674 NtCreateThread, 824, 867 parasitic, 675 NtCreateUserProcess, 872, 873 polymorphic, 698 NtDeviceloControlFile, 900 source code, 679-680 NtDuplicateObject, 824 Virus avoidance, 700-701 NtFlushBuffersFile, 900 Virus dropper, 673 NtFsControlFile, 900, 917 Virus payload, 673 NtLockFile, 900 Virus scanner, 695-699 NtMapViewOfSection, 824 Vista, 3, 813-926 NtNotifyChangeDirectoryFile, 900, 917 history, 818-819 NtQueryDirectoryFile, 899 Vista access control list, 828 NtQuerylnformationFile, 900 Vista access token, 919 NtQueryVolumelnformationFile, 899 Vista access violat ion, 888 NtReadFile, 899 Vista affinitized thread, 862 NtReadVirtualMemory, 824 Vista alternate data stream, 912 NtResumeThread, 873 Vista and large memories, 883-884 NtSetlnformationFile, 900 Vista API call, NtSetVolumelnformationFile, 899 AddAccessAllowedAce, 921 NtUnlockFile, 900 AddAccessDeniedAce, 922 NtWriteFile, 899 CreateDirectory, 61 NtWriteVirtualMemory, 824 CreateFile, 827, 857, 921 ObCreateObjectType, 857 CreateFileMapping, 885 ObOpenObjectByName, 855 CreateProcess, 60, 88, 821, 866, 871, 872, OpenSemaphore, 851 873, 921, 969 ProcHandle, 824 CreateSemaphore, 851, 869 PulseEvent, 870 DeleteAce, 922 QueueUserAPC, 840 DuplicateHandle, 869 ReadFile, 915 Ente:rCriticalSection, 870, 993 ReleaseMutex, 870 ExceptPortHandle, 823 ReleaseSemaphore, 869 ExitProcess, 60, 88 RemoveDirectory, FlushFileBuffers, 309 ResetEvent, 870 GetFileAttributesEx, 61 Sect ionHandle, 823 GetLocalTime, 61 SetCurrentDirectory, 61 GetTokenlnformation, 919 SetEvent, 870 InitializeAcl, 921 SetFilePointer, 61 InitializeSecurityDescriptor, 921 SetPriorityClass, 875 IoCallDriver, 901, 902 SetSecurityDescriptorDacl, 922 IoCompleteRequest, 901, 915 SetThreadPriority, 875 IopParseDevice, 855, 856 SwitchToFiber, 864 LeaveCriticalSection, 870 TerminateProcess, 89 LookupAccountSid, 921 ValidDataLength, 895 NtAllocateVirtualMemory, 824 WaitForMultipleObjects, 841, 848, 869, 926 NtCancelloFile, 900 WaitForSingleObject, 60, 869, 870 NtClose, 853, 854 Vista application verifier, 852 NtCreateFile, 824, 853, 855, 899, 900 Vista balance set manager, 891 1074 INDEX Vista bandwidth reservat ion, 898 Vista master file table, 908 Vista bank switching, 883 Vista memory manager, 844 Vista base priority, 875 Vista memory pressure, 891 Vista base record, 908 Vista mini-port, 847 Vista boot drivers, 847 Vista modified page wr iter, 893 Vista cache manager, 844 Vista nonresident attribute, 910 Vista class driver, 847 Vista object manager, 842 Vista committed page, 881 Vista object name space, 852-858 Vista configuration manager, 844 Vista page fault handling, 886-890 Vista context data structure, 865 Vista page frame number database, 891 Vista current priority, 875 Vista page replacement algorithm, 890-891 Vista default data stream, 912 Vista pagefi1e, 881-883 Vista device driver, 901-902 Vista physical memory management, 891-894 Vista device drivers, 845-847 Vista power manager, 905 Vista device object, 845 Vista process, 861-879, 862-863 Vista device stack, 845, 904-906 Vista process API calls, 866-87 Vista discretionary acl, 919 Vista process environment block, 862 Vista driver object, 897 Vista process manager, 843 Vista driver ver ifier, 901 Vista readyboost, 896 Vista dynamic disk, 897 Vista readyboot, 896 Vista executive, 836 Vista recovery console, 848 Vista executive layer, 841-845 Vista reparse points, 908, Vista file compression, 6-917 Vista restricted token, 863 Vista f encryption, 917-918 ile Vista safe-boot, 847 Vista f system, 906-9 18 ile Vista scheduling, 874 879 Vista file system structure, 908-912 Vista security API calls, 921-922 Vista filter, 845 Vista security descriptor, 920 Vista fllter driver, 904 Vista security reference monitor, 844 Vista handle, 850-852 Vista self-map, 872, 889 Vista hard fault, 889 Vista short name, Vista hibernation, 905 Vista side-by-side versions, 860 Vista hive, 829 Vista soft fault, 881, 889 Vista ideal processor, 876 Vista sparse files, 912 Vista immediate file, Vista standby list, 882 Vista impersonation, 920 Vista standby mode, 906 Vista import address table, 859 Vista storage allocation, 2-915 Vista input/output API calls, 898 Vista structure, 831-861 Vista input/output completion port, 900 Vista superfetch, 886 Vista input/output manager, 842 Vista synchronization, 869-871 Vista interprocess communication, 868-869 Vista system process, 866 Vista invalid page, 881 Vista thread environment block, 862 Vista jobs and fibers, 863-864 Vista thread local storage, 862 Vista journaling, 917 Vista threads, 864-879 Vista kernel, 832, 836-838 Vista unbuffered input/output, 895 Vista key, 848 Vista user shared data, 862 Vista mapped page writer, 893 Vista virtual address allocation, 881 1075 INDEX Vista volume shadow copy, 897 Windows NT 4.0, 817 Vista zeropage thread, 893 Windows NT API, 822-825 VM/370, 68-69 Windows on Windows, 825-826 VMI (see Virtual Machine Interface) Windows registry, 829 VMS, 17 Windows server 2008, 813 VMware, 70, 572 Windows subsystem, 820 Volume shadow copy, Vista, 897 Windows Vista (see Vista) Volume table of contents, 372 Windows XP, 17, 3, 817 VT (see Virtualization Technology) Wireless communication, 422 VTOC (see Volume Table Of Contents) WndProc, 409 Worker thread, 98 Working directory, 42, 270-271, 781 w Working set, 209 Working set algorithm, 209-2 13 Working set model, 210 WaitForMultipleObject, 841 Worm, 682-684 Waitqueue, Linux, 755 Wormhole routing, 551 Wakeup, 128 Worst-fit algorithm, 187 Wakeup-waiting bit, 128 WOW (see Windows on Windows) WAN (see Wide Area Network) Wr ite-through cache, 309 War dialer, 644 Wsclock, 213 Watchdog timer, 392 WSclock, 215 Waveform coding, 484 WSClock algorithm, 213 WDF (see Windows Driver Foundation) WDM (see Windows Driver Model) Web browser, 590 Web page, 590 X Web server, multithreaded, 97-99 When to schedule, 148-149 X (see X Window System) White-hat hacker, 642 X client, 401 Wide area network, 583 X intrinsics, 402 Wide striping, 510 X resource, 404 Widgets, 402 X server, 401 Wild card, 626, 732 X widget, 402 Win32 API, 59-61, 816, 825-831 X window manager, 403 Window, 406 X window system, 5, 18, 400-404, 726 Window manager, 403 X l l (see X Window System) Windows 3.0, 816 X86, 17 Windows 95, 3, 815 Xenix, 16 Windows 98, 3, 815 Xlib, 402 Windows 2000, 17, 3, 817 Windows 2003, 818 Windows driver foundation, 901 Windows driver model, 901 y Windows Me, 17, 3, 815 Windows NT, 3, 17 Yellow book, CD-ROM, 368-369 1076 INDEX z ZJVM 68 ZeroPage thread Vi ta 893 Zipf George 506 Zipf' law 506 Zornbie 668 Zombie tate 44 ZSerie IBM 1 · ... abstractions to work with instead Operating systems turn the ugly into the beautiful, as shown in Fig 1-2 Application programs Operating system Hardware Figure 1-2 Operating systems turn ugly hardware... impor­ tant subject, but one only peripherally related to operating systems 1.1.2 The Operating System as a Resource Manager The concept of an operating system as primarily providing abstractions... would be chaos The operating system can bring order to the potential chaos by buffering all the output destined for the print­ er on the disk When one program is finished, the operating system