何时 - 以及为什么 - 您应该将数据存储在 Windows 注册表中？

When - and why - should you store data in the Windows Registry?

提问by Roddy

As a developer, tools that store configuration/options in the registry are the bane of my life. I can't easily track changes to those options, can't easily port them from machine to machine, and it all makes me really yearn for the good old days of .INI files...

作为开发人员，在注册表中存储配置/选项的工具是我生命中的祸根。我无法轻松跟踪对这些选项的更改，无法轻松地将它们从一台机器移植到另一台机器，这一切让我真的很怀念 .INI 文件的美好时光……

When writing my own applications, what - if anything - should I choose to put in the registry rather than in old-fashioned configuration files, and why?

在编写我自己的应用程序时，我应该选择将什么（如果有的话）放在注册表中而不是老式的配置文件中，为什么？

采纳答案by James Curran

• Originally (WIN3) configuration was stored in the WIN.INI file in the windows directory.
• Problem: WIN.INI grew too big.
• Solution (Win31): individual INI files in the same directory as the program.
• Problem: That program may be installed on a network and shared by many people.
• Solution(Win311): individual INI files in the user's Window directory.
• Problem: Many people may share a windows folder, and it should be read-only anyway.
• Solution (Win95): Registry with separate sections for each user.
• Problem: Registry grew too big.
• Solution (WinXP): Large blocks of individual data moved to user's own Application Data folder.
• Problem: Good for large amounts of data, but rather complex for small amounts.
• Solution (.NET): small amounts of fixed, read-only data stored in .config (Xml) files in same folder as application, with API to read it. (Read/write or user specific data stays in registry)

• 原来（WIN3）配置保存在windows目录下的WIN.INI文件中。
• 问题：WIN.INI 变得太大了。
• 解决方案 (Win31)：与程序位于同一目录中的单个 INI 文件。
• 问题：该程序可能安装在网络上并被许多人共享。
• 解决方案（Win311）：用户窗口目录中的单个 INI 文件。
• 问题：许多人可能共享一个 windows 文件夹，无论如何它应该是只读的。
• 解决方案（Win95）：每个用户都有单独的部分的注册表。
• 问题：注册表变得太大了。
• 解决方案 (WinXP)：大块的个人数据移动到用户自己的应用程序数据文件夹中。
• 问题：适用于大量数据，但对于少量数据则相当复杂。
• 解决方案 (.NET)：少量固定的只读数据存储在与应用程序相同的文件夹中的 .config (Xml) 文件中，使用 API 读取它。（读/写或用户特定数据保留在注册表中）

回答by Jimoc

Coming at this both from a user perspective and a programmers perspective I would have to say there really isn't a good exceuse to put something in the registry unless it is something like file associations, or machine specific settings.

从用户的角度和程序员的角度来看，我不得不说真的没有一个很好的借口将某些东西放在注册表中，除非它是文件关联或机器特定设置之类的东西。

I come from the school of thought that says that a program should be runnable from wherever it is installed, that the installation should be completely movable within a machine, or even to another machine and not affect the running of it.

我来自这样的学派，即程序应该可以从安装的任何地方运行，安装应该可以在一台机器内完全移动，甚至可以移动到另一台机器上，而不影响它的运行。

Any configurable options, or required dlls etc, if they are not shared should reside in a subdirectory of the installation directory, so that the whole installation is easily moved.

任何可配置的选项或所需的 dll 等，如果它们不被共享，则应驻留在安装目录的子目录中，以便轻松移动整个安装。

I use a lot of smaller utility like programs, so if it cant be installed on a usb stick and plugged into another machine and just run, then its not for me.

我使用了很多较小的实用程序，如程序，所以如果它不能安装在 U 盘上并插入另一台机器并运行，那么它不适合我。

回答by AndrewD

When- You are forced to due to legacy integration or because your customer's sysadmin says "it shall be so" or because you're developing in an older language that makes it more difficult to use XML.

何时- 由于遗留集成或因为您客户的系统管理员说“应该如此”或因为您正在使用较旧的语言进行开发，这使得使用 XML 变得更加困难，所以您被迫这样做。

Why- Primarily because the registry is not as portable as copying a config file that is sitting next to the application (and is called almost the same).

