Right (on x86-32 and -64, because you can’t have 64KB pages there, though larger page sizes do exist and get used). You still cannot (e.g.) MapViewOfFile() on an address not divisible by 64KB, because Alpha[1]. As far as I understand, Windows is mostly why the docs for the Blink emulator[2] (a companion project of Cosmopolitan libc) tell you any programs under it need to use sysconf(_SC_PAGESIZE) [aka getpagesize() aka getauxval(AT_PAGESZ)] instead of assuming 4KB.

[1] https://devblogs.microsoft.com/oldnewthing/20031008-00/?p=42...

[2] https://github.com/jart/blink/blob/master/README.md#compilin...

this is no longer true with MapViewOfFile3: Third time's a charm, now you can map to page boundaries

TIL about MapViewOfFile3 and NtMapViewOfSectionEx, thanks! Still, the Microsoft docs say[1]:

> [in, optional] BaseAddress

> The desired base address of the view (the address is rounded down to the nearest 64k boundary).

> [...]

> [in] Offset

> The offset from the beginning of the section.

> The offset must be 64k aligned.

The peculiar part is where base address and offset must be divisible by 64K (also referred to as the “allocation granularity”) but the size only needs to be divisible by the page size. Maybe you’re right and the docs are wrong?..

[1] https://learn.microsoft.com/en-us/windows/win32/api/memoryap...

the new behavior works under the MEM_REPLACE_PLACEHOLDER flag, you can create those regions with VirtualAlloc2

4K, 2M ("large page"), or 1G ("huge page") on x86-64. A single allocation request can consist of multiple page sizes. From Windows Internal 7th Edt Part 1:

    On Windows 10 version 1607 x64 and Server 2016 systems, large pages may also be mapped with huge pages, which are 1 GB in size. This is done automatically if the allocation size requested is larger than 1 GB, but it does not have to be a multiple of 1 GB. For example, an allocation of 1040 MB would result in using one huge page (1024 MB) plus 8 “normal” large pages (16 MB divided by 2 MB).