MASM: Вызовы функций из других библиотек

Несколько странный вопрос: как скомпилировать прогу так, чтобы компилятор вставил тела всех вызываемых функций из других библиотек непосредственно в тело скомпиленной проги?

 

C masm32.lib так и происходит.

 

? вот допустим я вызываю CreateFileA. Каким образом сделать так, чтобы тело функции CreateFileA (со всеми вложенными в него call-ами на другие функции) оказалось в исполнимом модуле моей проги, т.о. мне вообще не нужна библиотека kernel32 становится

 

я думаю можно использовать dll2lib для превращения kernel32.dll в static lib.

В случае с CreateFile должно обойтись довольно дёшево т.к. CreateFile всего лишь переходник на NtCreateFile из ntdll.

Но общем случае это проблемно т.к. придется также добавлять в свой код "дочерние" ф-ции.

 

> я думаю можно использовать dll2lib для превращения kernel32.dll в static lib





В таком случае весь код kernel32.dll попадёт в исполнимый файл.



Broken Sword

Без исходников никак, кажется MS не распространяет kernel32.lib как статик lib.

 

Asterix

а почему ?

я правда dll2lib не использовал, не знаю насколько умно она разлагает код из dll на obj-модули.



или всё в один лепит ?

 

> не знаю насколько умно она разлагает код из dll на obj-модули.

или всё в один лепит ?



Вот именно что в один.

Чтоб иметь такую возможность, о которой говорит Broken Sword, нужно чтоб каждая процедура находилась в отдельном obj и потом из этих obj была собрана статическая lib'а.

 

createfile я привел для примера. на самом деле мне нужны функции runtime C (fopen, strrchr и т.п.). как там дело обстоит с msvcrt.dll?

 

Broken Sword

Исходники crt.lib кажется имеются в MSVC++, можно любые функции дернуть и скомпилить свою либу,

или просто подключить их к проекту и дёргать нужные функции.

 

ок, если верить MSDN-у, то libc.lib - статическая либа с crt-функциями. Ну вот я ее допустим нашел и скопировал в папку MASM. Что дальше? Т.е. вот я в исходнике вызываю любую функцию - допустим _fopen. Какие директивы и опции нужны, чтобы тело _fopen оказалось в моем исполнимом модуле?

 

Методы типа дописать dll-ку в конец, а потом править RVA и т.п. ручные - не предлагать. Все делается как-то гораздо проще, только я не знаю как. Дело в том, что у меня полно exe-шников, которые коды всех вызываемых crt-функций содержат внутри себя. Авторы этих прог явно не парились вручную, компили каким-нить VC++ с каким-то параметром и получили в итоге такой модуль. Вот как то же самое сделать мне?

 

вообщем, пришел к интересным находкам (которые для меня явились откровением): 1. lib - это скопище obj 2. obj и dll - есть суть одна и та же хрень, только obj - статическая либа, а dll - динамическая. 3. Сущесвуют два вида obj- файлов - первый и второй Первый тип содержит только ЗАГЛУШКИ (jmp в dll)-модуль) для всех фукнций, а второй - код всех функций целиком. Таким образом, для моей цели мне нужно искать obj-файлы второго типа. Нашел я такую либу (libcm.lib). Т.е. там не переходники в obj-хах, а код функций целиком. Теперь делаю importlib. Далее прописываю прототип. Вызываю call strrchr. Пишет: unresolved external symbol _strrchr@8.

Пробую call _strrchr (меняю соотвественно и пототип). Пишет: unresolved external symbol __strrchr@8 (т.е. я прибавил _ и он прибавил _ - издевается!!!)



Мож кто статью напишет?

 

это многопоточная версия либы

а ты ее как proto c объявил?

 

Прим. Стандартные библиотеки Си-СиПиПи бывают: однопоточные и многопоточные, отладочные и релизные, в динамической и статической библиотеке - все комбинации этих вариантов.

Если это динамическая библиотека (dll), то все равно требуется .lib для линковки, который обеспечит наличие в модуле заглушек для вызова процедур.

Все эти либы - в разных файлах.



Если взять для примера статическую рантаймовую релизную библиотеку для 6 студии (боюсь соврать, но вроде и для седьмой тоже), то это LIBCMT.LIB.



Ничего страшного в линковке ее нет. Определена она как extern "C" char * __cdecl strcpy(char *, const char *);, а значит незаманглена.



__cdecl означает, что стек очищать должен вызывающий.



В общем, вот переделанный вариант второго туториала с примером использования strcpy:

Код (Text):

1.  
2. .386
3. .model flat, stdcall
4. option casemap:none
5. include \masm32\include\windows.inc
6. include \masm32\include\kernel32.inc
7. include \masm32\include\user32.inc
8. includelib \masm32\lib\user32.lib
9. includelib \masm32\lib\kernel32.lib
10.  
11. extern C strcpy:near ; Вот такое просто определение
12.  
13. .data
14. MsgCaption      db "Iczelion's tutorial no.2",0
15. MsgBoxText      db "Win32 Assembly is Great!",0
16.  
17. .code
18. start:
19.     sub esp, 100h
20.     push    offset MsgBoxText
21.     lea     ebx, [esp + 4]
22.     push    ebx
23.     call strcpy
24.     add     esp, 8 ; очищаем стек
25.  
26.     invoke MessageBox, NULL,ebx, addr MsgCaption, MB_OK
27.     invoke ExitProcess,NULL
28. end start
29.  

И сборка его:

Код (Text):

