Windows 8, WinRT y la herencia de Win32

Este miércoles pasado ha sido un día especial en la pre campaña de lanzamiento de Windows 8: se ha iniciado su "consumer preview", con presentación especial en el Mobile World Congress de Barcelona, y comentarios simultáneos en toda publicación tecnológica que se precie. Sigue resultándome muy curioso que un producto todavía inmaduro, cuyas prestaciones aún no están completas, sea presentado primero a la comunidad de desarrolladores (esto sí es normal) y luego al público en general, tal como está. Sin embargo, puede decirse en este caso en que existe un cambio muy grande en el producto, que puede ser entendible: medir la respuesta, conocer temprano los fallos más gruesos, delinear un mercado de aplicaciones, entusiasmar al cambio. La actividad de difusión entre desarrolladores y socios de negocios ha sido intensa, y sus principales características son bastante conocidas. Desde hace meses se pueden encontrar evaluaciones, comentarios, ensayos, normalmente favorables a Windows 8, y pocas observaciones críticas. ¿No existen reservas críticas sobre los cambios de magnitud que se avecinan?
Sí existen, pero hubiera preferido ver más distanciamiento y criterio en desarrolladores, actores varios de consultoría  y comercializadores, en cuanto al impacto que Windows 8 pueda llegar a tener sobre el mercado actual de usuarios de empresa. Algo que ahora pudiera llamarse un mercado "legacy" o "tradicional", si comparamos lo que hoy usan, y lo que Windows 8 propone.
Partiendo del hecho de que la arquitectura propuesta (WinRT) es diversa y no integrable con la anterior, todo lo que hoy existe está inicialmente confinado al ámbito de Win32, un ámbito sin prioridad de evolución en cuanto a proyectos, y también al momento de ejecutarse. Usted puede construír una nueva aplicación desde cero para ser expuesta en WinRT (y ser aceptada por la AppStore), y se sentirá muy felíz de aprovechar sus ventajas intrísecas y ser de los primeros en el mercado; o tomar su aplicación ahora "legacy" para siempre, analizarla, reescribir todo lo necesario, y portarla a WinRT; o dejarla como está, y confinarla a Win32, es decir, al "escritorio", que ahora es un contenedor subordinado. Lo que está claro es que existe una verdadera ruptura entre las versiones anteriores y la nueva: usted deberá aprender un nuevo API, y deberá replantear cada aplicación, y olvidarse de lo que conocía. Algún comentarista recomienda reconvertir cada actividad diferenciada en un servicio web, para poder ir adelante en la migración. ¿Ha pensado en rever todas y cada una de sus aplicaciones que no sean Office u otros productos nativos de Microsoft?
¿Ha sido la mejor opción definir una arquitectura orientada a recursos móviles como prioridad casi exclusiva? ¿Se ajusta al mercado corporativo? probablemente sí, en el nicho de actividades de movilidad. Pero seguramente no en la mayoría de actividades diarias, atendidas por las llamadas aplicaciones "de escritorio". Este área difícilmente sacaría ventajas del paradigma Metro. Creo que existe una posibilidad de que se repita la situación dada con Windows Vista: una prolongada resistencia a adoptarlo. Tendrá que esforzarse mucho Microsoft para lograr adopcíon en ese área de su mercado.
Presento a continuación algunos análisis, algunos tempranos (último cuarto del año pasado en adelante) y otros muy recientes. Esto es importante porque, como hemos dicho, Windows 8 ES UN PRODUCTO EN CONSTRUCCIÓN, y algunas dudas tempranas se han disipado (y otras han madurado).

