Resuelto tras 25 años: Windows XP no elegía tu foto de usuario al azar sino por el tiempo de arranque

Resuelto tras 25 años: Windows XP no elegía tu foto de usuario al azar sino por el tiempo de arranque

Windows XPHistoria

Fuentes:HN + web research

Cientos de millones de usuarios en todo el mundo asumieron durante décadas que la imagen de perfil asignada en el primer inicio de Windows XP se elegía de forma puramente aleatoria. El 9 de septiembre de 2026, el veterano ingeniero de Microsoft Raymond Chen publicó un fragmento de código que desveló una lógica del sistema oculta durante un cuarto de siglo. Aquel avatar aparentemente fortuito nunca fue fruto de un sorteo a ciegas: respondía al cálculo exacto y determinista del sistema.

Un tuit desata una sesión de arqueología de código

El 11 de diciembre de 2025, un usuario llamado Xeno lanzó una pregunta en Twitter: ¿alguien había intentado averiguar el algoritmo de generación de números aleatorios con el que Windows XP decidía la imagen de usuario al crear una cuenta? Era una incógnita que llevaba más de dos décadas rondando los foros técnicos. Aunque en abril de 2004 Raymond Chen ya había comentado en un artículo que XP seleccionaba las imágenes al azar, aquella escueta mención nunca satisfizo a los desarrolladores más rigurosos. No querían conclusiones generales; exigían ver el código fuente y el fundamento matemático del algoritmo.

Finalmente, Chen desgranó la lógica exacta en su blog The Old New Thing. La publicación no tardó en alcanzar 333 puntos y 162 comentarios en Hacker News. Los lectores comprobaron con asombro que recibir la guitarra, la flor, las piezas de ajedrez o el patito de goma no dependía de una mano inocente en una urna cerrada. Detrás de la pantalla operaba un proceso matemático rigurosamente calculado.

La semilla inicial: vinculada a los milisegundos de arranque

En Windows XP, estos archivos de imagen iniciales se encontraban en una ruta profunda del sistema: %ALLUSERSPROFILE%\Application Data\Microsoft\User Account Pictures\Default Pictures. Cada vez que se daba de alta una cuenta, el sistema operativo debía seleccionar una imagen de esa carpeta.

La llamada central corría a cargo del generador pseudoaleatorio interno de Windows, RtlRandomEx. Cualquier algoritmo de esta naturaleza requiere una semilla de partida. En lugar de recurrir a complejas fuentes de entropía por hardware, los ingenieros de Microsoft tomaron directamente el valor devuelto por GetTickCount(). Esta función de la API entrega el número exacto de milisegundos transcurridos desde que la máquina inició su arranque.

Los algoritmos pseudoaleatorios parten de condiciones de entrada estrictas. Bastaba con registrar con precisión los milisegundos transcurridos hasta ese instante para predecir con exactitud qué imagen correspondería al usuario. Lo que en apariencia era impredecible resultaba ser, a nivel de código, una secuencia reproducible y determinista.

Muestreo de reservorio: reduciendo el recorrido a una sola pasada

Ante un directorio con un número indeterminado de archivos, la solución clásica de manual consiste en dar dos pasadas: primero se recorre la carpeta completa para contar el total n de elementos, se genera un índice aleatorio del 1 al n y se recorre de nuevo para recuperar el archivo situado en dicha posición. Es el clásico algoritmo de dos pasadas.

Los ingenieros de Microsoft descartaron esa vía y adoptaron un algoritmo de una sola pasada. Al explorar el directorio, el sistema solo mantiene dos variables en memoria: un contador count y el ganador provisional winner. Por cada archivo encontrado, incrementa count en uno y, con una probabilidad de 1/count, decide si sustituye winner por la imagen actual. Al concluir la lectura de la carpeta, el archivo que permanece en winner es la elección definitiva.

