Si utilizaste un PC durante los años ochenta o principios de los noventa, probablemente recuerdes el sonido característico del PC Speaker, aquel pequeño altavoz interno que tenía fama de producir únicamente pitidos; pitidos al arrancar, pitidos de error, pitidos en los videojuegos y, en general, pitidos para cualquier cosa que el ordenador quisiera comunicar al usuario. Comparado con una Sound Blaster o una AdLib, era poco más que una broma tecnológica.

Lo sorprendente es que, técnicamente, aquel insignificante altavoz era capaz de hacer bastante más de lo que parecía. De hecho, algunos programadores consiguieron reproducir voces digitalizadas, efectos de sonido complejos e incluso fragmentos musicales que parecían completamente imposibles para un dispositivo tan rudimentario. Y lo hicieron sin añadir hardware adicional.

Para entender el truco hay que comprender primero cómo funcionaba realmente el PC Speaker. A diferencia de una tarjeta de sonido moderna, no podía generar muestras digitales de audio ni reproducir varios canales simultáneamente. Estaba conectado a un temporizador programable Intel 8253 o 8254 presente en la placa base del PC, el cual generaba una onda cuadrada que encendía y apagaba el altavoz a una frecuencia determinada. Si configurabas una frecuencia de 440 Hz obtenías una nota La; si seleccionabas otra frecuencia distinta obtenías otra nota diferente.

Por eso los primeros juegos de PC sonaban como sonaban, porque el ordenador simplemente ordenaba al temporizador generar una frecuencia concreta y el altavoz vibraba siguiendo ese patrón. El resultado, pues, era esa onda cuadrada de la que hablamos, muy simple, rica en armónicos y bastante desagradable para los estándares actuales. Sin embargo, para una máquina de principios de los ochenta era una solución extraordinariamente barata y eficaz.

La limitación más importante era evidente, y es que el PC Speaker sólo conocía dos estados: encendido o apagado. No existían niveles de volumen, ni mezcla de sonidos, ni tonalidades complejas. A primera vista parecía imposible reproducir voz humana utilizando un dispositivo tan binario. Pero ahí entró en juego la creatividad de los programadores.

Algunos desarrolladores descubrieron que el cono del altavoz no respondía instantáneamente a los cambios eléctricos, sino que, como cualquier sistema mecánico, poseía una cierta inercia física. Si se activaba y desactivaba lo suficientemente rápido, el cono no llegaba a completar todo su recorrido y adoptaba posiciones intermedias, en otras palabras, aunque electrónicamente sólo existieran dos estados, mecánicamente podían obtenerse desplazamientos parciales. La técnica consistía en controlar aquel temporizador miles de veces por segundo y, en lugar de generar una simple nota musical, el programa modificaba constantemente la duración de los impulsos enviados al altavoz, cambiando con enorme rapidez el tiempo durante el cual permanecía activado o desactivado y haciendo posible simular diferentes amplitudes de señal. Este principio es muy parecido al que utilizan ciertas técnicas modernas de modulación por ancho de pulsos o PWM.

Desde el punto de vista matemático, lo que se hacía era aproximar una onda analógica mediante una sucesión extremadamente rápida de impulsos digitales. Cuanto mayor era la frecuencia de actualización, más convincente resultaba la ilusión acústica y, además, el oído humano actuaba como un filtro natural, integrando todas esas pequeñas variaciones en una forma de onda aparentemente continua. Por supuesto, aquello tenía un precio, y es que reproducir audio digitalizado mediante el PC Speaker consumía una cantidad enorme de tiempo de CPU. Mientras una Sound Blaster disponía de hardware específico para manejar el sonido, aquí era el propio procesador quien debía alimentar constantemente el flujo de datos y, por ejemplo, durante la reproducción de voz, una parte importante de la potencia de cálculo del ordenador quedaba dedicada exclusivamente a producir sonido.

¿Y por qué consumía tantos recursos? Pues básicamente por dos aspectos. El primero era la generación de interrupciones masivas (high overhead), pues para simular diferentes niveles de voltaje, la CPU tenía que cambiar el estado del altavoz (encendido/apagado) a frecuencias extremadamente altas (por ejemplo, a 8 kHz o a 11 kHz para audio digital de baja calidad). Esto significaba que el procesador debía interrumpir lo que estaba haciendo miles de veces por segundo solo para actualizar un bit del puerto. El segundo aspecto, se refería a los ciclos de reloj desperdiciados, ya que los procesadores de la época (como el Intel 8088 a 4,77 MHz del IBM PC original) no tenían potencia suficiente para procesar los gráficos de un juego y, al mismo tiempo, calcular los tiempos exactos de la onda de sonido. La CPU se veía obligada a entrar en bucles de espera (busy-waiting) midiendo los pulsos de máquina exactos para que el audio no se distorsionara, y los desarrolladores tenían que entrelazar el código del juego con el código de sonido de forma milimétrica, haciendo que cada instrucción de renderizado gráfico se calculara para que durara exactamente los ciclos de reloj idóneos entre pulso y pulso del altavoz.

Todo ello se traducía en congelaciones de juegos y ralentizaciones extremas la mayoría de las veces. Muchos usuarios descubrieron estas capacidades y sufrieron sus consecuencias gracias a juegos y demostraciones técnicas de la época en títulos como Castle Wolfenstein (versión de PC, en 1984), Space Quest III: The Pirates of Pestulon (1989), Pinball Dreams (1992), algunas conversiones de Prince of Persia (1989) o Street Fighter II para PC (1992). También diversas demos de la escena PC y numerosos programas shareware lograron reproducir voces sorprendentemente reconocibles utilizando únicamente el altavoz interno; escuchar una frase hablada salir de aquel pequeño transductor era casi magia para quien entendía las limitaciones del sistema. En España, el ejemplo más notable fue el de La abadía del crimen (1987), con su canto religioso del Ave María durante los rezos o aquel «Pirata, pirata…» enlatado cuando el juego detectaba que estabas ejecutando una copia ilegal o alterada.

Lo más fascinante es que el truco no explotaba una característica diseñada expresamente para ello, pues los ingenieros de IBM nunca imaginaron que aquel humilde altavoz destinado a emitir códigos de error terminaría reproduciendo frases digitalizadas, sino que fue una consecuencia inesperada de combinar física, electrónica y una alta cantidad de ingenio. Los desarrolladores observaron las limitaciones del hardware, comprendieron cómo vibraba realmente el altavoz y encontraron una manera de engañar tanto al dispositivo como al oído humano.

Hoy, cualquier teléfono móvil barato incorpora circuitería de audio millones de veces más sofisticada. Sin embargo, resulta difícil no sentir cierta admiración por aquellos programadores capaces de arrancar voces humanas a un componente diseñado básicamente para hacer «bip». Porque la historia del PC Speaker es, en el fondo, una de las historias más representativas de la informática clásica, aquella que dice que cuando el hardware era insuficiente, alguien siempre encontraba una forma ingeniosa de hacer lo imposible.

The post La física tras los pitidos del PC Speaker first appeared on teknoPLOF!.

Eran aquel momento en el que los usuarios de PC querían interfaces gráficas, ventanas, cuadros de diálogo y menús desplegables, pero el ordenador les respondía con un simple cursor parpadeando sobre una pantalla negra. Windows existía, sí, pero durante buena parte de los años ochenta y principios de los noventa el auténtico campo de batalla seguía siendo MS-DOS. Y fue precisamente en ese entorno hostil donde surgió una de las disciplinas más peculiares de la informática clásica: construir falsas interfaces gráficas utilizando únicamente caracteres de texto.

Para entender el fenómeno hay que recordar cómo era una sesión típica de DOS. La pantalla estaba formada por una cuadrícula de caracteres de 80 columnas por 25 filas. Cada posición almacenaba un código ASCII y unos atributos de color, y aquello, en teoría, sólo servía para mostrar texto. Sin embargo, los programadores pronto descubrieron que podían hacer bastante más con ello, porque el juego de caracteres de IBM incluía líneas horizontales, verticales, esquinas, bloques sombreados y otros símbolos semigráficos que permitían dibujar recuadros y estructuras sorprendentemente complejas.

La llegada de ANSI.SYS elevó la situación a otro nivel. Este controlador permitía interpretar secuencias ANSI enviadas por los programas o por archivos de texto y, gracias a ellas, era posible mover el cursor a cualquier posición de la pantalla, cambiar colores, borrar zonas concretas o modificar atributos visuales sin necesidad de acceder directamente al hardware. Para un usuario actual puede parecer algo trivial, pero en aquel momento era como descubrir superpoderes.

De repente comenzaron a aparecer programas cuya pantalla principal parecía una extraña imitación de un entorno gráfico. Había barras de menús, ventanas superpuestas, cuadros de ayuda y zonas coloreadas que daban la impresión de estar ante algo mucho más avanzado que una simple consola. Todo era mentira, por supuesto, no existían ventanas reales ni botones auténticos, tan solo había caracteres colocados cuidadosamente en posiciones concretas para crear una ilusión.

