Что такое код getcodehandle

Что такое код getcodehandle

Всем доброе время суток

Пытаюсь вызвать функцию из своей DLL при помощи GetModuleHandle, а она мне ошибку выдает :(

Подскажите ПЛИЗ что я делаю не так

If NameDll32<>0 then
Begin
@StartingProc:=GetProcAddress(NameDll32,»Starting»);

If Assigned(StartingProc) Then Starting:=StartingProc;

как я понял в блок If прога вообще не входит по причине ошибке возникающей после строчки NameDll32:=GetModuleHandle(«NameDll32.dll»);


> Интересующийся © (11.08.07 12:19)

> If NameDll32<>0 then

Win32Check(NameDll32<>0);

Насчет Win32Check не понял, можно по подробней


> Насчет Win32Check не понял, можно по подробней

Функция в SysUtils — если NameDll32 = 0, то вызовет ф-ю RaiseLastWin32Error, которая возбудит исключение и выдаст сообщение об ошибке. См Ф1 + сусУтилс.пас ;)

> Функция в SysUtils — если NameDll32 = 0, то вызовет ф-ю RaiseLastWin32Error, которая возбудит исключение и выдаст сообщение об ошибке. См Ф1 + сусУтилс.пас ;)

Ну насчет SysUtils это я понял, и насчет для чего она нужна смотрел по F1

Я непонял зачем ее использовать в коде который не вызывает ощибки о которой необходимо предупреждать пользователя

Тот код который я привел брался из стандартного примера вызова функции из Kernel32.dll и работает прекрасно, в моем же случае блок кода If. отказывается работать (как я понимаю по какой-то причине код неможет получить указатель моей DLL)

В настоящее время я подключаю DLL не денамически, но меня такой способ не устраивает, поскольку по условиям согласно которым разрабатывается приложение DLL может отсутствовать

PS
Мне нужно динамически загрузить процедуры и функции из моей DLL в мое приложение. Если у кого есть рабочие примеры ПЛИЗ поделитесь кодом

The GetModuleHandle function returns a module handle for the specified module if the file has been mapped into the address space of the calling process.


> Тот код который я привел брался из стандартного примера
> вызова функции из Kernel32.dll и работает прекрасно, в моем
> же случае блок кода If. отказывается работать (как я понимаю
> по какой-то причине код неможет получить указатель моей
> DLL)

Kernel32.dll присутствует в любом процессе, поэтому пример и работает

> trubin © (11.08.07 16:56) [5]
> trubin © (11.08.07 16:58) [6]

О LoadLibrary я и не подумал :(

Вставил, все ЗАРАБОТАЛО!

За подсказку РЕСПЕКТ :)


> Интересующийся © (11.08.07 16:23) [4]

> Я непонял зачем ее использовать в коде который не вызывает
> ощибки о которой необходимо предупреждать пользователя

Как же не надо предупреждать?
Вот, даже нас не ты предупредил.

Большинство win32 API — функции (в понимании паскаля),
возвращаемый результат которых принято анализировать,
в т.ч. и с использованием GetLastError.

Т.е., если б ты указал хотя бы код ошибки, то выявил проблему
не через 2.5 часа, а минут через 20.

Так что, прошу любить и пользовать Win32Check.

> Leonid Troyanovsky © (12.08.07 09:38) [8]

> Т.е., если б ты указал хотя бы код ошибки, то выявил проблему
> не через 2.5 часа, а минут через 20.

> Так что, прошу любить и пользовать Win32Check

