Quand - et pourquoi - devez-vous stocker des données dans le registre Windows?

126

En tant que développeur, les outils qui stockent la configuration / les options dans le registre sont le fléau de ma vie. Je ne peux pas facilement suivre les modifications apportées à ces options, je ne peux pas les porter facilement d'une machine à l'autre, et tout cela me fait vraiment aspirer au bon vieux temps des fichiers .INI ...

Lors de l'écriture de mes propres applications, que dois-je - le cas échéant - choisir de placer dans le registre plutôt que dans des fichiers de configuration à l'ancienne, et pourquoi?

Roddy
la source
Je travaille actuellement avec une ancienne application qui stocke des informations dans le registre (application .NET), et cela me rend fou.
George Stocker

Réponses:

75
  • À l'origine, la configuration (WIN3) était stockée dans le fichier WIN.INI dans le répertoire Windows.
  • Problème: WIN.INI est devenu trop gros.
  • Solution (Win31): fichiers INI individuels dans le même répertoire que le programme.
  • Problème: ce programme peut être installé sur un réseau et partagé par de nombreuses personnes.
  • Solution (Win311): fichiers INI individuels dans le répertoire Windows de l'utilisateur.
  • Problème: de nombreuses personnes peuvent partager un dossier Windows, et il devrait de toute façon être en lecture seule.
  • Solution (Win95): Registre avec des sections séparées pour chaque utilisateur.
  • Problème: le registre est devenu trop volumineux.
  • Solution (WinXP): De grands blocs de données individuelles sont déplacés vers le propre dossier Application Data de l'utilisateur.
  • Problème: bon pour de grandes quantités de données, mais plutôt complexe pour de petites quantités.
  • Solution (.NET): petites quantités de données fixes en lecture seule stockées dans des fichiers .config (Xml) dans le même dossier que l'application, avec une API pour la lire. (Les données en lecture / écriture ou spécifiques à l'utilisateur restent dans le registre)
James Curran
la source
16
Unix: configuration stockée dans $ HOME / .your-app Là, résolue en une itération.
Leonel
33
La solution Unix est également loin d'être idéale: $ HOME est rempli de fichiers à points, et vous n'avez aucune idée de ce que font la plupart d'entre eux.
grep
2
@Leonel XDG vous oblige en fait à placer vos fichiers de configuration à l'intérieur $HOME/.config/your-app/, une solution créée pour résoudre le problème des objets @grep. Et, surprise, Linux moderne (et quiconque sur le * BSD est assez fou pour utiliser GNOME) a également un registre dans la gconfsuite. Choix de races de logiciels libres, c'est sûr;)
new123456
1
@grep, Re " aucune idée de ce que font la plupart d'entre eux ", pourquoi pas? D'ailleurs, le ballonnement n'est guère comparable à celui de Windows.
Pacerier
16

Pour en venir à la fois du point de vue de l'utilisateur et du point de vue des programmeurs, je dois dire qu'il n'y a vraiment pas de bonne excuse pour mettre quelque chose dans le registre à moins que ce ne soit quelque chose comme des associations de fichiers ou des paramètres spécifiques à la machine.

Je viens de l'école de pensée qui dit qu'un programme doit être exécutable de partout où il est installé, que l'installation doit être complètement déplaçable dans une machine, voire sur une autre machine et ne pas affecter son fonctionnement.

Toutes les options configurables, ou les DLL requises, etc., si elles ne sont pas partagées, doivent résider dans un sous-répertoire du répertoire d'installation, afin que toute l'installation soit facilement déplacée.

J'utilise beaucoup d'utilitaires plus petits comme des programmes, donc s'il ne peut pas être installé sur une clé USB et branché sur une autre machine et simplement fonctionner, alors ce n'est pas pour moi.

Jimoc
la source
4
Mais l'installation est souvent effectuée sous le contrôle de l'administrateur, tandis que la mise à jour des paramètres doit être effectuée sous le contrôle de l'utilisateur. Imaginez essayer de mettre à jour les paramètres - une application exécutée sous l'identité de l'utilisateur qui souhaite écrire dans un répertoire limité à l'accès administrateur uniquement. C'est l'une des choses que le registre est censé traiter.
Cheeso
@Cheeso, la solution est que chaque utilisateur dispose d'une copie de l'exécutable. Pour économiser de l'espace, pas une vraie copie mais juste une fausse copie (pointeur).
Pacerier le
12

