Ну, собственно, всю проблему в заголовке написал!
Есть Борландовая ДЛЛ-ка - надо ее статически прилинковать в проект VC6.
Пробовал через билдеровскую impdef сделать DEF, а из него уже мокрософтовской LIB /DEF:filename.def - получить LIB. Все бы хорошо - даже линкуется, а вот в момент вызова функции вываливается. Есть мысль, что из-за различной структуры COFF и OMF библиотек.
Исходные данные: DLL (Builder6) + *.h к ней.
Задача: использовать эту библиотеку (без перекомпиляции самой dll) в проекте VisualC++ (6), подключая ее статически.
Подскажите, плз!, как быть?

implib-овские lib-ы компилятор VisualC++ не ест вообще. Может и есть возможность средствами MS сделать корректный lib из любой библиотеки, но если б я нашел - не спрашивал бы. А вот различия OMF и COFF сводятся к работе с памятью, в связи с чем при динамической линковке - получил конкретный адрес функции и все ОК, а статически - смещения не бьют. А OMF оказывается еще и разные бывают - Intel и Borland. Есть у Borland-а утилита coff2omf.exe - так вот мне бы как раз обратно надо!

White Owlimplib разный бывает. Бывает от Борланда, бывает от Микрософта....
Первый раз слышу. Есть lib.exe, но как ему впихнуть Борландовскую dll?

Вот к чему я пришел. Разница между стандартами библиотек в работе со стеком (где-то вычитал). При динамической компоновке, функция GetProcedureAdress возвращает реальный адрес нужной функции, а при статическом подключении, насколько я понимаю, используется смещение на каждую функцию. Вот тут и загвоздка - COFF по своему заполняет память, а OMF - по-своему.
У Борланда есть утилита coff2omf.exe, так вот мне надо как раз наоборот! При этом "implib.exe -a" не прокатывает...
Неужели никто не знает как это сделать? У меня в библиотеке более 1200 функций - я свихнусь их динамически подключать!

Вот это уже больше похоже на дельный совет! Однако, вот что выдает мне impdef:

Если impdef использовать с опцией -а, то получается вот так:

Отсюда вопрос - что как править и как использовать impdef (c -a или без)?
И откуда такая разница в описании функций в def-файле - то с собаками, то без, а то еще и с "баксами" - чтобы все это значило?

Попробовал. Не катит. Кроме того, все что там описано можно получить просто используя impdef с опцией -а. При этом в Билдере есть еще и утилита для преобразования lib-ов из COFF в OMF. Поэтому проблем-то никаких при использовании MSVC-библиотеки в Builder, надо-то как раз НАОБОРОТ! Если бы все так просто было - там черточку убрал, сюда поставил, то уж написал бы кто-то парсер для DEF-файлов, однако я ничего не нашел в Интернете.

White OwlВ Visual C зато есть утилита lib.exe, которая сама умеет делать библиотеки для импорта. Любыми средствами (хоть вручную хоть через борландовский imdef) делаешь def файл для своей dll. Потом lib /def:myimport.def , и все.
Я с этого начал (см. начало темы). Lib нормально собирается и безошибочно прилинковывается, однако, при вызове функций (причем после их отработки) вылетает сообщение:

Чтобы это значило?
При динамическом подключении все ОК. Изменения директив вызова функций в родном h-нике, либо устранение/добавление extern "C" приводят либо к ошибке на этапе компиляции, либо к ошибке в доступе к памяти в момент обращения к функции. Тогда как в первом случае функции хотя бы успевают отработать.
White Owlа сделать массив имен и массив адресов?Что-то вроде этого и пришлось на данный момент наваять, но ведь обидно, что не удается разобраться! Причем заковырка-то, скорее всего, плевая...

Всем доброго времени суток!
Прощу прощения за длительное отсутствие, но, думаю, следует эту тему продолжить, ибо конкретного решения до сих пор нет, а ситуация, судя по цитируемости в Инете, весьма распространенная.
Во-первых, всем большое спасибо за участие в дискуссии.
Во-вторых - результаты моих мучений.
Спасибо White Owl за наглядный пример. Реально он не помог, но его исследование привело к некоторым умозаключениям.
Дело в том, что есть набор библиотек, которые обновляются практически каждый день. Есть ряд разработок на различных языках, использующих эти библиотеки, в том числе и на VC (с чем и проблема). Кроме того, эти библиотеки поставляются еще и сторонним разработчикам. Соотвествено, писать промежуточные библиотеки для создания lib-ов для VC, как в примере White Owl , равно как и плодить дубликаты этих библиотек для каждой среды разработки - не есть приемлимый вариант. Утилита, скачаная по ссылке от ii , кроме того, что отказывается воспринимать DLL со смешанными вызовами функций _cdecl и _stdcall (и в help-e ничего путного про это не написано), также еще и не является программой "open source", что не приветствуется моей компанией.
Итак, чтобы статически прилинковать библиотеку формата OMF в проект VC, требуется выполнить ряд шагов (самый простой пока вариант):
1) сделать def.
для этого, используя borland-овский impdef, генерируем def-файл с перечнем функций библиотеки, далее правим его следующим образом:
2) используя поправленный def, сделать lib:
lib /def:<defname>.def
3) подключить lib: #pragma comment (lib, "<libname>.lib")
4) использовать функции с описанием их как __cdecl или __stdcall соответственно.

Однако, при таком раскладе не удается автоматизировать процесс создания lib из существующей dll, что в моей ситуации необходимо. Парсер для создания def-файла, даже имея все h-файлы с описаниями функций библиотек, представляется мне весьма сложным в отношении _stdcall -функций, ибо возможность подсчитать байты параметров функций себе плохо представляю, учитывая наличие множества пользовательских типов данных.
Соответсвенно, вопрос остается открытым.

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

Жду ваших рекомендаций и замечаний по этому вопросу.

Gluk (Kazan)А нафига нужно грузить все эти DLL именно статически ???
Грузи динамически, для этого lib-ы не нужны

Выше я описал проблему и то, почему надо именно статически.

Господа, еще один вопрос в ту же тему.
В def-файле для каждой функции прописывается ее номер:
При использовании Borland-ового IMPLIB можно указать опцию -f (force by name), тогда при подключении lib-a в проект, определение точек входа будет осуществляться по имени, а не по номеру. Вопрос: как заставить так же работать lib.exe (от MS), чтобы компилятор VC не ругался на lib, собранный по def-у, в котором не указаны номера функций (или указаны не те)?

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