Application compatibility layers are there for the customer, not for the program


Some time ago, a customer asked this curious question (paraphrased, as always):

Hi, we have a program that was originally designed for Windows XP and Windows Server 2003, but we found that it runs into difficulties on Windows Vista. We've found that if we set the program into Windows XP compatibility mode, then the program runs fine on Windows Vista. What changes do we need to make to our installer so that when the user runs it on Windows Vista, it automatically runs in Windows XP compatibility mode?

Don't touch that knob; the knob is there for the customer, not for the program. And it's there to clean up after your mistakes, not to let you hide behind them.

It's like saying, "I normally toss my garbage on the sidewalk in front of the pet store, and every morning, when they open up, somebody sweeps up the garbage and tosses it into the trash. But the pet store isn't open on Sundays, so on Sundays, the garbage just sits there. How can I get the pet store to open on Sundays, too?"

The correct thing to do is to figure out what your program is doing wrong and fix it. You can use the Application Compatibility Toolkit to see all of the fixes that go into the Windows XP compatibility layer, then apply them one at a time until you find the one that gets your program running again. For example, if you find that your program runs fine once you apply the VersionLie shim, then go and fix your program's operating system version checks.

But don't keep throwing garbage on the street.

Comments (39)
  1. …and the reply was: tl;dr.

  2. blah says:

    Ha. I wish Microsoft did the same for web standards, but no, they had to introduce the X-UA header to let sites remain in the dark ages.

  3. Bob says:

    "Don’t keep throwing garbage on the street"

    That would make a great PDC session title…

  4. blahyourself says:

    @blah

    X-UA compatibility header == Website admin telling IE8 that the site is not standards compliant hence IE8 should render the site with reduced standards compliance of IE7.

    In fact, its analogous to the application compatibility tab.

    Though I guess, facts are never an issue when bashing Microsoft.

  5. Bob says:

    "What changes do we need to make to our installer so that when the user runs it on Windows Vista, it automatically runs in Windows XP compatibility mode?"

    <sarcasm>

    Nothing. Microsoft will figure out what shims your program needs and apply them for you. Tell your customers to wait for a hotfix from Microsoft.

    </sarcasm>

    I’m glad Microsoft publishes the list of shimed applications in the KB articles. Now I know which apps to avoid.

  6. 640k says:

    Don’t keep throwing Vista on the street.

  7. ShellEx says:

    Does Microsoft apply appcompat shims to shell extensions? No apps are broken more than shell extensions in the XP > Vista transition.

  8. Ivo says:

    @blahyourself: I think “blah” makes a good point – the author of the content/app should not instruct the browser/OS to use the compatibility mode. They should fix their crap. The purpose of the compatibility mode is to run applications that predate the OS (and is activated by the end user). So if the app/website knows about the compatibility mode then it doesn’t predate the OS/browser, therefore should not use the mode :)

    @ShellEx: I’ve come to accept that shell extensions are going to be broken from one Windows version to the next. The coupling between a shell extension and the shell is much tighter than between an arbitrary app and the OS. So to make any progress in the shell department, MS has to sometimes break compatibility. Now if only that progress didn’t break some of my favorite shell features… :P

  9. Redmond, WA, circa 2010. Forced to deal with misbehaving apps that use undocumented methods to force invocation of application compatibility shims, the app compatibility team created a shim to simulate the application compatibility shim mechanism. Shortly thereafter, the universe ceased to exist due to the hitherto-unknown metashim paradox.

  10. f.aa says:

    Ivo: The reason shell extentions are more prone to breaking isn’t because it’s "tighter" or because Microsoft "break" compatability. It’s because the people writing them do horrific, undocumented and unsupported things.

    Or if you wish; They are throwing garbage on the street.

    If someone codes something to use a hard coded window class name, or the 6th memory location on the stack on Tuesdays after 2pm, then of course it’ll break sooner or later.

  11. f.aa says:

    Ivo: The reason shell extentions are more prone to breaking isn’t because it’s "tighter" or because Microsoft "break" compatability. It’s because the people writing them do horrific, undocumented and unsupported things.

    Or if you wish; They are throwing garbage on the street.

    If someone codes something to use a hard coded window class name, or the 6th memory location on the stack on Tuesdays after 2pm, then of course it’ll break sooner or later.

  12. John says:

    Not to go too off-topic, but I really miss the IColumnProvider interface.  Properties are fine, but there is no way to register a property handler for all file types.

  13. John Muller says:

    My ‘favorite’ class of compatibility bugs is (I don’t know if it has a proper name) native integer trucation/wraparound.

    That is, there are important numbers, like Handles if I’m recalling correctly, that are defined as 32 bits, but early versions of Windows only used 16 of them.

    So, many applications would get the number from the OS, only keep the low 16 bits, and then hand it back to the OS expecting it to refer to some resource. At that point if you are lucky, only the program fails; unlucky could be crash, data corruption, etc.

    Back in the Windows 95 days I was hit by http://support.microsoft.com/kb/263044; my new 80GB drive worked fine until I crossed the 64GB boundry… at which point random data overwrote the boot sector, partition table, root directory…

    I assume that’s why Microsoft requires signing for 64 bit device drivers. I would guess a lot of poorly converted ones would work fine, as long as they were only reading/writing the lowest 2GB of memory. But as soon as you cross that threshold, it’ll start writing to the address modulus 2^31. random crashes, corruption, etc. but only under heavy load, never in a simple scenario.

  14. dartme18 says:

    So, it says you posted at 7 am.  Did you really post it at 7am?  What were you doing awake before 7am to write and post this message?

  15. Tom says:

    @dartme18: Raymond has already explained this before in a different post, but I’m too lazy to look it up.

    Raymond has written more than a year’s worth of articles in advance and has a script post them automatically each morning at 07:00.

  16. Alexandre Grigoriev says:

    @John Muller,

    Back in XP gold days, many people hit 138GB (128GiB) boundary, and their data was thrashed… Someone didn’t think enough to artificially limit the reported size to avoid that.

    @f.aa:

    Once, Raymond wrote about a horrific thing they discovered that one column handler for a well known document viewer app was doing. That handler broke when layout of stack variables changed in Explorer.

    Oh, I soooo wish Windows had a list of shame, and would flag Known Krappy Applications and Binaries. That would force the IHVs to get their Krap together.

  17. Anonymous Coward says:

    That’s all just dandy I suppose, but what to do if the problem is inside a runtime library that you can’t fix? Yeah, you could spend hours in WinDbg tracing calls and writing patches, or even more time porting to a different framework or programming language even, or you say ‘sod it, it works fine in compatibility mode – let’s get on with it.’

    [You can go have a chat with the “What Microsoft needs to do is explicitly stop supporting broken apps” people and see if the two sides can come to some sort of understanding. -Raymond]
  18. Marquess says:

    @BCS

    That’s a problem with company culture, which, just like venture capital and technical competence, is one of the things they have to manage to stay in business. If they can’t, it’s not Microsoft’s (or anyone else’s job) to fix their mess.

    To get back on the metaphor: If it’s you wife who tells you to throw your garbage in front of the pet store, you have to take it up with your wife, not the store.

  19. Cheong says:

    I can imagine that even if the issue can technically be fixed, sometimes they can’t.

    They may have just allocated timeframe for quick fix that enables compatibility mode, so they’d run seriously behind schedule if they take time to find out all the "gitches" that cause compatibility problem in newer version of Windows.

    And management level could be ignorant enough to deny request to extend the deadline, because, afterall, the application runs without significant problem if the compatibility mode enabled. Even assigning something like 2 weeks for checking those "gitches" couldn’t be justified for the mandays involved.

    So as a smallpotato developer, what will you choose? 1) Working overtime unpaid to get the application fixed. 2) Sending such email hoping someone who knows better can tell them how to enable the switch and have their schedule be kept on time.

  20. Cheong says:

    Oh for those who doesn’t agree with my comment above, just remember that back in the day when Microsoft decide to rewrite Vista from scratch, how many people did say that’s a bad decision.

  21. jeremy says:

    Yeah, sometimes when I’m running late for work I have no choice but to throw the garbage in the street.  I mean, I’d have to walk all the way over to the dumpster, that would take valuable time!  Really, what jury could convict me for something I obviously had no other reasonable choice but to do?

  22. BCS says:

    Good advice, as long as the person asking the question *can* fix the problem (they can still build it, no PHB gets in the way, etc.)

  23. Drakkie says:

    @Ivo

    Good luck making a whole suite of web applications written especially for IE(7) standards compatible while also fixing bugs and implementing features being shouted for by customers. Guess which takes precedence?

  24. Grumpy says:

    @Cheong: 3) Write a mail to $BOSS explaining what the consequences of not fixing this will be. CC someone who actually has to go and show the resulting app to a customer and someone who has to take support calls. Then let things develop as they will.

    Of course, this only works if $BOSS is rational and the someones have enough clout to influence scheduling, but either way it’s SEP.

  25. Neil says:

    [The link detector mangled John Muller’s KB link by including the trailing semicolon.]

  26. Larry says:

    You rightly chastise 3rd party developers to clean things up but oh the irony that this should come from a Microsoft employee! The tragic garbage that MS feeds developers has plagued the software development community for years. I hope there is a special place in hell for the guys that came up with UAC, SxS, the registry etc. That and Microsoft’s cross platform non-story and non-guiding guidance.

    What I wouldn’t do even for a solid installation life cycle management tool under Windows!

    Imagine actually being able to install IIS twice. Or install two versions of Word. Or have an uninstall actually uninstalls. Or have all my apps auto update without each one having to write their own updater.

    How about supporting VS 2002/2003 on Win7?

  27. dave says:

    I hope there is a special place in hell for the guys that came up with UAC, SxS, the registry etc.

    Aren’t those the poor guys who have to clean up someone else’s crap?

    UAC – clean up because application developers are too stupid to grasp the concepts (1) "multiuser environment", (2) "do not run as root".

    SxS – clean up because application developers are too stupid to grasp the concepts (1) do not update version N with version N-1, (2) keep compatible.

    Registry – clean up because application developers can’t manage to update a text file (system.ini/win.ini) without borking it.

    I wish all those things didn’t exist too: I like ‘simple’.  The alternative, of a large man taking a baseball bat to the kneecaps of infringing application developers, should have been more thoroughly examined.

  28. Alexandre Grigoriev says:

    Larry, Dave,

    I wish the applications were isolated and "compartmentalized". An application would not be able to load third party DLLs from another compartment. An application would not be able to install anything to Windows. Any application would not be able to write registry around, other than into its dedicated key. And an application would only be able to read/write files that an user explicitly specifies. This would help greatly with security, too.

  29. David Walker says:

    Registry:  The problem isn’t that people aren’t smart enough to write code that will update a text file without borking it.

    The problem is that people CANNOT POSSIBLY write code to be used in a multithreaded system that can rewrite parts of the middle of a plain text file without the file getting mangled when another application is also trying to rewrite part of a different section of the text file at the same time.  Text files are NOT databases and are NOT designed to be multi-write by different applications.

    THAT is the problem with INI files.  And, as people have said before, if you want to scrap the Registry, then please come up with something to replace it.  Call it what you want, but it needs to be a multi-write datafile of some sort.  A fairly simple hierarchical format is not a bad first choice for such a thing, although a relational database could be used also.

    I never have any trouble with the Registry on the six computers that I use.

  30. Larry says:

    Take for example the registry key for the system path setting. I have a lot of issues with this how setting works distinct from the way the registry works but let’s put that aside for the moment.

    What stops an installer from corrupting the path? Nothing. Not a damn thing.

    Now, consider for a moment if installers had no code of their own and were simply manifest driven packages for a system provided install infrastructure. That system service could ensure that the setting was written correctly and safely. It could, in theory, arbitrate between different applications’ needs to edit that setting. Hell, it might be able to rebuild most of the system settings even if it did go south.

    This sort of thing has happened before. We used to use databases of files shared over the network. Now we use database servers. In the device driver space, drivers were build by vendors nearly from scratch. The newer model provides considerably more infrastructure automatically (plug and play and power states come to mind as near impossible to get right otherwise).

    To make an analogy with a trendy topic, the registry is shared mutable state.

    [“Consider for a moment if installers had no code of their own and were simply manifest driven packages for a system provided install infrastructure.” Oh, you mean Windows Installer? -Raymond]
  31. Larry says:

    Windows Installer? What stops installers that don’t use it from messing up applications that do? You need to think like a security guy here. Installers may not actually be hostile apps but they ACT like they’re hostile apps.

    (Sorry this topic is a pet peeve and it’s getting the better of me.)

    [I was responding to the comment “Microsoft should have a system where…” by pointing out that such a system already exists. Naturally programs with admin privs can screw up your system. -Raymond]
  32. Alexandre Grigoriev says:

    "What stops an installer from corrupting the path? Nothing. Not a damn thing."

    Here is an advice for ISVs: NEVER EVER modify PATH. Never. You don’t need it. Users don’t need it. You may modify it locally, in a command script, but NEVER MODIFY GLOBAL PATH.

  33. Crescens2k says:

    @Alexandre Grigoriev

    The issue with this is the home users. You install a program and it fails (because of a compartment setting problem). Can you imagine an averate user being able to fix this problem? Whats more this opens up a seperate class of attack. Can you imagine the chaos that this kind of compartmentisation could cause if a virus snuck in and set Explorer to never load kernel32.dll? Or maybe blocked processes accessing their registry keys or files? Whats more, do you think the average user would want to worry about which files get loaded in? No, they just want to use the computer for work or recreation.

    If people used the standard Windows security then it would be able to emulate most, if not all of this. But security seems to be an area that people don’t want to think about. Which is why we have people who run with full admin rights and programmers assuming full access to Windows/Program Files/HKLM and other sensitive locations on the computer.

  34. Dale says:

    It’s the price of keeping up with operating system versions.

    Which is to say, if you’re still marketing an application, it’s not that difficult to fix your application/installer once per operating system release.

    And in an ideal world, with each new release of OS, you could force the user to buy new versions of software.  Application vendors, and possibly the OS vendor would love this.  Customers would not.

  35. Larry says:

    @Crescens2k: With respect to standard security, ACLs have their limits. They aren’t app aware. If an app is compromised, it can mangle the system up to the limits of the current user. On the other hand if an app has declared it can only edit a certain file type and a limited set of registry keys, the damage might be contained or even averted entirely. Yes a virus could make use of this infrastructure – if it compromised an app that had declared its intent to modify such settings. Which would be an adminstrator mode app and if that’s compromised without app limits it’s near a total loss anyway.

    #Raymond: I guess I didn’t explain that well. My thinking leads me towards a view where a logical registry is synthesized from the manifests of the registered applications. Windows Installer doesn’t do that.

    @Alexandre Grigoriev: PATH has many issues and your recommendation is a good one. Though "never" might be too strong given the current lack of alternatives for some uses.

  36. Cheong says:

    @Grumpy: Consider recent entry from Michael Kaplan (See Raymond’s link of blogrolls) about Windows Installer does not gain full Unicode support as of Windows 7, even Microsoft have to address priority on thing that might seem trival like this. (At least they ought to have a thought on how to add Unicode support if needed. Afterall, UTF-8 had been unofficically supported. Buf to fix Windows compatibility problems, it can take weeks or even months to fix on the tricky parts)

    As long as there are workarounds (at the worse case, they may just have to include instruction on the installation guide to enable

    AppComp options), they will not allocate time to address it. It’s all about controlling development cost and will affect the PM’s performance review.

    Except that Microsoft officially announce a deadline to remove related AppComp support, so the application will break horriably in the selling period, I don’t think most $BOSS will entertain the request to allocate resources to fix it.

    [captcha: 443. How secure it is.]

  37. Matthew Wills says:

    @blah

    > Ha. I wish Microsoft did the same for web standards, but no, they had to introduce the X-UA header to let sites remain in the dark ages.

    Rightly or wrongly – you likely should be using the X-UA header. Otherwise, your site likely will switch to IE7 mode if your IE8 users add your site to their intranet zone.

  38. Legolas says:

    Isn’t it strange though that MS has all this code there to make an app work without much changes on the app makers side, but is telling them, no, don’t use that, rewrite your app to support whatever we changed?

  39. GregM says:

    "Isn’t it strange though that MS has all this code there to make an app work without much changes on the app makers side, but is telling them, no, don’t use that, rewrite your app to support whatever we changed?"

    No, it’s not.  The code that is there makes the system behave differently for that one app than for other apps that don’t use that compatibility setting.

Comments are closed.

Skip to main content