* An explanation for why older apps, devices get left behind
Last issue I started talking about why installing service packs or operating system upgrades sometimes breaks older applications, services and devices so that they no longer work. I said I had a theory that explains at least some of these problems, although I’m sure there are other reasons also.
First, there’s the issue of buggy new software. Anything as complex as a service pack or an operating system upgrade has a huge amount of code, not all of which gets tested in every environment. That’s why I advocate testing in a lab first and waiting a short period of time to hear what others discover in their labs. But even once the software is stable and relatively bug-free, there are still instances of applications, services and devices which simply no longer work, or no longer work as intended.
My theory for this involves what I call the “maturity lifecycle.”
Each new version of an operating system tends to introduce new functionality, which is made available to third-party application vendors through new APIs. Many APIs can be rather complex, and many aren’t finalized until just before the operating system ships.
Independent software vendors (ISV) have two choices: develop to the initial, tentative, experimental API or wait for the final release of the API. The operating system vendor and the independent vendor both have an interest in getting the third-party applications rolled out for the first release of the new operating system. That’s why the tentative API is released and that’s why the ISV uses it. To encourage the ISV to do this, the operating system vendor will institute lax enforcement of the rules in the final API. Things like syntax, variable types, and more will be inclusive of both the initial API as well as the final one. But, over time, as new APIs – and the new data link libraries (DLL) which accompany them – are released, the rules will be tightened and enforcement will be stricter.
Some ISVs will create new versions of their software which incorporate the final API and remove outdated or no longer supported functions of the tentative API. Some won’t. The reasons why they don’t are myriad – some vendors go out of business, some applications or devices are no longer being bought by consumers and some choose different development paths (with different products) to accomplish the same result. In any of these cases, your older application, service or device simply won’t work with the new operating system upgrade.
When there’s a long time between releases of an operating system, though, the new, more “mature” API, as well as its enforcement, may be distributed with a service pack – sometimes on purpose but frequently not, as developers simply include the newest versions of the DLLs without really considering what they might do in terms of breaking old software. If enough people complain, it’ll be called a “bug” and rolled back. But not always.
So there are reasons why you should thoroughly test upgrades and service packs even after a year or so has passed since their release and most known “bugs” have been fixed. You need to know how it will run with your applications, services and devices.