为什么- 主要是因为注册表不像复制位于应用程序旁边的配置文件那样可移植（并且调用几乎相同）。

If you're using .Net2+ you've got App.Config and User.Config files and you don't need to register DLL's in the registry so stay away from it.

如果你使用 .Net2+ 你有 App.Config 和 User.Config 文件，你不需要在注册表中注册 DLL，所以远离它。

Config files have their own issues (see below), but these can be coded around and you can alter your architecture.

配置文件有它们自己的问题（见下文），但是这些可以被编码并且你可以改变你的架构。

• Problem: Applications needed configurable settings.
• Solution: Store settings in a file (WIN.INI) in the Windows folder - use section headings to group data (Win3.0).
• Problem: WIN.INI file grew too big (and got messy).
• Solution: Store settings in INI files in the same folder as the application (Win3.1).
• Problem: Need user-specific settings.
• Solution: Store user-settings in user-specific INI files in the user's Window directory (Win3.11) or user-specific sections in the application INI file.
• Problem: Security - some application settings need to be read-only.
• Solution: Registry with security as well as user-specific and machine-wide sections (Win95).
• Problem: Registry grew too big.
• Solution: User-specific registry moved to user.dat in the user's own "Application Data" folder and only loaded at login (WinNT).
• Problem: In large corporate environments you log onto multiple machines and have to set EACH ONE up.
• Solution: Differentiate between local (Local Settings) and roaming (Application Data) profiles (WinXP).
• Problem: Cannot xcopy deploy or move applications like the rest of .Net.
• Solution: APP.CONFIG XML file in same folder as application - , easy to read, easy to manipluate, easy to move, can track if changed (.Net1).
• Problem: Still need to store user-specific data in a similar (i.e. xcopy deploy) manner.
• Solution: USER.CONFIG XML file in user's local or roaming folder and strongly-typed (.Net2).
• Problem: CONFIG files are case-sensitive (not intuitive to humans), require very specific open/close "tags", connection strings cannot be set at run-time, setup projects cannot write settings (as easily as registry), cannot easily determine user.config file and user settings are blown with each new revision installed.
• Solution: Use the ITEM member to set connection strings at runtime, write code in an Installer class to change the App.Config during install and use the application settings as defaults if a user setting is not found.

• 问题：应用程序需要可配置的设置。
• 解决方案：将设置存储在 Windows 文件夹中的文件 (WIN.INI) 中 - 使用部分标题对数据进行分组 (Win3.0)。
• 问题：WIN.INI 文件变得太大（并且变得凌乱）。
• 解决方案：将设置存储在与应用程序 (Win3.1) 相同的文件夹中的 INI 文件中。
• 问题：需要用户特定的设置。
• 解决方案：将用户设置存储在用户窗口目录 (Win3.11) 中用户特定的 INI 文件中或应用程序 INI 文件中的用户特定部分。
• 问题：安全性 - 某些应用程序设置需要只读。
• 解决方案：具有安全性的注册表以及特定于用户和机器范围的部分 (Win95)。
• 问题：注册表变得太大了。
• 解决方案：特定于用户的注册表已移至用户自己的“应用程序数据”文件夹中的 user.dat，并且仅在登录 (WinNT) 时加载。
• 问题：在大型企业环境中，您登录到多台机器并且必须设置每一台。
• 解决方案：区分本地（Local Settings）和漫游（Application Data）配置文件 (WinXP)。
• 问题：无法 xcopy 像 .Net 的其余部分一样部署或移动应用程序。
• 解决方案：APP.CONFIG XML 文件与应用程序在同一文件夹中 - ，易于阅读，易于操作，易于移动，如果更改可以跟踪（.Net1）。
• 问题：仍然需要以类似（即 xcopy 部署）的方式存储用户特定的数据。
• 解决方案：用户本地或漫游文件夹中的 USER.CONFIG XML 文件和强类型 (.Net2)。
• 问题：CONFIG 文件区分大小写（对人类来说不直观），需要非常具体的打开/关闭“标签”，无法在运行时设置连接字符串，安装项目无法写入设置（就像注册表一样容易），无法轻松确定user.config 文件和用户设置随着安装的每个新版本而被破坏。
• 解决方案：使用 ITEM 成员在运行时设置连接字符串，在 Installer 类中编写代码以在安装期间更改 App.Config，如果未找到用户设置，则使用应用程序设置作为默认值。

