¿Por qué se necesita el registro de Windows?

Como he depurado problemas en com, lado a lado, lidiado con dll hell, todo mientras odiaba el registro de windows con pasión, me preguntaba por qué es necesario.

Nunca me sentí obligado a leer un libro completo sobre las mejores prácticas de registro, y luego simplemente "entenderlo".

Sin embargo, he usado Linux y Mac OS, y miro las formas en que uno puede instalar múltiples versiones de Python y sus bibliotecas en la misma computadora * nix.

Debido a que el registro tiene un formato libre (aunque feo) y se usa para todo tipo de propósitos, nunca he entendido qué problema esencial está tratando de resolver.

Por ejemplo, Microsoft no quiere que tenga dos versiones diferentes de MS Office instaladas una al lado de la otra. Utilizan el registro para aplicar esto durante la instalación. Esta limitación es artificial, en mi opinión. Si realmente quisieran permitir un comportamiento diferente, podrían haber ajustado su arquitectura en consecuencia.

En Mac OS, puede instalar y eliminar aplicaciones simplemente soltándolas en una carpeta en particular.

Entonces,

A) ¿Qué problema esencial está tratando de resolver? B) ¿Cómo lo resuelven otros sistemas operativos?

La mayoría de las otras respuestas son más o menos correctas, pero (junto con la pregunta) no entienden el punto.

El registro es un administrador de base de datos jerárquico, nada más y nada menos.

Las "fallas" que atribuye al registro son realmente independientes del registro en sí. Son simplemente decisiones que varios proveedores han tomado sobre cosas como cómo instalar sus programas: si almacenó la información de otra manera / forma / contenedor, los mismos problemas podrían persistir.

Dada la filosofía de "todo es un archivo" de Unix, no sorprende (o debería ser) que los sistemas Unix (y similares, como Linux y MacOS) almacenen la información como archivos individuales en el sistema de archivos. Sin embargo, esto no es tan diferente como muchas personas podrían creer de inmediato, ya que el sistema de archivos Unix es en sí mismo una base de datos jerárquica (o, posiblemente, una base de datos de red si tiene en cuenta los enlaces simbólicos). La gran diferencia es que se accede al registro a través de una API separada, donde el almacenamiento de datos de configuración en archivos permite acceder a esos archivos, editarlos, etc., a través de la misma API (y herramientas) que cualquier otro archivo.

Es un repositorio de configuraciones : una ubicación centralizada y algo estandarizada para preferencias, configuraciones y perfiles livianos .

Se vuelve más fácil de entender cuando se observa el panorama general de todas las cosas que un SO tiene que almacenar para sus usuarios y aplicaciones:

Ventanas

• Depósito de configuraciones
  • Sistema: Registro de Windows HKEY_LOCAL_MACHINEy específicamente gran parte de él está en\SOFTWARE\Microsoft
  • Terceros en todo el sistema: Registro de WindowsHKEY_LOCAL_MACHINE
  • Sistema centrado en el usuario: Registro de Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Centrado en el usuario de terceros: Registro de WindowsHKEY_USERS\[user]\SOFTWARE
• Archivos de aplicación que un usuario no debería necesitar ver C:\Users\[User]\AppData en carpetas ocultas
• Archivos de aplicación que un usuario puede desear C:\Users\[User]\ en carpetas no ocultas creadas por la aplicación

Mac OS X

• Depósito de configuraciones
  • Sistema y tercero: /Library/Preferences en com.apple...plistarchivos
  • Tercero en todo el sistema: /Library/Preferences en plistarchivos de terceros
  • Sistema centrado en el usuario: /Users/[user]/Library/Preferences igual que el anterior
  • Centrado en el usuario de terceros: /Users/[user]/Library/Preferences igual que el anterior
• Archivos de aplicación de todo el sistema que un usuario no debería necesitar ver /Library/Application Support
• Archivos de aplicación que un usuario no debería necesitar ver /Users/[user]/Library/Application Support
• Archivos de aplicación que un usuario puede desear /Users/[user]/ en carpetas no ocultas

Esencialmente, el registro es idéntico a las carpetas de Mac OS X /Library/Preferences , y no mucho más ni menos.

El hecho de que Mac OS tenga una coincidencia casi uno a uno para grupos organizativos de datos de sistemas y aplicaciones ilustra que el Registro de Windows es un sistema completamente justificado que es solo una forma diferente de hacer las cosas

