引入注册表所谓的原因

首先，让我们来看一下为什么微软觉得要使用注册表而不是ini文件，下面是一些其列出来的ini方面的毛病：

ini文件不支持Unicode
ini文件的安全权限不够
ini文件在多进程下存取会有问题
如果一个进程锁上了这个文件，另一个进程就无法获得，只能出错。
ini文件只能包含字符串，无法使用二进制
解析ini文件相对来说性能比较慢，第一次读写都需要把整个文件读入内存，然后再写回去。
ini文件最大只有32K
ini文件的默认目录在Windows系统目录下，只能这个目录只能Windows管理员才能访问
ini只能包含了两层，对于多层不支持。
把ini文件放在中央服务器上管理很困难。
而微软说，注册表可以完美地解决这些问题。居然微软只说到了ini文件，但我觉得不单单是ini，所有的以纯文本方式保存配置文件的方法都会出现上述这样的问题。

我的观点

那么，当你在看到这些言论时，你是怎么想的？你有没有经过自己的独立思考？还是你觉得注册表完美地解决了所有的一切？下面是我的一些观点：

首先，我们要知道没有任何一件事是完美的，凡事必然有好的一面，也有不好的一面。
其次，当我们在改进一个东西时，不单单要解决其不好的东西，还要把其好的东西给传承下来。
所以，当你看到一些只说好或是只说坏的东西时，这往往意味着“宗教”或“洗脑”，这正是需要你独立思考的时候。

纯文本配置文件的好处

下面，是我觉得纯文本配置文件的好处（我用Unix下的纯文本配置文件来举例）：

很容易进行版本管理（配置文件和程序代码一样都需要版本控制）
很容易移植到别的平台
很容易自定义文本文件的格式和语法，已也有相关的库支持（ini只支持ANSI字符，只有32K，只支持两级，那是ini的问题，解决这些问题不需要引入注册表）
可以在配置文本中写注释信息
你要很容易的使用grep，awk，sed等等以及来和脚本集成。
你可以很容易地拆分配置文件把其放到conf.d中，这样一来，你就非常灵活
你就不用整个文件都读入内存，
你也可以分别设置上不同的存取权限，
同样可以减小多个进程同时存取的问题
同样可以引用别的二进制配置的文件
你可以很容易地产生备份或是在不同的配置中来回地切换配置文件以进行调试。
你可以很容易地使用rsync来向中央服务器同步你的配置文件。或者使用NFS/NIS直接就把配置放在中央服务器上。

真正的原因

可见，Windows 的注册表并没有把纯文本配置文件的这些好处都带过来，所以，经过这样的独立思考，我们可以知道，微软引入注册表的真正原因是——

让你的程序不具移植性，让你的软件永远运行在Windows上。
增加你编程的复杂度和你维护配置文件的复杂度，让你在痛苦之后，苦苦哀求微软再发布下一个“创新”。
各位程序员——Windows是很危险的，你们还是回火星去吧。