Lo fascinante es que esta técnica no se limitó a utilidades profesionales, los grupos de la escena warez y demoscene la adoptaron con entusiasmo. Muchas introducciones de cracks, por ejemplo, mostraban logotipos animados, textos desplazándose, degradados de color y marcos extremadamente elaborados. El usuario ejecutaba un programa y, antes de aparecer el juego, era recibido por una demostración técnica que parecía imposible para una simple pantalla de texto. En realidad, detrás de la magia sólo había secuencias ANSI, mucha imaginación y una paciencia infinita.

Técnicamente, ANSI.SYS era un controlador de dispositivo cargado desde al archivo de configuración CONFIG.SYS que interceptaba la salida de texto enviada a la consola de MS-DOS y analizaba las secuencias de escape ANSI que aparecían embebidas en el flujo de caracteres. Cuando un programa escribía una cadena que comenzaba por el carácter de escape ESC (ASCII 27), ANSI.SYS la interpretaba como una orden en lugar de mostrarla en pantalla. Estas órdenes permitían establecer el cursor en unas coordenadas concretas, cambiar colores de primer plano y fondo, eliminar líneas o regiones de pantalla, definir reasignaciones de teclado e incluso crear efectos de animación sin acceder directamente a la memoria de vídeo.

Internamente actuaba como una capa de traducción entre los programas y el controlador de consola de DOS, proporcionando una funcionalidad similar a la de los terminales profesionales compatibles con ANSI, pero con una penalización de rendimiento apreciable, ya que cada carácter enviado debía ser inspeccionado e interpretado antes de llegar a la pantalla. Por este motivo muchos programas profesionales, como gestores de archivos o BBS, acabaron utilizando bibliotecas propias que escribían directamente en la memoria de vídeo de las tarjetas CGA, EGA o VGA, obteniendo una velocidad muy superior a la que podía proporcionar ANSI.SYS.

Los más obsesivos llegaron a convertirlo en una disciplina artística, y se llegaron a diseñar auténticas ilustraciones formadas exclusivamente por caracteres ASCII y ANSI. Las sombras se construían mediante bloques semillenos, los reflejos se emulaban utilizando distintos colores de primer plano y las texturas eran combinaciones de símbolos aparentemente absurdos. Algunas composiciones ocupaban cientos de líneas y requerían terminales compatibles para renderizarse correctamente. Eran imágenes digitales, pero creadas con las mismas herramientas que se utilizaban para escribir un documento de texto.

La situación adquiría tintes casi cómicos cuando los desarrolladores intentaban competir visualmente con los primeros entornos gráficos. Aparecieron gestores de archivos, programas de comunicaciones y aplicaciones empresariales que simulaban cuadros de diálogo muy similares a los de Windows. Muchas personas pasaban horas trabajando dentro de aplicaciones DOS que, visualmente, intentaban convencerlas de que estaban utilizando una interfaz moderna, aunque por debajo siguiera existiendo exactamente la misma pantalla de texto de siempre.

Desde el punto de vista técnico, tampoco era una tarea sencilla. Había que considerar tarjetas gráficas diferentes, terminales incompatibles y sistemas que no siempre interpretaban las secuencias ANSI de la misma forma. Un efecto visual impresionante en un PC podía mostrarse completamente roto en otro. Por eso, muchos desarrolladores acabaron incluyendo detección automática de hardware, bibliotecas propias de control de pantalla e incluso sistemas alternativos cuando ANSI.SYS no estaba cargado.

Quizá lo más sorprendente es que todo este esfuerzo nacía de una limitación. Nadie habría dedicado tantas horas a dibujar botones con caracteres si hubiera tenido acceso a herramientas gráficas modernas. Sin embargo, precisamente porque existían restricciones técnicas, los programadores encontraron formas inesperadas de superarlas y, lo que debía ser un simple terminal de texto, acabó convirtiéndose en una plataforma para la creatividad visual.

Mirado con perspectiva, ANSI.SYS representa una de esas historias que definen perfectamente la informática clásica, donde un controlador diseñado para gestionar secuencias de terminal terminó alimentando una pequeña guerra entre la funcionalidad y el buen gusto. Algunos creaban interfaces elegantes y sorprendentemente profesionales, otros producían monstruos visuales llenos de colores fosforescentes, marcos imposibles y logotipos gigantescos que parecían diseñados después de una noche especialmente intensa de cafeína y ensamblador.

Y, siendo sinceros, ahí residía buena parte de su encanto, porque antes de los temas visuales, de las librerías gráficas y de los motores de interfaz, hubo una generación de programadores empeñada en demostrar que una pantalla de texto podía parecer cualquier cosa, incluso una interfaz gráfica. Aunque para lograrlo hubiera que declarar una guerra abierta al sentido estético.

The post La guerra silenciosa entre ANSI.SYS y el buen gusto first appeared on teknoPLOF!.

Hay una escena que el cine lleva décadas repitiendo mal: aparece un gran ordenador de los años cincuenta o sesenta, lleno de luces parpadeantes, y algún técnico con bata blanca pulsando interruptores de vez en cuando. La realidad era bastante más interesante, pues aquellos interruptores no estaban allí para decorar ni para impresionar a las visitas, y no se pulsaban cada media hora cuando el operario de turno hacía la ronda con una carpeta de pinza en la mano. En la mayoría de los casos eran literalmente «el teclado» de la máquina.

Las primeras computadoras electrónicas carecían de los sistemas de entrada que hoy damos por supuestos. No existían teclados ni ratones, no había interfaces gráficas ni terminales conectados permanentemente. Incluso antes de que una máquina pudiera leer una cinta de papel o una tarjeta perforada, había que cargar en memoria un pequeño programa inicial, y para introducir ese software se hacía necesario enviarlo bit a bit mediante los interruptores del panel frontal.

Imaginemos una máquina con un bus de 16 bits. En el frontal encontrábamos normalmente dieciséis palancas alineadas horizontalmente, cada una de ellas representando un bit. Interruptor hacia arriba significaba 1; interruptor hacia abajo significaba 0. Si el operador quería introducir el valor binario 0001001000110100, debía colocar exactamente cada interruptor en la posición correcta y, después, pulsar una tecla o palanca de carga para escribir ese valor en memoria. Luego cambiaba la combinación y repetía el proceso para la siguiente instrucción.

En máquinas como el IBM 1130, aquellos interruptores servían además para indicar direcciones de memoria concretas. El operador podía seleccionar una dirección, visualizar su contenido mediante los indicadores luminosos y modificarla manualmente. Era algo parecido a abrir hoy un editor hexadecimal, sólo que en lugar de una ventana tenías una consola metálica llena de bombillas.

El proceso de arranque, además, era especialmente delicado. Supongamos que el ordenador debía cargar el sistema desde una lectora de tarjetas perforadas, pero esa lectora todavía no podía utilizarse porque el equipo no sabía cómo comunicarse con ella. Por lo tanto, primero había que introducir mediante interruptores una rutina extremadamente pequeña, de apenas unas instrucciones en código máquina, que era capaz de leer unas pocas palabras desde la tarjeta. Lo leído contenía un cargador más potente que, a su vez, volcaba en memoria el resto del software. Era un proceso escalonado que los ingenieros llamaban bootstrap (arranque, en castellano), término del que deriva el actual boot de los sistemas operativos.

Un error de un solo bit podía arruinar la operación. Si el operador pretendía introducir una instrucción con valor hexadecimal 3A pero por descuido colocaba un interruptor incorrectamente y escribía 3B, el programa podía dejar de funcionar inmediatamente. No había mensajes explicativos ni depuradores sofisticados, y la solución habitual consistía en volver a revisar una por una las posiciones de los interruptores y compararlas con la documentación técnica.

Las luces del panel frontal eran igualmente importantes, pues no estaban pensadas para mostrar actividad de forma decorativa, como sucedería décadas después en muchos ordenadores domésticos. Habitualmente representaban el contenido de registros internos, direcciones de memoria o líneas de datos. Un operador experimentado podía observar el patrón de luces y deducir si el procesador estaba ejecutando instrucciones, atrapado en un bucle o esperando una entrada externa.

Algunos fabricantes llevaron la idea todavía más lejos. Los llamados sense switches permitían que los programas consultaran directamente el estado de determinados interruptores físicos durante la ejecución. En el IBM 701, por ejemplo, el software podía comprobar si un interruptor concreto estaba activado y tomar decisiones distintas en función de ello. En ciertos sistemas IBM, incluso el lenguaje FORTRAN incorporaba instrucciones específicas para leer estos interruptores y controlar luces del panel frontal. Esto daba lugar a situaciones que hoy resultan difíciles de imaginar, en las que, por ejemplo, un programa científico que llevaba horas ejecutándose podía modificar su comportamiento porque el operador había cambiado la posición de una pequeña palanca. También era posible activar modos de diagnóstico, solicitar información adicional o alterar estrategias de cálculo sin recompilar absolutamente nada, solo moviendo interruptores. En cierto modo, eran las opciones de configuración de una aplicación moderna, pero implementadas directamente en hardware.

