Confidencial de WindowsWindows 95 desconectado
Raymond Chen
Aunque los programas de 32 bits para Windows® 95 podían usar el compilador de 32 bits habitual y los programas de 16 bits podían usar el compilador de 16 bits habitual, Windows 95 necesitaba un compilador especial, uno que comprendiera ambos mundos de 32 y 16 bits, y que pudiera salvar las diferencias. Windows 95 también necesitaba un vinculador personalizado que supiera combinar estos dos tipos de código y necesitaba un vinculador personalizado para los VxD (el formato de controlador para Windows 95).
El equipo de Windows 95 confió en la división de lenguajes y herramientas para que le proporcionaran estos compiladores y vinculadores especiales. Estoy seguro de que la división de lenguajes consideró que se trataba de una solicitud extraña: "¿Podríais crear un compilador que haga X, Y y Z, y que se va a usar para compilar únicamente dos DLL en toda su vida?" Es cierto. Pero, después de todo, se trataba de dos DLL muy importantes.
A pesar de lo absurdo que parecía la solicitud, la división de lenguajes y herramientas cumplió y el compilador y el vinculador de alta especialización pasó a formar parte del proceso de creación de Windows 95. Evidentemente, el compilador no estuvo completo de buenas a primeras. El equipo de Windows recibió una versión preliminar y, después, actualizaciones periódicas a medida que se implementaban nuevas optimizaciones y se corregían los errores.
Un día, la compilación de Windows 95 inesperadamente empezó a ir muy lenta. Un archivo que normalmente tardaba unos segundos en vincularse tardó varios minutos. El archivo se generaba correctamente, pero tardaba muchísimo. Y no sólo sucedía en el equipo de un desarrollador, el problema afectaba a todos los del equipo. ¿Nuestro código había producido algún caso patológico en el vinculador? ¿Nos habíamos tropezado con un error del vinculador?
Después de realizar algunas tareas de depuración, identificamos el origen del problema. La versión más reciente del vinculador contenía código de diagnóstico que los encargados de los lenguajes se habían olvidado de quitar antes de entregar el código al equipo de Windows. Este código de diagnóstico registraba su salida en un archivo que se almacenaba en un equipo que se encontraba en la oficina de un miembro del equipo del compilador. Y el equipo estaba apagado. Esto me recuerda a Leslie Lamport, que en una famosa descripción explicaba que un sistema distribuido es aquel que no puede trabajar porque un equipo desconocido está apagado.
Esa versión del vinculador se había estado ejecutando felizmente durante semanas. Cada vez que alguien intentaba vincular un VxD al compilar Windows 95, se realizaba una actualización en el archivo que se encontraba en el equipo de ese desarrollador. Mientras el equipo estuvo encendido y conectado a la red, nadie se había dado cuenta. Pero un día el equipo se apagó y todo iba muy lento.
Una vez identificado el problema, los encargados del compilador no tardaron en dar al equipo de Windows una revisión que quitaba el código de diagnóstico del vinculador.
Esta historia tiene distintos desenlaces según quién la cuente. Cuando la cuento yo, el desenlace es: "Y ese desarrollador del compilador pasó al equipo de Windows y acabó siendo mi jefe". Suelo disfrutar contando esta historia como una broma amable.
Sin embargo, si es mi jefe quien cuenta la historia, el desenlace es muy distinto: "Y resulta que yo no había escrito el código de diagnóstico. Fue uno de mis colegas, que decidió que en vez de llenar su equipo con información de diagnóstico, llenaría el mío".
En el sitio web de Raymond Chen, The Old New Thing, y en su libro homónimo se trata la historia de Windows y la programación Win32. Su ADN está lleno de código muerto.