Реестр или ini ?

← →
Пастор (2002-07-05 08:57) [0]

Как вы думаете, где лучше хранить настройки программы ?

← →
Чайник2 (2002-07-05 08:59) [1]

Ini

← →
Виктор Щербаков (2002-07-05 09:10) [2]

Реестр

← →
tsarevep (2002-07-05 09:27) [3]

Свой зашифрованный.

← →
KUAW (2002-07-05 09:38) [4]

Ini более переносим м/у платформами / компьютерами
можно править руками, причем все кто захочет :)
не слетает при сносе винды
в реестре у разных юзеров как бы разные реестры
В общем надо смотреть что тебе надо у обоих подходов есть плюсы
и минусы

← →
tsarevep (2002-07-05 09:44) [5]

Полностью согласен с KUAW , всё зависит от программы. Если б мне только положение формы и т.п. надо было сохранить, то я б наверно INI использовал и пусть его юзают скоко хотят. Ну а если чего помощнее, то реестр.

← →
Doctor Deejay (2002-07-05 10:24) [6]

ini намного шустрее

← →
d_oleg (2002-07-05 10:24) [7]

Я делаю так: настройки, не зависящие от пользователя (например, пути к БД, шаблоны, маски) - в INI, персональные настройки пользователя (интерфейс например) - в реестре

← →
Vladislav (2002-07-05 10:26) [8]

Читал где-то... Майкрософт настоятельно рекомендует использовать реестр, т.к., по их мнению, инишники это уже в прошлом. Но, лично я, использую ini-файлы, т.к. есть ряд преимуществ.
1. Как уже говорилось - переносимость.
2. Где гарантия, что какой-нибудь чистильщик реестра не грохнет вашу информацию.
3. Винда имеет обыкновение падать (реестр, соответственно, тоже).
4. При работе в NT не каждому пользователю будет доступ к реестру. И более того потребуется вмешательство админа, чтобы расшарить доступ для юзера на вашу ветку в реестре.
5. Только начиная с D4 появился метод OpenKeyReadOnly. Опять-таки NT-вые грабли.

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

← →
Casee (2002-07-05 10:47) [9]

Одно из преимуществ Registry: программа может лежать по любому пути и не обязательно присутствие ini файла в том же каталоге.

← →
PVOzerski (2002-07-05 11:25) [10]

2Casee (05.07.02 10:47):
А вот преимущество ли это? IMHO, скорее наоборот. Тем более что никто не запрещает искать ini-файл по полному пути (например, в папке Windows) или вообще добавлять свои секции к win.ini/system.ini.

← →
cyborg (2002-07-05 11:27) [11]

Мало того что регистр раздувается на глазах и в какой то степени тормозит систему, дык ещё наши проги туда будут пихать что попало.
Либо INI либо свой формат. А в регистр пущай Билли пишет :).
Считаю что настройки проги должны лежать рядом с ней, что бы когда её удаляют, то удаляют всё а не оставался мусор в регистре.
Если секретные данные то шифровать и проверять целостность своего файла, если испорчен, например регистрация при "умелом" ковырянии :), то нивкакую не запускаться и т.д.

← →
Yuri Btr (2002-07-05 11:33) [12]

А я предпочитаю хранить настройки в INI файле.
Проще, безопаснее, и нет проблем под NT.
В реестре можно хранить какие либо "секретные" данные или данные, зависящие от конкретного юзера.

← →
PVOzerski (2002-07-05 11:37) [13]

>Считаю что настройки проги должны лежать рядом с ней, что бы
>когда её удаляют, то удаляют всё а не оставался мусор в регистре.
Полностью согласен. Особенно для сравнительно небольших программ. Наш пользователь воспитан в значительной мере на Norton Commander с клавишей F8, о корректной деинсталляции он зачастую и не слыхал (добро бы еще она всегда на самом деле корректной была...). А вообще - моя бы воля, я бы и апдейтящиеся при инсталляции DLL-и вроде mfc42 (говорю здесь не только применительно к разработкам на Delphi, так что извините за пример - просто злободневно для меня очень: недавно переустановил Norton Utilities - и AVP сдох...) кидал бы не в системную папку, а к в ту же, где .exe (хотя бы по указанию пользователя).

← →
Yuri Btr (2002-07-05 11:42) [14]

