Estimando el impacto de Windows 8, parte I

Este último mes me he dedicado a recolectar información sobre Windows 8, particularmente después que la conferencia Microsoft Build develara un buen número de características y planes. Inmediatamente se observa que la nueva versión del sistema operativo trae consigo un cambio drástico respecto a los sistemas anteriores. A primera vista el cambio fundamental es el ¿estilo de presentación/técnica de construcción?, que abandona una larga tradición de interacción con las aplicaciones, introduciendo un modo inspirado o destinado al mercado de tabletas táctiles. Sin embargo, yendo un paso adelante, un cambio más importante está por debajo de éste, y es el que posibilita el funcionamiento de su nueva interfaz de usuario (Metro): el nuevo API, WinRT.
Esta nueva API no se comunica con el API Win32, o no al menos muy bien. Dice Tim Anderson (mencionado por Mary-Jo Foley):

Make no mistake: Microsoft has re-invented the Windows API in WinRT. Just to recap, WinRT is the API for Metro-style applications, the touch-centric, app-centric API for tablets and, one presumes, eventually for Windows Phone (though Microsoft has yet to admit it).
WinRT is only useable from Metro applications. You cannot call WinRT from a Win32 application, nor vice versa*. I think it is reasonable to assume that a future version of Windows which runs only WinRT is a possibility; and that Windows 8 on ARM will look a bit like that even though Win32 will still be there, but mainly out of sight; but I am speculating.
Does that mean Win32 is now legacy? In a way, but such a huge legacy that for the moment we should think of Windows 8 as two platforms side by side.

Miguel de Icaza hace una evaluación temprana entusiasta y optimista (WinRT demistified). Sin embargo, de su comentario sobre WinRT y .Net, dejando aparte las ventajas que Miguel elogia, lo que consigue es abrir nuevas áreas de interrogantes acerca de su impacto.
¿Por qué hablo de impacto? Porque Windows 8 no sale en un mercado virgen, sino en uno en el que conviven no menos de dos clases de aplicaciones, las que fueron planeadas pensando en Windows XP y predecesores, y las que fueron, esforzadamente, movidas a Vista/Windows 7, o escritas para este nuevo y, por lo que se ve, fugaz concepto. Ahora podemos decir que no solo cualquier aplicación del nivel XP/anteriores es legacy, sino que también lo serán aquellas creadas para Vista/Windows 7, dado que ambos comparten el API Win32 (Y estoy tratando de evaluar el alcance de los cambios que impacten en .NET...) Sólo por ese hecho, estarán en una categoría inferior, y espero conocer más adelante las consecuencias de performance que puedan acarrear.
Es decir, debemos mirar el movimiento hacia Windows 8 no sólo desde el punto de vista de las novedades y mejoras, sino de todo aquello que condiciona y obliga a replanear. Este es el punto que ahora me interesa fundamentalmente: considerando el patrimonio de aplicaciones en las que trabajo, si me viera obligado a asumir una migración a Windows 8, debería pensar las alternativas: si soportara Metro, lo mínimo que debiera hacer en nuestros patrones sería contemplar una variante que invocara WinRT en lugar de Win32, y asumir el nuevo tipo de eventos que implica Metro. La separación entre la presentación y la lógica "servidora" sería manejable, así como los lenguajes de implementación (Esto vale para cualquier variante de interfaz de usuario). Si no soportara Metro, poco cambiaría o nada, pero los problemas estarían en el ambiente: estaría ejecutando aplicaciones en un ambiente "no preferente".
Finalmente, siempre queda la alternativa simple de desechar la interfaz del sistema cliente, y usar java. ¿cuál se supone que sería la alternativa más rápida y confiable?
¿Cuál supone usted que sería la alternativa que una corporación usaría si tuviera que pensar en la transición de sistema operativo de Microsoft?
Los reclamos de la comunidad de Silverlight pueden ser pálidos reflejos del impacto del cambio generalizado sobre el mundo corporativo. Especialmente si las politicas de actualizaciones de Microsoft comienzan a establecer presión hacia el cambio.