如何在 Windows 上保留内存，然后将文件映射到其中？

Question

我想保留一个内存区域，然后将文件连续映射到保留的内存中。在映射文件之间可能存在很大的时间间隔，在此期间其他函数可能会从堆中分配内存。一旦映射，文件可能不会被取消映射并映射到新的内存位置。

在 Linux 上类似于：

#include <iostream>
#include <sys/mman.h>
#include <unistd.h>
#include <fcntl.h>
#include <cerrno>

int main(){
    void *memory = mmap(nullptr, getpagesize() * 2,
                        PROT_READ | PROT_WRITE, MAP_ANONYMOUS | MAP_PRIVATE | MAP_NORESERVE, -1, 0); // reserve memory
    int handle1 = ::open("1", O_CREAT | O_RDWR, S_IRWXU); // open file1
    int handle2 = ::open("2", O_CREAT | O_RDWR, S_IRWXU); // open file2
    void *data = mmap(memory, getpagesize(), PROT_READ | PROT_WRITE, MAP_SHARED |MAP_FIXED, handle1, 0); // map first file into reserved memory
    void *data2 = mmap(static_cast<char *>(memory) + getpagesize(), getpagesize(), PROT_READ | PROT_WRITE, MAP_SHARED | MAP_FIXED, handle2, 0); // map second file into reserved memory
}

但在 Windows 上，我似乎找不到正确的方法来执行此操作。有谁知道这是怎么做到的？

编辑： 由于我的目标似乎并不那么容易理解。再次简化：

我想要内存映射的内存。一旦映射的内存被数据填充，我想在已经映射的内存之后直接将一个新文件映射到内存中以扩展映射的内存（不会在两个内存映射区域之间留下间隙）。

在以后的程序启动时，这些文件可用于恢复之前运行的所有数据。

解决稀疏文件和扩展现有文件的问题： 如果不再需要文件，程序应该能够删除它们。因此，映射始终是新文件很重要。

您可能会将其更多地视为分配器。需要内存映射内存。该库映射一个内存块并返回一个指向子块的指针。不再需要内存，它被返回给分配器。如果不再需要整个映射，则删除关联的文件（如果不再需要，则映射不需要写入数据）。

Answer 1

当您映射文件时，您实际上并不需要保留它，您只需要知道您可以在某处连续映射两个文件。例如，您的 Linux 示例代码是单线程的，如果您在映射到文件之前立即取消映射保留区域，也可以正常工作。

在 Windows 上，处理可能的多线程竞争条件，您可以执行以下操作：

 while(1) {
     char *memory = VirtualAlloc(NULL, page_size * 2, MEM_RESERVE, 0);
     VirtualFree(memory);
     if (MapViewOfFileEx(handle1, FILE_MAP_WRITE, 0, 0, page_size, memory) == NULL
         && GetLastError() == ERROR_INVALID_ADDRESS) {
         continue;
     }
     if (MapViewOfFileEx(handle2, FILE_MAP_WRITE, 0, 0, page_size, memory + page_size) == NULL
         && GetLastError() == ERROR_INVALID_ADDRESS) {
         UnMapViewOfFile(memory);
         continue;
     }
     break;
}

Answer 2

我的解决方案使用了 UNDOCUMENTED api

NTSYSAPI NTSTATUS NTAPI ZwExtendSection ( HANDLE SectionHaqndle, PLARGE_INTEGER SectionSize );

这个功能没有win32模拟，但这是解决的关键点。 我们还需要使用ZwMapViewOfSection 而不是MapViewOfFileEx （win32 shell over ZwMapViewOfSection）因为MapViewOfFileEx 的参数少于ZwMapViewOfSection - 我们不能将ULONG AllocationType 设置为MEM_RESERVE - 但这也是关键点。对于其他任务，我们可以使用 win32 模拟，但为了统一性和风格，我将使用 NT api。

当然，很多人只是说它未记录、不受支持等直接使用 ntdll api - 但它确实有效，在这里我不查看仅基于 win32 的解决方案。所以要的可以用，不要的不能用。原样

这个想法 - 我们只是通过调用 ZwMapViewOfSection 来保留所需的大区域（MapViewOfFileEx 不可能做到这一点），然后在需要时我们可以通过调用 ZwExtendSection 来扩展该区域

解决方案经过测试并有效。

class SECTION_EX
{
    LARGE_INTEGER _CurrentSize, _MaximumSize;
    HANDLE _hSection;
    PVOID _BaseAdress;

public:
    NTSTATUS Create(POBJECT_ATTRIBUTES poa, SIZE_T InitialSize, SIZE_T MaximumSize);
    NTSTATUS Extend(SIZE_T NewSize);

    SECTION_EX()
    {
        _BaseAdress = 0;
        _hSection = 0;
    }

    ~SECTION_EX()
    {
        if (_hSection) 
        {
            if (_BaseAdress) ZwUnmapViewOfSection(NtCurrentProcess(), _BaseAdress);
            ZwClose(_hSection);
        }
    }
};

