CreateFileMapping How to use

CreateFileMapping's MSDN translation and usage experience

Testing the creation and opening of the file map always get the "Invalid handle" error, after careful look at MSDN only to realize that the function is not understood, here to translate the relevant explanations

HANDLE CreateFileMapping (
HANDLE hfile,//physical file handle
Lpsecurity_attributes lpattributes,//Security settings
DWORD Flprotect,//Protection settings
DWORD Dwmaximumsizehigh,//High file size
DWORD Dwmaximumsizelow,//low file size
LPCTSTR lpname//Shared memory name
);

1) Physical file handle
No matter what physical file handle you can get, suppose you need to create a physical file-independent memory map, and set it to 0xFFFFFFFF (INVALID_HANDLE_VALUE).

If you need to associate with a physical file, make sure that the access mode and the "Protection settings" match when your physical file is created, for example: physical files are read-only and memory-mapped needs to be read and written. It is recommended that your physical files be created in exclusive fashion.

Assuming that you use INVALID_HANDLE_VALUE, you also need to set the size of the memory space to be requested, regardless of whether the physical file handle is valid, so that createfilemapping can create a memory space unrelated to the physical file size to you,  Even more than the actual file size, assuming that your physical file is valid, and the size of the number of participants is 0, then return to you is a physical file size of the same memory space address range. The file mapped address space returned to you is capable of being copied, integrated or named, with initial content of 0.

2) Protection settings
Is the security settings, only the general setting of NULL will be able to use the default security configuration. Under Win2K, it is assumed that there is a need to limit the use of application processes that share memory file mappings with the entire network, and that can be considered for throttling.

3) High File size
Brethren, I think our machines are 32 bits at the moment, it is impossible to get a private 32-bit address space that can be addressed by more than 32-bit processes, usually set 0, and I don't want to try to set it above 0.
4) Low File size
This is still able to be set up, just to let other shared users know about the file mapping you requested information, I use the address space in the acquisition of the header to join? A structured descriptive narrative information, the size of the memory map, name, etc., so that the actual application of space than the input added? The size of a header information structure, I think this way similar to a BSTR should be more reasonable.

5) Shared Memory name
This is the bane of my test today, because I set up a mutually exclusive handle for the purpose of mutual exclusion of memory, and the name I chose and named Shared memory, the next is because they use common namespace caused the error, hehe.

7) GetLastError corresponding error when calling CreateFileMapping
Error_file_invalid assumes that an attempt is made to create a 0-length file map, which should be reported
Error_invalid_handle assumes that your named memory space and existing memory mappings, mutually exclusive amounts, semaphores, the same name as the critical section are troublesome.
Error_already_exists indicates that a memory space name already exists

8) naming retention for related services or platforms
Terminal Services:
The naming can include "global\" or "local\" prefixes in global or Session namespace 0 base file mappings. Other parts can include any character other than (\), and can refer to Kernel Object Name Spaces.

Windows $ or later:
It is assumed that Terminal Services does not perform the special meaning of "global\" and "local\" prefixes.

createfilemapping function (reprint)
The memory-mapped API function CreateFileMapping creates a well-known shared memory:
HANDLE CreateFileMapping (
HANDLE hfile,//handle to the map file,
Set to 0xFFFFFFFF to create an inter-process shared object
Lpsecurity_attributes lpfilemappingattributes,//Security properties
DWORD Flprotect,//protection mode
DWORD Dwmaximumsizehigh,//Size of Object
DWORD Dwmaximumsizelow,
LPCTSTR lpname//must be named for the mapping file
);

Like virtual memory, protection can be page_readonly or page_readwrite. Assuming that multiple processes are writing to the same shared memory, you must maintain synchronization with each other. The mapping file can also specify the PAGE_WRITECOPY flag to ensure that its original data is not compromised and that the other process is free to manipulate copies of the data when necessary.

After creating the file-mapping object, use the ability to call the MapViewOfFile function to map to the address space of the process.

The following instructions create a well-known map file named Mysharedmem with a length of 4096 bytes:
HANDLE hmysharedmapfile=createfilemapping ((HANDLE) 0xFFFFFFFF),
null,page_readwrite,0,0x1000, "Mysharedmem");
and map the buffer view:
LPSTR pszmysharedmapview= (LPSTR) mapviewoffile (Hmysharedmapfile,
file_map_read| file_map_write,0,0,0);

