لطفا منتظر باشید ...
Processes and Memory Space
Before you learn how Windows manages memory, you must first understand what a process is. If you already know what a program is, you're on your way. A program is an EXE file that you can launch in various ways in Windows. Once a program is running, it's called a process. A process owns its memory, file handles, and other system resources. If you launch the same program twice in a row, you'll have two separate processes running simultaneously. The Windows Task Manager (right-click on the taskbar) gives you a detailed list of processes that are currently running, and they allow you to kill processes that are not responding. The SPYXX.exe program (which is also included with Visual Studio) shows the relationships among processes, threads, and windows.
| Note | The Windows Task Manager shows running programs and active processes. The Processes tab shows active processes. A single process (such as Windows Explorer) might have several main windows, each supported by its own thread, and some processes don't have windows at all. (See Chapter 11 for a discussion of threads.) |
| Note | The Microsoft .NET Framework provides a new level of isolation: the AppDomain. We'll look at AppDomains in Chapter 10. |
The important thing to know about a process is that it has its own "private" 4 GB virtual address space (which I'll describe in detail shortly). For now, pretend that your computer has hundreds of gigabytes of RAM and that each process gets 4 GB. Your program can access any byte of this space with a single 32-bit linear address. Each process's memory space contains a variety of items, including the following:
Your program's EXE image
Any nonsystem DLLs that your program loads, including the MFC DLLs
Your program's global data (read-only as well as read/write)
Your program's stack
Dynamically allocated memory, including Windows and C runtime library (CRT) heaps
Memory-mapped files
Interprocess shared memory blocks
Memory local to specific executing threads
All sorts of special system memory blocks, including virtual memory tables
The Windows kernel and executive, plus DLLs that are part of Windows
The Windows 95/98 Process Address Space
In Windows 95/98, only the bottom 2 GB (0 to 0x7FFFFFFF) of address space is truly private, and the bottom 4 MB of that is off-limits. The stack, heaps, and read/write global memory are mapped in the bottom 2 GB, along with application EXE and DLL files.The top 2 GB of space is the same for all processes and is shared by all processes. The Windows 95/98 kernel, executive, virtual device drivers (VxDs), and file system code, along with important tables such as page tables, are mapped to the top 1 GB (0xC0000000 to 0xFFFFFFFF) of address space. Windows DLLs and memory-mapped files are located in the range 0x80000000 to 0xBFFFFFFF.Figure 10-1 shows a memory map of two processes using the same program.
Figure 10-1: A typical Windows 95/98 virtual memory map for two processes linked to the same EXE file.
How safe is all this? It's next to impossible for one process to overwrite another process's stack, global, or heap memory because this memory, located in the bottom 2 GB of virtual address space, is assigned only to that specific process. All EXE and DLL code is flagged as read-only, so there's no problem if the code is mapped in several processes.However, because important Windows read/write data is mapped there, the top 1 GB of address space is vulnerable. An errant program could wipe out important system tables located in this region. In addition, one process could mess up another process's memory-mapped files in the range 0x80000000 through 0xBFFFFFFF because this region is shared by all processes.
The Windows NT/2000/XP Process Address Space
A process in Windows NT/2000/XP can access only the bottom 2 GB of its address space, and the lowest and highest 64 KB of that is inaccessible. The EXE, the application's DLLs and Windows DLLs, and memory-mapped files all reside in this space between 0x00010000 and 0x7FFEFFFF. The Windows NT kernel, executive, and device drivers all reside in the upper 2 GB, where they're completely protected from any tampering by an errant program. Memory-mapped files are safer, too. One process cannot access another's memory-mapped file without knowing the file's name and explicitly mapping a view.