Да взять хотя бы почти всеми любимый WinAmp - никаких записей в реестре. Для переноса настроек - один INI файл и правильность путей.При апдейте версии - сохраняется даже песня , проигранная последний раз. И никаких глюков. Некоторым стоит поучиться :-)

← →
Виктор Щербаков (2002-07-05 11:44) [15]

Явные преимущества реестра:
1. Санкционирование доступа.
2. Древовидная структура.
3. Богатый набор АПИ для работы с реестром.

Недостатки тоже есть но их не так много как у ini.
Основная проблема - куча кривых генераторов дистрибутивов и деинсталяторов.

← →
cyborg (2002-07-05 13:38) [16]

>Виктор Щербаков ©
>Явные преимущества реестра:
>1. Санкционирование доступа.

Создав свой файл, да ещё и зашифрованный ни одна собака не изменит твои настройки кроме твоей программы. А если изменит, то быстро пожалеет об этом.

← →
^Sanya (2002-07-05 13:51) [17]

Я бы посоветовал реестр для примитивной защиты программы, ну типа привязки к данному компу...
А вот ini использую очень активно, причём с шифрованием всех данных...Он как бы "мобильней" что ли...:)
Каждому своё.

← →
vixic (2002-07-05 14:17) [18]

Я согласен с cyborg. Очень хорошая мысль о создании файлов своих форматов но со структурой как в реестре!

← →
Виктор Щербаков (2002-07-05 14:22) [19]

cyborg © (05.07.02 13:38)
Речь не о шифровании, а о самой возможности изменения информации определенными пользователями.

← →
Skier (2002-07-05 14:25) [20]

> to all
Мамы всякие нужны, мамы всякие ВАЖНЫ :))

← →
cyborg (2002-07-05 14:52) [21]

Да я вообще-то то же не про шифрование говорю, а про хранение настроек. Не вижу вообще никаких плюсов реестра перед своим форматом файла настроек. Если нужно конфидециальность настроек проблем нет, если нужно строку записать, байты, флаги и вообще всё подряд - пишешь. Какие проблемы?

>^Sanya (05.07.02 13:51)
>Я бы посоветовал реестр для примитивной защиты программы,
>ну типа привязки к данному компу...

Такое ощущение что вообще разучились писать старыми, добрыми Паскалевскими методами, как будто для записи существует только реестр, остальное не бывает :)?

← →
DeMoN-777 (2002-07-05 14:56) [22]

Реестр это только до первой переустановки виндов, а дальше.......
Ini-это вечно ;)

← →
DeMoN-777 (2002-07-05 14:57) [23]

Реестр это только до первой переустановки виндов, а дальше.......
Ini-это вечно ;) (а если ещё и зашифрованный, то ваще супер)

← →
rog (2002-07-05 15:07) [24]

Я храню в ини файле для того , чтобы не надо было переустанавливать прогу каждый раз когда я переставляю винды

← →
smit_ (2002-07-05 15:37) [25]

А ни кто не встречал компонента, а-ля реестр но только локально?

← →
Anatoly Podgoretsky (2002-07-05 16:16) [26]

Нижеприведенный текст являет собой вольное изложение отдельных статей февральского выпуска 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 допускает чтение, изменение и создание новых подключей и значений.
Программе следует расчитывать на то что нужных ей ключей может не оказаться в реестре или значения лежащие в реестре имеют неверный формат или недопустимые значения. В таком случае, вместо несуществующих или неверных значений настройки, программа должна использовать значения по умолчанию которые разработчик может "железно забить в код" или получить с помощью различных системных функций.
Не следует использовать системный реестр для хранения больших кусков данных. Вместо этого лучше хранить объемные данные в отдельном файле, а в реестре запомнить имя этого файла.

← →
Anatoly Podgoretsky (2002-07-05 16:19) [27]

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

Для хранения настроек слишком больших для того чтобы их размещать в реестре существуют специально выделенные каталоги внутри домашнего каталога пользователя. Эти каталоги обычно называются "специальными каталогами" и имеют имена 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.

← →
MacX (2002-07-06 00:21) [28]

