Working Principle and usage of memory ing files in Windows

I. Introduction
Win32 API provides us with an efficient way to perform file operations, that is, memory ing files. The memory ing file allows us to reserve a memory area in the virtual address space of the Win32 process and map the target file to the virtual memory. We can directly operate the data in the file by accessing the memory data, as if the data was stored in the memory. In fact, we do not and do not need to call API functions to read and write files, and we do not need to provide any caching algorithms on our own. The operating system will do this for us. The use of memory ing files can provide great convenience for program development and high program running efficiency.
The implementation mechanism of memory ing files in Windows NT and Windows 95 is slightly different. The following describes the working principle and usage of memory ing files in Windows 95.
Ii. How to manage the memory space of Win32 processes in Windows 95
The implementation of memory ing files is closely related to the memory management of Windows 95. Therefore, we should first discuss the memory management and division of Windows 95 when running the Win32 process.
In Windows 3.x, all Windows applications share a single address space. Any process can perform read/write operations on the memory of other processes in this space, you can even access important data of the operating system. In such an environment, writing improper applications or malicious applications may corrupt the data or code of other programs, making the system abnormal, in severe cases, the system may even crash.
In Windows NT and Windows 95 that have implemented Win32, each Win32 process has its own address space. A Win32 process cannot access the private data of another process address space, two processes can be addressable with pointers with the same value, but only their data is read and written. This greatly reduces mutual interference between processes and enhances system robustness; on the other hand, each Win32 process has a 4 GB address space, but it does not mean that it actually has 4 GB of physical memory, but only the virtual address space provided by the operating system using the CPU memory paging function. Generally, the vast majority of virtual addresses do not correspond to physical memory. The actual physical memory needs to be provided by the operating system before these address spaces can be used. The actual physical memory provided for the virtual address is called & ldquo; Submit & rdquo; (COMMIT ). Under different circumstances, the physical memory types submitted by the system are different, Either ram or Virtual Memory Simulated by the hard disk.
The address space of Win32 process in Windows95 is divided as follows:
4 MB at the bottom of the address space is used by Windows95 to maintain compatibility with DOS and 16-bit windows. Ideally, the Win32 process should not be able to access this memory segment. However, due to implementation difficulties, Windows95 can only protect the low-end 4kb area from 0x00000000 to 0x00000fff, which is used to capture the NULL pointer. The 1 GB space from 0x80000000 to 0xbfffffff is shared by all Win32 processes, and the memory ing file uses this address space. The high-end 1 GB space is used by Windows 95. Unlike Windows NT, this space is not protected, and any process may destroy the data.
Iii. Working Principle of memory ing files
Memory ing files are divided into three situations: Memory ing of executable files, which is mainly used by Windows95; Memory ing of data files; the last is the memory ing of Page Swap files. Applications can use the following two memory ing files.
1. Memory ing of executable files
Windows95 uses a memory ing file when executing a Win32 application, which reserves sufficient address space for the EXE file to be executed. Generally, this space starts from the loading address 0x00400000 of the Win32 process. The physical storage submitted by the system to this space is the EXE file on the hard disk. After all preparations are made, the system starts to execute this program. At the beginning, the code of the program is not in Ram. When the first command of the program entry is executed, a page exception is generated. After the system detects this exception, it allocates a block of RAM, map it to 0x00400000, read the actual code, and continue to execute. In the future, page exceptions will also occur when code not in Ram is executed, so that the system has the opportunity to read the code. The system processes win32dll in a similar way, but the address space mapped to the DLL is shared by all Win32 processes.
When you run the second instance of the same application, the system knows that the program already has an instance, and the code and data of the EXE file have been read to ram, the system only needs to map this ram segment to the address space of the new process. This allows you to share the code and data in Ram. In fact, this type of sharing only applies to read-only data. Once a process changes its own code and data, the operating system copies the page where the modified data is located and assigns it to the process performing the write operation, this avoids mutual interference between multiple instances.
Of course, the actual process of running a Win32 application in the operating system is very complicated. The above describes only the working principle. We can use softicefor Windows95 to verify that the operating system executes an application in the form of a ing file: When wldr is used to call an application such as Notepad for the first time, SoftICE is activated. The entry code of the program it lists is invalid (invalid), which indicates that the page where the code to be executed is not in Ram. Press F8 and execute one command in a single step. The real program commands are immediately listed on the screen. This is because a page exception occurs first during command execution. When the operating system processes a page exception, read the code into RAM. When SoftICE is activated again, you can see the READ command. Further checks also show that the system reads a page (4 kb) to ram each time to save as much memory as possible. We use wldr to call the second notepad instance. This time, the entry code listed after SoftICE is activated is no longer invalid, but a real program instruction. Since SoftICE is a system-level debugger, when it is used to modify applications in memory, the operating system does not copy pages. We made some changes to the notepad entry code, and then transferred it to the third instance using wldr. This time, we can find that the listed entry code has just been modified, but the actual EXE file has not changed. This indicates that, the operating system maps the program code in the same block of Ram to the address space of multiple processes, thus implementing the program code in the shared RAM.
2. Memory ing of data files
The working principle of Data File Memory ing is the same as that of executable files. First, map a part of the data file to the virtual address space (the mapped area is in 0x80000000-0xbfffffff), but do not submit the ram, the command to access this memory also produces page exceptions. After the operating system detects this exception, it allocates a page of Ram and maps it to the address where the current process encounters an exception. Then the System reads the corresponding data in the file to this page, continue to execute the command that generated the exception. This is why the application itself does not need to call the file I/O function.
3. Memory ing Based on Page Swap files
The third case of memory ing files is based on Page Swap files. A Win32 process can use the memory ing file to reserve an area in the address space shared by the Win32 process. This area is associated with the system's Page Swap file. We can use it to store temporary data, but a more common usage is to use it to communicate with other Win32 processes. In fact, Win32 implements various methods for multi-process communication through memory ing files. For example, the postmessage () function or the sendmessage () function uses memory ing files internally.
Iv. Methods for using memory ing files
1. Use the memory ing file to perform file I/O operations. The following steps are required for file I/O operations:
Step 1: Call the createfile () function to create or open a file core object in an appropriate way;
Step 2: Pass the file handle returned by the createfile () function as a parameter to the createfilemapping () function. The createfilemapping () function creates an appropriate attribute for the file ing core object;
Step 3: after creating a file ing core object, call the mapviewoffile () function to tell the system which part of the file is mapped to the address space of the process and in which way the file is mapped;
Step 4: Use the pointer returned by the mapviewoffile () function to use file data;
Step 5: after the operation, call the unmapviewoffile () function to notify the system to cancel the ing of the core object mapped to the file;
Step 6: Use the closehandle () function to close the file ing core object;
Step 7: Use the closehandle () function to close the core object of the file;
For more information about each API function, see the online help of windows95sdk or some programming tools.
2. Use the memory ing file to implement Win32 inter-process communication
In Windows 95, the ing area of the file ing object opened by a process is visible to all Win32 processes, and the address of the ing area is the same for all Win32 processes. A process can open a file, create a file ing core object, use the mapviewoffile () function to open the file view, and then pass the file ing address to another process, the second process can read the data in the file. This method requires synchronization between processes, which is difficult to implement. In Windows NT, A ing area has different IP addresses in different Win32 process spaces. Therefore, to be compatible with Windows NT, try not to use this method.
The second method is to map two processes to the core object using the same file, open their own views, or the parent process inherits the core object mapped to the file created by the parent process to the child process. This method is safe and effective.

The third method is to create a memory ing object based on the page swap file. When calling the createfilemapping () function, the transfer file handle is 0 xffffffff, the system submits the physical storage from the page swap file, and then processes communicate with each other in the second way. This method is convenient without having to prepare a special file in advance.

Address: http://www.cnblogs.com/finallyliuyu/archive/2010/10/13/1850080.html