Longhorn Redux VII

John Udell at InfoWorld writes a quietly scathing critique of Longhorn. He writes ” a few months ago, key Microsoft architects were telling me that it would be impossible to decouple the Avalon presentation subsystem from the Longhorn OS. Now they’re huddling in conference rooms trying to figure out how to do just that.” Now I have also seen these “impossible” pronouncements before from other vendors besides Microsoft; but lets face it readers, Redmond since its DOJ Antitrust days are the umatched peers of “its impossible” stonewalling.

The problem with this approach is that the industry is moving so fast, Redmond can and has painted itself into untenable corners. Jon raises this issue of Avalon and how previously Redmond developers declared that it “would be impossible” to decouple Avalon from the new Longhorn API and ShoeHorn fit it into the WinAPI. But shoehorning Avalon are the new marching orders and that does raise some very fundamental questions. What gets lost in the downsizing/resizing of Longhorn for the WinAPI ? How are two entirely different Graphics DisplayAPIs for Avalon going to be supported in Visual Studio and the .NET framework. Remember .NET is already split into managed and unmanaged code (nudge, nudge, wink, wink, know what I mean, know what I mean about security and reliability). What is going to happen to GUI developers already faced with five different frameworks from WinForms through WebForms to the Compact Framework ? And what the WinHEC is happening with Longhorn device drivers ? Do ISV and developers who chose to go the WinAPI-Avalon rather than the LonghornAPI-Avalon route, do they have to rewrite their device drivers ? Or have device drivers been decoupled from Longhorn and its “damn the torpedoes and full conversion steam ahead” ?

Now its no surprise that Microsoft is trying to procure for itself a Server side monopoly equal in size and profitability as its desktop one. The target has been both enterprise servers and applications, a bookend match to the desktop. Now there is nothing inherently wrong with Microsoft trying to buy SAP or effectively buying out the middle tier of accounting and ERP vendors. Microsoft is trying to get an Office-like grip on basic accounting and business systems in mid-size companies and then leverage that up to Fortune 1000 corporates.

However, there are problems for IT shops when Microsoft starts to tie features in Office and other desktop apps such that they only work with Windows Server 2003 and/or its associated set of Server apps. In effect, Microsoft is saying if you want to get the most out of your Office apps (many of whose customers are locked into with Software Assurance contracts over 2-3 years); you have to buy our Server and its Exchange, SQL Server, Content Management Server, SharePoint Portal Server, and other services. Again nothing overtly wrong, just a bit coercive and mono-cultured.

However, on the interoperability side Microsoft becomes even more restrictive. Microsoft is non-cross platform in almost all its apps from Office to productivity apps to SQL Server. Its development tools refuse to provide native support for many defacto and dejure standards from CORBA through all things Java to Macromedia Flash to SVG. Microsoft also refuses, unlike its competitors, to provide a switch in its development tools and applications that guarantee that these same Microsoft tools only emit standard code. With such a switch customers can easily decide whether they want to go standard or use Redmonds proprietary code. Finally, Microsoft has refued to describe how IE will be developed in Longhorn.

This latter point is important because Microsoft has stopped all improvements other than critical security patches for Internet Explorer since 2001. They have also refused reporters efforts to get further details on what the IE browser will be like in WindowsDesktop 2006 (aka LongShortHorn, etc). In its previous Longhorn pronouncements, Microsoft had said the browser would become a part of the OS. Rumors have abounded of abrowser-capable dialog embedded in Office and a separate WinFS search utility that has some HTTP/browser like support. But with WinFS gone and Office 2006 developers facing the same quandry as ISVs – which Avalon do you develop for: LonghornAPI Avalon or WinAPI Avalon? – and where does Microsoft browsing fit in this new edsktop ?

It is interesting that Jon sees this as a critical question too – he ends his piece on Longhorn with
“It remains an article of faith in Redmond that the Web platform has run out of gas. Do you think there might be some unacknowledged possibilities there as well? I do. “ Now lets be crystal clear on what Jon is doing here. He is in effect teeing up the ball – and allowing Microsoft to define how its going to support what still is the API of choice for developers and corporates alike – the cross platform, high interoperable Web API. Heretofore, Microsoft has chosen to cut off the oxygen to interoperability and the Web API by:
1)closing down all improvements to the IE browser since 2001;
2)refusing to divulge any plans for IE in Longhorn;
3)refusing to deliver a “Stick to Standards” Switch in all its devlopment and generator software;
4)continuing to deliver an obsolete JVM version on the Windows desktop until at least 2007;
5)continuing to ignore many industry standards regardless of numbers of users;
6)embarking on a new campaign of wide patent claims despite calls for a Web patent free zone;
7)saying support for standards and then balking at many or saying ” its ours or else”;
8)building up a web of proprietary and increasingly closed dependency between Windows , Office Apps, Windows Server and other MS Servers ;
Jons being very generous here – he has put no goals, no “good faith” minimum level of interoprability, no critical measures of success on what Redmond will do to support the interoperable Web API. Redmond has huge leeway here to do nothing, mischief, or recognize as in the case of the Internet, its proprietary, “things must run best in Windows because we damn well make it so” is not winning new developers, partners, ISVs, and customers.

Many companies and organizations have deliberately chosen to simplify down to one operating system on the desktop because it was (past tense deliberate here) the lowest cost, most applications, fairly usable and “just good enough”. Since that decision, these same shops have seen Windows still deliver fairly good(though mono-cultured) usability, still the most applications but losing ground to the Web, but some severe tests in the arena of “just good enough” operations – security, reliability, availability and manageability falling increasingly short of the enterprise mark.

Now with Longhorn, Microsoft has flinched a little on the notion that what is good (and proprietary) for Microsoft is good enough for its legions of users. It will be interesting to see now who and where in the IT trade press and media will press Redmond to define whats in the new WindowsDesktop 2006 with some attention to interoperability, the role of IE, and the Web API. Users need more than vague white papers on the “Smart Clients”. Jons left the door wide open. It will be interesting to see what the pundits at BusinessWeekOnline, ComputerWorld, eWeek, Fawcette, ForbesOnline, JupiterMedia, eWeek, Technology Review, Wired, ZiffDavis, and other IT media have to say and demand of Redmond on this critical topic.