When we're about to close a file (ie, forget everything about it
and release any associated structure), actually delay it.
This allows keep data fresh in memory for faster reuse in case
it would be required. The effective closing will only happen after some time.
For specific operations, this will produce a real speed up in ReactOS.
For instance, with that patch, Winamp starts within seconds, instead of dozen
of minutes.
In most cases, it will bring ReactOS to performances it had before fixing
the huge leak in FastFAT (commit 94ead99) without leaking the whole FS.
For now, due to regressions, this is only activated for files and not
for directories. Once it gets fixed, it will be enabled for both.
CORE-14826
CORE-14917
This happened for the livecd, where the cdfs driver was inserted twice - once since it is the driver for the boot device, and the 2nd time, because it was specified in the registry - which was then initialized twice by the kernel, leading to a name conflict when trying to create another device object, which resulted in the newly created device object to be dereferenced again and the driver unloaded. This can be seen from the debug message "(ntoskrnl\mm\ARM3\sysldr.c:955) Leaking driver: cdfs.sys"
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
