Создание lib из dll средствами пакета masm

После неудачного эксперимента с линкером polink, входящим в состав пакета masm, оказался утерянным файлик user32.lib из папочки lib)) (Эксперимент: polink.exe /IMPLIB:"\lib\user32.lib" /subsystem:console /out:Test.exe Test.o - линковка прошла неудачно, из за того что MessageBoxA не был найден, что вообще странно учитывая что он описан в user32.lib, но зачем линкер удалил саму библиотеку импорта я хз)

Ладно суть не в этом, а в том, как восстановить этот файл. Использовав polib.exe, у меня создался lib-файл, но имена там декорированы по другому (без @) (линкер ld вообще отказался считать его Lib-файлом, а ml сказаль что не может найти там _MessaheBoxA@16, что весьма логично, учитывая что его там нет, а есть - _MessageBoxA, причем в опциях Polib.exe есть возможность убрать подчеркивание, но вот добавить декорирование имен там нельзя, опция /OLDIMPLIB, описанная в txt файле pelles, которая видимо должна создавать старую версию lib-файла, вообще оказалась не рабочей - /OLDIMPLIB is unrecognised option, версия polib - 5.00, а сам пакет масма - 10, скачивал с этого сайта)

Я полагаю, что есть и другие проги из папочки bin которые могут это сделать, но хелпа по их параметрам я не нашел. Мб кто знает?

 

inc2l user32.inc ;inc2l.exe лежит в masm32\include
он имеет свойство собирать .lib из .inc

 

P.S можно ещё более удобным методом:
masm32\include\bldlibs.bat

В более ранних версиях инсталлятора были только .inc, .lib создавались с помощью этого пакетного файла. В масм 10 он тоже есть. Короче просто запускаю и не парься.

 

Спасибо вам мастермсэм, правда bldlibs я как-то тоже не менее случайно удалил, а вот с inc2l получилось. НО все таки: Если средства пакета masm, позволяющие делать lib из dll ?

 

Praetor11

А нафига его вручную восстанавливать? что архива с масмом не осталось? или перескачать его религия не позволяет?

 

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

 

* Vortex's Utilities, Tools And Toys

DLL to module definition file & include file converter V1.4
Dll2inc is designed to create module definition & include files from C run-time DLLs such as msvcrt.dll and crtdll.dll
To avoid naming conflicts with the original MASM keywords, a macro named cinvoke is designed to call C functions.
The creation of import libraries from C run-time DLLs is very easy, check the attachment to see how to do it with Pelle's powerfull librarian Polink.
Dll2inc14.zip


* Object file converter

This utility can be used for converting object files between COFF/PE, OMF, ELF and Mach-O formats for all 32-bit and 64-bit x86 platforms. Can modify symbol names in object files. Can build, modify and convert function libraries across platforms. Can dump object files and executable files. Also includes a very good disassembler supporting the SSE4, AVX, FMA and XOP instruction sets. Source code included (GPL). Manual.


* \masm32\include\bldlibs.bat

 

