1) Without a kernel driver, it is impossible for AuProcess to preallocate address space. Memory maps cannot be placed deterministically on stock Windows 7. Although, if existing Windows patching features are used to introduce a VirtualAlloc2 dynamically, it is possible for support to be added unoffically; Aurora Runtime will just assume it's a valid Win10 RSx+ install. Ok, techincally I'm lying, it is possible to do on an unpatched kernel, but by god would it be annoying and be liable to data loss. You'd basically have to emulate POSIX-s mmap exactly like how DOS extenders do it: with exception handlers, a thread to handle write back cache flushing, Kernel32!MapUserPhysicalPagesScatter, and group policy adjustments. You're better off writing a driver if you need fine grained mapping (also the same for Win10).
2 - soft defect; emuation performance) The time to wake metric across AuThreading::[Wake/Wait]OnAddress starts off at 1.5 - 2.2x modern Windows with RtlWaitOnAddress; although, the best case of basic primitives will still be faster than SRW Locks of Windows 7 through 11. Era correct internal NT apis are used across XP - Windows 11 targets. Note, WaitOnAddress emulation is not required for basic thread primitives; such scheduler indirection would only hurt performance. Performance should otherwise be exactly what you would expect once you remove Microsofts regressing CRT and lackluster stock thread primitives from the equation.
3 - soft defect; workaround available) Stock Windows 7 console host is infamously bad. ConsoleTTY can in theory continue to work down to targets as old as Windows XP without the use of third party software; however, it should be noted TrueType fonts tend to cause hideous positioning faults when used with Aurora::Console::ConsoleTTY::GetTTYConsole()->Start(). Raster fonts tend to have better compatibility on older Windows operating systems. Aurora::Console::ConsoleTTY::* and Aurora::Console::ConsoleSTD::* (noncanonical apis) remain available and fully functional under Windows 7.