На счет Win32Check ВЫ полностью правы :)
Если сам о LoadLibrary додымал проблема вообще решилась бы за 10 минут, но к сожалению. :(


> Интересующийся © (12.08.07 14:31) [9]

> Если сам о LoadLibrary додымал проблема вообще решилась
> бы за 10 минут, но к сожалению. :(

Соглашусь, что прочтение
http://msdn2.microsoft.com/en-us/library/ms683199.aspx
может лишь насторожить:
The module must have been loaded by the calling process.

Но, Win32Check выскажется, IMHO, гораздо определенней.
Так что, время можно отмерять в секундах.

Получение handle module у DLL-ки.

В MSDN написано:
HMODULE GetModuleHandle( LPCTSTR lpModuleName
// address of module name to return handle for
);
If this parameter (lpModuleName ) is NULL, GetModuleHandle returns a handle of the file used to create the calling process.
——————————————————————
Ну так вот — я внутри DLL добавил функицю внутри которой ввызвается GetModuleHandle таким образом:
void some_func()
<
HMODULE hModule = GetModuleHandle(NULL);
//.

>
А мне GetModuleHandle упорно NULL возврашает, так как же тогда мне
HMODULE у этой DLL получить?

7 ответов

Сегодня эту тему уже разжевали

но я бы делал так:

HANDLE hInst;
BOOL APIENTRY DllMain( HANDLE hModule,DWORD ul_reason_for_call, LPVOID lpReserved)
<
if(ul_reason_for_call == DLL_PROCESS_ATTACH)
<
hInst = hModule;
>

одна и таже фигня.
—————————————————
вообщем в отладке уже позырил как hModule меняется:

когда объявляю hModule = NULL;, тогда ессесно значение 0x00000000
если hModule получать во входяшей фунции — т. е. BOOL APIENTRY DllMain( HANDLE hModule, //. ) брать значение из переданного аргумента,
то тогда hModule изменяется на заначение 0x01000000
Если получать с помощью GetModuleHandle то 0x00400000
——————————————————————
Главный облом в том, что я это значение получаю, чтобы передать
как аргумен в функцию GetModuleFileName
Поэтому делаю так:
if(hModule!=NULL) GetModuleFileName(. );
else MessageBox(. );
И каким бы не было значение hModule всегда вылетает мессаге бокс.
—————————————————-
Я уже даже пробовал без проверки сразу GetModuleFileName вызывать,
но тогда эта функция срабатывает не коректно.

В одном из спп файлов длл (не в функции, а именно в области видимости файла)

char _x[4]; // объявить в функции не получится, стек пренадлижит главному модулю, а не длл.

Потом в функции длл, в том же файле

.
HMODULE CurrHandle;
char FileName[0x200];

if(!GetModuleFileName(CurrHandle, FileName, 0x200))
<
Cons->Write(«Error while retreiving module name, err: %d», GetLastError());
return 1;
>

Илон Маск рекомендует:  Старый способ запроса аргументов (не рекомендуется)

[QUOTE=bave]
Ну так вот — я внутри DLL добавил функицю внутри которой ввызвается GetModuleHandle таким образом:
void some_func()
<
HMODULE hModule = GetModuleHandle(NULL);
//.

>
А мне GetModuleHandle упорно NULL возврашает, так как же тогда мне
HMODULE у этой DLL получить?[/QUOTE]

А мне на в2к3 упорно возвращался модуль ехе при таком способе :)

[QUOTE=Alexandoros]А мне на в2к3 упорно возвращался модуль ехе при таком способе :)[/QUOTE]

Вам ребята совсем плохо, да? Может хоть кто-нибудь заглянет в МСДН и увидит там ЧТО ОЗНАЧАЕТ ЕДИНСТВЕННЫЙ ПАРАМЕТР GetModuleHandle()?

Перелайте туда ИМЯ ВАШЕЙ ДЛЛ-КИ И ПОЛУЧИТЕ ЕЁ ХЭНДЛ МОДУЛЯ! Если вы травите туда NULL — она возвращает ТОТ МОДУЛЬ КОТОРЫЙ ЕЁ ВЫЗВАЛ! ТО ЕСТЬ ЕКЗЕШКУ! А вот ежели вы ей имя модуля СВОЕГО скормите — его и получите. GetModuleHandle(«mydll.dll»); Ясно?

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

[QUOTE=Ireul]Перелайте туда ИМЯ ВАШЕЙ ДЛЛ-КИ И ПОЛУЧИТЕ ЕЁ ХЭНДЛ МОДУЛЯ! Если вы травите туда NULL — она возвращает ТОТ МОДУЛЬ КОТОРЫЙ ЕЁ ВЫЗВАЛ! ТО ЕСТЬ ЕКЗЕШКУ! А вот ежели вы ей имя модуля СВОЕГО скормите — его и получите. GetModuleHandle(«mydll.dll»); Ясно?
[/QUOTE]

Слушай, полудурок, научись читать.

[QUOTE=bave]
чтобы передать как аргумен в функцию GetModuleFileName
[/QUOTE]

Если твой скудный мозг не знает назначение этой ф-ции, то хоть сиди и молчи, а не высовывайся с тупыми каментами.

[QUOTE=Ireul]
Если уж вы не знаете как имя текущего модуля получить, и найти сами не сможете — WinAPI не для вас
[/QUOTE]

Вот еще расскажи нам про откровения в последней инстанции от Ireul.

В чем причина написания пользовательской функции GetModuleHandle?

Я смотрел на вредоносное ПО ZeuS и наткнулся на этот кусок исходный код :

Логика заключается в следующем:

  1. Читать fs сегментный регистр (32-битные Windows хранят TEB там)
  2. Получить указатель на PEB
  3. Получить указатель на PEB_LDR_DATA (содержит информацию о загруженных модулях процесса)
  4. Итерация по InMemoryOrder список
  5. Сравните имя модуля с «kernel32.dll» используя собственную хэш-функцию доморощенного

Почему не было использования GetModuleHandle уместно там?

Решение

Фрагмент кода пытается получить дескриптор модуля (то есть базовый адрес) kernel32.dll, предположительно потому что у него еще нет дескриптора к этому модулю. GetModuleHandle экспортируется из kernel32.dll. Вы не можете вызвать функцию, если не знаете ее адрес.

GetModuleHandleA function

Retrieves a module handle for the specified module. The module must have been loaded by the calling process.

To avoid the race conditions described in the Remarks section, use the GetModuleHandleEx function.

Syntax

Parameters

The name of the loaded module (either a .dll or .exe file). If the file name extension is omitted, the default library extension .dll is appended. The file name string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. When specifying a path, be sure to use backslashes (), not forward slashes (/). The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process.

If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).

