Windows 的註冊表是個好的設計嗎？

01-02

好壞是相對的，一個工具，脫離使用場景，沒有比較對象和比較標準，好壞就無從談起。難道你手拿著鎚子看什麼都是釘子？

順便說一下，假設將不穩定性的標準定義在使用者良莠不齊的話，就沒有不穩定的工具了。一些軟體的安裝卸載程序存在bug，一些軟體出錯需要通過改註冊表來修復，也證明不了註冊表本身有任何不穩定性。這有時候是訪問註冊表的程序的開發水平問題，有時候是設計師就這麼設計的，比如偷摸安裝不希望用戶能夠簡單卸載，或者故意不做界面/放到文件里以避免不小心修改到重要設置。

註冊表在Windows 3.1中引入時，是用來存儲COM組件的註冊信息。因為用戶可以自定義安裝路徑，這樣的組件需要一個全局性的註冊位置來讓其他程序在激活時查找其安裝、能力和需求信息。COM組件的註冊信息存儲到現在都沒有出現過替代品，所以無所謂好壞。

Windows 95開始微軟建議程序員用註冊表而不是用傳統的INI來保存配置。INI文件存在的問題Why are INI files deprecated in favor of the registry?提到了如下幾個：

Unicode支持
沒有鍵級別的安全性設置
多個程序同時寫入時會有衝突
無法防禦拒絕訪問攻擊
只能保存文本
文本解析慢
應用程序直接打開INI文件讀取，這意味著INI文件的格式無法擴展。實際上，因為讀取INI的代碼良莠不齊，基本上你存儲的文本值不能超過70個字元，否則一些程序會崩潰。
有32KB大小的限制
默認情況下，INI文件存放在系統目錄。Windows NT上的這個目錄只有管理員可以寫入，所以一些在系統目錄保存配置的程序在普通用戶身份下運行會出問題
INI文件結構只有兩層
與管理員集中管理INI比較困難

採用XML可以解決INI的一些問題，前提是每個人都只讀不寫，而且使用一個遵從標準的XML解析器。.當然，這僅限於應用程序自己用的數據。要註冊到系統的信息，比如註冊個文件格式，還是只能用約定俗成的註冊表，你註冊到別的地方其他的程序都不會鳥你。要找個替代的通用註冊信息共享協議的話，需要一些比較大的應用開發商聯合起來開會定一個通用的介面，然後確保這個API的實現在每台電腦上都安裝。但是微軟推自家的.Net都困難重重，推這樣的替代品看起來沒有什麼成功的可能。

單元化保護也是註冊表的功能之一。Windows採用日誌來保證註冊表的完整。即使在寫入註冊表的時候計算機掉電，註冊表的完整性也不會受到破壞。在Windows Vista之前是沒有操作系統級別的API來支持文件級別的Transactions操作的（想像一下你的電腦/平板/手機斷電造成遊戲進度/軟體註冊信息丟失的情形）。

很多人認為註冊表是存在問題的，然而註冊表的很多問題並不來自於註冊表自身。

第一點，註冊表過於龐大。並不是註冊表過於龐大，而是windows的配置過於龐大，又反過來導致windows只能依賴於註冊表來報錯。

第二點，註冊表不易於修改。不使用搜索很難從註冊表的樹型結構和繁多的表項中找到需要修改的值，同時註冊表中很多的目錄名稱的含義難以理解，另外因為太大了所以在修改時容易漏掉需要修改的值。當然這依然是windows和某些程序的鍋。

第三點，註冊表同一個表項可能會出現在多個位置容易迷惑人。hkcr,hkcu,hkus和hkcc實際上是hklm的鏈接，又因為windows特別喜歡用guid當目錄名，所以無論是hklm還是其他目錄，裡面都是各種的guid，雖然很多guid是相等的，但很容易讓人理解成是不同的表項。

是的

註冊表本質就是一個資料庫，所以資料庫的優點都有：acid，Unicode, 許可權管理，性能等等

不信的話拿ini xml json去實現一個抗掉電可以樹狀存儲支持許可權管理同時性能不輸註冊表的配置持久化方案，看看有多難。

這是什麼的圖標？

昨天不知怎麼搞的突然想到註冊表，看那個註冊表的圖標，突然發現人家是按照空間思考問題的，怪不得人家比我們高效，在人家看來那個樹形的註冊表是一種一層套一層，一個挨一個堆積起來的立方空間結構體，那個表面就是上圖那個「計算機」根節點。

我以前理解不了註冊表，昨天突然就一下子明白了，根本無需深入學習就知道它是幹什麼的怎麼乾的以及它是否是良好的，是否會存在下去，突破什麼邊界會是不良好的，怎樣避免突破那個邊界……

