Pourquoi le registre Windows est-il nécessaire?

Alors que j’ai débogué des problèmes côte à côte dans le com, je me suis demandé dll enfer, tout en haïssant le registre Windows avec passion, je me demandais pourquoi on en avait besoin.

Je ne me suis jamais senti obligé de lire un livre entier sur les meilleures pratiques du registre, puis de simplement le comprendre.

Cependant, j’ai utilisé Linux et Mac OS et j’ai étudié les moyens d’installer plusieurs versions de Python et de ses bibliothèques sur le même ordinateur * nix.

Parce que le registre a un format quelque peu libre (bien que moche) et soit utilisé à toutes sortes d’activités, je n’ai jamais compris le problème essentiel qu’il essayait de résoudre.

Par exemple, Microsoft ne veut pas que deux versions différentes de MS Office soient installées côte à côte. Ils utilisent le registre pour appliquer cela lors de l'installation. Cette limitation est artificielle, à mon avis. S'ils voulaient vraiment permettre un comportement différent, ils auraient pu ajuster leur architecture en conséquence.

Sous Mac OS, vous pouvez installer et supprimer des applications en les déposant simplement dans un dossier particulier.

Alors,

A) Quel problème essentiel cherche-t-il à résoudre? B) Comment les autres systèmes d'exploitation le résolvent-ils?

La plupart des autres réponses sont plus ou moins correctes, mais (avec la question) elles manquent en quelque sorte le point.

Le registre est un gestionnaire de base de données hiérarchique - rien de plus, rien de moins.

Les "fautes" que vous attribuez au registre sont vraiment indépendantes du registre lui-même. Ce sont simplement des décisions que différents fournisseurs ont prises concernant l'installation de leurs programmes, par exemple. Si vous stockiez les informations d'une autre manière / sous une autre forme / sous un autre conteneur, les mêmes problèmes pourraient subsister.

Étant donné la philosophie d'Unix "tout est un fichier", il n'est pas surprenant que les systèmes Unix (et similaires, tels que Linux et MacOS) stockent les informations sous forme de fichiers individuels dans le système de fichiers. Ce n’est pas aussi différent que beaucoup de gens pourraient le croire tout de suite, car le système de fichiers Unix est lui-même une base de données hiérarchique (ou, on peut le dire, une base de données réseau si vous prenez en compte les liens symboliques). La différence flagrante réside dans le fait que le registre est accessible via une API distincte, où le stockage des données de configuration dans des fichiers permet d'accéder à ces fichiers, de les modifier, etc., via la même API (et les mêmes outils) que tous les autres fichiers.

C'est un référentiel de paramètres - un emplacement centralisé et quelque peu standardisé pour les préférences, les paramètres et les profils légers .

Il devient plus facile de comprendre lorsque l’on considère l’ensemble des éléments qu’un système d’exploitation doit stocker pour ses utilisateurs et ses applications:

les fenêtres

• Référentiel de paramètres
  • Système: registre Windows HKEY_LOCAL_MACHINEet en particulier une grande partie se trouve dans\SOFTWARE\Microsoft
  • Système tiers: registre WindowsHKEY_LOCAL_MACHINE
  • Système centré sur l'utilisateur: registre Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Tiers centré sur l'utilisateur: registre WindowsHKEY_USERS\[user]\SOFTWARE
• Fichiers d'application qu'un utilisateur ne devrait pas avoir besoin de voir C:\Users\[User]\AppData dans des dossiers cachés
• Fichiers d'application qu'un utilisateur peut souhaiter C:\Users\[User]\ dans des dossiers non masqués créés par l'application

Mac OS X

• Référentiel de paramètres
  • Système et tiers: /Library/Preferences en com.apple...plistfichiers
  • Système tiers: /Library/Preferences dans des plistfichiers tiers
  • Système centré sur l'utilisateur:, /Users/[user]/Library/Preferences comme ci-dessus
  • Tiers centré sur l'utilisateur:, /Users/[user]/Library/Preferences comme ci-dessus
• Fichiers d'application à l'échelle du système qu'un utilisateur ne devrait pas avoir besoin de voir /Library/Application Support
• Fichiers d'application qu'un utilisateur ne devrait pas avoir besoin de voir /Users/[user]/Library/Application Support
• Fichiers d'application qu'un utilisateur peut souhaiter /Users/[user]/ dans des dossiers non cachés

Essentiellement, le registre est identique aux dossiers de Mac OS X /Library/Preferences , et pas beaucoup plus ou moins.

Le fait que Mac OS corresponde presque parfaitement aux groupes d’organisations de données système et d’application montre que le registre Windows est un système parfaitement justifié, qui constitue simplement une façon différente de faire les choses.

