| UID | title | description | helpviewer_keywords | old-location | tech.root | ms.assetid | ms.date | ms.keywords | req.header | req.include-header | req.target-type | req.target-min-winverclnt | req.target-min-winversvr | req.kmdf-ver | req.umdf-ver | req.ddi-compliance | req.unicode-ansi | req.idl | req.max-support | req.namespace | req.assembly | req.type-library | req.lib | req.dll | req.irql | targetos | req.typenames | req.redist | ms.custom | f1_keywords | dev_langs | topic_type | api_type | api_location | api_name | ||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
NF:memoryapi.MapViewOfFile3FromApp |
MapViewOfFile3FromApp function (memoryapi.h) |
Maps a view of a file mapping into the address space of a calling Windows Store app. (MapViewOfFile3FromApp) |
|
base\mapviewoffile3fromapp.htm |
base |
5E10E1B2-69D9-4F68-8F06-D411CF7FE2ED |
12/05/2018 |
MEM_LARGE_PAGES, MEM_REPLACE_PLACEHOLDER, MEM_RESERVE, MapViewOfFile3FromApp, MapViewOfFile3FromApp function, base.mapviewoffile3fromapp, memoryapi/MapViewOfFile3FromApp |
memoryapi.h |
Windows.h |
Windows |
Windows 10 [desktop apps only] |
Windows Server 2016 [desktop apps only] |
WindowsApp.lib |
Kernel32.dll |
Windows |
19H1 |
|
|
|
|
|
|
Maps a view of a file mapping into the address space of a calling Windows Store app.
Using this function, you can: for new allocations, specify a range of virtual address space and a power-of-2 alignment restriction; specify an arbitrary number of extended parameters; specify a preferred NUMA node for the physical memory as an extended parameter; and specify a placeholder operation (specifically, replacement).
To specify the NUMA node, see the ExtendedParameters parameter.
A HANDLE to a section that is to be mapped into the address space of the specified process.
A HANDLE to a process into which the section will be mapped.
The desired base address of the view. The address is rounded down to the nearest 64k boundary.
If this parameter is <b>NULL</b>, the system picks the base
address.
If BaseAddress is not NULL, then any provided MEM_ADDRESS_REQUIREMENTS structure must consist of all zeroes.
The offset from the beginning of the section. This must be 64k aligned.
The number of bytes to map. A value of zero (0) specifies that the entire section is to be mapped.
The size must always be a multiple of the page size.
The type of memory allocation. This parameter can be zero (0) or one of the following values.
| Value | Meaning |
|---|---|
|
Maps a reserved view. |
|
Replaces a placeholder with a mapped view. Only data/pf-backed section views are supported (no images, physical memory, etc.). When you replace a placeholder, BaseAddress and ViewSize must exactly match those of the placeholder,
and any provided MEM_ADDRESS_REQUIREMENTS structure must consist of all zeroes.
After you replace a placeholder with a mapped view, to free that mapped view back to a placeholder, see the UnmapFlags parameter of UnmapViewOfFileEx and UnmapViewOfFile2. A placeholder is a type of reserved memory region. |
|
Maps a large page view. See large page support. |
The desired page protection.
For file-mapping objects created with the SEC_IMAGE attribute, the PageProtection parameter has no effect, and should be set to any valid value such as PAGE_READONLY.
An optional pointer to one or more extended parameters of type MEM_EXTENDED_PARAMETER. Each of those extended parameter values can itself have a Type field of either MemExtendedParameterAddressRequirements or MemExtendedParameterNumaNode. If no MemExtendedParameterNumaNode extended parameter is provided, then the behavior is the same as for the VirtualAlloc/MapViewOfFile functions (that is, the preferred NUMA node for the physical pages is determined based on the ideal processor of the thread that first accesses the memory).
The number of extended parameters pointed to by ExtendedParameters.
Returns the base address of the mapped view, if successful. Otherwise, returns NULL and extended error status is available using GetLastError.
This API helps support high-performance games, and server applications, which have particular requirements around managing their virtual address space. For example, mapping memory on top of a previously reserved region; this is useful for implementing an automatically wrapping ring buffer. And allocating memory with specific alignment; for example, to enable your application to commit large/huge page-mapped regions on demand.
With one important exception, file views derived from any file mapping object that is backed by the same file are coherent or identical at a specific time. Coherency is guaranteed for views within a process and for views that are mapped by different processes.
The exception is related to remote files. Although MapViewOfFile3FromApp works with remote files, it does not keep them coherent. For example, if two computers both map a file as writable, and both change the same page, each computer only sees its own writes to the page. When the data gets updated on the disk, it is not merged.
You can only successfully request executable protection if your app has the codeGeneration capability.
For a code example, see Scenario 1 in Virtual2Alloc.