А можете то же самое по-русски и с примерами?! С какими ключами запускать dll2inc. Ну а файла bldlibs.bat у меня вообще в папке bin нету(. Приведите алгоритм создания файла MyDll.lib из MyDll.dll (написана на C++ если это важно) - что, с какими ключами и в какой последовательности запускать. Плизз..

 

Ну так читай внимательнее...

 

Посмотрите статью «Создание универсальных def и lib-файлов для «чужих» dll». Там, в итоге сгенерирован user32.lib, который даже лучше мелкософтовского. Например, с помощью полученных универсальных либов можно программировать как в стиле Iczelion’а (но без громоздких inc-файлов), так и в стиле Ильфака Гильфнова (extrn . . . dword или extrn . . . proc директивы). Скажем, для кода

Код (Text):

1. ; ===========================================================================
2.  
3. .686p
4. .mmx
5. .model flat
6.  
7. option casemap:none
8.  
9. ; extrn MessageBoxA : proc
10. ; extrn MessageBoxA@16 : proc
11. ; extrn _imp__MessageBoxA : dword
12. extrn _imp__MessageBoxA@16 : dword
13.  
14. includelib Lib\user32.lib
15.  
16. ; extrn ExitProcess : proc
17. ; extrn ExitProcess@4 : proc
18. ; extrn _imp__ExitProcess : dword
19. extrn _imp__ExitProcess@4 : dword
20.  
21. includelib Lib\kernel32.lib
22.  
23. ; ===========================================================================
24.  
25. .data
26.  
27. Header      db "Question", 0
28. MsgText     db "Do you want quit?", 0
29.  
30. ; ===========================================================================
31.  
32. .code
33.  
34. _Start:
35.     push 4   ; MB_YESNO
36.     push offset Header
37.     push offset MsgText
38.     push 0
39.  
40.     ; call MessageBoxA
41.     ; call MessageBoxA@16
42.     ; call _imp__MessageBoxA
43.     call _imp__MessageBoxA@16
44.    
45.     cmp eax, 6  ; IDYES : 6 - Yes, 7 - No.
46.  
47.     je Quit
48.     jmp _Start
49.  
50. Quit:
51.     push 0
52.  
53.     ; call ExitProcess
54.     ; call ExitProcess@4
55.     ; call _imp__ExitProcess
56.     call _imp__ExitProcess@4
57.  
58. end _Start
59.  
60. ; ===========================================================================

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

 

Кстати, автору статьи: есть куда менее изъ... тернистый путь создания def. Пусть прочитает про MS DIA. Быстро выдираем символы, генерим деф.

 

Чем Ваша логика отличается от: «Есть lib-файлы в MASM32 и MS Visual Studio C++. Вот и используй их!»? Вы можете проверить эффективность своего совета на примерах из http://erfaren.narod.ru/Asm/CreatingLibFiles.003. Чтобы скомпилировать десять asm-проектов оттуда, нужно запустить def2lib.cmd который генерит 16 системных lib-файлов (но Вы создадите их своим способом, не так ли?). Затем для каждого проекта (из папки Results (содержимое которых копируется на два уровня выше) делается компиляция с помощью соответствующего файла asm.bat. Все примеры (перекомпилированные ехе-шники из Виндозы) работоспособные для прилагаемых деф-файлов. Вам остается только проверить Ваши def-файлы. Если Все будет ОК, то правы Вы, иначе автор статьи. Идет? Да, желательно простейший файл mb.asm скомпилировать в четырех вариантах (раскомментируя соответствующие строки), для одних и тех же либов.

 

Scholium
Он сам в своей статье написал "а вот если был бы способ распарсить pdb.. было бы проще". Так вот он есть, пусть смотрит DIA SDK.
А чо вы мне тут многабукв понаписали я ваще не знаю, хоть бы с вопросом разобрались сначала.

 

Ну, в VS C++ есть примеры работы с pdb-файлами через их API. Этот путь известен, но он громоздкий, ничуть не проще предложенного скрипта на VFP. А работа с «Идой» нужна по любому, ибо ради нее, в общем-то, все и затевалось.

Я понимаю, что «многабукв» писать лениво, но «малобукв» это как-то неконструктивно. Советы типа: «читать», «выдергивать» без конкретики не добавляют пиетета. Если бы я возражал на Вашем месте, то написал бы примерно так: «Erfaren просит подсказать более простой способ «потрошения» pdb-файлов. Так вот, такой способ существует и он состоит в том, что. . .». А далее следовал бы собственно совет, что именно «читать» и с какой целью, и как именно «выдергивать» и продемонстрировать примеры. Ну, там бы ссылочки были бы не вредны. А тот фронт работ, который Вы обозначили, слишком расплывчат. Явных преимуществ, перед уже проделанной работой не сулит. Потому и не вызывает энтузиазма.

А DIA SDK мы как-нибудь почитаем на досуге, по крайней мере, когда почувствуем в этом смысл. Ибо из Ваших слов таковой смысл выявить очень сложно. Это насчет пользы «многабукв» .

 

По большому счёту DIA SDK не сильно и нужен для того, чтобы имена экспортов из PDB получить. При настроенном сервере символов «dumpbin /exports» справляется с этим на твёрдую пятёрку, даже прототипы для декорированных C++ имён указывает.

 

<удалено>

 

Ну, я так и думал. Просто получить «имена экспортов из PDB» не большая проблема. Речь идет-то о создании универсальных def-файлов (а, следовательно, и lib-файлов), в смысле:

1. Использования как стиля Iczelion’a, но без inc-файлов, так и стиля Ильфака Гильфанова (в IdaPro) (фактически четыре варианта вызова функций, при двух вариантах описаний в дефах);

2. Полного (полноценного) описания всех функций системных dll-файлов от Майкрософт (сравните, например, описание mfc42u.def, в упоминаемой выше ссылке с представлением mfc42u.dll с помощью dumpbin.exe).

Реально, альтернативой метода, предложенного в статье, будет представление файла типа pdb2def.exe (желательно, с исходными текстами). Мы могли бы и сами написать это приложение, тем более что сырого кода на си вполне достаточно для юзания файлов символов. Просто этот путь показался излишне трудоемким, при том же уровне полученных результатов. Поэтому, реплики типа: «а можно сделать по-другому», воспринимаются не очень. Да, можно! Кто спорит? Ну, так сделайте и проверьте свои дефы для прилагаемых асм-проектов. Тогда будет интересно сравнивать.

Вот следующая интересующая нас тема. Перекомпиляция файла tsadmin.exe (ок. 300 Кб) прошла успешно. Но полученный файл не работает. Причина – несколько сотен нераспознанных «Идой» ссылок (оффсетов), которые она восприняла как (абсолютные) значения. Как направить «Иду» (демо-релиз) на путь истинный? Многие скажут: «Это можно сделать! И даже делалось тем-то и тем-то». Но нам надо не вообще, а конкретно, для данного случая. Поскольку «Ида» демонстрационная, то скрипты могут быть только внешние. Этот скрипт мы уже написали, сейчас отлаживаем. Можете предложить другой реальный, а не абстрактный вариант?

 

Scholium,

Пользоваться полезными утилитами (dumpbin, sed/awk) для генерации исходного кода MASM можно?

На мой взгляд, dumpbin побогаче будет, в смысле правильных имён для экспортов по ординалу.

И ещё — меня смущает наличие двух разных подходов к .Lib: то, как они описаны у Питрека (и генерируются ImpLib от Quantum), и новый формат, используемый VS.Net и выше.

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

 

Можно. Говорю только про dumpbin, так как других не знаю. Только dumpbin даст вам имя, скажем, MessageBoxA, но не даст имя MessageBoxA@16, так как его в user32.dll просто нет. Реально, это алиас, поставляемый файлом user32.pdb. Тоже для ординалов. Так, в файле mfc42u.dll около 7000 экспортируемых функций, но имена определены только для шести из них. Остальные имена, точнее алиасы (или первоначальные имена известные только Майкрософту) берем из файла символов mfc42u.pdb. Однако даже этот файл символов может показать, например, что существует свыше тридцати ординалов с общим телом функций, но имен (алиасов) этих функций не дать. Некоторые из этих имен можно найти в pdb-файлах для Майкрософтовских ехе-шников, импортирующих mfc42u.dll. Одно это показывает, что формально одних символов для данной длл-ки недостаточно, чтобы построить ее полноценный деф-файл.

Как видите, из предыдущего абзаца, это не так.

Надо исходить не из либов, а из дефов. Тогда и проблем будет поменьше. Нужные дефы всегда легко подправить и перекомпилировать снова в либы. Это все равно, что вместо си-шных h-файлов ориентироваться на их предкомпилированный pch-файл. А формат дефов достаточно примитивный, чтобы говорить о двух подходах. Обо всем этом подробно говориться в упоминаемой статье.