El objeto CDO y Office: ¿obsolescencia programada?

 Revisando algún otro asunto (algún fallo ajeno en el uso de MAPI), topé con un anuncio que en particular nos afecta en más de una instalación; digamos que en general puede afectar a cualquier usuario de Plex, pero supongo que su alcance es más amplio, más allá de la estrategia propia de Plex, para cualquier instalación basada en mensajería de Microsoft. El anuncio tampoco es nuevo: refiere a Office 2010: Collaboration Data Objects (CDO) 1.2.1 no es soportado con Outlook 2010 y versiones posteriores. CDO es una librería basada en el modelo COM de Microsoft, accesible por medio de C, C++, VBA, VB, C#, usada ampliamente para el envío de mensajería en sistemas Windows. En el mismo sitio del anuncio CDO es definido como  a client library that provides a thin wrapper over Extended MAPI functionality. This library is typically used to add email messaging functionality to custom programs. This library allows those programs to perform functions such as sending email through MAPI, working with calendars, and accessing various data in Microsoft Outlook or in Microsoft Exchange.

Posiblemente el API de MAPI haya sido intermediado por el uso de CDO ampliamente desde su aparición; bien definido, bien documentado, consistente, capaz de ser invocado desde casi todos los lenguajes ejecutables en Windows, y particularmente desde las propias implementaciones de Microsoft para el lenguaje de propósito especial de Office (VBA).
Sin embargo, a partir de Office 2010, nos encontramos que CDO no es instalado, y es desaconsejado su uso para interactuar con Office a partir de esta versión, debido a cambios de arquitectura en la suite de oficina:  

Microsoft Outlook 2010 and later versions include many architectural changes to the client-side MAPI subsystem. Of particular concern are scenarios in which Outlook is configured to use multiple Exchange accounts. Also, CDO 1.2.1 is a 32-bit client library and will not operate with 64-bit versions of Outlook. Given all these factors, CDO 1.2.1 is not supported for use with Outlook 2010 or Outlook 2013, and we do not recommend its use with Outlook 2010 and later versions.

¿Podemos considerar esta decisión una violación de los principios de arquitectura del modelo COM? Una vez más, el concepto de compatibilidad y continuidad del soporte de Microsoft opta por la vía rápida: se elimina su instalación, se ralea la información y documentación a partir de ahora "legacy", y se recomienda calurosamente el cambio a la nueva versión. Microsoft tiene una solución a su patrimonio de funciones construidas usando CDO:

Programs that use CDO should be re-designed to use other Application Programming Interfaces (APIs) instead of CDO (...) Developers should use the Outlook 2010 and later object model instead of CDO 1.2.1. Also, developers can still use Extended MAPI (which requires unmanaged C++) in some scenarios where CDO was required. However, if it is possible, we generally recommend that the Outlook object model be used instead of Extended MAPI. Microsoft product support can help developer customers migrate custom programs from using CDO 1.2.1 to using other APIs. However, Microsoft will not provide support for any scenarios in which CDO 1.2.1 is used with Outlook 2010 or Outlook 2013. 

Simple, entonces: busque todos los casos en que usara CDO, y rediseñelos para usar el modelo de objeto Office. Justo cuando Microsoft está en transición entre Win32 y WinRT, para descubrir que dentro de un par de años WinRt determina otro modelo de objeto, y, sin más trámite, todo su patrimonio sea discontinuado de nuevo.
Sin duda usted podrá seguir usando CDO, en un marco limitado, recurriendo a modificaciones de la instalación, a condición de cómo administre su instalación de Exchange (vea el punto More information en la página del anuncio de Microsoft). Pero no será soportado, y cada día encontrará menos documentación para arreglárselas por su cuenta. Si lo va a seguir utilizando, tome una medida de precaución: conserve como documento off line todo lo que pueda conseguir todavía de guía de referencia y soporte de Microsoft. Como en muchos casos, pronto encontrará que las (escasas) referencias que se conserven, lo conducirán a páginas muertas. ¿CDO funciona? digamos que sí. Lo que ha cambiado es Office, y la compatibilidad hacia atrás parece que es secundaria: cambie de modelo de API. La mejor explicación acerca de las razones del conflicto de versiones la he encontrado en lo analizado por Matt Stehle, en los MSDN blogs. Matt apunta a la existencia de dos modelos de manejo de memoria: el de MAPI/CDO, y el de .NET, que pueden producir intermitentes problemas de asignación de memoria:

MAPI has its own memory management model that conflicts with and is incompatible with the .NET runtime. This the primary reason that MAPI and CDO 1.21 are not supported running in a .NET process. The common symptoms you will see are seemingly random Access Violations and very often memory leaks (especially with CDO 1.21). There is no methodology for avoiding or managing these symptoms by using interop libraries or managing references in a particular fashion in your .NET code – it just won't work.
The trap is that CDO 1.21 and .NET can "appear" to work and you can get pretty far in your dev cycle before you run into problems. Many times we see this come up in soon after a solution is released to production, in late cycle performance testing, or in a pilot program. Opening a critical case with Microsoft when you have end users complaining of crashes or project managers short on budget is not a good time to find out that your solution is unsupportable.

Matt se extiende sobre el alcance de éste conflicto, reconociendo que realmente sólo a partir de Office 2007 existen mejores reemplazos de CDO, y que por lo demás, ambos serán excluyentes (The simple answer is you either need to not use .NET or not use MAPI or CDO 1.21). Puede leer la nota completa de Matt en su blog. No se arrepentirá, especialmente si sigue la acotación que apunta Matt a lo que Patrick Reehan dice acerca de qué significa "no soportado" para Microsoft.

En nuestro caso, el impacto sería reducido (por otra parte en ningún caso los servidores de Exchange han provocado conflictos todavía), porque CDO/MAPI están sumamente encapsulados, y no conviven procesos .NET con CDO. Todo nuestro manejo de mensajería pasa por un solo objeto, y las interfases entre un modelo y este objeto son exclusivamente de datos, sin ningún condicionamiento técnico. Bastará con redefinir las actuales llamadas, adecuándolas a los nuevos requerimientos, y recompilarlo y distribuirlo. No hará falta tocar nada más. ¿Pero esto es así en todos los casos? seguramente no, y probablemente en muchas empresas habrá (o hubo) trabajo inesperado.

