Microsoft is a company founded by developers, which makes it a rarity among major technology companies. While you would think this provenance would predispose it towards the needs of developers, the company has long preferred to use developers as a wedge to sell its technologies, rather than a constituency to care for. It has done this is by pushing its own APIs, extending standards to use proprietary extensions, and once-a-decade forcing a sharp change of direction in programming technologies. The last point is critical to the Microsoft way, as it resets operating systems, APIs, and tools all at once. The Build conference in September marked another of these 10-year inflection points.
To recap history: In the early 1990s, the Redmond giant moved developers from DOS-based APIs to Win32, by forcing them through a painful series of API subsets: Win16 to Win32s and Win32g to Win32. In the early 2000s came the forced migration to .NET. In both cases, the company supported backwards compatibility; but by changing the UI, limiting updates, and providing diminished support for older products, Microsoft forced organizations to either rewrite their existing code, or at least commit to write future code for the preferred platforms.
The costs of these migrations has been enormous and continues to accumulate especially for sites that, for one reason or another, cannot migrate applications to the new platforms. (Those that can, of course, still bear the price of migration, but as a one-time cost.)
To be fair, the migration from DOS to Win32 had compelling motivators. The world was clearly moving to a GUI interface and 32-bit operating systems. One way or the other, there was a migration coming and Microsoft took action. The migration from Win32 to .NET had less obvious benefits. The most touted of these was so-called "managed code," which in theory eliminated a whole class of bugs and provided cross-language portability. It's not clear that the first benefit warranted rewriting existing apps, nor that the second one created lasting value.
Comes now the latest re-do: Windows 8, WinRT, and a host of new developer technologies and APIs that were announced at the Build conference. The primary axis of these announcements was the bifurcation of application technologies into two main lines: the new Metro apps and the legacy category, now called "desktop" apps, which subsumes all previous technologies. The Metro apps have a whole new UI that derives from the company's mobile offerings and is intended to look like a kiosk app, with brightly colored boxy buttons and no complex, messy features like dialog boxes or even message boxes.
The Metro apps will interact with the Windows Runtime (WinRT) APIs, while the desktop apps will interact with Windows Kernel Services (effectively the existing core Windows functionality repackaged). If you're finding this hard to follow, join the club. Slides with multiple revisions from Redmond suggest that even Microsoft is not quite sure what's what or how all the pieces work together.
Separately, the future of .NET, WPF, and Silverlight are open questions. Microsoft made various statements about ongoing support for those technologies, including the upcoming .NET 4.5 release, but there was no clear roadmap for them. The principal focus was on Metro apps, where the company stressed the resurgent role of C++ and of non-managed applications, which would seem to undercut .NET's future.
What is clear, if the presentations at Build are to be believed, is that Microsoft will push developers hard to rewrite code for the new platforms. (Already, the .NET 4.5 beta docs state: "Building a Metro style app requires that you redesign the .NET Framework application for the new user experience.") The benefits to the company are the same as ever: selling more tools, selling more software, and forcing adoption of new technologies. What is not at all clear is why, in the absence of conspicuous benefits, developers and IT organizations should go along for the ride.