HMODULE в DLL - WIN API

Подскажите, пожалуйста, как, находясь в DLL, получить HMODULE этой DLL? Проблема в том, что в этой DLL нужно пользовать custom ресурсы, а соответствующие вызовы API FindResource, LoadResource, SizeofResource требуют HMODULE. Если вместо HMODULE пользовать NULL или использовать GetModuleHandle(NULL), то возвращается HMODULE вызывающего DLL процесса, а не самой DLL. Вызывать

GetModuleHandle("Путь")

тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
Так как же поиметь HMODULE DLL, находясь в самой DLL? Или как поиметь custom ресурс, который в этой же DLL?

Здравствуйте Polosaty, Вы писали:

P>Подскажите, пожалуйста, как, находясь в DLL, получить HMODULE этой DLL? Проблема в том, что в этой DLL нужно пользовать custom ресурсы, а соответствующие вызовы API FindResource, LoadResource, SizeofResource требуют HMODULE. Если вместо HMODULE пользовать NULL или использовать GetModuleHandle(NULL), то возвращается HMODULE вызывающего DLL процесса, а не самой DLL. Вызывать
P>

P>GetModuleHandle("Путь")
P>

HINSTANCE hInst;
...
BOOL WINAPI DllMain(HINSTANCE hinstDLL,DWORD fdwReason,LPVOID lpvReserved)
{ 
if (fdwReason == DLL_PROCESS_ATTACH)
  hInst = hinstDll;
}
...
use hInst in program
...

P>GetModuleHandle("Путь")
P>

P>тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
P>Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
P>Так как же поиметь HMODULE DLL, находясь в самой DLL? Или как поиметь custom ресурс, который в этой же DLL?

Специально для таких случаев сделал функцию GetCurrentInstance (по аналогии с GetCurrentThread и GetCurrentProcess). Возвращает HINSTANCE модуля, из которого была вызвана эта функция.

HINSTANCE GetInstanceFromAddress(
    PVOID pEip
    )
{
    _ASSERTE(pEip != NULL);

    MEMORY_BASIC_INFORMATION mem;
    if (VirtualQuery(pEip, &mem, sizeof(mem)))
    {
        _ASSERTE(mem.Type == MEM_IMAGE);
        _ASSERTE(mem.AllocationBase != NULL);
        return (HINSTANCE)mem.AllocationBase;
    }
    return NULL;
}

__declspec(naked) 
HINSTANCE GetCurrentInstance()
{ __asm {
#ifdef _M_IX86
    mov   eax, [esp]
    push  eax
    jmp   GetInstanceFromAddress
#else
#   error This machine type is not supported.
#endif
} }

Здравствуйте Alex Fedotov, Вы писали:

AF>Специально для таких случаев сделал функцию GetCurrentInstance (по аналогии с GetCurrentThread и GetCurrentProcess). Возвращает HINSTANCE модуля, из которого была вызвана эта функция.

AF>

AF>HINSTANCE GetInstanceFromAddress(
AF>    PVOID pEip
AF>    )
AF>{
AF>    _ASSERTE(pEip != NULL);

AF>    MEMORY_BASIC_INFORMATION mem;
AF>    if (VirtualQuery(pEip, &mem, sizeof(mem)))
AF>    {
AF>        _ASSERTE(mem.Type == MEM_IMAGE);
AF>        _ASSERTE(mem.AllocationBase != NULL);
AF>        return (HINSTANCE)mem.AllocationBase;
AF>    }
AF>    return NULL;
AF>}

AF>__declspec(naked) 
AF>HINSTANCE GetCurrentInstance()
AF>{ __asm {
AF>#ifdef _M_IX86
AF>    mov   eax, [esp]
AF>    push  eax
AF>    jmp   GetInstanceFromAddress
AF>#else
AF>#   error This machine type is not supported.
AF>#endif
AF>} }
AF>

Черт, в процессе публикации изчез __stdcall у обеих функций. Добавь, а то падать будет.

Здравствуйте Alex Fedotov, Вы писали:

AF>Здравствуйте Polosaty, Вы писали:

P>>Подскажите, пожалуйста, как, находясь в DLL, получить HMODULE этой DLL? Проблема в том, что в этой DLL нужно пользовать custom ресурсы, а соответствующие вызовы API FindResource, LoadResource, SizeofResource требуют HMODULE. Если вместо HMODULE пользовать NULL или использовать GetModuleHandle(NULL), то возвращается HMODULE вызывающего DLL процесса, а не самой DLL. Вызывать
P>>

P>>GetModuleHandle("Путь")
P>>

P>>тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
P>>Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
P>>Так как же поиметь HMODULE DLL, находясь в самой DLL? Или как поиметь custom ресурс, который в этой же DLL?

AF>Специально для таких случаев сделал функцию GetCurrentInstance (по аналогии с GetCurrentThread и GetCurrentProcess). Возвращает HINSTANCE модуля, из которого была вызвана эта функция.

AF>

AF>HINSTANCE GetInstanceFromAddress(
AF>    PVOID pEip
AF>    )
AF>{
AF>    _ASSERTE(pEip != NULL);

AF>    MEMORY_BASIC_INFORMATION mem;
AF>    if (VirtualQuery(pEip, &mem, sizeof(mem)))
AF>    {
AF>        _ASSERTE(mem.Type == MEM_IMAGE);
AF>        _ASSERTE(mem.AllocationBase != NULL);
AF>        return (HINSTANCE)mem.AllocationBase;
AF>    }
AF>    return NULL;
AF>}

AF>__declspec(naked) 
AF>HINSTANCE GetCurrentInstance()
AF>{ __asm {
AF>#ifdef _M_IX86
AF>    mov   eax, [esp]
AF>    push  eax
AF>    jmp   GetInstanceFromAddress
AF>#else
AF>#   error This machine type is not supported.
AF>#endif
AF>} }
AF>

Сильно !!!

А DllMain чем хуже? Или я не врубился?

Здравствуйте Владимир Гренадеров, Вы писали:

ВГ>А DllMain чем хуже? Или я не врубился?

Ничем не хуже. Наоборот, даже лучше. Однако, иногда (в моей практике — однажды) бывают ситуации, когда на DllMain надеяться нельзя. Например, я делал статическую библиотеку, у которой уже был прописан интерфейс. То есть ни добраться до параметра DllMain, ни добавить параметр в свою функцию я не мог. Пришлось извратиться.

Здравствуйте Владимир Гренадеров, Вы писали:

ВГ>Здравствуйте Alex Fedotov, Вы писали:

AF>>Здравствуйте Polosaty, Вы писали:

P>>>Подскажите, пожалуйста, как, находясь в DLL, получить HMODULE этой DLL? Проблема в том, что в этой DLL нужно пользовать custom ресурсы, а соответствующие вызовы API FindResource, LoadResource, SizeofResource требуют HMODULE. Если вместо HMODULE пользовать NULL или использовать GetModuleHandle(NULL), то возвращается HMODULE вызывающего DLL процесса, а не самой DLL. Вызывать
P>>>

P>>>GetModuleHandle("Путь")
P>>>

P>>>тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
P>>>Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
P>>>Так как же поиметь HMODULE DLL, находясь в самой DLL? Или как поиметь custom ресурс, который в этой же DLL?

ВГ>Сильно !!!

Согласен

ВГ>А DllMain чем хуже? Или я не врубился?

Если посмотреть на 4 строки выше, то там есть одно предложение из самого первого письма с вопросом:

Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.

Ну так получилось, что не могу я в моей ситуации поиметь HMODULE из DLLMain

Здравствуйте Alex Fedotov, Вы писали:

AF>Здравствуйте Alex Fedotov, Вы писали:

AF>>Специально для таких случаев сделал функцию GetCurrentInstance (по аналогии с GetCurrentThread и GetCurrentProcess). Возвращает HINSTANCE модуля, из которого была вызвана эта функция.

AF>>

AF>>HINSTANCE GetInstanceFromAddress(
AF>>    PVOID pEip
AF>>    )
AF>>{
AF>>    _ASSERTE(pEip != NULL);

AF>>    MEMORY_BASIC_INFORMATION mem;
AF>>    if (VirtualQuery(pEip, &mem, sizeof(mem)))
AF>>    {
AF>>        _ASSERTE(mem.Type == MEM_IMAGE);
AF>>        _ASSERTE(mem.AllocationBase != NULL);
AF>>        return (HINSTANCE)mem.AllocationBase;
AF>>    }
AF>>    return NULL;
AF>>}