A propósito de una API de c++

Hace algunos días me pidieron que estudiara alguna manera de validar que una fotografía cumplía con ciertos requisitos de densidad y medida en pixeles: un requerimiento simple, que exige acceder a metadatos de la imagen. Desde el punto de vista de nuestros modelos de Plex, esto significa usar un API, ya que no existen dentro del conjunto de funciones propias del producto, ni tampoco en ninguno de sus patrones de tecnología, alguna función preelaborada que permita obtener esa información.
Un API es un trozo de código específico de una plataforma que funciona encapsulado: en su interior resuelve una necesidad específica, en este caso, tratar metadatos de una imagen, intercambiando información con el modelo a través de parámetros. Así, el modelo se mantiene a nivel abstracto, y se relaciona con código específico de plataforma a través de un marco de inicialización que resuelve la relación entre el nivel del modelo y el del código encapsulado. El marco de las APIs que Plex maneja es relativo a plataformas específicas: c++ para clientes Windows de código no administrado (en términos del marco .NET) u ODBC, un motor de VBscript incrustado para VBscript, c# para  .NET, y java o RPG para las variantes respectivas. Ya hace tiempo existe en la comunidad de Plex el estilo de definir un API de tal forma que responda a múltiples plataformas, por medio de metaoperaciones, que permitan intercambiar los parámetros entre el modelo y el código encapsulado, que será uno distinto por variante, y se resolverá en tiempo de compìlación según metaoperaciones que interroguen al modelo acerca de qué lenguaje se ha configurado. De esta forma, un sólo objeto API permite representar en un modelo su solución para tantas variantes como sea necesario y posible.
¿Estas son las únicas variantes posibles? Aunque hasta donde conozco, nadie lo ha intentado, existe una posibilidad de "sobrecargar" Plex para agregar APIs de otra plataforma o lenguaje: Plex sigue el modelo .COM, y permite importar un componente, y utilizar sus métodos y variables públicas como parte del modelo. Es entonces posible añadir transformaciones que habiliten otra variante, al menos al nivel puntual de una API. Utilizando elementos similares por otra vía, Websydian primero, y Webclient después, permitieron agregar capas de arquitectura web completas a un modelo de Plex.

Pero ahora, volviendo al pedido de lectura de metadatos de imágenes...Primero, restringimos el alcance del API a una aplicada a un modelo WinC, es decir, uno de plataforma Windows de modelo Win32, al menos para su primera versión: el horizonte de aplicación abarca por lo menos los próximos tres años. No está claro si en el futuro la aplicación continuará sobre Windows o Java, y en el primer caso, si sobre Win32 o WinRT. Digamos de todas formas que WinRT todavía no está soportado sobre Plex, lo que estrechaba el marco de posibilidades. Ahora bien, ¿qué alternativas hay disponibles para trabajar con imagenes escritas en c++ o c? En una primera revisión, encontré varias alternativas; Adobe XMP Toolkit, ExifTool (en modo de línea de comandos), Exiv2, y especialmente el Windows Imaging Component, o el objeto PropertyItem (en System.Drawing.Imaging Namespace) , ambos de Microsoft. Con algo de entusiasmo, comencé pesando las posibilidades de estas dos alternativas de Microsoft. Trabajando con Visual Studio y sobre una plataforma Windows ¿qué alternativa más "natural" puede considerarse que la del propietario de la plataforma? Sin embargo, luego de revisar la documentación (algo escasa en general), encuentré su uso demasiado exigente para el caso que debíamos atender: En primer lugar, la clase PropertyItem parecía más simple y directa de usar (a pesar de que tampoco estamos hablando de pocas líneas de código), pero aparecieron un par de observaciones (1, 2) que es necesario tener en cuenta, sin hablar de las posibles dependencias de versión del framework .NET. En el caso de WIC, examinando la documentación claramente marchabamos a matar moscas a cañonazos. Tanto por la complejidad relativa al objetivo a resolver, como también por la ambigua situación de evolución y deriva de .NET, Win32 y WinRT,decidí volver a evaluar otras opciones de código abierto, y finalmente adopté Exiv2, pero aún de una manera más simple: no recurriendo a la librería c++, sino usando el comando de consola exiv2, que permite acceder a la mayoría de los estándares de metadata...sin necesidad de asegurarse de que estén instalados los codecs adecuados...
En fin, resuelta la estrategia, en un par de días cerramos el problema con un código simple, reducido, y fácilmente ampliable a la obtención de otros atributos. En una situación de transición de la plataforma de Windows como la actual, es preferible quedar libre de dependencias y compromisos, si es posible. En tanto, ActiveX, VBA, VB for Office, c++ y en alguna medida .NET y .COM, atraviesan la borrosa frontera entre Win32, WinRT y otras alternativas que puedan sumarse a "un solo Windows"...

Prisionero en el Metro...

Metro, Windows 8, o como quiera que finalmente se llame, innegablemente fue hecho para dispositivos móviles, para entrar con fuerza en un mercado mucho mayor que el de escritorio (¿centenas de millones de unidades contra millones?), pero probablemente, también con pocas dudas, a expensas del mercado de escritorio, especialmente el empresario. Se ha comentado esto aquí otras veces, pero quizá el comentario de Tad Anderson sea más claro:

Windows 8 runs best on my MacBook Pro

I have had a version of Windows 8 running since the first day the Developer Preview was available for download. I did so out of necessity, not because the techie in me wanted to. The techie in me that has spent the last 10 years exclusively in Microsoft's world wants nothing more than my freedom from the Microsoft Empire.

That will not be happening anytime soon since they own me and every enterprise I work with. I therefore have no choice but to keep learning the Microsoft platform as new releases and tools come out.

Windows 8 RTM is no less annoying to me than the first time I downloaded it. I still don't run it on bare metal and do not plan to. I have found several ways to make it less painful. I do not use the Metro crap ribbon at all. As soon as it loads I hit the desktop.