Короче хранить надо в реестре (Виктор Щербаков прав), а те кто говорит что в ini, никогда не работали в многопользовательской системе... ни один пользователь (без прав администратора) не сможет изменить настройки, а во многих таких программах не сможет работать вообще по причине постоянного появления сообщения "доступ запрещен" при попытке записи в ini.

← →
Aleks1 (2002-07-06 03:32) [29]

Хм. Короче, еще одна победа Билла над нами...
"И все-таки она вертится!"
Использую только INI и CFG, для своих программ. Реестр - только в тех случаях, когда требуется стандартная реакция Windows.

← →
NailMan (2002-07-06 04:10) [30]

Реестр я считаю надо использовать для хранения пути к твоей проге, а ее внютренние настройки в ИНИ или КФГ. Гемора при смерти Мастдая будет меньше,а в прогу вполне можно вставить определение/добавление(если в первый раз запускается) ентого пути в реестре.
Тем более править свой ИНИ при помощи универсального драйвера РУКИ.SYS гораздо удобнее нежели при помощи REGEDIT или чего там более продвинутого.

← →
cyborg (2002-07-06 08:21) [31]

MacX а если не в INI писать, то же не разрешает?
Возможно не разрешает когда INI в виндоузном каталоге лежит, а не рядом с программой?

← →
ivlex (2002-07-06 08:37) [32]

Лично я, если не нужно автозагружать программу, пользуюсь Ini. Настройки легче сохранить при переустановке Win, легче перенести на другой компьютер, да с Ini и возни меньше, чем с реестром (в смысле кода меньше писать :)).

← →
Anatoly Podgoretsky (2002-07-06 12:00) [33]

← →
Nadia (2002-07-06 13:34) [34]

А я реестр использовала для хранения паролей пользователей, а если Winda грохнулась, то они по умолчанию нулятся, как при первой установке, а в Ini файл любой пользователь влезет и наизменяет там чего попало...

← →
Anatoly Podgoretsky (2002-07-06 14:09) [35]

Нет разницы, и туда и туда спокояно влязят, только реест можно легко защитить

← →
cyborg (2002-07-06 16:02) [36]

← →
AL2002 (2002-07-06 16:58) [37]

Я вообще уважаю проги, которые не нужно инсталлировать. Зверею, когда у 50Кб-й проги запускается инсталлшилд и реестр замусоривается. INI лучше. А крякнуть прогу, которая в реестре что-то там запишет для своей "защиты" тоже элементарно.
Да и вообще, если Гей-Тс что-то навязывает – значит, это делать не надо.

Вот если б компоненту какую, чтобы с ИНИ хорошо работала... (мечтательно)

← →
Doctor Deejay (2002-07-06 19:15) [38]

Это компонента. Просто сохрани содержимое в пас-файл и инсталлируй. Работает как с реестром, так и с ини. Взял из xTools, но последняя версия была под Д3, поэтому пришлось переделать.
А по поводу обсуждаемой темы, то я ближе к ини, но в последней моей проге без реестра не обошлось, т.к. нужно было сохранить параметры, которые зависят от данной звуковухи. Ну а т.к. прога без инсталляции, то при переносе на другой комп начнется что-то страшное....
Но если можно обойтись без реестра, то лучше без него обойтись. Он и тормознутый к тому же. Кто не верит - пусть вспомнит как ACDSee при инсталляции регистрирует свои расширения в реестре. На моем P1 200 MMX этот процесс занимает секунды 3. А если не 20 записей нужно сделать а под 1000.
Короче ини намного шустрее, да и руками править можно. А если кому пароли хранить нужно, так реестр не поможе. Тут шифровать нужно :)

Удачи

← →
Doctor Deejay (2002-07-06 19:16) [39]

Вот и компонент

====================================================