Los paneles frontales también eran herramientas de mantenimiento. Cuando una máquina fallaba, los técnicos examinaban las luces para localizar el punto exacto del problema. Muchos manuales de servicio incluían tablas completas indicando qué combinación de indicadores correspondía a determinados errores. Hoy conectamos un depurador o revisamos un registro de eventos; entonces se observaba el comportamiento de las bombillas.

Lo más fascinante de todo es que aquellos operadores desarrollaban una comprensión extraordinariamente profunda de sus sistemas. No trabajaban sobre capas de abstracción, leían directamente los bits, las direcciones de memoria y los registros internos. Cuando un programa no funcionaba, podían seguir visualmente el recorrido de los datos por la máquina. La informática moderna nos ha dado herramientas infinitamente más cómodas, pero también nos ha alejado de esa relación casi física con el hardware.

Quizá por eso cuesta no sentir cierta admiración por aquellos pioneros. Mientras nosotros nos quejamos cuando un IDE tarda siete segundos en arrancar, ellos cargaban el programa inicial de un ordenador colocando docenas de interruptores en la posición correcta uno por uno. Y si se equivocaban en el último bit, tocaba empezar otra vez desde el principio. Eso sí que era programación de bajo nivel.

The post Cuando programar significaba mover interruptores first appeared on teknoPLOF!.

Fueron los tiempos en los que encender un PC compatible significaba enfrentarse a una pantalla negra, escribir comandos y aprender sobre la marcha cómo funcionaba aquella máquina. Y en el ámbito de la programación o el desarrollo ocurría tres cuartos de lo mismo. Bajo aquel contexto tecnológico apareció GORILLA.BAS, uno de los programas más recordados de Microsoft QBasic, un juego aparentemente sencillo que acabó convirtiéndose en la primera lección de programación, física y diseño de gráficos para toda una generación de usuarios. Muchos recuerdan Doom, Prince of Persia o Wolfenstein 3D como las grandes puertas de entrada al videojuego en PC, pero antes de ellos hubo miles de adolescentes lanzando plátanos explosivos entre rascacielos pixelados.

GORILLA.BAS (del año 1990) no era un producto comercial ni una demostración tecnológica destinada a impresionar a la prensa especializada. De hecho, su objetivo principal era enseñar. Microsoft lo distribuía junto con QBasic y QuickBASIC como ejemplo práctico de programación avanzada. Al instalar el entorno de desarrollo, el usuario encontraba no sólo el ejecutable, sino también todo el código fuente, algo que hoy parece inconcebible para la mayoría del software comercial. Bastaba pulsar unas teclas para abrir miles de líneas de BASIC perfectamente comentadas y comenzar a descubrir cómo estaba construido el juego. Para muchos futuros programadores aquello fue como desmontar un motor y comprobar cómo funcionaba pieza por pieza.

La mecánica era extraordinariamente simple. Dos gorilas aparecían situados sobre edificios de una ciudad generada aleatoriamente, cada jugador introducía mediante teclado el ángulo y la velocidad del lanzamiento y el ordenador calculaba entonces la trayectoria del proyectil y representaba el vuelo del plátano sobre el horizonte urbano. El primer jugador que acertaba a su rival ganaba la ronda. No había música digitalizada, no existían niveles, ni siquiera una inteligencia artificial elaborada. Sin embargo, como ocurría con los mejores juegos de la época, la sencillez escondía una enorme profundidad, pues cada partida planteaba un problema balístico diferente que exigía observación, ensayo y corrección continua.

Desde el punto de vista matemático, GORILLA.BAS —formalmente, QBasic GORILLAS— era una clase práctica de física de secundaria disfrazada de videojuego. La posición del plátano se calculaba mediante ecuaciones de movimiento parabólico. El programa tenía en cuenta la velocidad inicial, el ángulo de disparo, la gravedad y una variable adicional que simulaba la fuerza del viento. En cada iteración se recalculaba la posición horizontal y vertical del proyectil, dibujándolo en pantalla mientras avanzaba sobre los edificios. Lo interesante es que aquellos cálculos se realizaban en tiempo real sobre procesadores que hoy resultarían ridículos, y un 8088 o un 286 funcionando a unos pocos megahercios era más que suficiente para ofrecer una simulación convincente.

Uno de los aspectos más brillantes del diseño era precisamente la implementación del viento. En la parte inferior de la pantalla aparecía una pequeña indicación visual (una flecha) que mostraba la dirección e intensidad. Matemáticamente, el viento actuaba como una aceleración horizontal añadida a la ecuación del movimiento. Un valor elevado podía convertir un disparo aparentemente perfecto en un completo desastre, y los jugadores experimentados aprendían a estimar rápidamente cuántos grados debían corregir el lanzamiento o cuánta velocidad adicional necesitaban aplicar para compensar la desviación. Sin darse cuenta, estaban realizando cálculos aproximados similares a los que utilizan disciplinas tan distintas como la artillería o la aeronáutica.

La ciudad también escondía más trabajo técnico del que podía parecer a simple vista, ya que los edificios no estaban dibujados manualmente, sino que cada partida generaba un skyline diferente mediante procedimientos aleatorios. El programa elegía alturas, anchuras y posiciones dentro de ciertos márgenes para construir una ciudad única en cada ronda. Las ventanas iluminadas se distribuían igualmente mediante números aleatorios, creando la sensación de una auténtica metrópolis nocturna. Esta generación procedural era especialmente llamativa en una época en la que la mayoría de escenarios de videojuegos estaban completamente predefinidos por los desarrolladores.

Los propios gorilas representaban una demostración técnica muy interesante. Los personajes no eran imágenes cargadas desde disco ni sprites acelerados por hardware. Estaban definidos dentro del código mediante matrices de datos que describían pixel a pixel su apariencia y, durante la ejecución, el código convertía esos datos en gráficos visibles sobre la pantalla. Cuando el gorila lanzaba un plátano, levantaba los brazos mediante una sencilla pero eficaz animación. Resulta sorprendente comprobar cómo unos pocos cientos de bytes podían transmitir tanta personalidad a un personaje tan rudimentario.

También merece atención la forma en que el juego gestionaba las colisiones. Cada fotograma verificaba si el plátano había impactado contra un edificio, un gorila o había abandonado los límites de la pantalla. Cuando se producía un choque, el programa utilizaba primitivas gráficas para generar una explosión circular que alteraba permanentemente el escenario. Los edificios podían quedar parcialmente destruidos, modificando las condiciones de los siguientes disparos. Este detalle, aparentemente menor, introducía un nivel de interacción con el entorno que muchos títulos más sofisticados no ofrecían por aquella época. (¿Y que decir con la colisión con el sol? Dejamos este asunto para que el lector lo descubra por sí mismo).

A nivel gráfico, GORILLA.BAS aprovechaba las capacidades disponibles en CGA, EGA y VGA utilizando exclusivamente las funciones del lenguaje BASIC. Todo el dibujo se realizaba mediante comandos como LINE, CIRCLE, PAINT y PSET. Quien abría el código descubría que detrás de los edificios, los gorilas y las explosiones no existía ningún motor gráfico secreto; todo eran llamadas relativamente sencillas combinadas con ingenio y paciencia. Precisamente ahí radicaba gran parte de su valor educativo. El usuario comprendía que los videojuegos no eran magia, sino algoritmos.

Quizá el aspecto más importante de GORILLA.BAS fue su influencia silenciosa sobre una generación de aficionados. Miles de futuros programadores modificaron el código para cambiar colores, alterar la gravedad, transformar los plátanos en misiles o aumentar el tamaño de las explosiones. Algunos añadieron nuevos tipos de edificios, otros intentaron incorporar sonido o marcadores más sofisticados. Sin saberlo estaban aprendiendo conceptos fundamentales sobre programación estructurada, gestión de memoria, gráficos, simulación física y depuración. Muchas vocaciones informáticas comenzaron precisamente ahí, examinando un programa real y atreviéndose a romperlo para descubrir cómo funcionaba.

Visto desde 2026, cuando los videojuegos manejan mundos abiertos de cientos de kilómetros cuadrados y millones de polígonos por segundo, GORILLA.BAS podría parecer una reliquia irrelevante. Sin embargo, su importancia histórica va mucho más allá de sus gráficos primitivos y representa una época en la que los ordenadores invitaban a la curiosidad, en la que el usuario podía acceder al código fuente de un programa, modificarlo y aprender de él.

GORILLA.BAS tampoco estaba solo. Formaba parte de una tradición de programas demostrativos que acompañaban a los intérpretes y entornos de desarrollo BASIC de Microsoft, distribuyéndose con su código fuente completo para que los usuarios pudieran estudiarlo y modificarlo a voluntad. Entre ellos destacaba NIBBLES.BAS, una adictiva variante multijugador de Snake que servía para enseñar técnicas de animación en tiempo real, captura de teclado y detección de colisiones, o DONKEY.BAS, el sencillo juego de conducción creado por Bill Gates y Neil Konzen para los primeros IBM PC, concebido como demostración de las capacidades gráficas y sonoras del BASIC de Microsoft. Junto a ellos existían otros ejemplos como MONEY.BAS y diversos programas de simulación, matemáticas y gráficos destinados a enseñar programación de una forma práctica y entretenida.