The biggest trick I have found to make it the least annoying so far is to run it in Parallels Desktop 8 for Mac on my MacBook Pro. The main reason for that is I get my start menu back. (...)
Up until the RTM came out I ran Windows 8 in VMware on my Alienware M18X. I installed the RTM on it but moved all my development to my Mac and haven't opened it on my Alienware since. Not having to deal with that annoying Metro banned of squares is great!!! Sorry about all the Metro references, but that is the only name I know to describe the ugly in Windows 8 on the desktop.

Another plus is that on the MacBook the touch pad allows me to pinch and do a ton of other gestures that aren't available on windows pads. The Magic Mouse also works great with it.

If you are an enterprise user or developer, Microsoft owns you, your sole, your desktop, your servers, and especially your check. They don’t care if they have to throw us under the bus, because they own us. To get a non-enterprise and non-developer customer base they are willing to burn us for the next 3-4 years. We have nowhere else to go and they know it. So yes I will be learning Metro development (or whatever they are calling it now).

On tablets and phones it isn't a bad environment since that customer base is what it is made for. On the desktop it is a joke, and no one but partners who are being force to upgrade are giving it any thought.

I believe they will come around and provide a decent development environment again in 3-4 years, but the bad news is, this will happen again with them. They are followers not leaders, they are imitators not innovators. In 3-4 years they will have missed another bus and it will be catch up time again. The baby will be tossed out with the bath water and we will be starting over…. again.

Anyway...  If you own a Mac and you need to run Windows 8, ironically your best bet is to run it on your Mac environment.

Otro enfoque crítico sobre Windows 8

A las diversas razones que exponen distintos analistas acerca de los problemas críticos que podría experimentar Windows 8, Tim Worstall agrega otro: Windows Metro exige que los viejos usuarios de Windows deban aprender una nueva manera de relacionarse con su sistema operativo. Si se debe aprender algo nuevo, pudiera ser que se optara por algo con un costo menor o directamente gratuito:

Yes, it looks like a good enough tablet operating system. And it’s also quite fine as a desktop operating system. But there’s a problem with the way in which every user now has to learn to use the operating system all over again. And what should worry Redmond a great deal more than some journo like me remarking upon this is the way that at least one fund manager has sold his stock in the company as a result of his confusion over their plans.
(...) The essential point is that at the heart of the Microsoft value equation is their near lock on desktop operating systems.
Even if we all stopped writing new code for Windows (as, to some extent is true, we have done, much writing is now being done in Python and so on which is not platform or OS specific) right now then there are vast numbers of legacy systems out there that will continue to require Windows licenses for decades to come.

But Windows 8 asks everyone to relearn how they interact with a computer. Yes, there’s still that legacy systems tailwind helping the company. But if everyone now has to learn a new OS then why would everyone learn the new Windows? The very change they’re bringing in means that people will be open to changing to a non-Windows platform.

I could argue this from an entirely personal perspective. Sure, I use a computer as the essential tool for making my daily bread and butter. I use Windows simply because that’s what every cheap computer on the market comes pre-loaded with. Plus I’ve near 20 years experience of using one form of Windows or another (no, really, I had Windows 1.0 at one point). But I don’t actually use “Windows” if you see what I mean. I use something that opens a word processor, I use something that will allow a browser to run. And that really is about it. I’m sure my experience of computing is similar to the vast majority of people out there too. We’re no more interested in which OS we use than which spark plugs are in our car’s engine. As long as it works then we’re happy.

Which is the danger of presenting us with an entirely new way (the Metro interface which pretty much insists that you access as if you’re on a tablet) of interacting with the computer. If we’ve got to learn all this new stuff well, why not go off and use some other OS that doesn’t force us to do so? Or one that we don’t have to pay for?

It’s entirely possible even that Metro, the tablet interface, really is a better and more intuitive method of interfacing with a computer. But who cares? Maybe changing where the pedals on a car are is a really good idea too. But can you imagine trying to bring in such a change while still keeping your market share?

 Windows 8 consiste en una paradoja: En su mercado consolidado, el escritorio, Windows 8 no solo no agregará más nada sustancial (Win32), sino que lo considerará "legacy", con todo lo que ello implica. Y sus novedades, su nueva visión (WinRT), las pondrá en un mercado, el móvil, en el que  tiene un peso prácticamente nulo, y donde debe hacerse un lugar entre dos grandes competidores. Una apuesta al filo de la navaja.

Win 8/Metro, en su camino

Microsoft acaba de anunciar su tablet, que a simple vista confirma dos hechos, uno muy obvio, y otro, su consecuencia o "daño colateral". Lo primero, que el objetivo de Windows 8/WinRT/Metro es competir por una posición hegemónica en el mercado de dispositivos móviles, por delante de su preocupación por el mercado de computadores de escritorio (de servidores, ni hablar). Lo segundo, la manifestación visible de la dualidad a la que Microsoft se ve sometida: habrá dos entregas de tablets: una con "Windows 8" (Win32), y otra con "Metro" (WinRT); más aún, el tablet vendrá con un teclado flexible, apareciendo en las presentaciones "como si" fuera un portable ultrafino: ¿todo el mercado a mano? No tanto en la opinión de algunos críticos, al menos. Jason Perlow o Steven J. Vaughan-Nichols en ZDNet, Dave Thier en Forbes. El más extenso, Perlow, que no solo nota los problemas de la dualidad de oferta, sino también lo inconveniente que resulta que Microsoft salga a competir con su universo de socios fabricantes:

(...) The Surface tablets in and of themselves look like nice devices. Beautiful construction, decent specs. But absolutely nothing was said about price or availability. Only that the Windows RT/ARM version will ship around the Windows 8 retail release timeframe (October) and the Pro/Intel version will ship 3 months after that.
To quote Microsoft, “suggested retail pricing will be announced closer to availability and is expected to be competitive with a comparable ARM tablet or Intel Ultrabook-class PC. OEMs will have cost and feature parity on Windows 8 and Windows RT.”
So let me get this straight, Microsoft. You made journalists schlep across the country, no, the planet, for a product that might not ship for months? You’re lucky they didn’t burn the venue down.
Okay, no ship date, no prices and… no compelling 3rd-party applications or even Office to show on it whatsoever. So we have no idea how well it performs, and how well supported it will be by 3rd-party software developers. No partnerships to speak of. Nada.