這是誰人設計的圖標？又是誰人封鎖的知識？是誰人在阻止我們不讓我們激活右腦？那些人真狹隘！

那些說計算機軟體行業不如同建築行業的人是根本不理解計算機軟體！你以為他們理解了，因為他們說像建築，結果他們又反悔了說不像建築，原來你突然發現他們其實根本從來就沒理解計算機軟體行業。

註冊表是直接掛在計算機根節點下的一片森林，雖然.NET開發的應用程序是不需要用註冊表的，之所以不需要用註冊表其實是把「註冊表」放在了應用系統的當地去了，分形到當地的配置目錄樹上去了。

昨天不知道怎麼回事就冒出了註冊表概念，剛才搜索了一下人們好像對windows中的註冊表很有抱怨。註冊表這個詞看來是不能提了。但註冊表應該是個好東西，windows算是一個系統，windows的註冊表如果只供微軟用的話就是個好東西，如果供第三方讀寫的話就不是好東西。許可權引擎的目錄樹應只供許可權引擎自己讀寫，若供第三方讀寫考慮走LDAP協議。

註冊表是個好設計，windows把它的所有軟硬體資源掛在了它的註冊表上，linux雖然沒有註冊表但是它的文件系統幹了註冊表乾的事情。操作系統是一種成熟的系統，我們的業務系統可以借鑒它們的設計也弄一個自己內部使用的「註冊表」把業務系統感知到的資源都掛上去。業務系統看作是操作系統的分形，而操作系統又是計算機硬體體系結構的分形，計算機硬體體系結構又是時空的分形。

要看怎麼比。

最早的時候Windows跟現在OS X的*.plist類似，用*.ini來儲存設置信息。它們都是純文本格式。

3.x的時候就有C:WINDOWSREGEDIT.EXE了，但當時文件格式比較簡單，用REGEDIT打開來看，裡面也不像現在的電腦一樣有一大堆數不完的數據。

這幾天正在研究一個SDK程序，因為是自己寫的小軟體，就不想專門搞個註冊表來存儲配置信息（其實也不會搞），所以用了*.ini來存，純文本格式瀏覽、修改也方便。

於是就去查幫助文檔，看看相關的函數怎麼用。一查就被噁心到了，GetPrivateProfileString()要求*.ini文件名必須帶有完整的路徑，只有文件名沒有路徑放在當前目錄下都不行。我不明白為什麼MS的人要這樣設計。好在可以用GetModuleFileName()先得到程序本身的完整文件名，再藉助於一些字元串函數來間接得到。

所以應該大家已經看出來了，用註冊表的一個好處就是把各個程序的數據都集中在一個地方，統一管理。

另外*.ini也有一些弊端，它的格式被固定為每一組以[&]開頭、然後一行行的&=&，但數據類型有很多種，還有雙字（REG_DWORD）、字元串數組（REG_MULTI_SZ），以及設備驅動器資源列表（REG_RESOURCE_LIST）等等，雙字還可分為大小端序，字元串里還可以包含有%path%等環境變數，不可能總是普通的字元串。另外文本處理起來也不如二進位快，比如要記下程序退出時窗口的大小、位置等，一般是存儲在註冊表裡的，用文本格式去儲存效率不高。

但註冊表的特點也決定了只有對Windows非常了解的用戶才懂得怎麼去操作它，不了解的人去盲目地修改，容易造成系統出現問題。普通用戶面對這種格式自然一頭霧水，不如純文本的*.ini那樣清晰明了。

那些方便攜帶的綠色小軟體，應該用*.ini，讓普通用戶也能看懂裡面的內容，不去修改系統目錄，減少犯強迫症的機會。而對於那些龐大複雜的軟體，顯然註冊表更適合。

把註冊表影射到文件系統上就好了，用file explorer代替註冊表編輯器。

初覺得有了註冊表後，軟體綠色化難度加大，商業軟體防盜版

壞處就是軟體出了問題基本只能抓瞎，無法自己獨立排查解決，註銷、重啟、重裝，三大法寶

碰到過多次軟體無法工作，卸載時失敗，想覆蓋重裝卻又需要先卸載，進入兩難的境地

為什麼 Linux 沒有註冊表？為什麼說註冊表是萬惡之源？

為什麼 OS X 不需要註冊表？

Windows系統的註冊表有哪些缺陷？

關於m$ windows註冊表在《UNIX程序設計藝術》一書中，有單獨一個章節討論

最大的壞處是每機器關聯的。

不是。

給許多人造成了非常大的麻煩。安裝和卸載軟體的種種問題有許多來源於此（最典型的就是裝不上去卸不幹凈）。軟體本身的許多出錯都需要通過改註冊表來修復，說明了它的不穩定性。

出於兼容性的考慮，中短期內看不到桌面系統扔掉這個歷史包袱的可能性。