Ссылка на Windows API PatchAPI

Я бы хотел использовать Windows API's PatchAPI, чтобы применить некоторые исправления. Применение патчей реализовано в файле mspatcha.dll, который должен находиться в папке system32.Ссылка на Windows API PatchAPI

После прочтения в различных местах, таких как их ref и googling, мне еще предстоит найти правильный путь для ссылки на эту DLL. Я хотел бы связать статически, имея дело с LoadLibrary, кажется беспорядочным и своего рода поражением цель их заголовок patchapi.h. Так как я не нашел файл .lib я подключиться, я создал свой собственный, используя следующие команды:

1) Dumpbin/экспорт C: \ Windows \ system32 \ mspatcha.dll

2) Создать mspatcha.def файл, написать строку «экспортирует», а затем на одну строку для каждого имени функции, которая появляется на выходе DUMPBIN

3) Lib /def:mspatcha.def /out:mspatcha.lib

Хотя я уверен, что это неправильный способ статической связи с patchapi, я не нашел правильный способ сделать это. В любом случае, после выполнения этих шагов и написания простой тестовой записи, сделанной из одного вызова ApplyPatchToFileExA(), я по-прежнему получаю ошибку компоновщика на символе _ApplyPatchToFileA @ 16. Взглянув на экспортируемые символы моего вновь созданного mspatcha.lib, оказывается, что функции используют неправильное имя конвенции

D: \ TMP \ mspatcha> DUMPBIN/экспорт mspatcha.lib | найти «ApplyPatchToFileExA»
   _ApplyPatchToFileExA 

Если я не ошибаюсь, это указывает на то, что Lib экспортируемые функции с использованием Cdecl а длл использует STDCALL (или, по крайней мере декларирует функцию как _stdcall). См.: C name decoration in Microsoft Windows.

Мои вопросы: что такое правильный способ использования mspatcha.dll в моем приложении и что было не так с моим процессом создания lib из dll, чтобы я мог делать статические ссылки?

Подробный вывод моего терминала можно найти здесь: http://pastebin.com/q4FV4Se6

источник

2011-04-18 Stefan Moo

Пожалуйста, разделите термины «статически импортированные» и «статически связанные». Первое означает, что загрузчик будет разрешать любые импортированные функции до того, как двоичный элемент получит контроль (он может выйти из строя). Последнее означает, что фактический объектный код связан с вашим окончательным двоичным изображением. – 0xC0000022L

Я немного смущен тем, что 'lib.exe' должен создавать декорированные имена, подобные этому из файла DEF, который вы даете. Вы пытались связать это.lib, а затем проверить каталог импорта полученного двоичного файла? – 0xC0000022L

Попробуйте использовать этот маленький инструмент: http://vortex.masmcode.com/files/def2lib11.zip - он принимает оформленное имя в файлах .def, чтобы и компоновщик, и загрузчик были довольны. – 0xC0000022L

В качестве отправной точки терминологии вы пытаетесь связать неявно, а не статически, что означает что-то совсем другое.

Если вы действительно не можете получить файл .lib, то один простой способ его создания - создать фиктивную DLL с пустыми заглушками для каждой функции. Вызвать DLL mspatcha.dll. Убедитесь, что вы используете файл .def и stdcall.

Когда вы построили DLL, выбросьте его, но сохраните файл .lib!

Я делал это в прошлом, чтобы генерировать файлы .lib для библиотек DLL, созданных с помощью цепей инструментов, которые не генерируют .lib-файлы.

Используемая вами техника работает только для функций cdecl.

источник

2011-04-18 22:37:51

Это перебор. 'lib.exe' может использоваться для создания импорта' .lib', просто используя файл '.def' (определение модуля). Не нужно создавать фиктивную DLL вообще. Это то, что делает OP, поэтому проблема связана с вызывающим соглашением, как предполагалось. – 0xC0000022L

Боковое примечание: используемый им метод не только работает для '__cdecl'. Я использовал его много раз с '__stdcall'. – 0xC0000022L

@status ваш комментарий о cdecl противоречит здесь: http://support.microsoft.com/kb/131313 –

Ссылка на Windows API PatchAPI

ответ

Смежные вопросы