Версия для печати темы Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Системное программирование и WinAPI > PlugThisAPI )) или Окна в ДЛЛ

Автор: MoZy 15.7.2006, 18:45

Суть моего вопроса (подробно): Допустим у меня реализован так сказать приложение-провайдер. В том смысле, что оно должно осуществлять роль посредника между сервером и плагинами, которые подключаются к этому самому приложению. Плагины будут представлять собой сетевые игрушки и другие фенечки. Сами по себе они будут лишь передавать и получать данные от моего "провайдера". С этим проблем нет. Ну вобщем это все не важно. Важно то что я не могу реализовать обыкновенную WinMain ну и Proc'едуру главную. Вобшем ДЛЛка моя не хочет быть ни чем, кроме библиотеки. Так как все-таки окошки, процедуры и другие подобные вещи сделать в ДЛЛ? вобщем я в растерянности... помогите.

Автор: 586 15.7.2006, 19:12

Цитата(MoZy @  15.7.2006,  19:45 ) Так как все-таки окошки, процедуры и другие подобные вещи сделать в ДЛЛ? Также, как и в exe.

Автор: MoZy 15.7.2006, 20:05

586,  во-первых, я пишу в Dev-C++. Там варианты проектов Win32 DLL, Win32 GUI, ... . Если ставить ГУИ и откомпилить, то все окошки создаются и все нормально. НО создается ЕХЕшник. Но это не самое страшное, а страшно то, что при вызове етого ехешника как библиотеки, он и работает как библиотека и окна не создаются (то есть только функции и работают). А если компилить просто как ДЛЛ - окошек ни там ни тут не видно. Может есть какие-то особые штуки, которые надо сделать, чтобы все было хорошо?  например, если  Цитата Также, как и в exe.  то куда девать АППЕНТРИ? даю кусок кода. хедер с экспортными функциями приводить не буду - нет необходимости. Код #include <windows.h> #include "zone.h" BOOL APIENTRY DllMain (HINSTANCE hInst     /* Library instance handle. */ ,                        DWORD reason        /* Reason this function is being called. */ ,                        LPVOID reserved     /* Not used. */ ) {     switch (reason)     {       case DLL_PROCESS_ATTACH:             hLibInst=hInst;                      break;       case DLL_PROCESS_DETACH:         break;       case DLL_THREAD_ATTACH:         break;       case DLL_THREAD_DETACH:         break;     }     /* Returns TRUE on success, FALSE on failure */     return TRUE; } /*  Declare Windows procedure  */ LRESULT CALLBACK WindowProcedure (HWND, UINT, WPARAM, LPARAM); /*  Make the class name into a global variable  */ char szMainWndClass[] = "WindowOne"; HINSTANCE g_Inst,rInst,hPlugin; HWND hwndMain; int WINAPI WinMain (HINSTANCE hInst,HINSTANCE hPrevInstance,LPSTR lpszArgument,int nFunsterStil) { g_Inst=hInst; MSG nMsg; WNDCLASSEX wincl; /* The Window structure */ wincl.hInstance = hInst; wincl.lpszClassName = szMainWndClass; wincl.lpfnWndProc = WindowProcedure;      /* This function is called by windows */ wincl.style = CS_HREDRAW | CS_VREDRAW;  // Catch double-clicks CS_SAVEBITS| wincl.cbSize = sizeof (WNDCLASSEX); /* Use default icon and mouse-pointer */ wincl.hIcon = LoadIcon (NULL, IDI_APPLICATION); wincl.hIconSm = LoadIcon (NULL, IDI_APPLICATION); wincl.hCursor = LoadCursor (NULL, IDC_ARROW); wincl.lpszMenuName = NULL; wincl.cbClsExtra = 0; wincl.cbWndExtra = 0; wincl.hbrBackground = (HBRUSH) BLACK_PEN; /* Register the window class, and if it fails quit the program */ if (!RegisterClassEx (&wincl)) return 0; /* The class is registered, let's create the program*/ hwndMain = CreateWindowEx (     0,     szMainWndClass,/* Class name */     "",     WS_OVERLAPPEDWINDOW,     200,     300,     300,     300,     HostWnd,/* No parent window */     NULL,/* No menu */     hInst,/* This program instance */     NULL/* Creation parameters */ ); ShowWindow (hwndMain, SW_SHOW); //************MSG************* while (GetMessage (&nMsg, NULL, 0, 0)) {     /* Translate virtual-key messages into character messages */     TranslateMessage(&nMsg);     /* Send message to WindowProcedure */     DispatchMessage(&nMsg); } /* The program return-value is 0 - The value that PostQuitMessage() gave */ return nMsg.wParam; } LRESULT CALLBACK WindowProcedure (HWND hwnd, UINT nMsg, WPARAM wParam, LPARAM lParam) { switch (nMsg) { case WM_CREATE: return 0; case WM_DESTROY:     PostQuitMessage (0); break;          default:     return DefWindowProc (hwnd, nMsg, wParam, lParam); } return 0; }