Politique Microsoft:

  • Avant Windows 95, nous utilisions des fichiers ini pour les données d'application.
  • À l'époque de Windows 95 - XP, nous avons utilisé le registre.
  • Depuis Windows Vista, nous utilisons des fichiers ini bien qu'ils soient désormais basés sur XML.

Le registre dépend de la machine. Je ne l'ai jamais aimé car il ralentit et il est presque impossible de trouver ce dont vous avez besoin. C'est pourquoi j'aime les fichiers ini simples ou autres. Vous savez où ils se trouvent (dossier d'application ou dossier utilisateur) afin qu'ils soient facilement portables et lisibles par l'homme.

Toon Krijthe
la source
1
Pouvez-vous fournir un lien original vers le document qui énonce cette politique de Microsoft? Et quand vous parlez de politique, voulez-vous dire, c'est ce que fait Microsoft, ou voulez-vous dire que c'est ce que Microsoft recommande aux développeurs qui créent des applications pour Windows?
Cheeso
1
ps: Raymond Chen de Microsoft a déclaré que les fichiers INI sont obsolètes en faveur du registre, et explique pourquoi. blogs.msdn.com/oldnewthing/archive/2007/11/26/6523907.aspx Il déclare également que les fichiers XML présentent plusieurs des mêmes inconvénients que les fichiers ini.
Cheeso
8
Fichiers de paramètres XML = fichiers INI qui sont plus difficiles à analyser
Robert Fraser
3
@Fraser si vous pensez que l'analyse XML est difficile, vous vous trompez de métier.
SnakeDoc
@SnakeDoc, Harder ne veut pas dire plus difficile. Cela signifie simplement une analyse et un décalage plus lents.
Pacerier
12

Quand - Vous êtes obligé de le faire en raison de l'intégration héritée ou parce que l'administrateur système de votre client dit "il en sera ainsi" ou parce que vous développez dans un langage plus ancien qui rend l'utilisation de XML plus difficile.

Pourquoi - Principalement parce que le registre n'est pas aussi portable que la copie d'un fichier de configuration qui se trouve à côté de l'application (et s'appelle presque la même chose).

Si vous utilisez .Net2 +, vous avez des fichiers App.Config et User.Config et vous n'avez pas besoin d'enregistrer les DLL dans le registre, alors évitez-les.