unit xRegistr; { let"s you access windows registry easy as ini-file replacement } interface uses Windows, Classes, Dialogs, SysUtils, Controls, Graphics, Forms, Registry; type TRegBranch = (rbClassesRoot,rbCurrentUser,rbLocalMachine, rbUsers,rbPerformanceData, rbCurrentConfig,rbDynData); TxRegistry = class(TComponent) private FRegistry : TRegistry; FItem : String; FValue : String; FOnChange : TNotifyEvent; procedure SetKey(const Value: String); function GetKey: String; procedure SetItem(const Value: String); procedure SetBranch(const Value: TRegBranch); function GetBranch: TRegBranch; public constructor Create(aOwner:TComponent); override; destructor Destroy; override; function ReadString: String; procedure WriteString(const Value: String); function ReadInteger: Integer; procedure WriteInteger(Value: Integer); function ReadBool: Boolean; procedure WriteBool(Value: Boolean); function DeleteKey: Boolean; function DeleteItem: Boolean; procedure EnumKeys(Strings: TStrings); procedure EnumItems(Strings: TStrings); published property Branch: TRegBranch read GetBranch write SetBranch; property Key: String read GetKey write SetKey; property Item: String read FItem write SetItem; property OnChange: TNotifyEvent read FOnChange write FOnChange; end; procedure Register; implementation { TxRegistry } constructor TxRegistry.Create(aOwner: TComponent); begin inherited Create(aOwner); FRegistry:=TRegistry.Create; FRegistry.OpenKey("Software\",True); FItem:=""; end; destructor TxRegistry.Destroy; begin FRegistry.Free; inherited Destroy; end; procedure Register; begin RegisterComponents("xTools", [TxRegistry]); end; procedure TxRegistry.SetKey(const Value: String); begin if Value<>GetKey then begin FRegistry.CloseKey; FRegistry.OpenKey(Value,True); if Assigned(FOnChange) then FOnChange(Self); end; end; function TxRegistry.GetKey: String; begin Result:=FRegistry.CurrentPath; end; procedure TxRegistry.SetItem(const Value: String); begin if Value<>FItem then FItem:=Value; end; procedure TxRegistry.SetBranch(const Value: TRegBranch); var aKey: String; begin if Value<>GetBranch then begin aKey:=GetKey; case Value of rbClassesRoot : FRegistry.Rootkey:=HKEY_CLASSES_ROOT; rbCurrentUser : FRegistry.Rootkey:=HKEY_CURRENT_USER; rbLocalMachine : FRegistry.Rootkey:=HKEY_LOCAL_MACHINE; rbUsers : FRegistry.Rootkey:=HKEY_USERS; rbPerformanceData: FRegistry.Rootkey:=HKEY_PERFORMANCE_DATA; rbCurrentConfig : FRegistry.Rootkey:=HKEY_CURRENT_CONFIG; rbDynData : FRegistry.Rootkey:=HKEY_DYN_DATA; end; SetKey(aKey); end; end; function TxRegistry.GetBranch: TRegBranch; begin case FRegistry.Rootkey of HKEY_CLASSES_ROOT : Result := rbClassesRoot; HKEY_CURRENT_USER : Result := rbCurrentUser; HKEY_LOCAL_MACHINE : Result := rbLocalMachine; HKEY_USERS : Result := rbUsers; HKEY_PERFORMANCE_DATA: Result := rbPerformanceData; HKEY_CURRENT_CONFIG : Result := rbCurrentConfig; HKEY_DYN_DATA : Result := rbDynData; end; end; { deletes a key and all his subbranches } function TxRegistry.DeleteKey: Boolean; begin Result:=FRegistry.DeleteKey(Key); end; { Deletes one Value from the branch } function TxRegistry.DeleteItem: Boolean; begin Result:=FRegistry.DeleteValue( FItem); end; { Enumerates all subkeys for a key } procedure TxRegistry.EnumKeys(Strings: TStrings); begin FRegistry.GetKeyNames(Strings); end; { Enumerates all values for a key } procedure TxRegistry.EnumItems(Strings: TStrings); begin FRegistry.GetValueNames(Strings); end; function TxRegistry.ReadString: String; begin Result:=FRegistry.ReadString(FItem); end; procedure TxRegistry.WriteString(const Value: String); begin FRegistry.WriteString(FItem,Value); end; function TxRegistry.ReadBool: Boolean; begin Result:=FRegistry.ReadBool(FItem); end; procedure TxRegistry.WriteBool(Value: Boolean); begin FRegistry.WriteBool(FItem,Value); end; function TxRegistry.ReadInteger: Integer; begin Result:=FRegistry.ReadInteger(FItem); end; procedure TxRegistry.WriteInteger(Value: Integer); begin FRegistry.WriteInteger(FItem,Value); end;

====================================================

← →
wicked (2002-07-06 19:26) [40]

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

Реестр или ini ? Найти похожие ветки