AuroraSupport/AuroraRuntime
2
1
Fork 0
Code Issues 27 Pull Requests Releases Wiki Activity

[+] Windows 7 support notice

Browse Source 
[*] Update copyright year
This commit is contained in:
Reece Wilson 2023-07-04 07:43:16 +01:00
parent 9fcee7041e
commit e2689367fb
3 changed files with 10 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
LICENSE
View File

@ -1,4 +1,4 @@
Copyright 2020-2022 J Reece Wilson
Copyright 2020-2023 J Reece Wilson
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:

7
Media/Windows 7 Defects.txt Normal file
View File

@ -0,0 +1,7 @@
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.

4
README.md
View File

@ -71,8 +71,8 @@ Discord: [Invite](https://discord.gg/XYjCGWWa4J)
| XNU/NS-like | ❌ |
Win7/8: memory management (AuProcess) is limited. \
Applications that don't need ::mmap-like functionality **with pre-reserved address allocations** should put your minimum requirements into the Vista era of NTs.
Applications that don't need ::mmap-like functionality **with pre-reserved address allocations** should put your minimum requirements into the Vista era of NTs. \
See: [Windows 7 defects](https://gitea.reece.sx/AuroraSupport/AuroraRuntime/src/branch/master/Media/Windows%207%20Defects.txt)
## Performance
Performance of each system should ideally be that of the best implementation on the platform,