Ответ на »сообщение 410« (Александр Алексеев)
___________________________
>>> Я вам открою секрет, но типовый пользователь компьютера и не должен знать этих вещей. Более того, процентов 80 всех пользователей - не технари, а "домохозяйки".
То есть деградировали. Потому что раньше даже "блондинки" (кроме самых уж откровенных) могли в нортоне скопировать файл с дискеты и запустить его.

>>> Они сейчас вымерли или деградировали?
Я вам открою секрет, но типовый пользователь компьютера и не должен знать этих вещей. Более того, процентов 80 всех пользователей - не технари, а "домохозяйки".

Ответ на »сообщение 407« (Alexeyslav)
___________________________
>>> Помоему, никто не запрещал настраивать программы двумя способами сразу - и с самой программы и при помощи редактирования INI-файла
Безусловно. Если разработчик считает это нужным.

>>> Порой ведь как оно бывает, настроишь что-то не так программа не запускается, а сбрасывать настройки к умолчанию не хочется - лезешь в файл настроек, правишь и все становится на свои места.
А бывает так, что программа глючит. Вот бы влезть в программу и поправить ее. Ну как? Будем все переходить на Open Source? Или начнем писать на интерпретаторах и скриптовых языках? ;-)

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

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

>>> запустил программу на другой машине где старший/младший байт слова имеют различное положение и привет
А EXE-шник на той другой машине запустится? ;-)

>>> каким образом можно проконтролировать корректность сохранения настроек программой?
У нас в рамках дискретного анализа был семестровый курс теории кодирования. Это наука. Неужели Вы думаете, что все контрольные коды придуманы лично Биллом Гейтсом? ;-)

>>> Даже такое действие как создание ярлыков и установка программы в нужную папку - несомненный плюс, как для пользователей которые слабо себе представляют что такое файловый менеджер и куда собственно ставить программу и что делать "вот с этим файлом.zip"
В ДОСовские времена люди без проблем понимали, что если тебе дали дискетку с программой, то надо с нее скопировать файлы к себе на винт, а потом запустить файл с расширением EXE. Они сейчас вымерли или деградировали? Или пользователи, которых Вы упоминаете, это подросшее моложое поколение, которое на имеет опыта работы с ДОС? ;-)

Вы исходите из неявного предположения, что программа должна размещаться не где попало, а в специально отведенном для нее месте. Что где-то что-то должно быть прописано. И т.д. и т.п. Это совершенно правильно для больших и сложных программных комплексов. Но какая нибудь игрущка типа сапера великолепно разместится не только в Program Files, но и, например, на рабочем столе.

>>> если каждую из них надо распихать по своим папкам, прописать ярлыки в нужных местах
У Вас в настройках меню Пуск опция personalized включена? Если да, то отвлекитесь от чтения, откройте и посмотрите, сколько у вас там пунктов видно. Именно эти 5-6 ярлыков Вам и нужно прописать сразу. Остальные программы либо вообще никогда не потребуются, либо будут тербоваться крайне редко, и не составит труда раз в месяц создать руками один ярлычок.

Ответ на »сообщение 405« (Игорь Шевченко)
___________________________
>>> И откуда стойкая уверенность, что организация реестра изменится, а WMI останется без изменений ?
Наверное, из того факта, что за последние 20 лет формат винвордовского документа поменялся раз шесть, не меньше. А комбинация Ctrl+B как использовалась для Bold, так и используется ;-)

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

В то же время, тот же механизм WMI (насколько я успел понять) задуман именно как интерфейс для пользовательских приложений. Более того, он документирован. И это гарантирует ему жизни еще как минимум на два поколения (то есть, лет на 6-8).

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

Ответ на »сообщение 381« (Игорь Шевченко)
___________________________

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

Помоему, никто не запрещал настраивать программы двумя способами сразу - и с самой программы и при помощи редактирования INI-файла.
Порой ведь как оно бывает, настроишь что-то не так программа не запускается, а сбрасывать настройки к умолчанию не хочется - лезешь в файл настроек, правишь и все становится на свои места. Как вспомню Win 3.11, в котором частота кадровой развертки записывалась в INI файл, и не давалось 15 секунд для восстановления настроек в случае если они приводят к сбою синхронизации.

... допустим, есть бинарный файл настроек, представляющий собой образ памяти, содержащей данные для работы программы. Такой файл грузится при старте программы целиком в память, создавая сразу готовую структуру данных для работы программы.
Это конечно было бы здорово но ... изменился состав модулей программы, образ настроек уже не подходит ... Запустил программу на другой машине где старший/младший байт слова имеют различное положение и привет... А каким образом можно проконтролировать корректность сохранения настроек программой? А если настройки динамичны? Слишком уж непрозрачен такой подход. Потом еще можно крыть различными версиями программы: как следующая версия должна импортировать настройки своей предшественницы? Ведь ей прийдется разобрать структуру образа и собрать по-новому, а если пропустишь одну-две-десять версий? Программа в таком случае должна уметь импортировать свои же настройки различных версий самой себя.

