Хотим переделать старое приложение, которое ранее для своей работы требовало отключения UAC (если быть более точным - не было рассчитано на работу под ограниченными учетными записями), а по сему все свои настройки хранило в ветке реестра HKLM\Software\<FirmName>\<AppName>. Все пользователи могли из программы менять эти настройки и всем было хорошо.
Когда в майкрософте решили повысить защищенность ОС, некоторые пользователи стали иметь доступ к этой ветке реестра только на чтение и уже поменять ничего по сути не могут. При включенном UAC эта ветка как я знаю, виртуализируется, поэтому ограниченные учетки могут сохранять измененные ими данные настроек программы в своей виртуализированной ветке. Но это не будет теперь доступно для других пользователей. Более того, насколько мне известно, в 64-разрядной ОС эти ветки при включенном UAC не виртуализируются, а значит будем иметь проблемы.
Соответственно возникает вопрос: можно ли убрать настройки программы из этой ветки реестра, чтобы все пользователи как и раньше имели возможность менять их, и если это возможно, то куда лучше всего их переместить. Или может организовать какое другое хранилище этих настроек? Например инишный файл (хотя как по мне - это атавизм и давно устаревшая практика)?
Это приложение многопользовательское и на одной машине может быть запущено его несколько экземпляров.
У кого какие будут соображения на этот счет?

Погоди, я же тебе все подробно по аське все моменты еще две недели объяснил как именно организовать в твоем случае хранение настроек, не срослось что-то?

Типа того. :( Не устраивает начальство то, что у ограниченных пользователей будут свои копии настроек. Хотят чтобы было как раньше, но чтобы работало со включенным UAC. И чтобы настройки были централизованные и чтобы все могли из программы их менять без необходимости давать юзерам расширенные права на запись.
То, что ты мне тогда по аське написал, я попробовал и остался доволен, т. к практически ничего менять в моем коде в программе не пришлось за исключением флагов открытия ключей реестра в зависимости от уровня прав пользователя. А вот начальство такой вариант не устроил. :(

> И чтобы настройки были централизованные и чтобы все могли
> из программы их менять без необходимости давать юзерам расширенные
> права на запись.

В таком случае не получится, либо будет через пень колоду.
Есть конечно вариант - писать централизированный сервис настроек, но это вариант через то еще место с твоими требованиями.

> А вот начальство такой вариант не устроил. :(

Кстати, а начальство то технически подкованное? :)))
Тыж можешь сказать что сделал как они хотят, не вдаваясь в детали ;)

чем то похожее было... суть/причина другая но похоже
у меня был
> Например инишный файл (хотя как по мне - это атавизм и давно устаревшая практика)?
нифига не атавизм, удобно, все  (/мелкософт/...) так делают, но "стесняются"...
собственно вот http://pda.delphimaster.net/?n=5&id=1357723591&p=1

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

кстати у тебя, если пользователи/настройки всегда на одной машине, можно и в AppData ini-ник держать.

> можно и в AppData ini-ник держать.

Этот вариант обсуждался с автором, но по ТЗ вносить туда изменения могут только доверенные пользователи, что в случае INI файла нереально обеспечить (FAT32 тот-же, где нельзя навесить нужные права на файл)

> вносить туда изменения могут только доверенные пользователи
тогда любое место хранения подойдет по схеме с RunAs, где у этих доверенных пользователей будут права на запись, а остальным будет предложено ввести логин/пароль.
хоть место в расшарке в сети (права обеспечит сервер).

> FAT32 тот-же, где нельзя навесить нужные права на файл
эээ... а нужен именно такой, настолько, универсальный метод? почему тогда fat16 исключен?

> FAT32 тот-же, где нельзя навесить нужные права на файл

Имхо, столь общего решения данная задача не имеет.

Не. Тут уж вы загнули. FAT32 (и тем более FAT16) не рассматривается. :)

> harisma ©   (12.03.13 13:07) [10]
> Не. Тут уж вы загнули. FAT32 (и тем более FAT16) не рассматривается.
>  :)

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

> [11] Rouse_ ©   (12.03.13 14:00)
> FAT32 присутствует примерно в 30 процентах случаев.

Интересно, как наличие FAT32/NTFS коррелирует с остальными параметрами системы?

В смысле? У меня EP2 файлы эвриковские валятся где вгоняются в базенку, где разбивается по параметрам, ОС/память/файловая система и т.п. и отображается в процентном соотношении. В основном народ сидит на ХР, где больше половины на файловой системе FAT32.

> если ты будешь отказываться работать на FAT32
а кто отказывается работать? отказ только в разделении файловых прав на нем... причем объяснение "винда тут сама не разделяет" клиентами легко понимается.

ИМХО, не стоит усложнять себе жизнь выдуманными проблемами, реальных хватает.

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

> Все пользователи могли из программы менять эти настройки
> и всем было хорошо.

Не все - а только те у кого были соответствующие права, собственно от сюда я и пляшу :)
Кабы не это условие, все давно бы уже разрешилось :)

> [13] Rouse_ ©   (12.03.13 14:29)
> В основном народ сидит на ХР, где больше половины на файловой системе FAT32

Так и подумал. XP позволяла себя ставить на ФАТ, а народ боялся НТФС.

Систему давно не переставлял - а семерка разве не позволяет? (ну, не в курсе просто...)

> [17] Rouse_ ©   (12.03.13 15:03)
> а семерка разве не позволяет?

По крайней мере не предлагает в инсталяторе, а это для 99,9% всё равно что не позволяет. ХП ещё ставили (или даже обновление было) на диски с Вин98. Вин7 на такие компьютеры вряд ли кто будет ставить, а на новые НТФС. В общем, думаю, ноги наличия ФАТ оттуда растут, а не от реальной необходимости в ней.

>  В общем, думаю, ноги наличия ФАТ оттуда растут, а не от
> реальной необходимости в ней.

Даже спорить не буду - вероятно так оно и есть.