The GetModuleHandle function does not retrieve handles for modules that were loaded using the LOAD_LIBRARY_AS_DATAFILE flag. For more information, see LoadLibraryEx.

Return Value

If the function succeeds, the return value is a handle to the specified module.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

Remarks

The returned handle is not global or inheritable. It cannot be duplicated or used by another process.

If lpModuleName does not include a path and there is more than one loaded module with the same base name and extension, you cannot predict which module handle will be returned. To work around this problem, you could specify a path, use side-by-side assemblies, or use GetModuleHandleEx to specify a memory location rather than a DLL name.

The GetModuleHandle function returns a handle to a mapped module without incrementing its reference count. However, if this handle is passed to the FreeLibrary function, the reference count of the mapped module will be decremented. Therefore, do not pass a handle returned by GetModuleHandle to the FreeLibrary function. Doing so can cause a DLL module to be unmapped prematurely.

This function must be used carefully in a multithreaded application. There is no guarantee that the module handle remains valid between the time this function returns the handle and the time it is used. For example, suppose that a thread retrieves a module handle, but before it uses the handle, a second thread frees the module. If the system loads another module, it could reuse the module handle that was recently freed. Therefore, the first thread would have a handle to a different module than the one intended.

Что такое код getcodehandle

Retrieves a module handle for the specified module. The module must have been loaded by the calling process.

To avoid the race conditions described in the Remarks section, use the GetModuleHandleEx function.

Syntax

Parameters

The name of the loaded module (either a .dll or .exe file). If the file name extension is omitted, the default library extension .dll is appended. The file name string can include a trailing point character (.) to indicate that the module name has no extension. The string does not have to specify a path. When specifying a path, be sure to use backslashes (\), not forward slashes (/). The name is compared (case independently) to the names of modules currently mapped into the address space of the calling process.

Илон Маск рекомендует:  Что такое код ccvs_auth

If this parameter is NULL, GetModuleHandle returns a handle to the file used to create the calling process (.exe file).

The GetModuleHandle function does not retrieve handles for modules that were loaded using the LOAD_LIBRARY_AS_DATAFILE flag. For more information, see LoadLibraryEx.

Return value

If the function succeeds, the return value is a handle to the specified module.

If the function fails, the return value is NULL. To get extended error information, call GetLastError.

Remarks

The returned handle is not global or inheritable. It cannot be duplicated or used by another process.

If lpModuleName does not include a path and there is more than one loaded module with the same base name and extension, you cannot predict which module handle will be returned. To work around this problem, you could specify a path, use side-by-side assemblies, or use GetModuleHandleEx to specify a memory location rather than a DLL name.

The GetModuleHandle function returns a handle to a mapped module without incrementing its reference count. However, if this handle is passed to the FreeLibrary function, the reference count of the mapped module will be decremented. Therefore, do not pass a handle returned by GetModuleHandle to the FreeLibrary function. Doing so can cause a DLL module to be unmapped prematurely.

This function must be used carefully in a multithreaded application. There is no guarantee that the module handle remains valid between the time this function returns the handle and the time it is used. For example, suppose that a thread retrieves a module handle, but before it uses the handle, a second thread frees the module. If the system loads another module, it could reuse the module handle that was recently freed. Therefore, the first thread would have a handle to a different module than the one intended.

Examples

For an example, see Using Brushes.

Requirements

Minimum supported client

Windows XP [desktop apps only]

Minimum supported server

Windows Server 2003 [desktop apps only]

Winbase.h (include Windows.h) Kernel32.lib Kernel32.dll

Unicode and ANSI names

GetModuleHandleW (Unicode) and GetModuleHandleA (ANSI)

Что GetModuleHandle () делать в этом коде?