Other processes to access the shared object, you need to get the object name and call the OpenFileMapping function.
HANDLE hmysharedmapfile=openfilemapping (File_map_write,
FALSE, "Mysharedmem");

Once the other process obtains a handle to the mapped object, it can invoke the MapViewOfFile function as the creation process to map the object view. Users can use the object view for data read and write operations to achieve the purpose of data communication.

After the user process has finished using shared memory, call the UnmapViewOfFile function to cancel the view within its address space:
if (! UnmapViewOfFile (Pszmysharedmapview))
{

AfxMessageBox ("Could not unmap view of file");

}

Create a File View

    to map the data in the file to the virtual memory of the process, you must create a view of the file. The
    mapviewoffile and Mapviewoffileex functions use the file-map object handle returned by CreateFileMapping to create a view of the file in the virtual address space of the process. Or a portion of a file. Assuming that the permission flags specified by these functions are inconsistent with the permission flags in the CreateFileMapping, the run fails. The
    mapviewoffile function returns a pointer to the file view. Using the address pointers declared in the MapViewOfFile, the program can read from the file and write data to the file. Writing data to a file view causes the file-mapping object to change. A file that actually writes data to disk is handled by the system. The data is not immediately written to disk, and the input and output of very many files are cached to improve the performance of the system. The program can call the Flushviewoffile function over this way, forcing the system to immediately write the data to disk. The
    Mapviewoffileex function and the MapViewOfFile function work exactly the same, just to take advantage of the lpvbase parameters of the Mapviewoffileex function, To specify the base address of the file view in the process virtual address space. Assuming that there is not enough space at the specified address, the call fails.
    1, the lpvbase parameter must be an integer multiple of the minimum unit of system memory, or the call will fail. To get the smallest unit of system memory, using the GetSystemInfo function, he writes the information to the members of the SYSTEM_INFO structure. The
    program can create multiple file views from the same file-mapping object. File views can be of different sizes, but they must be smaller than file-mapped objects. The Dwoffsethigh and Dwoffsetlow parameters of the MapViewOfFile function must be an integer multiple of the minimum unit of system memory.

File mapping issues
The memory-mapped file is not a simple file I/O operation, it actually uses the core programming technology of Windows-memory management. Therefore, the false assumption of memory mapping files have a deeper understanding, must have a clear understanding of the Windows operating system memory management mechanism, memory management knowledge is complex, beyond the scope of this article, no longer repeat, interested readers can refer to other related books. The following is a general way to use a memory-mapped file:

The first thing to do is to create or open a file kernel object through the CreateFile () function, which identifies the file on disk that will be used as a memory-mapped file. After the file image is advertised to the operating system in the location of the physical memory with CreateFile (), only the path to the image file is specified, and the length of the image is not specified. To specify how much physical storage is required for a file mapping object, you also need to use the createfilemapping () function to create a file map kernel object to tell the system file size and how to access the file. After you create a file-mapping object, you must also reserve an address space area for the file data and submit the file data as a physical memory that is mapped to the zone. It is the responsibility of the MapViewOfFile () function to map all or part of a file-mapped object to the process address space through the management of the system. At this point, the use and processing of the memory-mapped file is basically the same as the processing of the file data that is normally loaded into memory, and when the memory-mapped file is used, it is cleared by a series of operations and the release of the resource is used. This is relatively simple and can be done by UnmapViewOfFile () to undo the image of the file data from the process's address space, and close the previously created file-mapping object and file object by CloseHandle ().

Memory-mapped file-related functions

When using a memory-mapped file, the API functions used are mostly the ones mentioned earlier, which are described in the following separate sections:

HANDLE CreateFile (LPCTSTR lpfilename,
DWORD dwDesiredAccess,
DWORD dwShareMode,
Lpsecurity_attributes lpSecurityAttributes,
DWORD dwCreationDisposition,
DWORD dwFlagsAndAttributes,
HANDLE htemplatefile);