Un análisis positivo se puede leer en los comentarios y ejemplos de Harry Pierson (varios). Dos analistas favorables que de todas maneras exponen la magnitud del problema, son Rockford Lhotka y Miguel de Icaza. Lhotka, por octubre de 2011, presentaba una serie de diagramas que mostraban dónde operaban distintas tecnologías, WinRT o Win32. De estos diagramas queda claro que prácticamente todo lo que hoy ejecutamos cae del lado de Win32: Silverlight, WPF, sitios web con plugins (Today’s web sites that use HTML, js, Flash, Silverlight, ActiveX, and other common web technologies all run in the desktop web browser. This is the same as web sites work today in Win7), c++, MFC, ATL, Windows Forms. Y se ejecutan en WinRT casi exclusivamente tecnologías nuevas construídas por Microsoft para Windows 8: WinRT .NET y XAML (I expect this to be the most widely used technology stack for building WinRT applications. The .NET available to WinRT applications is (I think) best thought of as being like .NET on the Windows Phone. It is basically the Silverlight subset of .NET, plus a bunch of WinRT-specific features and capabilities. The differences between Silverlight and WinRT are a bit more dramatic than with WP7, but the analogy remains quite accurate. The XAML is very close to Silverlight and WPF, and the types of code you can write using C# and VB are very comparable to what you can write today using Silverlight); HTML5, WinRT c++. Excepcionalmente, también se pueden ejecutar en WinRT paginas web que consistan sólo de HTML, CSS y JavaScript (If a web site only uses HTML, CSS, and js, then it can run in the WinRT and desktop browsers interchangeably. Microsoft clearly expects this type of web site to become more common over time, though it is interesting that a large number of existing Microsoft web sites are really only useful in the desktop browser)
Resumiendo sus primeras impresiones, Lhotka dice:

Through this series of diagrams, we clearly show how today’s technologies map directly into the Win8 desktop world, still running on the Win32 API. And we show the three technology stacks that enable development of applications on the new WinRT API.
From everything we know today, it seems clear that migrating to WinRT will require effort, regardless of the technology used today, or in the Win8 desktop. Of all existing technologies, Silverlight and then WPF appear to offer the easiest migration. HTML 5, css, and js skills, along with some code assets will also migrate, but there’s a non-trivial architectural difference between web development and smart client development that shouldn’t be overlooked.

por su parte, Miguel de Icaza estudia detalladamente el nuevo modelo enfocado en .NET, y en su detalle podemos dimensionar la dificultad de readecuación a Windows 8 y su API. El API sigue un modelo asincrónico (Microsoft feels that when a developer is given the choice of a synchronous and an asynchronous API, developers will choose the simplicity of a synchronous API. The result usually works fine on the developer system, but is terrible when used in the wild. With WinRT, Microsoft has followed a simple rule: if an API is expected to take more than 50 milliseconds to run, the API is asynchronous); .NET pasa a estar disponible parcialmente en el nuevo modelo (Some developers are confused as to whether .NET is there or not in the first place, as not all of the .NET APIs are present (File I/O, Sockets), many were moved and others were introduced to integrate with WinRT. When you use C# and VB, you are using the full .NET framework. But they have chosen to expose a smaller subset of the API to developers to push the new vision for Windows 8. And this new vision includes safety/sandboxed systems and asynchronous programming. This is why you do not get direct file system access or socket access and why synchronous APIs that you were used to consuming are not exposed)

Invito a seguir sus observaciones, para ir teniendo una idea de cuánto trabajo deberá afrontar en estas condiciones para adecuarse.

Para no abundar, recomiendo la lectura del resumen de dificultades comentada en Techrepublic por Justin James. De las más importantes mencionadas, el modelo asincrónico, la falta de acceso directo a disco, el uso de pantallas táctiles, el énfasis en la nube. Hay más, pero quizá sea preferible que lo lea directamente.

Esto es sólo un pequeño resumen, para que usted piense y estime los tiempos por venir, y vaya calculando decisiones. Una vez más, sería valorable que desarrolladores, implementadores, consultantes, comercializadores, e influyentes en general, se ocuparan del impacto de la adopción del producto, y no sólo del brillo de las novedades. Tras muchos años de hegemonía, también Microsoft tiene un patrimonio "legacy", y alguien debería recordar que eso significa muchas horas de trabajo, y mucho dinero invertido.