AF>>__declspec(naked) 
AF>>HINSTANCE GetCurrentInstance()
AF>>{ __asm {
AF>>#ifdef _M_IX86
AF>>    mov   eax, [esp]
AF>>    push  eax
AF>>    jmp   GetInstanceFromAddress
AF>>#else
AF>>#   error This machine type is not supported.
AF>>#endif
AF>>} }
AF>>

AF>Черт, в процессе публикации изчез __stdcall у обеих функций. Добавь, а то падать будет.

Огромное спасибо. Сейчас попробую.

Здравствуйте Polosaty, Вы писали:

ВГ>>А DllMain чем хуже? Или я не врубился?

P>Если посмотреть на 4 строки выше, то там есть одно предложение из самого первого письма с вопросом:
P>

P>Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
P>

P>Ну так получилось, что не могу я в моей ситуации поиметь HMODULE из DLLMain

А-а... Ступил что-то я...

P.S. А все-таки, почему DllMain не пашет (вдруг и уменя такое произойдет?), или ты
LoadLibraryEx юзаешь ?

Здравствуйте Владимир Гренадеров, Вы писали:

ВГ>Здравствуйте Polosaty, Вы писали:

ВГ>>>А DllMain чем хуже? Или я не врубился?

P>>Если посмотреть на 4 строки выше, то там есть одно предложение из самого первого письма с вопросом:
P>>

P>>Использовать HMODULE, который передается в DLLMain, в моем случае тоже не получается.
P>>

P>>Ну так получилось, что не могу я в моей ситуации поиметь HMODULE из DLLMain

ВГ>А-а... Ступил что-то я...

ВГ>P.S. А все-таки, почему DllMain не пашет (вдруг и уменя такое произойдет?), или ты
ВГ>LoadLibraryEx юзаешь ?

DllMain пашет. Все гораздо хуже. У меня ее нет

Это один из случаев, когда HMODULE получить в DllMain нельзя. Можно было, конечно, определить DllMain, но... "нормальные герои всегда идут в обход"

.
Второй случай, который привел Alex Fedotov — это когда Вы делаете статическую библиотеку, которая будет прилинкована неизвестно к чему, да еще и интерфейсы определены заранее и передача HMODULE ни в один из вызовов этой библиотеки не предусмотрена.
В общем, DllMain работает, только вот до HMODULE иногда не удается добраться.

P>GetModuleHandle("Путь")
P>

P>тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
P>Так как же поиметь HMODULE DLL, находясь в самой DLL?
А почему нельзя? Ведь про каталог ничего не сказано в описании данной функции. Она case independently определяет, загружена ли библиотека с таким именем, без учета пути. По-моему (мне так кажется, и у Рихтера о том вроде написано, хотя не нашел сейчас), что чтоб узнать адрес либы внутри исполняемого модуля, надо знать только имя библиотеки, и не нужно путь к ней. А потом, по HMODULE получается полный путь, откуда она загружена (GetModuleFileName).

Я ошибаюсь?

Здравствуйте Kaa, Вы писали:

Kaa>Здравствуйте Polosaty, Вы писали:

P>>Подскажите, пожалуйста, как, находясь в DLL, получить HMODULE этой DLL? Проблема в том, что в этой DLL нужно пользовать custom ресурсы, а соответствующие вызовы API FindResource, LoadResource, SizeofResource требуют HMODULE. Если вместо HMODULE пользовать NULL или использовать GetModuleHandle(NULL), то возвращается HMODULE вызывающего DLL процесса, а не самой DLL. Вызывать
P>>

P>>GetModuleHandle("Путь")
P>>

P>>тоже нельзя, т.к. положение текущего каталога относительно каталога с DLL неизвестно. Абсолютный путь к DLL заранее тоже не известен.
P>>Так как же поиметь HMODULE DLL, находясь в самой DLL?
Kaa>А почему нельзя? Ведь про каталог ничего не сказано в описании данной функции. Она case independently определяет, загружена ли библиотека с таким именем, без учета пути. По-моему (мне так кажется, и у Рихтера о том вроде написано, хотя не нашел сейчас), что чтоб узнать адрес либы внутри исполняемого модуля, надо знать только имя библиотеки, и не нужно путь к ней. А потом, по HMODULE получается полный путь, откуда она загружена (GetModuleFileName).