Aquel enfrentamiento entre dos gorilas lanzándose plátanos sobre edificios generados aleatoriamente era mucho más que un pasatiempo, era una puerta de entrada a la programación, una lección de matemáticas interactiva y una demostración de que, con unos pocos cientos de líneas de BASIC y mucha imaginación, era posible crear algo capaz de permanecer grabado en la memoria de varias generaciones de aficionados a la informática. Y eso, probablemente, tiene mucho más mérito que muchos videojuegos multimillonarios de nuestros días.

Podemos descargar el juego, y también jugar online, desde la web de Internet Archive, concretamente desde su repositorio en https://archive.org/details/GorillasQbasic#.

The post «GORILLAS.BAS» first appeared on teknoPLOF!.

Cuando pensamos en las grandes innovaciones de la informática clásica solemos imaginar microprocesadores cada vez más rápidos, discos duros con capacidades que entonces parecían imposibles o tarjetas gráficas capaces de poner más colores y píxeles en pantalla. Sin embargo, durante los años ochenta existió otra clase de innovación bastante menos sofisticada que podía duplicar, al menos en determinadas máquinas, la capacidad útil de nuestros disquetes. La tecnología necesaria no podía ser más sencilla: hacer una muesca adicional en un trozo de plástico. Y no se trataba simplemente de una chapuza doméstica, porque llegó a existir una pequeña industria dedicada a fabricar herramientas cuya única misión consistía en practicar ese corte exactamente en el lugar adecuado.

Para entender por qué aquello funcionaba hay que regresar a la época de los disquetes flexibles de 5¼ pulgadas. Ordenadores como el Commodore 64, el Apple II y otros muchos sistemas domésticos utilizaban unidades que, en determinados modelos, disponían de una sola cabeza de lectura y escritura. Eso significaba que la unidad únicamente podía acceder a una de las superficies magnéticas del disco mientras este se encontraba introducido en su posición normal. Si queríamos utilizar la otra cara, la cabeza no podía desplazarse mágicamente hasta ella porque, sencillamente, no había una segunda cabeza al otro lado.

Dentro de la funda cuadrada de un disquete de 5¼ pulgadas había un disco circular flexible, normalmente fabricado con una base de poliéster y recubierto con material magnético. Aunque un disquete se comercializase como single sided, o de una sola cara, físicamente existía otra superficie magnética al otro lado. Ello no significaba necesariamente que el fabricante hubiese probado y certificado esa segunda superficie para almacenar datos con la misma fiabilidad, pero sí abría una posibilidad bastante evidente para cualquiera que se parase a pensar cómo funcionaba la unidad, ya que, si la cabeza sólo podía acceder a una cara, quizá bastaba con sacar el disco, darle la vuelta y volver a introducirlo.

Eso fue exactamente lo que empezaron a hacer muchos usuarios. Una vez llena la primera cara, extraían el disquete, lo giraban físicamente e intentaban utilizar la superficie posterior como si se tratase de otro disco completamente diferente. Desde el punto de vista magnético, la idea tenía sentido, pero existía un pequeño inconveniente mecánico. Las unidades de 5¼ pulgadas no se limitaban a leer el material magnético, sino que también utilizaban determinadas características de la funda exterior para saber cómo tratar el soporte que acababa de introducir el usuario.

Además de la gran abertura central y de la ventana longitudinal por la que la cabeza entraba en contacto con la superficie magnética, los disquetes podían incorporar otras referencias físicas. Una de las más importantes para esta historia era la muesca lateral utilizada por el mecanismo de protección contra escritura. Dependiendo del diseño de la unidad, la presencia o ausencia de esa abertura indicaba si estaba permitido modificar el contenido del disco. Cuando se daba la vuelta al soporte, la muesca original quedaba en el lado contrario y dejaba de encontrarse donde la unidad esperaba verla.

La solución consistió en practicar otra muesca en posición simétrica. De esta manera, al girar físicamente el disquete, la unidad volvía a encontrar la abertura en el lugar adecuado y permitía escribir sobre la segunda superficie. La modificación no aumentaba la densidad del soporte, no alteraba electrónicamente la unidad y tampoco activaba ninguna característica oculta del material magnético; simplemente engañaba a un mecanismo de detección extraordinariamente sencillo para permitir que el disco fuese utilizado en una orientación para la que su funda no había sido preparada originalmente.

Así nacieron los llamados flippy disks, cuyo nombre describía perfectamente su funcionamiento. Cuando una cara estaba llena, el usuario sacaba el disquete, le daba la vuelta —flip— y continuaba utilizando la otra superficie. En las máquinas compatibles, cada cara podía tratarse prácticamente como un disco independiente, de modo que un sencillo corte en la carcasa permitía obtener aproximadamente el doble de almacenamiento aprovechable.

Uno de los sistemas en los que esta práctica se hizo especialmente popular fue Commodore 64 con su unidad Commodore 1541. Un disquete formateado normalmente por la 1541 podía almacenar alrededor de 170 KB por cara, de manera que convertirlo en flippy permitía disponer de dos superficies independientes y superar los 300 KB de capacidad total. Visto desde un ordenador actual parece una cantidad ridícula, pero en aquella época 170 KB podían contener numerosos programas, documentos, partidas guardadas o una colección considerable de pequeños archivos.

La 1541, además, tenía una característica que facilitaba considerablemente el truco. Algunas unidades de disquete utilizaban el denominado agujero de índice, una perforación de referencia que, junto con un sensor de la unidad, permitía conocer la posición angular del disco durante su rotación. En sistemas que dependían de este mecanismo, darle la vuelta al soporte podía provocar problemas porque la geometría de las perforaciones dejaba de coincidir con la posición esperada. El sistema utilizado por la unidad Commodore 1541 no dependía de ese agujero de índice de la misma manera, ya que obtenía la sincronización necesaria a partir de la información grabada magnéticamente en las pistas. Aquello convertía a la unidad de Commodore en una candidata especialmente apropiada para utilizar discos invertidos.

La famosa muesca lateral, por su parte, tenía una función mucho más sencilla de lo que podría sugerir el truco, y es que estaba relacionada con la protección contra escritura. En muchos disquetes de 5¼, la unidad detectaba aquella abertura para determinar si podía grabar información. Si el usuario quería proteger el contenido, había de cubrir la muesca con una pequeña pegatina opaca, evitando así que la unidad autorizase operaciones de escritura. Al darle la vuelta al disquete, la abertura original dejaba de estar en la posición esperada, por lo que crear una segunda muesca simétrica permitía recuperar la posibilidad de escribir en la cara invertida.

Como ocurre con casi cualquier truco informático suficientemente popular, alguien terminó viendo una oportunidad comercial. Aparecieron herramientas diseñadas específicamente para convertir disquetes normales en flippy disks, conocidas habitualmente como disk notchers o diskette notchers. Su aspecto recordaba a una mezcla entre unos alicates, una grapadora y una perforadora de oficina. El usuario introducía el borde del disquete, apretaba la herramienta y esta retiraba un pequeño fragmento de plástico exactamente en la posición necesaria. No había electrónica, motores, circuitos ni ninguna clase de comunicación con el ordenador. Era, en esencia, un sacabocados especialmente preciso para disquetes.

Naturalmente, los propietarios de ordenadores domésticos de los años ochenta tampoco eran conocidos por comprar un accesorio especializado cuando el mismo resultado podía conseguirse con lo que hubiera por casa. Las perforadoras comerciales convivieron con toda clase de soluciones artesanales, y tijeras, cúteres, perforadoras de cuero, pequeñas limas, alicates modificados y plantillas caseras terminaron utilizándose para fabricar flippy disks. Un procedimiento bastante lógico consistía en tomar otro disco como referencia, marcar cuidadosamente la posición equivalente en el lado contrario y retirar una pequeña sección de la funda.

Había que hacerlo con cierto cuidado, porque dentro de aquella aparentemente robusta carcasa de plástico se encontraba una superficie magnética bastante más delicada. Un corte excesivamente profundo podía alcanzar el disco propiamente dicho, y dejar pequeños restos de plástico dentro de la funda tampoco era una idea particularmente buena. El soporte giraba a varios cientos de revoluciones por minuto y la cabeza trabajaba muy cerca de su superficie, así que introducir fragmentos de plástico, polvo o suciedad podía convertir un intento de ahorrar dinero en una excelente forma de destruir datos. Aun así, muchos usuarios adquirieron bastante práctica y algunos discos modificados artesanalmente presentaban un acabado sorprendentemente limpio. Otros parecían haber sido abiertos con los dientes, pero mientras la muesca estuviera aproximadamente en el lugar correcto podían funcionar exactamente igual.

La cuestión más discutible era si la segunda cara de un disquete vendido como de una sola cara resultaba realmente tan fiable como la primera. Que existiese material magnético por ambos lados no significaba necesariamente que las dos superficies hubieran pasado los mismos controles de calidad. La industria distinguía entre soportes single sided y double sided, y un fabricante podía certificar únicamente la superficie destinada oficialmente a almacenar información. La cara posterior podía funcionar perfectamente, presentar algunos defectos o empezar a producir errores después de cierto tiempo.

