El Registro de Windows y el XML

1. INTRODUCCIÓN

El registro de windows es una base de datos donde se almacena información sobre el hardware, la configuración del sistema operativo, los usuarios y el software instalado. El acceso a la información se hace mediante una ruta similar a la que se usa para el acceso a archivos, es decir, mediante un árbol. Este árbol contiene al menos cuatro ramas (claves) principales, sobre las cuales se hablará más tarde.

2. EL PROBLEMA DEL REGISTRO

Resulta sorprendente cómo muchas aplicaciones hacen un uso exagerado del registro, al grado de almacenar verdaderos archivos en las secciones correspondientes. Muchas veces los desinstaladores de estas aplicaciones dejan esa información y esto se va convirtiendo en basura.

En otras ocasiones, debido a que el registro tiene datos relacionados, una instalación fallida o incorrecta, o la eliminación accidental de una sola entrada de datos, puede causar que varios programas dejen de funcionar o no pueda instalarse actualizaciones. Un ejemplo concreto es la instalación de VisualStudio 2005 en un sistema que previamente tuvo una beta de alguna versión express. El desinstalador de la beta deja algunas claves "huérfanas" y el instalador de la versión final se confunde, haciendo que el programa nuevo no funcione.

Otro ejemplo: ciertos programas para edición de archivos de texto pueden solicitar que se les asocien las extensiones ".txt", con lo cual el Block de Notas de Windows deja de ser la aplicación por defecto para abrir estos archivos. El problema surge al desinstalar el editor, ya que no sólo deja sin asociación a los archivos ".txt", sino que afecta de tal modo al sistema, que puede desaparecer del menú contextual del explorador el comando para crear nuevos archivos de texto. Esto se debe a que el programa de instalación no guardó la configuración anterior.

Y ni qué decir del "infierno" que constituyen los conflictos de versiones de las bibliotecas dinámicas (dll). En la visión del .NET, se ha empezado a atacar este problema, haciendo innecesario registrar los ensamblados y/o dlls. Los programas que utilizan varias bibliotecas, los buscan directamente en el directorio donde se instalaron, o en caso de que utilicen archivos compartidos, en el GAC. Igualmente, muchos datos de configuración de los programas se guardan en los archivos ".config".

Sin embargo, todavía se hace un uso bastante exagerado del registro. Prueba de ello es VisualStudio, como se mencionó antes. El registro debería ser usado sólo para guardar configuración de sistema.

3.CÓMO FUNCIONA EL REGISTRO

La configuración actual del registro físicamente es así:

RAIZ 
| 
+-HKEY_LOCAL_MACHINE 
| +---HKEY_CLASSES_ROOT 
+-HKEY_USERS 
+---HKEY_CURRENT_USER 

Otras claves predefinidas pueden existir para ciertas plataformas, por ejemplo:

HKEY_DYN_DATA 
HKEY_CURRENT_CONFIG 

Para propósitos lógicos, las subclaves HKEY_CLASSES_ROOT y HKEY_CURRENT_USER se manejan como si estuvieran en raíz.

4. LA PROPUESTA

La idea de cómo debería ser el registro es como sigue. Empezar por la creación de una carpeta especial en el directorio de windows, llamada "registro".

Aquí se pueden almacenar varios archivos en formato xml, ya que actualmente existen muchas APIs que permiten el uso de este formato y además, tienen una estructura similar a la del registro, es decir, de árbol. La separación de archivos impide que el daño de un elemento incida menos o nada en el sistema. Sin embargo, para propósitos de programación se puede usar la misma API del registro de windows - o una muy similar, pero que en vez de interactuar con una base de datos, trabaje con esta carpeta de archivos xml:

1) Las claves HKEY_USERS y HKEY_CURRENT_USER quedarían en un archivo xml. Aquí sólo se almacenaría la información de cada usuario respecto del sistema. La información específica del software se guardaría en archivos propios de cada programa, en sus carpetas de instalación (archivos ".config"), y no como actualmente, en estas secciones del registro.

2) Claves especiales que contengan configuración del sistema, como "settings" de pantalla, impresoras instaladas, configuración de red, etc. se guardan en otro archivo xml. Esto reemplaza a HKEY_DYN_DATA, HKEY_CURRENT_CONFIG y una parte de HKEY_LOCAL_MACHINE, es decir, el hardware instalado, configuración de seguridad, etc.

3) Finalmente, un archivo xml contendría las asociaciones de los tipos de archivos con el software para abrirlos. Reemplazaría las entradas de la llave HKEY_CLASSES_ROOT. Por ejemplo, para los tipos ".txt" y ".bmp":

<associations> 
  <txt> 
    <OpenWith> Notepad.Exe</OpenWith> 
    <Icon> Notepad.exe,1</Icon> 
  </txt> 
  <bmp> 
    <OpenWith> Paint.Exe</OpenWith> 
    <Icon> Paint.exe,1</Icon> 
  </bmp> 
</associations> 

En la realidad, muchos tipos de archivos pueden abrirse con un mismo programa, por lo cual el registro de windows asocia esos tipos de archivos con una misma entrada. Si esta entrada se borra, todos los tipos de archivos quedan sin software asociado. Al almacenar en xml como se propone, habrá redundancia - cada tipo de archivo asociado con el software directamente - pero esto no importa, ya que ahora se cuenta con gran capacidad de almacenamiento, y borrar una entrada no afectaría al resto del sistema.

5. RESTAURANDO EL SISTEMA

Supóngase que se borraran los tres archivos del registro y no se tiene respaldo. Ocurriría que el sistema al reiniciar tendría que detectar todo el hardware (actualmente todo es plug&play), y con esto se restablecería el archivo de configuración de sistema (se supone que los controladores se encuentran en el directorio de sistema y sólo hay que agregarlos a la lista).

La información de usuarios sí se perdería, pero no es esencial para que trabaje el sistema. En todo caso sería cuestión de reconfigurar los datos de usuario, labor ciertamente tediosa, pero no crítica, considerando que habría ocurrido una pérdida total de información de sistema y sin respaldo.

Finalmente, los tipos de archivos quedarían sin asociar, lo cual se puede arreglar conforme se vaya teniendo acceso a ellos, es decir, con el explorador de windows se les vuelve asociar antes de abrirlos.

Actualmente, si se borra el registro y no hay respaldo, el sistema no funciona y el software que tenga claves almacenadas puede requerir ser instalado de nuevo.

6. CONCLUSIONES

En conclusión, con la propuesta anterior se puede lograr lo siguiente:

1) Simplificar la instalación de software reduciendo o eliminando la necesidad de guardar información en el registro. Es decir, fortalecer el enfoque de instalación tipo xcopy.

2) Eliminar la acumulación de basura o datos específicos de programas, que no tienen por qué estar en una zona compartida. Igual que el punto anterior, esto fortalece el enfoque de xcopy.

3) Facilitar el respaldo de información del sistema.

4) Evitar conflictos de versiones en librerías, ya que la información de cada programa no se comparte.

5) Reducir o eliminar el riesgo de daños al sistema por borrar o alterar información del registro.

Ojalá que las siguientes versiones de windows vayan tendiendo a este enfoque.