Basic Windows concepts and terminology

---

This chapter will introduce the basic concepts of Windows, these concepts are to facilitate the understanding of Windows internals, so as to understand the basic concepts and some terms of Windows in advance.

Windows API

The Windows application programming interface (application programming interface, API) is the user-mode system programming interface of the Windows operating system family. Before 64-bit Windows was released, the programming interface for 32-bit Windows was known as the Win32 API. This is primarily to differentiate it from earlier 16-bit Windows APIs. Most of the Windows API is now called Win32 API, which refers to both 32-bit and 64-bit Windows programming interfaces.

Windows API style

The Windows API initially contained only C-style functions. Currently, thousands of such functions are available to developers. On the day Windows was born, C language was the most natural choice, because it can be said to be the lowest common denominator of many languages ​​(that is, C language can also be accessed through other languages), and C language is low enough to expose operating system services. But the downside of the C language is the sheer number of functions and the lack of naming consistency and logical grouping (like C++'s namespaces). One consequence of these difficulties is that some newer APIs use a different API mechanism: the component object model (COM).

COM was originally developed to allow Microsoft office applications to communicate and exchange data between documents (such as embedding an Excel table into a Word document or PowerPoint presentation). This capability is also known as object linking and embedding (OLE). OLE was originally implemented using an ancient Windows messaging mechanism called dynamic data exchange (DDE). DDE had some inherent limitations, so a new communication method was developed: COM. In fact COM was originally called OLE2, officially released around 1993.

COM is based on two fundamental principles:

1. First principle: Clients can communicate with objects (sometimes called COM server objects) through interfaces. An interface is a well-defined "contract" consisting of a series of logically interrelated methods, grouped according to the virtual table scheduling mechanism. This is also a common method for C++ compilers to implement virtual table scheduling. This allows for binary compatibility, avoids compiler mangling issues, and investigates these methods with many languages ​​(and compilers) such as C, C++, visual basic, .net, delphi, etc.
2. The second principle: the implementation of components can be loaded dynamically without statically linking to the client.

The term COM server usually refers to the dynamic link library (dynamic link library, DLL) or executable file (executable, EXE) used to implement the COM class. COM also provides important features related to security, marshalling, threading models, and more. The detailed introduction to COM will not be elaborated here. If you are interested, you can refer to the book Essential COM written by Don Box.

Windows runtime

Windows 8 adds a new API and supporting runtime called the Windows Runtime (sometimes referred to simply as WinRT, but it's not the same as Windows RT, the ARM-based version of the Windows operating system). The Windows Runtime consists of platform services and is primarily intended for application developers of Windows apps (formerly known as metro apps, modern apps, immersive apps, and Windows Store apps). Windows apps can run on devices of different types and sizes, from small IoT devices to phones, tablets, laptops, desktops, and even devices like Xbox one and HoloLens.

From an API perspective, WinRT is built on top of COM, with various extensions added to the basic COM infrastructure. For example, WinRT can use full type metadata (stored in WINMD files, based on the .NET metadata format) to extend a similar concept in COM called a type library. From an API design perspective, it is more restrained than classic Windows API functions, providing namespaces, hierarchies, consistent naming, and programming patterns.

Windows apps adhere to a new set of rules, which is very different from ordinary Windows applications (now called Windows desktop applications or classic Windows applications).

The relationship between the various APIs and applications is not so straightforward. Desktop applications can use a subset of the WinRT API, and Windows applications can use a subset of the Win32 and COM API. For the specific details of this part, please refer to the MSDN documentation. The WinRT API is not a new "native" API, but somewhat similar to .NET using the traditional Windows API.

.NET Framework

.NET Framework is part of Windows. The following table lists the .NET Framework versions that are installed by default on Windows. Newer versions of the .NET Framework can also be installed on older versions of the Windows operating system.

Windows version	.NET Framework version
Windows 8	4.5
Windows 8.1	4.5.1
Windows 10	4.6
Windows 10 version 1511	4.6.1
Windows 10 version 1607	4.6.2

.NET Framework consists of two main components:

1. Common language runtime (CLR). This is .NET's runtime engine, which includes a just-in-time (just lm time, JIT) compiler that translates common intermediate language (CIL) instructions into the underlying hardware CPU machine voice, garbage collector, type verification, code access security, and more. It is implemented as a COM in-process server (DLL) that makes use of the facilities provided by the Windows API.
2. .NET Framework class library (framework class library, FCL). This is a large collection of types used to implement functionality that client and server applications may typically require, such as user interface services, networking, database access, and more.

By providing the above features along with new high-level programming languages ​​(C#, visual basic, F#) and supporting tools, .NET Framework can help developers increase the development sales volume of target applications and improve security and reliability. The direct relationship between .NET Framework and Windows operating system is shown in the figure below:

Services, Functions and Routines

In Windows user documentation and programming documentation, many terms have different meanings in different contexts. For example, the word "service" can refer to a callable routine in the operating system, a device driver, or a server process. The meanings of the different terms are listed below:

• Windows API functions. A subroutine in the Windows API that is exposed and callable. Such as CreateProcess, CreateFile, GetMessage.
• Native system services (or system calls). Low-level services that are not exposed in the operating system but can be called from user mode. For example: Windows' CreateProcess function calls NtCreateUserProcess, an internal system service, to create a new process.
• Kernel support functions (or routines). Inside the Windows operating system, a subroutine that can only be called from kernel mode. For example: A driver can call the ExAllocatePoolWithTag routine to allocate memory from the Windows system heap.
• Windows service. A process started by the Windows Service Control Manager. For example, the Task Scheduler service running in user mode can also support the schtasks command
• Dynamic Link Libraries (DLLs). Callable subroutines are linked into a binary file that can be dynamically loaded by an application that uses the subroutine. For example, Msvcrt.dll and Kernel32.dll (one of the Windows API subsystem libraries). Windows user-mode components and applications make heavy use of DLLs. The advantage of DLLs over static libraries is that applications can share DLLs, and Windows ensures that only one copy of the same DLL used by multiple applications exists in memory.

process

Although programs and processes look similar on the surface, there are fundamental differences. A program is a static sequence of instructions, while a process is a container that contains a set of resources that will be used to execute an instance of the program. From the highest level of abstraction, a Windows process can contain the following elements:

1. A private virtual address space. A range of virtual memory addresses available to the process.
2. an executable program. Defines the initial code and data that will be mapped into the virtual address space of the process.
3. A list of open handles. Handles are mapped to various system resources. Examples include semaphores, synchronization objects, and files that can be accessed by all threads in a process.
4. a security context. An access token used to identify a process-related user, security group, privilege, attribute, claim, capability, user account control (UAC) virtualization state, session, restricted user account state identity, and also contains the appcontainer identifier and related sandbox information.
5. A process ID. A unique identifier that is internally part of the client ID identifier.
6. At least one thread of execution. It is possible to create "empty" processes though.

Many tools can help us view (or even modify) processes and process information. Below we will try to demonstrate.

Use Task Manager to view process information

Under Windows, you can use the shortcut key Ctrl+shift+esc to open the task manager, or right-click the mouse on the toolbar to open the task manager.

In the process tab, four columns of information are displayed by default: CPU, memory, disk and network. After right-clicking on the table header, you can choose to display more column information or hide part of the displayed information. Information that can be displayed includes process name, process ID, type, status, publisher, and command line. Some processes can be expanded to display the top-level visible windows created by that process.

You can go to the Details tab, where process information is also shown, but in a more compact way. The window created by the process will not be shown here, but more columns of different types of information will be provided.

Similarly, in the detailed information, you can also right-click the header and select Set Column Information to display more information about the process.

Here we need to focus on the role of several option values:

• "Threads": Displays the number of threads owned by each process.
• "Handle": Displays the number of kernel object handles opened by the internal lock of the process.
• "Status": Displays the current running status of the process, such as running, suspended, etc.

parent process

Each process also points to its own parent process (the parent process can be the creator process, but this is not always the case). If the parent process no longer exists, this information will no longer be updated. So it is possible for a process to point to a non-existent parent process. But this will not cause a problem, because the operation of any process does not depend on whether the parent process information is valid or not. process explorer takes into account the start time of the parent process to avoid child processes attaching to reused process ids.

Most tools do not display the ID of the process's parent or creator process. We can use Performance Monitor to query the creating process ID to get this information. Display the process tree by using the Tlist.exe tool in Debugging Tools for Windows with the /t switch. (Tlist.exe has been changed to TaskList (Tasklist.exe) in the new Windows 10, and the .t option is no longer supported)

Here we use the process explorer in the sysinternals package provided by MS to display more detailed process information. (Description and download link of this tool: https://learn.microsoft.com/zh-cn/sysinternals/downloads/ )

The process explorer of sysinternals can display more detailed process and thread information than other similar tools, and can also display or implement some unique functions:

1. Process security tokens such as rent and privilege lists and virtualization state.
2. Highlight changes in process, thread, DLL and handle lists.
3. Services A list of services within the hosting process, including the service's display name and description.
4. A list of other process attributes, such as mitigation policy and process protection level.
5. Processes and job details included in the job.
6. The process that hosts the .NET application and .NET-related details such as appdomain listings, loaded assemblies, and CLR performance counters.
7. The process that hosts the Windows Runtime (the immersive process).
8. The start time of processes and threads.
9. Complete list of memory-mapped files (not just DLLs).
10. The ability to suspend a process or thread.
11. The ability to terminate a specific thread.
12. Easily identify processes that are consuming the most CPU resources over a period of time.

Note: Performance Monitor can display CPU utilization for a specified set of processes, but cannot automatically display information about processes created after a Performance Monitor session was started, only manually created binary output formats can contain such information.

Process Explorer also helps users easily access the following information in one place:

1. Process tree with the ability to collapse parts of the tree.
2. Open handles in the process, including unnamed handles.
3. List of DLLs in the process.
4. Thread activity in the process.
5. User-mode and kernel-mode thread stacks, including names to which addresses are mapped using Dbghelp.dll provided by Debugging Tools for Windows.
6. Memory manager details such as peak memory commits, kernel memory paging limits, and nonpaged memory pool limits.

thread

A thread is an entity within a process that Windows schedules for execution. Without threads, the program of a process cannot run.

A thread consists of the following basic elements:

1. A list of CPU register contents representing the state of the process.
2. Two stacks: one for threads executing in kernel mode; the other for threads executing in user mode.
3. A private storage area called thread-local storage used by subsystems, runtime libraries, and DLLs. (thread-local storage, TLS)
4. A unique identifier called the thread ID.

In addition, threads sometimes have their own security context, also known as a token, which is mainly used by multi-threaded server applications to mimic the security context of the client being served.

The combination of volatile and nonvolatile registers and private storage areas form the thread context. Because these information are different in Windows running on computers with different architectures. So in essence, this structure is related to a specific architecture. Windows' GetThreadContext function gives us access to this architecture-dependent information (also known as a CONTEXT block). In addition, each thread has its own stack (pointed to by the stack register section in the thread context).

Switching the execution process from one thread to another requires the participation of the kernel scheduler, which can be an expensive operation, especially when two threads need to switch between each other frequently. To reduce overhead, Windows implements two mechanisms:

• fiber
• User-mode scheduling (UMS) threads

fiber

Fibers allow applications to directly schedule the execution of their own threads without resorting to Windows' built-in priority-based scheduling mechanism. Fibers are also commonly called lightweight threads. In terms of scheduling, fibers are invisible to the kernel because fibers are implemented in user mode via Kernel32.dll. To use fibers, you first need to call the Windows ConvertThreadToFiber function, which converts a thread into a running fiber. The newly converted fiber can then create more fibers through the CreateFiber function. (Each fiber can have its own set of fibers.) But unlike threads, fibers cannot start executing until they are manually selected by calling the SwitchToFiber function. The newly created fiber will continue to run until it exits or the SwitchToFiber function is called again and another fiber is selected to run. Details about fiber functions can be found in the Windows SDK documentation.

User-Mode Scheduling Threads

Available only on 64-bit Windows, User-Mode Scheduling (UMS) threads serve a similar basic purpose as fibers, but avoid most of the disadvantages of fibers. UMS threads have their own kernel thread state and are therefore visible to the kernel, whereby multiple UMS threads can issue blocking system calls and share or compete for resources. Alternatively, when two or more UMS threads need to perform operations in user mode, they can also periodically switch execution contexts (one thread yields execution rights to another thread), and this process can be performed in user mode without the participation of the scheduler. From the kernel's point of view, the same kernel thread is still running at this point, nothing has changed. When an operation performed by a UMS thread needs to enter the kernel (such as a system call), it can switch to its own dedicated kernel-mode thread (this process is called a directed context switch, directed context switch). Although concurrent UMS threads still cannot run through multiple processes, they conform to a pre-emptible mode, so they are not fully cooperative.

Although threads have their own execution contexts, and even each thread in a process shares the virtual address space of the process, all threads in a process can fully read and write access to the virtual address space of the process. However, a thread cannot inadvertently refer to another process's address space, unless the other process programs part of its own private address space into a shared memory area (called a file mapping object in the Windows API), or unless a process has permission to open another process to use cross-process memory functions, such as ReadProcessMemory and WriteProcessMemory functions (the process must run under the same user account, not in an AppContainer or other type of sandbox, and unless the target process has some kind of protection mechanism, it is accessible by default).

In addition to a private address space and one or more threads, each process also has its own security context and a list of open handles to kernel objects such as synchronization objects such as files, shared memory areas, mutexes, events, and semaphores.

In the figure, VAD refers to virtual address descriptor, which is a data structure used by the memory manager to track the virtual addresses used by processes.

The security context of each process is stored in an object called an access token. A process access token contains the security identity and credentials of a process. By default, a thread does not have its own access token, but it can obtain a token to allow itself to impersonate the security context of another process (including a process on a remote Windows system) without affecting other threads in the process (more on process and thread security later).

Operation

Windows provides an extension to the process model called "jobs". The main function of a job object is to manage and operate a set of resources as a whole. A job object can be used to control certain properties and place restrictions on one or more processes that a job is associated with. In addition, basic account information can be logged for all processes associated with the job, and for all processes associated with the job but terminated after the association. To a certain extent, the job object makes up for the lack of Windows in the structured process tree, and in many cases it is more powerful than the process tree like Unix.

Virtual Memory

Windows implements a virtual memory system based on a flat (linear) address space, so that each process can "feel" that it can obtain a huge private address space. The logical view that virtual memory provides for memory may not be consistent with the physical layout. At runtime, the memory manager can (with the assistance of the hardware) translate virtual addresses. Immediately map to the physical address where the data is actually stored. By controlling the protection and mapping process, the operating system can ensure that processes will not affect each other and will not overwrite operating system data.

Since the amount of physical memory in most OSes is far less than the total amount of virtual memory required for a process to run, the memory manager needs to convert some memory contents, that is, page them to disk. Paging data to disk frees physical memory for use by other processes or by the operating system itself. When a thread needs to access a virtual address that is paged to disk, the virtual memory manager reloads the relevant information from disk into physical memory.

Applications do not need to be specifically tuned to take advantage of the benefits provided by paging, because hardware support allows the memory manager to page without the knowledge or assistance of the process or thread. Among the virtual memory used by the two processes, part is still mapped in physical memory (physical memory RAM), and the other part has been paged to disk. Note that contiguous blocks of virtual memory may be mapped to non-contiguous blocks of physical memory. These blocks are also called pages, and the default size of each page is 4KB.

The size of the virtual memory address space varies for each hardware platform. In a 32-bit X86 system, the theoretical maximum of the total amount of virtual memory space is 4GB. By default, Windows allocates the lower half of this address space (from 0x00000000 to 0x7FFFFFFF) to the process as private storage unique to the process, and the upper half (from 0x80000000 to 0xFFFFFFFF) to itself as protected operating system memory. The lower half of the mapping changes to reflect the virtual address space of the currently executing process, but the upper half of the mapping (mostly) always consists of the operating system's virtual memory. Windows-supported startup options, such as the increaseuserva modifier in the boot configuration database, allow processes running programs with special tags to use up to 3GB of private address space, leaving only 1GB for the operating system. This approach allows applications such as database servers to keep most of their content in the address space of the process, reducing the need to map a subset of database views to disk, thereby improving overall operating performance.

Two typical virtual address space layouts supported by 32-bit Windows are shown in the figure below.

Although 3GB of virtual address space is better than 2GB, it is still not enough to map very large databases. In order to solve this problem on 32-bit systems, Windows provides a mechanism called Address Windowing Extension (AWE), which allows 32-bit applications to allocate up to 64GB of physical memory, and then map views or windows to their own 2GB virtual address space. Although AWE shifts the management burden of the virtual memory-to-physical memory mapping relationship to the developer, it does meet the demand for direct access to more physical memory, and the specific number even exceeds the upper limit that the 32-bit process address space can accommodate at one time.

64-bit Windows provides a larger address space for processes because 64-bit address lengths can access up to 2 to the power of 64 (16 EB, 1EB = 1024 PB, 1PB = 1024 TB, 1TB = 1024 GB).

kernel mode and user mode

In order to prevent user applications from accessing or modifying important data of the operating system, Windows uses two processor access modes (in fact, the processor running Windows may support more modes). The two modes are user mode and kernel mode:

1. User Mode: Application code runs in user mode.
2. Kernel Mode: Operating system code runs in kernel mode. Kernel mode is the processor execution mode that allows access to all system memory and CPU instructions.

Some processors use terms such as code privilege level or Ring level to distinguish between different modes. But there are also processors that use similar supervisor mode (supervisor mode) and application mode to distinguish.

While each Windows process has its own private memory space, kernel-mode operating system and device driver code share the same virtual address space. Each page in virtual memory has a tag indicating which access mode the processor must use to read or write the page. Memory in system space can only be accessed from kernel mode, while all pages in user address space can be accessed from either user mode or kernel mode.

Read-only pages (pages with static data) are not writable in any mode. In addition, for processors that support non-executable memory protection, Windows will mark the data contained in the page as non-executable, which prevents inadvertent or malicious code from executing in the data area (requires data execution prevention (data execution prevention, DEP) to be turned on).

Windows provides no protection for private read/write system memory used by components running in kernel mode. In other words, once in kernel mode, both the operating system and device driver code can access the entire system space memory and can bypass Windows security mechanisms to access various objects. Because the Windows operating system has a large amount of code running in kernel mode, components running in kernel mode must be carefully designed and tested to ensure that they do not violate system security mechanisms or cause system instability.

This lack of protection also makes it necessary to be more cautious when loading third-party device drivers, especially the third-party device drivers do not contain digital signatures. Once entering the kernel mode, the driver can completely access all data of the operating system. This is also one of the reasons why Windows 2000 began to implement the driver signature mechanism. (In addition to the signature mechanism, Windows provides a driver verifier for driver testing and finding bugs, which will be explained later, link: https://learn.microsoft.com/zh-cn/windows-hardware/drivers/devtest/devcon-examples#example-8-list-all-driver-files）

Through the performance monitor that comes with Windows 10, you can observe the current switching between kernel mode and user mode and the time-consuming comparison.

hypervisor

In recent years, there have been major changes in the application and software development model, such as the emergence of cloud services and the ubiquity of Internet of Things devices. These new trends push operating system and hardware vendors to find ways to virtualize guest operating systems through host hardware in a more efficient way. For example, it may be necessary to host multiple tenants through a server, run 100 isolated websites with one server, and even allow developers to test dozens of different operating systems without purchasing dedicated hardware. Users put forward higher requirements for the speed, efficiency and security of virtualization technology, which in turn gave birth to new computing models and software theories. In fact, some of today's software, such as Docker, itself is supported by Windows 10 and Windows server 2016, and can run in containers to obtain a fully isolated virtual machine environment, thereby running the same application stack or framework to realize the innovation of the guest/host machine model.

To provide such virtualization services, almost all modern solutions use a hypervisor, a special, highly privileged component that virtualizes and isolates all resources on a computer, from virtual and physical memory to device interrupts and even PCI and USB devices. Hyper-V is one such hypervisor, and the Hyper-V client functionality in Windows 8.1 and later is enabled by this technology.

In Windows 10, Microsoft provides a series of new services for Virtualization Based Security (VBS) using the Hyper-V hypervisor:

1. Device Guard. Via Hypervisor Code Integrity (HVCI) provides stronger code signing assurance than using KMCS alone, and provides customized signing policies for user-mode and kernel-mode code for Windows operating systems.
2. Hyper Guard. Protects critical data structures and code related to the kernel and hypervisor.
3. Credential Guard (credential guard). Credentials and secrets to prevent unauthorized access to domain accounts and can be used in conjunction with biometric authentication mechanisms.
4. Application Guard. Provides a stronger sandbox mechanism for the Microsoft Edge browser.
5. Host Guardian and Shielded Fabric. Virtual machines can be protected from threats to the infrastructure with a virtual TPM (v-TPM).

firmware

Windows components are increasingly dependent on the security of the operating system and the system kernel, which depends on the protection provided by the hypervisor.

This then creates a problem: then make sure the hypervisor component can be safely loaded and verify its contents. Typically this is the responsibility of the boot loader, but the boot loader itself needs to receive the same level of validation checks, complicating the trust relationship between the different components.

So how to ensure that the boot process is reliable and unaffected through the root chain of trust? On modern Windows 8 and later systems, this is achieved through system firmware, but only if a UEFI-based certified system is used.

As a Windows requirement, and part of the UEFI standard, Secure Boot must provide strong guarantees and requirements for the signed quality of boot-related software. This verification process ensures that Windows components are loaded in a safe manner from the very beginning of the boot process. In addition, techniques such as injecting Trusted Platform Module (TPM) can also measure the entire boot process and provide corresponding proofs (local or remote proofs).

Terminal Services and Multisession

Terminal Services refers to the ability of Windows to provide support for multiple interactive user sessions through a single system. Remote users can use Windows Terminal Services to establish sessions on other computers, log on to the server, and run applications. The server then transmits a Graphical User Interface (GUI) to the client, and the client sends user input back to the server. (Similar to the X Window system, Windows allows specific applications to be uploaded on the server system and the display screen is sent back to the remote client, but the entire desktop does not need to be transmitted to the remote end)

The first session is usually the service session, session 0, which contains the system service hosting process. The first session established on the computer through a physical login to the console is Session 1, and further sessions are subsequently connected through the Remote Desktop Connection program (Mstsc.exe) or Fast User Switching.

The Windows client version allows only one remote user to connect to the computer, and if someone is already logged into the console at the time of connection, the workstation is locked. That is to say, the computer used for remote connection cannot support multiple people to use it at the same time.

Windows Server systems support two concurrent remote connections. This is to facilitate remote management, for example, the management tools used may not require users to log in to the computer being managed. Additional remote sessions can be supported if the necessary licenses are in place and configured as a terminal server.

Objects and Handles

In the Windows operating system, a kernel object refers to a single run-time instance of a statically defined object type. An object type consists of a system-defined data type, functions that perform operations on that data type, and a set of object properties.

If you need to develop Windows applications, you may encounter many concepts, such as processes, threads, files, event objects, and so on. These objects are based on the underlying objects created and managed by Windows. In Windows, a process is actually an instance of the process object type, and a file is an instance of the file object type.

Object properties are data fields in an object that define parts of the object's state. For example, an object of type process will contain process ID, base scheduling priority, pointer to access token object, etc. through attributes. Object methods are the means by which an operating system object can be used to read or change object properties. For example, a process's Open method can accept a process identifier as input and return a pointer to an object as output.

The most essential difference between objects and ordinary data is that the internal structure of objects is opaque. Object services must be called to obtain data stored in the object, or to put external data into the object, but cannot directly read or change the data inside the object. This difference effectively separates the underlying implementation of objects from the code that simply uses them, allowing easy access and changes to the object's implementation at any time.

With the help of the object manager, a kernel component, objects have the ability to facilitate the following four important operating system tasks:

• Provide human-readable names for system resources
• Sharing resources and data across processes
• Protect resources from unauthorized access
• Reference tracking, whereby the system recognizes when an object is no longer in use so that it can be released automatically.

Not all data structures in the Windows operating system are objects. Only data that needs to be shared, protected, named, or visible to user-mode programs needs to be placed in objects.

safety

Windows has been designed with security fully in mind, and can meet various formal security rating requirements of the government and the industry, such as the common criteria for information technology security evaluate (CCITSE) specification. Achieving a government-approved security rating can make the operating system more competitive in the relevant field. Of course, many of these features can benefit any multi-user system:

The core security features of Windows include the following:

1. Discretion is provided for all sharable system objects such as files, directories, processes, threads, etc., and the protection of the application is emphasized.
2. Perform security audits and accountability for principals or users and the actions they initiate.
3. User authentication at login.
4. Prevent users from unauthorized access to resources that have been deallocated by other users, such as free memory or disks.

Windows provides three forms of access control for objects:

• Discretionary access control. This protection mechanism is the first thing most people think of when they think of operating system security. In this way, the owner of an object (such as a file or printer) can run or deny access to others. When a user logs in, he can obtain a series of security credentials, also called a security context. When a user attempts to access an object, the system compares their security context with the desired access control list to determine whether the user is authorized to perform the requested operation. In Windows server 2012 and Windows 8, this discretionary control mechanism is further enhanced with attribute-based access control (Dynamic Access Control). However, an access control list for a resource doesn't have to identify individual users and groups, it can also identify the attributes or claims that are required to allow access to the resource, such as "Permission Level: Top Secret" or "Seniority: 10 Years". By automatically obtaining such attributes by parsing SQL databases and schemas with the help of Active Directory, this more elegant and flexible security model can free organizations from the tedious work of manually managing groups and group hierarchies.
• Privileged access control. It is also a necessary mechanism when discretionary access control cannot fully meet the needs. This approach ensures that others can still access protected objects when the owner is unavailable. For example, if an employee leaves the company and an administrator needs a way to access a file that was previously only accessible to that employee, the administrator can take ownership of the file in Windows and then manage access to the file as needed.
• Mandatory integrity mechanism. This mechanism is required when additional security controls are required for protected objects accessed by the same user account. This mechanism is used in many places, such as the sandbox mechanism provided for Windows applications, the isolation provided by Internet Explorer in protected mode through user configuration, and the protection of objects created by elevated administrator accounts from access by non-elevated administrator accounts.

Starting from Windows 8, the system will use a sandbox called appcontainer to host Windows applications. This technology can isolate between different appcontainers and between appcontainers and non-Windows application processes. Code in an appcontainer can communicate through the broker, and sometimes with other appcontainers or processes, through well-defined contracts provided by the Windows Runtime.

Various security mechanisms are fully integrated into the Windows API interface. The Windows subsystem implements an object-based security model in a similar way to the operating system:

• Sets the Windows security descriptor for shared Windows objects to prevent unauthorized access.
• When an application first attempts to access a shared object, the Windows subsystem verifies the application's permissions.
• If the security checks pass, the Windows subsystem allows the application to continue accessing.

registration form

Anyone who has used the Windows operating system must have heard of or even used the registry. When it comes to the internal principles of Windows, it is inevitable to mention the registry, because the system database of the registry contains

• Information necessary to automate and configure the system
• System-level software settings that control how Windows runs
• security database
• User configuration information such as the screen saver used

The registry also provides access to volatile data in memory, such as the current hardware state of the system (which device drivers are loaded, which resources are used by the drivers). There are also Windows performance counters. Performance counters are not actually located in the registry, but performance counter details can be accessed through the registry.

While many Windows users and administrators will never have to deal with the Registry directly (because most configuration options are viewed and changed through standard administrative tools), the Registry is still a useful source of information about Windows internals, containing many settings that can affect system performance and behavior. (The system-level configuration root key HKEY_LOCAL_MACHINE of the registry, referred to as HKLM)

Unicode

Windows is one big difference from most other operating systems: Most text strings in Windows are stored and processed as 16-bit wide Unicode strings (technically using UTF-16LE). Unicode is an international character set standard that defines unique values ​​for most of the world's known character sets, providing 8-bit, 16-bit, or even 32-bit encodings for each character.

Because many applications deal with 8-bit (single-byte) ANSI strings, many Windows functions can accept string parameters through two entry points:

• A Unicode (16-bit wide character) version
• An ANSI (8-bit narrow character) version

If you call narrow character versions of Windows functions, there may be a slight performance impact because input string parameters need to be converted to Unicode characters before they can be processed by the system, and output parameters are converted from Unicode to ANSI for output to the application. Therefore, if you need to run older versions of services or codes on Windows and the related codes are written in ANSI strings, Windows will convert ANSI characters to Unicode for its own use, but Windows will never convert the data in the file. It is up to the application to decide whether the data needs to be stored in Unicode or ANSI.

Open Kernel32.DLL through the Dependency Walker tool, and you can see the function interfaces contained in it, including CreateFileA and CreateFileW function interfaces, which are the paired function interfaces provided for different string types.
(Dependency Walker tool download link: http://dependencywalker.com/ )

Summarize

This article only organizes and records the main concepts and terms in the Windows operating system, so as to facilitate the learning of the Windows kernel and drivers later. Through reading this article, you can have a certain understanding and familiarity with the general structure of the Windows operating system and some professional terms, and the specific details need to be studied and understood in depth.