En la práctica, muchos usuarios comprobaron que una gran cantidad de discos de una cara podían formatearse y utilizarse por ambos lados sin ningún problema aparente. Aquello alimentó durante años la discusión sobre hasta qué punto existían diferencias reales entre determinados modelos comercializados como de una o de dos caras. La respuesta dependía del fabricante, de la época, del proceso de producción y de los controles de calidad aplicados. No era correcto asumir que todos los disquetes de una cara eran simplemente modelos de doble cara vendidos más baratos, pero tampoco era raro encontrar unidades cuya segunda superficie funcionaba sin inconvenientes.

La filosofía doméstica solía ser bastante pragmática: si la segunda cara podía formatearse, superar una verificación y guardar archivos sin producir errores, se utilizaba. Probablemente no era el lugar ideal para conservar la única copia existente de un trabajo importante, pero para juegos, programas fácilmente recuperables, copias temporales o software intercambiado entre amigos resultaba difícil resistirse a la posibilidad de obtener el doble de espacio sin comprar más discos.

Para comprender hasta qué punto podía resultar atractivo hay que situarse en la economía informática de principios y mediados de los años ochenta. El almacenamiento era caro y los discos duros se encontraban fuera del alcance de buena parte de los propietarios de microordenadores domésticos. Una colección de unas decenas o centenares de disquetes podía representar prácticamente todo el archivo digital de una persona. Programas, juegos, documentos y copias de seguridad ocupaban un soporte físico que había que comprar, etiquetar, ordenar y conservar. Si una caja de diez disquetes podía proporcionar, a efectos prácticos, veinte superficies independientes de almacenamiento, el ahorro resultaba evidente. Para estudiantes, aficionados y usuarios que intercambiaban constantemente programas, la diferencia tenía bastante más importancia que la que podemos imaginar desde un mundo en el que una diminuta tarjeta de memoria almacena millones de veces más información.

Además, un flippy disk no era exactamente equivalente a un disquete convencional de doble cara utilizado en una unidad de dos cabezas. En el primero, las superficies podían funcionar como dos discos independientes y era necesario invertir físicamente el soporte para pasar de una a otra. En una unidad de doble cara, en cambio, el hardware podía acceder a las dos superficies sin intervención del usuario. Esta diferencia explica también por qué algunos programas comerciales llegaron a distribuirse en discos que debían darse la vuelta manualmente. En determinados ecosistemas aquello dejó de ser un truco de aficionados y se convirtió en una forma perfectamente normal de distribuir software.

Los flippy disks resultan especialmente interesantes porque pertenecen a una clase de trucos informáticos que hoy parece casi arqueológica. No había que modificar el firmware, parchear el sistema operativo, instalar un controlador ni escribir una sola línea de código. El truco consistía en comprender la interacción entre el soporte físico, la unidad y sus sensores y modificar unos pocos milímetros de plástico para conseguir que el hardware aceptase algo que su diseño exterior no contemplaba directamente. Esa forma de enfrentarse a las limitaciones era muy característica de la microinformática de los años setenta y ochenta. Las máquinas tenían unas capacidades extremadamente reducidas comparadas con las actuales, pero muchos de sus mecanismos eran suficientemente visibles y comprensibles como para que un usuario curioso pudiera investigar cómo funcionaban. Era posible abrir el ordenador, estudiar sus conectores, observar cómo giraba un disquete, averiguar para qué servía cada abertura de la funda y terminar descubriendo que un problema de almacenamiento podía resolverse con una modificación puramente mecánica.

Y es por todo ello que ahí residía buena parte del encanto de los flippy disks. No añadían transistores, no aumentaban la frecuencia del procesador, no inventaban un nuevo sistema de codificación magnética y ni siquiera modificaban realmente la capacidad física del medio. Se limitaban a aprovechar una característica que ya estaba allí y que las limitaciones mecánicas de determinadas unidades dejaban sin utilizar. Miles de usuarios descubrieron que, en algunos ordenadores, la frontera entre quedarse sin espacio y disponer prácticamente del doble podía depender de retirar unos pocos milímetros de plástico. Y pocas veces en la historia de la informática se ha conseguido tanto haciendo, literalmente, un agujero en el sitio correcto.

The post «Flippy disks», el negocio de la venta de agujeros para disquetes first appeared on teknoPLOF!.

Hubo una época en la que la mayoría de la gente compraba un ordenador sin saber demasiado qué se escondía bajo aquella carcasa beis que ocupaba medio escritorio. Se hablaba de los megas de memoria, del tamaño del disco duro o de si la tarjeta de sonido era capaz de reproducir decentemente las explosiones del último juego de moda, pero el procesador era un componente prácticamente invisible para el usuario medio. Estaba ahí, escondido bajo disipadores, manuales y términos técnicos que pocos entendían y menos aún necesitaban comprender.

A principios de los años noventa, Intel tuvo una idea tan sencilla que hoy parece obvia, aunque en aquel momento resultaba casi revolucionaria. La empresa no vendía ordenadores completos al gran público, sino los chips que utilizaban los fabricantes para construirlos, sobre todo microprocesadores de CPU y coprocesadores matemáticos. Sin embargo, decidió que ya no le bastaba con que las marcas de los equipos conocieran sus productos, también quería que los conociera el comprador que paseaba por una tienda sin tener la menor idea de arquitecturas informáticas.

La estrategia fue sobresaliente. La compañía estadounidense comenzó a financiar campañas publicitarias junto a los fabricantes de ordenadores con una condición muy simple, que el nombre de Intel apareciera claramente asociado al producto. De aquella operación nacería uno de los eslóganes más reconocibles de la historia de la tecnología: ‘Intel Inside‘. Lo que parecía una campaña más, terminó convirtiéndose en un fenómeno cultural que transformó la forma de vender componentes informáticos.

La famosa pegatina comenzó entonces a adherirse en millones de equipos. Daba igual que el ordenador fuera de IBM, Compaq, Olivetti, Inves o cualquier ensamblador local de barrio, allí estaba aquella etiqueta brillante colocada en un lugar eminentemente visible de la torre o del portátil. Lo curioso es que muy poca gente sabía exactamente qué significaban los números y letras que acompañaban al logotipo, pero eso tampoco importaba demasiado. La pegatina transmitía confianza incluso a quienes no entendían nada de procesadores.

En poco tiempo ocurrió algo insólito. Los usuarios comenzaron a hablar de Intel como si fuera una marca de consumo corriente. De la noche al día surgieron conversaciones en las que alguien presumía de tener un «486», un «Pentium» o un «Pentium II» del mismo modo que otros presumían de coche nuevo. La mayoría no habría sabido explicar qué ventajas técnicas ofrecía cada modelo respecto al anterior, pero sí había aprendido que uno era mejor que otro y que Intel representaba lo deseable.

Aquello generó una situación bastante peculiar para la competencia. Empresas como AMD, Cyrix o IBM también fabricaban procesadores capaces de competir con Intel e incluso de superarla en determinados momentos. Sin embargo, en la mente de muchos compradores existía una asociación casi automática entre ordenador de calidad y procesador Intel. No era raro encontrar clientes que acudían a una tienda pidiendo expresamente «un ordenador Pentium» sin conocer una sola de sus características técnicas.

Lo más divertido era la relación emocional que muchos usuarios desarrollaron con aquella pequeña pegatina. Los ordenadores podían llenarse de polvo, amarillear con los años o sobrevivir a varias mudanzas, pero la etiqueta seguía ahí, perfectamente conservada. Había quien incluso mantenía intacto el plástico protector transparente durante años para evitar que se rayara. Parecía más un símbolo de prestigio que una simple indicación técnica.

En realidad, Intel había entendido algo fundamental sobre el comportamiento de los consumidores, y es que la mayoría de las personas no quieren estudiar complejas especificaciones técnicas antes de comprar tecnología, lo que buscan es una referencia sencilla que les permita sentir que están tomando una decisión segura. ‘Intel Inside’ funcionó precisamente porque resumía toda esa complejidad en una idea muy fácil de comprender: si lleva esta pegatina, debe de ser bueno.

Así pues, desde un punto de vista psicológico, el fenómeno de ‘Intel Inside’ demuestra que las personas no siempre tomamos decisiones basándonos en el conocimiento técnico, sino en símbolos que nos transmiten seguridad y pertenencia. Aquella pequeña pegatina funcionaba como una especie de certificado social. Pocos usuarios podían explicar qué hacía realmente un procesador, pero muchos experimentaban una sensación de tranquilidad al ver el logo de Intel en la carcasa. En cierto modo, la marca consiguió convertir un componente invisible en un elemento de identidad, permitiendo que los compradores sintieran que estaban tomando una decisión informada sin necesidad de comprender la complejidad que había detrás. Es el mismo mecanismo por el que algunos consumidores prefieren determinadas marcas de coches, relojes o teléfonos móviles: no adquieren únicamente un producto, sino también la confianza, el estatus y la tranquilidad asociados a él. Intel no vendía procesadores en aquella época, vendía la sensación de estar comprando «el procesador bueno», y pocas campañas de marketing han logrado manipular con tanta elegancia un comportamiento tan profundamente humano.

