[4.3.0-win] Как быть с dll?

[Icoz]

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

Не понял:
1) Скачать новую версию DeDe? Или моей либы, которую пытаюсь распотрошить?
2) Авторы опять же DeDe или моей либы? Если авторами моей либы - то нет, пробовали уже. Дохлый номер, народ пытается нам тупо втюхать другой свой продукт. Нам же надо работать с ЭТОЙ dll. Так что обновить версию ее невозможно.

[Icoz]

поднимаю наверх, проблема не решена.

[Tonal]

Создай новую тему, опиши в краце что хочешь сделать и что не получается.
А то искать среди 5и страниц что же тебе надо как-то в лом. ;-)

[Icoz]

Вкратце не выйдет! Тем более мне опять напишут те самые 5 страниц, что можно сделать!
Так ты хоть ознакомишься с тем, что предложили, проверили и отвергли.

А суть проблемы: надо в винде подключить dll к проге. Есть dll, есть хидеры, к ней НЕТ lib (import library).
QLibrary отпадает, ибо там куча классов. Всего порядка 3500 экспортируемых функций.
Подробнее читай предыдущие посты

[Icoz]

еще раз поднимаю.
Проблема все еще имеется в наличии

[Tonal]

Если компилишь mingw и либа слинкована им же, или имеет только С экспорты - можно просто указать её в списке либ.
Если нет - то всё сильно зависит от...

[Icoz]

Почитай посты в самом начале (штуки 3-4) и 3-5 с конца, чтобы достаточно вникнуть в проблему.
Dll сделана в borland'е, скорее всего Borland C++ 5.02. ImpLib к ней нету.
Надо ее подрубить к проге.

[Tonal]

Если используется экспорт классов, то напрямую подрубить - дохлый номер.
Проще сделать так:
1) Найти компилятор, которым это чудо собрано.
2) Собрать им dll-переходник которая импортирует твою, а экспортирует чистый С-ишный апи.
3) Подцепить переходник из мингвы.

В принципе, вместо/вместе с чистым С, если согласовать выравнивания, можно обмениваться интерфейсами. Я так делал.

Можно ещё COM прикрутить, но это уже для мазахистов, т.к. ни для багланда ни для мингвы нормальных лёгких библиотек нету...

P.S. насчёт DeDe - бред.

[Icoz]

Если используется экспорт классов, то напрямую подрубить - дохлый номер.

Читай выше, кое-что подрубается. Через QLibrary я смог поштучно подрубать все функции класса, явно передавая в них (обычно неявный) указатель this. Слишком тяжело, ибо там 10-15 классов крупных (по 100-150 функций) и с десяток помельче (10-30 функций). Руками анрил, после скрипта все равно много работы.

Проще сделать так:
1) Найти компилятор, которым это чудо собрано.
2) Собрать им dll-переходник которая импортирует твою, а экспортирует чистый С-ишный апи.
3) Подцепить переходник из мингвы.

Допустим проблему с 1 и 3 я решу. А про п.2 по-подробнее рассказать можешь? Пример кода что ли?...
Скажем для класса(только с условием, что там по 100-150 функций... как-то по рациональней что ли...):

Код:

class Test{
public:
int func1(int,double);
void func2(int) inline; // или как там? короче с инлайн функциями
};

[Tonal]

Если используется экспорт классов, то напрямую подрубить - дохлый номер.

Читай выше, кое-что подрубается. Через QLibrary я смог поштучно подрубать все функции класса, явно передавая в них (обычно неявный) указатель this. Слишком тяжело, ибо там 10-15 классов крупных (по 100-150 функций) и с десяток помельче (10-30 функций). Руками анрил, после скрипта все равно много работы.

А кто сказал, что функции из дллки выдернуть незя?
А вот глюков при этом  отловить - запросто. Самые очевидные:
1) Если есть исключения - будет глючить.
2) Если память выделяется в разных модулях - будет глючить (например память выделилась в обычной функции а удалилась в инлайне)
3) Если попытаешся отнаследоваться - будет глючить.
4) Если будешь использовать dynamic_cast - будет глючить.
5) Если в параметрах/возвратах используются не только POD типы - будет глючить.
Это только на вскидку...

Теоретически, всё это можно разрулить...
Практически - я бы взялся, за "многа денгаф" и без каких-либо гарантий. ;-)

2) Собрать им dll-переходник которая импортирует твою, а экспортирует чистый С-ишный апи.

Допустим проблему с 1 и 3 я решу. А про п.2 по-подробнее рассказать можешь? Пример кода что ли?...
Скажем для класса(только с условием, что там по 100-150 функций... как-то по рациональней что ли...):

Код:

class Test{
public:
int func1(int,double);
void func2(int) inline; // или как там? короче с инлайн функциями
};

Довольно просто.
Заголовок будет выглядеть так:

Код:

extern "C" {
typedef void* HTest;
HTest test_create();
void test_destroy(HTest);
int test_func1(HTest, int, double);
void test_func2(HTest, int);
}

Реализация - тривиально.

Если объем классов очень уж большой, то можно нарисовать скриптик (python, perl, ets) который по исходному заголовочнику быстро соорудит заготовку. Дальше допиливаешь неоднозначности, разруливаешь перегрузки, и собираешь.

[Icoz]

Если объем классов очень уж большой, то можно нарисовать скриптик (python, perl, ets) который по исходному заголовочнику быстро соорудит заготовку. Дальше допиливаешь неоднозначности, разруливаешь перегрузки, и собираешь.

Хидеры у меня родные есть, только не помогают.
Пока так и делаю, только скрипт написать так, чтобы он прямо по хидеру работал, для меня тяжко (там парсер нехилый нужен). Поэтому я сначала руками специально готовлю хидер (что тоже тяжко, ибо хидеры почти полметра весят! их там файлов 40-45), чтобы его кушал мой скрипт.
Так что, к сожалению, ты мне ничего нового (кроме как обширный список глюков) не сказал.

Вопрос-то изначально стоял иначе: как подрубить dll без излишних телодвижений? Хидеры есть (это самое главное, ибо по ним известен размер классов), а вот все эти шаманства с переходниками... много бубнов программерских попереломаю.

Есть ли способ получить implib для этой dll?

[Tonal]

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

Единственное, что можно сделать, это нарисовать б/м "умный" набор скриптов.

P.S. Ещё можно подождать до выхода следующего стандарта С++, или лучше послеследующего. Там вопросам совместимости некоторое внимание начали уделять. ;-)

[Icoz]

Смешно. Меня начальство уже сейчас трясет... 

[Icoz]

UP

[T800]

Единственный реальный способ когда все будет работать -
1. Создать в том же компиляторе на котором написана библиотека либ-файл по принципу - заколовок  плюс .cpp в котором все методы есть но они пустые.
2. Создать СOM+ библиотеку врапперов всего чего там есть НА ТОМ ЖЕ КОМПИЛЯТОРЕ
3. А вот с помощью ее MIDL-ов пользоваться этими COM-бъектами уже из под той среды, что тебе нужна.
Очень много работы и без скриптов  не обойдешся (займет  при том объеме который заявлен порядка квартала в одиночу плюс съеденный бессонницей мозг)
Большой минус такой реализации - потеря быстродейсвия