Приветствую, Geo

Насчет ApplicationData. Я еще не рылся в хелпах на эту тему, но, по идее, в WinAPI должна быть функция, возвращающая корневой каталог для размещения данных пользовательских приложений. Причем, должен быть либо флажок, либо даже две разных функции: одна -- для всех пользователей, другая -- для текущего пользователя. Опять же, из соображений надежности, лучше не рыться самостоятельно в Documents and Settings, а воспользоваться готовой функцией.

Для своего приложения - есть функция, ShGetSpecialFolderPath, например. Но я описал несколько иную ситуацию - когда другая программа что-то сохраняет в AppData, а мне это что-то желательно найти и перенести (ну хотя бы на другой носитель в целях резервного копирования).

Приветствую, Александр Алексеев

Нормальная программа под Windows должна предусматривать импорт/экспорт настроек через GUI

Нормальную надо писать. В смысле вносить лишний код, тестировать этот код, возможно, документировать.
А зачем ? Только для того, чтобы соответствовать абстрактным критериям нормальности ?

Здесь проблема не в месте хранения, а в плохо спроектированной программе

Так куда ни глянь - везде программы хоть чем-то, но плохо спроектированы. Можно ждать наступления идеальных времен, а можно пользоваться тем, что есть. Кстати, бесплатным, что тоже немаловажно.

Для меня простота - это когда я знаком с логичной и понятной парадигмой (реестр).

Реестр сам по себе не дает ни логичности ни понятности, он обспечивает, если так можно сказать, мини-файловую систему для хранения настроек. Взяли и собрали все содержимое каталога /etc (или все ini из %SystemRoot%) в один большой двоичный файл и написали к нему API.

У реестра по сравнению с файлами есть один (с моей точки зрения) недостаток - в файле можно комментарии писать, к каждой настройке. В реестре такое не получится.

Персистентное состояние системы, где бы оно не хранилось (в бинарнике ли, в xml, в реестре, в базе и т.п.) я не снабжаю публичными комментариями или описаниями.

Зря. Вреда от этого уж точно не будет, а пользы достаточно.

С наилучшими,

Но тут Микрософт наконец-то спохватился (спустя 15 с лишним лет).
Не очень понятно, о каких 15-ти годах идёт речь, если это было так ещё в WinNT (1996-й). Это вина Microsoft, что ленивые разработчики всегда работают под админом и даже не задумываются о запуске программ из под обычного пользователя?

но реестром я пользоваться не хочу и, скорее всего, не буду
Это априори дефектное решение, поскольку MS?

Или если хочется иметь несколько отличающихся конфигураций, которые можно быстро переключаить между запусками. Не изобретать же подобие ControlSet001, ControlSet002, CurrentControlSet :) Своих непрограммирующих коллег я так и не смог обучить легкому и быстрому экспорту/импорту ветвей из реестра посредством regedit, а вот ini-файлы они вполне копируют.
Насколько я понимаю, ручное лазание по диску - прерогатива Unix-подобных систем ;)
Нормальная программа под Windows должна предусматривать импорт/экспорт настроек через GUI, если эту операцию нужно выполнять часто. При этои место хранения настроек значения не имеет (что позволяет нам свободно им распоряжаться). В серьёзных случаях это осуществляется инсталятором, в более простых можно обойтись другими средствами. MS Office 2003 в своё время приятно удивил наличием "Мастера сохранения настроек Microsoft Office 2003". Настроил, сохранил экспорт, и доволен. Потом импортировал сохранённое, и счастлив. Прекрасно работает, даже тулбары и макросы переносит. Консольный FAR тоже хранит всё в реестре, преимущественно в HKCU, в HKLM только сведения о регистрации. С ним проблем ещё меньше, авторы озаботились парой сценариев - SaveSettings.bat сохраняет пару .reg файлов, RestoreSettings.bat восстанавливает. Beyond Compare 2.2.7 имеет два пункта в меню Tools, догадайтесь какие. Etc.
Кроме того, хранение настроек в реестре или в AppData имеет то преимущество, что все настройки можно перенести/сохранить разом. Если же каждая программа хранит их где хочет - так сделать уже не получится.

Например, присылают мне через QIP файл, он его сохраняет где-то в далеких дебрях, если файл ценный, мне бы его из этих дебрей извлечь, и тут начинаются поиски.
Здесь проблема не в месте хранения, а в плохо спроектированной программе. Потому что в нормальных программах есть кнопки вида "Показать загрузки", "Открыть файл", "Показать файл в папке" и т.п. Что опять-таки означает, что место хранения значения не имеет.