No demonstration or even any claims of how good the battery life on each model is.

Nothing to say whatsoever about the nature of what display technology they are using, whether it is OLED or LED/LCD backlight or something else. Great, so one is a 720p and the other is a 1080p. Details, please.

Gee, that doesn’t exactly make folks want to stop in their tracks from buying iPad 3s, does it?
(...) Okay. Back to the the dual-architectures thing. They decided to launch a tablet product with their own brand, but bifurcate the message? Which one are we really supposed to buy, then? ARM for consumers? x86 for prosumers and enterprises?
And oh yeah. That niggling little OEM thing.
Does that mean that a “Surface” branded Microsoft tablet is bloatware free? Why should we as consumers buy an OEM device now, if the Microsoft is going to be the “Pure” Windows 8 experience, a la Google’s Nexus, and will be “price competitive” with the OEMs?

(...) And if the Pro version of the Surface is powerful enough, with Intel Core i5 Ivy Bridge CPUs, why do we need Ultrabooks if we can just clamp a keyboard cover to a Surface Pro?
Am I the only person who beleives this thing is a total jump the shark cluster-you-know-what for Microsoft?
Right now, Microsoft’s OEMs — with the exception of whatever “lucky” company got the nod to do the contract manufacturing for this product — must be absolutely livid. To produce their own ARM and x86 Windows 8 systems, they have to pay exorbitant licensing fees.
Windows RT is going to cost an estimated $85 per copy to your average OEM. A Windows 8 Professional license on x86 will be considerably more.

I don’t care what the hell Microsoft says about partners having cost and feature parity, that’s $85 of pure margin advantage that Microsoft has and the OEM doesn’t.

But since Microsoft now produces its own hardware, that $85-$150 per copy the OEM would otherwise have to pay is pure profit which gives them an unfair advantage.

And wait until we start seeing the BOMs for Surface added up by companies like iFixit and see how much cheaper Microsoft can go than the OEMs with their own competing Windows 8 tablets when manipulating the supply chain as well.

What are the OEMs supposed to do? Well I suspect that if you are someone like a Lenovo or a Hewlett-Packard, you probably are seriously going to re-think whether or not you really want to produce tablets with similar specs to the Surface RT and Surface Pro.

You now have to out-value the Surface devices, or you have to play the Enterprise game with beefier, more expensive Windows 8 convertible tablets with higher-res screens and faster CPUs and SSDs that nobody other than select Fortune 500 firms may want to buy, because they’d rather do business with a hardware partner they already buy systems from.
And the Ultrabook concept may no longer be sexy to the majority of its target market anymore. Intel can’t be particularly crazy about that.
And the Asus and Acers of the world? How are they going to compete on margins with this thing, unless they are being chosen as the actual contract manufacturers? Something tells me that the bulk of the contract biz on the Surface is going to end up with Foxconn, Quanta and Samsung, not these folks.
Personally, if I was Steve Ballmer and the bigwigs at Microsoft, I would have done it a bit differently.
“Surface” as a brand name actually is pretty good. It sounds futuristic and new. So why just not make “Surface Tablet” the brand name for all convertible Windows 8 tablets? Or have Surface replace “Windows” as the name of the OS going forward?
Why not give the OEMs access to the manufacturing technology for the special “VaporMG” casings and the keyboard cover? Why create such a potentially hostile situation by biting the hand of the companies that license your software which is currently your bread and butter income stream?
What, you really want them to start pushing Ubuntu and Android and other Post-PC solutions for real now? Because now you just asked them to.
All of this reeks of suicidal thinking from a company that wants to deep six its long-established manufacturer ecosystem.
It does not reflect the actions of a company that tried so hard to shed long-held industry perceptions of being a monopolist, and worst case, it could potentially re-ignite federal antitrust activity that Microsoft has spent more than ten years digging itself out of.
Yeah, I’m cranky. But I’m not crazy.
Will Surface result in untenable, stressed relationships with Microsoft’s traditional OEM partners and Intel, and a renewal of its status as industry monopolist? Talk Back and Let Me Know.

¿Windows 8 en el filo de una navaja?

Por primera vez, leo en un comentarista la posibilidad de que Windows 8 pudiera convertirse en una falla catastrófica de Microsoft. En realidad, una relectura de la gran cantidad de información publicada en los últimos días muestra signos no muy tranquilizadores. El más reciente, la campaña algo acuciante en busca de desarrolladores y empresas que soporten Metro y Windows Phone 7 y 8, en sus aplicaciones y lenguajes, y la continuada ratificación de la limitación o extinción de soporte de .NET y Silverlight, respectivamente. Por largo tiempo, se percibía que la irrupción masiva de dispositivos móviles representaba una amenaza cierta a la hegemonía de mercado de Microsoft. Si Metro era la respuesta de la empresa a este desafío, hoy da la impresión de que pudiera ser un fiasco mayor, que comprometa su posición en todos los frentes. Pareciera que fue lanzado sin abrir suficientemente su arquitectura a proveedores y socios de negocios, de tal forma que hoy pudiera no contar con suficientemente respaldo de quienes deberían soportarlo. Así sucede aparentemente en el mercado de ARM. Dice Patrick Moorhead en Forbes:

As we head toward the availability of Windows 8 in Q4, the amount of information available about X86-based platforms dwarfs that of ARM-based platforms from NVIDIA, Qualcomm, and Texas Instruments.  One example is the Consumer Preview (CP).  The Windows 8 CP on X86 (Intel/AMD) was and still is openly available for any consumer on the planet to try, without exaggeration.  In contrast, there’s Windows 8 on ARM (WOA) where, without an NDA, no one can even touch a system.  There can be a few reasons for that, including secrecy, the unique ARM software images required, it just isn’t ready yet, or a combination of all.  With approximately six months until launch, is Microsoft ready for Windows 8 on ARM? (...) Microsoft has written a lot about this on their Building Windows 8 blog, but the questions still remain on specificity.  Specifically which hardware peripherals work well, which ones work but without all features and which ones just don’t work.  This means USB printers, webcams, scanners, digital cameras, SD-cards, game controllers, displays, headsets, speakers, etc.  Sure, drivers are being written now and will be updated well after launch, but without anything definitive, what are OEMs and channel partners to plan?  The channel needs to prepare appropriately with the right peripherals that are compatible with WOA systems. (...) We’re six months from launch and channel partners and OEMs should know this already to prepare for the holidays.

