A little while back, those of us who explain application compatibility for a living and try to help people get their arms around it ran up against those who implement it in the product on the scale of … the whole earth.
Those of us who explain things for a living really prefer (really, really prefer) when the system is internally consistent, because that makes it easier to explain.
Those who build systems really work to make the investments they can, with finite resources, to fix the greatest percentage of applications they can.
And sometimes those goals are not in alignment.
Case in point: remember back in April when i was talking about how we added the new AdditiveRunAsHighest shim to our operating system layers? Well, it turns out that we didn’t touch quite all of them. The following layers have AdditiveRunAsHighest applied:
The following layers do not have it applied:
What’s the rhyme or reason here? Well, you can start to tease out some logical ones. First, most people don’t use compatibility modes on server apps. (They may use them on a server, such as when you use terminal services apps, but if you have a high-throughput server application, shimming it up and running it unsupported is probably not high on your list of acceptable mitigations. So, remove Server 2003 and Server 2008. Next, if it worked on Windows Vista, it has already seen UAC, so we don’t really need to have it there. But … what about NT4 and Windows 2000? If those were included, couldn’t we just say, “ever client operating system prior to Windows Vista includes this shim”?
Yes, we could.
And wouldn’t the same arguments that made sense for the other ones make sense here?
Yes, they would.
So, what gives?
Well, in the game of probability (fix the most apps), internal consistency was not the focus. Fixing the largest number of apps was. And there simply were not enough apps that needed the Windows NT 4 and Windows 2000 modes to bring it on the radar that they needed them too. And those of us who do explain these things for a living didn’t notice it until July, when the bug bar was way too high to get this fix in (since it doesn’t actually block you from getting things done, it just makes it harder to explain why the system behaves the way it does).
So, instead of a nice, logical rule, you have a list to memorize. 95, 98, and XP get AdditiveRunAsHighest. Everything else does not. Sorry for making you memorize a list – I’d much rather you were memorizing rules that you could logically explain, but so it goes.