Con el tiempo, la tecnología evolucionó y el mercado cambió por completo, pero la estrategia dejó una huella enorme. Muchas de las campañas modernas siguen utilizando exactamente la misma fórmula. Cuando Apple presume de sus chips M, AMD destaca sus Ryzen o NVIDIA hace lo propio con GeForce, en el fondo están intentando reproducir aquella misma conexión emocional entre un componente interno y la percepción del usuario final.

Quizá por eso, la pegatina ‘Intel Inside’ ocupa un lugar tan especial en la memoria colectiva de quienes crecieron rodeados de ordenadores en los noventa. No era la pieza más importante del equipo ni la más sofisticada, pero consiguió algo mucho más difícil, convertirse en un icono reconocible para millones de personas que jamás habían visto un procesador. Y eso tiene bastante mérito para una empresa cuyo producto, por definición, estaba diseñado para permanecer oculto dentro de una caja cerrada.

The post La historia de una estrategia publicitaria brillante: la pegatina ‘Intel Inside’ first appeared on teknoPLOF!.

En el mundo de la tecnología empresarial existe una regla no escrita: cuanto más grande es el proyecto, más espectacular puede ser el fracaso. Y pocos casos ilustran mejor esta realidad que el enfrentamiento entre Lidl y SAP, una historia que comenzó con la intención de modernizar una de las mayores cadenas de supermercados de Europa y terminó convirtiéndose en uno de los abandonos de ERP más costosos de los que se tiene noticia. Diversos medios especializados cifraron las pérdidas asociadas al proyecto en torno a los 500 millones de dólares americanos cuando finalmente fue cancelado en 2018.

Para entender lo ocurrido hay que comprender qué pretendía conseguir Lidl. La compañía llevaba años utilizando sistemas desarrollados y adaptados internamente para gestionar su enorme red logística. Sin embargo, la complejidad creciente del negocio llevó a la dirección a apostar por una implantación global de software empresarial basado en la plataforma de SAP, considerada una de las referencias mundiales en planificación de recursos empresariales. El objetivo era unificar procesos, mejorar la trazabilidad y simplificar la gestión corporativa a gran escala.

Sobre el papel, la decisión parecía impecable. SAP era líder de mercado, disponía de miles de implantaciones exitosas y ofrecía funcionalidades estándar para finanzas, compras, inventario y logística. Nadie estaba eligiendo una tecnología experimental. Al contrario, Lidl estaba apostando por una solución consolidada que ya utilizaban multitud de grandes organizaciones. Precisamente por eso, el desenlace resultó tan llamativo para el sector tecnológico.

El problema apareció cuando los consultores comenzaron a analizar en profundidad los procesos internos de Lidl. Históricamente, la compañía había desarrollado una forma propia de gestionar determinados aspectos de su inventario y valoración de mercancías. Mientras que SAP estaba diseñado para trabajar siguiendo modelos estandarizados ampliamente aceptados en la industria, Lidl había evolucionado durante décadas alrededor de procedimientos muy específicos que encajaban perfectamente con su operativa diaria.

Lo que empezó siendo una diferencia aparentemente pequeña se transformó poco a poco en una fuente constante de conflictos. La cuestión más citada por los analistas fue la forma de valorar las existencias. Lidl utilizaba determinados enfoques centrados en el precio de compra, mientras que SAP seguía una filosofía más alineada con otros criterios contables y logísticos habituales en las grandes implantaciones ERP. Adaptar uno al otro resultó mucho más complejo de lo inicialmente previsto.

A estas dificultades técnicas se añadió un fenómeno habitual en los grandes proyectos corporativos, como fue el crecimiento continuo del alcance. Cuando una organización intenta transformar simultáneamente procesos, software, estructuras organizativas y métodos de trabajo en decenas de países, cualquier cambio genera efectos en cadena. Lo que inicialmente parece una modificación sencilla puede terminar afectando a cientos de interfaces, informes, procedimientos y reglas de negocio.

Durante años se siguieron invirtiendo recursos en desarrollos, personalizaciones y actividades de integración. Sin embargo, cuanto más avanzaba el proyecto, más evidente resultaba que buena parte del esfuerzo estaba dedicado a adaptar SAP para que se comportara como los sistemas antiguos. Y ahí aparece una de las preguntas más incómodas de la informática empresarial: si necesitas modificar profundamente un software estándar para que haga exactamente lo mismo que el software que ya tienes, ¿dónde está realmente el beneficio?

Finalmente, en 2018, Lidl tomó una decisión extremadamente poco habitual en proyectos de esta magnitud, cancelar la iniciativa. Después de más de siete años de trabajo, la empresa concluyó que continuar no resultaba razonable desde el punto de vista económico ni operativo. La noticia causó un gran impacto en el sector porque demostraba que incluso organizaciones altamente profesionales pueden encontrarse con obstáculos prácticamente insalvables al acometer transformaciones digitales masivas.

Lo interesante del caso es que no se trata de una historia de incompetencia. Nadie estaba utilizando tecnología obsoleta, nadie estaba desarrollando software en un garaje y nadie había elegido una plataforma marginal. Participaban profesionales experimentados, una de las mayores cadenas minoristas del mundo y uno de los fabricantes de software empresarial más importantes del planeta. Precisamente por eso el fracaso resulta tan instructivo, ya que demuestra que los problemas más peligrosos rara vez son tecnológicos. Suelen ser organizativos, estratégicos y culturales.

La verdadera lección del caso Lidl-SAP es que la transformación digital no consiste únicamente en instalar software nuevo, muchas veces implica decidir qué procesos deben cambiar y cuáles merecen conservarse. Cuando una empresa y una plataforma tecnológica intentan adaptarse mutuamente al mismo tiempo, el proyecto puede entrar en una espiral de complejidad difícil de controlar. Y así fue como una iniciativa destinada a modernizar una de las cadenas de supermercados más exitosas de Europa terminó convirtiéndose en un auténtico bluf, recordando a toda la industria que, en informática, gastar más dinero no siempre acerca al éxito, sino que, a veces simplemente compra una versión más cara del mismo problema.

The post Lidl contra SAP: cómo quinientos millones de dólares se acabaron convirtiendo en una lección de informática empresarial first appeared on teknoPLOF!.

Mucho antes de AirDrop, de WhatsApp y de que Bluetooth estuviera hasta en el cepillo de dientes, hubo una época en la que dos teléfonos móviles podían intercambiar información mediante algo bastante más rudimentario y, al mismo tiempo, fascinante: luz infrarroja. Quienes tuvieron determinados teléfonos móviles, ordenadores portátiles o agendas electrónicas durante los años noventa y los primeros años del nuevo milenio seguramente recuerden aquella pequeña ventana de plástico oscuro situada en algún lateral del aparato. No parecía hacer gran cosa, no había que introducir ningún cable en ella y normalmente ni siquiera emitía una luz que pudiéramos ver. Sin embargo, detrás de aquel rectángulo negro se escondía un pequeño sistema de comunicaciones capaz de enviar datos de un dispositivo a otro.

El principio de funcionamiento era relativamente sencillo. En lugar de utilizar ondas de radio, como hace Bluetooth, por ejemplo, los dispositivos con puerto de infrarrojos utilizaban radiación electromagnética situada justo un punto más allá de la parte visible del espectro. Nuestros ojos no pueden verla, pero un emisor y un receptor adecuados sí pueden utilizarla para transmitir información. La idea, en realidad, nos resulta mucho más familiar de lo que parece. Un mando a distancia de televisión funciona siguiendo un principio parecido: al pulsar un botón, un pequeño LED infrarrojo situado en la parte frontal del mando emite una secuencia de pulsos. El televisor recibe esos pulsos, interpreta su patrón y descubre si queremos subir el volumen, cambiar de canal o apagarlo. No existe ningún cable entre ambos aparatos: la información viaja mediante luz.

Los puertos de infrarrojos de ordenadores, teléfonos y otros dispositivos llevaron esa idea bastante más lejos. No se trataba simplemente de enviar unas pocas órdenes predefinidas, ya que era posible establecer una comunicación digital entre dos aparatos y utilizarla para intercambiar contactos, sincronizar una agenda, enviar archivos, imprimir documentos o incluso conectarse a Internet utilizando un teléfono móvil como el módem adecuado.

Una de las tecnologías fundamentales detrás de aquello fue IrDA, siglas de Infrared Data Association. La asociación se creó en 1993 con el objetivo de establecer estándares que permitieran que dispositivos de distintos fabricantes pudieran comunicarse mediante luz infrarroja. Gracias a esas especificaciones, el infrarrojo dejó de ser simplemente una tecnología utilizada en mandos a distancia y pudo convertirse en una auténtica interfaz de datos para ordenadores y dispositivos portátiles.

El funcionamiento físico tenía una consecuencia que cualquiera que utilizase estos sistemas aprendía enseguida: los aparatos «tenían que verse». Dentro del puerto había un emisor infrarrojo y un receptor. Cuando un dispositivo quería transmitir información, convertía los datos digitales en una serie de pulsos luminosos extremadamente rápidos. El otro dispositivo detectaba esas variaciones de luz y las transformaba de nuevo en información digital. Como la radiación infrarroja utilizada en estas comunicaciones se comportaba fundamentalmente como la luz, no atravesaba alegremente paredes y obstáculos como pueden hacerlo determinadas señales de radio. Por eso había que colocar los dispositivos relativamente cerca y orientar sus puertos uno hacia otro.