The function CreateFile () is often used to create and open files even during normal file operations, and when processing a memory-mapped file, the function creates/opens a file kernel object and returns its handle. When calling this function, it is necessary to set the parameters dwDesiredAccess and dwShareMode according to whether the data read and write and the file share, the wrong parameter setting will cause the failure of the corresponding operation.

HANDLE createfilemapping (HANDLE hfile,
Lpsecurity_attributes Lpfilemappingattributes,
DWORD Flprotect,
DWORD Dwmaximumsizehigh,
DWORD Dwmaximumsizelow,
LPCTSTR lpname);

The CreateFileMapping () function creates a file-mapped kernel object that specifies the file handle to be mapped to the process address space by the parameter hfile (the handle is obtained by the return value of the CreateFile () function). Since the physical memory of a memory-mapped file is actually a file stored on disk, not the memory allocated from the system's page file, the system does not actively reserve the address space area for it, nor does it proactively map the storage space of the file to that region, in order for the system to determine what protection properties are taken on the page. It needs to be set by the parameter flprotect, and the protection attributes Page_readonly, Page_readwrite, and page_writecopy respectively indicate that the file mapping object is mapped and can read and read and write the file data. When using page_readonly, it is important to ensure that the CreateFile () is Generic_read and Page_readwrite requires CreateFile () generic_read| Generic_write, the attribute page_writecopy only needs to make sure that CreateFile () uses one of the Generic_read and Generic_write. The DWORD-type parameters Dwmaximumsizehigh and Dwmaximumsizelow are also important, specifying the maximum number of bytes of the file because the two parameters are 64 bits in length, so the maximum supported file lengths are 16EB. Almost enough to meet the requirements of large data volume file processing situations.

LPVOID MapViewOfFile (HANDLE hfilemappingobject,
DWORD dwDesiredAccess,
DWORD Dwfileoffsethigh,
DWORD Dwfileoffsetlow,
DWORD Dwnumberofbytestomap);

The MapViewOfFile () function is responsible for mapping the file data to the address space of the process, hfilemappingobject the file image object handle returned by the createfilemapping (). The parameter dwdesiredaccess again specifies how the file data will be visited, and the same must match the protection attributes set by the CreateFileMapping () function. Although it may seem superfluous to repeatedly set the protection properties here and there, it allows the application to control many of the other data protection properties effectively. The MapViewOfFile () function agrees with all or part of the mapping file, specifying the offset address of the data file and the length to be mapped when mapping. , the offset address of the file is specified by a 64-bit value consisting of the Dwfileoffsethigh and Dwfileoffsetlow of the DWORD type, and must be an integer multiple of the allocation granularity of the operating system, and the allocation granularity is fixed to 64KB for the Windows operating system. Of course, you can also dynamically get the allocation granularity of the current operating system by, for example, the following code:

System_info Sinf;
GetSystemInfo (&sinf);
DWORD dwallocationgranularity = sinf.dwallocationgranularity;

The parameter dwnumberofbytestomap specifies the length of the mapping for the data file, and it is particularly noted that for the Windows 9x operating system, it is assumed that mapviewoffile () cannot find a large enough area to hold the entire file-mapping object. NULL is returned (NULL), but under Windows 2000, MapViewOfFile () only needs to find a large enough area for the necessary view, regardless of the size of the entire file-mapping object.

After the processing of the file mapped to the process address space area is completed, the release of the file data image through function UnmapViewOfFile () is completed, and the function prototype declares such as the following:

BOOL unmapviewoffile (lpcvoid lpbaseaddress);

The unique parameter lpbaseaddress specifies the base address of the return range, which must be set to the return value of MapViewOfFile (). After the function mapviewoffile () is used, a corresponding unmapviewoffile () call is required, otherwise the reserved area will not be freed until the process terminates. In addition, the CreateFile () and createfilemapping () functions have been previously created by the file kernel object and the file map kernel object, it is necessary to release it through the CloseHandle () before the process terminates, otherwise there will be a resource leak problem.

In addition to these required API functions, there are other auxiliary functions to use when using memory-mapped files, depending on the situation. For example, when using a memory-mapped file, the system quickly caches the file's data page for faster speed, and does not update the file's disk image as soon as the file map view is processed. To solve the problem, consider using the Flushviewoffile () function, which forces the system to write the changed data part or all of the disk images again, ensuring that all data updates are saved to disk in a timely manner.