La nature du système de fichiers du registre rend plus difficile la sauvegarde, la restauration ou la migration de certaines parties tout en laissant les autres; par conséquent, je préfère le système Mac, mais le but est presque identique.

Les deux systèmes d’exploitation ont des applications qui choisissent de violer ces structures à des degrés différents, généralement en usurpant un contexte plus global pour créer des fichiers ou des dossiers qui n’y appartiennent pas vraiment. Certaines applications créent en fait des dossiers directement dans C:\ou /sans demander. Cela me rend vraiment fou!

^{Soit dit en passant, alors que la plupart des applications Mac OS sont géniales, il existe un problème similaire avec différentes versions côte à côte, même si vous ne le remarquez probablement pas, car vos paramètres ne sont pas stockés. dans le .appfichier lui - même, mais Application Supportou Preferences, toutes les versions de l'application toujours utiliser les mêmes paramètres et affecter l'autre, à moins que la nouvelle version décide explicitement d'utiliser un dossier par un autre nom ( IntelliJIDEA70, IntelliJIDEA81, etc.)}

Je n'ai jamais compris quel problème essentiel il essayait de résoudre.

Avant le registre, Windows utilisait des fichiers .INI. Dans l'article de blog Pourquoi les fichiers INI sont-ils déconseillés au profit du registre? Raymond Chen énumère les problèmes qui existaient avec les fichiers .INI qui tentaient d'être résolus. Il énumère également les problèmes que les fichiers de configuration XML partagent avec les anciens fichiers .ini. C’est probablement ce qu’il faut regarder, car c’est ce que beaucoup d’applications utilisent de nos jours.

... le pendule est revenu aux fichiers de configuration de texte, mais cette fois, ce sont des fichiers XML. Cela rouvre la plupart des problèmes des fichiers INI, mais vous avez le principal avantage que personne n’écrit dans les fichiers de configuration XML; ils ne font que lire d'eux. Les fichiers de configuration XML ne sont pas utilisés pour stocker les paramètres utilisateur. ils ne contiennent que des informations sur le programme lui-même. Regardons à nouveau ces problèmes.

• La sécurité des fichiers XML n'est pas assez granulaire. Mais comme le fichier de configuration XML est en lecture seule, l'objection principale est évitée. (Mais si vous souhaitez que seuls les administrateurs soient autorisés à lire des parties spécifiques du code XML, vous avez des problèmes.)
• Les fichiers de configuration XML étant en lecture seule, vous n'avez pas à vous soucier de plusieurs rédacteurs.
• Les fichiers de configuration XML peuvent subir un déni de service. Vous pouvez toujours les ouvrir exclusivement et verrouiller d'autres processus.
• Les fichiers XML ne contiennent que des chaînes. Si vous souhaitez stocker des données binaires, vous devez les encoder d'une manière ou d'une autre.
• L'analyse d'un fichier XML est relativement lente. Mais comme ils sont en lecture seule, vous pouvez mettre en cache le résultat analysé en toute sécurité. Vous n'avez donc besoin d'analyser qu'une seule fois.
• Les programmes analysent les fichiers XML manuellement, mais le format XML est déjà verrouillé. Vous ne pouvez donc pas l'étendre, même si vous le vouliez. Espérons que ces programmes utilisent un analyseur XML conforme aux normes au lieu de produire leur propre algorithme, mais je ne serais pas surpris que des personnes écrivent leur propre analyseur XML personnalisé, qui étouffe, par exemple, les instructions de traitement ou les chaînes de plus de 70 caractères.
• Les fichiers XML n'ont pas de limite de taille.
• Les fichiers XML n'ont pas d'emplacement par défaut.

Tout cela suppose que les applications n'écrivent jamais dans leurs fichiers de configuration, ce sur quoi je ne suis pas d'accord, mais cela ne ferait qu'empirer les choses.

Ma théorie est que la force motrice n'est rien de ce qui précède. C'était plutôt une mesure anti-piratage. Dans les jours de pré-enregistrement, vous pouvez généralement simplement copier un programme entier d'une machine à une autre. Trouvez les fichiers .dll et vous étiez prêt à partir. Le registre rend BEAUCOUP plus difficile cette tâche .

Le registre accomplit très peu de choses qui, à mon avis, ne seraient pas mieux servies par un fichier de configuration par objectif.

(2014) Pour développer un peu mon raisonnement ici: je vois le registre comme un objet divin. Nous savons tous que c'est un anti-modèle.

Ma compréhension élémentaire est que le registre a été conçu pour être une sorte de référentiel de paramètres, remplaçant les fichiers .ini utilisés.

(NB, une compréhension rudimentaire, cela pourrait donc être incorrect).

A) Je suis d'accord avec la réponse de Tim.

