No cabe duda de que Windows 95 fue uno de los SO más exitosos de Microsoft, aunque también hay que reconocer que tuvo muchas peculiaridades bajo su capó. Una de estas es la manera en que el SO determinaba cuándo un archivo había realizado alguna instalación, pues no tenía la capacidad de reconocer los instaladores como tal.
¿Cómo Windows 95 determinaba cuando un instalador se había ejecutado?
De acuerdo con el ingeniero veterano de Microsoft, Raymond Chen, Windows 95 detectaba cuando un programa había hecho una instalación… adivinando. Sí, como lo lees, adivinando. Para ello, el SO aplicaba una heurística de coincidencias con cadenas de palabras que contenían relación con instalar, ejecutar y similares. De esta manera, si un archivo contenía la palabra install o setup o su equivalente en los idiomas soportados por el SO, Windows 95 determinaba que se trataría de un instalador.
¿Y qué sucedía cuando los instaladores no tenían un nombre que hiciese referencia a install o Setup?
Aquí es donde se pone interesante la anécdota que relató Chen, pues en estos casos el SO recurría a dos mecanismos, igualmente adivinatorios. El primer mecanismo consistía en aplicar otra heurística, la cual tenía una larga lista de coincidencias de términos cortos que se asimilaran a install y setup. En caso de que no arrojase ninguna coincidencia, el SO recurría a su otro mecanismo, el cual consistía en comprobar que la palabra install o setup apareciese en algún lugar de la ruta del instalador. Todos estos mecanismos, por cierto, Windows 95 los aplicaba luego de que el instalador finalizase la respectiva instalación.
Esto trajo como consecuencia que los instaladores (especialmente de los controladores) modificasen a su antojo las DLL del SO, lo cual provocaba fallos frecuentes en aplicaciones e inclusive en componentes mismos del sistema. Si bien Windows 95 contaba con un directorio oculto donde guardaba las copias de seguridad de las versiones originales de las DLL que fuesen sobreescritas por los instaladores (C:\Windows\SYSBCKUP), esto dependía completamente del sistema de detección de instaladores de Windows 95. Pero, y como acabamos de leer, el SO no tenía capacidad real de detectarlos o determinarlos. Así pues, la restauración de las versiones originales de DLL en Windows 95 dependía de si el instalador llevaba por nombre install o setup o alguna palabra relacionada con dichos términos.
Otro aspecto ineficaz de este método es que las comprobaciones muchas veces se posponían hasta el siguiente arranque o reinicio. La razón de esto es que los instaladores, cuando no podían reemplazar algunas DLL que estaban siendo utilizadas en ese momento por algún programa o componente del sistema, iniciaban el MS-DOS para ejecutar archivos por lotes. De esta manera, lograban sobreescribir las DLL originales por sus DLL modificadas y reiniciaban Windows 95.
Windows 2000 le puso un freno a este enfoque ineficaz
Con Windows 2000, Microsoft introdujo la protección de archivos de Windows. Esta característica consistió en que el SO registrase cada cambio que efectuase algún instalador y fuese notificado a través de winlogon. Si este cambiaba alguna DLL importante, Windows 2000 automáticamente restauraba la versión original desde su caché %WinDir%\System32\dllcache sin recurrir a las adivinanzas ni esperar a que se finalizase una instalación.
Luego, con Windows Vista, Microsoft introdujo la actual protección de recursos de Windows, la cual protege las DLL y archivos clave del sistema mediante un control de acceso. Un dato interesante es que el comando sfc /scannow deriva precisamente del trabajo que se hizo en Windows 2000.
