The Dirty Little World of AppCompat
Jun. 23rd, 2006 05:41 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
walbournFor 25 years, people have used the Windows OS and one of the main reasons it has gotten such lasting use is that each generation runs the important applications of the previous one or two generations if not more. This despite the fact that 99% of the software written for the Windows OS makes at least one horribly bad assumption about the system behavior. Usually far more than that.
Achieving that compatibility has not been easy or cheap. Application developers, as it turns out, are completely unsympathetic to the fact that their broken software is making it hard to improve the platform. Besides, Microsoft has always done the work so why should they bother?
The way we do it is by having this magic little thing called a "shim", a tiny hack in the operating system that we turn on based on testing the applications to make them work. There are thousands of entries in the shim database. Some of them do stuff like lie to the silly setup program that fails if the OS version is "6.0" instead of "4.0" saying "Hey, this is NT 3.51 and we don't support it!" Some of it emulates the behavior of previous releases of Windows because the application does buggy stuff like release memory and then proceed to use it for the next hundred cycles or so because Windows 95 didn't notice. Sometimes we have to lie about a particular DLL being present on the system that they never use, but crash if it isn't present or endlessly try to install some component that no longer applies.
Each of these solutions is crafted by hand, applied with a debugging skill more akin to alchemy than science, and is one monstrous pain in the ass.
The really sad part is this doesn't just apply to old software. Major games released in the past few years by developers who should know better are rife with this kind of crap.
It is made even more difficult by three major factors:
(a) sticking to legacy APIs years after Microsoft tells you to stop. No really, Direct3D Retained Mode was dead on arrival in 1996, much less by the time Direct3D 7 came out in 1999. That was 7 years ago. Cut it out. Really.
(b) the proliferation of the hackery that is 'copy-protection' schemes. These things don't actually stop hardcore pirates and are typically hacked within days by 14 year olds in China, but make using standard debugging techniques impossible. That means in 2-3 years when we try to get your application running on the next version of Windows, we have to resort to black magic and sacrificing a goat to even figure out why the application is crashing much less fix it. As our AppCompat guru said, if you guys are going to use this crap, then you should be patching your game every OS release.
(c) despite having a version info resource record system in place for binaries since 1995, too few applications actually use them. That means our appcompat database has to resort to all kinds of scary things to try to determine if "Game.EXE" is the exact thing we need to fix-up or not--which, btw, is primarily what Windows is doing when you run "Setup.EXE" and it seems to just sit there a few seconds.
If you learn nothing else from this post, application developers, learn this: for the love of god, try not to make future appcompat gnomes lives hell and use accurate version information! For the rest of you, next time you run your favorite game from the 90s and it actually runs on a computer made 15 years later, quietly thank the poor bastard who had to figure out how to make it work without a clue from the people who wrote it and made all the money ever made off it. Hell, thank the poor bastard that got the game from last year to run on the new OS given the team that wrote it was likely laid off the day it shipped.
Achieving that compatibility has not been easy or cheap. Application developers, as it turns out, are completely unsympathetic to the fact that their broken software is making it hard to improve the platform. Besides, Microsoft has always done the work so why should they bother?
The way we do it is by having this magic little thing called a "shim", a tiny hack in the operating system that we turn on based on testing the applications to make them work. There are thousands of entries in the shim database. Some of them do stuff like lie to the silly setup program that fails if the OS version is "6.0" instead of "4.0" saying "Hey, this is NT 3.51 and we don't support it!" Some of it emulates the behavior of previous releases of Windows because the application does buggy stuff like release memory and then proceed to use it for the next hundred cycles or so because Windows 95 didn't notice. Sometimes we have to lie about a particular DLL being present on the system that they never use, but crash if it isn't present or endlessly try to install some component that no longer applies.
Each of these solutions is crafted by hand, applied with a debugging skill more akin to alchemy than science, and is one monstrous pain in the ass.
The really sad part is this doesn't just apply to old software. Major games released in the past few years by developers who should know better are rife with this kind of crap.
It is made even more difficult by three major factors:
(a) sticking to legacy APIs years after Microsoft tells you to stop. No really, Direct3D Retained Mode was dead on arrival in 1996, much less by the time Direct3D 7 came out in 1999. That was 7 years ago. Cut it out. Really.
(b) the proliferation of the hackery that is 'copy-protection' schemes. These things don't actually stop hardcore pirates and are typically hacked within days by 14 year olds in China, but make using standard debugging techniques impossible. That means in 2-3 years when we try to get your application running on the next version of Windows, we have to resort to black magic and sacrificing a goat to even figure out why the application is crashing much less fix it. As our AppCompat guru said, if you guys are going to use this crap, then you should be patching your game every OS release.
(c) despite having a version info resource record system in place for binaries since 1995, too few applications actually use them. That means our appcompat database has to resort to all kinds of scary things to try to determine if "Game.EXE" is the exact thing we need to fix-up or not--which, btw, is primarily what Windows is doing when you run "Setup.EXE" and it seems to just sit there a few seconds.
If you learn nothing else from this post, application developers, learn this: for the love of god, try not to make future appcompat gnomes lives hell and use accurate version information! For the rest of you, next time you run your favorite game from the 90s and it actually runs on a computer made 15 years later, quietly thank the poor bastard who had to figure out how to make it work without a clue from the people who wrote it and made all the money ever made off it. Hell, thank the poor bastard that got the game from last year to run on the new OS given the team that wrote it was likely laid off the day it shipped.
