Зачем нужен реестр Windows?

Поскольку я отлаживал проблемы в com, бок о бок, имел дело с dll hell, все время ненавидя реестр Windows со страстью, мне было интересно, зачем это нужно.

Я никогда не чувствовал себя обязанным прочитать целую книгу о лучших методах регистрации, а затем просто "получить ее".

Однако я использовал Linux и Mac OS и смотрю, как можно установить несколько версий Python и его библиотек на одном компьютере * nix.

Поскольку реестр имеет бесплатный (хотя и некрасивый) формат и используется для самых разных целей, я никогда не понимал, какую существенную проблему он пытается решить.

Например, Microsoft не хочет, чтобы у вас были установлены две разные версии MS Office. Они используют реестр для обеспечения этого во время установки. Это ограничение является искусственным, на мой взгляд. Если бы они действительно хотели разрешить другое поведение, они могли бы соответствующим образом скорректировать свою архитектуру.

В Mac OS вы можете устанавливать и удалять приложения, просто поместив их в определенную папку.

Так,

А) Какую существенную проблему он пытается решить? Б) Как это решают другие операционные системы?

Большинство других ответов более или менее правильны, но (наряду с вопросом) они как бы упускают суть.

Реестр представляет собой иерархический менеджер баз данных - не более и не менее.

«Ошибки», которые вы приписываете реестру, на самом деле не зависят от самого реестра. Это просто решения, принятые различными поставщиками в отношении того, как устанавливать свои программы - если вы сохранили информацию в каком-либо другом стиле / форме / контейнере, могут остаться те же проблемы.

Учитывая философию Unix «все является файлом», неудивительно, что системы Unix (и аналогичные, например, Linux и MacOS) хранят информацию в виде отдельных файлов в файловой системе. Однако это не так сильно отличается, как многие могут сразу поверить, поскольку файловая система Unix сама по себе является иерархической базой данных (или, возможно, сетевой базой данных, если принять во внимание символические ссылки). Разница заключается в том, что доступ к реестру осуществляется через отдельный API, где хранение данных конфигурации в файлах позволяет получать доступ к этим файлам, редактировать их и т. Д. Через тот же API (и инструменты), что и любые другие файлы.

Это хранилище настроек - централизованное и несколько стандартизированное расположение для предпочтений, настроек и облегченных профилей .

Становится легче понять, когда вы смотрите на общую картину всех вещей, которые ОС должна хранить для своих пользователей и приложений:

Windows

• Репозиторий настроек
  • Система: Реестр Windows HKEY_LOCAL_MACHINEи, в частности, многое из этого находится в\SOFTWARE\Microsoft
  • Сторонние общесистемные: реестр WindowsHKEY_LOCAL_MACHINE
  • Система ориентирована на пользователя: реестр Windows HKEY_USERS,[user]\SOFTWARE\Microsoft
  • Сторонние ориентированные на пользователя: реестр WindowsHKEY_USERS\[user]\SOFTWARE
• Файлы приложений, которые пользователь не должен видеть C:\Users\[User]\AppData в скрытых папках
• Файлы приложения, которые пользователь может хотеть C:\Users\[User]\ в не скрытых папках, созданных приложением

Mac OS X

• Репозиторий настроек
  • Системные и сторонние: /Library/Preferences в com.apple...plistфайлах
  • Сторонние общесистемные: /Library/Preferences в сторонних plistфайлах
  • Система ориентирована на пользователя: так /Users/[user]/Library/Preferences же, как и выше
  • Сторонний ориентированный на пользователя: /Users/[user]/Library/Preferences такой же, как выше
• Общесистемные файлы приложений, которые пользователь не должен видеть /Library/Application Support
• Файлы приложений, которые пользователь не должен видеть /Users/[user]/Library/Application Support
• Файлы приложений, которые пользователь может хотеть /Users/[user]/ в не скрытых папках

По сути, реестр идентичен папкам Mac OS X /Library/Preferences и не намного больше или меньше.

Тот факт, что Mac OS имеет почти однозначное соответствие для организационных групп данных системы и приложений, показывает, что реестр Windows является полностью оправданной системой, которая представляет собой просто другой способ ведения дел.

