Как получить список запущенных приложений c
Итерации по ключу реестра «SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Uninstall», кажется, дают исчерпывающий список установленных приложений.
Помимо приведенного ниже примера, вы можете найти версию, аналогичную тому, что я сделал здесь.
Это грубый пример, вы, вероятно, захотите что-то сделать, чтобы вырезать пустые строки, как во второй предоставленной ссылке.
В качестве альтернативы вы можете использовать WMI, как уже упоминалось:
Но это довольно медленное выполнение, и я слышал, что он может отображать только программы, установленные в разделе «ALLUSERS», хотя это может быть неверно. Он также игнорирует компоненты и обновления Windows, которые могут быть вам полезны.
Я хотел иметь возможность извлекать список приложений так, как они отображаются в меню «Пуск». Используя реестр, я получал записи, которые не отображались в меню «Пуск».
Я также хотел найти путь к exe и извлечь значок, чтобы в конечном итоге сделать красивую пусковую установку. К сожалению, с методом реестра это своего рода хит и промах, поскольку, по моим наблюдениям, эта информация недоступна надежно.
Моя альтернатива основана на оболочке: AppsFolder, к которой вы можете получить доступ, запустив explorer.exe shell:appsFolder , и в которой перечислены все приложения, включая приложения из магазина, которые в настоящее время установлены и доступны через меню "Пуск". Проблема в том, что это виртуальная папка, к которой нельзя получить доступ с помощью System.IO.Directory . Вместо этого вам придется использовать собственные команды shell32. К счастью, Microsoft опубликовала Microsoft.WindowsAPICodePack-Shell на Nuget, которая является оболочкой для вышеупомянутых команд. Достаточно сказать, вот код:
Вот и все. Вы также можете запускать приложения, используя
Это работает для обычных приложений Win32 и приложений магазина UWP. Как насчет яблок.
Поскольку вас интересует перечисление всех установленных приложений, разумно ожидать, что вы, возможно, захотите также отслеживать новые или удаленные приложения, что вы можете сделать с помощью ShellObjectWatcher :
Изменить: также может быть интересно узнать, что упомянутый выше AppUserMoedlID является уникальным Идентификатор Windows, который используется для группировки окон на панели задач.
Вы можете ознакомиться с этой статьей. Он использует реестр для чтения списка установленных приложений.
Я согласен с тем, что лучше всего использовать раздел реестра.
Обратите внимание , однако, что указанный ключ, @"SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall" , будет отображать все приложения в 32-битной установке Windows и 64-битные приложения в 64-битной установке Windows.
Чтобы также видеть 32-разрядные приложения, установленные в 64-разрядной версии Windows, вам также потребуется перечислить ключ @"SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall" .
Стоит отметить, что класс Win32_Product WMI представляет продукты, установленные Установщик Windows. не каждое приложение использует установщик Windows
Однако "SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Uninstall" представляет приложения для 32-битной версии. Для 64-разрядной версии вам также необходимо пройти через «HKEY_LOCAL_MACHINE \ SOFTWARE \ Wow6432Node \ Microsoft \ Windows \ CurrentVersion \ Uninstall», и, поскольку не у каждого программного обеспечения есть 64-разрядная версия, все установленные приложения представляют собой объединение ключей в обоих местах с «UninstallString» Цените их.
Но лучшие варианты остаются теми же. поперечные ключи реестра - лучший подход, поскольку каждое приложение имеет запись в реестре [включая те, что находятся в установщике Windows]. однако метод реестра небезопасен, так как если кто-то удалит соответствующий ключ, вы не узнаете Напротив, изменение HKEY_Classes_ROOT \ Installers сложнее, поскольку связано с проблемами лицензирования, такими как Microsoft Office или другие продукты. для более надежного решения вы всегда можете комбинировать альтернативный реестр с WMI.
Хотя принятое решение работает, оно не является полным. Безусловно.
Если вы хотите получить все ключи, вам нужно учесть еще 2 вещи:
Приложения x86 и x64 не имеют доступа к одному и тому же реестру. Обычно x86 не может получить доступ к реестру x64. А некоторые приложения регистрируются только в реестре x64.
некоторые приложения фактически устанавливаются в реестр CurrentUser вместо LocalMachine
Имея это в виду, мне удалось получить ВСЕ установленные приложения, используя следующий код, БЕЗ с использованием WMI.
Просмотрите ключи «HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ Uninstall» и проверьте их значения «DisplayName».
Используйте Windows Installer API!
Это позволяет производить надежное перечисление всех программ. Реестр ненадежен, но WMI тяжеловесен.
Объект для списка:
Призыв к созданию списка:
Как указывали другие, принятый ответ не возвращает установки как x86, так и x64. Ниже мое решение для этого. Он создает StringBuilder , добавляет к нему значения реестра (с форматированием) и записывает свой вывод в текстовый файл:
Лучше всего использовать WMI. В частности, класс Win32_Product.
Существуют различные классы WMI для установленных приложений, но если он был установлен с помощью установщика Windows, то вам, вероятно, лучше всего подходит класс Win32_Product.
Я использовал подход Nicks - мне нужно было проверить, установлены ли Remote Tools для Visual Studio или нет, это кажется немного медленным, но в отдельном потоке для меня это нормально. - вот мой расширенный код:
Как получить список запущенных приложений
Здравствуйте. Подскажите пожалуйста, как получить список запущенных приложений? Попросту хочу.
Список запущенных приложений
задача в следующем: имеется форма, на форме помимо прочих контролов расположен DataGridView, нужно.
Получение caption-ов\тайтлов всех запущенных приложений
Добрый день. Нужно получить тайтлы для всех запущенных приложений, у которых они есть. Сейчас.
Данный код работает, но если попытаться прочитать путь к исполняемому файлу ( Console.WriteLine(p.MainModule.FileName); ), то под x64 мы можем получить исключение о невозможности доступа к из 32-х битного процесса к 64-х битному. Чтобы такого не происходило нужно компилировать приложение под AnyCPU.
Другой момент это то что код ориентируется на список процессов, а тебе возможно нужен список "приложений" в понимании "Диспетчера Задач Windows". В этом случае придется прибегнуть к Windows API.
Решение
Alex5, тогда лучше по аналогии примера OwenGlendower:greg zakharov, моих знаний не хватает, чтобы прочитать этот код Какие темы почитать, чтобы понять? Тут вроде лямбда функции? Что то еще? Chizel, там читать-то особо нечего. А по теме - LINQ и Regex. Alex5, так мне не список процессов нужен, а список запущенных приложений.
greg zakharov, благодарю, пошел изучать.
Получить список запущенных в системе процессов
Здравствуйте, формучане. Давно не задавал вопросы, решил написать. Честно пробовал найти на.
Мониторить список запущенных приложений по таймеру
Здравствуйте, у меня такая задача: 1. необходимо получать список всех запущенных приложений каждые.
Как получить размеры окон всех запущенных программ и их имена?
Как получить размеры окон всех запущенных программ и их имена?
Как получить список всех запущенных приложений как в диспетчере задач?
Как получить список всех запущенных приложений как в диспетчере задач вкладка Приложения (Не.
Получить список всех приложений, запущенных текущим пользователем
Как получить список всех приложений, запущенных текущим пользователем? То есть то, что показывает.
если с этого форума всех студентов заделетить то тут тогда останется два хмыря и три модератора. и форум сдохнет, отбросив копыта.
PS не обижайтесь тока те, кто не модеры и не студенты =) Просто я не уверен что профессиональные кодеры (особенно сишники) будут задавать какие-нить вопросы чтобы написать например какую-то функцию в эвристическом анализе допустим каспера
Последний раз редактировалось Аlex; 03.12.2009 в 21:58 .| если с этого форума всех студентов заделетить то тут тогда останется два хмыря и три модератора. и форум сдохнет, отбросив копыта. |
А кто второй хмырь?
Не сдохнет,просто станет меньше бестолковых тем.
| росто я не уверен что профессиональные кодеры (особенно сишники) будут задавать какие-нить вопросы чтобы написать например какую-то функцию в эвристическом анализе допустим каспера |
| PS не обижайтесь тока те, кто не модеры и не студенты =) Просто я не уверен что профессиональные кодеры (особенно сишники) будут задавать какие-нить вопросы чтобы написать например какую-то функцию в эвристическом анализе допустим каспера |
категорически не согласен =)
для тех, кто не умеет и не хочет ничего делать есть фриланс
если можно то лучше бы пример и на русском йазыке
реально облазил весь инет - там только для Delphi а MS VC++ 2008 нету ничё.
и желательно поподробнее а то я С++ вообще не знаю.
у делфи и Си одинаковые функции. ну могут различаться там кол-ом параметров, ну может и не одинаковые, но функции которые я тырил с исходников делфи у меня хорошо шли на Си, я тоже хотел такой темой заняться, там специально от мелкого, чтобы не играл в определенное время, но пока нету возможности, так что выкладывай код хотя бы на Дэлфиp.s. если Вы не хотите учится, не получаите ответы, зачем обсерать людей других ?
если можно то лучше бы пример и на русском йазыке
реально облазил весь инет - там только для Delphi а MS VC++ 2008 нету ничё.
и желательно поподробнее а то я С++ вообще не знаю.
Схема следующая:
1. Делаешь снепшот системы.
2. Объявляешь структуру, в которой будет храниться информация о процессах.
использую c++17 c++20
имеется приложение, которое использует ресурсы используя относительные пути — как выяснить реальный путь в файловой системе до самого бинаря внутри кода?
апд
в общем найдено несколько способов:
1. только для систем с procfs — C++ как получить путь запущенного приложения? (комментарий)
2. по идее кроссплатформенный через sdl2 — C++ как получить путь запущенного приложения? (комментарий)
3. использовать метод нахождения используемый в which (определять является ли argv путем, если да то каким — относительным или абсолютным, если нет, то искать название бинарника по путям в env var PATH)
я так понимаю std::filesystem не содержит такой возможности?
надо будет по подобию which делать ?
Относительные относительно бинаря или таки рабочего каталога?
readlink("/proc/self/exe", buf, bufsize)
относительные именно бинаря. — я просто юзаю файлы ресурсов — скажем бинарь может быть в /usr/bin, а ресы в /usr/share — неплоха было бы просто сделать ../share
но файл может же запускаться и просто по имени — тогда такой фокус не проходит по arcv[0].
но походу да — для линукса тут будет именно readlink.
попробую в коде отвечу то или нет.
Это linux-специфично и непереносимо. Правильно сказали - конфигурировать пути при cборке.
работает именно так как я хотел
думаю можно закрывать.
для винды аналог как я понимаю енто GetModuleFileName?
Я не про readlink , а про /proc/self/exe - нигде кроме линукса её нет.
да понятно — ну в винде своя функция есть — через дефайны буду делать.
Кроме винды и линукса есть ещё куча операционных систем.
Правильно сказали - конфигурировать пути при cборке.
Это ещё хуже. Бинарник и данные должны работать из любого места.
Кроме винды и линукса есть ещё куча операционных систем.
в argv[0] еще может быть ваще другое — енто же не путь запускного файла — енто команда запуска — она может состоять из вообще других слов, нежели путь к exe.
в ентом то и проблема — пока я не начал устанавливать прогу в /usr/bin все было норм — но когда поставил туда и запустил не путем а командой — тоесть просто по названию проги — перестали действовать относительные пути к ресурсам.
я просто изначально думал чо в std::filesystem реализован механизм обнаружения пути к exe — но увы — нет.
safocl ★★ ( 15.01.21 05:04:06 )Последнее исправление: safocl 15.01.21 05:07:13 (всего исправлений: 2)
потому что данные программа должна собирать с приоритетами:
переменная среды MY_PROG_DATA
через сборку препроцессора, $MY_PROG_DATA
глобальное хостовые пути xdg
пользовательские пути xdg
3 и 4 местами поменяй.
Хрена вы норкоманы.
Но в целом, глобальную проблему ТС решает именно такой подход, только и правда последние два пункта надо свапнуть.
Резолвить argv[0] до абсолютного пути не помогает, если программа не была запущена по абсолютному пути:
(Не говоря уже о том, что в системном вызове execve в argv[0] можно подставить любую чушь, не имеющую ничего общего с путём к исполняемому файлу.)
Лол, значит я был не прав, интересный факт, спасибки.
Надо ещё символьные ссылки резолвить.
а ресы в /usr/share — неплоха было бы просто сделать ../share
Так делать глупо.
После старта бинарники:
Он считывает переменные окружения PATH_БЛАБЛА_ДЛЯ_БЛА и т.п. Если их нет, то использует дефолт (man hier).
Использует параметры, если их нет, то использует дефолты (man hier).
Он читает конфиг, где определены пути. Если его нет, то использует дефолт (man hier).
Он использует стандартные пути (man hier).
Полные пути рулят.
Файловая система и твой ехе это как бы разные вещи, с чего бы рантайм лабуде быть в std::filesystem?
чуть выше уже был коммент на счет argv[0] — енто не путь исполняемого файла — а команда запуска программы — она может быть ваще не путем, да и ваще не особо относиться к названию бинаря проги.
ну в таком случае если ты портабельно собрал прогу она не найдет ресы.
путь там указывается.
да и текущий каталог ведь можно узнать через std::filesystem — енто тоже рантайм сущность.
кстати нашел один кроссплатформенный способ — через SDL2/SDL_filesystem.h — функция SDL_GetBasePath() возвращает реальный путь нахождения проги.
safocl ★★ ( 15.01.21 13:40:46 )Последнее исправление: safocl 15.01.21 13:47:26 (всего исправлений: 1)
argv[0] ёпта, при старте приложения.
Разговор же идёт про обычный вариант сборки (/usr/bin, /usr/share и т.п.). С портабельной версией придётся работать через переменные окружения или ./бла-бла. Тут даже спорить не нужно.
Это linux-специфично и непереносимо.
Можно натравить which или своровать код поиска (по списку путей в PATH).
да зачем если есть /proc/self/exe симлинк ведущий к бинарю?
Это linux-специфично и непереносимо.
Это если надо переносимо. Решение, естественно, неточное - нужно чтобы совпали алгоритмы и данные для поиска пути у приложения и у системы.
Это ещё хуже. Бинарник и данные должны работать из любого места.
- Кто это сказал?
- Какие аргументы?
- В каких пределах это должно работать?
Потому что либо ты хардкодишь абсолютный путь, либо относительный. В первом случае ты можешь бинарник переносить куда угодно и он продолжит работать. Во втором можешь переносить только параллельно с данными. В разных случаях может потребоваться разное.
Претензия здесь не к одному из этих вариантов, потому что требование ровно одно - бинарник должен работать так как его установили, и ему удовлетворяют оба. Но к способу получения пути к бинарнику который непереносим, и быдлокод с /proc/self/exe просто сломается на *bsd, haiku, macos и ещё куче систем.
Но к способу получения пути к бинарнику который непереносим, и быдлокод с /proc/self/exe просто сломается на *bsd, haiku, macos и ещё куче систем.
ессесна — надо делать разные пути для проверки — сам способ не меняется на юникс подобных системах. — но выше же и сказано чо енто непереносимо.
Это говённый код который надо допиливать под каждую новую систему чтобы запустить. Едва ли от автора можно ожидать что он знает как получить путь к бинарнику на всех существующих системах. И потом всё уткнётся в систему где этого сделать вообще нельзя и всё равно будет добавлен универсальный способ с абсолютным путём.
В итоге получаем:
- Коллекцию способов получить путь к бинарнику на несколько страниц мёртвого кода, из которого тестируется только тот что работает на системе автора
- Теряем поддержку относительной переносимости, потому что она уже не везде работает
Поэтому собственно везде и всегда используются абсолютные пути, и это единственный правильный способ.
Можно ещё через argv[0] путь получить, но там могут быть символьные ссылки и относительные пути.
Нельзя, если бинарник запущен через $PATH там вообще пути не будет. Поведение зависит от шелла и на самом деле там вообще не обязано оказаться что-либо осмысленное.
так а способ с применением sdl2 который я выше привел он что не везде работает где есть sdl2?
Какие ещё разные пути? На других системах нет никаких путей аналогичных /proc/self/exe
В разных дистрибутивах разные пути. Если хранить данные относительно бинарника, то будет работать везде. Часто даже без перекомпиляции. Встречал вредителей, которые даже абсолютный путь к динамическим библиотекам при линковке бинарника прописывают. А потом долго ищешь почему нужная динамическая библиотека не загружается.
Встречал вредителей, которые даже абсолютный путь к динамическим библиотекам при линковке бинарника прописывают.
я хароший — такого вроде еще не делал)) вухахахахах
Едва ли от автора можно ожидать что он знает как получить путь к бинарнику на всех существующих системах.
Я допишу (для Haiku). Дело 5 минут.
В разных дистрибутивах разные пути. Если хранить данные относительно бинарника, то будет работать везде.
Разные пути в том числе и относительные, так что мимо.
Встречал вредителей, которые даже абсолютный путь к динамическим библиотекам при линковке бинарника прописывают.
Абсолютный путь при линковке нужно прописывать обязательно (так делает cmake например), потому что так разрешаются неоднозначности между разными версиями библиотек, а также статическими и данамическими библиотеками. Это никак не влияет на то как рантайм линкер ищет библиотеки.
Читайте также: