系统与基础设施rwmj.wordpress.com
为什么 Windows 注册表在技术上很糟糕（2010）
Why the Windows Registry sucks technically (2010)
2010 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这是 rwmj（Richard W.M. Jones）2010 年的一篇技术批评文章，逐条拆解 Windows 注册表在实现层面的问题：把注册表做成单一文件里的伪文件系统、只能通过专用 API 读写二进制数据、备份与合并困难、缺乏真正的并发与事务语义等。作者的语气是就事论事的技术剖析，而非情绪化吐槽。
为什么经久不衰：注册表至今仍是 Windows 的核心组件，文中指出的"单一 hive 文件 + 伪文件系统 + 无通用文本格式"这些取舍，今天依然是讨论配置该存在哪、怎么存的经典参照系。
HN 评论精选
文章不够深入：单文件设计才是注册表一切问题的根源，作者却轻描淡写地放过了。
我觉得这篇文章不值得在 12 年后重新翻出来。它漏掉了注册表真正糟糕的几个关键原因，而有些批评（比如"我们必须精确写出 Windows 期望的那些字节"——那当然，它本来就只该通过 API 修改）也没怎么想清楚。文章用"你用 ext3 也能干同样的事"来打发"注册表是单文件里的蹩脚文件系统"这一批评，这不是好理由：别人也能做类似的事，不代表注册表这么做就是对的。单文件恰恰是大量问题的根源——它导致全有或全无的语义，也迫使它自己实现一套糟糕的文件系统而不是用底层真实文件系统。
greenthrow查看英文原文
I don't feel like this article is good enough to be worth resharing 12 years later. It missed some of the key reasons why the Registry is bad and other criticisms ("We have to write exactly the bytes Windows expects." yeah of course you do. It's only meant to be changed using APIs.) are not very well thought out. The criticism that the Registry is a janky filesystem in a single file is dismissed because you can do the same thing with ext3. That's not a good reason to dismiss it. Just because you can do a similar thing doesn't mean it is a good thing to do for the Registry. The Registry being a single file is a cause of a ton of problems, and is IMHO the root of all the other problems. If this were a better technical article it would go into that instead of hand waving it away. (E.g. it being a single file leads to the all or nothing nature of it. It necessitates the bad filesystem implementation instead of using the actual underlying filesystem, etc.)
注册表本质接近键值数据库；UNIX 的 /etc 更灵活但格式碎片化，双方都有配置残留无法清理的问题。
我很欣赏用技术事实来批评的做法，这篇对 2010 年乃至今天注册表实现的剖析写得很扎实。我猜如果注册表这个概念是今天才发明的，它会更像数据库（比如 SQLite）；不过按虚拟文件系统来组织确实有吸引力，可惜我不知道有哪个数据库引擎支持这种布局。注册表的键值对和数据库表的列值是一一对应的，难的是上面那几层"文件夹"式的组织。UNIX 那套无疑更灵活，因为它不是虚拟文件系统，它就是文件系统；但问题在于每个人都在 /etc 里发明自己的配置格式，没有一个与格式无关的 API 去读这些信息（你能打开文件，但你能看懂吗？）。另外两个世界都有同样的孤儿问题：数据写进去了、程序卸载了，却不敢删，因为你不知道作者是谁、还有谁在消费它。
Someone1234查看英文原文
I really appreciate when people use technical facts to criticize something, like with this. It is a well written take-down of the implementation of the Windows Registry as of both today and 2010. I suspect if the concept of the registry was created today it would look more like a database (e.g. Sqlite), although organizing it like a virtual FileSystem does have a certain appeal, and unfortunately I don't know of a database engine that supports such a layout. The Registry's Key-Value pairs are 1:1 with a database table's column-values pairs, it is just the multiple tiers of organizing "folders" above that that are a difficult implementation detail. The UNIX way is undeniably more flexible since it isn't a virtual filesystem, it is just a filesystem. The problem is that everyone invented their own configuration format to store configuration data in /etc and there's no format agnostic API to access that information (you can open it, but can you understand it?). Both UNIX and Windows suffer from the same orphan issue wherein information can be written, the application removed, and it is unsafe to ever remove it since you may not know the author and or all consumers.
在当年磁盘昂贵的背景下，把微小配置项集中存进单文件是为了节省空间。
文章和评论都忽略了一点：注册表里的记录大概每条只占 10–100 字节，而一个真实文件至少要占 1KB（可能更接近 4KB）。在注册表诞生年代的老机器上，把这种极小的"文件"塞进一个专门格式里是显而易见的选择。我猜节省空间本来就是创造注册表的动机之一。
veltas查看英文原文
A point being overlooked by article and commenters: the records in the registry probably use in the order of 10-100 bytes each, while every actual file takes up at least around 1024 (EDIT: maybe more like 4096?) bytes. Putting tiny 'files' into a special format is a no-brainer on the older computers that existed when the Registry was first created. I am assuming this was one of the motivations to create the Registry in the first place, to save space.
注册表最初是为解决 INI 文件读取慢和磁盘损坏问题而生，后来被各方滥用成通用存储。
理解它何时、为何被创造出来会有帮助。据我印象中的内部传说：当时开发者把设置存在 \Windows 目录下的 INI 文件里，读取这种 name=value 文件非常慢。注册表是为了集中存储这些数据、加快应用启动时读取设置的速度，并能更稳健地应对磁盘损坏。当然，它诞生之后，COM、MSI/Darwin 等等全都把它当通用存储滥用。如今 XML 解析已经够快，官方反而鼓励应用把私有配置放在自己的目录、把每用户配置放在用户目录。
larsberg查看英文原文
It helps to realize when and why it was created. The internal lore, as best I recall it is below... At the time, application developers stored settings in INI files in the \Windows directory. Reading this name=value file was very slow. The registry was an attempt to centralize storage of that data, speed up application startup by reducing the time required to settings data from it, and to respond robustly to disk corruption. Of course, after it was created, everybody and their grandpappy (COM, MSI/Darwin, etc.) decided to abuse it as a general-purpose store. Now that XML file load is considered zippy enough to be done at application start, developers are encouraged to have a private configuration file in their own application directory and per-user ones in the per-user directories.
历次讨论
同类还值得读
TTY 揭秘（2008）
The TTY demystified (2008)
经典文章深入剖析了 Unix/Linux 中 TTY 子系统的工作原理，包括线路规程、终端驱动、信号与控制字符等机制。
系统与基础设施上首页 11 次 · 2009–2025linusakesson.net编辑精选为什么 GNU grep 这么快
Why GNU grep is Fast
FreeBSD 邮件列表上一篇广为流传的帖子，解释 GNU grep 为什么快：核心在于 Boyer-Moore 字符串搜索算法配合精心优化的内部循环和 I/O，让程序在搜索时“…
系统与基础设施上首页 9 次 · 2010–2022lists.freebsd.orgXplain：为普通人讲解 X11
Xplain – Explaining X11 for the rest of us
《Xplain》是作者（HN 用户 Jasper_）写的一系列 X11 长文，用他在浏览器中重建的 X11 绘图模型做交互演示，讲解 X11 的绘图模型与窗口系统设计。
系统与基础设施上首页 6 次 · 2013–2020magcius.github.io编辑精选旋风教程：为 Linux 创建极小 ELF 可执行文件（1999）
A Whirlwind Tutorial on Creating Really Teensy ELF Executables for Linux (1999)
breadbox 写于 1999 年的经典教程，主题是如何为 Linux 手工构造并裁剪出体积极小的 ELF 可执行文件。
系统与基础设施上首页 6 次 · 2007–2025muppetlabs.comPostgreSQL 内部原理
The internals of PostgreSQL
《The Internals of PostgreSQL》是一本免费在线书籍，系统讲解 PostgreSQL 的内部实现，包括查询处理、并发控制、WAL、缓冲区管理等核心机制。
系统与基础设施上首页 5 次 · 2017–2025interdb.jp编辑精选