Про главное преимущество файла настроек, расположенного рядом с EXE, я уже писал: перенос программы на другой компьютер выполняется простым копированием каталога с программой. Такой простоты ни один из предложенных здесь альтернативных способов.

Банально, в каталог программы может быть запрещена запись из соображений противодействия вирусным атакам.
Виндовс пока не имеет механизма выборочного запрета/разрешения основанном на типе файла.
Ну и потом, данная проблема решается очень просто - функции импорта/экспорта настроек в самой программе или отдельной утилитой входящей в комплект.
Это что касается больших и сложных программ. Для мелких программ уровня "утилиты" вполне допустимо хранить настройки рядом с собой но это должно быть 1 или максимум 2 файла, иначе сборище таких утилит быстро превращается в непонятный клубок, понять где чье в котором становится невозможным.
Тут есть еще один небольшой фактор, обычно настройки программ локализованные в одном месте проще помещать в резервную копию, и восстанавливать при сбоях или даже переустановке системы. О специфических настройках которые хранятся с самими программами в их папках обычно вспоминают только когда они уже потеряны.



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

Даже такое действие как создание ярлыков и установка программы в нужную папку - несомненный плюс, как для пользователей которые слабо себе представляют что такое файловый менеджер и куда собственно ставить программу и что делать "вот с этим файлом.zip"
Файловый менеджер может и справится лучше при одном условии: Вы помните все пути куда что нужно прописать, все эти пути открыты в отдельных окнах и готовы для создания ярлыков/копирования файлов ...

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

Ответ на »сообщение 403« (Игорь Шевченко)
___________________________

А что, есть предложение, что CPU изменится с момента появления записи в реестре ? ;)
Если что, оно там записывается на ранних этапах загрузки системы...
С наилучшими,
Проверил последнее утверждение (не напрямую, а почитав, что пишут :) ), судя по тому, что нашел в интернете, это так.
Тогда с точки зрения достоверности конечно можно пользоваться этими данными.
Насчет "если что-то изменят", теоретически мне ближе то, о чем написал Geo - работать через стандартные интерфейсы, в данном случае WMI. Но я согласен, что "WMI точно также может кануть в лету, как и прочие технологии."

Ответ на »сообщение 404« (Geo)
___________________________
Речь немного не о том. Реестр -- это всго ишь хранилище данных, а WMI -- интерфейс доступа к этим данным. Выйдет новая версия ОС, и эти же данные будут храниться уже в каком-нибудь бредестре (или просто ветки будут организованы по-другому). А WMI как работал, так и будет работать. Потому что его реализацию просто переделают на работу с новым бредестром.

К данным реестра доступ несколько иной - это набор соответствующих API. И откуда стойкая уверенность, что организация реестра изменится, а WMI останется без изменений ? WMI точно также может кануть в лету, как и прочие технологии. Придумают чего-нибудь новое, чтобы разработчики не расслаблялись.

http://russian.joelonsoftware.com/Articles/FireAndMotion.html

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

Ответ на »сообщение 403« (Игорь Шевченко)
___________________________
>>> А что, есть предложение, что CPU изменится с момента появления записи в реестре ? ;)
Речь немного не о том. Реестр -- это всго ишь хранилище данных, а WMI -- интерфейс доступа к этим данным. Выйдет новая версия ОС, и эти же данные будут храниться уже в каком-нибудь бредестре (или просто ветки будут организованы по-другому). А WMI как работал, так и будет работать. Потому что его реализацию просто переделают на работу с новым бредестром.

Ответ на »сообщение 402« (Сергей О.)
___________________________

Дискуссия, которая перекочевала сюда из обсуждения вопроса на КС, началась с того, откуда брать информацию о процессоре. Там называли 3 варианта: CPUID, WMI, реестр. Меня интересовал один частный вопрос: откуда берет информацию WMI, из того же реестра, или все-таки с помощью CPUID? Кажется, что более надежным было бы для WMI брать её через CPUID, но как оно на самом деле...

А что, есть предложение, что CPU изменится с момента появления записи в реестре ? ;)

Если что, оно там записывается на ранних этапах загрузки системы...

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

Дискуссия, которая перекочевала сюда из обсуждения вопроса на КС, началась с того, откуда брать информацию о процессоре. Там называли 3 варианта: CPUID, WMI, реестр. Меня интересовал один частный вопрос: откуда берет информацию WMI, из того же реестра, или все-таки с помощью CPUID? Кажется, что более надежным было бы для WMI брать её через CPUID, но как оно на самом деле...