La naturaleza del registro que no pertenece al sistema de archivos hace que sea más difícil hacer copias de seguridad, restaurar o migrar partes de él mientras deja otros, por lo que prefiero el sistema Mac, pero el propósito es casi idéntico.

Ambos sistemas operativos tienen aplicaciones que eligen violar estas estructuras en diferentes grados, generalmente mediante la usurpación de un contexto global más para crear archivos o carpetas que realmente no pertenecen allí. Algunas aplicaciones realmente crean carpetas directamente C:\o /sin preguntar. ¡Eso realmente me vuelve loco!

^{Por cierto, si bien la naturaleza de arrastrar y soltar de (la mayoría) de las aplicaciones de Mac OS es brillante, tiene un problema similar con diferentes versiones de lado a lado, aunque probablemente no se dé cuenta, ya que su configuración no está almacenada en el .appmismo, pero en el expediente Application Supporto Preferences, todas las versiones de la aplicación seguirán usando la misma configuración y se afectan entre sí, a menos que la versión más reciente decide explícitamente para utilizar una carpeta con un nombre diferente ( IntelliJIDEA70, IntelliJIDEA81, etc.)}

Nunca he entendido qué problema esencial está tratando de resolver.

Antes del Registro, Windows usaba archivos .INI. En la publicación del blog ¿Por qué los archivos INI están en desuso a favor del registro? Raymond Chen enumera los problemas que existían con los archivos .INI que intentaban resolverse. También enumera los problemas que los archivos de configuración XML comparten con los viejos archivos .ini. Esto es probablemente lo que vale la pena ver, ya que eso es lo que muchas aplicaciones usan hoy en día.

... el péndulo ha vuelto a los archivos de configuración de texto, pero esta vez, son XML. Esto reabre muchos de los problemas que tenían los archivos INI, pero tiene la gran ventaja de que nadie escribe en los archivos de configuración XML; solo leen de ellos. Los archivos de configuración XML no se utilizan para almacenar la configuración del usuario; solo contienen información sobre el programa en sí. Veamos esos problemas nuevamente.

• La seguridad del archivo XML no es lo suficientemente granular. Pero dado que el archivo de configuración XML es de solo lectura, la objeción principal se elude. (Pero si solo desea que los administradores tengan permiso para leer partes específicas del XML, entonces está en problemas).
• Dado que los archivos de configuración XML son de solo lectura, no tiene que preocuparse por múltiples escritores.
• Los archivos de configuración XML pueden sufrir una denegación de servicio. Todavía puede abrirlos exclusivamente y bloquear otros procesos.
• Los archivos XML contienen solo cadenas. Si desea almacenar datos binarios, debe codificarlos de alguna manera.
• Analizar un archivo XML es relativamente lento. Pero dado que son de solo lectura, puede almacenar en caché de forma segura el resultado analizado, por lo que solo necesita analizar una vez.
• Los programas analizan los archivos XML manualmente, pero el formato XML ya está bloqueado, por lo que no podría extenderlo de todos modos, incluso si quisiera. Afortunadamente, esos programas usan un analizador XML de conformidad estándar en lugar de rodar el suyo, pero no me sorprendería si la gente escribiera su propio analizador XML personalizado que se atasca, digamos, procesando instrucciones o cadenas de más de 70 caracteres.
• Los archivos XML no tienen un límite de tamaño.
• Los archivos XML no tienen una ubicación predeterminada.

Todo esto supone que la aplicación nunca escribe en sus archivos de configuración con los que no estoy de acuerdo, pero eso empeoraría las cosas y no mejoraría.

Mi teoría es que la fuerza impulsora no es ninguna de las anteriores. Más bien, fue una medida antipiratería. En los días previos al registro, generalmente podría simplemente copiar un programa completo de una máquina a otra. Encuentra los .DLL y estarás listo para comenzar. El registro hace que esto sea MUCHO más difícil de hacer.

Es muy poco lo que logra el registro que creo que no sería mejor atendido por un archivo de configuración por propósito.

(2014) Para ampliar un poco mi razonamiento aquí: veo el registro como un objeto divino. Todos sabemos que es un antipatrón.

Mi cruda comprensión es que el registro fue diseñado para ser una especie de repositorio de configuraciones, reemplazando los archivos .ini que solían usarse.

(NB, una comprensión cruda, por lo que esto podría ser incorrecto).