Shared Memory Object Method (MapViewOfFile)
Shared memory object methods Typically, memory-mapped files that are supported by a paging file are used as techniques for sharing memory between user processes. However, the same technique can be used to share memory between user processes and device drivers. There are two ways to use this technique.

In the first method, by using openfilemapping, and then calling the MapViewOfFile function to get a pointer to a zone or all of the shared memory, the driver can create a named memory object (called a "zone object"). And one or more user applications can open the same object. You can define how the process manipulates memory by specifying protection properties to the Zone object.

In another approach, an application can create named memory objects in user mode with CreateFileMapping. The driver can open the same memory object by using Zwopensection and calling Zwmapviewofsection to get a pointer to it. Always use the exception handler to access this memory address in kernel mode.

Because the object is always mapped in the user address space of the process (less than 0x80000000, regardless of whether the object was created in kernel mode or in user mode), the address is valid only when the address is visited in the context of the process. Each time a mapviewoffile or zwmapviewofsection is called on the same memory object, a different memory address is returned (even for the same process). It is not recommended to use such a method (especially for low-level device drivers), as described earlier, because the address range is limited to the process of object mapping, and addresses cannot be interviewed in DPC or ISR. In addition, the API for creating memory objects in kernel mode is not documented in DDK.

However, to use this address on an improved IRQL (such as DPC or ISR), you must identify and lock the buffer page and obtain the system virtual address mmgetsystemaddressformdl (as described in the IOCTL method earlier in this article).

Such a method is easier only if you want to share memory between two (or many other) user processes and one or more device drivers. Otherwise, using IOCTL technology to share memory between user processes and device drivers is simpler and more efficient.

Memory-Mapped file technology
1. Use and basic operation
For memory sharing between different processes, the ability to map a physical file to memory and then directly utilize the allocated or open address space of the named shared memory for resource sharing access

2. Related processes
1) Create a new named Shared Memory
First obtain a physical file handle for the mapping using CreateFile or createfileformapping. The file handle is then combined with createfilemapping to get a named shared memory map file handle.
//createfilemapping Create a well-known or nameless file image for the specified file;
HANDLE createfilemapping (
  HANDLE hfile,   Handle to            //Map file
  Lpsecurity_attributes Lpfilemappingattributes,//Security descriptive descriptor pointer
  DWORD flprotect,           //Protection of mapped objects
  DWORD dwmaximumsizehigh,  //High 32 bits of object maximum length
  DWORD dwmaximumsizelow,   //object Maximum length low 32-bit
  LPCTSTR lpname       The name of the       //File memory mapped object
);

Attention:
Hfile: The handle to the map file, the open mode of the file must be the same as the flprotect, assuming that the value is 0xFFFFFFFF, Then the size of the mapped object must be specified in the Dwmaximumsizehigh and Dwmaximumsizelow parameters. The file mapping object will be created in the operating system virtual memory page replacement file instead of using the disk file, and the size of the mapped object must be given at the same time. File mapping objects are shared by a copy, heredity, or name.
Lpfilemappingattributes: Security Descriptive descriptor pointer, determines whether the return handle can be inherited by the quilt process, assuming null, then the child process cannot inherit. In Winnt, if NULL is assumed, then the file map object gets a default security descriptor.
Flprotect: An attempt was made to specify a protected mode for the resulting file, which can be set to the following values:
Page_readonly: Read Only property, and hfile the corresponding file must be opened in generic_read form.
Page_readwrite: Readable writable properties, and hfile the corresponding files must be opened in Generic_read and Generic_write form.
Page_writecopy: Post-Copy operations on writable regions, and hfile the corresponding files must be opened in Generic_read and Generic_write form.
Dwmaximumsizehigh,dwmaximumsizelow: Assuming that the two parameters are 0, the maximum length of the file mapping object is equal to the file length specified by hfile.
Lpname: The name of the file mapping object, assuming that the name already exists, the mapping object is processed according to the flprotect specified. If this parameter is empty, a file-map object with no name is created. Assuming that the name of the parameter is the same as the name of the system event, the function fails and GetLastError returns Error_invalid_handle;