Характер реестра, не относящийся к файловой системе, затрудняет резервное копирование, восстановление или миграцию его частей, оставляя другие, поэтому я предпочитаю систему Mac, но цель почти идентична.

Обе ОС имеют приложения, которые решают нарушать эти структуры в разной степени, обычно через узурпацию более глобального контекста для создания файлов или папок, которые там на самом деле не принадлежат. Некоторые приложения на самом деле создают папки прямо C:\или /без запроса. Это действительно сводит меня с ума!

^{Между прочим, хотя характер перетаскивания (большинства) приложений Mac OS великолепен, у вас есть похожая проблема с различными версиями бок о бок, хотя вы, вероятно, не замечаете - поскольку ваши настройки не сохраняются в самом .appфайле, но в Application Supportили Preferencesкаждая версия приложения будет по-прежнему использовать одни и те же настройки и влиять друг на друга, если только новая версия явно не решит использовать папку с другим именем ( IntelliJIDEA70, IntelliJIDEA81и т. д.)}

Я никогда не понимал, какую существенную проблему он пытается решить.

До регистрации Windows использовались файлы .INI. В записи блога Почему файлы INI устарели в пользу реестра? Раймонд Чен перечисляет проблемы, которые существовали с файлами .INI, которые пытались решить. Он также перечисляет проблемы, которые файлы конфигурации XML разделяют со старыми файлами .ini. Вероятно, это то, на что стоит обратить внимание, поскольку именно этим сегодня пользуются многие приложения.

... маятник вернулся к текстовым файлам конфигурации, но на этот раз это XML. Это вновь открывает многие проблемы, которые были у файлов INI, но у вас есть главное преимущество, что никто не пишет в файлы конфигурации XML; они только читают от них. XML-файлы конфигурации не используются для хранения пользовательских настроек; они просто содержат информацию о самой программе. Давайте снова посмотрим на эти проблемы.

• Безопасность файлов XML недостаточно детальна. Но поскольку файл конфигурации XML доступен только для чтения, основное возражение обходится стороной. (Но если вы хотите, чтобы только администраторы имели разрешение на чтение определенных частей XML, у вас проблемы.)
• Поскольку файлы конфигурации XML доступны только для чтения, вам не нужно беспокоиться о множестве авторов.
• Файлы конфигурации XML могут подвергаться отказу в обслуживании. Вы по-прежнему можете открывать их исключительно и блокировать другие процессы.
• XML-файлы содержат только строки. Если вы хотите хранить двоичные данные, вы должны как-то их кодировать.
• Разбор XML-файла сравнительно медленный. Но так как они предназначены только для чтения, вы можете безопасно кэшировать анализируемый результат, поэтому вам нужно выполнить только один анализ.
• Программы анализируют XML-файлы вручную, но формат XML уже заблокирован, поэтому вы не сможете расширить его, даже если захотите. Надеемся, что эти программы используют стандартный синтаксический анализатор XML вместо собственного, но я не удивлюсь, если люди напишут свой собственный XML-анализатор, который, скажем, прерывает обработку инструкций или строк длиной более 70 символов.
• Файлы XML не имеют ограничения по размеру.
• XML-файлы не имеют местоположения по умолчанию.

Все это предполагает, что приложение действительно никогда не записывает в свои файлы конфигурации, с которыми я не согласен, но это может ухудшить ситуацию.

Моя теория - движущая сила - ничто из вышеперечисленного. Скорее, это была мера борьбы с пиратством. В дни до регистрации вы могли просто скопировать целую программу с одного компьютера на другой. Найдите .DLLs, и вы были в порядке. Реестр делает это намного сложнее.

Реализация реестра очень мала, и я думаю, что лучше не обслуживать один файл конфигурации для каждой цели.

(2014) Чтобы немного расширить мои рассуждения: я вижу реестр как объект бога. Мы все знаем, что это антипаттерн.

Мое грубое понимание состоит в том, что реестр был спроектирован как хранилище настроек, заменяющее файлы .ini, которые раньше использовались.

(NB, грубое понимание, так что это может быть неправильно).

А) Я согласен с ответом Тима.

Б) Другие операционные системы используют другие методы хранения настроек программы, например, Unix обычно помещает файлы в / etc (глобальные файлы) и в пользовательскую папку в различные скрытые папки (пользовательские настройки). Таким образом, все они используют некоторую форму реестра, за исключением того, что в некоторых случаях он распространяется.

Как я понимаю (не обязательно наслаждаться этим)

А) Предоставить «централизованное расположение», где любая программа может хранить информацию о своей установке или настройке. Эта информация может быть использована программами так, как они решат. Кастомизация, антипиратство и пр.

Вся эта информация, находящаяся в этой структуре, как бы защищает ее, думает о том, что животные стекаются вместе, больше безопасности в количестве. Если бы каждый бит информации был его собственным INI-файлом, то какой-то пользователь мог бы удалить его по своей прихоти. Они все еще могут сделать это, войдя в реестр, но многие рассматривают его как черный ящик и не будут трогать его, опасаясь взлома своей системы.

Б) Mac OS использует отдельные файлы так же, как окна ini-файлов, которые использовались до появления реестра.

Очевидная цель реестра - действовать как единый репозиторий для всех данных конфигурации и настроек и удалять зависимость от файлов конфигурации.

В других операционных системах modus operandi должен хранить информацию о приложении (например, файлы конфигурации) в скрытых каталогах, специфичных для приложения, в домашнем каталоге пользователя. (Например, игра Aquaria хранит информацию о конфигурации в $HOME/.Aquaria.) Файлы глобальных настроек хранятся в /etc/.

Маки делают свое дело: специфичные для приложения plistфайлы хранятся (я считаю) в Libraryкаталоге пользователя или системы .

Проблема не в философии реестра, а в его дизайне. Реестр используется ОС для поиска важной информации о загружаемой программе. Однако вместо загрузки информации по мере необходимости она загружает все данные во время загрузки, что «может» повлиять на производительность системы. Система также подвергается жестокому обращению, поскольку поставщики загружают ее кучей информации, и часто они не удаляют информацию при удалении программного обеспечения.

В отличие от Unix, где все хранится в n файлах и загружается по мере необходимости. Таким образом, ОС не полагается на навыки программирования поставщика, чтобы повлиять на ее производительность ...

Хотя я не могу комментировать другие операционные системы, реестр также помогает поддерживать конфигурацию приложения во время процесса обновления или удаления / переустановки. Если вся конфигурация была в INI-файле, который необходимо было заменить из-за обновления, в котором были добавлены функции, вы можете столкнуться с трудностями или создать собственный процесс, чтобы объединить данные конфигурации с входящим INI-файлом.

Однако с данными в реестре вы можете использовать общий установочный пакет (WIX, InstallShield и т. Д.), Который будет обрабатывать удаление / переустановку файлов, не затрагивая параметры приложения.

(все А. Не уверен насчет Б)

Я считаю, что это на самом деле до (исторического) момента, когда реестр действует как своего рода общий интерфейс для настроек приложения.

Есть приложение? Хотите сохранить пользовательские настройки? Сунул его в реестр.

Нет необходимости «обеспечивать профили пользователей», вообще не нужен прямой доступ к файловой системе. Win32 выглядит после всего этого.

Это был способ создать что-то новое, незнакомое и запретное для большинства пользователей, поэтому они оставили это в покое. Файлы .ini и autoexec.bat могут быть легко удалены или изменены в худшую сторону.

Изменение настроек Registgry, о боже!

В дополнение к простому хранению настроек приложения, реестр - это средство, с помощью которого программы и компоненты обнаруживают другие программы и компоненты . В конечном счете, я думаю, что именно поэтому он централизован в единую базу данных, а не распространяется на тысячи текстовых или XML-файлов.

Например, компонент, который выполняет, скажем, видеоэффекты, «регистрируется» в реестре, позволяя другим приложениям, связанным с видео, знать о его существовании и использовать его. Имея для этого централизованную систему, она позволяет избежать серьезной путаницы, поскольку тысячи систем и приложений используют разные методы для достижения этого уровня интеграции.