回答by Toon Krijthe

Microsoft policy:

微软政策：

• Before windows 95, we used ini files for application data.
• In the windows 95 - XP era, we used the registry.
• From windows Vista, we use ini files although they are now xml based.

• 在 windows 95 之前，我们使用 ini 文件作为应用程序数据。
• 在windows 95-XP时代，我们使用了注册表。
• 在 Windows Vista 中，我们使用 ini 文件，尽管它们现在是基于 xml 的。

The registry is machine dependent. I have never liked it because its getting to slow and it is almost imposible to find the thing you need. That's why I like simple ini or other setting files. You know where they are (application folder or a user folder) so they are easy portable, and human readable.

注册表依赖于机器。我从来不喜欢它，因为它变得很慢，而且几乎不可能找到你需要的东西。这就是为什么我喜欢简单的 ini 或其他设置文件。您知道它们的位置（应用程序文件夹或用户文件夹），因此它们易于携带且可读。

回答by Angus Glashier

Is the world going to end if you store a few window positions and a list of most recently used items in the Windows registry? It's worked okay for me so far.

如果您在 Windows 注册表中存储一些窗口位置和最近使用的项目列表，世界会结束吗？到目前为止，它对我来说没问题。

HKEY-CURRENT-USER is a great place to store trivial user data in small quantities. That's what it's for. It seems silly not to use for its intended purpose just because others have abused it.

HKEY-CURRENT-USER 是存储少量琐碎用户数据的好地方。这就是它的用途。仅仅因为其他人滥用它而不将其用于预期目的似乎很愚蠢。

回答by Chris Jester-Young

Settings that you want to have available in a user's roaming profile should probably go in the registry, unless you actually want to go to the effort of looking for the user's Application Data folder by hand. :-)

您希望在用户的漫游配置文件中可用的设置可能应该在注册表中，除非您确实想要手动查找用户的应用程序数据文件夹。:-)

回答by Martin

Registry reads and writes are threadsafe but files are not. So it depends on whether or not your program is single threaded.

注册表读取和写入是线程安全的，但文件不是。所以这取决于你的程序是否是单线程的。

回答by rlerallut

Slightly off-topic, but since I see people concerned about portability, the best approach I've ever used is Qt's QSettings class. It abstracts the storage of the settings (registry on Windows, XML preference file on Mac OS and Ini files on Unix). As a client of the class, I don't have to spend a brain cycle wondering about the registry or anything else, it Just Works (tm).

有点跑题了，但是因为我看到人们关心可移植性，所以我用过的最好的方法是 Qt 的 QSettings 类。它抽象了设置的存储（Windows 上的注册表、Mac OS 上的 XML 首选项文件和 Unix 上的 Ini 文件）。作为班级的客户，我不必花时间思考注册表或其他任何事情，它 Just Works (tm)。

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

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

回答by JohnIdol

If you are developing a new app and you care about portability you should NEVERstore data in windows registry since other OS don't have a (windows) registry (duh note - this may be obvious but gets often overlooked).

如果您正在开发一个新的应用程序并且您关心可移植性，则永远不要将数据存储在 Windows 注册表中，因为其他操作系统没有（Windows）注册表（废话注意 - 这可能很明显，但经常被忽视）。

If you're only developing for Win platforms ... try to avoid it as much as possible. Config files (possibly encrypted) are a way better solution. There's no gain in storing data into the registry - (isolated storage is a much better solution for example if you're using .NET).

如果你只是为 Win 平台开发......尽量避免它。配置文件（可能加密）是一种更好的解决方案。将数据存储到注册表中没有任何好处-（例如，如果您使用的是 .NET，则隔离存储是一个更好的解决方案）。

回答by chillysapien

Personally I have used the registry to store install paths for use by the (un)install scripts. I'm not sure if this is the only possible option, but seemed like a sensible solution. This was for an app that was solely in use on Windows of course.

我个人使用注册表来存储安装路径以供（卸载）安装脚本使用。我不确定这是否是唯一可能的选择，但似乎是一个明智的解决方案。这当然适用于仅在 Windows 上使用的应用程序。