Есть A.exe и B.exe. B.exe содержит таблицу экспорта. Запускаем A.exe. A.exe вызывает CreateProcess и запускает B.exe A.exe вызывает LoadLibrary c параметром B.exe А теперь вопрос. Как сделать так, чтобы инстанц B.exe не продублировался, а взялся уже существующий?
- ты же запустил B.exe - у него теперь свой процесс и он выполняется с его родной базой - потом в свой процесс ты мапишь B.exe, можно сказать просто прочитал файл к себе, тут база у него может быть любая свободная Как понимать продублирование инстанца?
Чтобы B.exe не мапился второй раз в память, а взялся от уже отмапленного exe-шника, т.е. чтобы HINSTANCE B.exe был равен HMODULE B.exe
АП разные будут. А мапить надо в конкретное АП. А вообще как родился такой интересный вопрос? Зачем поставлена такая цель?
Bill_Prisoner Это ясен болт. Вот и интересно, как их в одно пространство замапить. Интересно посмотреть на поведение просесса, когда у него снаружи будут дергать экспортируемые функции. Сначала хотелось таким образом управлять процессом, но чувствую будет гемор с синхронизацией. Вобщем, как это часто бывает, надобность отпала, но вопрос остался
Попробуй так, может и выйдет: 1)A.exe вызывает LoadLibrary c параметром B.exe 2)создаёшь поток с точкой входа в уже промапленом B.exe. Правда косяков всяких возникнуть может.
Гм. Раз вопрос немного исказили. Будем говорить о траблах метода asd: 1) CreateProcess может запускать программу любой подсистемы, а здесь только для подсистемы win32 2) АП пространство процесса будет более узкое из-за модулей A.exe 3) Траблы с приоритетами процесса. 4) Если B.exe - консольное приложение, то оно не появиться автоматически. Его придеться создавать вручную. 5) Параметры командной строки отменяются. 6) Нормальная работа GetModuleHandle(NULL) отменяеться. 7) Переменные окружения отменяються. Они будут, но совместное использование переменных не желательно. 8) Функции требующие hProcess обламываются. 9) Размер стека потока для B.exe может отличаться от размера стека потока A.exe. 10) релоков в большинстве exe сейчас нету, а в данном случае b.exe промэппиться точно не по базовому адресу. Крах обеспечен. 11) CreateWindow обломиться т.к. она требует hInstance, а hInstance получается с помощью вызова GetModuleHandle(смотри 6). Это только то что сразу пришло в голову, а если смотреть более подробно, то...
Ну, для конкретного случая может и подойти. 7)Ладно окружение, без него можно и обойтись, а вот переменные в В.ехе 10)А вот про релоки интересно: если В.ехе будет что-либо экспортировать, то не вставит ли компилятор релоки автоматически.
asd Смотря какой компилер, но все таки это очень зависит от самой проги B.exe и ее создателя. Если он захочет вставить релоки, то он их вставит. Если есть конечно цель, создать именно такую прогу, то это подойдет, но в большинстве случает будет оболом.
_DEN_ Можно то можно, но все проблемы остануться. Это как говориться - "грибы можно есть все, но только некоторые один раз в жизни".
_DEN_ Очень просто. Есть функция GetModuleHandle. Передаем ей параметр NULL. Это означаем что мы получем описатель модуля из которого вызывается функция. НО при вызове ее из DLL которой является B.exe(DLL - потому что мы загружаем ее через LoadLibrary) функция возвращет адрес A.exe, а yt адрес B.exe. А MZ-то полюбому будет.
_DEN_ Ну какие проблемы тут будут с HINSTANCE? Ну если тебя только эта проблема занимает, то тут решение просто. Вместо GetModuleHandle находи базу ручками.
Хмм... А что будет если в DllMain по PROCESS_ATTACH создать поток, который не будет завершен по выходу из DllMain? Всмысле, какая дальнейшая судьба потока?
_DEN_ Поток созданный в DllMain как правило начнет выполнятся (а стало быть и сможет завершится) после выхода из DllMain. Уникальный в своем роде трабл, его надо учитывать при написании внутрипроцессных серверов. Например попытка "подождать" такой поток с помощью Wait функции приведет к таймауту ожидания или вечному ожиданию.