Código del algoritmo de una sola pasada selectRandomFromIterator Figura: Código del algoritmo de una sola pasada selectRandomFromIterator. Fuente: The Old New Thing

Se trata del caso especial clásico del muestreo de reservorio (Reservoir Sampling) cuando k = 1. En una colección de n elementos, el último tiene una probabilidad matemática estricta de 1/n de ser seleccionado. Si no se escoge, el dilema se reduce recursivamente a elegir con distribución uniforme entre los n - 1 elementos anteriores. Sin importar cuántos archivos contenga el directorio, todas las imágenes conservan exactamente la misma probabilidad uniforme de 1/n de ser la elegida final.

La teoría matemática cede ante los límites de lectura y escritura

¿Por qué evitar la sencillez de las dos pasadas y decantarse por el muestreo de reservorio? La explicación se halla en los cuellos de botella del sistema operativo. Al configurar un perfil de usuario, el coste de las llamadas al sistema de archivos supera con creces el cálculo en CPU. En aquellos años, los discos duros mecánicos sufrían penalizaciones de rendimiento notables al recorrer repetidamente directorios con múltiples archivos pequeños.

El recorrido en una sola pasada redujo de forma drástica los accesos a disco y toleraba cambios en el directorio sin provocar fallos de ejecución.

El método de dos pasadas exige que el número total de archivos permanezca inmutable entre el primer y el segundo escaneo. Si en la fracción de segundo que separa el recuento de la lectura otro proceso modificaba la carpeta de imágenes, el sistema se arriesgaba a un desbordamiento de índice o a un error por archivo inexistente, lo que provocaría un bloqueo. El mecanismo de una sola pasada eliminó por completo este riesgo de concurrencia.

Parada obligatoria tras escanear 100 imágenes

En el terreno puramente teórico, el muestreo de reservorio es impecable ante flujos de datos arbitrarios: a medida que el contador sube, la probabilidad de reemplazar el elemento se reduce de forma inversamente proporcional. Sin embargo, el código de producción de un sistema operativo comercial nunca se encomienda a bucles infinitos. En esta rutina crítica, los ingenieros fijaron una salvaguarda pragmática y contundente.

En cuanto el algoritmo alcanza una muestra de 100 imágenes leídas, interrumpe el bucle de inmediato y devuelve el ganador que tenga en ese instante.

Interfaz Luna predeterminada de Windows XP Figura: Interfaz Luna predeterminada de Windows XP. Fuente: Wikipedia

Los ingenieros de sistemas en primera línea no rinden culto a la pureza matemática abstracta. Establecer un límite físico de 100 archivos evitaba que un usuario malintencionado saturara el arranque colocando un millón de fotos en el directorio. Mientras los modelos teóricos buscan la distribución uniforme sobre conjuntos infinitos, el software industrial antepone un principio inquebrantable: el sistema jamás debe quedarse colgado.

Una calculada precisión tras la apariencia del azar

Regresando a la duda que abrió el debate en Twitter, millones de personas entre 2001 y 2014 recuerdan la expectación de iniciar Windows XP por primera vez. Ver en pantalla un balón de fútbol, un patito o una rana parecía una grata sorpresa fruto de la casualidad. La percepción humana no puede distinguir diferencias de pocos milisegundos en el arranque; esa variación infinitesimal bastaba para disfrazar un cálculo riguroso de auténtico azar.

El artículo de Raymond Chen no solo resolvió una curiosidad histórica, sino que rescató una instantánea de la ingeniería de software de una época irrepetible. Con memorias reducidas y discos lentos, cada línea de código requería optimización al milímetro y cada caso extremo exigía programación defensiva.

Aquel avatar asignado hace 25 años no fue fruto de una tómbola arbitraria. Fue una combinación magistral de límites prácticos y lógica de muestreo que definió la experiencia inicial de dos generaciones de usuarios.

Referencias:

  • The Old New Thing
  • HN
  • Wikipedia