Thanks for informing us that you know about the compatibility issue in your application, so we don't have to fix it


During the public prerelease period of a version of Windows some time ago, I remember a bug came in from an application developer. It went something like this:

Hi, we just tried our program on the most recent public prerelease version of Windows, and we noticed that you changed the undocumented XYZ function. Our program uses that undocumented function, and your change to the function breaks us. can you change it back? Yes, we understand that there are no guarantees surrounding the use of undocumented APIs, but still we'd like you to continue supporting the old version. It should just be a few dozen lines of code on your side.

How very nice of the application vendor to identify their compatibility issues for us. Now we don't need to create a compatibility shim, because not only do we know that the application vendor is still actively supporting the program in question, but that they have already been alerted to the problem with plenty of advance warning for them to issue a patch to their customers before the next version of Windows is released.

The product team rejected this change request with the simple comment, "Unsupported APIs are unsupported." Presumably the customer liaison translated this into something a bit more polite before communicating it back to the vendor.

Comments (58)
  1. Xv8 says:

    And then the vendor doesn't patch it, and every complains that ++Windows is broken and useless.

  2. Anon says:

    Wow, never thought you'd have a link to a KYM page in one of your posts.

  3. CarlMess says:

    No matter how many lines of code it would have been on MS side, I'm sure it would have had far more consequences in the use base than them figuring out a fix for themselves...

  4. Eddie says:

    @Xv8:

    It gets worse, some will complain that Microsoft is a monopoly and they purposely broke the app so as to compete with it.

  5. John Ludlow says:

    @Xv8:

    The alternative would be to build in yet another workaround for the fact that some people are stupid, which makes life harder for everyone else. Half the posts on this blog are of the form "functionality X is misleading, but if we correct it, something somewhere may break", or "When you ask for X, we automagically translate that to Y because we think that's more appropriate".

    Eventually, I think MS will have to spend a release cycle untangling this nonsense, breaking everything in the world ever, because this stuff will build up to the point where it's impossible to predict what any given call to anything will ever do, which will make it impossible to develop and maintain applications.

    Personally, I like the idea of major releases being allowed to break stuff, because it avoids that kind of situation.

    [All that means is that people will say "Don't upgrade to the next major release. It breaks stuff." -Raymond]
  6. @John Ludlow says:

    The application developers wouldn't have any issues if they STUCK WITH THE CONTRACT.  Microsoft upholds their end of the published contract(API).

    The problem is the people who decide "that's not good enough" and go digging around in the internals of Windows, using stuff that's not publicly documented or supported, and then complaining when that stuff changes, demanding Microsoft fix it, even though Microsoft does not provide support for those internals, and has the right to change them at any time.

  7. Joshua says:

    I reported one awhile back where GetAddrInfoW would accept trailing whitespace (at least a trailing newline) in pServiceName on XP through 7 but stopped doing so on Windows 8. I reported it via the MSDN article comments so I never found out if it was an intended change or not. Thankfully I wasn't in the case of having to support that headache on existing versions because the installer died pretty hard on Windows 8 (there's still a kernel32.dll version check* for >= 6.2 in the installer today because the right thing on 8 doesn't work at all on 7) and we discovered this during testing of the first version to work on Windows 8.

    *We use kernel32.dll version checks because GetVersion() lies always now. Yeah sure I should be using VerifyVersionInfo but it's a worse headache than a version ladder in the installers's procedural language. Also, the ladders check for hotfixes (install on XPSP2 below a specific hotfix version -> bluescreen loop), which VerifyVersionInfo can't do.

  8. John Ludlow says:

    > The problem is the people who decide "that's not good enough" and go

    > digging around in the internals of Windows, using stuff that's not publicly

    > documented or supported, and then complaining when that stuff changes

    Not sure if you realise this, but we're in agreement here. I don't think people should root around in undocumented areas for "clever" solutions to problems.

    My point was that MS cause problems, not by changing stuff in potentially breaking ways, but by trying to avoid breaking stuff. There's plenty of examples in this blog.  Arguably, some of these are examples of Microsoft breaking the contract on their side.

    One example: The Windows API lies about what version of Windows you're running on to cater for some old, poorly written applications. That means the documented method of finding out what version of Windows you're on **does not work** because it returns an incorrect value.

    [But why do you need to find out what version of Windows you're on? You should be doing feature detection, not version detection. -Raymond]
  9. Ooh says:

    @John Ludlow: First, as Raymond noted in the meantime, why do you need to know the version at all?

    Second, why does it not work for you? What's the incorrect value you're talking about? It works fine for our products, also on Windows 10. Only thing to remember is to declare compatibility in the application's manifest, which you should do anyway (of course only after you've successfully tested it).

  10. Joshua says:

    [But why do you need to find out what version of Windows you're on? You should be doing feature detection, not version detection. -Raymond]

    pkgmgr vs. dism

    The way you install .NET if it's missing

    Detecting presence or absence of mandatory hotfixes (such as KB3081436)

    The way you install the IIS compatibility framework is different between IIS versions

    The only times I got feature detection for Windows components to work reliably optional Windows components and 32 vs 64 bit. We just don't end up using Windows core features that aren't there on older Windows versions much.

    [I don't know what the issues you have with pkgmgr, dism, and IIS are, so I won't try to address those. The way to install .NET is to run the installer. The installer will do the rest of the work. Version checking to detect presence of hotfixes is incorrect, because hotfix application is nonlinear. You should ask Windows Update if hotfix X needs to be applied. -Raymond]
  11. John Ludlow says:

    > [But why do you need to find out what version of Windows you're on? You should be doing feature detection, not version detection. -Raymond]

    Because I want to know what version of Windows I'm on. That's a valid answer in and of itself. Being able to report to a user "hey, I think you're on this version of Windows" is a valid thing to want to do. It's also valid for me to restrict you from installing on versions of Windows I haven't tested my app on, regardless of what *features* may be installed.

    And, of course, in newer versions, MS will add new (fully documented) functionality to the API which is not in a feature like IIS or PowerShell, and my application relies on that functionality. I need to mandate that this functionality is present (because my application relies on it) and I can't do it in a feature check (because it's not a feature).

    I'm also not entirely clear how the feature detection is supposed to work - how can I mandate that IIS version 10 is installed, for example?

    But really, you're missing the point, I'm afraid. It doesn't matter why I want that information. What matters is that the information is reported correctly. And it's not. I understand why that is, but I disagree that it was the correct thing to do.

  12. John Ludlow says:

    @Ooh

    The 2 main things that spring to mind

    1: VistaRTMVersionLie

    technet.microsoft.com/.../cc748938(v=ws.10).aspx

    This makes it difficult to have custom version detection logic in installers.

    2: Changes to App Compat, discussed here by Heath Stewart:

    youtu.be/W8jYsXWP0D4

  13. alegr1 says:

    At this time, there is no good way for an MSI package to detect it's rinning on Windows 10. Because Microsoft forgot to add Windows 10 manifest to msiexec.exe. So if you want to install different driver packages for Windows 8.x and Windows 10, you're SOL.

  14. jon says:

    Would be less of a problem if Microsoft weren't so obsessed with having so many undocumented APIs. Just get some interns to write the docs, they wouldn't do a worse job than most of the stuff that has been documented lately.

  15. Brian says:

    @John Ludlow:

    >>Eventually, I think MS will have to spend a release cycle untangling this nonsense, breaking everything in the world ever, because this stuff will build up to the point where it's impossible to predict what any given call to anything will ever do, which will make it impossible to develop and maintain applications.

    Vista kinda-sorta did that (as a follow-on to XPsp2, where the trend started).  Remember how much fun Vista was and what a great success it was for MSFT.

  16. Anon says:

    @John Ludlow

    No, it isn't valid for you to tell me what versions of Windows I can install the product I purchased on. It is valid for you to tell me what versions of Windows you *support*, but when your company goes out of business next week, I may have mission-critical apps that rely on your product that suddenly don't run because you thought you magically knew your application wouldn't run on Windows 10.2

  17. Benjamin says:

    It never ceases to amaze me how many times this same conversation can be had.  As if Microsoft is going to say "You know, the last 20 years of market experience, during which we have sold more OSes than anyone else on the planet, mean nothing!  Instead, let's follow the advice of commenters on the Interwebz and break everything for the sake of satisfying some programmers' obsessive desire for API elegance!"

    The API are undocumented not because nobody has time to document them, but because once it gets documented, it has to be supported for all time. It's like some people have never read this blog before...

    [See, for example, the long-forgotten (but documented) MenuHelp function. -Raymond]
  18. dasuxullebt says:

    Hm. The one thing I liked when I learned Java - which was a while ago when it renamed itself from "Java 1.2" to "Java 2" - was downward compatibility. And in fact, the standard API is still downward compatible. But it is never sufficient, and everything else assumes at least some additional things about the system layout.

    Am I the only person who somehow gets scared when thinking about the probably existing towers of lost-source-software that run in maybe important systems?

  19. Yukkuri says:

    >>It's also valid for me to restrict you from installing on versions of Windows I haven't tested my app on

    Is this a feature you expect to get a big bonus for from management?

  20. John Ludlow says:

    @alegr1:

    Yup.

    @Brian:

    Every major version of Windows did that to the extent that Vista did. XP was every inch as bad as Vista. And they didn't strip out nearly as much of the compat stuff, which is why we still read posts about app compat fixes for Win 9x-era apps.

    @Anon:

    Of course it's valid! You can take your ball and go home (AKA, don't buy my application) if you don't like the fact that I did that. But it's still valid for me to do it. You make a fair point about support, but if I allow you to install on Windows 95, you can guarantee that someone will try that regardless of what I support. The install should actively prevent that situation.

    Your comment suggests you're building mission-critical apps based on an assumption that my application will work on some magic future version of Windows. Sorry, I can't guarantee that. That's not how time works, and I'd suggest you rethink how you build mission-critical apps.

    Generally, though, I wouldn't restrict the upper bound, but I would restrict the lower bound. In other words, unless I had some specific reason to restrict you from installing on Windows 10.2, I wouldn't.

    [Word on the street is "Don't upgrade to Windows 10. John Ludlow's app won't install." My guess is that the single largest source of version compatibility hacks is apps which do a version check and refuse to run, even though they run just fine. (Instead of refusing to run, why not warn the user "Hey, I haven't been tested on this version of Windows, so it may not work. Install me anyway?" That way you don't block the corporation who is trying to deploy Windows 10 to its 5,000 employees.) -Raymond]
  21. Anon says:

    @Brian

    Other than fixing the security model, the big breaking change in Vista was the kernel version, which broke any code stupid enough to depend on the kernel version for... well, anything at all.

  22. Anon says:

    @John Ludlow

    I'm building mission-critical apps based on an assumption that third-party apps won't stop working for trivialities. If the application *breaks*, that's on me -- you didn't test it against the future. If the application *intentionally stops working*, that's on you.

  23. skSdnW says:

    Feature detection does not work in all cases. You cannot detect if your desktop app can use the share contract without checking the Windows version number. It only works (for desktop apps) on Win10 but the COM interfaces exist on Win8 and even go as far as returning S_OK on the final share method call but nothing is actually shared!

  24. Chris says:

    Raymond, I think you might be trying to be helpful, but seriously, you need to consider what question you are being asked when providing an answer.  If there is an API that says it provides a version, why in the world would you ask someone why they need the version?  Why does their reason matter?  If they have a really, really good reason, would you consider fixing a broken API?  If the reason doesn't meet your criteria, are you suddenly comfortable with a broken API?

    And as far as why not install, the same applies.  Maybe they have a good reason.  Maybe they don't want to deal with support calls regarding something they don't support!  Maybe customers really do tend to be stupid and so they need hand holding to make sure they do the right thing (for example, providing a broken API and then asking customers why they want to use the broken API is not hand holding).

    And @John Ludlow, you are doing the right thing.  Tell your customers that the app works on versions X, Y and Z of OS.  If they want it to work, they should get version X, Y or Z of the OS.  I'm guessing that you know this and I'm guessing that your boss is sick of having to spend money dealing with calls from customers saying that the app won't work on version Z of the OS and can someone please help them.

  25. A regular viewer says:

    This argument is as old as the term "EDP". Product or Service. A product is feature-bound at only a specific time. In other times the feature set can differ. A service is feature bound for only a specific feature-set; irrespective of the time when that feature is called into action.

    Is MS Windows a product or a service (for application developers, that is)?

    More to the point. What should it be?

    Being both is well nigh impossible.

  26. David Totzke says:

    @Chris Microsoft has been quite vocal about Windows 10 being the last version of Windows.  From here on out it's feature enhancement/addition/whatever.  Version detection, such as it is, is no longer a viable option for controlling the behavior of your program/installer/component/thing.  @John Ludlow et al can make up all the excuses and reasons they like for why they MUST do version detection, but that's not going to work from here on out.

    I think there is some confusion around feature detection as well.  It's not capital "F" "Feature" detection as in Windows Features that are installed.  It's features with a lower case "f".  I prefer the term "capabilities".  Can the system do "x"?  If so, then certain functionality "lights up" in your program.  

  27. Kirby FC says:

    @John Ludlow

    "You make a fair point about support, but if I allow you to install on Windows 95, you can guarantee that someone will try that regardless of what I support. The install should actively prevent that situation."

    Why?  Have you actually tested your program on Windows 95 and verified that it doesn't work properly?  If you have, then fair enough.  If you haven't, and you just don't want to be bothered supporting your application on Windows 95 then tell people up front "This product is only guaranteed to run on Windows XX and YY and anything  else is not supported".

    Real life example:  A couple of months ago I tried to install an application on Windows 10.  It displayed a message "Not supported on this version of Windows".  I ran it anyway and it worked fine.

  28. Harry Johnston says:

    @John, personally, I think the changes to the version API weren't in order to support "old, poorly written applications" (the compatibility engine can handle them) but in order to make it harder for programmers to make the same mistakes in the future.  (It reminds me of UAC in that respect.)

    Since you're *trying* to make one of those mistakes, i.e., refusing to install unless the version number meets your approval, it isn't surprising that the changes are annoying to you.  On the other hand, there is still a documented procedure for getting the "real" version number, so you're not stuck - you can still break your software, you just have to put a little extra effort in! :-)

  29. Wear says:

    @John Ludlow Stop DDoSing yourself. You are literally spending hours of your life making your own application not run.

  30. Joshua says:

    [The way to install .NET is to run the installer.]

    The pre-Windows 8 Installer and the Windows 8+ installers for .NET framework versions are completely different, and the compatibility shim that picked up the pre-8 version didn't work right when I tried it (I think it ran asynchronously or something like that, which is really bad when you invoke a .NET program 5 seconds after the framework install seems to finish.) Also, starting with Windows 8, the best way to install .NET appears to be invoking dism.exe.

    [You should ask Windows Update if hotfix X needs to be applied. -Raymond]

    Too many of our customers like to run w/o any internet connectivity, so I can't ask Windows Update reliably. By checking myself (I read the update KB files to determine branch ranges so I really can handle nonlinear checks), I can at least error out cleanly.

  31. Harry Johnston says:

    @Joshua: you might want to double-check that; I believe the bits of the Windows Update API relating to which updates are already installed will work w/o internet connectivity.  (I'm not certain.)

  32. Erik says:

    How do I do a "feature" check to see whether the OS will block ATA DATA SET MANAGEMENT and instead required me to use the (broken, but that's another story) FSCTL_FILE_LEVEL_TRIM? How about determining which of the Volume Snapshot Service executables(XP, 2003, others) I've bundled that needs to be executed?

    Feature checks does not cover all cases. A reliable version check is needed, so that we don't have to resort to probing what works.

  33. John Ludlow says:

    @All (including Raymond):

    You are aware that this is a hypothetical scenario, right? Hypothetical app with hypothetical (but totally realistic) dependencies.

    On a more serious note:

    I'd expect that most applications are used by a relatively small percentage of the computing population, and that my application's compatibility issues should not drive policy for everyone. Which means that, as a user,  I'd rather that an application break than cause ridiculous workarounds to be subjected onto the rest of humankind just so that I shouldn't be forced to (shock! horror!) upgrade or find an alternative.

    I treat this no differently than upgrading to a newer version of an IDE, such as Visual Studio. I should always be on the latest version of everything. As soon as an upgrade for something I rely on is released, I should adopt that version. Unless there are good reasons not to. A library failing to compile under the latest version of Visual Studio is not a reason not to upgrade, as that library should be upgraded or replaced. We recently learned this to our cost, since we put off an upgrade of VS for a very long time, and it took a year and a team of 6 skilled engineers to upgrade our code.

    Similarly, an application breaking on the latest version of Windows is not a good reason to avoid an upgrade - that application should be upgraded or replaced.

    > Why?  Have you actually tested your program on Windows 95 and verified that it doesn't work properly?

    Maybe, maybe not. Maybe I know that I need stuff that isn't in Windows 95 (which is a heck of a lot of stuff!). Maybe I just don't want support calls from versions of Windows that MS won't support. Maybe I **just don't want to test it**.

    > Real life example:  A couple of months ago I tried to install an application on Windows 10.  

    > It displayed a message "Not supported on this version of Windows".  I ran it anyway and it worked fine.

    You got lucky. The app said "don't do this, it don't work" and it worked. You appear to be asking for things to be the other way around.

    > Is this a feature you expect to get a big bonus for from management?

    It's usually a manager who asks me to make a change like that. If it came from someone else (such as QA), I'd get a manager's approval first. As for a bonus, since it's usually trivial I wouldn't expect a bonus as they are handed out for major pieces of work. However, since it seems to be getting more difficult, maybe I will expect a bonus for this sort of thing in future!

    > [The way to install .NET is to run the installer.]

    Basically, what Joshua said. If you run the .NET 3.5 installer on Windows 8, it fails. You have to use the Programs And Features control panel applet (or the Roles And Features wizard if you're on 2012 R2) to install it.

  34. Phil McKerracher says:

    Am I the only one who finds the tone of this rather condescending and arrogant? It's effectively saying "you'll get what we give you and like it, son", without even having the courage to say it to the customer's face, relying instead on "customer liaison" to sugar coat it with some lie. The customer is just trying to earn a living like all of us and you seem to be preventing that without a second thought - in a closed source operating system, no less.

    Let's hope "customer liaison" had more of a clue and either helped the customer do what they were trying to do with supported APIs, achieve a better result some other way, realise that what they were doing was never actually as useful as they thought it was, or apologised profusely for turning a useful product (for them) into a useless one for the greater good of other customers.

    Maybe I'm being unfair and the debate did happen but was omitted from the summary above. But as described it sounds as if a customer has unnecessarily been lost along with a good chance to improve the product.

  35. Stephen says:

    I actually ran into the version thing while working on management firmware.  There is a very simple program that runs on the host that provides the OS version to the management controller.  A remote administrator can then (while the system is powered off) query the last used OS (with version information).

    The intent is to be used for software inventory purposes.

    If a remote admin wants to ask "what version of Windows is that system running?", the version of Windows is absolutely relevant.  Feature detection is not useful in this case.

    The API change *prevents* a well-written program using only supported APIs from working on future releases of Windows.

    We ended up finding a different supported API to get the Windows version (the purpose isn't to get the Windows version, it just happens to include it), but I'll not post it here to help prevent it from getting "fixed" as well.

  36. Viila says:

    "[But why do you need to find out what version of Windows you're on? You should be doing feature detection, not version detection. -Raymond]"

    In my case telemetry. I would very much like to know that if my application starts reporting failures whether it really IS failing on Windows X or Windows X+1. I would like to think that this is a perfectly valid and acceptable use case for knowing accurate version you're on, even (especially) if it's a future one.

    In the end I dug it out from WMI, or from an ugly hack if WMI is not available.

    [Yes, telemetry is a valid use case for this. Your program won't change its behavior; it's just using this for analytics information. Interestingly, the Windows Runtime API for getting analytics information is already being abused to make programmatic decisions. -Raymond]
  37. cheong00 says:

    @Phil McKerracher: IMO "Unsupported API is unsupported" is a reasonable response.

    Think about it. There is a empty land area in the town where some people try to place their goods there. The government keeps saying people should place their goods there but they won't listen.

    One they the government decided that they need a new building on the empty land so they build it. Now people complain that they no longer be able to store their goods there so the government should demolish the building so that they can store the goods there again.

    Do you think those people storing goods resonable or not?

  38. cheong00 says:

    @Viila: In your case you'll want to know the DLL version number of the DLL containing API that is failing, not the Windows version.

    Your way prevent your program to work even if a later fix corrected the behaviour.

  39. Yukkuri says:

    I see my comment went sailing right over someone's head...

  40. Yuhong Bao says:

    There was at least one major app where a shim was created for Win10 because of a buggy .NET Framework version check in the installer, where to fix it properly the media would have to be remastered, and that major app does yearly releases.

  41. Scarlet Manuka says:

    After reading the "Now we don't need to create a compatibility shim" paragraph, I was expecting the kicker to be that they did have to create a compatibility shim for it anyway in the end (e.g. due to the vendor being unable – or perhaps just unwilling – to get a patch out in time).

  42. Anon says:

    @John Ludlow

    If you run a .NET 3.5 app on Win8, it will offer to install .NET 3.5 for you.

  43. John Doe says:

    @Anon, how convenient, I'm sure someone will be there to answer the prompt when the service starts after installation.  Oh...

    @Phil McKerracher, although it is condescending, using undocumented APIs is just that.  Imagine someone using undocumented exported functions from your native DLLs, or internal or private definitions from your .NET assemblies.  If you were Microsoft, would you be willing to change your internals because of 1 customer that knowingly does The Wrong Thing™?

    So, there should be a reliable way of getting the actual version, a reliable way of getting the emulated/shimmed version and a reliable way to ask for capabilities/features.  Is this all in place?

  44. 640k says:

    EU might be interested in hearing more about this uncompetitive behaviour.

  45. @640k: How is this discouraging competition?  We don't even know that the API in question is.  Heck, we don't even know what the app is.

  46. morlamweb says:

    @John Ludlow:

    "> Real life example:  A couple of months ago I tried to install an application on Windows 10.  

    > It displayed a message "Not supported on this version of Windows".  I ran it anyway and it worked fine.

    You got lucky. The app said "don't do this, it don't work" and it worked. You appear to be asking for things to be the other way around."

    Are you reading the same message as I am?  How do you turn the message "Not supported on this version of Windows" into "it don't work"?  I work in tech support and I am keenly aware of the difference between unsupported and broken.  They are not even close to the same thing.  In my business, 'unsupported' means that you won't get help from the company for technical questions; 'broken' or 'it don't work' means that we've tested the software in that configuration and we know that it doesn't work.

    The app was right in displaying a message about the unsupported OS.  It's likely that the app hasn't (yet) been tested on Windows 10.  However, since unsupported != broken, the installer was allowed to continue, and it sounds like the app worked.  (Hopefully because the developer(s) stuck to the published APIs).

  47. Microsoft OSes are the Best! says:

    The greatest thing about Microsoft Windows (and DOS!) is that programs from years and years ago still work!  I trusted in Microsoft to not break backwards compatibility - and they followed through!  If an app uses the documented API, then there is no reason to version-detect.  The fact that the OS may lie about its version means some apps still work (so much backwards compatibility effort from Microsoft and Raymond, Thank You Very Much!!)

    Apps that purposely DoS themselves after a Microsoft Customer upgrades to a new OS... wow.  Maybe on some OSes, but not on Microsoft Windows.  

    Of course, exceptions to every rule, the general case being that "no API exists, we have to use undocumented details".  In which case, version detect is not the solution, one has to detect the feature.  How to detect a feature?  Well, that's the fun part!  There are no rules for that.  The OS version is not the way to detect a feature.

  48. James Sutherland says:

    It is a shame the answer amounted to "don't use xyz" rather than something more helpful, like "instead of using the undocumented function xyz, you can get that information by calling FrobnicateBadgersEx passing the FBE_XYZ flag". Otherwise, I think we all know they're going to end up with "if winver() < 410 xyz(a,b,c) else xyz(42,c,b,a)", and if a subsequent patch backports the new xyz implementation, someone's going to complain that patch breaks that application now...

    I know users can be demanding - it wasn't that long ago I got a plaintive email reporting that a free utility of mine had stopped working on Windows 2000 ... and in 2012, a request for Windows '98 support on another one. (Now I test against a Win2k VM for the first, and I went and added DOS support to the second one, since it was an interesting challenge: DOS 6 to Win10 x64 in a single EXE...)

  49. @James Sutherland says:

    We don't have enough information to know if that would have been a good response. They may have been calling an undocumented API for changing a setting that should only be controlled by the user or a hardware event. If Microsoft locked down the function in a later release, perhaps making sure that calls only come from something like CSRSS, then it would break their code and there would be no supported API to achieve the same goal. In that case the liaison likely knew that it is a setting that no one should be screwing with, but did due diligence by following up with the people responsible for it.

  50. Katie says:

    That last comment was from me if you want to respond. I noticed as I submitted that I put the @ reply in the name field.

  51. Max says:

    "Your comment suggests you're building mission-critical apps based on an assumption that my application will work on some magic future version of Windows."

    Think of it from a user's perspective. The user expects the program to run, period, regardless of what they do with any other piece of software on their system. You're free to inform them that a particular configuration isn't supported, but they'll probably try it anyway, and most of the time it'll probably work fine - after all, the app-compat guys go to a lot of trouble to minimize breakage.

    From a developer's perspective, this is potentially very annoying, but from a user perspective, you're preventing users from upgrading other software they own because you don't want to deal with them complaining about bugs you haven't fixed yet. This can have potentially wide-ranging impacts: one of the biggest technology scourges of the 00s was platform lock-in caused by developers who dragged their feet on modernizing their software and chained users to old versions of platforms - IE6 and Java 6 stuck around far too long, mostly because of legacy enterprise applications refusing to work properly on newer versions of those platforms.

    "Similarly, an application breaking on the latest version of Windows is not a good reason to avoid an upgrade - that application should be upgraded or replaced."

    Upgrading or replacing an application is expensive - for certain kinds of software, particularly in the enterprise space, even upgrades can cost quite a bit of money. And of course replacing a program that's running on every computer in your globe-spanning multinational business is absurdly costly. Even if it's not a business-critical application that you literally can't keep the doors open without, it's still a considerable inconvenience and cost to have to buy a new program because the old one just decided it's not going to work on new platforms and the developer was too much of a purist to care about their users' problems.

  52. Anon says:

    @John Doe

    You can use dism or Powershell to get the status of any Windows feature during installation, and/or change the state of any Windows feature during installation.

    A better method, of course, is to stop using .NET 3.5. .NET 3.5 is no longer supported. Hell, .NET 4.0, 4.5 and 4.5.1 only have ~3 months left.

  53. Pete says:

    MSDN itself suggests version checking for WP stuff, e.g.:

    Do not use ReaderWriterLockSlim on Windows Phone 8 devices that are running a version of the Windows Phone 8 operating system earlier than Windows Phone 8 (8.0.10322.0). Prior to Windows Phone 8 (8.0.10322.0), this class throws a MethodAccessException exception when two readers enter the lock. In most cases, use the Monitor class instead.

    For a code sample that shows how to check the operating system version and build number, see Adding Windows Phone 8 and Windows Phone 7.8 Tile functionality to Windows Phone OS 7.1 apps.

  54. James Sutherland says:

    @Katie: That's possible, but the complaint was that MS 'changed' the function, not that they disabled it, which suggested something like a change in the numbering of some option number - so FrobnicateBadger(7) on previous versions became FrobnicateBadger(11) on the new version due to adding some new badger frobnication methods.

    If it had been a "user-only setting" (a concept I've always disliked - after all, the software is running on behalf of the user; if there is an on-screen checkbox for enabling something, applications *can* change that, it's just a question of how awkward and obfuscated the mechanism is, ranging from a proper documented and supported API to a hideous kludge of having to simulate user input and manipulate the UI to achieve it) the reply really should have said that. Maybe it's implied, from the lack of suggesting a better route, but either way I'd have expected a bit more effort to steer them to a way less likely to create compatibility headaches for both sides later on...

    [Not a user setting. It's an internal interface that the shell uses for keeping track of XYZ. The interface changed for internal reasons, and they want to change it back. Basically "Please change your interface back to the old way. Sure, you're adding back dead code and have to continue supporting an old interface, but that way we can still call it." -Raymond]
  55. Anon says:

    @Pete

    Relevant as soon as Raymond starts up his Windows Phone blog.

  56. Anon says:

    @jon

    Undocumented APIs are unsupported, that's why they're undocumented. They've intentionally not been documented to discourage anyone from attempting to use them, so having people document them would be counter-productive.

  57. morlamweb says:

    @Pete: as Anon has pointed out, this is a win32 blog, not Windows Phone, and the rules regarding version checks may be different for that OS.  Is version-checking the acceptable way in the WP world to check for phone features or APIs?  Or is it something recommended by MSDN only for specific cases where an API had a known bug in older versions of the OS?  Whatever the case may be, the answer has no bearing (yet) on Win32 and version checks.  Examining the OS version in win32 to determine support for features will only lead you down a bad path.

  58. Anon says:

    Windows seems to generate a lot of "blah blah isn't compatible ENOUGH" traffic. Worth a reminder that Windows is the only OS that even *tries* to be backwards-compatible.

    If you don't like Windows' backward- and forward-compatibility efforts, feel free to move development to OSX, where every point-release breaks everything, and the dev-support response is "So?"

Comments are closed.

Skip to main content