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.

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) DNS look ups, when using the systems interface, will block the users thread as opposed to being an overlapped operation. Most application vendors would want to run their IO, especially network io, on a seperate thread from UI. This shouldn't be much of an issue for Windows 7 clients, I suppose.

4 - 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.