On x64 we only map 1GB of pages, so adjust MM_MAX_PAGE accordingly and also respect that value when searching for the best location of the page lookup table.
CORE-11048 #resolve
The PROCESS_DEVICEMAP_INFORMATION union has 2 fields, one is a handle, the other one is a structure of 36 bytes (independent of architecture). The handle forces 64 bit alignment on 64 bit builds, making the structure 4 bytes bigger than on 32 bit builds. The site is checked in NtQueryInformationProcess (case ProcessDeviceMap). The expected size on x64 is the size of the Query structure without alignment. autocheck correctly passes the site of the Query union member, while smss passes the full size of PROCESS_DEVICEMAP_INFORMATION. Packing the structure is not an option, since it is defined in public headers without packing. Using the original headers sizeof(PROCESS_DEVICEMAP_INFORMATION) is 0x28, sizeof(PROCESS_DEVICEMAP_INFORMATION::Query) is 0x24.
- Rename ObDirectoryType to ObpDirectoryObjectType and remove it from NDK (this is not exported!)
- Rename ObSymbolicLinkType to ObpSymbolicLinkObjectType
- Remove duplicated ObpTypeObjectType from ob.h
fix control overlapping in IDD_FOLDER_OPTIONS_FILETYPES
(broke in 0.4.10-dev-24-ed1c6bb0060d06f4c0167d9c2d732f4dc2b4cce4)
and translate IDD_NEWEXTENSION, IDD_EDITTYPE, IDD_ACTION, IDD_FOLDER_CUSTOMIZE
Additional changes:
- Adapt the message-box dialog procedure to correctly take into account
the presence or absence of a CANCEL button and take appropriate actions.
- Cache the strings retrieved by MB_GetString() (add FIXME notices too).
- Remove usage of ButtonLen and ibtn-pointer arrays, to make the code
more generic and less dependent on the (maximal) number of buttons
in the message boxes.
- Move around the code that computes the positions and sizes of the
window controls.
Kernel stacks that re freed, can be placed on an SLIST for quick reuse. The old code was using a member of the PFN of the last stack page as the SLIST_ENTRY. This relies on the following (non-portable) assumptions:
- A stack always has a PTE associated with it.
- This PTE has a PFN associated with it.
- The PFN has an empty field that can be re-used as an SLIST_ENTRY.
- The PFN has another field that points back to the PTE, which then can be used to get the stack base.
Specifically: On x64 the PFN field is not 16 bytes aligned, so it cannot be used as an SLIST_ENTRY. (In a "usermode kernel" the other assumptions are also invalid).
The new code does what Windows does (and which seems absolutely obvious to do): Place the SLIST_ENTRY directly on the stack.
This commit adds support for the MS symbol encoding (FT_ENCODING_MS_SYMBOL) in our font engine.
It also fixes the display of the Anastasia font. And replacing our Marlett font with Windows' Marlett font is also fixed.
CORE-13269, CORE-14907