Хорошо в Unix - реестра нет, все хранится в файлах, по файлам есть маны, нет манов - файлы конфигурации можно найти по содержанию, да и поменять в них что-нибудь одним махом.
Хм, простота - для Unix она выражается в том, чтобы надрессировать себя на ключи разных программ. Для меня простота - это когда я знаком с логичной и понятной парадигмой (реестр).
Никто не запрещает делать поиск по реестру (и это проще, чем поиск по всему диску) и/или хранить в нём же описания ключей (*). Другое дело, что так не делают. Почему? Потому что реестр - это аналог private-полей объекта. Вам незачем туда лазить - никто не лезет в реестр просто так, за посмотреть. Он предназначен в большей степени для девелоперов. Ты либо конфигуришь его через консоли/гуй, либо у тебя на руках конкретная опция, которую надо поставить и находится она моментом. Если GUI нет, но сильно припёрло - поиск в интернете. Да, описания ключей нет. Но если бы они хранились в конфиге, ничего бы не изменилось - описания так же не было бы.
Реестр изначально было создан исключительно для девелоперов. В целом и в частности он очень удобен для хранения состояния приложения. Состояние приложения - это не конфиг и оно также должно руководствоваться принципами инкапсуляции, как это делается в ООП-архитектуре. Есть внутреннее состояние, а есть публичные функции для доступа к нему в той мере, в которой это предполагается приложением, и реестр полностью этой концепции следует. Является ли "хорошей инженерной практикой" лезть в приватные поля класса в обход предусмотренного интерфейса? И часто ли вы комментируете приватные поля? Или может хорошая инженерная практика - это когда есть класс настроек, его интерфейсная часть хорошо откомментирована, а уж какую стратегию сохранения настроек он инкапсулирует - это его дело. Не так ли нас индустрия учат разрабатывать софт?
Когда интерфейс доступа к настройками - текстовый, я снабжаю его тщательными комментариями. Если интерфейс доступа к настройкам через АПИ - я снабжаю методы этого АПИ тщательными комментариями и/или хелпом. Если интерфейс доступа - экранный, я снабжаю контекстной помощью и/или хелпом. Персистентное состояние системы, где бы оно не хранилось (в бинарнике ли, в xml, в реестре, в базе и т.п.) я не снабжаю публичными комментариями или описаниями.

Ссылка в тему: Why are INI files deprecated in favor of the registry?

(*) Так редко делают, но если проводить аналогию с ini-файлами, то у нас появляется несколько дополнительной информации на настройку (далее обратите внимание на терминологию). ini-файл - это [секция] и ключ=значение. Реестр - это иерархическая структура: ключ/ключ/ключ. Секция становится просто ещё одним ключом, которых хранит подключи. Но ключ теперь может хранить больше, чем одно значение (несколько параметров). То значение, которое раньше было в ini-файле справа от ключа, идёт теперь в т.н. "значение по-умолчанию". А теперь у вас есть куча параметров, которые вы можете использовать под комменты, бинарники и всё, что душе угодно.

P.S. Мне сильно лениво было всё писать самому, поэтому часть текста я скопировал из темы http://forum.sources.ru/index.php?showtopic=264775&st=0 :)

Вопрос вроде этого:
http://www.how-to-do.ru/page.php?id=517

А если винда грохнется или айтишники переставят её в очередной раз?
Поэтому правило - ничего не храните в каталогах с пробелами.

Ответ на »сообщение 366« (Geo)
___________________________
функция, возвращающая корневой каталог для размещения данных пользовательских приложений Есть такая функция.

unit SHFolder;
unit ShlObj;  // в двух модулях (для надёжности :)

  CSIDL_PERSONAL = $0005; { My Documents }
  CSIDL_APPDATA = $001A; { Application Data, new for NT4 }
  CSIDL_LOCAL_APPDATA = $001C; { non roaming, user\Local Settings\Application Data }
  CSIDL_COMMON_APPDATA = $0023; { All Users\Application Data }

  function SHGetFolderPath(hwnd: HWND;
                          csidl: Integer;
                          hToken: THandle;
                          dwFlags: DWord;
                          pszPath: PAnsiChar): HRESULT; stdcall;

Ответ на »сообщение 363« (Игорь Шевченко)
___________________________
>>> Впрочем, кроме regentry.chm есть еще такой забавный источник документации, как support.microsoft.com/kb
М-дя... В этом источнике черным по белому написано официальное мнение (причем, капсом):
"MICROSOFT CORPORATION AND/OR ITS RESPECTIVE SUPPLIERS MAKE NO REPRESENTATIONS ABOUT THE SUITABILITY, RELIABILITY, OR ACCURACY OF THE INFORMATION AND RELATED GRAPHICS CONTAINED HEREIN <...>"

Это значит, что Микрософт в любой новой версии может изменить что-то в ОС и программы, использующие описанную фичу, перестанут корректно работать. А вот если бы Микрософт подписался под этими словами, то поменять могли бы не раньше, чем через версию (сначала объявить как obsolete, а потом поменять ;-)).

Про Windows Resource Kit надо смотреть отдельно.

