Microsoft and the API War

Joel Spolsky wrote a recent article "How Microsoft Lost the API War?" because of its recent tendency to abandon existing APIs and languages such as Win32 and VB6 in favor of new ones, like WinFX and VB.NET.

I don't think his arguments are persuasive. If anything, I think the new platforms have revitalized interest in programming Windows. I think that I think the older platforms was showing their age and preventing innovation.

In Win32, APIs were inconsistent and split into one of many different models--the classic API, COM interfaces like OLEDB and DirectX, C++-based APIs like GDI+, and OLE Automation-based object models found in Office applications. These various APIs were optimized for one language, and thus inaccessible or awkward to use from another language. There also was not a clean mechanism to move or run applications in the different platforms, be they different mobile devices or 64-bit processors.

Jeffrey Richter has spoken about some of the challenges Windows faced to balance innovation and compatibility. Entire features, that have been fully spec'ed, developed and tested for Windows, had to be dropped, because of incompatibility with legacy applications. He described how improvements to CreateWindowEx broke several existings application and had to be abandoned. Windows function calls are riddled with special-case code for different applications. For example, PeekMessage checks to see how often it was called in the last second and whether the calling application was PowerPoint.

Windows XP includes an Application Compatibility Layer, which modifies the behavior of Win32 calls based on the name of the executable. Supposedly, if the Windows calculator was renamed from calc.exe to armymen.exe (or some similar sounding name that Jeffrey Richter), Windows changes to 640x480 mode and disables Alt-Tab. Win32 is too stuck with the past to move forward in a compelling way.

I actually think much of the migration away from Microsoft is attributed to the difficulty of developing and deploying applications for Windows; if developers were so concerned with Microsoft maintaining compatibility with older platforms, I don't see why they would make a leap to a radically different and incompatible environment like Java. Microsoft's compatibility story isn't very bad; Microsoft's problem was ease of development.

As for Joel's comment that Longhorn's changes are not impressive, it's too early to talk to about the compellingness of Longhorn, since the latest bits released include neither the desktop composition engine nor the Longhorn user experience (Aero).

 

Comments

[Jonathan]

It seems to me that you're missing the most convincing point Joel made -- leaving aside the desirability of breaking with the past, having Avalon planned to supercede Win.Forms within a few years of the latter's introduction is a great way to dilute acceptance of either.

[Jeff Atwood]

Joel usually has interesting things to say, but I think he's completely off base on this one.

1) Without .NET, in particular, Java would have locked down every enterprise client in sight by now.

2) The Windows GUI is long overdue for a from-scratch overhaul; XP's GUI is basically a slightly prettier version of what was introduced with Windows 95. That makes it almost ten years old! I'm definitely looking forward to Avalon, to bring some of that html/flash GUI richness (and 3D hardware acceleration) to the operating system.

"The other camp is what I'm going to call the MSDN Magazine camp, which I will name after the developer's magazine full of exciting articles about all the different ways you can shoot yourself in the foot by using esoteric combinations of Microsoft products in your own software."

.. but that was very funny. So true. :)

[Wolfgang]

I really don't get it. What is all this talk about Avalon replacing WinForms? If you are only targeting Longhorn, yes, you are well adviced to use XAML/Avalon. But in any other situation, use Windows Forms. That's what Microsoft says. Now, since even now people are still using Windows 98, why would that all of a sudden stop with the introduction of Longhorn? I think WinForms has at least another 5-7 years in it, before a large enough portion of userbases have migrated to Longhorn to ditch it in favor of XAML/Avalon. Furthermore, I see absolutely no reason why you should at all be worried about any Longhorn technology if your application is primarily targeting current Windows systems.

The way I see it, you now have either a project targeting Longhorn, or a project targeting previous versions of Windows. In both cases, the choice between Avalon/WinForms seems pretty clear to me.

Meanwhile, the Windows kernel and APIs are dragging along. Every new version introduces new "special code" to not break what was before (usually code that does not follow Microsoft guidelines, uses undocumented calls and hacks). It's time to cleanup. I for one welcome this approach to Longhorn. It's long overdue.

[Jon H]

This actually reminds me of the angst in the Mac community over the Carbon vs. Cocoa divide. Carbon being the cleaned-up version of the legacy C-based Mac API, and Cocoa being the Objective-C-based OO framework API.

There was lots of worry about whether Apple would keep supporting one or the other. Lots of people parsing Apple announcements (and developer conference session descriptions, for that matter) for clues, interpreting subtle signs as meaning that, surely, one API or the other was doomed.

As it turned out, Apple has kept supporting both. They've used Cocoa for many of their recent applications like iPhoto and iMovie and iCal. They also use Carbon for things like Quicktime and iTunes, in part because Quicktime on Windows includes much of the Carbon API, while Cocoa is not available on Windows.

Perhaps Joel's angsty along those lines, thinking that one API "side" has to lose and one has to win.

[stefan demetz]

http://dotnetjunkies.com/WebLog/stefandemetz/archive/2004/06/23/17474.aspx

[Engr. Wale Kassim]

Let Microsoft changes everything because of their lack of foresight, it should have been obvious to them long ago (during Win 1-3.x) that improvement will be necessary, and all the API should have been designed in a manner that innovation will not affect previous software instead will even enrich them.

All the claims in Longhorn is easier said than done, after all you will see them breaking the rules by hiding some codes in other to enrich their own applications which usually caused programmers to reverse engineered most of their applications to learn some trade secrete, just like they do with screen saver programming in early Win95 and Office System Agents.

In Win 3.x era, Microsoft promised that the API will not change, but it turned out not to be true, by now it should be obvious to them that their exist lot of Windows supported software houses that those days, and the effect of abandoning 32bit API can better be imagined than experienced, they can’t bring us to this far and drop us.

No problem let them release OS that will not allow old software to function and we will see how much of there own application software can rule the entire Windows community.