Kaa>Я ошибаюсь?

Наверняка сказать, что Вы ошибаетесь, не могу, не знаю точно. Но логика у меня такая.
Представьте себе, что 2 разных приложения запускаются из разных каталогов. Совершенно случайно в составе обоих приложений оказались DLL с одним и тем же именем, и лежат эти DLL каждая в каталоге со своим EXE, т.е. каждая в своем. Если бы ОС было "наплевать" на путь к DLL, то что бы Вам вернул GetModuleHandle, когда обе DLL загружены?

Здравствуйте Polosaty, Вы писали:

P>Здравствуйте Kaa, Вы писали:

Kaa>>А почему нельзя? Ведь про каталог ничего не сказано в описании данной функции. Она case independently определяет, загружена ли библиотека с таким именем, без учета пути. По-моему (мне так кажется, и у Рихтера о том вроде написано, хотя не нашел сейчас), что чтоб узнать адрес либы внутри исполняемого модуля, надо знать только имя библиотеки, и не нужно путь к ней. А потом, по HMODULE получается полный путь, откуда она загружена (GetModuleFileName).

Kaa>>Я ошибаюсь?

P>Наверняка сказать, что Вы ошибаетесь, не могу, не знаю точно. Но логика у меня такая.
P>Представьте себе, что 2 разных приложения запускаются из разных каталогов. Совершенно случайно в составе обоих приложений оказались DLL с одним и тем же именем, и лежат эти DLL каждая в каталоге со своим EXE, т.е. каждая в своем. Если бы ОС было "наплевать" на путь к DLL, то что бы Вам вернул GetModuleHandle, когда обе DLL загружены?

Вот написал такое и сам засомневался и полез в Рихтера. А там на стр. 54 IV издания сказано, что GetModuleHandle проверяет адресное пространство только того процесса, который ее вызвал. Тогда вопрос формулируется по-другому: если приложение загружает несколько разных DLL, которые имеют одинаковое имя, но лежат в разных каталогах, то что вернет GetModuleHandle?
Вообще-то обходиться без имени просто надежнее. Вдруг вздумается когда-нибудь переобозвать DLL, а аргумент функции GetModuleHandle при пересборке поменять забудете... Хотя это, конечно, за уши притянуто.
Кроме того, в Рихтере есть еще такое замечание: "если же файл системой не найден, функция возвращает NULL." Непонятно, что стоит за словами "файл системой не найден".
А метод, предложенный Alex Fedotov, работает всегда. И не только для DLL. И, как я понял, не только для исполняемого модуля (впрочем, как и GetModuleHandle). Но что еще выгодно отличает его от GetModuleHandle (если, конечно, я правильно врубился) — можно даже имени файла, спроецированного на адресное пространство процесса, не знать, а его HMODULE Вы получите.

Здравствуйте Polosaty, Вы писали:

P>Наверняка сказать, что Вы ошибаетесь, не могу, не знаю точно. Но логика у меня такая.
P>Представьте себе, что 2 разных приложения запускаются из разных каталогов. Совершенно случайно в составе обоих приложений оказались DLL с одним и тем же именем, и лежат эти DLL каждая в каталоге со своим EXE, т.е. каждая в своем. Если бы ОС было "наплевать" на путь к DLL, то что бы Вам вернул GetModuleHandle, когда обе DLL загружены?

Ну, ОС такое допускает. Вернут будет первый из найденных "инстансов". Адреса загрузки DLL начинаются с 0x10000000. Будет выдан адрес первой найденной DLL. Если уж думать о том, что их может быть более одной, то все плохо. Тогда надо этого либо не допускать, либо проверять на наличие нескольких экземпляров. Но наличие нескольких экземпляров — не пресекается.

Прогони в отладчике такой пример (имена либ измени на свой манер, но чтоб пути разные были

)

# include <windows.h>

int main()
{
  HMODULE hSecond = LoadLibrary( "d:\\ProjectRoot\\bin\\somelib.dll" );
  HMODULE hFirst  = LoadLibrary( "d:\\ProjectRoot\\SE\\bin\\somelib.dll" );

  HMODULE hFound = GetModuleHandle( "metazlib" );
  char szPath[0x1000];

  GetModuleFileName( hFound, szPath, sizeof(szPath) );
  printf( "%s\n", szPath );
  GetModuleFileName( hFirst, szPath, sizeof(szPath) );
  printf( "%s\n", szPath );

  return 0;
}

