запуск другой программы

[LeshikSan]

Здравствуйте!

Стоит задача запустить программу при условиях:
1)путь к программе неизвестен
2)нужно запустить определенную версию программы, поскольку в системе могут стоять две и более версии с одинаковым именем exe-файла

[PooH]

прописываешь переменную окружения PATH к нужному каталогу.

и запускаешь просто по имени.

[LeshikSan]

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

[PooH]

Условия были определены только на запуск программы - поэтому и выделил.
Правильно поставленый вопрос - это уже половина ответа. Самый тривиальный (и тупой) путь обходишь весь диск, проверяешь версию программы и запускаешь. Остальные решения зависят от самой программы и способа версифицирования.

[Вад]

Тут такой вопрос: собственно, а цель задумки какова?
А то ведь от изначальной идеи тоже зависит, какое решение окажется разумным. Может быть (ну, чисто программистский вариант), нужно один раз явно заставить пользователя указать путь (ну или поискать программно, включая всякие варианты по умолчанию), а потом запомнить единожды найденное и пользоваться (по аналогии с тем, как в каком-нибудь Eclipse пути к SDK и компиляторам прописываются).

[LeshikSan]

Вад, да, это вариант!
Но странно, что вроде как простая задача пределения списка установленного ПО вызывает сложности. Поискал по сети, предлагают например использовать список "Установка и удаление программ", не знаете - есть ли для этого стандартная функция?

Мне нужно чтобы моя програмка делала следующее: при ее запуске выводила окно со списком программ в виде кнопок, нажатие на одну из которых запускало бы соответствующую программу (если она присутствует в системе, а также если она еще не запущена) и передавало ей скрипт на выполнение.

[PooH]

Если прога себя довольно корректно прописывает в системе, то её можно попробовать найти по её деисталятору, тут: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
Но как я и писал, этот способ уже зависит от проги.

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

[LeshikSan]

а как определить путь к системной Program files? и как считать с экзешника программы название и версию этой программы?

[Антон (LogRus)]

1. переменные окружения
2. GetModuleHandle->FindResource->LoadResource

[PooH]

а как определить путь к системной Program files?

SHGetSpecialFolderPath Function

[Dimka]

А я бы не доверял. Я, например, разные программы ставлю на разные диски, так что в системной Program Files далеко не всё.

[PooH]

и как считать с экзешника программы название и версию этой программы?

сам не использовал, но вот нашел инфу

[LeshikSan]

LogRus, PooH, спасибо большое!

dimka, да, справедливо. тогда придется добавить вариант ручного выбора к проге.

Еще вопрос по  Visual Studio (я в visual c++ только собираюсь войти, пока что мой багаж - JS):
не могу найти внятной информации принципов работы с заголовочными файлами и вообще SDK.
Вот, например,  имееся урок, там указан iostream.h. Запускаю компиляцию простого cout<<'hello world!'; - выдает:
- Не удается открыть файл include: iostream.h
Как проверить - подключен он у меня к Visual или нет. Как их, собственно подгружать к Visual Studio чтоб компилятор их видел?
В структуре моего проекта присутствует папка 'Заголовочные файлы', в ней - три .h-файла (stdafx.h, targetver.h, resource.h). Означает ли это что только они доступны компилятору?

Простите за такой примитив, но про эти простейшие вещи я почему-то не могу найти ничего.

[Вад]

Конкретно iostream.h в новых версиях имеет имя "iostream", без ".h". Это касается всех заголовков стандартной библиотеки C++: в старых версиях файлы имели расширение ".h", впоследствии они его лишились. Поскольку эти файлы - из стандартной библиотеки, то они должны быть обязательно видны при сборке любого C++-проекта.

Компилятору доступны (видны) все заголовочные файлы, находящиеся по определённым путям (включая пути по умолчанию к библиотекам - стандартной и Microsoft-овским). Директория проекта тоже входит в число таких путей.

Вообще, лучше взять две вещи: хороший учебник по C++ (позволит разобраться с самим языком, а также с заголовочными файлами и стандартной структурой проекта в целом) и какое-нибудь пособие по конкретно Visual C++ - чтобы разобраться с тем, как пользоваться средой при разработке Windows-приложений, и что ещё VS может предложить на эту тему. Короче, следует разделять среду и язык, и изучать оба вопроса.

[LeshikSan]

тогда почему при создании нового проекта стандартная пустая main-ф-ция сопровождается  #include "stdafx.h" с постфиксом .h (у меня VS 2008)?
и где можно прописать пути к другим SDK?
----
просто я сейчас прохожу учебник по c++  и хотелось бы сразу щупать руками те примеры, которые там приводятся. А получается такой порочный круг: учебники по языку предполагают знание Visual Studio, поэтому не делают пояснений, а учебник по VS в свою очередь предполагает знание c++, и там вообще ничего не понятно.

[Вад]

LeshikSan, потому что stdafx.h не является заголовком стандартной библиотеки. Скорее, это стандарт (да и то, наверное, большей частью чисто Microsoft-овский), как реализовывать прекомпиляцию заголовков. Там ещё и stdafx.cpp в проекте может присутствовать, если эта прекомпиляция была включена. Суть этих всех тонкостей - в оптимизации процесса компиляции.

