2010LN – Microsoft se piensa que somos tontos

Una crítica mordaz a las encuestas de Microsoft y la implementación de Copilot. ¿Por qué hacen preguntas estúpidas y diseñan herramientas inútiles?

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, gallinicas mías? Aquí vuestro reportero Marechal Achero de Barrio Sésamo, listo para echarnos unas risas a costa de Microsoft. Hoy voy a desahogarme sobre una gilipollez monumental que espero que alguien en Redmond escuche, aunque lo dudo mucho. La magia rara vez ocurre, pero no perdemos nada por intentarlo.

La pregunta más estúpida que Microsoft te puede hacer

Estaba yo tranquilamente sincronizando ficheros con Synology Drive cuando, de repente, salta la dichosa ventanita de Microsoft 365. La pregunta, que aparece de vez en cuando, es de traca: «¿Recomendarías Windows 11 a tus amigos?». Te dan una escala del 1 al 5 y un campo para explicar el porqué. Mi respuesta es siempre la misma: un 1 rotundo, porque no hay un cero.

En el comentario siempre pongo lo mismo: «Cuando hagáis una pregunta inteligente, responderé de manera adecuada». Porque, seamos serios, ¿recomendaría Windows 11? No. ¿Recomendaría Microsoft 365? No. ¿OneDrive? Tampoco. No recomendaría absolutamente nada de Microsoft, simple y llanamente porque no funciona bien. El problema es que la pregunta está diseñada por un descerebrado.

Si en lugar de esa sandez, hicierais preguntas con contenido real, la cosa cambiaría. Os voy a dar ideas, gratis. «¿Basado en la velocidad de arranque, recomendarías Windows 11?». «¿Y basado en la velocidad de respuesta del explorador de archivos?». No pido que preguntéis por los tiempos de acceso al kernel o las llamadas a la API Win32, sino por cosas útiles para vosotros. Si de 100.000 usuarios, 99.000 os dicen que el explorador es lento, a lo mejor es que algo pasa, ¿no creéis?

La masturbación de los managers y la telemetría

Estas preguntas genéricas solo sirven para una cosa: la masturbación de los managers. Se formula una pregunta ambigua que la mayoría de la gente, por inercia, responderá positivamente. Luego, esos datos se presentan al jefe para decirle: «¡Mira qué bien lo estamos haciendo!». Es un ciclo de autoengaño para que el gran «sartironatillas» se siente en su trono pensando que todo funciona de maravilla.

Esto no es una encuesta, es una farsa para justificar sueldos. Si tu jefe no se da cuenta de que la pregunta es una trampa para obtener la respuesta deseada, es tan tonto como tú. Ahora, si es consciente y lo hace para impresionar a su propio jefe, entonces es inteligente, pero moralmente cuestionable. En cualquier nivel de esa cadena donde se pierda la consciencia de esta manipulación, solo hay gilipollas, con todas las letras.

Y mientras tanto, recogen toda nuestra telemetría. Aunque sigas esos vídeos de YouTube que te dicen cómo desactivarla matando servicios y cambiando permisos, Microsoft sigue espiando. Para cortarla de verdad tienes que meterte en las políticas de grupo (gpedit.msc) y denegar permisos a carpetas específicas. Tienen toda la potencia, pero cero control y, sobre todo, cero inteligencia para usarla.

Copilot: una IA que nos toma por imbéciles

Esta mentalidad se extiende a su gran apuesta: la inteligencia artificial. ¿Recordáis la noticia de que iban a hacer Copilot «menos intrusivo»? Su gran solución fue quitar el botón de la IA de un montón de aplicaciones. ¡Problema resuelto! Se piensan que somos idiotas. Quitar un botón no soluciona el problema de fondo, que es una implementación completamente inútil.

El botón en sí no molestaba. El problema es lo que hacía, o más bien, lo que no hacía. Tomemos el Bloc de notas. Abrí un fichero .bat y el menú de Copilot me ofrecía opciones como «reescribir», «resumir» o «cambiar el tono». ¿En serio? ¿Quién usa el Bloc de notas para escribir alta literatura? Lo usamos para editar ficheros de configuración, scripts… ¡ficheros de sistema! Lo útil habría sido que Copilot me ayudara a depurar o mejorar ese script.

Es un despropósito. Con razón la gente se quejaba. Es como el botón del Paint para generar una gallinica; es una función que está ahí, la usas si quieres y si no, pues no. Pero en el Bloc de notas, Copilot es un añadido inútil que solo sirve si estás escribiendo un texto plano, algo que podrías hacer en Word, donde sí tendría más sentido.

La genial idea del «Copilot PC»

Y esto me lleva a otra de sus maravillosas ideas: la distinción de «Copilot PC». Tengo un Minisforum con una tarjeta gráfica capaz de mover un modelo de lenguaje local a 20 tokens por segundo, pero como no es un «Copilot PC» oficial, no tengo la aplicación principal. Sin embargo, sí tengo los inútiles botones de Copilot repartidos por el sistema. ¿Lo entendéis? Tengo Copilot, pero no tengo Copilot.

Puedo usar la IA para resumir un correo en el nuevo Outlook (lo cual es útil, aunque le falta una opción para resumir siempre en español) o para hacer chorradas en Paint, pero no para tareas realmente productivas en el sistema. Es una de esas ideas que suenan bien en la cabeza de un ejecutivo, pero que en la práctica son un desastre.

Nadie se libra: Apple y Linux también patinan

Y que nadie piense que esto es solo cosa de Microsoft. Apple, con su Apple Intelligence, no se queda atrás. La famosa estrellita de la IA te aparece una vez tras una actualización y luego desaparece para siempre. En la aplicación de Mail, la función de resumir tiene el mismo fallo que la de Microsoft: si recibo un correo en holandés, me lo resume en holandés. Para traducirlo, tengo que dar siete pasos. ¿Tan difícil es poner una opción que diga «responder siempre en mi idioma»?

Incluso en el mundo del software libre vemos estas implementaciones a medias. La última versión de KDE permite hacer OCR en las capturas de pantalla, ¡lo cual es genial! Instalas Tesseract y funciona. ¿El problema? Te copia todo el texto de la pantalla, sin darte la opción de seleccionar solo el fragmento que te interesa. Una idea brillante ejecutada de la peor forma posible. Otra panda de inútiles haciendo inutilidades.

Al final, todo esto me huele a lo mismo: son juguetes de la señorita Pepis. Anuncian a bombo y platillo que el Paint genera imágenes con IA para que las acciones suban, pero la puta realidad es que estas herramientas, en su estado actual, no valen para absolutamente nada.

En fin, ahora sí. No olvidéis sospechosos habitualizaros y que no os la pique un pollo belga. ¡Qué cansado estoy!

2006IIP – Qué es WinRT (I de II)

Descubre los orígenes de WinRT explorando su predecesor, el complejo y lento modelo COM de Microsoft. Una historia de desarrollo, errores y reinicios.

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!