Les fichiers de configuration ont leurs propres problèmes (voir ci-dessous), mais ceux-ci peuvent être codés et vous pouvez modifier votre architecture.

  • Problème: les applications nécessitaient des paramètres configurables.
  • Solution: stockez les paramètres dans un fichier (WIN.INI) dans le dossier Windows - utilisez les en-têtes de section pour regrouper les données (Win3.0).
  • Problème: le fichier WIN.INI est devenu trop gros (et est devenu désordonné).
  • Solution: stockez les paramètres dans les fichiers INI dans le même dossier que l'application (Win3.1).
  • Problème: nécessite des paramètres spécifiques à l'utilisateur.
  • Solution: stockez les paramètres utilisateur dans des fichiers INI spécifiques à l'utilisateur dans le répertoire Windows de l'utilisateur (Win3.11) ou dans des sections spécifiques à l'utilisateur dans le fichier INI de l'application.
  • Problème: Sécurité - certains paramètres d'application doivent être en lecture seule.
  • Solution: Registre avec sécurité ainsi que sections spécifiques à l'utilisateur et à l'échelle de la machine (Win95).
  • Problème: le registre est devenu trop volumineux.
  • Solution: le registre spécifique à l'utilisateur a été déplacé vers user.dat dans le propre dossier «Application Data» de l'utilisateur et chargé uniquement lors de la connexion (WinNT).
  • Problème: dans les grands environnements d'entreprise, vous vous connectez à plusieurs machines et devez configurer CHACUN.
  • Solution: faites la différence entre les profils locaux (Paramètres locaux) et itinérants (Données d'application) (WinXP).
  • Problème: Impossible de xcopy déployer ou déplacer des applications comme le reste de .Net.
  • Solution: fichier XML APP.CONFIG dans le même dossier que l'application -, facile à lire, facile à manipuler, facile à déplacer, peut suivre s'il est modifié (.Net1).
  • Problème: il faut encore stocker les données spécifiques à l'utilisateur d'une manière similaire (c'est-à-dire xcopy deploy).
  • Solution: fichier XML USER.CONFIG dans le dossier local ou itinérant de l'utilisateur et fortement typé (.Net2).
  • Problème: les fichiers CONFIG sont sensibles à la casse (pas intuitifs pour les humains), nécessitent des "balises" d'ouverture / fermeture très spécifiques, les chaînes de connexion ne peuvent pas être définies au moment de l'exécution, les projets d'installation ne peuvent pas écrire les paramètres (aussi facilement que le registre), ne peuvent pas facilement déterminer Le fichier user.config et les paramètres utilisateur sont soufflés à chaque nouvelle révision installée.
  • Solution: utilisez le membre ITEM pour définir des chaînes de connexion au moment de l'exécution, écrivez du code dans une classe Installer pour modifier App.Config lors de l'installation et utilisez les paramètres de l'application par défaut si aucun paramètre utilisateur n'est trouvé.
AndrewD
la source
C'est une réponse beaucoup plus complète que celle approuvée. Merci @AndrewD.
rotman
8

Le monde va-t-il se terminer si vous stockez quelques positions de fenêtre et une liste des éléments les plus récemment utilisés dans le registre Windows? Cela a bien fonctionné pour moi jusqu'à présent.

HKEY-CURRENT-USER est un excellent endroit pour stocker des données utilisateur triviales en petites quantités. C'est pour ça que c'est. Il semble idiot de ne pas l'utiliser aux fins prévues simplement parce que d'autres en ont abusé.

Angus Glashier
la source
et c'est génial pour se corrompre ... c'est un plus. Moins de travail pour l'utilisateur à faire ...
SnakeDoc
4

Les paramètres que vous souhaitez voir disponibles dans le profil itinérant d'un utilisateur devraient probablement aller dans le registre, à moins que vous ne souhaitiez réellement chercher à rechercher manuellement le dossier Application Data de l'utilisateur. :-)

Chris Jester-Young
la source
4

Les lectures et écritures du registre sont sûres pour les threads, mais les fichiers ne le sont pas. Cela dépend donc du fait que votre programme soit ou non à thread unique.

Martin
la source
2

Si vous développez une nouvelle application et que vous vous souciez de la portabilité, vous ne devriez JAMAIS stocker de données dans le registre Windows car les autres systèmes d'exploitation n'ont pas de registre (Windows) (note duh - cela peut être évident mais est souvent négligé).

Si vous ne développez que pour les plates-formes Win ... essayez de l'éviter autant que possible. Les fichiers de configuration (éventuellement cryptés) sont une solution bien meilleure. Il n'y a aucun gain à stocker des données dans le registre - (le stockage isolé est une bien meilleure solution, par exemple si vous utilisez .NET).

JohnIdol
la source
Ceci est partiellement vrai. Mono a implémenté l'espace de noms Microsoft.win32 pour les registres - sauf qu'il le stocke dans un fichier dans ~ / .mono / Registry dans un fichier xml, et il est géré de manière transparente. Maintenant, si vous pouviez activer la gestion xml pour n'importe quelle application, quelle que soit la plate-forme ...
Robert P
Remarque: disponible uniquement si vous écrivez une application .NET / Mono.
Robert P
Le registre offre un gain: les données sont plus facilement accessibles dans une application multi-thread. Plus important encore, il vous permet de séparer les données de configuration spécifiques à la machine et spécifiques à l'utilisateur. Votre application n'a pas besoin de savoir qui est connecté lorsqu'elle accède à HKEY_CURRENT_USER. Vous avez cependant raison sur la portabilité.
James
2

Un peu hors sujet, mais comme je vois des gens préoccupés par la portabilité, la meilleure approche que j'ai jamais utilisée est la classe QSettings de Qt. Il fait abstraction du stockage des paramètres (registre sous Windows, fichier de préférences XML sous Mac OS et fichiers Ini sous Unix). En tant que client de la classe, je n'ai pas à passer un cycle cérébral à m'interroger sur le registre ou quoi que ce soit d'autre, ça marche juste (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

rlerallut
la source
Il semble que l'URL ne fonctionne plus. Une référence de mise à jour devrait être qt-project.org/doc/qt-5/QSettings.html#details
Eineki
0

Habituellement, si vous ne mettez pas de paramètres dans le registre, vous l'utilisez principalement pour obtenir les paramètres Windows actuels, modifier les associations de fichiers, etc.
Maintenant, si vous devez détecter si votre logiciel est déjà installé, vous pouvez faire une entrée minimale dans le registre , c'est un emplacement que vous pouvez retrouver dans n'importe quelle configuration. Ou recherchez un dossier du nom donné dans Application Data.

Si je regarde mon dossier Document and Settings, je vois beaucoup de logiciels utilisant la notation par points Unix pour définir les dossiers: .p4qt .sqlworkbench .squirrel-sql .SunDownloadManager .xngr .antexplorer .assistant .CodeBlocks .dbvis .gimp-2.4 .jdictionary .jindent .jogl_ext (etc.)

et dans Application Data, divers dossiers avec des noms d'éditeurs ou des noms de logiciels. On dirait que c'est la tendance actuelle, au moins parmi les applications portables ...
WinMerge utilise une approche légèrement différente, stockant les données dans le registre, mais offrant des options d'importation et d'exportation dans la boîte de dialogue de configuration.

PhiLho
la source
La notation par points Unix que vous voyez est probablement due au fait que tous ces exemples sont des projets open source portés, pas parce que c'est une meilleure pratique pour le développement Windows.
James
En effet, je n'ai pas dit que c'était "meilleure pratique", mais pratique courante ... :) Les dossiers dans l'application data / are / best practice, notamment pour le big data, mais aussi parce qu'ils sont plus faciles à sauvegarder.
PhiLho
0

Personnellement, j'ai utilisé le registre pour stocker les chemins d'installation à utiliser par les scripts de (dés) installation. Je ne sais pas si c'est la seule option possible, mais cela me semblait être une solution sensée. C'était pour une application qui était uniquement utilisée sous Windows, bien sûr.

chillysapien
la source
0

(en retard à la discussion mais) Réponse courte: Stratégie de groupe.

Si le service informatique de votre client souhaite appliquer des paramètres liés à Windows ou au (x) composant (s) que vous écrivez ou regroupez, comme une vitesse de liaison, un message d'erreur personnalisé ou un serveur de base de données auquel se connecter, cela reste généralement fait via la stratégie de groupe, qui en fait sa manifestation ultime sous forme de paramètres stockés dans le registre. Ces politiques sont appliquées à partir du moment où Windows démarre ou que l'utilisateur se connecte.

Il existe des outils pour créer des modèles ADMX personnalisés qui peuvent mapper les paramètres de vos composants aux emplacements de registre, et donner à l'administrateur une interface commune pour appliquer les stratégies qu'il doit appliquer tout en leur montrant uniquement les paramètres qui sont significatifs pour appliquer de cette manière.

Spencer
la source
-1

Je pense que le registre Windows était une bonne idée, mais à cause des grands abus de la part des développeurs d'applications et des politiques standard non encouragées / mandatées par Microsoft, il est devenu une bête ingérable. Je déteste l'utiliser pour les raisons que vous avez mentionnées, il y a cependant des occasions où cela a du sens de l'utiliser:

  • Laisser une trace de votre application après la désinstallation de votre application (par exemple, mémoriser les préférences de l'utilisateur au cas où l'application serait de nouveau installée)
  • Partager les paramètres de configuration entre différentes applications - composants
kgiannakakis
la source
5
Je ne suis pas d'accord avec vous concernant votre premier point, "[l] espérer une trace de votre application après que votre application a été désinstallée". Je préfère que si je dis "retirez-vous de mon système" que votre application soit totalement conforme. Je suppose que ce serait différent si vous demandiez à l'utilisateur s'il est correct de laisser quelque chose derrière, mais même dans ce cas, je voudrais probablement que ce soit un fichier de configuration enregistré. Nonobstant les licences, etc.
AgentConundrum
2
De nombreuses applications le font et vous avez raison de dire que ce n'est pas une très bonne chose, surtout si elles le font sans l'autorisation de l'utilisateur. Cependant, c'est souvent la fonctionnalité que les utilisateurs attendent d'une application (la majorité des utilisateurs ne savent pas ce qu'est le registre). Les utilisateurs s'attendent simplement à retrouver leurs paramètres automatiquement par magie, lorsqu'ils désinstallent et réinstallent.
kgiannakakis
2
Je pense que nous avons trouvé ici un auteur de malware. Ne laissez jamais la merde de votre programme sur le système de quelqu'un s'il vous a demandé de le désinstaller. Au moins, demandez-leur s'ils veulent se souvenir des paramètres, etc. Ne le faites jamais. Que faire si vous stockez une clé de licence et que je vends mon ordinateur? Que faire si votre programme causait des problèmes sur mon ordinateur et que j'essayais de le désinstaller pour le résoudre? Eh bien, les restes de votre registre pourraient me causer beaucoup de problèmes. Ne fais pas ça. Ne le fais pas.
SnakeDoc