LongGoneHorn Redux II

In the aftermath of August 27s LongGongHorn Redux, it appears that Avalons role has been radically altered – from pivotal leading new UI API which with its own new GDI to tack-on to the old WinAPI. But Macromedias John Dowdell raises the most interesting question – how will Avalons codebase be delivered in the new LongGonerHorn.

I agree explicitly with Johns basic premise – how do you get from the originally envisioned Avalon/Longedhorn there (new OS backbone, new GDI, new XML interface=XAML) to the new here, Avalon as XP addon ? As John rightly conjectures there are some old Avalon=>OS backbone, Avalon=>new LongHorned GDI dependencies and they will have to be replaced. And so the WinAPI will have to expand or conversely features will have to drop out of Avalon. In any case, this is major surgery – and we have not even taken into account the dropping of WinFS and some of its dependencies with Avalon and Indigo.

Why do major surgery ? MS says to meet the 2006 date. I dont think so. This surgery alone will guarantee that 2006 will not be met. Rather I think that MS blinked at being able to convert their userbase to the all new yet almost completely different Longshothorn==Avalon/Indigo/WinFS code base versus sticking with the tried and somewhat true WinAPI. In short, they did not want to get Itaniumed as Intel has all but ceded the 64bit chip computing lead to AMD.

This is the real concern – developers, major users, ISVs simply did not want a major conversion thrust upon them. Intel has found out how resistant to change OEMs and developers were to a brand new Itanium 64bit longword architecture and instruction set. When AMD offered an X86 compatible 64bit architecture – Sun, HP, and IBM jumped on it and only lukewarmly used Itanium. The incremental benefits of Itanium simply are not yet nearly worth the monumental costs of conversion.

Ditto it appears for Long-and-blessedly-goneHorn.

But what is the rival technology to WinAPI ? Well it is Johns Eureka concept, a XAML/XUL/MXML cross platform XML UI definition language able to support multiple if not any UI engine – J2ME, GDI, X-Windows, J2SE, Flash Player, etc. Because really, as Jakob Nielsen implies, users want not identically the same but primarily the same convenience and UI experience on ANY DEVICE. Minimum relearning but also let me take advantage of that devices virtuosities (and developers will welcome the hopefully decreased development requirements). This may be easy to say/describe but obviously it is a bear to decide what needs to be “primarily the same” and then the devilish details of implementing it is one tough cookie. But John is on the right path.

Right now the best ANY DEVICE engines appear to be JSwing for J2ME and Flash Player. The XML side of the equation is wide open. But as of August 27th, 2004 – the race to the new pervasive UI has markedly changed and its anybodies ball game.
——
PS: I promise not to mock the name LongHorn anymore because there are many Microsoft developers who put long hours and effort into its development. But the real villains of the piece are Redmonds Architects and Designers who have originally tasked their developers to produce what I have called the Gates of Longhorn in previous postings. This has been perversely envisioned as a primarily proprietary OS and development environ (proprietary Avalon, WinFS, Indigo backbones) with very strictly controlled data and programmatic interoperability. We have said it before but it bears repeating – the Gates of Longhorn offered little to more-often-none-whatsoever Microsoft native support for many defacto and dejure standards such as Java, CORBA, an increasing number of XML standards, Flash/SWF, OpenGL, etc, etc. Microsofts top management has been guilty of trying to create a proprietary outpost based on their Windows monopoly in a World of Interoperability – for that they and their Gates of LongGongHorn deserve to be mocked.