logo标签列表

为什么存在Windows注册表？

windowsunixregistry
45
这更像是一个操作系统架构问题，而不是直接的编程问题。为什么创建Windows注册表作为完全独立的子系统来存储系统/应用程序设置？在*nix操作系统中，有一个/ etc目录，这是可以理解的，因为文件系统是一种自然的分层存储设置的方式，而Microsoft决定创建一个完全独立的分层子系统，这似乎是一个愚蠢的投资，他们为什么不使用文件系统层次结构呢？
21
我很愿意看到你证明文件系统是更自然的操作方式。 - Rob
4
我认为这应该是社区维基（Community Wiki）。 - Seb
8
你有没有看过最近Linux系统中的/etc/目录下的文件？总共有2389个文件，包括子目录。这些文件并不是一致的，也不是很简单。尽管其中一些可能是可以理解的——像sendmail.cf、named.conf和ntp.conf这样的文件从来都不是完全易懂的。 - nos
10
你有查看最近Linux系统中的"/etc"目录吗？- 是的，我查过了。你有通过注册表编辑器(regedit)查看最近Windows系统中的注册表吗？那里有多少个键和子树（它们的含义和原因显然不为你所知）？ - justadreamer
9个回答
54
  1. 集中式 - 适用于漫游配置文件。
  2. 事务性 - 可以使配置更加不易被破坏。
  3. 安全性 - 您可以比文件更细粒度地强制执行读/写权限（每个键/值）。
15
简明扼要的总结不错。 - Michael Burr
2
注册表中的事务是什么？您是指单个值更新是原子的吗？还是您指的是Vista的事务性注册表（这显然是最近的发展）？当然，如果每个值都是单独的文件，则可以在文件中使用每个键/值ACL（我记得IBM有一些类似于Linux注册表的东西实际上是这样做的...）。 - Pavel Minaev
个别更新是交易的 - 这种情况自NT 3.1以来就存在了。与平面文件不同，更新需要读取/更改/写入序列，这可能会损坏文件。 - Larry Osterman
集中化 - /etc 也是集中化的（默认情况下由 root 拥有，除非你在某些子目录上设置了不同的权限）事务性 - 嗯，现代文件系统的文件系统写操作也是事务性的，健壮性非常重要，我从未见过 /etc 被破坏，但我经常看到 Windows 注册表被破坏。安全性/细粒度 - 这肯定是 /etc 的一个缺点。然而，在 /etc 中拥有通用设置，同时将用户首选项存储在用户主目录中也更简单。 - justadreamer
2
@justadreamer：/etc是集中的，但许多应用程序在注册表之前的状态是将配置文件放入“。”；注册表是一种替代方法。文件系统最多提供文件级别的事务（并且并非所有正在使用的文件系统都是如此）；这意味着要以事务方式更新配置文件，您必须将整个文件存储在内存中-您无法将单个键更新为事务。按任何定义来说，在/ etc和〜与HKLM和HKCU中存储东西并不更简单；它们是等效的分区。 - Kevin Montrose
显示剩余2条评论
13
谢谢，非常好的文章。它真正证明了为什么注册表比ini文件好得多。然而，在*nix下的/etc概念和用户特定设置在主目录中比旧的ini文件更广泛。 - justadreamer
12

这样，当二进制注册表损坏时，你只需放弃并购买最新版本的Windows进行全新安装。

不错的观点 :) 我经常看到注册表损坏的情况。 - justadreamer
7
  • 每个应用程序不必重新发明配置文件格式
  • 您可以轻松地在内核模式代码中使用注册表

如Bastien所引用的Old New Thing文章中提到的：

  • 系统可以为您处理并发问题
  • 您可以对注册表键进行ACL

我还要提到许多*nix框架已经重新发明了注册表... 就像GNOME上的gconfd。

1
gconfd只是一个GUI前端，用于管理位于您的主目录中的纯文本配置文件。不过还是很不错的尝试。 - Vitali
4
注册表编辑器只是一个图形用户界面，用于编辑保存在系统目录中的编码配置文件。不过你说得不错。 - snicker
3
@gVitali -- Uh. gconf是一组用于配置数据的结构化键值对，就像注册表一样。 - asveikau
7
此外，文件系统的粒度：每个值一个簇有点过于多了，因此需要在文件系统结束和设置文件开始之间进行权衡。当然，这并不能给您一个一致的API。那么为什么不将所有设置都放入几个关键文件中，并提供一个一致的API来访问它呢？BAM-注册表。
（由于微软通常认为API比格式更重要，所以文件是不透明的并不奇怪）
[雷蒙德·陈的声音]记住，它是为只有4MB RAM的计算机设计的。[/雷蒙德·陈的声音]
任何现代文件系统都不会为每个值提供一个簇，因为它们知道如何直接在分配表中打包小文件流。NTFS就是这样做的；请参见http://en.wikipedia.org/wiki/Ntfs#Resident_vs._non-resident_data_streams - Pavel Minaev
不错的观点，Pavel。（注册表的年龄保留了我的答案 - 哎呀！） - peterchen
1

这个想法是将所有程序的所有设置都存储在一个单一的位置，而不是让它们分散在您的磁盘上。

7
或许最初的设计是正确的，只是微软在设计程序文件夹、公共程序文件夹、用户主目录、用户应用数据、用户本地应用数据和所有用户应用数据时没有想到这一点。没有批评，只是我旧时的抱怨之一。 - peterchen
@peterchen - 不，不是的。你说得有道理。尽管我承认，也许最初是这样考虑的，然后随着历史的发展，必需品迫使考虑其他事情...但正如我在回复 @yogman 的评论中所说，为什么不使用Unix的配置文件不同优先级的原则呢？ - Rook
3
事实上，如今Windows的最佳实践强烈建议不要将设置存储在注册表中，而应该使用配置文件（最好是人类可读的）来进行设置。将注册表保留给操作系统设置、文件关联和COM组件。 - Pavel Minaev
1
@PavelMinaev，你有这样的建议链接吗？我很感兴趣看到所有的论点，因为我不知道（尽管我几乎总是使用配置文件）。 - julealgon
@peterchen 只是补充一下，Program Files (x86)，SysWOW64，winsxs，drivers，DriverStore... - IGRACH
1

我相信他们这样做是为了支持每个登录用户的单独设置。在Unix中，有一个家目录的概念，而在Windows中没有。

并不完全正确...为什么不使用像vim一样的方案呢...从更高级别的目录加载vimfiles（由管理员指定），然后从较低级别的目录加载vimfiles（由用户指定），必要时覆盖前一个...问题是为什么需要整个注册表被加载，而不是针对单独的程序。 - Rook
在Windows中（只要我们谈论NT），有一个用户主目录的概念。在像Win9x这样的单用户操作系统上，它无论如何都不相关。 - Pavel Minaev
有没有Win32 API或环境变量可以做到这一点？我很好奇。 - yogman
0

首先，在用户会话期间读写注册表更快。

-2

它创建了整个系统应用程序配置控制的单一入口。这本来是一个内嵌网络数据库（例如 Rational 使用的 Raima）或文本数据库（Bernstein 的 cdb）的不错用例。

1
在1989年的一台386电脑上，拥有12MB RAM，使用哪种嵌入式、快速的网络数据库是合适的？ - Michael
@Michael：如果接口和实现分开，底层结构就可以轻松地用嵌入式数据库替换。无论如何，为了争论而争论，我相信Raima和cdb在89年的DOS系统中都已经存在。 - srini.venigalla
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接