Más aún, está claro que Windows 8 no será compatible hacia atrás para ARM: <<For some it may be an obvious thing to state, but Windows 8 on ARM will be a completely blank canvas with no compatibility mode for any software running on previous x86 versions of Windows. If a developer wants an older app to run on Windows 8 ARM, they need to develop a new version specifically for the platform>>
Mary Jo Folley escribe el 3 de abril acerca de la llamada de Microsoft a escribir aplicaciones y adaptar lenguajes a WinRT, destacando que <<Microsoft officials have been encouraging developers to consider HTML5/JavaScript and C++ when writing new Metro-style apps. However, as Development and Platform Evangelist (DPE) Jerry Nixon recently noted, it’s the managed languages and .Net that seem to be where most of the Windows 8 developer interest is — at least when measured in terms of developer questions and comments on the MSDN forums (...) I guess it shouldn’t be too surprising, however, that devs prefer using what they already know>>. La propia comunidad de desarrolladores de Microsoft se encuentra desorientada, y probablemente defraudada, sometida a un cambio no esperado, y sometida a la presión de la obsolescencia de todo su desarrollo previo.
 En fin, estos son algunos elementos de los últimos días que marchan en una dirección concurrente. Bajo estos antecedentes, Adrian Kingsley-Hughes, agrega el problema del hardware, para componer un escenario más que complicado para Microsoft:

ZDNet’s Mary Jo Foley wonders when are we going to start seeing ‘reimagined’ hardware that will make using the touch-centric Windows 8 less painful and more compelling.

“The problem is,” writes Foley, “without these next-gen PCs and tablets, it’s hard for me - and I’d think others, too - to really grok how Windows 8 is going to work from running it on PCs and tablets that were designed for a non-touch-centric operating system like Windows 7.”

Yeah, that is a bit of a problem. Especially given that we’re probably six months or so away from Windows 8 being released. So, where is all this cool new hardware?

Don’t hold your breath for it just yet.
We can be certain of one thing. There will be Windows 8-specific hardware, in the form of tablets, ultrabooks and touch-enabled PCs, available at the launch of the operating system. The problem isn’t going to be the availability of hardware, but the price point of the hardware.
Touch adds dollars to a system — especially to the price of a PC, where the market hit rock bottom a long time ago — and it is adding cost at a time when both consumer and enterprise buyers are most sensitive to price. To make matters worse, OEMs currently have no idea how the mass market will react to Windows 8. It could flop like Vista, in which case demand for touch-enabled hardware is going to be very soggy and OEMs will be left struggling to offload hardware. Alternatively, it could be a runaway success like Windows 7 was, in which case it will be harvest time for the OEMs.
Problem is, failure is still very much an option, and the idea of Windows 8 being a catastrophic failure is a massive turn-off for hardware makers; doubly so when they are expected to pour significant capital into design, development and production of Windows 8-specific systems. Failures of devices such as Motorola’s Xoom and RIM’s PlayBook are still on the minds of all OEMs.
Another problem is the incumbent desktop and notebook PC. While Microsoft is undoubtedly embracing touch computing with both hands, we’re still not sure what the game-plan is here. Microsoft has made a lot of noises about how touch is the future because it is better and easier to use, but many others and I still remain unconvinced.
The keyboard and mouse are far too entrenched in computing to be swiped away overnight. I firmly expect that the majority of systems that will ship with Windows 8 over the new operating system’s lifespan will be traditional, non-touch systems featuring keyboards and mice, and the OEMs must also suspect this.
Then there are Windows 8 tablets. It’s here I feel that Microsoft’s new operating system will shine the brightest, but it’s still far too early to say that there’s any guarantee of success. The biggest problem facing OEMs here is that they have to deliver a product that competes favorably with the iPad when it comes to a number of metrics - form factor, weight, battery life and, probably most significant of the lot, price.
If the OEMs can’t get all their ducks in a row here, it could be a bloodbath.
Why are we not seeing some OEMs take a leap of faith now and start releasing touch-enabled hardware powered by Windows 7 in advance of Windows 8? Simple. That would be a bloodbath too. Windows 7 is an appalling choice for touch-enabled hardware. This means that OEMs don’t really have the option of shipping touch-enabled hardware now with the promise of a free upgrade down the line to Windows 8.
Windows 8 will reimagine hardware, just not that much. There will be touch-enabled systems available, but they will command a premium price and appeal to a niche market. The traditional desktop and notebook will continue to be the main platform for Windows 8. There will also be Windows 8-powered tablets, but it remains to be seen just how well these will stack up against the iPad.
Uncertain times lay ahead for the OEMs.

 En estas condiciones, consultoras y empresas planeando su estrategia futura, deberían ser muy prudentes en sus movimientos.

Windows Metro y sus clientes corporativos