NTSTATUS SECTION_EX::Extend(SIZE_T NewSize)
{
    LARGE_INTEGER Size;
    Size.QuadPart = NewSize; 

    if (Size.QuadPart <= _CurrentSize.QuadPart)
    {
        return STATUS_SUCCESS;
    }

    if (Size.QuadPart > _MaximumSize.QuadPart)
    {
        return STATUS_SECTION_TOO_BIG;
    }

    NTSTATUS status = ZwExtendSection(_hSection, &Size);

    if (0 <= status)
    {
        _CurrentSize = Size;
    }

    return status;
}

NTSTATUS SECTION_EX::Create(POBJECT_ATTRIBUTES poa, SIZE_T InitialSize, SIZE_T MaximumSize)
{
    HANDLE hFile;
    IO_STATUS_BLOCK iosb;

    NTSTATUS status = ZwCreateFile(&hFile, FILE_GENERIC_READ|FILE_GENERIC_WRITE, poa,
        &iosb, 0, 0, FILE_SHARE_VALID_FLAGS, FILE_OPEN_IF, FILE_SYNCHRONOUS_IO_ALERT, 0, 0);

    if (0 <= status)
    {
        _MaximumSize.QuadPart = MaximumSize;

        LARGE_INTEGER Size, *pSize = &Size;
        Size.QuadPart = InitialSize;

        if (iosb.Information == FILE_OPENED)
        {
            FILE_STANDARD_INFORMATION fsi;

            if (0 <= (status = ZwQueryInformationFile(hFile, &iosb, &fsi, sizeof(fsi), FileStandardInformation)))
            {
                if (fsi.EndOfFile.QuadPart)
                {
                    pSize = 0;// in case file already exist with not zero size - use it
                }
            }
        }

        if (0 <= status)
        {
            status = ZwCreateSection(&_hSection, SECTION_ALL_ACCESS, 0, pSize, 
                PAGE_READWRITE, SEC_COMMIT, hFile);
        }

        ZwClose(hFile);

        if (0 <= status)
        {
            SECTION_BASIC_INFORMATION sbi;

            if (0 <= ZwQuerySection(_hSection, SectionBasicInformation, &sbi, sizeof(sbi), 0))
            {
                _CurrentSize = sbi.Size;// real file size in bytes, without align

                // !!! use MEM_RESERVE !!!
                // MaximumSize - will be reserved, but not all commited

                status = ZwMapViewOfSection(_hSection, NtCurrentProcess(), &_BaseAdress, 0, 
                    0, 0, &MaximumSize, ViewUnmap, MEM_RESERVE, PAGE_READWRITE);
            }
        }
    }

    return status;
}

void demoS()
{
    SECTION_EX se;
    STATIC_OBJECT_ATTRIBUTES(oa, "\\??\\c:\\***");
    // reserve 256Mb,but initially commit only 32kb or file size
    if (0 <= se.Create(&oa, 0x8000, 0x10000000))
    {
        se.Extend(0x18000);
        se.Extend(0x1e245);
        se.Extend(0x74100);
    }
}

---

更新：我发现从 win 8.1 开始，我们可以通过使用的部分保留内存区域 undocumented FILE_MAP_RESERVE - 所以需要调用

_BaseAdress = MapViewOfFileEx(_hSection, FILE_MAP_ALL_ACCESS|FILE_MAP_RESERVE, 0, 0, MaximumSize, 0);

但在 windows 7、vista 和 XP 中 - 这将不起作用。然而，ZwMapViewOfSection 即使在 XP 中也可以使用 MEM_RESERVE 标志。

通常情况 - 与 Nt*/Zw* 函数相比，win32 shell 的功能通常较少。

对于ZwExtendSection 仍然没有任何 win32 模拟/shell（此调用扩展文件和视图）

Answer 3

正确的解决方案是重新架构以消除对相邻映射的要求。

根据您的具体需求，一种方法是使用单个稀疏文件 (as described here)，其初始长度等于您要保留的地址空间量。由于文件稀疏，只有实际使用的块才占用磁盘空间。

否则，您可能需要更改正在处理数据的底层算法，以便它们不再依赖于连续的内存。这通常并不像听起来那么难。

---

一个（完全不正确！）替代方法是挂钩 VirtualAlloc 函数，以便您可以在必要时使其阻塞。这将允许您以有效的原子方式操作保留的内存范围 - 您可以释放它，映射它的一部分，然后重新保留其余部分，类似于 Ross Ridge 的回答，而不用担心另一个线程会分配内存在你这样做的时候。

（这不会保护您免受设备驱动程序的影响，但 AFAIK 设备驱动程序自发地在用户地址空间中分配内存是极其罕见的。）

NB： 我在这里假设由于某种原因使用单个文件是不可接受的。如果可以使用单个文件，则应使用上面建议的稀疏文件。如果由于某种原因单个文件可以，但不能使用稀疏文件，我会推荐 RbMm 的方法而不是这个 - 好 解决方案，但我最好的猜测是这个风险略高。 （当然更难。）