B) D'autres systèmes d'exploitation utilisent d'autres méthodes de stockage des paramètres du programme, par exemple, Unix place généralement les fichiers dans / etc (fichiers globaux) et dans le dossier de l'utilisateur dans divers dossiers cachés (paramètres de l'utilisateur). Ils utilisent donc tous une forme de registre, sauf que dans certains cas, il est distribué.

Si je comprends bien (pas nécessairement en profiter)

A) Donner un "emplacement centralisé" où tout programme peut stocker des informations sur son installation ou sa configuration. Ces informations peuvent ensuite être utilisées par les programmes comme bon leur semble. Personnalisation, anti-piratage, etc.

Toutes ces informations contenues dans cette structure la protègent en quelque sorte, pensez à l’idée que les animaux se rassemblent, plus de sécurité en nombre. Si chaque information était son propre fichier ini, un utilisateur pourrait éventuellement la supprimer sur un coup de tête. Ils peuvent toujours le faire en entrant dans le registre, mais beaucoup le considèrent comme une boîte noire et ne le toucheront pas de peur de casser leur système.

B) Mac OS utilise des fichiers individuels très similaires aux fenêtres de fichiers ini utilisées avant l’enregistrement du registre.

Le but évident du registre est d’agir comme un référentiel unique pour toutes les données de configuration et de paramétrage et de supprimer la dépendance vis-à-vis des fichiers de configuration.

Sur d'autres systèmes d'exploitation, le mode opératoire consiste à stocker des informations spécifiques à l'application (telles que les fichiers de configuration) dans des répertoires masqués spécifiques à l'application, dans le répertoire de base des utilisateurs. (Par exemple, le jeu Aquaria stocke les informations de configuration $HOME/.Aquaria.) Les fichiers de paramètres globaux sont stockés dans /etc/.

Les Mac font leur propre chose: les plistfichiers spécifiques à une application sont stockés (je crois) dans le Libraryrépertoire de l'utilisateur ou du système .

Le problème ne vient pas de la philosophie du registre mais de sa conception. Le système d’exploitation utilise le registre pour rechercher des informations importantes concernant le programme en cours de chargement. Bien que, plutôt que de charger les informations à tout moment, il les charge toutes au démarrage, ce qui "peut" affecter les performances du système. Le système est également soumis à une exploitation abusive car les fournisseurs le chargent avec une foule d’informations et souvent, ils ne la suppriment pas lorsque le logiciel est désinstallé.

Contrairement à Unix où tout est stocké et chargé au fur et à mesure des besoins. Le système d'exploitation de cette manière ne s'appuie pas sur les compétences en programmation du fournisseur pour influer sur ses performances ...

Bien que je ne puisse pas commenter sur d'autres systèmes d'exploitation, le registre aide également à maintenir la configuration d'une application lors d'un processus de mise à niveau ou de désinstallation / réinstallation. Si toute la configuration se trouvait dans un fichier .ini devant être remplacé en raison d'une mise à niveau ajoutant des fonctionnalités, vous pourriez rencontrer des difficultés ou devoir créer un processus personnalisé pour fusionner les données de configuration dans le fichier ini entrant.

Cependant, avec les données du registre, vous pouvez utiliser un package d’installation commun (WIX, InstallShield, etc.) qui gérera la désinstallation / réinstallation des fichiers sans modifier les paramètres de l’application.

(tous A. pas sûr de B)

Je pense que cela tient en fait au fait (historique) que le registre agit comme une sorte d’interface commune pour les paramètres d’application.

Vous avez une application? Vous souhaitez stocker un paramètre défini pour l'utilisateur? Bung it dans le registre.

Pas besoin de "garantir les profils utilisateur", pas besoin d'accéder directement au système de fichiers. Win32 s'occupe de tout ça.

C'était un moyen de créer quelque chose de nouveau, d'inconnu et de tabou pour la plupart des utilisateurs, afin qu'ils le laissent tranquille. Les fichiers .ini et autoexec.bat peuvent facilement être supprimés ou modifiés.

Modification des paramètres d’enregistrement, oh mon dieu!

En plus de stocker simplement les paramètres de l'application, le registre est le moyen par lequel les programmes et les composants localisent d' autres programmes et composants . En fin de compte, je pense que c’est la raison pour laquelle il est centralisé dans une base de données unique, au lieu de le répartir sur des milliers de fichiers texte ou xml.

Par exemple, un composant qui effectue, par exemple, des effets vidéo "s'enregistre" dans le registre, permettant ainsi aux autres applications liées à la vidéo de connaître son existence et de l'utiliser. En disposant d'un système centralisé à cet effet, cela évite des problèmes sérieux, car des milliers de systèmes et d'applications utilisent différentes méthodes pour atteindre ce niveau d'intégration.