Windows XP arrastra fama de sistema imbatible a la hora de ejecutar software antiguo, y parte de esa reputación responde a un truco que Microsoft nunca publicitó demasiado. El ingeniero Raymond Chen, con más de tres décadas en la compañía, ha detallado cómo XP escondía una base de datos de aplicaciones problemáticas y, cuando detectaba alguna, le mentía directamente sobre la versión de Windows que tenía delante.
Si usasteis XP en su día, recordaréis que corría juegos y programas de gestión escritos años antes de 2001, muchos sin actualizar nunca para el nuevo sistema. Chen explicó en 2003 que estas correcciones vivían en la carpeta C:/WINDOWS/AppPatch, en formato binario pensado, en sus palabras, «para permitir un escaneo rápido». Lo llamativo es que Windows cambiaba su comportamiento solo para ese programa, y solo mientras estuviera en ejecución.
La Application Compatibility Database de Windows XP
Microsoft bautizó este mecanismo como Application Compatibility Database, un archivo binario indexado con extensión .sdb. En Windows XP, la base principal se llamaba Sysmain.sdb y, según Chen, incluía unas 200 correcciones de compatibilidad ya disponibles en el momento del lanzamiento del sistema operativo.
El sistema no se limitaba a mirar el nombre del ejecutable: comprobaba el tamaño del archivo, su checksum, la versión y la fecha, y hasta podía fijarse en otros ficheros de la carpeta del programa, lo que permitía afinar una corrección para una versión concreta de un software sin afectar a una versión más reciente que ya funcionase bien. Cuando encontraba coincidencia, Windows aplicaba lo que Microsoft llama shims: pequeñas funciones que se interponían entre la aplicación y el sistema operativo, capaces de alterar lo que el programa enviaba, lo que Windows respondía, o de ejecutar código propio antes de dejar pasar la llamada original hacia el sistema.
Cuando Windows XP fingía ser Windows 98
Algunos programas se negaban a arrancar si no reconocían una versión concreta de Windows. Para esos casos existía el shim Win98VersionLie, que devolvía información de Windows 98 a la aplicación sin importar qué sistema corriera realmente en el ordenador. El programa creía estar en un entorno antiguo; Windows XP seguía funcionando por debajo sin que nadie se enterara.
Chen no era muy partidario de que los desarrolladores dependieran de este truco. En 2010 escribió que si un programa solo arrancaba tras aplicarle VersionLie, su creador debería corregir las comprobaciones de versión, porque el modo de compatibilidad existe para el cliente final, no para la aplicación. Cada modo, de hecho, no es una versión reducida de un Windows antiguo sino un paquete concreto de shims e indicadores: el modo Windows 95 en XP agrupaba unas 50 de las correcciones más habituales.
El shim que copiaba el gestor de memoria de Windows 95
Mentir sobre la versión era solo el principio. El shim favorito de Chen es EmulateHeap, que sustituye el gestor de memoria estándar por una copia exacta del que usaba Windows 95, el heap que algunos programas antiguos necesitaban para no romperse en una versión más reciente. Windows, en vez de señalar que el programa estaba mal escrito, le entregaba el gestor de memoria con el que había crecido. Microsoft ya recurría a parches así antes de XP: Windows 95 detectaba a SimCity, que leía memoria recién liberada, y ajustaba el asignador para evitar el fallo, según contó el programador Joel Spolsky.
Chen explicó en 2017 que el modo de compatibilidad de Windows 2000 obliga a cargar las DLL siguiendo reglas anteriores a SafeDllSearchMode, una opción de seguridad posterior, algo que Microsoft hacía a propósito. Él lo llama compatibilidad bug-for-bug, porque un fabricante que no ha corregido su programa en quince años no lo va a hacer ahora. Los shims, eso sí, tienen límites: solo actúan dentro del proceso de la aplicación y no sirven con controladores incompatibles en modo kernel.
Por qué bloquear un programa era un gran problema
Microsoft podría haber bloqueado cualquier app que dependiera de comportamientos no documentados. Chen explicó en 2003 por qué no lo hizo: cada programa bloqueado era un motivo más para no actualizar a la siguiente versión de Windows. Bastaba un programa incompatible para echar a perder toda una actualización.
Puesto en la piel de un responsable de informática cuyo procesador de textos no funciona en XP: si el fabricante pide 150 dólares por la versión 2.0, el coste de actualizar se triplica, suponiendo que la empresa siga existiendo. Chen recordó una encuesta interna de Microsoft en la que casi todas las compañías tenían algún programa imprescindible, a menudo una app casera en Visual Basic cuyo desarrollador ya no trabajaba allí.
Buena parte de estas correcciones terminó en archivos DLL dentro de la carpeta AppPatch, lejos de los archivos centrales del sistema. Microsoft siguió alimentando XP con nuevas correcciones durante años: su Application Compatibility Update de abril de 2011 llegó una década después del lanzamiento original.