There’s the interface contract, and there are the implementations of the interface contract


Ivo wants to know whether it is legal to use NULL as the icon parameters to IExtractIcon::Extract. The documentation says that the parameters are optional, but some shell folder implementations treat them as mandatory.

Yes, the parameters are technically optional, but it's also the case that many people mess up their implementation of the interface and treat them as mandatory, either by crashing on a null pointer or by returning E_INVALIDARG. Since IExtractIcon is an extension interface, you are pretty much at the mercy of all the implementations of that extension.

Welcome to the land of application compatibility, where you have to incorporate workarounds for other people's bugs. In this case, it means always passing non-null pointers for the output icons if you want to get anything meaningful back, even if that means asking for more than you really need and then throwing part of it away.

Ivo's second question was whether there is a performance benefit of asking just for the icon you want, or whether it's almost as fast to get both.

If you ask for just one of the icons, then the icon extractor doesn't need to go extract it, which saves you a small amount of disk access (or a large amount if you're asking for the monster 256×256 icon). But given that compatibility forces you to ask for both anyway, the answer doesn't help you any. Given that there are drivers who run red lights, you could say that, in theory, "It is more efficient to cross the street as soon as the light turns green," but in practice, you'd be better served to look for traffic before stepping out into the roadway.

You'd be right, but you'd be dead right.

