Roadmap for the kernel.

I propose my version of the ReactOS development roadmap (for the kernel).
This is a draft.

Abbreviations:

MM - memory manager
CC - system cache manager
PNP - plug and play manager
PO - power manager

HAL - Hardware Abstraction Layer
ACPI - Advanced Configuration and Power Interface
PIC - Programmable Interrupt Controller
APIC - Advanced Programmable Interrupt Controller
UP - Uniprocessor
MP - Multiprocessor

Development Order:

Why such an order? It seems more logical to start with HAL. For the full development of the NTFS driver (the main file system for NT-compatible systems), the CC functionality is required, which in turn uses the functionality of the MM. Therefore, it will be the green light for NTFS development.

1 - MM and CC managers:
Joint development is advisable, since CC is highly dependent on MM. Btw: https://reactos.org/blogs/memory-manager-development/
since it is necessary to make significant changes, and the section structures are incompatible, development should be done in the parallel directories "ntoskrnl\mm_new\" and "ntoskrnl\cache_new\" (an additional key for Cmake is "MM_CC_NEW"). This will not break the current kernel and will be safer.

1.1.1 - the main task at this stage is to get rid of _MEMORY_AREA, using the _SECTION and _SEGMENT structures instead of PROS_SECTION_OBJECT and _MM_SECTION_SEGMENT. Accordingly, the code to support the operation of the sections will need to be changed and the missing functionality added.
1.1.2 - adding initialization of the system cache and missing functions for it.
1.1.3 - correction of MmAccessFault() and all related functions
1.1.4 - testing, debugging, code formatting
1.2.1 - the CC manager, apparently, should be actually updated, so it uses other structures (both - "cc" and "cache"). So far I have no final decision at this point. Analysis of this part is not yet complete.
1.2.2 - testing, debugging, code formatting
1.3.1 - at this stage paging should be implemented. This step can be implemented later.
1.3.2 - testing, debugging, code formatting

2 - HAL

development should be carried out in separate directories "hal\halxxx\". This will allow to concentrate efforts only on functionality and not be distracted by combining different versions (development acceleration). It is also safer and will not break other HALs.
RU http://vgal.ru.com/pic-ili-apic/
RU-> EN https://translate.google.com/translate?hl=en&tab=TT&sl=en&tl=en&u=http%3A%2F%2Fvgal.ru.com%2Fpic-ili-apic%2F

2.1.1 - ACPI APIC UP HAL (halaacpi.dll)
change and add the missing functionality for the processor and APIC controller.
2.1.2 - testing, debugging, code formatting
2.1.3 - after development is completed, using "halaacpi" in "LiveCD" instead "hal"

it can be developed after beta (or?):
2.3.1 - ACPI APIC MP HAL (halmacpi.dll) (need support MP)
2.2.1 - ACPI PIC HAL (halacpi.dll)
2.4.1 - Non-ACPI PIC HAL (hal.dll)
2.5.1 - Non-ACPI APIC UP HAL (halapic.dll)
2.6.1 - Non-ACPI APIC MP HAL (halmps.dll)
2.7 - after the development is completed, merge all HALs into one (if necessary).

3 - PNP manager:

Since it is necessary to make significant changes, development should be done in the parallel directory "ntoskrnl\pnp_new\" (an additional key for Cmake is "PNP_NEW"). This will not break the current kernel and will be safer.

3.1 - add the arbiter library;
3.2 - adjust and supplement the RTL library "rangelist.c" (there is no support for intersecting ranges);
3.3 - add/replace Windows-compatible Device Node Status Flags https://docs.microsoft.com/en-us/windows-hardware/drivers/debugger/device-node-status-flags
3.4 - redo the initialization subsystem
3.5 - redo the device enumeration subsystem
3.6 - redo the device removal subsystem
3.7 - redo the subsystem of working with hardware resources
3.8 - analyze and possibly change the subsystem of the interface with the User-mode PnP subsystem
3.9 - testing, debugging, code formatting

4 - PO manager;

it can be called either a white sheet or a black hole
the current functionality is extremely minimal, since it is not necessary for virtual machines, UNIMPLEMENTEDs are much more than IMPLEMENTED ...
need analysis and adding the necessary functionality, as well as adjusting the OS shutdown procedure.

5 - Drivers;

There are also problems with drivers:
Test drivers compatibility between OS:
Test NT drivers in ReactOS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview#
Test ROS drivers in NT OS - https://docs.google.com/spreadsheets/d/1xvsjmEFZ9euM5uSlIDB3s1S_2xmgI7HtnHN22yZFfUw/htmlview#
Thanks to Andrey Shatalov for the table and everyone who filled it (column "Tested by")

5.1 - the arbiter library is required for the pcix driver, this driver should become the main instead of the current pci
5.2 - for the driver "acpi" it is necessary to achieve compatibility with NT, in particular, from DriverEntry (), make a call to HalInitPowerManagement () to create an interface with HAL.

How Basic Disks and Volumes Work - https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc739412(v=ws.10)
5.3 - add "drivers\storage\ftdisk.sys"
5.4 - add "drivers\storage\partmgr.sys"

5.5 - add missing functionality to NTFS, as well as the ability to boot the OS from NTFS partitions.
...
CONTINUE ME

This is all for one purpose: making ReactOS not only an “OS for Virtual Box”.