Расширяем контекстное меню кнопки «Пуск» в Windows 8.1

[@Gero]

Неужели Microsoft не оставила способа расширения данного меню через реестр? Совсем что-то сдали разрабы.
Два вопроса к автору:
1. На данные хаки виндовая защита не ругается?
2. Не проще ли было сделать свое меню с блекджеком и чем угодно?

[@Gero]

Не дочитал до конца, оказывается, меню легко расширяется через каталоги, зачем было городить огород? )

[@LrdSpr]

Ну мне нужна была группировка, в стандарте она у меня не сработала. Да и статья скорее как обзор возможностей, занимался ввиду наличия свободного времени и интереса по теме.

[@Lincoln6Echo]

Майкрософт последние пару лет не приветствует работу с реестром — набирайте очки в программе Windows Logo и печеньки в ClickOnce, там расписано, а на конференциях уже давно говорится, что виндовый реестр в обозримом будущем станет obsolete.

Вероятнее всего, данный пост сократит жизненный цикл описаного хака в качестве хака, потому-что он — инъекция, запинают его в Microsoft Security Essentials, а далее он попадет во все антивирусные базы.

[@Gero]

Как это «не приветсвует работу», если все системные настройки, в том числе и новые хранятся до сих пор там? Или есть новое хранилище? Что предлагается использовать?
Я просто несколько лет уже не пишу под Windows, поэтому не в курсе трендов, но буду признаетелен, если вы в двух словах объясните или бросите подходящие ссылки, раз вы в теме.

[@Lincoln6Echo]

Local Applications Data или в системной учетной записи, или в локальной юзера. Папки есть, роуминг на них еще с Висты. Внутри AppData можно любом виде, или как классические ini, или как хочется, это приват приложения и его личное дело как хранить настройки.

[@Gero]

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

[@Lincoln6Echo]

Я сериализую XML. Создаю там свою папку и фигачу туда что хочу. Похоже на работу с Windows Azure
.
Идея такая. Изменяемые файлы приложения должны быть в «ProgramData», если они относятся целиком к приложению.
Само приложение в неизменяемой без привелегий папке «Program Files».
Локальные настройки в учетных записях. Для сервисов в Системной учетной записи в AppData. Локальные изменяемые для конкретного юзера в его собственой AppData. Для всех — в AppData для Public
Это +100 (иноскозательно) для прохождения текущего теста Windows Logo.

[@Gero]

Интересно, а Google Chrome не проходит сей тест? Он-то в локальную AppData инсталлится и все пишет )

[@Lincoln6Echo]

Микрософт пока тиранию на соблюдение своих спецификаций не ввел. И, наверное, не введет… тиранию… в силу давней любви к обратной совместимости.

[@Lincoln6Echo]

ini не устарели, зря вы так. Они просто эффективны лишь для одномерных данных без вложений и массивов. По-старинке тупо сохранить три строки: адрес до сервера, логин и хэш пароля вызовом нативного Win32 API — быстро и эффективно резко как понос.

[@Gero]

Верно, начать использовать их просто, но с ростом приложения начинаются проблемы (из собственного опыта):
1. Стандартные WinAPI функции не поддеррживают INI-файлы размером более 64кб.
2. Появляется необходимость хранить более сложные данные

И когда это происходит в боевом приложении не первой версии, нужно полностью переписывать подсистему настроек, делая еще и перенос старых настроек в новый формат для существующих пользователей, что может быть весьма накладно. Куда лучше сразу писать как минимум в XML. А пользовательские данные, количество которых не фиксированно — сразу в Integrated DB, даже если сначала кажется, что записей не будет более десятка-другого (потом их могут оказаться тысячи).

[@Lincoln6Echo]

Все так и есть, согласен. Но в простых случаях, где можно не заморачиваться и использовать ini, который правится блокнотом неподготовленным юзером при телефонной консультации — благо ;)

[@pieceofsummer]

Еще как устарели!
Рядом с каждой функцией, относящейся к ini, есть пометка: «This function is provided only for compatibility with 16-bit Windows-based applications. Applications should store initialization information in the registry.»

[@Lincoln6Echo]

А файлы не относящиеся к уонкретным настойкам должны быть в (скрытой) папке ProgramData на системном диске в корне, как и к локальной папке AppData юзера или системных учеток туда ведут системные переменные. В .Net например так в ProgramData попасть:

string path = Environment.GetFolderPath(Environment.SpecialFolder.CommonApplicationData)  + "\\Komdiagnostika";
DirectoryInfo inf = new DirectoryInfo(path);
if (!inf.Exists)
     inf.Create();

[@boov]

Спасибо за наводку на API Monitor.