Определение имени dll-файла

[Qwertiy]

Как без .NET из dll узнать её имя файла? Именно имя файла, не assembly name.

Т. е. нужен нативный аналог этого:

Код: Выделить всё

System::Reflection::Assembly::GetExecutingAssembly()->Location

[Хакер]

Именно имя файла, не assembly name.

Лол. Windows знать не знает, что такое assembly, единственное, что она знает, это module image.

Получить имя файла легко — GetModuleName.

[Qwertiy]

Получить имя файла легко — GetModuleName.

А где хендл модуля взять? Если передавать 0 или GetModuleHandleW(0), то получается exe-файл, а мне надо мой dll. Причём, из загружающей его программы я ничего передать не могу, dll должен сам определить своё имя.

[Хакер]

А где хендл модуля взять?

VB? C/C++? Delphi?

DLL-шке при загрузке передаётся её hModule и DLL-шка должна сохранить у себя это значение, если ей оно в дальнейшем потребуется.

Если это пишется на С/С++, то надо это делать вручную.
Если на VB — всё уже сделано, сохранённое значение можно получить через App.hInstance.
В делфях не знаю как.

Если значение сохранить не судьба в силу каких-то совершенно невероятных причин, то...
Собственно, ответь для себя на вопрос: в адресном пространстве загруженно несколько десятков разных DLL-шек. Имя какой из них нужно получить?

[Qwertiy]

DLL-шке при загрузке передаётся её hModule и DLL-шка должна сохранить у себя это значение, если ей оно в дальнейшем потребуется.

Си++. Сохранил, теперь всё работает. Спасибо

Имя какой из них нужно получить?

Я думал, что выполняющийся код "знает", из какой он взят...

[Хакер]

Я думал, что выполняющийся код "знает", из какой он взят...

То есть ты считал это врожденным свойством x86-машинного кода?

[Qwertiy]

То есть ты считал это врожденным свойством x86-машинного кода?

Я считал это врождённым свойством Windows, точнее, что существует некая функция, делающая примерно то же, что и .NET'овская GetExecutingAssembly.

[Хакер]

А что именно она должна делать? Успешная формулировка ещё задачи, то есть успешная постановка вопроса сразу даст лучший ответ.

[Qwertiy]

А что именно она должна делать?

Определять хендл dll'ки, в которой находится та функция, из которой она вызвана

[Хакер]

Определять хендл dll'ки, в которой находится та функция, из которой она вызвана

Та = функция, а она = кто?

[Qwertiy]

Та = функция, а она = кто?

Ты издеваешься что ли
Я же даже пример показал того, о чём думал. Только хендл вместо сборки.

[Хакер]

Ты издеваешься что ли

Абсолютно нет.

Я же даже пример показал того, о чём думал. Только хендл вместо сборки.

Понятие сборка — такое же дотнетспецифичное, как понятие EpiProject у VB6.
Windows знать не хочет и не оперирует таким понятиями: ни понятием сборка, ни понятием EpiPrject.

Windows оперирует понятием «executable image» или «module».
Теперь ты спрашиваешь: есть некая функция и есть некий модуль. Нужно, чтобы эта функция получила имя этого модуля.
Решить эту задачу никак нельзя, пока ты со всей строгостью не скажешь, какая связь между этой функцией и этим модулем присутствует. Ведь функций может быть сто тысяч, и модулей может быть сотня. Имя какого из ста модулей должна возвращать каждая из ста тысяч функций. Очевидно же, что не любого, а какого-то определённого спецификой задачи.

Вот ты должен с математической строгостью определить взаимосвязь. Я то знаю, какую примерно взаимосвязь ты хочешь. Но важно, чтобы именно ты высказал. Потому что сразу увидишь проблемы, которые сейчас не видишь. Концептуальные.

[Qwertiy]

какая связь между этой функцией и этим модулем присутствует

Между вызывающей функцией и модулем - она в нём находится.
Между вызываемой функцией и модулем - никакой.
Возможная проблема - вызываемая функция не имеет непосредственной связи с модулем. Возможное решение - использование адреса возврата из стека.
Других проблем пока не вижу.

К тому же, передав 0, я получаю exe'шник. Не вижу концептуальных проблем, что мешает получить dll'ку примерно таким же образом.

[VBTerminator]

а она = кто?

Как я понял, когда выполнение передаётся в какую-то функцию его библиотеки, этой функции надо узнать имя файла, в котором она была объявлена.

[Qwertiy]

Как я понял, когда выполнение передаётся в какую-то функцию его библиотеки, этой функции надо узнать имя файла, в котором она была объявлена.

Было надо Это уже сделано и работает.
Теперь тут обсуждается, почему нельзя получить хендл этой библиотеки вызовом какой-нибудь winapi-функции, а надо его сохранять сразу

[Хакер]

Между вызывающей функцией и модулем - она в нём находится.

Между вызываемой функцией и модулем - никакой.[/quote]

Речь идёт о твоей функции или о гипотетической системной? Системная, насколько я помню, такая тоже была, правда из PSAPI или ImageHelp (непомню, откуда и как называлась).

Вот видишь, теперь уже всё стало ясно (не на уровне догадок, а на уровне изложенного факта).


Если ты хочешь написать сам функцию, которая определяет имя модуля, которым принадлежат её инструкции. То это просто. Инструкция может получить свой собственный адрес? Может. Теперь уже по адресу инструкции нужно получить адрес модуля. Это можно сделать двумя путями. Округлить адрес вниз на 64k и проверить, является ли это началом модуля (если нет, отнимать 64k до тех пор, пока это не будет началом). Второй способ заключается в том, чтобы перечислить все модули и смотреть, какому принадлежит полученный адрес.