1. \masm32\bin\ml /c /coff MSGBOX.ASM
2. \masm32\bin\link /subsystem:windows msgbox.obj LIBCMT.LIB
3.  

P.S. Я не знаю, как сделать с прото, вероятно где-то надо указать calling convention.

 

Broken Sword >

Скорми либу IDA и пользуй полученый исходник





_Juicy >

Вот как в WINDOWS.INC объявлена wsprintf:



wsprintfA PROTO C WORD,:VARARG

wsprintf equ <wsprintfA>

 

2 _Juicy: твой метод рабочий, но дело в том что там сотни crt-функций, я замахаюсь их всех extern-ировать.

Гораздо предпочтительней из-за этого исп. прото, т.к. protoize автоматизирует эту рутину.



2 Stas: насчет кормления IDA - та же самая проблема. IDA почему-то не может работать со всей lib целиком - только с отдельными obj-ами. Я также замахаюсь их все конвертировать.



Вообщем, даже вариант - использовать прото c динамической библиотекой не работает. Делаю includelib msvcrt.lib, include msvcrt.inc, потом вызов _fopen - куча ошибок непонятных:



decrypt.obj : error LNK2001: unresolved external symbol _??_C@0

decrypt.obj : error LNK2001: unresolved external symbol _??0DName@0

decrypt.obj : error LNK2001: unresolved external symbol _??4DName@0

decrypt.obj : error LNK2001: unresolved external symbol _??HDName@0

decrypt.obj : error LNK2001: unresolved external symbol _??YDName@0

decrypt.obj : error LNK2001: unresolved external symbol _?getDataIndirectType@0

decrypt.obj : error LNK2001: unresolved external symbol _?getLastChar@0

decrypt.obj : error LNK2001: unresolved external symbol _?getString@0

decrypt.obj : error LNK2001: unresolved external symbol _?length@0

decrypt.obj : error LNK2001: unresolved external symbol _?name@0

decrypt.obj : error LNK2001: unresolved external symbol _??0__non_rtti_object@0

decrypt.obj : error LNK2001: unresolved external symbol _??0bad_cast@0

decrypt.obj : error LNK2001: unresolved external symbol _??0bad_typeid@0

decrypt.obj : error LNK2001: unresolved external symbol _??0exception@0

decrypt.obj : error LNK2001: unresolved external symbol __real@8

decrypt.obj : error LNK2001: unresolved external symbol __fopen





первые unresolved external symbol всегда постоянные, а вот последний (тут __fopen) варьируется от того, какую функцию я вызываю. Слушайте, это никак не связано с crtstartup ? Я помню где-то когда-то компили прогу, и пока не сделал extern вот эту функцию она не компилилась. но то было под pocketpc и потом я как то обошел эту проблему

 

Broken Sword

сделать свой заголовочный файл для CRT.

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

 

Broken Sword >

Э-ээ.. а они именно все и нужны?

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



Может быть я не понимаю суть проблемы, что мешает использовать внешнее crt, вроде msvcrt.dll

В FASM это делается очень просто: crt.zip

 

В FASM-е работает, а почему в MASM-е нет?



msvcrt.inc - сгенерен protoize

msvcrt.lib - вытянут из MSVC



код проги (вообще пустота считай):



.386

.model flat, stdcall

option casemap :none ; case sensitive



include \masm32\include\windows.inc

include \masm32\include\user32.inc

include \masm32\include\kernel32.inc

include \masm32\include\msvcrt.inc



includelib \masm32\lib\user32.lib

includelib \masm32\lib\kernel32.lib

includelib \masm32\lib\msvcrt.lib



return MACRO arg

mov eax, arg

ret

ENDM



.code



LibMain proc hInstDLLWORD, reasonWORD, unusedWORD

.if reason == DLL_PROCESS_ATTACH

return TRUE

.endif

ret

LibMain Endp



end LibMain



Компилю:

\masm32\bin\ml /c /coff decrypt.asm

\masm32\bin\Link /SUBSYSTEM:WINDOWS /section:.text,ERW /DLL /DEF:decrypt.def decrypt.obj



тут же:

decrypt.obj : error LNK2001: unresolved external symbol _?vswprintf@0

decrypt.obj : error LNK2001: unresolved external symbol _?swprintf@0

decrypt.obj : error LNK2001: unresolved external symbol _??_V@0

decrypt.obj : error LNK2001: unresolved external symbol _??_U@0

decrypt.obj : error LNK2001: unresolved external symbol _??3@0

decrypt.obj : error LNK2001: unresolved external symbol _??2@0

decrypt.obj : error LNK2001: unresolved external symbol _??0exception@0

decrypt.obj : error LNK2001: unresolved external symbol _??0bad_typeid@0

decrypt.obj : error LNK2001: unresolved external symbol _??0bad_cast@0

decrypt.obj : error LNK2001: unresolved external symbol _??0__non_rtti_object@0

decrypt.obj : error LNK2001: unresolved external symbol _??_C@0

decrypt.dll : fatal error LNK1120: 11 unresolved externals



Это проблема чего вообще? protoize? неужели никто не сталкивался ей богу...

 

ну с вышеприведенными проблема решилась - оказывается protoize всех их в inc-файле продублировал по два и более раз. убираю копии - и данный "пустой" исходник компилется без ошибок. Теперь добавляю в него "полезный" код - call _fopen:



decrypt.obj : error LNK2001: unresolved external symbol __fopen. В inc файле у меня такое определение: _fopen PROTO C :VARARG. Опять protoize напортачил?