Acabo de ver una presentación sobre la evolución del mercado de aplicaciones móviles, que muestra una tendencia abrumadoramente inclinada hacia el crecimiento de la venta de recursos móviles (tablets y teléfonos) en perjuicio de un mercado estancado de computadores de escritorio. Ninguna novedad, así como tampoco lo es que el contenido de las aplicaciones varía radicalmente del que poblaba los PCs de escritorio. Se trata de una verdadera explosión del alcance de las aplicaciones, que escalan al uso diario de cientos o miles de millones de personas. El hecho es que la computación corporativa o de negocios pasa a ser una fracción relativamente estable del mercado total, y, comparativamente, con un crecimiento mucho menor que el resto. Esta es, a mi juicio, la razón que explica el estilo del nuevo Windows 8: salir a luchar por una porción dominante en el mercado de móviles. ¿Estará a tiempo todavía, o estará condenado a compartir una porción dividida con la competencia ya suficientemente establecida? ¿Podría haber sido más adecuado, a partir de un núcleo común, desarrollar dos líneas de producto que respetaran las diferencias de estos dos mundos?
El problema está en el universo corporativo: ¿contempla Windows 8 genuinamente este mercado? Por ahora, por lo que veo, no: Fundamentalmente, lo único que se ha destinado a este mundo es Win32, al que se ha declarado obsoleto. Todas las herramientas y lenguajes disponibles apuntan a soportar lo nuevo, básicamente pensado para dispositivos móviles, poco aptos para el trabajo de escritorio. Ni siquiera, al menos por ahora, es posible arrancar una estación Win 8 en modo "tradicional": usted debe iniciar en Metro, y luego cambiar manualmente de modo: se avecina una pesadilla para todos los administradores de servicios de escritorio que tengan scripts de inicio de sistema...Microsoft desprecia las grandes diferencias que existen entre una estación de trabajo y un aparato de comunicación móvil.
¿Será esta la versión final corporativa? Creo que todavía habrá importantes cambios, y, quizá veamos todavía, en "el Service Pack 2", algo más próximo a lo que este mercado requiere. Entretanto, haga sus cálculos financieros para solventar el cambio, o estaciónese en Windows 7.
Mary-Jo Foley comentaba hace poco lo incómodo del nuevo panorama:

While many love the tiled Metro start screen and are looking forward to using it on touch tablets and PCs, many others aren’t keen on it — especially business users who are convinced that Metro will be nothing but a nuisance, especially on non-touch-enabled hardware, and that they’ll do most of their work in the Desktop app on Windows 8.
Paul Thurrott of Windows SuperSite told me a while back that he believed Microsoft would allow users to get around Metro using a group-policy setting, but when I ran that past my contacts at Microsoft, I was told this would likely not be the case. So in the end, it looks like So who knows at this point whether business users who don’t want Metro may get their wish, after all.
(...)
The other big looming question that many business users want more information about is what they will and won’t be able to do when it comes to managing their Windows 8 on ARM (WOA) tablets and PCs.
Microsoft posted a document for download on February 29 (not sure if intentionally or not) that outlined Consumer Preview features for business users. In that document, Microsoft corroborated word that WOA tablets won’t be able to join an Active Directory domain. Some sites have reported that the document also said that Microsoft wouldn’t allow WOA tablets to be managed at all using Microsoft’s own management tools.
(...)
Charles Fitzgerald, a former Microsoft exec now working at VMWare, noted that the domain join limitation means Microsoft won’t be able to one-up the iPad on this front. (And lack of manageability was one of the themes that Microsoft has advised its salesforce to use in selling agains the iPad in businesses.) From Fitzgerald’s March 1 post:

Lack of domain join “means Windows 8 ARM tablets are going to be consumer devices that don’t integrate with the Microsoft enterprise infrastructure any better than the iPad, so Microsoft loses what should have been a major selling point. You will have to sacrifice battery life and go with x86 to get enterprise features and manageability. This is a big blow to Microsoft’s tablet proposition for the enterprise and WOA may be DOA as a result.

Foley todavía dejaba lugar en su comentario a las novedades que la participación de Microsoft en CeBIT pudiera tener para mejorar este panorama. Hasta donde se puede ver, no ha habido cambios notables.

Java y Metro/WinRT

Windows 8, en su versión orientada a futuro, es Metro/WinRT. Francamente, no sé si Metro será un nuevo Vista, condenado a ser cambiado a una nueva versión tras ser descartado masivamente; sin embargo, creo que está claro que este será el nuevo sistema operativo de Microsoft, con mayores o menores parches o variaciones, después de un mayor o menor paso de tiempo. Y también está claro que el API de Win32 tiene sus años contados, que será considerado "legacy", y que no se deben esperar mejoras futuras sobre él. En estas condiciones, que creo que son irreversibles desde el punto de vista de Microsoft, WinRT debe ser considerado como el futuro del mercado Windows dependiente.
Si esta premisa es cierta, la pregunta siguiente es acerca del universo de productos, lenguajes o herramientas construídas sobre y para esta plataforma: seguramente, algunas que ya hoy han quedado obsoletas, o cambiarán radicalmente, o deberán repensar una tecnología que las suplante, como sería el caso de Flash. Otras, las más, enfrentan un camino complicado. Particularmente, en este momento pienso en Java; no sé si tendrá sentido crear una máquina virtual pensando en Metro como interfaz de usuario (tiles, pantalla táctil), que pudiera quedar a futuro como algo más asociado al usuario final, a tablets, a dispositivos móviles en general. Pero seguramente sí debe comprobarse que una máquina virtual puede ejecutarse sobre WinRT. No he visto todavía ningún pronunciamiento de Oracle ni de otros responsables del estándar, y probablemente pase algún tiempo antes de que haya alguno; habrá problemas de políticas (qué excelente momento para cerrar Windows a la competencia...), antes de resolver cómo enlazar la máquina virtual. por ahora, solo es posible encontrar algunos sencillos intentos de ejecutar java, algunos logrados, pero doy por entendido que estos casos lo han hecho sobre el escritorio (Win32). La siguiente es una pequeña lista de  casos en este sentido:
Ejecutando Java en DOS, claramente sobre Win32,
Lo mismo, en una edición temprana.
Un intento de  instalar Eclipse.
Un intento algo inadvertido, quizá sobre Metro, pero que cae hacia Win32.
Un intento con muchos problemas.

Sin embargo, lo más sustancioso está en otros casos tempranos enfocando Metro/WinRt. Particularmente uno en Google Groups (The Java Posse), discutiendo los problemas de arquitectura (aunque para nada hay que despreciar otro argumento discutido allí: "The real reason is Microsoft pathetically trying to exclude competitors and competing technologies, trying to impose HTML5 for everything"):

So it seems that Windows 8's new "Metro" user environment will make IE plugin-free. Any attempt to use plugins like Flash, Java, Silverlight or anything else, will bring the user to the "old-style" (as in  Windows 7) desktop, which will be seen as a severe experience degradation for users who prefer the new environment.