извините сэр, я имел в виду этот кусок кода из статьи Стивена Toub .. В

Может кто-нибудь объяснить мне в общем . ??

Короче говоря, этот код инициализирует ключ регистратор. Принятый в Parmeter, Proc, является функцией обратного вызова, которая будет вызываться при каждом нажатии клавиши.

Используя оператор только обеспечивает непосредственные вызовы Dispose () на объявленных переменных (curProcess и curModule), когда они покидают сферу, тем самым надлежащим образом высвобождая ресурсы в целесообразном порядке, не дожидаясь сборки мусора, чтобы освободить их, которые могут занять некоторое время.

SetWindowsHookEx это вызов апи win32, что позволяет зарегистрировать функцию обратного вызова, которая вызывается при возникновении определенного события уровня ОС. В этом случае первый параметр, WH_KEYBOARD_LL, указывает, что вы хотите зарегистрировать для событий низкого уровня клавиатуры. Второй параметр является обратным вызовом (делегат в .NET), который будет называться. Третий параметр представляет собой окна ручка (указатель управляется ОС) к модулю, где обратный вызов находится, в этом случае основной EXE-файл для процесса. Обратите внимание, что процесс имеет несколько модулей (EXE-й или DLL), загруженных в любой момент времени. Последний параметр является идентификатор потока, который вы хотели бы контролировать; потому что 0 передается в, обратный вызов будет вызываться для любых ключевых событий для любого окна, открытые по ОС.

Во- первых , как общее для вопросов о функциях библиотеки Windows, вы должны рассмотреть поиск MSDN . Вот страница MSDN для GetModuleHandle (), она содержит большую часть необходимой информации.

На Ваш вопрос (и тех, кто более знаком с Windows API, не стесняйтесь, поправьте меня), «модуль» является своего рода всеобъемлющим термином для программы в Windows, как правило, непосредственно относящиеся к любой исполняемый файл (.exe), или библиотека (DLL). А «ручка» является термином, относящимся к указателю. GetModuleHandle () возвращает указатель (дескриптор) для конкретной программы (модуля). Как отметил Павел, как очень широкие термины.

Что касается фрагмента кода вы публикуемый:

Это становится текущим запущенным процесс, а также текущий модуль (очевидного). Затем вызова SetWindowsHookEx (обратитесь к MSDN для получения дополнительной информации), которая принимает в случае с крючком (В этом случае, низкий уровень событий клавиатуры.), процедура для вызова (Proc), когда произойдет событие зацепило, и указатель на текущую программу.

См Крючки на MSDN для получения дополнительной информации о подсекать.

По существу, сообщение этого поста больше использовать в MSDN, это довольно солидный кусок документации :)

GetModuleHandle() является Windows API, который в простом слове возвращает вам дескриптор загруженного DLL или EXE.

Вы можете увидеть подробное описание этого API на этой ссылке

Straight From MSDN:

Функция GetModuleHandle возвращает дескриптор отображенного модуля без увеличения его счетчика ссылок. Поэтому, будьте осторожны при переходе ручки к FreeLibrary функции, так как это может вызвать модуль DLL быть некартированным преждевременно.

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

Простая в использовании обертка над LoadLibrary() и GetProcAddress()

Преамбула

Использование динамически связываемых библиотек (DLL), как известно, предполагает один из двух способов подключения: связывание во время загрузки (load-time linking) и связывание во время выполнения (run-time linking). В последнем случае нужно использовать предоставляемый операционной системой API для загрузки нужного модуля (библиотеки) и поиска в нем адреса необходимой процедуры. Существует множество оберток, но, к сожалению, все встречавшиеся мне сильно усложнены и перегружены лишним кодом. Предлагаемое решение изначально предназначено для вызова функций, хранящихся в DLL из исполняемых модулей (EXE), отличается относительной простотой реализации, и (что гораздо более важно) простотой использования в клиентском коде.

Илон Маск рекомендует:  Программирование сайтов на PHP, MySQL, JS

Решение с использованием чистого Win32 API выглядит примерно так (пратически, это повторение фрагмента из MSDN):

В этой статье предлагается простая в использовании обертка над этими системными вызовами. Пример использования:

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

Реализация

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

Подумаем над тем, как добиться, чтобы разрабатываемый шаблонный класс вел себя как функция в точке вызова и мог поддерживать произвольное количество и тип аргументов. Первое, что приходит на ум — использовать обобщенный функтор. Авторы известных мне реализаций подобных оберток поступают именно так. При этом используется либо частичная специализация шаблона функтора в зависимости от числа аргументов, либо множественная перегрузка оператора вызова функции. Дело, как правило, не обходится без помощи макросов. К счастью, в C++11 появилась шаблоны с переменным числом аргументов, которые значительно упрощают жизнь:

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