Если ты хочешь написать сам функцию, которая определяет имя модуля, которому принадлежит вызывающая сторона, то ты сам уже сказал:

Возможное решение - использование адреса возврата из стека.

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

Если какой-то код хочет получить имя модуля, значит он должен знать хендл модуля. И хендл модуля он должен получить от системы тогда, когда она загружает модуль. В противном случае, может быть код вообще живёт НЕ в модуле. Для ситуации, когда код есть, а модуля нет, система должна быть спроектирована так, что в такой ситуации и получить имя/хендл модуля нельзя. Система спроектированна так. Блестящее решение.

[Qwertiy]

Вот видишь, теперь уже всё стало ясно (не на уровне догадок, а на уровне изложенного факта).

А что из этого было не ясно раньше?

То она во-первых насколько я помню есть.

Для ситуации, когда код есть, а модуля нет, система должна быть спроектирована так, что в такой ситуации и получить имя/хендл модуля нельзя. Система спроектированна так.

Ну представим такую ситуацию. Присваивание выполнено не будет, поэтому в переменной будет лежать 0. Что тут хорошего?

[Хакер]

А что из этого было не ясно раньше?

Да есть тысяча вариантов.
Вызываемый код должен определять модуль, которому он сам принадлежит.
Вызываемый код должен определять модуль, которому принадлежит вызывающий код.
В первом случае, если речь идёт о дотнете, то известно, что дотнет конвертирует MSIL в Native-код, и очевидно, что Native-код уже не будет лежать в пределах какого-либо из модулей.
Во-втором случае вызывающий код так же может не принадлежать какому-либо из модулей.
При использовании стека для выяснения деталей возникает целая цепочка из потенциально нужных тебе модулей.

Проблема в том, что когда говорят «код должен определить текущую библиотеку», то остаются незафиксированные вариации. А когда говорят, код должен установить модуль, которому он сам (код, инструкции) принадлежат — это совсем другое.

Присваивание выполнено не будет, поэтому в переменной будет лежать 0. Что тут хорошего?

Какой-то совершенно не состоятельный довод. Про любую программу можно сказать: а что если какого-то присваивания в ней вдруг не состоится. Ой-ой, тогда всё пойдёт не так, как должно.

[Qwertiy]

Какой-то совершенно не состоятельный довод. Про любую программу можно сказать: а что если какого-то присваивания в ней вдруг не состоится. Ой-ой, тогда всё пойдёт не так, как должно.

Это тут при чём?

сли какой-то код хочет получить имя модуля, значит он должен знать хендл модуля. И хендл модуля он должен получить от системы тогда, когда она загружает модуль. В противном случае, может быть код вообще живёт НЕ в модуле. Для ситуации, когда код есть, а модуля нет, система должна быть спроектирована так, что в такой ситуации и получить имя/хендл модуля нельзя. Система спроектированна так. Блестящее решение.

Если код не в модуле, то DllMain не вызывается, хендл модуля не присваивается и остаётся 0. Или я неправильно представляю эту ситуацию?

[Хакер]

Если код не в модуле, то DllMain не вызывается, хендл модуля не присваивается и остаётся 0. Или я неправильно представляю эту ситуацию?

Если код не в модуле, то DllMain не существует, хендл не передаётся, присваивания нет, и самой переменной нет. Как и бесконечного множества других гипотетических сущностей, которых в мире не существует. В чём смысл о них думать, коли они не существуют?

[Qwertiy]

Если код не в модуле, то DllMain не существует, хендл не передаётся, присваивания нет, и самой переменной нет. Как и бесконечного множества других гипотетических сущностей, которых в мире не существует. В чём смысл о них думать, коли они не существуют?

А теперь ты меня запутываешь. Следующая ситуация возможна: сторонняя программа загружает образ dll'ки в память, сам файл на диске не существует. DllMain не вызывается, но переменная существует и в ней лежит 0? Если нет, то я не понимаю, как тот факт, что модуль может не существовать, связан со всем остальным в этой теме.

[Хакер]

возможна: сторонняя программа загружает образ dll'ки в память, сам файл на диске не существует

Такая ситуация невозможна. Нельзя спроецировать в файл образ, которого нет на диске.

Если нет, то я не понимаю, как тот факт, что модуль может не существовать, связан со всем остальным в этой теме.

Я тоже не понимаю. Ты спросил, почему они сделали так, а не иначе. Я ответил: то, как они сделали — пример хорошей инженерии, а то, как ты предлагаешь — пример плохой.

[Qwertiy]

возможна: сторонняя программа загружает образ dll'ки в память, сам файл на диске не существует

Такая ситуация невозможна. Нельзя спроецировать в файл образ, которого нет на диске.

В смысле в память?

Я тоже не понимаю. Ты спросил, почему они сделали так, а не иначе. Я ответил: то, как они сделали — пример хорошей инженерии, а то, как ты предлагаешь — пример плохой.

Вот так - понятно

[Хакер]

В смысле в память?

Да, описка.

[VBTerminator]

Если код не в модуле, то DllMain не существует, хендл не передаётся

А как тогда вызывать функции, ожидающие на входе хендл DLL?

[Хакер]

функции, ожидающие на входе хендл DLL?

Что означает «функции, ожидающие хендл DLL»?

[VBTerminator]

функции, ожидающие хендл DLL

Я про функции, принимающие одним из аргументов значение hinstDLL, которое как раз и неизвестно из-за отсутствия DllMain.

[Хакер]

Если функция что-то делает с DLL, а самой DLL, с которой хочется что-то сделать, нет, то в чём смысл подобной ситуации?