Windows API
Windows API: The Windows application programming interface(API) is the system programming interface to Micresoft Windows operating system. The Windows API is described in the Platform Software Development Kit(SDK) documentation. An excellent description of how to program the Windows base API is Jeffrey Richter's book Programming Applications for Microsoft Windows(4th ed., Microsoft Press, 1999). The Windows API consists of thousands of callable funcations, which are divided into the following major categories:
- Base Service
- Component Service
- User Interface Service
- Graphics and Multimedia Service
- Messaging and Collaboration
- NetWorking
- Web Services
.Net: The .NET Framework consists of a library of classes called the Framework Class Library(FCL) and a Common Lanaguage 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 redues common programming errors. (For an excellent description of the .NET Framework and its core architecture, see Applied Micresoft .NET Framework Programming by Jeffrey Richter.)
Services, Functions, and Routines
- Windows API functions Documented, callable subroutines in the Windows API.
- Native system services(or executive system services) The undocumented, underlying service in the operating system that are callable from user mode.
- Kernel support functions(or routines) Subroutines inside the Windows operating system that can be called by only from kernel mode.
- Windows services Processes started by the Windows service control manager.
- DLL(dynamic-link library) A set of callable subroutines linked together as a binay file that can be dynamically loaded by applications that use the subroutines.
Processes, Threads, and Jobs
Although programs and processes appear similar on the surface, they are fundamentally different. A program is a staitc sequence of instructions, whereas a process is a container for a set of resuource used when executing the instance of the program. At the highest level of abstraction, a Windows process conprises the following:
- A private virtual address space, which is a set of virtual memory address that the process can 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 pots, 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 proecss also points to its parent or creator process. However, if the parent exits, this information 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.
We can use some tools to view(and modify) processes and process information.
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 executiong 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 ofen 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. Because this information is different for each machine architecture that Windows runs on, this structure, by necessity, is architecture-specific.
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 proecess), 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 prot 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。
Every process has a security context that is stored in an object called 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 sytem-without affecting other threads in the process.
The virtual address descriptor(VADs) are data structures that the memory manager uses to keep track of the virtual addresses the process is using.
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 process 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.
Virtual Memory
Windows implements a virtual memory system based on a flat(linear) address space that provides each process with the illusion of having its own large, private address space. Virtual memory provides a logical view of memory that might not correspond to its physical layout. At run time, the memory manager, with assistance from hardware, translates, or maps, the virual addresses into physical addresses, where the data is actually stored. By controlling the protection and mapping, the operating system can ensure that individual process don't bump into one another or overwrite operating system data.
Because most systems have much less physical memory than the total virtual virtual memory in use by the running processes, the memory manager transfers, or pages, some of the memory contents to disk. Paging data to disk frees physical memory so that it can be used for other processes or for the operating system itself. When a thread accesses a virtual address that has been paged to disk, the virtual memory manager loads the information back into memory from disk. Applications don't have to be altered in any way to take advantage of paging because hardware support enables the memory manager to page without the knowledge or assistance of processes or threads.
The size of the virtual address space varies for each hardware platform.
Kernel Mode vs. User Mode
To protect user applications from accessing and/or modifying critical operating system data, Windows uses two processor access modes(even if the processor on which Windows is running supports more than two): user mode and kernel mode. User application code runs in user mode, whereas operating system code(such as system services and device drivers) runs in kernel mode.
TUser applications switch from user mode to kernel mode when they make a system service call. For example, a Windows ReadFile function eventually need to call the internal Windows routine that actually handles reading data from a file. That routine, because it accesses internal system data structures, must run in kernel mode. The transition from user mode to kernel mode is accomplished by the use of a special processor instruction that causes the processor to switch to kernel mode. The operating system traps this instruction, notices that a system service is being requested, validates the arguments the thread passed to the system function, and then executes the internal function. Before returning control to the use thread, the processor mode is switched back to user mode. In this way, the operating system protects itself and its data from perusal and modification by user processes. A transition from user mode to kernel mode does not affect thread scheduling and a mode transition is not a context switch.
Terminal Services and Multiple Sessions
The firt login session at the physical console of the machine is considered the console session, or session zero. Additional sessions can be created through the use of the remote desktop connection program(Mstsc.exe).
Objects and Handles
In the Windows operating system, an object is a single, run-time instance of a statically defined object type. An object type conprises a system-defined data type, functions that operate on instances of the data type, and a set of object attributes. If you write Windows applications, you might encounter process, thread, file, and event objects, to name just a few examples. In Windows, a process is an instance of the process object type, a file is an instance of the file object type, and so on.
An object attribute is a field of data in an object that partially defines the object's state. An object of type process, for example, would have attributes that include the process ID, a base scheduling priority, and a pointer to an access token object. Object methods, the means for manipulating objects, usually read or change the object attributes. For example, the open method for a process would accept a process identifier as input and return a pointer to the object as output.
The most fundamental difference between an object and an ordinary data structure is that the internal structure of an object is hidden. You must call an object service to get data out of an object or to put data into it. You can't directly read or change data inside an object. This defference separates the underlying implementation of the object from code that merely uses it, a technique that allows object implementations to be changed easily over time.
Objects provide a convenient means for accomplishing the following four important operating system tasks:
- Providing human-readable names for system resources
- Sharing resources and data among processes
- Protecting resources from unauthorized access
- Reference tracking, which allows the system to know when an object is no longer in use so that it can be automatically deallocated
Not all data structures in the Windows operating system are objects. Only data that needs to be shared, protected, named, or made visible to user-mode programs(via system service) is placed in objects. Structures used by only one component of the operating system to implement internal functions are not objects.
Security
The core security capabilities of Windows include: discretionary(need to know) protection for all shareable sytem objects(such as files, directories, processes, threads, and so forth), security auditing(for accountability of subjects, or users and the actions they initiate), password authentication at logon, and the prevention of one user from accessing uninitialized resources(such as free memory or disk space) that another user has deallocated.