Microsoft's Protean APIs

Microsoft is a company built by developers. Unlike IBM, Oracle, Apple, and other competitors, Microsoft came to the operating system and application business via selling software development tools. Programming is wired into its DNA.

These roots are reflected in the way Redmond provisions products. Developers enter a closed world where internal connections are directed at other Microsoft products. It's a world in which the entire ecosystem comes exclusively from Microsoft. To reach this goal, the company has at times undermined competing platforms and stretched standards. To wit, Microsoft paid Sun Microsystems $1.6 billion to settle a lawsuit claiming Microsoft undermined Sun's Java platform. Microsoft dropped its J# product. In other arenas, it uses market share to apply torsion to standards. No clearer example of this is Internet Explorer, which, in versions 5.0 through 8.x, made running standard HTML next to impossible. All Web developers know the frustration of fixing valid HTML so it renders correctly in IE.

This tradition of creating new standards that fit the company's strategic objectives has led to numerous new APIs and pressure on developers to migrate to them. Even in the early days of Windows, the company's fondness for new APIs cost developers dearly. The transition from 16-bit Windows to Win32 initially required programmers to choose one of three API subsets. Ultimately, two variants faded away, leaving just Win32. Then Microsoft published the Microsoft Foundation Classes, an entirely new framework that dominated Windows programming until .NET.

Migrating code to .NET was difficult and the new languages Microsoft provided generally weren't backward compatible. To use the new features, a working application had to be substantially modified or rewritten. This was particularly painful for Visual Basic programmers. The conversion from Visual Basic 6 to VB.NET meant brooking numerous syntactic language changes for which Microsoft provided limited assistance.

Making it across the river Jordan to .NET, however, didn't spare developers from a new series of APIs. They still had to choose which platform to use for projects: WinForms, Windows Presentation Foundation, and Silverlight are the principal client-side choices.

This history of constant forced migration raises the question of whether Microsoft will abandon Silverlight, now that HTML5 is increasingly the center of the rich Internet application universe. Given that IE 9 has extensive HTML5 support, this concern is particularly apposite.

While it's a fool's errand to predict corporate behavior, we know something of Microsoft's Silverlight plans. Version 5.0 is in a lengthy beta test and is expected to ship midyear.

Longer term, Silverlight looks like a keeper: Microsoft has invested substantially in making it run on Mac OS X and on the handheld version of Windows. The company also has invested in a Linux version, called Moonlight, developed jointly with Novell. It seems unlikely that Microsoft would walk away from this investment, especially now that RIAs are a hotbed of activity.

More likely, Microsoft will ride the RIA wave with continued investment in Silverlight and sufficient commitment in HTML5 to be part of that market.

HTML5--a specification controlled by an independent group--isn't historically where Microsoft would go. The company tends to provide programming layers over which it can exert control. I expect that if HTML5 becomes the standard everyone is expecting, Microsoft will leverage it via Silverlight, thereby preserving its technology while integrating it with the larger world.

Write to Andrew Binstock at [email protected].