Как не используя переменную из функции DllEntryPoint получить HINSTANCE текущего модуля.
GetModuleHandle требует имя, а мне бы стандартный прием, типа GetThisHandle.....
При помощи GetModuleHandle(0) можно получить описатель EXE вызвавшей модуль.

По-моему - никак (если имени модуля не знаешь). А чем тебя DllEntryPoint не устраивает? Заведи глобальную переменную и запомни, потом спрашивай.

Добавлено через 1 минуту и 25 секунд
Т.е. DllMain

Earnest, Кхм. Потому что хочется сделать независимый класс, который ничего не экстернит.
Ну раз никак значит никак.)

Ну и не экстернь. Сделай приватную статическую переменную и инициализируй ее в DllMain (соответствующей статической функцией). Так примерно MFC делает.

В принципе никак.
Откуда твоя функция будет это знать? Над адресом возврата чтоли издеваться?

На самом деле это довольно просто сделать. Мой пример нуждается в библиотеке dbghelp.dll.

Ну если такой способ, с учетом всех возможных багов, то почему бы не использовать просто VirtualQuery ^_^

Tectoder, есть много способов получить базовый адрес текущего модуля, коим и является HMODULE (HINSTANCE), тем не менее вы утверждали, что это невозможно сделать. 

Примерно, таким же образом я получал текущий модуль, только использовал разбор секции импорта, в поисках экспортируемого "ключевого символа". Но раз условие таково:

то видимо Pale_Master ближе всех подобрался к решению (хотя не совсем понимаю, зачем неэкспортируемый ничего модуль, разве что для регистрации оконной процедуры виндового класса?).

На сколько я помню, VirtualQuery вернет для того же qwCurAddress базовый адрес исполняемого модуля, а не модуля dll, хотя могу ошибаться, у кого на ходу какая-нибудь библиотека, проверьте плз. мои сомнения

Куда-то всех понесло не туда 



Это сообщение отредактировал(а) W4FhLF - 3.9.2007, 10:55

W4FhLF, Очень красиво.  

Забавно, только упаси вас бог, таким способом искать текущий модуль ))
Сигнатура MZ не уникальна, нет ни какой гарантии, что MZ не втретится, ни в коде, ни в статических данных. К примеру, 0x48r - код команды DEC. Если DEC будет выполняться для регистра BP или EBP, в зависимости от разрядности команды, то код будет 0x4D, т.е. 'M', аналогично и для 'Z'.

есть еще сигнатура PE и OptionalHeader.Magic и такое совпадение маловероятно. Расположение PE-файла в ресурсах по такому выравниванию в ресурсах тоже маловероятно. К тому же в PE заголовке где-то есть флаг, что модуль загружен в память.

Про сигнатуру PE 586 отметил верно, в своих программах я учитывал это. 



А ты видел много программ в которых нативные секций данных и ресурсов располагаются в памяти по адресам младшим относительно адреса секции кода?

Добавлено @ 14:56
И ещё, лучше перестраховаться и сделать hModule = (DWORD)&DllMain & 0xFFFFF000;

Это сообщение отредактировал(а) W4FhLF - 4.9.2007, 17:46

Зря бушуешь, я не говорю, что твой метод не сработает, в конкретных программах - конечно, не спорю, быстро и аккуратно так можно найти базовый адрес модуля, НО. Виртуальный адрес любой секции физически можно переназначить без особых проблем и загрузчик это проглотит, практически все среды позволяют менять, по крайней мере базовые адреса, я уже не говорю о умных следопытах, которые практикуют прямое назначение адресов секций, в таком случае секция кода может располагаться где-угодно, ресурсы, в которых так же может лежать как модуль, так и драйвер, так же можно переносить в любое место. Выравнивание условно и выставляется в основном только ms компиляторами. Если говорить об общем случае, то возьми просто, наугад пару-тройку левых программ и попробуй найти фаром эти сигнатуры.

Вобщем, если нет гарантии, что последовательность уникальна, то не стоит использовать "лобовые" поисковые алгоритмы в своих программах, в основном это временные или частные решения.

Я тут просто еще раз посмотрел на третий пост

Ключевое слово независимый, т.е. независимый от среды внедрения, т.е. работающий везде...

надеюсь, я понятно все изложил