Longhorn Redux III

Give Microsoft credit where credit is due – they know a losing strategy and the Gates of Longhorn was certainly that. And so they have abandoned it. And make no mistake despite overtures to WinFS being developed in parallel while Avalon and Indigo get to “to flourish” by being retrofitted and tacked onto the WinAPI – the vision is gone.

But just like the US in Iraq – do they have an intelligent exit strategy, another hip pocket, fallback alternative? Or will it be another case of Windows design by winging it – not quite impromptu comedy but more like harpoon thrusts trying to stick to that great Ahab whale, the WinAPI. To answer the question we have to consider why Longhorn was abandoned

Longhorn was abandoned for 3 primary reasons. First, as Microsoft alluded to – they needed to cut to meet their 2006 deadline. And the reason they needed to cut is because Avalon plus WinFS and parts of Indigo added up to a brand new WinAPI. But the coding tools for that could not be delivered by 2006. So each development team would be bootstrapping their way to completion.

Just as a point of reference, the latest .NET Framework – not the Longhorn enabled one but its predecessor – is not due out as Visual Studio 2005 until mid next year. Now the latest versions of Win XP, Office 2003, and many of Microsofts application programs and server products have not yet been converted to .NET Framework managed code. However, senior MS management have promised that 3 months after Longhorn was to appear in 2006, Office 2006 would also be introduced and it would be coded using Longhorn APIs. But there are no tools for the Office group to write the Longhorn code with. OOOOOOgah OOOOOOgah OOOOOgah – Abandon Ship!

The second reason that Longhorn was abandoned is because the uptake of the current .NET Framework by ISVs and corporates has reflected Redmonds own practices – slow. You may have seen the Microsoft ad – “56 % of corporate shops are using .NET Framework for development”. Omitted from that statistic was the the number of shops that had fully converted to .NET development – a much smaller percentage. And with Longhorn coming along in two years time and requiring nearly a complete change again in code – literally Longhorns API was going to completely displace the WinAPI as used in the .NET Framework, you can imagine the enthisiasm in shops large and small for the fact that they would have to convert their “new” .NET code in two years time to Longhorn code. No wonder the old time religion of VB6, C/C++, COM, ActiveX and pointer-filled never-managed code are doing so well. Microsoft could see this problem and adjusted accordingly.

The third reason that Longhorn was abandoned was alluded to in an earlier posting. Microsoft does not want to get Itaniumed. As seen above, Redmond is already seeing major resistance to .NET . But the propensity to adopt the wholescale changes represented by Longhorn (think conversion of all device drivers, substantial portions of UI code , plus data transactions systems) must have been oscillating between slim and none both for ISVs and corporate developers. With Linux, J2SE, Flash, and J2EE all on the brink of major breakthroughs – alienating the developer community with major yet less than compelling changes … Microsoft could see the AMD vs Intel in 64bit computing writing on the wall. Dont risk the Windows franchise on getting cash strapped ISVs and IT shops to do major conversions to Longhorn. Just as OEM and PC vendors have owed a big thank you to AMD for keeping Intel in line, ISVs and corporates owe Linux , Java and Open Source bigtime for keeping Microsoft honest.

So now the question is what is the Long-turn-to-short-horn exit strategy ?

Well first lets consider the problems that Longhorn was designed to address.
1)There is a mess in Redmonds UI development with five different frameworks vying for developers attention and allegiance: i-the old VBAforms, ii-classic Winforms, iii-the “new” .NET WebForms, iv-the newer Compact Framework, and v-the newer-still InfoPath forms. Avalon+XAML+the new GDI were designed to reduce this proliferation down to two possibly one framework for developers to know. What Shorthorn is going to do is unclear.
2)There is an equivalent mess on the database side of development as well. ADO, OLE/DB, WSS, ADO.NET, MSDE are just some of the competing technologies. Yukon or WinFS was designed to finally rationalize all the competing database frameworks buried in various Microsoft servers, applications and development tools. Now that WinFS is off the table ….
3)There is a mess in Redmonds component and distributed processing frameworks supported. Is it COM, DCOM, .NET Framework, Web Services ? Allbeit with .NET Framework for Longhorn to be used by the Office, Server, and Application system groups to coincide with Longhorns introduction – a grand unification as in theoretical physics was deemed imminent in Redmond development. But with WinFS gone and Avalon become a tachyon to the WinAPI, and Indigo now missing some pieces – in the immortal words of Desi Arnez – “Redmond, you have some splainin to do”.
4)There is a mess in Microsofts scripting tools. Its the same old broken record – many different and mutually incompatible and now growing in obsolesence tools: WSH, VBA, VSA, JScript, JScript.NET, VBScript. plus not a little unofficial Perl. Is this the fire that just does not get put out ?
5)There is a ship-or-get-off-the-pot mess in Redmonds interoperability message. On one hand Redmond claims they are interoperable because they support many languages, Web Services, and XML. On the other hand Redmond has been the one vendor who has stopped updating W3C , ECMAScript, and other standards in their browser since 2001. In doing so, Microsoft has foisted hundreds of millions of man hours of extra work on developers every year to make sure Web applications run in the IE browser. Redmond has started to take out patents on its XML code despite W3C recommendation that XML and its standards remain patent free. Microsoft has stated it will not support XPath2, XSLT2, and any other standard other than its own XAML for GUI resource definition. As well Redmond has taken rainchecks on XML stanadrds XForms, SVG, and SMIL among others. So much for Microsofts “support” for XML standards. Microsoft also has failed to implement natively in its software a number of defacto and/or dejure standards including Flash/SWF, CORBA, OpenGL, Java (Microsoft paid $2B for the right to poison the well of Java compatibility on the desktop with an obsolte version of the Java VM at least until 2007) etc, etc. Finally, many vendors like Adobe and Macromedia have toggle switches in their development tools that allow users to check that their code meets some level of W3C and other standards – and by turning on the switch certain menus and commands are either greyed out or changed such that only standard code is emitted. Redmond has refused to do likewise in its major development tools. Is Shorthorn going to do any better on interoperability ?
6)Finally, there is a mess running along for 4 years and counting since Microsoft introduced the .NET Framework as the tool that was to rid the world of .DLL Hell, the Registry, Memory and other unmanaged code vulnerabilities that impugned Windows reputation in reliability, availability and security. Longhorn was held out as the solution to many of these problems. But as we have just seen, the take up of .NET within Redmond and without has been very slow. So now the question is: will Shorthorn address directly any of these festering problems ?

In sum, the dropping of Longhorn leaves a number of fundamental questions about the attractiveness and viability of Microsoft as a development choice on the table. Just two years ago nobody would have questioned buying an Intel server. Now with emergence of AMD 64 bit from many vendors plus Apple G5 or Sun Solaris with either Opteron or UltraSparc , having Intel-inside may not be the best way to advance your career. Likewise, until Microsoft enunciates how its changes in Longhorn strategy will address some of the fundamental and lingering development issues we have raised above – choosing Microsft may no longer be the “you can never get fired” sure thing.