Era el famoso ritual de los puertos infrarrojos: se activaba la función en los dos teléfonos, se buscaba la pequeña ventana oscura de cada uno y se colocaban ambos sobre una mesa, enfrentados. Entonces aparecía el dispositivo remoto y comenzaba la transferencia. Si todo iba bien, unos segundos o unos minutos después, el archivo estaba al otro lado. Si alguien movía uno de los teléfonos, podía irse la trasmisión al carajo y había que comenzar del nuevo.

Aquello tenía una ventaja curiosa desde el punto de vista de las interferencias. Mientras las tecnologías de radio transmiten en todas direcciones y pueden convivir numerosos dispositivos dentro del mismo espacio, una conexión infrarroja era mucho más direccional. Los dos aparatos estaban físicamente enfrentados y la comunicación quedaba bastante delimitada entre ellos. El inconveniente era exactamente el mismo, que había que mantener dicha orientación.

Los primeros estándares IrDA ofrecían velocidades que hoy resultan ridículas. Las especificaciones iniciales permitían comunicaciones desde unos pocos kilobits por segundo hasta 115,2 kbit/s. Posteriormente aparecieron versiones más rápidas, como Fast Infrared (conocida como FIR), que elevó la velocidad hasta 4 Mbit/s, y otras evoluciones del estándar que llegaron todavía más lejos.

Cuatro megabits por segundo pueden parecer insignificantes en una época en la que una conexión doméstica puede mover cientos o miles de megabits, pero conviene recordar qué tipo de información circulaba entonces entre aquellos dispositivos. Un contacto ocupaba prácticamente nada y una fotografía tomada por uno de los primeros móviles con cámara podía tener unas pocas decenas o centenares de kilobytes. Las agendas electrónicas almacenaban cantidades diminutas de información comparadas con las actuales y muchos documentos eran igualmente pequeños.

El infrarrojo tenía además otra característica muy atractiva para los fabricantes de dispositivos portátiles, que era que el hardware podía ser relativamente pequeño y consumir muy poca energía. En una época en la que los teléfonos tenían baterías diminutas comparadas con las actuales y cualquier función adicional debía justificar cuidadosamente su consumo, aquello era un algo muy relevante. Además, se evitaban los conectores físicos, y un portátil, por ejemplo, podía comunicarse con una impresora compatible sin necesidad de encontrar el cable adecuado; una PDA podía sincronizar información con un ordenador; y dos teléfonos podían intercambiar una tarjeta de contacto. Todo sin cables, pero con mucha puntería.

La pequeña ventana oscura que cubría el puerto también tenía su razón de ser. El material estaba diseñado para permitir el paso de las longitudes de onda infrarrojas utilizadas por el sistema mientras filtraba parte de la luz visible y protegía los componentes internos. Para nosotros parecía simplemente un trozo de plástico negro o rojizo. Para el emisor y el receptor era una ventana perfectamente transparente a la radiación que les interesaba.

Una forma divertida de comprobar que la luz infrarroja existe sigue estando al alcance de cualquiera. Muchos sensores de cámaras digitales pueden detectar parte del infrarrojo cercano y si apuntamos un mando a distancia hacia la cámara de determinados teléfonos y pulsamos un botón, es posible observar en la pantalla un destello procedente del LED que nuestros ojos, mirando directamente al mando, no perciben. Dependiendo del teléfono y de los filtros incorporados a sus cámaras, el efecto será más o menos visible.

Y entonces llegó la tecnología Bluetooth con una ventaja demoledora: los dispositivos no necesitaban mirarse. Al utilizar radiofrecuencia, un teléfono era capaz de comunicarse con otro aunque estuviera dentro de un bolsillo. No era necesario localizar una pequeña ventana, colocar ambos aparatos sobre una mesa ni mantenerlos cuidadosamente alineados durante la transferencia. Además, Bluetooth fue evolucionando rápidamente y comenzó a integrarse en auriculares, ordenadores, teclados, ratones, automóviles y una cantidad creciente de dispositivos.

Wi-Fi también fue extendiéndose y cubriendo las comunicaciones que necesitaban mayores velocidades y alcance. Entre ambos fueron dejando cada vez menos espacio para IrDA en los dispositivos de consumo. Pero no ocurrió de golpe, ya que durante algunos años convivieron teléfonos con infrarrojos y Bluetooth. Algunos incorporaban ambas tecnologías y permitían elegir. Poco a poco, sin embargo, el infrarrojo dejó de aparecer en las listas de especificaciones; los nuevos usuarios ya no lo necesitaban y los antiguos descubrieron que Bluetooth era mucho más cómodo y veloz.

Pero el infrarrojo no murió, simplemente dejó de utilizarse masivamente para transmitir archivos entre ordenadores y teléfonos. Sigue estando a nuestro alrededor, como decíamos, en los mandos a distancia, donde resulta extraordinariamente barato, sencillo y eficaz, pero también existen sensores, sistemas de comunicaciones de corto alcance y numerosas aplicaciones industriales que trabajan con radiación infrarroja. Incluso algunos teléfonos han incorporado en distintas épocas emisores infrarrojos para poder funcionar como mandos a distancia universales.

Lo que desapareció fue aquella forma tan particular de comunicarnos.

The post El puerto de infrarrojos: cuando para enviar una foto había que apuntar con el móvil first appeared on teknoPLOF!.

Había una dimensión del retrohacking ochentero y noventero que rara vez sale en las conversaciones habituales sobre phreaking, warez o demoscene y, sin embargo, estaba ahí, latiendo en silencio entre los sectores de los disquetes y los búferes de memoria de los módems: la manipulación deliberada de las bases de mensajes en sistemas BBS para alterar la realidad percibida por sus usuarios. Y no hablamos de borrar envíos ni de vandalismo simplón, sino de reescribir la historia de una comunidad byte a byte, atacando el propio formato en que los mensajes se almacenaban.

A la sazón, muchas BBS populares utilizaban formatos de almacenamiento propietarios o semiestandarizados, como los MSG de FidoNet, los JDT de JAM o los HMB de Hudson. Estos sistemas no eran bases de datos en el sentido moderno, sino colecciones de registros binarios con cabeceras relativamente sencillas. Cada mensaje tenía offsets, identificadores, flags y enlaces a otros mensajes. La mayoría de operadores de sistemas confiaban en la integridad del software que gestionaba estos archivos, asumiendo que cualquier modificación debía pasar por la lógica de la aplicación. Ahí estaba el error.

El truco consistía en acceder a los archivos de mensajes desde fuera de la BBS, normalmente mediante una puerta trasera bastante mundana como una cuenta mal configurada en un shell auxiliar o, también, aprovechando scripts de mantenimiento accesibles. Una vez dentro, se trataba de entender la capa binaria para poder modificarla. Nada glamuroso, sólo paciencia, un editor hexadecimal y la propia documentación recogida de FidoNews o la experiencia directamente deducida a base de prueba y error. Cambiar el autor de un mensaje era tan simple como sobrescribir un campo ASCII, pero lo interesante venía al jugar con los punteros de hilo y los estados de lectura.

En los sistemas JAM, por ejemplo, los envíos estaban indexados por un archivo separado (JDX) que apuntaba a los bloques de texto. Si se alteraban estos índices, era posible hacer que un mensaje respondiera a otro distinto, creando conversaciones que nunca ocurrieron o, mejor aún, reorganizando debates enteros para que pareciera que alguien había dicho lo contrario horas antes. En Hudson, más primitivo, bastaba con duplicar un registro con ligeras modificaciones y ajustar la marca de tiempo (timestamp) para insertar respuestas fantasma que parecían perfectamente legítimas.

Lo realmente perverso de este tipo de hacking vetusto no era el acceso técnico, sino el efecto psicológico. A diferencia de la desfiguración visible (defacing) o del robo de cuentas, aquí el sistema seguía funcionando con aparente normalidad. Los usuarios leían discusiones que tenían coherencia sintáctica pero no semántica, respuestas que nunca recordaban haber escrito o mensajes que parecían anticipar eventos futuros. Era desinformación artesanal, hecha con offsets y checksums, antes de que la palabra estuviera de moda.

Otro vector menos conocido consistía en manipular los identificadores únicos de mensaje utilizados durante las exportaciones y sincronizaciones entre nodos. En redes basadas en FidoNet, muchos programas dependían de campos como MSGID y REPLY para reconstruir árboles de conversación durante el intercambio de correo. Alterando cuidadosamente esos valores era posible provocar bifurcaciones lógicas en los hilos, generar referencias huérfanas o hacer que mensajes legítimos aparecieran asociados a contextos completamente distintos. El resultado no siempre era visible de inmediato; a menudo la distorsión emergía gradualmente a medida que los paquetes se propagaban entre sistemas y cada nodo reinterpretaba la estructura según sus propias reglas.