Автор: 586 15.7.2006, 20:22

Не понял. У тебя exe-шник в роли exe-шника и библиотеки сразу? Или WinMain экспортируется. Или тут слеплен код exe и dll?????

Автор: MoZy 15.7.2006, 20:39

586,    смотря как компилить. Вобщем я бы хотел ДЛЛку, которая была бы обыкновенной ехе, но со связью с "мамой", которая ее  и подгружает. Связь я эту вижу лишь в экспортируемых функциях. Если не трудно, то подскажите структуру и основные моменты ))  ой. неужели надо просто WinMain экспортировать и запустить из "мамы"? А процедуры не надо?

Автор: Pilligrim 15.7.2006, 20:47

Глянул я твой кусок кода,  и не пойму как у тебя используется DllMain. К-а-к?

Автор: 586 15.7.2006, 20:48

У тебя exe-шник который ты загружаешь, как dll, функцией LoadLibrary. WinMain у тебя исполняться не будет, а DllMain воспринимается, как обычная функция, и не исполняется.  Вообще, у DLL ф-ция DllMain - это точка входа. У твоего exe точка входа - WinMain. А у исполняемого файла две точки входа быть не может! Поэтому exe просто загружается.

Автор: MoZy 15.7.2006, 20:54

586,  ну я компилю как DLL проект и получается DLL. Функции экспортируются нормально... Так что мне сделать? Экспортировать WinMain и отказаться от DLLMain?

Автор: 586 15.7.2006, 20:58

Если у тебя exe - откажись от DllMain. Если у тебя dll - откажись от WinMain. Цитата Так что мне сделать? Экспортировать WinMain и отказаться от DLLMain? Хочешь запускать модуль отдельно - exe.

Автор: MoZy 15.7.2006, 21:07

586,  Я хочу, чтобы была связь между модулем и хостом. От WinMain'а отказаться не могу. Нельзя ли сделат ехе, но с расширением ДЛЛ? Кстати, с импортом функций проблем не будет? Добавлено @ 21:10  УРААА!!! Я отказался от DLLMain (я его раньше вообще не использовал, просто подумал, что может понадобиться при инициализации) и просто экспортировал WinMain и вызвал в хосте. И теперь у меня в ДЛЛке окошко есть!

Автор: 586 15.7.2006, 21:21

Цитата(MoZy @  15.7.2006,  22:07 ) Нельзя ли сделат ехе, но с расширением ДЛЛ? Можно, но какой смысл в WinMain. Цитата(MoZy @  15.7.2006,  22:07 ) Кстати, с импортом функций проблем не будет? Не должно. С экспортом WinMain могут быть проблемы. Я поэксперементировал, и вот что получил: Код #include <windows.h> extern "C" {  __declspec(dllexport) int Function1(char*);  __declspec(dllexport) void Function2();  __declspec(dllexport) void main(){_asm jmp dword ptr WinMain} } int __stdcall WinMain(HINSTANCE, HINSTANCE, char*, int) {     return 0; } int Function1(char* str) {  return MessageBoxA(0, str, 0, 0); } void Function2() {     Beep(0x1FF, 50); } А функцию main вызываешь, как WinMain - c теми же параметрами. Она всего лишь передаёт управление WinMain.

Автор: 586 15.7.2006, 21:39

Цитата(586 @  15.7.2006,  22:21 ) Цитата(MoZy @  15.7.2006,  22:07 ) Кстати, с импортом функций проблем не будет? Не должно. А проблемы оказываются есть. Если в функции WinMain прописать какую-нибудь функцию, она обращается в таблицу импорта exe. Вызываюшего exe, а не самого себя. Происходит ошибка.