Пути к каким sdk ты хочешь прописать? Как бы то ни было, в настройках проекта есть опция, что-то типа "Include paths" (не помню, как он точно называется), куда можно добавить все пути, по которым находятся сторонние заголовочные файлы, которые нужно включать. Только если это не какой-нибудь boost или другие шаблонные библиотеки, то придётся ещё и параметры линковки задавать.

[LeshikSan]

вот сейчас строку #include "stdafx.h" привел в вид #include "stdafx" - компилятор выда ошибку. По каким критериям определять где ставить .h а где нет?
и равнозначна ли запись #include "stdafx.h" записи #include <stdafx.h>? встречал в учебниках и то и другое
-----
вот нашел на другом форуме пост за 2004 год:

Чтоб подключить в 6ой версии, идём в настройки проекта (Alt+F7) -> C/C++
Выбираем категорию Preprocessor и вводим дополнительнй путь (3 окошко ввода сверху)
../MyLib
это позволит делать #include без указания пути - в нашем случае
#include <MyLib.h> вместо #include "..\\MyLib\\MyLib.h"
Переходим на страничку настроек Linker. Выбираем категорию Input (Ввод)
если в списке используемых библиотек уже что-то стоит, то добавляем через пробел :!:  нашу библиотеку:
kernel32.lib user32.lib gdi32.lib winspool.lib MyLib.lib
можно сразу указать путь к ней - "../MyLib/MyLib.lib" ,  но ( если планируется использовать несколько LIB) лучше это сделать в соответствующем месте - доп. пути для библиотек.
Вписываем туда ../MyLib
Нажимаем Ок.
Теперь достаточно инклудировать MyLib.h (например в stdafx.h) и доступ к функциям и классам этой библиотеки готов.

Примечания:
1. Если используется несколько библиотек и они лежат в разных местах, то необходимо перечислить все пути к h- и lib-файлам, через запятую. И все lib-файлы через пробел.
2. Если есть различные конфигурации проекта (напр. Debug и Release), то необходимо выполнить подключение библиотеки в каждой конфигурации.
3. Если вариант с DLL, после сборки она должна находится там, где находится ЕХЕ.

Это еще актуально для VS 2008?

[Вад]

Всё правильно: можешь заглянуть в каталог проекта и убедиться: там лежит файл stdafx.h, и никакого stdafx (без расширения) там нет. В глубинах каталога includes в VS, напротив, есть файл iostream, но нет (по крайней мере, не должно быть) никакого iostream.h.

Угловые скобки указывают компилятору на то, что файл следует искать в стандартном каталоге заголовочных файлов. Кавычки - что файл следует искать в текущем каталоге проекта (или по явно определённому там пути, типа "C:\myincludes\myincude.h" или относительному: "inc\myinclude.h"). Ещё раз: в C/С++ заголовочные файлы именуются с окончанием/расширением ".h" (редко - ".hpp" для C++). Это не обязательное правило, а общепринятое соглашение. Файлы стандартной библиотеки такого расширения не имеют (кроме устаревших версий).

Видимо, учебники у тебя недостаточно хороши Не советовал бы пользоваться книгой "Язык программирования С++" Страуструпа как учебником по C++, но как справочник вот на такие вопросы, пожалуй, сойдёт.

[Вад]

Это еще актуально для VS 2008?

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

[LeshikSan]

да, точно, я сначал взялся за Java, но бросил потому что те учебники, которые я находил - это что-то невозможное, для кого их пишут непонятно (а ведь java куда проще)
для c++ нашел вот этот учебник, мне в самый раз пока, но там о работе в среде програмирования ничего нет.
----
Вад, а как в VS просматривать ресурсы доступных библиотек? так чтобы не проверять каждый раз поиском есть ли тот или иной .h

[Вад]

    #include <iostream.h>
    void main(void)
    {
       cout << "Учимся программировать на языке C++!";
    }

блин, сдаётся мне, эти научат... Во-первых, cout уже сто лет в обед как в пространстве имён std. Во-вторых, по стандарту функция main должна иметь тип int - этот код вообще не будет компилироваться на современных компиляторах
Лучше, имхо, найти учебник поновее - а то постоянно придётся делать поправки на ветер.

2all: что сейчас есть хорошее в плане учебников по C++? Я в своё время учил по Страуструпу и немного по "Бархатному пути" - так они мне изрядно мозги загадили

[LeshikSan]

ну, да, что он уже устарел я это понял, но основы языка разжевываются достаточно хорошо
--
присединяюсь 

[Вад]

как в VS просматривать ресурсы доступных библиотек?

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

То есть, заголовки, в принципе, могут называться как угодно и содержать что угодно. Главное, чтобы всё это было так или иначе объявлено и скомпилировано, чтобы на этапе линковки исполняемого кода все зависимости срослись - иначе (если не срастутся зависимости) даже программа, не содержащая ни единой синтаксической ошибки, не будет собрана в исполняемый файл (произойдёт ошибка линковки).

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