because George is having an open Draft PR since July 2022,
which might also touch this file on master in some years.
And it ofc is easier for me to revert my work now, then for him to
go through the great lengths of merging his work then.
HvpCreateHiveFreeCellList returns a NTSTATUS code yet the way the code path checks
checks for failure is just wrong. This was spotted whilst working on #4571 PR.
Whenever ReactOS finishes its operations onto the registry and unlocks it, a lazy flush is invoked to do an eventual flushing of the registry to the backing storage of the system. Except that... lazy flushing never comes into place.
This is because whenever CmpLazyFlush is called that sets up a timer which needs to expire in order to trigger the lazy flusher engine worker. However, registry locking/unlocking is a frequent occurrence, mainly when on desktop. Therefore as a matter of fact, CmpLazyFlush keeps removing and inserting the timer and the lazy flusher will never kick in that way.
Ironically the lazy flusher actually does the flushing when on USETUP installation phase because during text-mode setup installation in ReactOS the frequency of registry operations is actually less so the timer has the opportunity to expire and fire up the flusher.
In addition to that, we must queue a lazy flush when marking cells as dirty because such dirty data has to be flushed down to the media storage of the system. Of course, the real place where lazy flushing operation is done should be in a subset helper like HvMarkDirty that marks parts of a hive as dirty but since we do not have that, we'll be lazy flushing the registry during cells dirty marking instead for now.
CORE-18303
This header is included by ntoskrnl which effectively disabled all PAGED_CODE checks since 2015. Thanks Alex.
Instead define _BLDR_ when building cmlib, which will avoid trying to import KeGetCurrentIrql()
Correct fix was to fix the HCELL_INDEX <-> HKEY conversions, much like
is being done with UlongToHandle / HandleToUlong.
The on-disk/in-memory hive file structures are platform-independent:
their layout must not depend on whether code is compiled in 32 or 64
bits.
In principle there should be different get-cell routines, depending
on the type of the hive (given by the OperationType parameter of
HvInitialize): for flat hives, memory-mapped hives, etc.
For now in ReactOS we only support a restricted subset of these,
therefore we are still happy with a single get-cell callback...
This may change in the future.
Dynamically check for sys/types.h and pid_t in wine config.h
Use TARGET_xxx defines instead of _X86_ as this is undefined by GCC
Add some sense in include directories management by using interface
libraries
This fixes the crashes in HvpGetCellMapped on Windows Server 2003 when booting from Freeloader, as mentioned in maharmstone/btrfs#16.
When the bootloader loads the system hive, it cleans the data pertaining to any volatile keys. The Windows bootloader does this by setting SubKeyCounts[Volatile] to 0. After boot, the kernel marks any cell where this is 0 but SubKeyLists[Volatile] isn't HCELL_NIL as dirty, meaning that the sanitized version will then get flushed to the disk.
Because Freeloader sets SubKeyLists[Volatile] to HCELL_NIL straightaway, Windows thinks the cell is clean, and can unload it without flushing. If it then reads it from the disk, it will crash in HvpGetCellMapped due to the stale volatile pointers.
If you break on nt!CmpInitializeSystemHive on Windows and "gu" to the let the function run, you'll see that DirtyVector of the HHIVE has only the first 8 bits set. If you run it using the official bootloader, it'll have a lot more than that.
