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