Как видишь, все четко определяется, но находится первая библиотека, и находится она только по имени, без учета каталога. Так что, в этом случае какраз ОС "наплевать"

С уважением

Kaa>Как видишь, все четко определяется, но находится первая библиотека, и находится она только по имени, без учета каталога. Так что, в этом случае какраз ОС "наплевать"

Да, похоже, что ты прав

. Но после твоего примера становится понятно, что метод от Alex Fedotov надежнее .

Здравствуйте Polosaty, Вы писали:

P>Вообще-то обходиться без имени просто надежнее. Вдруг вздумается когда-нибудь переобозвать DLL, а аргумент функции GetModuleHandle при пересборке поменять забудете... Хотя это, конечно, за уши притянуто.
Это точно. Большинство приложений линкуются со своими библиотеками статически, поэтому случаев на общем фоне не так много. Хотя предположить такое можно, и есть задачи, которые к этому иногда приводят.

P>Кроме того, в Рихтере есть еще такое замечание: "если же файл системой не найден, функция возвращает NULL." Непонятно, что стоит за словами "файл системой не найден".
Это значит, что в адресное пространство процесса файл с таким именем не "замапплен".

P>А метод, предложенный Alex Fedotov, работает всегда. И не только для DLL. И, как я понял, не только для исполняемого модуля (впрочем, как и GetModuleHandle).

Никто не ставит под сомнение метод мэтра. Просто есть стандартное средство проверить, что загружено в адресное пространство процесса, причем совершенно все равно, ккого типа это файл. При умолчании расширения .dll подразумевается, но там может быть все что угодно: от .exe до .txt

С уважением

Здравствуйте Alex Fedotov, Вы писали:

Таки надо FAQ написать по этому делу.

Здравствуйте VladD2, Вы писали:

VD>Таки надо FAQ написать по этому делу.

Ну путь кто-нибудь еще для Alpha и IA64 напишет, тогда можно и FAQ.

Здравствуйте Alex Fedotov, Вы писали:

AF>Здравствуйте VladD2, Вы писали:

VD>>Таки надо FAQ написать по этому делу.

AF>Ну путь кто-нибудь еще для Alpha и IA64 напишет, тогда можно и FAQ.

Ну, для IA64 ты наверное и сам сможешь, а для Alpha-ы уже поздновато.

AF>HINSTANCE GetInstanceFromAddress(
AF>    PVOID pEip
AF>    )
AF>{
AF>    _ASSERTE(pEip != NULL);

AF>    MEMORY_BASIC_INFORMATION mem;
AF>    if (VirtualQuery(pEip, &mem, sizeof(mem)))
AF>    {
AF>        _ASSERTE(mem.Type == MEM_IMAGE);
AF>        _ASSERTE(mem.AllocationBase != NULL);
AF>        return (HINSTANCE)mem.AllocationBase;
AF>    }
AF>    return NULL;
AF>}

AF>__declspec(naked) 
AF>HINSTANCE GetCurrentInstance()
AF>{ __asm {
AF>#ifdef _M_IX86
AF>    mov   eax, [esp]
AF>    push  eax
AF>    jmp   GetInstanceFromAddress
AF>#else
AF>#   error This machine type is not supported.
AF>#endif
AF>} }
AF>

Мне кажется, что во второй функции лучше использовать GetThreadContext. Получится переносимее.

	От:	Polosaty
	Дата:	20.02.02 17:52
	Оценка:

	От:	Владимир Гренадеров
	Дата:	20.02.02 17:57
	Оценка:

	От:	Alex Fedotov
	Дата:	20.02.02 17:58
	Оценка:	115 (10)

	От:	Alex Fedotov
	Дата:	20.02.02 18:02
	Оценка:	9 (1)

	От:	Владимир Гренадеров
	Дата:	20.02.02 18:07
	Оценка:

От:	Kaa	http://blog.meta.ua/users/kaa/
Дата:	21.02.02 17:32
Оценка:

От:	VladD2	www.nemerle.org
Дата:	21.02.02 21:04
Оценка:

	От:	Аноним
	Дата:	24.02.02 17:14
	Оценка: