Какой смысл системного реестра?
Извините за то, чтобы быть действительно неосведомленным здесь, я просто хочу учиться, почему реестр необходим для программ? Что это для и почему программное обеспечение не может только записать переменные в их собственные локальные файлы? Это делает что-то, о чем я не знаю?
8 ответов
IMHO, реестр Windows - это изобретение, почти такое же практичное и полезное, как домашнее животное.
Помещая данные конфигурации приложения в одно и то же место с данными конфигурации операционной системы, он делает любую попытку обновить приложение опасной для выхода из строя операционной системы. Это похоже на создание одного пульта ДУ, который управляет и вашим телевизором, и кардиостимулятором. Конечно, вы можете возразить, что удобно иметь все элементы управления в одном месте, но это также создает опасность того, что любая попытка изменить канал убьет вас.
Старые файлы INI легко читались и обновлялись как компьютерами, так и людьми. Для по-настоящему ленивого программиста, который не мог понять, как управлять простым текстовым файлом, существовали библиотечные функции, позволяющие сделать это просто и легко. Реестр довольно сложно обновить с помощью программы, и его чрезвычайно сложно читать любому человеку, особенно непрограммисту.
В старые добрые времена, когда каждая программа имела каталог и хранила все свои данные в этом каталоге, вы могли удалить программу, просто удалив каталог, и вы могли уверенно создать резервную копию программы, просто скопировав этот каталог. При работе с реестром вам потребуется специальная программа удаления для каждой программы, и часто в реестре постоянно появляются устаревшие или ненужные записи.
Есть ли кто-нибудь, кто может с невозмутимым видом сказать, что реестром легко управлять или что он повышает надежность системы?
Я думаю, что Microsoft следовало создать центральный файл, в котором записывались записи. каталог, в котором установлено каждое приложение, и расширения файлов, которые оно умеет открывать. Это должна быть единственная информация, которую ОС должна знать о приложении. Все остальное следует хранить в собственном каталоге приложения.
Обновление: ответ Мику
Я не согласен с большинством пунктов упомянутой статьи. Например, «Вы не можете хранить двоичные данные в файле INI» и «Файлы INI имеют только два уровня структуры». Если системный INI-файл хранит только ту информацию, которую ОС должна знать о приложениях, то есть всего несколько текстовых строк каждая, нет необходимости в двоичных данных или иерархической структуре. INI приложения должен просто содержать информацию о конфигурации и предпочтениях, и, таким образом, опять же, нет необходимости в двоичных данных и иерархиях. Преимущество формата INI состояло в том, что это был простой, читаемый текстовый файл. Это упростило анализ, обновление и управление. Вся суть моего первоначального сообщения заключалась в том, что, добавив реестр со всевозможными сложными функциями, Microsoft заменила то, чем было легко управлять, чем то, чем было трудно управлять.
Есть некоторая обоснованность положений о безопасности и параллелизме. Но, конечно, мы могли бы решить эти проблемы в существующих рамках.
Конечно, INI-файл не может быть хорошей базой данных. Но что с того? Это было не для этого.Это все равно, что жаловаться на то, что пара обуви не помогает плавать, не позволяет летать или готовить завтрак, и поэтому мы должны заменить всю обувь на ласты с реактивным двигателем, радиоуправлением и встроенными микроволновыми печами. В результате наверняка получится слишком сложное и неудобное чудовище. В него перестанет быть комфортно ходить и, вероятно, будет не очень хорошо купаться или готовить завтрак. Вместо того, чтобы хорошо подходить для одного - для ходьбы - он вряд ли годится для десятка вещей. Вещи, которые, кстати, у нас уже были отличные инструменты для выполнения. О, вроде как в реестре.
Реестр Windows был предназначен для борьбы с распространением локальных .ini файлов, которые писали программы.
Было хорошо аргументировано, что конкретная реализация была намного хуже, чем проблема, которую она должна была решить. Мне приходилось в своей жизни делать прецизионные операции на одном или двух реестрах, и я с этим согласен.
Почему программное обеспечение не может просто записывать переменные в свои собственные локальные файлы?
Может, но это может быть неудобно для разработчика программного обеспечения, потому что:
- Разработчик должен писать свои собственный парсер.
- Разработчик должен написать свою собственную логику сериализации.
- Пользователи, которые хотят редактировать параметры вручную, должны изучить синтаксис данного файла конфигурации.
Реестр - это не что иное, как простая (от будущего программиста) база данных.
Цель реестра
Реестр Windows является иерархическим база данных, в которой хранится конфигурация настройки и параметры в Microsoft Операционные системы Windows. Это содержит настройки для работы на низком уровне компоненты системы, а также приложения, запущенные на платформе: ядро, драйверы устройств, службы, SAM, пользовательский интерфейс и сторонние организации все приложения используют Реестр. В реестре также есть средство доступа к счетчикам для профилирования производительность системы.
Почему реестр поверх файлов INI?
Файлы .INI хранят пользователя каждой программы настройки в отдельный файл. От напротив, реестр Windows хранит все настройки приложения в одном центральное хранилище и в стандартизированная форма. Это предлагает несколько преимущества перед файлами INI. [2] С доступ к реестру не требуется синтаксический анализ, его можно прочитать из или написано быстрее, чем INI файл.Кроме того, строго типизированные данные могут храниться в реестре, в отличие от к текстовой информации, хранящейся в INI файлы. Поскольку пользовательский реестр настройки загружаются из пользовательский путь, а не от системное расположение только для чтения, реестр позволяет нескольким пользователям использовать одну и ту же машину, а также позволяет программам работать на пользователь с минимальными привилегиями. Резервное копирование и восстановление также упрощается, поскольку доступ к реестру можно получить через сетевое подключение для удаленного управление / поддержка, в том числе от скрипты, используя стандартный набор API, если удаленный реестр служба запущена и правила брандмауэра разрешите это.
В реестре есть функции, улучшающие целостность системы, так как реестр построена как база данных и предлагает функции, похожие на базы данных, такие как атомарные обновления. Если два процесса пытаются обновить то же значение реестра в в то же время изменение одного процесса будет предшествуют друг другу и в целом согласованность данных будет поддерживается. Где вносятся изменения в INI-файлы, такие условия гонки могут приводят к несогласованным данным, которые не соответствует ни одной из попыток обновления. Windows Vista и Windows 7 предоставляют транзакционные обновления реестра, расширение гарантий атомарности через несколько ключей и / или значений изменения, с традиционной фиксацией-прерыванием семантика. (Обратите внимание, что NTFS обеспечивает такую поддержку файла система, так что те же гарантии теоретически может быть получено с традиционные файлы конфигурации.)
Собственно, именно так это и было сделано в Windows 3.1, когда многие приложения использовали свои собственные файлы INI. Windows 95 (по памяти) представила концепцию централизованного репозитория (хотя я думаю, что до того времени существовал реестр ограниченного назначения), и с тех пор люди покупают программы очистки реестра.
Тогда люди жаловались, что нужно управлять слишком большим количеством INI-файлов и что скорость является проблемой, поскольку это текстовые файлы, требующие синтаксического анализа. Я, например, предпочитаю, чтобы приложения имели свои собственные файлы в своих каталогах , чтобы облегчить очистку, когда вы хотите их удалить.
Дословно цитируется из википедии:
Когда впервые был представлен в Windows 3.1, основной целью реестра Windows было хранение информации о конфигурации для компонентов на базе COM. С появлением Windows 95 и Windows NT его использование было расширено, чтобы убрать изобилие INI-файлов для каждой программы, которые ранее использовались для хранения параметров конфигурации для программ Windows.
Централизованное, повсеместное управление предпочтениями и настройками программ.
Это просто глупое соглашение. В файловой системе unix или mac программное обеспечение делает именно то, что вы предлагаете, записывая свои настройки в обычные файлы, обычно организованные в скрытых папках в домашнем каталоге пользователя. В Windows есть нечто подобное, папка под названием "Application Data" в домашней папке каждого пользователя, и ваша программа может использовать ее для хранения, вместо того чтобы возиться с API windows и реестром.