In future, ReactOS will probably need a compatibility layer similar to NT 5.1+ shim engine.
You have probably already seen it in action when using NT 5.1+ the Compatibility shell extension in the shell32 file-property dialog or the weird "Compatibility Wizard". It offers some options like "Disable visual themes", "Run application in Windows xyz" [where xyz is a previous Win32 OS from 9x to NT 5.0), limited screen resolutions, etc. A total of 4 shim options, one with four predefined settings.
Most people don't know that NT 5.1+ comes with a shim-database of more than one hundred shims, plus some other database files that contain app-names, check sum and some other relational data to match specific applications (both MS and third party). For example Visual Studio 6 Setup wouldn't work in NT 5.1 because it checks for an outdated MS Java version, and other system files. The shim engine automatically checks the app while loading and 'fake' some of the requested information. Advanced user can also create their own shim-settings and store it in an separate shim-database (and share them with others). The related tool called Compatibility Administrator comes with the AppComp toolkit. I have successfully executed several Win9x applications that had been marked as incompatible with NT. For example, most Win9x games of the late nineties check for Win9x and refuse to execute on NT. One of them are games of the Need for Speed game series. I applied some of the shims to the game executable and player NfS 4 and NfS Porsche was not a problem at all.
Alex has already investigated how the NT shim-engine work internally, and 4 of 11 of his (up-to-date) unfinished blog-article series about it, can be found on his website.
Some information can also be found on msdn website, especially at the channel9 (videos) sub-section.
ReactOS would benefit from a similar technology as well, for example video driver from vendors like nVidia and AMD are known for various NT version specific hacks (as I have been told). And probably a just-in-time patch of the executable via the system compatibility layer would be reasonable. On the other side, NT 4 & NT5 video driver are kernel mode drivers and the shim engine of NT 5.1+ acts mainly on the user mode side. There are two options, afaik, user mode video driver like NT 6, or patch the driver while installing process.
I am not sure why 64-bit NT 5.2 (2003, XP-64) and NT 6 don't use the shim-engine to redirect 32-bit executable to the 'correct' path (file system, registry). And if those OS's use it, why it is such a mess (System32 (64bit), and SysWOW64 for 32bit; apps dirs, etc.). Afaik, all those redirection takes place in WOW64. Using the shim layer, several design flaws could be fixed without break compatibility; it's a great chance for ReactOS to learn from the early inventors and implementers and make it better from the beginning.
Microsoft Application Compatibility Toolkit 5.0 (for NT 5.1+, dotNet 1.1 required, no WGA): http://www.microsoft.com/downloads/details.aspx?FamilyID=24da89e9-b581-47b0-...
app compatibility msdn pages: http://msdn2.microsoft.com/en-us/library/Aa286552.aspx http://technet.microsoft.com/en-us/library/bb457032.aspx
Alex Ionescu's related blog entries: http://www.alex-ionescu.com/index.php?s=Application+Compatilibity+Database
Klemens