>Я так понял, есть следующие варианты решения моей проблемы:
>1) Написать маленькое Виндовс-приложение, которое содержит вызовы к моей
>Windows длл-ке. Это приложение работает например через командную строку.
>Опрашивая определенный параметр в коммандной
>строке приложение вызывает определенную функцию длл-ки.
>Порядок работы с длл-кой я вижу таким: моя линуховая прога вызывает
>виндовую прогу через Wine с определенным списком параметров коммандной строки.
>Виндовая прога дергает нужную функцию длл-ки
>и возвращает результат (интересно, как?).
Вполне работоспособный вариант. Проблемы будут как раз с обменом данными
между Linux-овой и Windoze-ной частями.
Можно поплясать вокруг временных файлов либо (как бы смешно это ни звучало)
вокруг сокетов семейства AF_INET.
>2) Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я так понял, можно
>взять бинарную длл-ку без исходников, и WineLib может сделать из нее
>линуховый бинарник?
Как раз это и есть невозможное дело. Употребить WineLib можно _только_
при наличии исходных кодов той части, коя с ним собирается.
>3) Лучшим выходом из положения было-бы переписать длл-ку самостоятельно.
>Вот только проблема в чем. Эта длл-ка - это длл-ка от стороннего производителя. Она
>реализует часть функций набора компонент для сжатия файлов ZipTV. В частности,
>мы используем алгоритм BlackHole для упаковки файлов. От использования этого алгоритма
>мы отказаться не можем. Этот алгоритм является фирменным закрытым алгоритмом
>производителя этих компонент для Дельфи. Поэтому переписать нам этот алгоритм не
>получится. Я пытался найти библиотеку, реализующую этот алгоритм для Линуха. Так
>и не нашел :(
Типичный пример отсутствия предварительного (до выбора архитектурных и, в данном
случае, алгоритмических решений) анализа направлений развития софта. Здесь можно
сказать нехилое спасибо Wine за то, что он есть. Говоря откровенно, возможность
бинарника для одной ОС функционировать в совершенно другой, реализующей
принципиально другие наборы API - большая редкость.