I love analysts. Whether it’s predicting tomorrow’s next big thing or sounding the death knell for yesterday’s industry pacesetter, analysts never run out of new ways to get it wrong.
Case in point: Windows Vista and the “app gap.” According to Evans Data Corporation (EDC), less than 10 percent of developers are writing for Microsoft’s current state of the art. The majority (49 percent) are still writing for XP, while a small, but growing, contingent (13 percent) are focusing on Linux. Meanwhile, the myriad major media outlets continue to decry the lack of new Vista applications.
“It’s the OS that nobody wants,” they say, and developers are “reacting accordingly.” Of course, they’re wrong. Again.
You see, there’s no such thing as a Vista application. Just like there’s no such thing as an XP application. Or a Windows 2000 application. Developers who write for Windows rarely target a specific version. Rather, they select a particular API framework — for example, MFC/ATL or .Net — and proceed from there.
Whether or not the resulting application runs on a given Windows version depends on what, if any, version-specific API extensions the developer employs in their project.
For the majority of application types, this is a nonissue: They use the generic API functions, which allows them to run across any version of Windows that supports that framework. And since Microsoft does a good job of back-porting new frameworks to its legacy OS platforms, developers are rarely faced with a choice between rich API functionality or a broad installed base (the notable exception being video game developers, for whom leveraging DirectX 10 means committing to Vista).
So the entire Vista “app gap” argument is a bit of a straw man. The real question should be: Why aren’t developers leveraging the various iterations of the .Net framework? As anyone who follows Microsoft’s development road map will attest, most of the company’s cutting-edge API evolution is taking place within .Net.
In fact, when the “experts” talk about new programmatic resources in Vista — Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF), and so on — they’re really talking about the .Net framework 3.0. And since .Net 3.0 is available on down-level platforms (such as Windows XP), the argument circles back around to a question of .Net acceptance among developers — and why they have (so far) shunned it.
The answer is twofold: First, developers don’t like to target APIs that aren’t broadly available across the installed base.
Despite Microsoft’s aggressive support of down-level versions, there’s still a big difference between “available” and “available after downloading 20MB-plus of complex libraries and having them installed across various parts of your system.”
The fact of the matter is that .Net doesn’t ship as part of Windows XP, and that means that developers need to convince users to first install the required version of the .Net framework before they can install a piece of software — not always an easy sell, especially in the locked-down world of enterprise IT.
As the first OS to ship with the .Net framework installed by default, Vista was supposed to encourage development of .Net 3.0 applications. However, since it also supports legacy Win32, COM, ATL, MFC, and down-level .Net framework applications, there’s no real shortage of Vista programs.
In fact, unless you’ve just got to have that latest and greatest WPF/WCF framework functionality, there’s little to motivate you, the developer, to make the jump to .Net 3.0, or even 2.0. Assuming you don’t bump into the User Account Control (UAC) mechanism, your “legacy” Windows application probably looks and works great under Vista as is.
I know, because that was the case with my own code: A few tweaks to accommodate UAC (mostly shifting some temporary files away from newly protect directory structures) and my applications and services were running like champs under Vista — just like they do under Windows XP, Server 2003, and Windows 2000. Why fix it when it ain’t broke?
The second reason developers have shunned .Net is that it’s slow. Many common functions simply take longer under .Net, forcing developers to choose between API sophistication and raw performance. Not surprisingly, most developers choose the latter, as I was once forced to do when I discovered that the .Net equivalent of Performance Data Helper (PDH) was all but unusable for real-time sampling of Windows performance counter data.
As a result, I’m forced to maintain an aging (circa 1997) Visual Studio 6 code base while waiting for Microsoft to finally streamline .Net to a point where it’s a viable alternative.
It’s an old story and far too common among Windows developers.
Bottom Line: When analysts (and their media accomplices) decry the lack of “Vista applications” they merely trumpet their own ignorance.
I’m guessing it’s a Mac thing: So many of my contemporaries have been caught up in the reality distortion field that the idea of a link between API functionality and OS version has become an accepted part of the conventional wisdom.
It’s an honest mistake, equating Apple’s archaic patchwork of version dependencies to Microsoft’s imperfect, but far more flexible, API sprawl.
Too much fruit will do that to you.