Comments 17
Неужели Microsoft не оставила способа расширения данного меню через реестр? Совсем что-то сдали разрабы.
Два вопроса к автору:
1. На данные хаки виндовая защита не ругается?
2. Не проще ли было сделать свое меню с блекджеком и чем угодно?
Два вопроса к автору:
1. На данные хаки виндовая защита не ругается?
2. Не проще ли было сделать свое меню с блекджеком и чем угодно?
Не дочитал до конца, оказывается, меню легко расширяется через каталоги, зачем было городить огород? )
Майкрософт последние пару лет не приветствует работу с реестром — набирайте очки в программе Windows Logo и печеньки в ClickOnce, там расписано, а на конференциях уже давно говорится, что виндовый реестр в обозримом будущем станет obsolete.
Вероятнее всего, данный пост сократит жизненный цикл описаного хака в качестве хака, потому-что он — инъекция, запинают его в Microsoft Security Essentials, а далее он попадет во все антивирусные базы.
Вероятнее всего, данный пост сократит жизненный цикл описаного хака в качестве хака, потому-что он — инъекция, запинают его в Microsoft Security Essentials, а далее он попадет во все антивирусные базы.
Как это «не приветсвует работу», если все системные настройки, в том числе и новые хранятся до сих пор там? Или есть новое хранилище? Что предлагается использовать?
Я просто несколько лет уже не пишу под Windows, поэтому не в курсе трендов, но буду признаетелен, если вы в двух словах объясните или бросите подходящие ссылки, раз вы в теме.
Я просто несколько лет уже не пишу под Windows, поэтому не в курсе трендов, но буду признаетелен, если вы в двух словах объясните или бросите подходящие ссылки, раз вы в теме.
Local Applications Data или в системной учетной записи, или в локальной юзера. Папки есть, роуминг на них еще с Висты. Внутри AppData можно любом виде, или как классические ini, или как хочется, это приват приложения и его личное дело как хранить настройки.
А система, оболочка, сервисы тоже теперь в файлах все хранят?
В appdata давно можно хранить как угодно, только вот конкретно ini уже сто лет как устарели и не рекомендуются к использованию.
В appdata давно можно хранить как угодно, только вот конкретно ini уже сто лет как устарели и не рекомендуются к использованию.
Я сериализую XML. Создаю там свою папку и фигачу туда что хочу. Похоже на работу с Windows Azure
.
Идея такая. Изменяемые файлы приложения должны быть в «ProgramData», если они относятся целиком к приложению.
Само приложение в неизменяемой без привелегий папке «Program Files».
Локальные настройки в учетных записях. Для сервисов в Системной учетной записи в AppData. Локальные изменяемые для конкретного юзера в его собственой AppData. Для всех — в AppData для Public
Это +100 (иноскозательно) для прохождения текущего теста Windows Logo.
.
Идея такая. Изменяемые файлы приложения должны быть в «ProgramData», если они относятся целиком к приложению.
Само приложение в неизменяемой без привелегий папке «Program Files».
Локальные настройки в учетных записях. Для сервисов в Системной учетной записи в AppData. Локальные изменяемые для конкретного юзера в его собственой AppData. Для всех — в AppData для Public
Это +100 (иноскозательно) для прохождения текущего теста Windows Logo.
ini не устарели, зря вы так. Они просто эффективны лишь для одномерных данных без вложений и массивов. По-старинке тупо сохранить три строки: адрес до сервера, логин и хэш пароля вызовом нативного Win32 API — быстро и эффективно резко как понос.
Верно, начать использовать их просто, но с ростом приложения начинаются проблемы (из собственного опыта):
1. Стандартные WinAPI функции не поддеррживают INI-файлы размером более 64кб.
2. Появляется необходимость хранить более сложные данные
И когда это происходит в боевом приложении не первой версии, нужно полностью переписывать подсистему настроек, делая еще и перенос старых настроек в новый формат для существующих пользователей, что может быть весьма накладно. Куда лучше сразу писать как минимум в XML. А пользовательские данные, количество которых не фиксированно — сразу в Integrated DB, даже если сначала кажется, что записей не будет более десятка-другого (потом их могут оказаться тысячи).
1. Стандартные WinAPI функции не поддеррживают INI-файлы размером более 64кб.
2. Появляется необходимость хранить более сложные данные
И когда это происходит в боевом приложении не первой версии, нужно полностью переписывать подсистему настроек, делая еще и перенос старых настроек в новый формат для существующих пользователей, что может быть весьма накладно. Куда лучше сразу писать как минимум в XML. А пользовательские данные, количество которых не фиксированно — сразу в Integrated DB, даже если сначала кажется, что записей не будет более десятка-другого (потом их могут оказаться тысячи).
Еще как устарели!
Рядом с каждой функцией, относящейся к ini, есть пометка: «This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.»
Рядом с каждой функцией, относящейся к ini, есть пометка: «This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.»
А файлы не относящиеся к уонкретным настойкам должны быть в (скрытой) папке ProgramData на системном диске в корне, как и к локальной папке AppData юзера или системных учеток туда ведут системные переменные. В .Net например так в ProgramData попасть:
string path = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData) + "\\Komdiagnostika";
DirectoryInfo inf = new DirectoryInfo(path);
if (!inf.Exists)
inf.Create();
UFO just landed and posted this here
Спасибо за наводку на API Monitor.
Sign up to leave a comment.
Расширяем контекстное меню кнопки «Пуск» в Windows 8.1