The reserve IRP is an IRP which is allocated on system boot and kept during
the whole system life. Its purpose is to allow page reads in case of
low-memory situations where the system doesn't have enough memory left
to allocate an IRP to read from the page file (would be catastrophic situation).
services\database.c:
- Refactor ScmControlService() so that it can be used to send the dispatcher loop stop command.
- Separate the code to decrement the image run counter from the service image cleanup code.
services\rpcserver.c:
- RSetServiceStatus(): Stop the dispatcher loop when the image run counter is zero and remove the service image after that.
advapi32\service\sctrl.c:
- Do not terminate the service dispatcher loop when the last service is being stopped. Wait for an explicit dispatcher stop command (empty service name).
CORE-12413
(So the fun begins)
In spite of what VFATLIB headers pretend, there's not magic in FAT boot sector.
The 3 first bytes are just the jump instruction (to the boot code). No jump, no boot.
Also, some (many?) FAT implementations rely on the jump code to help detecting that
a FAT volume is really a FAT volume. Like MS FastFAT. Or our own FAT recognizer in FS_REC.
The story is that, up to that commit, we zeroed the 3 first bytes; leading to broken
FAT volumes.
This got hidden in most cases by the fact that during setup, when we install boot
loader, we erase parts of the boot sector, including the jump instruction, making the
volume valid again. But that wouldn't fix secondary volumes where the boot loader isn't
installed.
And, also, imagine a scenario where you want to install ReactOS on a newly formatted volume
with MS FastFAT instead of our own implementation... That would simply not work to
the fact that the driver wouldn't recognize the fresh formatted volume!
(So the non fashion begins)
Fix this by putting a not that valid jump into the boot sector when formatting our
partitions. That way, our volume is always regarding a FAT view point. But, instead of
putting values that mean (nearly) nothing. We should also put a dummy bootloader
displaying the user and error message, as done by dosfstools.
(So the hope begins)
This opens the way for trying to install ReactOS with MS FastFAT (doesn't work yet).
CORE-11819
CORE-14362
The two methods were completely broken because they passed a full pidl to the parent folder (and not desktop folder).
Compile SHGetNameFromIDList to use it in CShellItem but don't export it.
on 32bit builds CSIDL_PROGRAM_FILESX86 is treated as CSIDL_PROGRAM_FILES and on wow64 builds CSIDL_PROGRAM_FILES gets treated as CSIDL_PROGRAM_FILESX86