Ниже приводится полный код заголовочного файла «ntprocedure.h».

Пара моментов, которые заметил внимательный читатель — адрес процедуры хранится в переменной m_function и вычисляется один раз, и второй момент — в базовом классе хранится разделяемый указатель на объект класса ntmodule. Нетрудно догадаться, что он хранит информацию о загруженном модуле. Использование shared_ptr позволяет автоматически выгрузить модуль после уничтожения всех объектов-процедур, которые его используют.

Рассмотрим определение класса ntmodule:

Как видно, указатели на все используемые модули хранятся в статическом списке. Этим обеспечивается кеширование. Конструктор класса ntmodule помещает указатель на свой объект в список, а деструктор удаляет его. Полностью прояснит картину определение класса ntprocedure.

В конструкторе ntprocedure_base происходит поиск нужного модуля в статическом списке по его имени. Если такой модуль найден, то вызов module->share() создает разделяемый указатель на основе имеющегося в списке указателя, если же такого модуля еще нет, создается новый объект.

Обратите внимание, что для каждого впервые используемого нами модуля мы вызываем LoadLibrary(), не полагаясь на функцию GetModuleHandle() и уже потом контролируем созданные объекты посредством shared_ptr. Это делает безопасным использование созданной обертки совместно в одном проекте с кодом, использующим непосредственные вызовы LoadLibrary() и FreeLibrary().

На этом все. Ах, да, в коде фигурирует тип resouce_ptr. Это ничто иное, как RAII-обертка над такими типами, как HANDLE, HMODULE и так далее. Для тех, кому интерено, привожу реализацию:

Как работает GetModuleHandle()?

Я читаю , она описывает GetModuleHandle() API, как показано ниже:Как работает GetModuleHandle()?

При вызове этой функции, вы передаете завершается нулем строку, которая определяет имя исполняемого файла или DLL-файла загруженного в адресное пространство вызывающего процесса. Если система находит указанное исполняемое имя или имя DLL, GetModuleHandle возвращает базовый адрес, в который загружается файл исполняемого файла или файла DLL;

Мне интересно , где система ищет имя файла? Когда я загрузил некоторый файл в адресное пространство процесса, есть ли какая-то централизованная таблица для хранения сопоставления всех имен загруженных файлов и их адресов загрузки? Если мы будем искать на основе совпадения строк, будет ли это низкая эффективность?

Что такое код getcodehandle

Итак, мы с Вами все время в разделе MFC пользуемся DLL только это использование скрыто за LIB и H файлами. Но ведь любой DLL можно вызывать и динамически. Вот пример вызова функции Win 32 API для удаления файлов — DeleteFile. Тип приложения Win32 Application.

Первой строкой мы с Вами создаем прототип функции для того, чтобы функция имела тип и была реализована проверка типов при передаче параметров. GetModuleHandle получает указатель на DLL:

Эта функция возврашает указатель на модуль, если он загружен. Но Kernel32.Dll — это системная библиотека Windows и она находится в памяти всегда. Если это не так, то нужно использовать LoadLibrary:

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

Что такое код getcodehandle

Возвращает дескриптор модуля для указанного модуля

#include
_WinAPI_GetModuleHandle ( $sModuleName )

$sModuleName Имя Win32 модуля (.DLL или .EXE файл). Если расширение файла не указано, то по умолчанию добавляется расширение .DLL. Строка имени файла может включать в себя завершающий символ «точка» (.), означающее, что имя модуля не имеет расширения. Строка не должна иметь путь. Имя сравнивается (независимо) с именами модулей в текущий момент сопоставленные в адресном пространстве вызывающего процесса. Если этот параметр равен 0, то функция возвращает дескриптор файла, который создал процесс.
Успех: Возвращает дескриптор указанного модуля
Ошибка: Возвращает 0

Искать GetModuleHandle в библиотеке MSDN

Global $hHook , $hStub_KeyProc , $buffer = «»

$hStub_KeyProc = DllCallbackRegister ( «_KeyProc» , «long» , «int;wparam;lparam» )
$hmod = _WinAPI_GetModuleHandle ( 0 )
$hHook = _WinAPI_SetWindowsHookEx ( $WH_KEYBOARD_LL , DllCallbackGetPtr ( $hStub_KeyProc ), $hmod )

MsgBox ( 4096 , «» , «Click OK, then in notepad type. » & _
@LF & @LF & «Jon» & @LF & «AutoIt» & @LF & @LF & «Press Esc to exit script» )

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL