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 source
Réponses:
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.
la source
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
HKEY_LOCAL_MACHINE
et en particulier une grande partie se trouve dans\SOFTWARE\Microsoft
HKEY_LOCAL_MACHINE
HKEY_USERS
,[user]\SOFTWARE\Microsoft
HKEY_USERS\[user]\SOFTWARE
C:\Users\[User]\AppData
dans des dossiers cachésC:\Users\[User]\
dans des dossiers non masqués créés par l'applicationMac OS X
/Library/Preferences
encom.apple...plist
fichiers/Library/Preferences
dans desplist
fichiers tiers/Users/[user]/Library/Preferences
comme ci-dessus/Users/[user]/Library/Preferences
comme ci-dessus/Library/Application Support
/Users/[user]/Library/Application Support
/Users/[user]/
dans des dossiers non cachésEssentiellement, 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
.app
fichier lui - même, maisApplication Support
ouPreferences
, 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.)la source
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.
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.
la source
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.
la source
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).
la source
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é.
la source
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.
la source
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
plist
fichiers spécifiques à une application sont stockés (je crois) dans leLibrary
répertoire de l'utilisateur ou du système .la source
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 ...
la source
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.
la source
(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.
la source
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!
la source
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.
la source