Return value: The function call successfully returns a handle to the file-map object, assuming that the file-mapping object already exists and returns the handle to the original mapping object, GetLastError returns ERROR_ALREADY_EXISTS. The function failed to run and returned null.

2) Open named shared memory
Suppose you need to share a named shared memory-mapped file that already exists, using the openfilemapping function.
OpenFileMapping opening a named file-mapping object
HANDLE openfilemapping (
DWORD dwdesiredaccess,//Interview mode
BOOL bInheritHandle,//Inheritance flag
LPCTSTR lpname//File map object name pointer
);
Attention:
dwDesiredAccess: The interview mode is the same as the access mode in MapViewOfFile.
bInheritHandle: Inheritance flag, can be used by a new process to inherit, assuming true, you can be a new process to inherit the handle.
return value:
A named file-mapping object was successfully returned, and Null was returned by failure.

3) Get the address space pointer
The memory mapped file read-write and general file read and write different, is directly facing your application address space, for this need to use MapViewOfFile to get the relevant address LPVOID type pointer. Suppose you need to write a file, you can assign a value directly to the memory address by type conversion, for example:
memcpy (lpaddress, lpbuf, ...)
There is a natural need to prevent a memory overflow situation.
Suppose it is a read operation, it is possible to adjust the order of the parameters.

MapViewOfFile maps a file view in the calling process's address space
LPVoid mapviewoffile (
  HANDLE hfilemappingobject, // File map object handle created
  DWORD dwdesiredaccess,     //Access Mode
  DWORD Dwfileoffsethigh ,    //File offset high 32-bit
  DWORD dwfileoffsetlow,     //Low 32-bit file offset
  DWORD dwnumberofbytestomap //size of Map view
);
Note:
Hfilemappingobject: A handle to the file-map object returned by createfilemapping or openfilemapping.
dwDesiredAccess: The access mode of the map view, which is related to the protection mode Flprotect of creating a file-mapped object, can be set to the following values:
 file_map_write: A file view of a read-write property is created, Protected mode is Page_readwrite
 file_map_read: A file view of a read-only property is created with a protected mode of Page_readwrite or page_readonly
 file_map _all_access: The same as the File_map_write mode
 file_map_copy: When the protection mode is page_writecopy, a view file is obtained, and when you write to the image file, the page actively exchanges itself. And the changes you make will not damage the original data.
Dwnumberofbytestomap: The size of the map file section, assuming 0, maps the entire file.
Return value:
assumes that a successful return returns the starting address of the mapped view, assuming that the failure returns NULL.

4) Mapviewoffileex maps a file view in the address space of the calling process, and agrees that the calling process specifies a special memory address for the mapping view
LPVOID Mapviewoffileex (
HANDLE Hfilemappingobject,//handle to the file map object
DWORD dwdesiredaccess,//Interview mode
DWORD Dwfileoffsethigh,//High 32 bits of file offset
DWORD Dwfileoffsetlow,//Low 32 bits for file offset
DWORD Dwnumberofbytestomap,//size of the map view
LPVOID lpbaseaddress//Specify the de facto memory address of the map view
);
Attention:
As with MapViewOfFile, the function fails if the specified memory address space is not large enough.

5) Copy the memory to the mapped physical file
The Flushmapviewoffile function can dump the contents of the memory onto the physical disk.
Flushviewoffile write the contents or all of the changes in the file map view back to the disk file
BOOL Flushviewoffile (
Lpcvoid lpbaseaddress,//change the start address of the content
DWORD Dwnumberofbytestoflush//number of bytes changed
);
function run successfully returned nonzero.

6) Unload memory map file address pointer
The Unmapviewofffile function is the Unload
UnmapViewOfFile map view of deleted files
BOOL UnmapViewOfFile (
Lpcvoid lpbaseaddress//Map view start address
);
Attention:
Lpbaseaddress: The map view start address, generated by the MapViewOfFile function Mapviewoffileex.
return value:
Assuming that the call successfully returns nonzero, the dirty pages in all the specified addresses are written to the hard disk. The call failed to return zero.

7) Close the memory-mapped file
It's too easy, CloseHandle.

CreateFileMapping How to use