Tampoco ayudaba la ausencia de controles criptográficos significativos. La autenticidad de un mensaje descansaba casi por completo en la confianza depositada en el software de transporte y en la integridad del sistema remoto. Salvo mecanismos puntuales de validación o firmas implementadas por algunas redes especializadas, la mayoría de mensajes circulaban como registros cuya procedencia se asumía legítima. Desde una perspectiva moderna resulta llamativo comprobar hasta qué punto la coherencia social de aquellas comunidades dependía más de convenciones operativas que de garantías técnicas verificables, lo que convertía la manipulación de metadatos en una herramienta sorprendentemente eficaz para alterar narrativas sin necesidad de comprometer grandes infraestructuras.

Por supuesto, había riesgos técnicos. Muchos de estos formatos incluían mecanismos rudimentarios de verificación, y un byte mal colocado podía corromper enteramente la base de mensajes, obligando al sysop a restaurar desde una copia de seguridad. Por eso, los más finos trabajaban siempre sobre copias, recalculaban punteros y, en algunos casos, desarrollaban pequeñas utilidades en C para automatizar las modificaciones sin romper la estructura. Era un equilibrio delicado entre el caos creativo y la ingeniería inversa meticulosa.

Hoy, cuando todo está en bases de datos relacionales con registros inmutables y sistemas de auditoría, este tipo de manipulación parece infantil o inviable. Pero en aquel ecosistema distribuido y heterogéneo de las BBS, donde cada nodo tenía su propia idiosincrasia y las sincronizaciones eran lentas y parciales, había espacio para jugar con la realidad misma de la comunicación. No era sólo hackear máquinas, era hackear la memoria colectiva de una comunidad digital en pañales, y hacerlo sin dejar apenas rastro distinguible del ruido normal del sistema.

The post Así de manipulaban hilos de mensajes en las BBS de los años ochenta y noventa first appeared on teknoPLOF!.

En mayo de 2017 el mundo fue testigo de uno de los ciberataques más impactantes de la historia. Miles de organizaciones en decenas de países vieron cómo sus sistemas informáticos quedaban bloqueados de forma repentina por un ransomware llamado WannaCry. Hospitales, empresas de telecomunicaciones, fábricas, universidades y organismos públicos se encontraron con sus archivos cifrados y una exigencia de rescate en bitcoins para recuperarlos. Durante unas horas pareció que Internet estaba asistiendo a una especie de pandemia digital capaz de expandirse sin control.

Lo que hacía especialmente peligroso a WannaCry era que no dependía de la torpeza de los usuarios. La mayoría de los programas maliciosos necesitan que alguien abra un archivo adjunto, pulse sobre un enlace o instale una aplicación infectada. WannaCry era diferente, pues hacía uso de una vulnerabilidad de Windows conocida como MS17-010 para propagarse automáticamente de un ordenador a otro. Dicha vulnerabilidad afectaba (y afecta, si no está parcheada) al protocolo SMBv1, el mecanismo utilizado por Windows (en su primera versión) para compartir archivos, impresoras y recursos en general dentro de una red. Gracias a ella, un atacante podía ejecutar código de forma remota en una máquina vulnerable sin necesidad de autenticarse ni de que el usuario realizara ninguna acción.

La herramienta que aprovechaba esta vulnerabilidad era un exploit denominado EternalBlue. Lo más sorprendente es que EternalBlue no había sido desarrollado por un grupo criminal cualquiera, sino por la propia Agencia de Seguridad Nacional de Estados Unidos, la NSA. Durante años fue una herramienta secreta utilizada con fines de inteligencia hasta que acabó filtrada al público por un misterioso grupo conocido como The Shadow Brokers. De repente, una de las armas digitales más sofisticadas del arsenal de una agencia gubernamental quedó al alcance de cualquiera que quisiera utilizarla.

Cuando WannaCry apareció en Internet (viernes, 12 de mayo de 2017), combinó dicho exploit EternalBlue con un ransomware tradicional, y el resultado fue devastador. Una vez que una máquina era infectada, comenzaba a escanear la red en busca de otros equipos vulnerables. Si encontraba alguno, lo comprometía automáticamente y repetía el proceso. Este comportamiento convirtió a WannaCry, además, en un gusano informático, una categoría especialmente peligrosa de malware porque puede expandirse por sí mismo sin intervención humana y, en aquel entonces, en cuestión de horas se registraron decenas de miles de infecciones en más de ciento cincuenta países.

Entre las víctimas más conocidas estuvo el Servicio Nacional de Salud británico. Numerosos hospitales tuvieron que cancelar operaciones y consultas porque sus sistemas informáticos quedaron inutilizados, y también resultaron afectadas grandes empresas industriales, compañías de telecomunicaciones y organismos gubernamentales. Las imágenes de pantallas mostrando el mensaje de rescate dieron la vuelta al mundo y generaron una sensación de vulnerabilidad pocas veces vista hasta entonces.

Sin embargo, cuando todo parecía fuera de control, ocurrió algo inesperado. Un joven investigador británico de seguridad informática llamado Marcus Hutchins, conocido en Internet por el alias MalwareTech, comenzó a analizar una muestra del ransomware para comprender su funcionamiento. Durante su investigación, Hutchins observó un comportamiento extraño. Descubrió que, antes de iniciar el cifrado de archivos o de comenzar su propagación, WannaCry intentaba contactar con un extraño dominio de nombre aparentemente aleatorio: iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com.

La mayoría de los investigadores habría considerado aquel detalle como una simple curiosidad técnica, pero Hutchins, intrigado por su presencia en el código fuente, decidió registrar aquel dominio para estudiar el tráfico que pudiera recibir. El coste fue insignificante, apenas unos pocos dólares, pero lo que ocurrió después sorprendió a todo el mundo. Una vez que el dominio comenzó a responder, las nuevas instancias de WannaCry dejaron de ejecutarse. Sin saberlo, Hutchins había activado un mecanismo oculto dentro del software malicioso que actuaba como un interruptor de apagado, conocido popularmente como kill switch. Si la conexión fallaba, el malware continuaba ejecutándose normalmente; si la conexión tenía éxito, se detenía.

La razón exacta por la que los autores incluyeron este mecanismo sigue siendo objeto de debate. La teoría más aceptada es que pretendían dificultar el análisis del malware en entornos de laboratorio, ya que muchos sistemas automáticos utilizados por investigadores responden positivamente a cualquier petición DNS o HTTP realizada por un programa sospechoso con el objeto de observar su comportamiento. Los desarrolladores de WannaCry podrían haberlo diseñado para que se detuviera si conseguía contactar con aquel dominio, asumiendo que eso significaba que estaba siendo ejecutado dentro de una sandbox de análisis. Lo que no imaginaron es que a alguien le diera por registrar el dominio (o sí, quién sabe) y provocaría que todas las nuevas infecciones interpretaran que debían detenerse.

Es importante señalar que el hallazgo no eliminó el ransomware de los equipos ya comprometidos ni recuperó los archivos cifrados. Los sistemas infectados continuaron afectados. Sin embargo, el descubrimiento sí que logró frenar la propagación masiva que estaba alimentando el crecimiento exponencial del ataque. En otras palabras, se cerró la principal vía por la que la epidemia digital seguía expandiéndose.

El caso WannaCry también dejó al descubierto una realidad incómoda. Microsoft había publicado el parche que corregía la vulnerabilidad dos meses antes del ataque. A pesar de ello, miles de organizaciones no habían actualizado sus sistemas. Muchas utilizaban versiones antiguas de Windows o mantenían configuraciones obsoletas por motivos de compatibilidad. El resultado fue que una vulnerabilidad conocida y corregida acabó convirtiéndose en la puerta de entrada de una de las mayores crisis de seguridad informática de la década.

Con el paso del tiempo, WannaCry se ha convertido en un ejemplo clásico de cómo múltiples factores pueden combinarse para producir una tormenta perfecta: una vulnerabilidad grave, una herramienta ofensiva filtrada desde una agencia gubernamental, miles de sistemas sin actualizar y un malware diseñado para propagarse automáticamente fueron los ingredientes de un incidente histórico. Sin embargo, también es recordado por una circunstancia casi surrealista, la de que una crisis global que amenazaba con paralizar infraestructuras críticas terminó siendo frenada, al menos en gran medida, gracias al registro de un dominio olvidado que costó menos que una comida rápida.

Pocas veces en la historia de la informática una decisión tan simple tuvo un impacto tan enorme. Mientras miles de expertos intentaban comprender qué estaba ocurriendo y gobiernos de todo el mundo activaban protocolos de emergencia, un investigador sentado frente a su ordenador acabó encontrando la pieza que detuvo la expansión del ataque. Es una historia que parece sacada de una novela ciberpunk, pero ocurrió de verdad. Y, quizás por ello, WannaCry sigue siendo, casi una década después, uno de los episodios más fascinantes de la historia de la ciberseguridad.

The post «iuqerfsodp9ifjaposdfjhgosurijfaewrwergwea.com»: cuando un dominio de 10 dólares frenó una pandemia digital first appeared on teknoPLOF!.