Автор: 586 15.7.2006, 22:13

Попробовал вот что: Код #include <windows.h> #pragma comment (linker, "/DLL") #pragma comment (linker, "/base:0x1000000") extern "C" {  __declspec(dllexport) int Function1(char*);  __declspec(dllexport) void Function2();  __declspec(dllexport) void main(HINSTANCE p1, HINSTANCE p2, LPSTR p3, int p4){WinMain(p1, p2, p3, p4);}; } int __stdcall WinMain(HINSTANCE, HINSTANCE, char*, int) {     MessageBoxA(0, "Hello world", 0, 64);     return 0; } int Function1(char* str) {  return MessageBoxA(0, str, 0, 0); } void Function2() {     Beep(0x1FF, 50); } Работает хорошо, но exe-шник сам запускаться не хочет. Делай DLL!!!

Автор: MoZy 16.7.2006, 18:15

Спасибо, 586. Я все именно так и сделал. Но у меня возникли проблемы (в том числе и с пониманием сути вещей): 1. Если где-либо (хоть в WinProc, хоть в WinMain хоста) прописать что-либо (Beep или MessageBox) после вызова функции ModuleWinMain (или main как в твоем примере, 586), то это самое после сработает после того, как отдестроится окошко модуля. В чем прикол? 2. Если в хосте прописать FreeLibrary(Module_hInst), без предварительной команды модулю закрыть себя, то вылазит ошибка. Вопрос: это нормально? 3. Если же отдестроить окно хоста (то есть PostQuitMessage(0)) не делая выше сказанное, то: а) модуль продолжит свою работу; б) каким-то чудом хост будет попрежнему принимать сообщения от модуля и реагировать на них* *В модуле я по таймеру шлю сообщение хосту, а тот на это сообщение реагирует звуковым сигналом. Растолкуйте, пожалуйста, всю эту муть.

Автор: 586 16.7.2006, 19:58

Цитата(MoZy @  16.7.2006,  19:15 ) 1. Если где-либо (хоть в WinProc, хоть в WinMain хоста) прописать что-либо (Beep или MessageBox) после вызова функции ModuleWinMain (или main как в твоем примере, 586), то это самое после сработает после того, как отдестроится окошко модуля. В чем прикол? В том, что код застревает в цикле обработки сообщений GetMessage. Так и должно быть. Цитата(MoZy @  16.7.2006,  19:15 ) Если в хосте прописать FreeLibrary(Module_hInst), без предварительной команды модулю закрыть себя, то вылазит ошибка. Вопрос: это нормально? Нормально. Вында обращается к функции WindowProc, а она находится в выгруженном exe. Происходит ошибка 0xC0000005. Цитата(MoZy @  16.7.2006,  19:15 ) 3. Если же отдестроить окно хоста (то есть PostQuitMessage(0)) не делая выше сказанное, то: а) модуль продолжит свою работу; б) каким-то чудом хост будет попрежнему принимать сообщения от модуля и реагировать на них* Тестил в диалоге. Когда главное окно закрываю, окно exe продолжает работать. Если в диалоге прописать PostQuitMessage(0) и закрыть, окно exe тоже закроется. Но это в диалоге. В окне не знаю.

Автор: MoZy 16.7.2006, 20:11

586, спасибо, что растолковал ))

Автор: 586 16.7.2006, 20:21

Кстати, в винде есть такая прога - rundll32. Она запускает процедуры в библиотеках.  rundll32.exe shell32.dll,ShellAboutA Таким образом можно запустить DLL, "без приложения". Может пригодится...

Автор: MoZy 17.7.2006, 22:45

Теперь еще смешнее. При первой загрузке-выгрузке модуля все функции импортируются и выполняются нормально. Но при повторной загрузке выполняются все функции кроме ModuleWinMain. Проскакивает и окошек не делается. Вот такая проблема. И еще: если загрузить модуль, а потом его копию (то есть имя файла другое, а контент тот же), то вылазит ошибка 0хС000000000000005 Вот никогда бы не подумал, что будут такие проблемы...

Автор: 586 17.7.2006, 22:50

