Este texto ha sido generado por Gemini 2.5/3.1 a partir del audio del autor. El contenido y las ideas son íntegramente del autor; la redacción ha sido asistida por IA.
¿Qué pasa, patáticas mías? Aquí vuestro reportero maricharachero de barrio, Sésamo. Sí, hoy toca un nuevo saludo, «patáticas», que no sé cuánto durará, quizás un par de programas o quizás este sea el único. Hoy nos adentramos en un tema técnico que surgió del audio anterior, donde hablaba de las promesas de Microsoft para mejorar su sistema operativo.
El plan es hablar de WinRT y WinUI 3, pero son dos bestias muy diferentes, así que iremos por partes. Empezaremos por la de más bajo nivel: WinRT. Como no lo tenía del todo claro, le pedí a Gemini que me preparara un informe en profundidad, y ahora que lo entiendo, os lo voy a explicar. Pero para entender qué es WinRT, primero tenemos que hacer un viaje en el tiempo.
Un viaje al pasado: Corva, DDE y el nacimiento de COM
Si sois desarrolladores con solera, de los viejos como yo, seguramente os suenen términos como Corva, DDE o las aplicaciones COM. Hubo una época en la que se pusieron de moda los sistemas de objetos, una idea adelantada a su tiempo que buscaba que las librerías y componentes de software se autodescribieran.
La teoría era fantástica: tener una «caja negra» universal que un programador pudiera usar sin importar la plataforma (Solaris, Windows, Linux), la arquitectura o cualquier otro detalle. La funcionalidad debía ser agnóstica. Sin embargo, en la práctica, era una chorrada, porque como programador, sigues necesitando saber qué hacen esas librerías para poder usarlas correctamente.
Microsoft contraatacó a estas tendencias primero con DDE y luego con su propio protocolo: COM (Common Object Model). La idea de COM también estaba adelantada a su tiempo, pero a diferencia de otras, esta sí que funcionaba, aunque con matices importantes que veremos más adelante.
Entendiendo COM con una metáfora: el portátil y el dock
Para que entendáis el concepto de COM, olvidemos el código por un momento y pensemos en una metáfora. Imagina que tu aplicación es un «dock» de escritorio y un objeto COM es un ordenador portátil. Cuando conectas el portátil al dock, de repente el sistema se expande: tienes más puertos USB, el cargador se conecta, quizás accedes a un disco duro externo SCSI o a un almacenamiento PCI Express.
El dock (la aplicación) ya sabe qué interfaces tiene el portátil (el objeto COM). Sabe que tiene un conector de carga, puertos USB y una salida de vídeo, y sabe cómo conectarse a ellos, alimentarlos y activarlos. A partir de una interfaz base llamada IUnknown (Interfaz Desconocida), la aplicación puede «preguntarle» al objeto qué es capaz de hacer y solicitar una instancia de sus funcionalidades.
Lo realmente potente de este modelo es la flexibilidad. Puedes tener cinco modelos de portátiles diferentes, pero si todos tienen los conectores en el mismo sitio, puedes intercambiarlos. Un día usas tu portátil con un procesador i3 para tareas sencillas. Al día siguiente, necesitas potencia bruta, así que sacas el i3 y conectas un i9 con 600 TB de RAM. Los periféricos del dock siguen siendo los mismos, pero el «objeto» que los alimenta ha cambiado por completo.
Esta idea, nacida en el mundo de los «objetos de negocio», tenía otra ventaja brutal: el objeto COM no tenía por qué estar en tu ordenador. Podía estar ejecutándose en un servidor remoto. Tu aplicación simplemente llamaba al objeto a través de su identificador y, según la configuración del sistema, este se cargaba en otro equipo de la red sin que tu programa se diera cuenta.
La dolorosa realidad: lentitud, memoria y el infierno de la conversión
Sobre el papel, COM era una maravilla. En la práctica, tenía un problema gigantesco: no era lento, era inmanejablemente lento. Además, consumía una cantidad de memoria increíble. ¿Por qué? Por el coste de los «acoples», las conversiones de datos entre el objeto y la aplicación.
Imagina que tu portátil tiene una salida de vídeo DisplayPort, pero tu monitor es un viejo VGA. Como no hay un conversor directo, tienes que encadenar adaptadores: de DisplayPort a DVI, de DVI a HDMI, y finalmente de HDMI a VGA. Cada adaptador en esa cadena es un paso intermedio que añade latencia y complejidad. Eso es exactamente lo que pasaba con COM.
Veámoslo con un ejemplo de programación. Supongamos que un objeto COM tiene una cadena de texto «Hola Mundo» en un formato propio: Unicode con un CRC de verificación y terminada en el carácter 67. La interfaz intermedia de COM usa otro formato, los Hstrings. Y tu aplicación, escrita en C++, usa el formato de la librería STL, que guarda primero el tamaño y luego el texto. Para leer esa simple cadena, el sistema tiene que hacer tres conversiones, pasando por un formato intermedio.
Ahora imagina que quieres modificarla. La cosa se pone todavía peor. Modificas la cadena en C++, lo que crea una nueva asignación de memoria. Luego, esa cadena modificada debe convertirse al formato intermedio, que a su vez realiza su propio proceso de memoria. Y finalmente, se convierte al formato del objeto original. Si, para colmo, el objeto COM no permite modificar cadenas, acabas de liarla pardísima.
Para gestionar todo esto, había que definir un «Lenguaje de Definición de Interfaces» (IDL), donde se especificaba con todo lujo de detalles qué podía hacer cada objeto, si sus datos eran mutables, qué formato tenían las estructuras de datos (como el registro de un cliente), etc. Era un sistema propenso a errores y terriblemente complejo.
Anécdotas desde las trincheras: cuando Word decidía explotar
En la práctica, usar esto era una aventura. Imagina que querías automatizar Microsoft Office desde tu aplicación. El proceso parecía fácil: importabas el objeto ActiveX de Word, lo instanciabas y le decías «abre este documento». Y de repente, todo reventaba. ¿Por qué?
¡Ah, amigo! Quizás una llamada anterior había dejado a Word en un estado inestable en la memoria, y al volver a llamarlo, el programa se rompía. De esto, mi amiga Penny tiene bastante experiencia. La solución clásica era reiniciar el ordenador, y entonces, el mismo código funcionaba mágicamente. Aquello era un batiburrillo de diferentes ABIs (Interfaces Binarias de Aplicación) y una complejidad estructural demencial, especialmente en la era de Windows 95, 98 y 2000.
Este era el mundo en el que vivíamos los desarrolladores. Un sistema potente pero frágil y complicadísimo. Entender este caos es fundamental para apreciar por qué nació WinRT como su sucesor. Pero los pasos exactos para instanciar y trabajar con estos objetos… eso os lo contaré en el siguiente audio.
Así que ya sabéis, no olvidéis supextros habitualizaros. ¡Hasta el siguiente audio!