A) Estoy de acuerdo con la respuesta de Tim.

B) Otros sistemas operativos utilizan otros métodos para almacenar la configuración del programa, por ejemplo, los Unix generalmente colocan archivos en / etc (archivos globales) y en la carpeta del usuario en varias carpetas ocultas (configuración del usuario). Entonces todos usan alguna forma de registro, excepto que en algunos casos se distribuye.

Según tengo entendido (no necesariamente disfrutándolo)

A) Dar una "ubicación centralizada" donde cualquier programa pueda almacenar información sobre su instalación o configuración. Esta información puede ser utilizada por los programas de cualquier forma que ellos decidan. Personalización, antipiratería, etc.

Toda esta información que se encuentra en esta estructura la protege, piense en la idea de que los animales se junten, más seguridad en números. Si cada bit de información fuera su propio archivo ini, algún usuario podría eliminarlo por capricho. Todavía pueden hacerlo ingresando al registro, pero muchos lo ven como una caja negra y no lo tocan por miedo a romper su sistema.

B) Mac OS usa archivos individuales muy parecidos a los archivos ini que Windows usaba antes de que apareciera el registro.

El propósito obvio del Registro es actuar como un repositorio único para todos los datos de configuración y configuración y eliminar la dependencia de los archivos de configuración.

En otros sistemas operativos, el modus operandi es almacenar información específica de la aplicación (como archivos de configuración) en directorios ocultos específicos de la aplicación en el directorio de inicio de los usuarios. (Por ejemplo, el juego Aquaria almacena información de configuración en $HOME/.Aquaria). Los archivos de configuración global se almacenan en /etc/.

Las Mac hacen lo suyo: los plistarchivos específicos de la aplicación se almacenan (creo) en el Librarydirectorio del usuario o del sistema .

El problema no es con la filosofía del registro sino con su diseño. El sistema operativo utiliza el registro para buscar información importante sobre el programa que se está cargando. Aunque en lugar de cargar la información cuando sea necesario, la carga toda en el momento del arranque, lo que "puede" afectar el rendimiento del sistema. El sistema también se abusa a fondo porque los proveedores lo cargan con mucha información y muchas veces no eliminan la información cuando se desinstala el software.

A diferencia de Unix, donde todo se almacena en n archivos y se carga cuando sea necesario. El sistema operativo de esta manera no depende de las habilidades de programación del proveedor para afectar su rendimiento ...

Si bien no puedo comentar sobre otros sistemas operativos, el registro también ayuda a mantener la configuración de una aplicación durante un proceso de actualización o desinstalación / reinstalación. Si toda la configuración estaba en un archivo .ini que necesitaba ser reemplazado debido a una actualización que agregaba características, podría tener dificultades o tener que crear un proceso personalizado para fusionar los datos de configuración en el archivo ini entrante.

Sin embargo, con los datos en el registro, puede usar un paquete de instalación común (WIX, InstallShield, etc.) que manejará la desinstalación / reinstalación de archivos sin tocar la configuración de la aplicación.

(todos A. No estoy seguro acerca de B)

Creo que esto se debe al punto (histórico) de que el registro actúa como una especie de interfaz común para la configuración de la aplicación.

¿Tienes una solicitud? ¿Desea almacenar una configuración con ámbito de usuario? Bung en el registro.

No es necesario "garantizar los perfiles de usuario", no es necesario acceder directamente al sistema de archivos. Win32 se encarga de todo eso.

Era una forma de crear algo nuevo, desconocido y tabú para la mayoría de los usuarios, para que lo dejaran en paz. Los archivos .ini y autoexec.bat se pueden eliminar o cambiar fácilmente para peor.

Cambiando la configuración de registro, ¡Dios mío!

Además de simplemente almacenar la configuración de la aplicación, el registro es el medio por el cual los programas y componentes ubican otros programas y componentes . En última instancia, creo que es por eso que está centralizado en una sola base de datos en lugar de extenderse a través de miles de archivos de texto o xml.

Por ejemplo, un componente que realiza, por ejemplo, efectos de video 'se registra' en el registro, permitiendo que otras aplicaciones relacionadas con el video sepan de su existencia y lo usen. Al tener un sistema centralizado para esto, evita lo que sería un desastre grave, ya que miles de sistemas y aplicaciones utilizan diferentes métodos para lograr ese nivel de integración.