Цитата(MoZy @  17.7.2006,  23:45 ) И еще: если загрузить модуль, а потом его копию (то есть имя файла другое, а контент тот же), то вылазит ошибка 0хС000000000000005 Вот никогда бы не подумал, что будут такие проблемы...   Переходи на DLL!!!!!!!!! У exe проблемы с импортом! Для этого изобрели DLL. Вообще, зачем тебе функция WinMain? Хендл модуля ты знаешь, как и без него получить.

Автор: MoZy 20.7.2006, 18:39

Цитата Переходи на DLL!!!!!!!!! Что ты этим сказать хотел? Я и так гружу длл. просто в нем есть WinMain. 586, WinMain мне для того, чтобы окно в длл было (впринципе функцию хоть как назвать можно - от этого ниче не меняется). Поясню свою задачу: Мне необходимо из ехе загружать много разных длл, в которых свои маленькие программки. Нужно, чтобы нельзя    было запускать их без моего ехе (так как работать без него они не смогут). Эти длл содержат и экспортируемые функции и свои окошки - если мелко сказать. А если нормально, то это целые проекты (в будущем, разумеется). Почему я не сделаю все наооборот? Почему в эти проекты не засуну длл моего ехе? Потому что я хочу, чтобы из одного моего ехе были доступны все эти проекты. Потому что так удобно и целостно. Но вот эта проблема с импортом... Нехочет второй раз импортировать мой ехе функцию WinMain модуля. Я ее уже и по другому называл, но ничего. Может еще процедуру обозвать по другому. Я в WinAPI недвано начал писать и с этими процедурами и функциями неполностью разобрался. 586, попробуй из ехе вызвать функцию WinMain (обзови ее по-другому) так, чтобы окно (ну или диалог), которое у тебя в длл, появилось. Потом выгрузи. И повтори операцию. Загрузится опять или нет? И если да, то скинь, плиз, пример длл и ехе. PS и почему никто больше постов не пишет?

Автор: GremlinProg 20.7.2006, 20:27

В принципе понял, в чем суть, и могу порекомендовать экспортировать не WinMain функции, а наборы оконных классов, каждый класс будет описывать твой отдельный модуль, а из exe проекта нужно будет только подгружать твою библиотеку и создавать окно экспортированного класса. За примером долго ходить не надо, сама винда использует этот способ (32-битные версии). Если необходимо несколько окон, создавай несколько, но это уже в процедуре окна. Это еще удобно тем, что проблем с синхронизацией у тебя не будет. Посмотри, например, как реализована библиотека comctl32, которую использует большинство виндовых программ, посмотри, сколько она содержит классов, а каждый класс - это и есть отдельная подпрограмма - как раз то о чем ты и спрашивал. Но в сущности, библиотеки используются не для такой поддержки, как "приложение-провайдер", а просто для того, чтобы уменьшить объем кода в программах, уменьшить время её загрузки и  уменьшить общее, потребляемое количество ресурсов в системе.

Автор: Damarus 20.7.2006, 20:32

Цитата(MoZy @  20.7.2006,  19:39 ) Мне необходимо из ехе загружать много разных длл, в которых свои маленькие программки. Нужно, чтобы нельзя    было запускать их без моего ехе (так как работать без него они не смогут). Так может быть проще запускать дополнительные потоки, в которых и будут работать "маленькие программки"

Автор: MoZy 20.7.2006, 20:47

Damarus, всмысле Thread? Я еще не очень курю.  Как я понял можно экспортить win main модуля, а потом создать для нее поток. Если я правильно понял, спасибо!

Автор: Damarus 20.7.2006, 21:25