I am not as much plugin-hater as some people; in my Android smartphone, I certainly appreciate the support for Flash, for simple practical purposes - the rare website that uses some Flash and has no mobile-optimized version or native Android app. And yeah, my karma be damned but Flash works well enough  for me (admittedly on a nice hardware - Tegra2, dual-core Droid X2, rooted & debloated, Flash updated to 10.3).

Still, I love the idea of a plugin-free world, if only for the security improvement. (Including avoidance of trash like "security plugins" mandated by online banking sites...) But this is not really fair if we consider modern browsers that run plugins in separate and low-privilege processes, plus enhanced plugin technology like Google's (Pepper and NaCl / PNaCl), plus plugins for runtimes that are managed and have their own sandboxing and security mechanisms and are sufficiently well patched (candidates: Java, Flash, Silverlight - yes none of them are perfect, they all add some to the attack surface, but the ever-growing browser is already a huge attack surface, there's no single week going without new security bugs being found in every major browser so I don't think the "three big" plugins would make things significantly worse).

There's already people betting that Microsoft will have to back away and maybe, put an option to allow plugins in Metro mode even if not active by default. I know for sure, that corporations are writing new apps with things like Flash, by the thousands. Everybody complains that the corporate world is still dragging its feet with old versions of IE, remarkably the much reviled IE6; but if you think that ActiveX code for IE6 is holding back the web, this is nothing compared to how much stuff depends on Flash. A plugin-free IE10+ will be adopted in corporate world by 2020 with some optimism...

What about the applet tag? This is not part of HTML5 anymore, but it's part of previous versions even if deprecated. This should give Java applets special privileges, at least if Metro-mode-IE will support pre-HTML5 markup (and sure as hell it must, for a long time still). I'm too lazy to install the Win8 beta just to check this, would anybody report if applet [tag] works in Metro/IE? Just curious, I guess it doesn't...