Про то, где хранить настройки. Если программа небольшая и не требующая инсталляции, то все же удобнее всего хранить настройки в файле, расположенном по относительному пути от EXE-файла. Как правило, в том же каталоге. Копировать очень даже удобно. Формат, кстати, не важен. Если самому программировать лень, то можно сделать ini или xml. Если не лень или если в этом есть потребность, то все что угодно. Вплоть до бинарника предопределенного собственного формата.

Но тут Микрософт наконец-то спохватился (спустя 15 с лишним лет), что не надо превращать каталог программы в помойку, да и от вирусов надо бы защититься, и поэтому прикрыл возможность внесения изменений в каталог Program Files в режиме пользователя (резко усложнив жизнь очень многим). Тут уже дело вкуса, но реестром я пользоваться не хочу и, скорее всего, не буду. Это реестр ОС, а не реестр моей программы. Поэтому отметим в этом реестре, что моя программа на этом компьютере есть и расположена вот тут (ну, может быть, еще версию указать и еще какие-то общие слова). А вот рабочий реестр моей программы я сделаю так, как удобно мне.

Насчет ApplicationData. Я еще не рылся в хелпах на эту тему, но, по идее, в WinAPI должна быть функция, возвращающая корневой каталог для размещения данных пользовательских приложений. Причем, должен быть либо флажок, либо даже две разных функции: одна -- для всех пользователей, другая -- для текущего пользователя. Опять же, из соображений надежности, лучше не рыться самостоятельно в Documents and Settings, а воспользоваться готовой функцией.

И по теме дискуссии: Так случилось, что тоже периодически приходится смотреть на чужой код, не могу не удержаться, чтобы не привести пример:

  if (pos('  ',VarToStr(Values))<>0) or (VarToStr(Values)<>trim(VarToStr(Values))) or
    ((Length(VarToStr(Values))-Length(StringReplace(VarToStr(Values),' ','',[rfReplaceAll])))<>2) then
    ....

С наилучшими,

Ответ на »сообщение 362« (Geo)
___________________________

Продолжаем диспут, начавшийся здесь »вопрос КС №76093«

Еще в диспуте был затронут вопрос о месте хранения настроек, удобно ли в реестре, удобно ли в %UserProfile%\Application Data, удобно ли в рабочем каталоге программы в виде ini\xml-файлов.
Способ хранения не имеет однозначной рекомендации, хранить только так, а не иначе. Все зависит от задачи. Если программа, например, перемещается с компьютера на компьютер или в бэкап, к примеру, и желательно, чтобы переместилась она с настройками, то удобно будет хранить настройки в виде ini/xml-файлов рядом или отдельно (но в известном месте), чтобы было удобно перетаскивать. Или если хочется иметь несколько отличающихся конфигураций, которые можно быстро переключаить между запусками. Не изобретать же подобие ControlSet001, ControlSet002, CurrentControlSet :) Своих непрограммирующих коллег я так и не смог обучить легкому и быстрому экспорту/импорту ветвей из реестра посредством regedit, а вот ini-файлы они вполне копируют.

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

Насчет Application Data - все никак не могу не могу привыкнуть, где мне его искать, что программа туда положила. Например, присылают мне через QIP файл, он его сохраняет где-то в далеких дебрях, если файл ценный, мне бы его из этих дебрей извлечь, и тут начинаются поиски. Для начала где он - то ли в %UserProfile%\Application Data, то ли в
%UserProfile%\Local Settings\Application Data, и так далее. А если еще учесть, что это обычно скрытые папки и проводник по умолчанию их не показывает, то процедура поиска начинает слегка надоедать. Это в XP я успел выучить, где каталоги находятся, а в Windows 7 еще не успел, поэтому там поиск слегка затягивается :)

Наверное какие-то внутренние данные немаленького объема промеж запусками программы в Application Data хранить вполне достойно.

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

Все варианты хороши - остается только грамотно выбрать:)

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

С наилучшими,

Приветствую, Geo

Игорь, у меня Windows XP SP2. Я не нашел файла regentry.chm. Он появился в более поздних версиях ОС? Автор Микрософт? Там сказано, что в реестре в узле HKLM\Hardware\Description\System\CentralProcessor находится описание процессора?

Файл regentry.chm является официальной документацией по реестру, входит в состав Windows Resource Kit.

Впрочем, кроме regentry.chm есть еще такой забавный источник документации, как support.microsoft.com/kb.

В частности, там есть следующие статьи:

http://support.microsoft.com/kb/556021
http://support.microsoft.com/kb/556009

И аналогичная дискуссия:
http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/b634cc1e-55e2-4f47-ab4d-aeca26dd26ce

С наилучшими,

Продолжаем диспут, начавшийся здесь »вопрос КС №76093«

>>> Конечно документировано, в regentry.chm
Игорь, у меня Windows XP SP2. Я не нашел файла regentry.chm. Он появился в более поздних версиях ОС? Автор Микрософт? Там сказано, что в реестре в узле HKLM\Hardware\Description\System\CentralProcessor находится описание процессора?