Принцип следующий: Dll'ка с первой программой (MoZyDll1.dll): Код #include <windows.h> // Это будет первая "программа" DWORD WINAPI ProgramMain(LPVOID) {     MessageBox(0, L"Программа 1", L"Программа 1", MB_OK);     return 0; } // Эта функция запускает "программу" в новом потоке extern "C" __declspec(dllexport) void RunProgram(void) {     HANDLE hThread = CreateThread(NULL, NULL, &ProgramMain, 0, 0, NULL);     CloseHandle(hThread); } Dll'ка со второй программой (MoZyDll2.dll): Код #include <windows.h> // Это будет вторая "программа" DWORD WINAPI ProgramMain(LPVOID) {     MessageBox(0, L"Программа 2", L"Программа 2", MB_OK);     return 0; } // Эта функция запускает "программу" в новом потоке extern "C" __declspec(dllexport) void RunProgram(void) {     HANDLE hThread = CreateThread(NULL, NULL, &ProgramMain, 0, 0, NULL);     CloseHandle(hThread); } Exe, загружающий Dll'ки: Код #include <windows.h> #include <iostream> typedef void (*_RunProgram)(void); int wmain(int argc, wchar_t *argv[], wchar_t *envp[]) {     HMODULE hDlls[2];     _RunProgram RunProgram[2];     // Загружаем Dll'ки     hDlls[0] = LoadLibrary(L"MoZyDll1.dll");     hDlls[1] = LoadLibrary(L"MoZyDll2.dll");     // Находим функции     RunProgram[0] = (_RunProgram)GetProcAddress(hDlls[0], "RunProgram");     RunProgram[1] = (_RunProgram)GetProcAddress(hDlls[1], "RunProgram");     RunProgram[0](); // Запускаем первую "программу"     RunProgram[1](); // Запускаем вторую "программу"     Sleep(INFINITE);     FreeLibrary(hDlls[0]);     FreeLibrary(hDlls[1]); }

Автор: GremlinProg 20.7.2006, 21:48

Sleep(INFINITE) - весьма оригинально! библиотеки так не выгрузятся, нужно использовать WaitForMultipleObjects для обоих потоков, так что нужно, чтобы RunProgram из длл возвращали хотя бы дескрипторы потоков. Добавлено @ 21:51  но в любом случае нужно придумать еще и защиту: такую библиотеку подгрузит любая программа и вызовет RunProgram, имя будет известно, а в данном случае - и параметры тоже.

Автор: Damarus 20.7.2006, 21:56

Цитата Sleep(INFINITE) - весьма оригинально! библиотеки так не выгрузятся, нужно использовать WaitForMultipleObjects для обоих потоков, так что нужно, чтобы RunProgram из длл возвращали хотя бы дескрипторы потоков. GremlinProg, всё верно, но это просто пример     Добавлено @ 22:59 Цитата но в любом случае нужно придумать еще и защиту: такую библиотеку подгрузит любая программа и вызовет RunProgram, имя будет известно, а в данном случае - и параметры тоже.  Тоже верно, но полная защита не возможна.

Автор: GremlinProg 20.7.2006, 22:20

Damarus, Sleep(INFINITE), WaitForMultipleObjects и т.п. - методы для синхронизации объектов, я как раз про них и говорил. Отлаживать такие приложения(в винде) довольно сложно, потому что они разделены во времени, поэтому и предложил более простой способ. Нужно хорошо знать принципы построения "параллельных" программ, чтобы писать корректный код. Не каждый может таким умением похвастаться. С защитой, конечно, согласен, но если так думать, то можно вообще не защищать софт.

Автор: MoZy 21.7.2006, 17:37

Всем спасибо. Но потоки никак не изменили результат. Разве что их стало больше. Меня впринципе любой вариант устраивает. И импорт WinMain'a, и импорт функции, вызывающей WinMain, и создание потока с импортируемой функцией WinMain, и создание потока с импортируемой функцией, вызывающей WinMain, и импорт функции, создающей поток с WinMain. Но все это не работает так как надо! Почему-то при любой из этих махинаций WinMain второй раз не вызывается    Извинияюся    Вызывается! Я как это проверял: окно не создалось - значит не вызвалась. Оказывается вызывается, только вот окна уже не создает. Щас узнаю в чем дело. И все же странно. Ведь первый раз создаются...  Оказалось функция вылетает при регистрации класса   . Ну правильно, он же остается. Вугружать-то его некому )) Ну вот. Как говорится: "Один дурак задаст столько вопросов, что сто мудрецов не ответят." Думаю тему надо закрыть. Но спешить не буду   . Я ведь только решил первую проблему. Вдруг еще возникнут. Цитата Тоже верно, но полная защита не возможна.  Я уже реализовал протокол между хостом и плагинами, так что незная его плагином не воспользоваться   Один OFF TOPIC: новички могут поднимать репутацию?

Powered by Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)