Windows Operating System Versions
Table 1-1 Windows Operating System Releases 
Windows NT vs. Windows 95
From the initial announcement of Windows NT, Microsoft made it clear that it was to be the long-term replacement for Windows 95 (and its subsequent releases, Windows 98 and Windows Millennium Edition). The following list highlights some architectural differences and advantages that Windows NT (and its subsequent releases) has over Windows 95 (and its subsequent releases):
- Windows NT supports multiprocessor systems—Windows 95 doesn’t.
- The Windows NT file system supports security (such as discretionary access control).The Windows 95 file system doesn’t.
- Windows NT is fully a 32-bit (and now 64-bit) operating system—it contains no 16-bit code, other than support code for running 16-bit Windows applications.Windows 95 contains a large amount of old 16-bit code from its predecessors,Windows 3.1 and MS-DOS.
- Windows NT is fully reentrant—significant parts of Windows 95 are nonreentrant(mainly the 16-bit code taken from Windows 3.1). This nonreentrant code includes the majority of the graphics and window management functions (GDI and USER). When a 32-bit application on Windows 95 attempts to call a system service implemented in nonreentrant 16-bit code, the application must first obtain a system-wide lock (or mutex) to block other threads from entering the nonreentrant code base. And even worse, a 16-bit application holds this lock while running. As a result, although the core of Windows 95 contains a preemptive 32-bit multithreaded scheduler, applications often run single threaded because so much of the system is still implemented in nonreentrant code.
- Windows NT provides an option to run 16-bit Windows applications in their own address space—Windows 95 always runs 16-bit Windows applications in a shared address space, in which they can corrupt (and hang) each other.
- Process shared memory on Windows NT is visible only to the processes that are mapping the same shared memory section. On Windows 95, all shared memory is visible and writable from all processes. Thus, any process can write to and corrupt shared memory being used by other cooperating processes.
- Windows 95 has some critical operating system pages that are writable from user mode, thus allowing a user application to corrupt or crash the system.
从最初的声明中，微软就清楚的表明 WindowsNT 就是 Windows95 及其后续版本（Windows98，Windows Me）的替代版本。以下是两个架构之间的区别：
- NT支持多处理器，Windows95不支持NT的文件系统支持安全控制（如自主访问控制），Windows95的文件系统不支持
- NT是完全的32位操作系统（现在已是64位），除为了支持一些16位的程序外，不包含16位的代码。Windows95则从Windows3.1和MS-DOS中继承了大量的16位代码。
- NT的代码是可重入的，但Windows95的一些关键组件并不是可重入的。 这样造成的影响就是虽然Windows95 也是抢占式的多线程系统，但很可能实际上长时间运行的只能是其中一个线程
- NT可以让16位的程序选择加载到自己独立的地址空间， Windows95 总是把16位程序加载到统一的共享地址空间。一个程序崩溃后就可能会影响到其他的程序。
- NT中，进程共享内存只对那些映射了相同共享内存节的进程可见； Windows95中，共享内存对所有进程可见并可以修改。所以任意进程都可能破坏其他进程正在使用的共享内存
- Windows95中 有一些关键的操作系统页是可以被用户模式改写的，因此用户程序就可能破坏操作系统，甚至让其崩溃。
Foundation Concepts and Terms
Windows API
The Windows application programming interface (API) is the system programming interface to the Microsoft Windows operating system family, including Windows 2000, Windows XP, Windows Server 2003, Windows 95, Windows 98, Windows Millennium Edition (Me), and Windows CE. Each operating system implements a different subset of the Windows API.
Prior to the introduction of 64-bit versions of Windows XP and Windows Server 2003, the programming interface to the 32-bit version of the Windows operating systems was called the Win32 API, to distinguish it from the original 16-bit Windows API, which was the programming interface to the original 16-bit versions of Windows.
Windows API 就是操作系统的编程接口。可以把它理解为一个Interface或者一个框架。里面定义了很多的方法和数据类型。如果你要想同Windows打交道，就要使用Windows的API，要使用API，就会遇到里面定义的很多方法和数据类型。这和高级语言中引用的程序集什么的是一样的。
Win32 API VS Win16 API
What About .NET and WinFX
The .NET Framework consists of a library of classes called the Framework Class Library (FCL) and a Common Language Runtime (CLR) that provides a managed code execution environment with features such as just-in-time compilation, type verification, garbage collection, and code access security. By offering these features, the CLR provides a development environment that improves programmer productivity and reduces common programming errors.
The CLR is implemented as a classic COM server whose code resides in a standard usermode Windows DLL. In fact, all components of the .NET Framework are implemented as standard user-mode Windows DLLs layered over unmanaged Windows API functions.(None of the .NET Framework runs in kernel mode.) 
WinFX is “the new Windows API.” It is the evolution of the .NET Framework that ships with Windows “Longhorn,” the next major release of Windows. It will also be installable on Windows XP and Windows Server 2003. WinFX provides the foundation for the next generation of applications built for the Windows operating system.
。NET框架包括FCL和CLR。CLR提供了托管代码的执行环境，提供了即时编译，类型验证，垃圾回收，代码访问安全等特性，可以提高程序员的生产性并降低一般的编程错误（注意啊，。NET程序员，同C++/C程序员相比，优势就是生产率高啊）
CLR就是一个典型的COM 服务器，实现代码包含在运行于用户模式的DLL中。事实上。NET的所有组件都是由在非托管的Windows API基础上的运行于用户模式的DLL来实现的。 整个框架都不内核模式运行。
WinFX是下一个版本的API。 是在API的基础上发展出来的。 因此它同样离不开原先的Win32。 Win代表 Win32。 F代表。NET Framework 。X 感觉应该表示扩展，即加上WPF,WF等一些特性
History of the Win32 API
Interestingly, Win32 wasn’t slated to be the original programming interface to Microsoft Windows NT. Because the Windows NT project started as a replacement for OS/2 version 2, the primary programming interface was the 32-bit OS/2 Presentation Manager API. A year into the project, however, Microsoft Windows 3.0 hit the market and took off. As a result, Microsoft changed direction and made Windows NT the future replacement for the Windows family of products as opposed to the replacement for OS/2. It was at this juncture that the need to specify the Windows API arose—before this, the Windows API existed only as a 16-bit interface.
Although the Windows API would introduce many new functions that hadn’t been available on Windows 3.1, Microsoft decided to make the new API compatible with the 16-bit Windows API function names, semantics, and use of data types whenever possible to ease the burden of porting existing 16-bit Windows applications to Windows NT. So those of you who are looking at the Windows API for the first time and wondering why many function names and interfaces seem inconsistent should keep in mind that one reason for the inconsistency was to ensure that the Windows API is compatible with the old 16-bit Windows API.
Services, Functions, and Routines
- Windows API
functions Documented, callable subroutines in the Windows API. Examples include CreateProcess, CreateFile, and GetMessage.
- Native system services (or executive system services)
The undocumented, underlying services in the operating system that are callable from user mode. For example, NtCreateProcess is the internal system service the Windows CreateProcess function calls to create a new process.
- Kernel support functions (or routines)
Subroutines inside the Windows operating system that can be called only from kernel mode. For example, ExAllocatePool is the routine that device drivers call to allocate memory from the Windows system heaps.
- Windows services Processes
started by the Windows service control manager. (Although the registry defines Windows device drivers as “services,” we don’t refer to them as such in this book.) For example, the Task Scheduler service runs in a usermode process that supports the at command
- DLL (dynamic-link library)
A set of callable subroutines linked together as a binary file that can be dynamically loaded by applications that use the subroutines. Examples include Msvcrt.dll (the C run-time library) and Kernel32.dll (one of the Windows API subsystem libraries). Windows user-mode components and applications use DLLs extensively. The advantage DLLs provide over static libraries is that applications can share DLLs, and Windows ensures that there is only one in-memory copy of a DLL’s code among the applications that are referencing it.
Processes, Threads, and Jobs
- A program is a static sequence of instructions, whereas a process is a container for a setof resources used when executing the instance of the program. At the highest level of abstraction,a Windows process comprises the following:
- A private virtual address space, which is a set of virtual memory addresses that the processcan use
- An executable program, which defines initial code and data and is mapped into the process’s virtual address space
- A list of open handles to various system resources, such as semaphores, communication ports, and files, that are accessible to all threads in the process
- A security context called an access token that identifies the user, security groups, and privileges associated with the process
- A unique identifier called a process ID (internally called a client ID)
- At least one thread of execution
- Each process also points to its parent or creator process. However, if the parent exits, thisinformation is not updated. Therefore, it is possible for a process to point to a nonexistent parent.This is not a problem, as nothing relies on this information being present.
A process has the following resources
- A private address space
- One or more threads
- a list of open handles to objects such as files, shared memory sections
- Every process has a security context that is stored in an object
called an access token. The process access token contains the security
identification and credentials for the process. By default, threads
don’t have their own access token, but they can obtain one, thus
allowing individual threads to impersonate the security context of
another process—including processes running on a remote Windows
system—without affecting other threads in the process. - The virtual address descriptors (VADs) are data structures that
the memory manager uses to keep track of the virtual addresses the
process is using. - One of the synchronization objects such as mutexes, events, or semaphores
A thread is the entity within a process that Windows schedules for execution. Without it, the process’s program can’t run. A thread includes the following essential components:
- The contents of a set of CPU registers representing the state of the processor.
- Two stacks, one for the thread to use while executing in kernel mode and one for executing in user mode.
- A private storage area called thread-local storage (TLS) for use by subsystems, run-time libraries, and DLLs.
- A unique identifier called a thread ID (also internally called a client ID—process IDs and thread IDs are generated out of the same namespace, so they never overlap).
- Threads sometimes have their own security context that is often used by multithreaded server applications that impersonate the security context of the clients that they serve.
The volatile registers, stacks, and private storage area are called the thread’s context
Although threads have their own execution context, every thread within
a process shares the process’s virtual address space (in addition to
the rest of the resources belonging to the process), meaning that all
the threads in a process can write to and read from each other’s
memory. Threads cannot accidentally reference the address space of
another process, however, unless the other process makes available part
of its private address space as a shared memory section (called a file
mapping object in the Windows API) or unless one process has the right
to open another process to use cross-process memory functions such as
ReadProcessMemory and WriteProcessMemory.
线程本身的属性中不包括代码，代码是进程的属性。线程中只包含访问代码的地址，这些存在寄存器中
Windows provides an extension to the process model called a job. A job
object’s main function is to allow groups of processes to be managed
and manipulated as a unit. A job object allows control of certain
attributes and provides limits for the process or processes associated
with the job. It also records basic accounting information for all
processes associated with the job and for all processes that were
associated with the job but have since terminated. In some ways, the
job object compensates for the lack of a structured process tree in
Windows—yet in many ways it is more powerful than a UNIX-style process
tree.
Fibers vs. Threads
Fibers allow an application to schedule its own “threads” of execution rather than rely on the priority-based scheduling mechanism built into Windows. Fibers are often called “lightweight” threads, and in terms of scheduling, they’re invisible to the kernel because they’re implemented in user mode in Kernel32.dll. To use fibers, a call is first made to the Windows ConvertThreadToFiber function. This function converts the thread to a running fiber. Afterward, the newly converted fiber can create additional fibers with the CreateFiber function. (Each fiber can have its own set of fibers.) Unlike a thread, however, a fiber doesn’t begin execution until it’s manually selected through a call to the SwitchToFiber function. The new fiber runs until it exits or until it calls SwitchToFiber, again selecting another fiber to run.