Как хранить настройки программ

Примечание. Все упоминаемые в статье модули, функции и т.п. относятся к Delphi.

Нижеприведенный текст являет собой вольное изложение отдельных статей февральского выпуска Microsoft Platform SDK. Год 2001 от рождества Христова. При проектировании способов хранения настроек своей программы следует задаться тремя вопросами:

• Что хранить?
• Где хранить?
• Как хранить?

Что хранить

Поскольку первая часть вопроса нам известна по определению, т.е. хранить мы будем настройки программы, то перейдем ко второй части вопроса. Ваша программа устанавливается на КОМПЬЮТЕР а пользуются ей ПОЛЬЗОВАТЕЛИ. Соответственно все настройки разделяются на две части а то и на все три - настройки которые относятся к компьютеру в целом, настройки которые относятся ко всем локальным пользователям, настройки которые относятся к конкретному пользовател. В зависимости от специфики программы первая и вторая часть могут быть совмещены или разделены. Поэтому важно сделать логическое разделение - какие настройки вашей программы действительно специфичны для самого ПК, какие настройки должны прилагаться ко всем пользователям, какие должны прилагаться к конкретному пользователю. Кроме того Мокрософт рекомендует чтобы настройки учитывали возможную мобильность пользователя, т.е. для пользователя находящегося в разных местах, возможно потребуется иметь разные наборы настроек.

Где хранить

Вообще в голову приходят три вещи.

• Хранить настройки в системном реестре.
• Хранить настройки в каталоге куда установлена программа.
• Хранить настройки в системном каталоге Windows.
• Хранить настройка в домашнем каталоге пользователя.

В Windows имеется три места предназначенных для хранения настроек которыми и следует пользоваться.

• Системный реестр.
• Домашний каталог пользователя (точнее один из его подкаталогов).
• Общий каталог для пользователей.

Прочие мысли о местах хранения настроек должны быть выброшены из голов как вредные и противоестественные, Microsoft уже за вас все придумала и нефиг извращаться. Для тех кто не понимает почему, объясняю. На нормальной ОС (W'NT, W'2K) программа обычно запускается от имени и с правами конкретного пользователя. Обычно, если этот пользователь не является администратором, он имеет право изменять содержимое следующих ресурсов:

• часть реестра HKEY_CURRENT_USER\*
• содержимое своего домашнего каталога.
• содержимое временного каталога (который как правило находится внутри домашнего).
• содержимое некого каталога или каталогов специально выделенного для этого администратором.

При нормальном (читайте параноидальном) администрировании системы прочие места либо доступны только в режиме чтения, либо вообще недоступны. В том числе и папки \Program Files и Windows. Посему любая попытка программы изменять любые файловые ресурсы окромя вышеуказанных черевата тем что ее (программу) и его (пользователя) пошлют подальше. Причем далеко не в самой вежливой форме.
Пример. Adobe Photoshop и его разработчики наивно полагают что им должны быть выданы эксклюзивные права мусорить своими scratch-файлами в корневых каталогах дисков, кроме того они полагают что им должна быть выдана в пользование в режиме полный доступ часть системного реестра.. Временных каталогов, специально выделенных для подобоного рода занятий, их не устраивает. Как результат - Photoshop имеет серьезные проблемы с работой под Windows NT/2000.

Системный реестр

С точки зрения хранения настроек программы системный реестр разделен на две части. Это ветви HKEY_CURRENT_USER для хранения настроек специфичных для пользователя, и HKEY_LOCAL_MACHINE для хранения настроек специфичных для всего ПК и соответственно всех пользователей, работающих с этим ПК. Рекомендуемая структура ветвей для хранения настроек программы - HKEY_CURRENT_USER\Software\Company Name\Application Name\Version и соответственно HKEY_LOCAL_MACHINE\Software\Company Name\Application Name\Version. Параметры Company Name, Application Name, Version желательно не хранить в виде hard-coded строк в коде программы а устанавливать в опциях проекта (Project\Options\Version Info) и доставать впоследствии из ресурса с помощью той же библиотеки RxLib. Альтернативный путь выбирать данные о версии программы из ресурсов - использование Windows API (GetFileVersionInfo, GetFileVersionInfoSize, VerQueryValue). Программе следует расчитывать на то что доступ к подключам HKEY_LOCAL_MACHINE разрешен в режиме только для чтения, а доступ к подключам HKEY_CURRENT_USER допускает чтение, изменение и создание новых подключей и значений. Программе следует расчитывать на то что нужных ей ключей может не оказаться в реестре или значения лежащие в реестре имеют неверный формат или недопустимые значения. В таком случае, вместо несуществующих или неверных значений настройки, программа должна использовать значения по умолчанию которые разработчик может "железно забить в код" или получить с помощью различных системных функций. Не следует использовать системный реестр для хранения больших кусков данных. Вместо этого лучше хранить объемные данные в отдельном файле, а в реестре запомнить имя этого файла.

Домашний каталог пользователя

Для хранения настроек слишком больших для того чтобы их размещать в реестре существуют специально выделенные каталоги внутри домашнего каталога пользователя. Эти каталоги обычно называются "специальными каталогами" и имеют имена Application Data и Local Settings. Полный путь к ним можно получить с помошью функций SHGetSpecialFolderPath или SHGetFolderPath.

Общий каталог пользователей

Обычно это каталог "Documents and Settings\All users". Внутри него имеются такие-же подкаталоги для хранения настроек и данных программ но относящихся ко всем пользователям. Полный путь к ним можно также получить с помошью функций SHGetSpecialFolderPath или SHGetFolderPath.

Как хранить

Системный реестр

Для работы с системным реестром можно использовать функции Registry API общим числом около 40 штук, а можно использовать классы из Registry.pas - TRegistry, TRegistryIniFile, TRegIniFile. Особенно следует обратить внимание на TRegistryIniFile который предоставляет упрощенную модель доступа к системному реестру очень схожую с моделью работы с INI-файлами.

INI-файлы

Это старый метод хранения настроек программ, но все еще применяющийся программистами. Настройки хранятся в текстовом файле в виде:

[Section1]
Field1=Value1
Field2=Value2
...
FieldN=ValueN

[Section2]
Field1=Value1
Field2=Value2
...
FieldN=ValueN
...

[SectionN]
Field1=Value1
Field2=Value2
...
FieldN=ValueN

Для доступа к данным содержащимся в INI-файлах существуют классы из модуля IniFiles - TIniFile, TMemIniFile. Преимущество использования INI-файлов состоит в том что их можно легко подредактировать с помощью текстового редактора. Они обычно легче воспринимаются для прочтения нежели дерево ключей системного реестра.

Бинарные файлы настроек

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

• Экономится место.
• Настройку можно спрятать от пользователя (сделать нечитабельной).

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

Заключение

Почти вся эта информация была вычерпана из кладезя мудрости под названием Platform SDK (Software Development Kit), поставляемого в составе сборника документации MSDN (Microsoft Software Developer Network). Разработчикам настоятельно рекомендуется приобрести Platform SDK, это снимает огромную массу вопросов связанную с программированием под Windows.

Оставить комментарий

Комментарий: можно использовать BB-коды Максимальная длина комментария - 4000 символов.	CodeNet ВКонтакте Facebook Twitter Google Яндекс Чтобы оставить комментарий, необходимо авторизоваться. Можно ввести логин и пароль, или авторизоваться через социальные сети.

Комментарии