Comments (28)
  1. John says:

    Ok, but there's got to be some limit on how far you are willing to go to fix other people's bugs.  Then again, I remember reading the blog entry about manually pushing a hundred bytes on the stack so people can continue to abuse rundll32.  So I guess there is no limit.  Your life must suck.

  2. Mike Caron says:

    In real life, you can sue people for violating contracts.

    Sigh.

  3. Compatibility price says:

    Microsofts first mistake of many: "Bending over and taking it."

    X years later we see how desperate microsoft were to keep their few customers happy.

    Oh and surprise, guess who's paying the performance penalties and the api mess confusion for all these "compatibility-fixes".

    What they should have done is to say to the customer using a buggy software to report the bug to the developers of switch to a more stable software.

    Doesn't you find it odd that when ever microsoft does something stupid that goes against common sense its not microsoft that pays the price in the end but its users.

    I for one would love to be able to permanently turn of ALL compatibility fixes and workarounds.

    1. That way i would avoid depending on undocumented compatibility "fixes" when i write programs.

    2. It would reveal all the software that does stupid things, i love to publicly file bug reports. My shame-list is long already. Best way to make developers get off their ass and fix the bugs. Works like a charm for security bugs ;D that they would otherwise try to hide.

    3. The performance gain, woho !

    [If you don't want to accommodate compatibility in your code, then go ahead and pass NULL. See how many customers you get. If you want to see the shame list, just look at the Application Compatibility Database. And as we saw some time ago, in most cases, the performance gain is minuscule. -Raymond]
  4. Gabe says:

    "Compatibility price"'s definition of the word 'few' is one that I'm not familiar with.

  5. There's something to be said for a "developer mode" switch that enforces strict behavior.  Running on a chk build with Application Verifier turned on, Driver Verifier turned on, and a kernel debugger attached gets you a good portion of the way there.

    [The great thing about making a strict version of the operating system is that nobody will run it. -Raymond]
  6. alegr1 says:

    "Running on a chk build with Application Verifier turned on, Driver Verifier turned on, and a kernel debugger attached gets you a good portion of the way there."

    I don't know about you, but in the Win7 checked build, I can't even play Mahjong Titans (or was it Freecell?). Without App Verifier.

  7. Joshua says:

    I don't know about you, but in the Win7 checked build, I can't even play Mahjong Titans (or was it Freecell?). Without App Verifier.

    That sucks.

  8. The idea of a "strict mode" is not so that you can play FreeCell on it, but rather so that you can verify your application isn't mistakenly relying on a Windows safety net.

    That said, there are the occasional kooks out there who like to selfhost some variation of "strict mode" (like me, and apparently like alegr1.)  I find lots of bugs this way.

  9. Alex Cohn says:

    Can't you pass the same pointer twice, giving same sizes for small and big icons? Or this will also bump into some incompatible extensions?

    [How do you destroy the first icon if its handle got overwritten by the second one? -Raymond]
  10. Ben Voigt says:

    Several parts of the .NET framework also cause Windows checked build to complain loudly.  No one on the .NET team seemed to care, however.

    connect.microsoft.com/…/system-windows-forms-control-wmpaint-always-calls-beginpaint

    It's very difficult to impress on third-party developers that they should test their applications using the checked build when Microsoft won't do the same for their developer runtimes (which creates false positives for the third-party developer to wade through).

  11. Nobody wants to run Windows checked builds because few of the people who know they even exist can justify setting up and doing additional testing using a dedicated (virtual) machine, where most likely nothing actually works anyway, even before you throw in third-party components.

    Don't confuse people ignoring a flawed solution with a lack of desire for a good solution. :) It's an example of the politician's logic that you quoted a while ago. ("Something was needed. Checked builds are something. Therefore checked builds must be what was needed.")

  12. Christian says:

    So I guess there is no limit.  Your life must suck.

    I don't understand these kind of comments. Thinkering and working around bugs is always a part of engineering. It's sad if you don't like your job.

    And whenever you want to run an application or help your relatives fix their computer, you should be really grateful for everyone who makes programs work instead of being an idealistic PITA

  13. chentiangemalc says:

    I love these people who live in some idealistic fantasy world and always begging to have all this stuff switched off, they have no idea what it breaks. Working with appcompat issues daily I'm continually thankful for Raymond's efforts in these areas.

    The WinRT (Metro) app model in Windows 8 does potentially move away from the need for this app compat patching though…

  14. Ben Voigt says:

    It seems to me that there's a straightforward solution to developers not using checked builds to catch errors — make public prerelease versions (Technology Preview, Beta) of Windows only available as checked build.  You want to be a "launch partner" and have the logo for Windows 9 compatible on launch day?  Make your app work on the checked build.  Development houses that can't be bothered can still develop for Windows.next and get the logo, they'll just have to wait for RTM.

    @Leo: Anyone who cares about testing already has virtual machines with different Service Packs, different versions of .NET installed, etc.  Having one running the latest checked build really shouldn't be a great additional burden.  If the checked build comes bundled with apps that fail the checks, then Microsoft really needs to clean those up.  Nothing says "Our security culture is a sham" quite like positive reports from your own automated analysis tools.

    Maybe that's the solution — report Microsoft products triggering checked build warnings as potential security flaws.  Get the SDL folks investigating each invalid parameter to see if it creates a vulnerability.

  15. Anonymous Coward says:

    Regarding the crash in Extract, MSDN has this to say: Beginning with the .NET Framework version 4, the Assembly Cache Viewer (Shfusion.dll) [the implementation that crashed when passing NULL] is obsolete and has been removed.

    As for the non-crashing case, I wouldn't bother with working around the bug. If someone doesn't implement the contract correctly then simply don't show the icon. But if you hide bugs they will never get fixed.

    And if you want to properly guard against crashing extensions, you have to extract your icons in a helper process anyway. If the crash report dialogues get too painful, you can use SEH to terminate the process nicely on the second and subsequent crash. But always let the helper crash at least once, otherwise no one will know that something went wrong and hence no one can fix it. At least when you crash Microsoft can notify the developer or create a shim.

    If the problem doesn't get fixed within a reasonable time frame and customers complain, I would probably unregister the crashing extension or even shim, but I'm not going to change my Extract call if it follows the contract. The only way to detect bugs is to break when they occur; it may be more painful in the short term but if you don't follow this principle bugs can linger for decades, inconveniencing many more people.

  16. John says:

    @Christian:  Obviously there is value in providing application compatibility, but it's all work that could have been avoided if people didn't write bad code in the first place.  However, there is no incentive for people to write better code since application compatibility is maintained so vigorously.  People (including myself) are stupid and lazy and will do whatever they can get away with.  If you want them to write better code then you have to give them no other option.

  17. Tud says:

    [The great thing about making a strict version of the operating system is that nobody will run it. -Raymond]

    What is the main drawback to making EVERY copy of the OS run "strict"? If it's speed, you could enable it randomly in, say, 1 out of 100 times.

    It would break backwards compatibility completely of course, so it would have to be enabled for "new versions" only (the introduction of Metro apps, for example, is a wonderful opportunity to break compatibilities).

    ["Randomly, about once every three months, Windows runs horribly slow and apps start behaving erratically. Windows is a piece of junk." -Raymond]
  18. cheong00 says:

    If there aren't business related consequence, sometimes I do wish Microsoft publish News Flash on new entries of Application Compatability Database, much in the same style as Hall of Shame.

    People who litters around deserve to be punished in some way… In an afterthought, maybe it'd be embrassing if some of Microsoft's product would be on the list a lot.

  19. James says:

    If you don't want to accommodate compatibility in your code, then go ahead and pass NULL. See how many customers you get.

    Raymond, as a developer, why do you care about how many customers you get?

    That is the job of the sales team.

    If the sales teams determines that such issues are hurting their sales figures, then discussion about addressing it may be worthwhile. That may include educating other people or it may end up just working around their mistakes.

    But instead of ever letting such a discussion proceed, you seem fully willing to work around it, even when you are not in the wrong.

    Why? Or you a developer or are you sales?

  20. Anonymous Coward says:

    James, in this case the point may be moot since the crashing extension is deprecated and the worst you'll get is a missing icon. Nothing you'll lose customers over.

    However, I've been in a situation myself where our software had to talk to Office (that was for the administrators). We were calling the object model correctly, but unpredictably the Office application would crash and sometimes even corrupt files. Since it was pretty much a given that even if Microsoft could be persuaded to do something, the fix would arrive much too late for us, we had to work around it.

  21. JM says:

    @James: Microsoft is in the business of selling an operating system that can run my programs. If the next version of their OS doesn't run my programs, I won't use it, until such time as there's an indispensable program that requires me to upgrade the OS. Lower adoption rates would in turn compel fewer developers to write such software. If Microsoft adhered to the position that application developers should write things so they don't break with the next version of Windows, they would be dependent on those developers for when they could ship the next version. Try explaining that to sales and see if they agree that shipping isn't that important as long as you're "in the right". I'm sure MS already does its darndest to educate people and put pressure on them when they can, but that only goes so far. In the end, you want to ship, even if Contoso is not fixing their payroll app because they don't see the value in Windows 2042 (but their customers do, for other applications).

    If you're not Microsoft, things look differently. You may not even have any third parties you're dependent on. Contoso Payroll may not be installed on any of your customer's machines, so you don't have to interoperate with it. Your customer may accept "sorry, that won't work because Contoso wrote their software wrong, please contact them". You may be able to tell sales "it's your job to sell whatever we're making, not our job to make sure you can sell it". The truth will probably be somewhere in the middle, since few people would want to be out of a job over a discussion on technical excellence. You seem to assume that discussions like this are never held within MS and development is martyring themselves to fix things when they don't have to — something tells me that's not right.

  22. DWalker says:

    I was about to say what JM just said, in response to Tud and others.  Raymond has explained this at length before:  

    If a user upgrades to a new version of Windows, and some of their critical applications stop working (since the new OS now enforces a contract more strictly), the users are going to say "The new version of Windows sucks!  Don't buy it!"

  23. Joshua says:

    @JM: "sorry, that won't work because Contoso wrote their software wrong, please contact them" is the essence of a line we often have to tell our customers, where Contoso is some form of antivirus software.

    We don't like antivirus software all that much anymore due to the high support cost, which is in turn due to the terrible performance and odd issues because they do some of the most incredible undocumented hacks.

  24. Ken White says:

    @James: "Raymond, as a developer, why do you care about how many customers you get?"

    What do you think pays the developer's salary? Yep, that's right – sales of the software they're developing. Do you even work in the software industry (retail or corporate software)? Or are you just a developer that works on software used in-house at your company? I'm suspecting the latter (actually, I'm expecting you to be a developer in a small ISP that has no experience with selling to the general consumer market or corporations). Sales keep the company in business, and pay the salaries of not only the sales staff, but the programmers, admin staff, tech support staff, and even the janitorial services people.

  25. Rasmus says:

    Oh dear the mess…

    So to summarize:

    Compatibility shims exists because microsoft is afraid of bad PR no matter how stupid / misinformed the person spreading the bad PR is ?

    Sales better than correctly informed developers.

    Sales better than performance and the impact it have on nature (So much for microsoft saying they care about nature and make green software).

    Make sales at any cost even lie, redirect blame, hide real cause of problem make it obscure.

    Yes, i agree with Ben Voigt. Providing a checked build only is a good way to force lazy developers to fix their bugs that they hid away. But i would go further than that if they want the logo certificate they will have to pass with the checked build even after RTM.

    What i hear is more hypocritical bullshit. Even from developers i assume is from outside microsoft that have obviously a lazy reason they don't want microsoft to change or just stupid and drinking the kola-id microsoft provides.

    Remember windows vista and what it did with old windows xp programs ?

    Where was all this sales-above-all-else-bullshit back then ?

    [If you don't want to accommodate compatibility in your code, then go ahead and pass NULL. See how many customers you get. If you want to see the shame list, just look at the Application Compatibility Database. And as we saw some time ago, in most cases, the performance gain is minuscule. -Raymond]

    I would implement error messages that reflect what program is to blame for the crashing. Putting blame and shame were shame it should be.

    The big problem with the Application Compatibility Database is that its not very many that know about or what it really is for.

    A shame list is meant to be public and very easily accessible to put pressure on the developers to fix the bugs instead of being lazy. Thats why its called a shame list !

    Microsoft already have the processes in place to make this happen.

    The Windows Logo Program Certification Process. If the developers want it then their software is required to pass all tests with the compatibility stuff completely turned off. Full hardcore strict mode.

    Yes they will complain and wine like the spoiled snotty brats they are but after the complaining and whining they will comply anyway. (All parents know this)

    For instance when windows crash it doesn't suggest what software was the cause because microsoft got no balls and dosen't want to get sued and get bad pr.

    This can easily be solved by modifying the terms of use agreement when developers program for the operating system. No unjustified lawsuits due to own fault, check!

    Telling the user about what software probably caused the crash or why it didn't run correctly is good very effective and motivating for developers to do their jobs and check their work.

    @DWalker "If a user upgrades to a new version of Windows, and some of their critical applications stop working (since the new OS now enforces a contract more strictly), the users are going to say "The new version of Windows sucks!  Don't buy it!"

    Thats just another poor excuse.

    Solution: Inform the user of why their software stopped working. (Come on now, the general population of the planet isn't at the same level of stupidity as those in america. Users will understand that its not the new version of windows fault.

    As with guns and car (licenses) if you are too stupid to use it properly than you shouldn't use it in the first place)

    Tell the user that software is doing something wrong (ie incorrect use of api) and is not compatible with the new version of windows.

    The manifest and certificate can tell what version of windows it have been tested with and supports

    All i hear are poor excuses of why not to fix the root problem. Money (sales), bad stupid pr, assumptions that all users are morons therefore treat them all as such and dont tell them the truth because they do not understand words or honest explanations.

    Did i miss anything ? Does that pretty much sum it up ?

    It's evil spiral that will only get worse and worse. It started small and got big.

    Windows 7 actually did compatibility a bit better. Instead of adding more compatibility crap into windows they added a virtual environment for software that doesn't work on windows 7.

    Using VMs are nearly perfect. Yes some hardware stuff doesn't work like 3d gaming but that can be fixed by adding support for it.

    Microsoft are treating all its users as complete morons. What they should do is inform and educate them.

    ( I know microsoft is an american company and as such got christian, religious, influences that is "education is bad" "science is evil" but you have to grow up eventually or get left behind. Microsoft likes to say they innovate, well put your actions were your mouth is ! )

    oh dear this got long, were you see only problems i see solutions out the wazoo

  26. @Rasmus says:

    Your assumption that the cause of bugs can automatically be determined is crazy bullshit. Example: Yesterday I discovered that the online help of my program does not open anymore but gives "DDE conversion failed". After googling, it turns out that the Reader no longer understands it "DDE application name" which was used by all older versions but requires a new one. How can you auto-detect such kind of problem, to automatically inform the user about the root cause?

    How would you determine which layer in the I/O system is guilty for wrong data or "device is unaccessible" because it depends on some very subtile "backward compatible" behavior (for example when accessing some external USB/ATA/Bluetooth device, having installed antivirus software + an harddisk imaging software + a DVD burning software + a driver for virtual CD drives + some anti-piracy driver installed by a game)?

    That said, I will not use a separate "checked" version of Windows. I dont have the time to install and maintain it. I develop within VisualStudio or Delphi, run and test the software there, so the only good solution would be a switch in Windows to configure additional checking (for all or only for some processes).

  27. Tud says:

    I wrote a long-ass response yesterday but apparently it got swallowed by the intertube monster. That's the second time it happens here. It even had fancy words from game theory like "Nash equilibrium", "tit for tat", "precommitment" and all!

    But now you won't get to read it. Ever.

  28. Anonymous Coward says:

    Tud, a lot of people here are frustrated by the commenting system. When you post a comment here it gets swallowed. Always. The only way to prevent it is to copy the text of your post, refresh the page and paste it back in and post it as quickly as you can. It's been reported but no one does anything about it.

    [In fact just yesterday, the site administrators applied another patch to try to fix the comment bugs. So it's definitely not the case that no one does anything about it. In fact, it's probably the #1 issue for the site administrators. -Raymond]

Comments are closed.

Skip to main content