Even in HTML5, there's the [object] tag which is supported and not even deprecated. Will Microsoft break the spec and declare that this feature of HTML5 is not supported in Metro mode? What about Java WebStart, maybe the deployment toolkit can be adapted to detect Metro and not depend on [object], I guess the only fundamental need is the ability to download a JNLP file and launch the associated program? Will Metro restrict such launching too? Both Oracle and Adobe are working on their Plan B for the eventual dominance of HTML5, with new tooling that convert their stuff in plain HTML5. In Oracle's case, there is hope for JavaFX 2.0 if its Web Runtime turns out to be good (it's not yet included in the public beta so I have no idea). There is no similar hope though for old-style, AWT/Swing applets or JAWS apps that will not benefit from a similar Web Runtime.

By the way, the JavaFX Web Runtime (WRT) will be a very interesting test for the claim that Javascript & HTML5 can be fast enough and powerful enough to build any application, competing at least with Java/Silverlight/Flash if not with native apps. Summarizing, the WRT will have a pure-web implementation of the JavaFX frameworks (animation, controls, graphics etc.), I guess using canvas or WebGL and Javascript; and the application code will be (perhaps partially) converted to Javascript code. So, supposing that this WRT is well designed and implemented - and that's a core part of the v2.0 reboot plan so I guess they carefully redesigned the whole thing to make the WRT possible - then if it turns out to be much less efficient than the conventional runtime, this will be strong evidence that the mantra "HTML5/Javascript is fast enough" is bullshit. Let's wait and see.

In another interesting development, Google's technologies like PNaCl and Dart can be powerful enablers for anything that generates Javascript code, from GWT to Adobe's and Oracle's  tools. Dart is supposed to be much more efficient than Javascript, and also, the Java language will probably be much
closer to Dart than it is to Javascript (less sure about AS3...); and I'm sure Oracle and Adobe can write new compilers that emit Dart code instead of Javascript code. Or even, PNaCl code. So if these Google technologies succeed, they can benefit other platforms too. We will still be able to run other browsers in Win8. 

Otra interesante apertura es la expuesta en Iced in code:

The big question now is where does JavaSE fit in all this bold re-imagining? Oracle/Sun have done a great deal of work over the past few years to get Java to work pretty well on Windows and become as natively integrated as possible, but with the re-working of Windows, Java will be confined to the “legacy” application section for the time being, and will not be able to play with the new cool kids in the “Metroverse”. I wonder what steps Oracle  is going to take to make Java still a viable product in the new Windows 8 platform, or will they simple give up and require us all to move to platform specific programming again, like C#?

y alguna acotación de lectores:

First, Oracle should under all circumstances make Java SE compatible with the new platforms like tables, macbooks and metro to keep their concept intact – OR – find a way to easily let Java SE applications run as “apps-likes” under another Java distribution made specificly to these platforms.
Second, Metro is nothing more (or less) than a simple “start-web-page”. Windows 8 is very similar to Windows 7, with program and filesystem seperated – where android and apple are more likely to melt these two things together. Therefore I doesn’t like andorid and apple as their operationsystem are defining the limitations. Some people would call that user-friendliness, I partially agree with that.
I believe that Windows 8 Metro will be an extension to their current desktop on traditional computers, but not a future replacement making the desktop legacy – and we won’t see anything like this within the next 10 years. But Windows 8 Metro will be the beginning of web and computers melting together – and this will eventually make the desktop computer look more like a tablet – and a tablet will look more like a desktop computer – and that will happen!

Uno de los casos que chocaron con WinRT.
Una discusión que refiere a Intel y ARM.

En fin, faltando una respuesta oficial de Oracle, comienza a abrirse el juego. ¿Va usted sopesando el impacto de Windows 8 en sus inversiones en licencias, plataformas, aplicaciones?

Firefox en Windows 8

Firefox anuncia sus planes de desarrollo del soporte para Windows 8. Su plan de trabajo delinea el tipo de dificultades con las que cualquier tercero se encontrará al trabajar para Windows 8 y Metro:

Mozilla’s Brian R. Bondy revealed today that development has begun on Firefox for Metro.

Last month, Mozilla’s Asa Dotzler announced that a Metro version of Firefox was in early planning stages, with a blog post about Mozilla’s goals that in turn linked to a roadmap. Dotzler is listed as the product manager.

Today’s announcement fleshes out some of the key decisions that the Mozilla team has made in the past month.

According to Bondy, Firefox for Metro will mimic Internet Explorer 10’s split personality, as a “Metro style enabled desktop browser”:

Unlike Metro applications, Metro style enabled desktop browsers have the ability to run outside of the Metro sandbox. Meaning not only can we build a browser, but we can build a powerful browser which gives an experience equal to that of a classic Desktop browser.

Metro style enabled desktop browsers have access to most Win32 API and the entire new WinRT API.

Unfortunately a browser can only participate in Metro mode if it is the default browser. So if Firefox is not the default browser on a system, you can’t use it in Metro mode. This is a decision made by Microsoft.

Volveremos sobre la "doble personalidad...

Metro y la herencia de Win32, II

Mientras recopilo información de Windows 8, pensando en el impacto que pudiera tener sobre las aplicaciones existentes (Win32), encuentro estas observaciones de Osvaldo Doederlein, ingeniero en Google:

Microsoft's "squaring of the circle" is by no means perfect: it looks more like an octogon to me. And while I understand and even appreciate the new UI concepts (semantic zoom, layout, typography etc.), its current rendering still looks crude, and (like Peter mentions) the Desktop and Metro look totally alien to each other. Maybe Microsoft can still work on this and make Metro's look more polished, and more similar to the desktop. I like shades, subtle 3D effects, and other decorations that a large display can use (and yeah, OSX uses more elegantly than anyone, though I'm happy enough with Win7). And I'm not visually impaired to need fonts with grotesque sizes everywhere; I'll rather see more data in one screen than need lots of horizontal scrolling (which is really cumbersome on mouse systems). My PC is not a giant Windows Phone!

Now I realize that MS is struggling in the smartphone and tablet markets, and having a single OS and UI that carries over all these platforms will be a big win. Can't really blame Microsoft: Apple is moving in the same direction with Mountain Lion (but not as aggressively as Metro). Even at Google we have Android and ChromeOS, but these platforms are more device-/web-/cloud-centric, and they have no desktop legacy; also, they're not competing on full desktops, to run complex apps like Photoshop (at work, I use Goobuntu for my "macho apps" like Eclipse). The problem is, after years of failure trying to shoehorn the classic Windows into tablets, Microsoft went to the opposite extreme--the total "tabletification" of the PC. Big mistake; there's no reason to believe a device-centric UI will be optimal for a conventional PC, remarkably when running sophisticated applications like IDEs, graghic editors, office suites etc.

Esta es mi especial preocupación. Así como y antes observara respecto a la tecnología de Activex frente al énfasis en .NET, existe un riesgo evidente de que todo el universo de aplicaciones basadas en Win32 y en la interfase visual del Windows [ahora] tradicional, se encuentre ante un futuro de difícil encaminamiento. Por necesidad, volveré sobre esto. Mi cuenta de aplicaciones Win32 a atender es demasiado grande.

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.

WinRT en el laboratorio...

 Rafael Ontiveros publica un interesante artículo sobre WinRT, tratando de adivinar las características de un producto que todavía es más trabajo de mercadeo que realidades. Aprecio su interés por ir a las cosas mismas, antes que adherir a las alabanzas tempranas. Fundamental, pone en duda el alcance de WinRT:

WinRT y Metro se ejecutan, como todo lo demás, sobre Win32, con las ventajas y los inconvenientes que eso pueda tener. No me malinterpretéis: no hay nada malo que la arquitectura sea diferente a la indicada en el gráfico de arriba, lo que está mal es que Microsoft nos mienta tan descaradamente. Simplemente eso.
Si lo han hecho así, por algo será y sus motivos tendrán, y es entonces cuando, ya definitivamente, yo tenía razón: Windows ya no es Windows NT, y su grandiosa arquitectura por bloques se ha perdido en el camino. Y esto sí que es malo, bastante malo, porque estamos volviendo a un batiburrillo de código como es, por cierto, el OS X (quizás algún día hable de ello).
Vosotros mismos podéis comprobarlo sin problema alguno y de forma muy rápida. Tenéis que construir dos aplicaciones, una WinRT en C++/CX y otra clásica de Win32. No hay más que utilizar las plantillas por defecto sin ningún cambio.
Eso sí, hay que hacerlo a partir de la versión Developer de 64 bits de Windows 8, e instalar una versión de la MSDN, porque la Express creo que no es capaz de generar programas Win32 puros.
(...) He llamado “TestWin32” a mi aplicación tradicional, que genera una ventana de Windows normal y corriente utilizando directamente el API de Win32. A la Metro la he llamado “TestSplitApplication”. Una vez generadas, tenemos que compilarlas.
(...) Si ahora nos vamos a la carpeta en donde está almacenado el proyecto (que podemos hacer desde el mismo IDE posicionándonos en el nombre de la solución en el Explorador y elegimos Open Folder in Windows Explorer), carpeta Debug, encontraremos el ejecutable del programa nativo (TestWin32.exe) y dentro de la carpeta TestSplitApplication, el de la aplicación Metro.
(...) Si nos diera por abrir, por ejemplo, uno de los dos KERNEL32.DLL, veríamos que ambas DLL son la misma con las mismas dependencias y exportaciones. Por lo tanto, ambas aplicaciones dependen del mismo subsistema.
Reitero que es una tontería, pero no lo es cuando intentan engañarte.
Lo que sí parece han hecho ha sido romper KERNEL32.DLL en otros ficheros más pequeños que contemplan subconjuntos de lo que en versiones anteriores había en él. Quizás de esta forma reduzcan la huella de memoria evitando cargar sub ficheros cuando estos no se vayan a utilizar.
(...) 
Esto nos lleva a un tercer problema: parecer ser que una aplicación Metro no puede ejecutar funciones de Win32, y una de Win32 tampoco de WinRT.
¡¡Pero si es el mismo subsistema!!
Pues bien, estamos ante una limitación artificialmente impuesta por Microsoft sin ningún motivo técnico aparente… con lo guapo que sería hacer aplicaciones Win32 con C++/CX…

 Conocido gracias a Bruno Capuano.

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.