Как не используя переменную из функции 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 компиляторами. Если говорить об общем случае, то возьми просто, наугад пару-тройку левых программ и попробуй найти фаром эти сигнатуры.

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

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

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

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

Извини конечно, но я не понимаю к чему эти многабукофф? Ты же получаешь описатель СВОЕГО модуля, тебе заранее должны быть известны расположение секций. Я не видел ниодного компилятора располагающего секцию кода за секциями данных или ресурсов. 
Хорошо, пусть ты решил извратиться и сделал секцию кода последней, пусть у тебя в ресурсах лежит ещё какой-то PE файл и пусть его адрес совпадает с началом страницы в памяти, тогда возьми InMemoryOrderModuleList в PEB'e и пройдись по нему в цикле или пропусти это срабатывание и всё. 



И что я должен увидеть?



Называть частным решение, которое основано на фундаментальных аспектах архитектуры ОС я бы не решился. 

Это сообщение отредактировал(а) W4FhLF - 5.9.2007, 08:42

Согласен, только если бы вопрос стоял именно так, то я, честно, использовал бы hInstance из DllMain, и не морочил бы ни кому голову. Суть ведь именно в том, что доступ к модулю не должен быть привязан к конкретной архитектуре приложения, на то он и класс, т.е. понятие СВОЙ модуль он в принципе-то и знать не должен. Сможешь найти в примере Pale_Master какую-нибудь такую привязку или неопределенность?

Громко, но я бы наверное именно это и не решился бы написать, по крайней мере не стал бы призывать всех пресвятых, как то старо, и не убедительно.

Ещё разок перечитай, задача состоит в том, чтобы получить СВОЙ описатель. Классу пофиг в пределах какого модуля выполняться, известно лишь одно - код класса выполняется в пределах модуля описатель которого надо получить. В этом состоит задача, не знаю чего ты споришь.



Чего?

Это сообщение отредактировал(а) W4FhLF - 5.9.2007, 14:49

Если исполнительная среда устроена так что код библиотеки генерируется в рантайме(примеры таких сред приводить надо?), адрес какойнибудь функции может оказаться очень сильно отличен от базы dll, вы не находите? Имелось ввиду это. А не то что нельзя определить базу региона обладающего кучей характерных признаков.
Хотя если речь идет о C++ в частности, а не о Win32 вообще, то сказанное тобой конечно вполне разумно.

Это сообщение отредактировал(а) Tectoder - 5.9.2007, 20:09