Как запустить dll linux
Обновлено: 03.07.2024
наше приложение основано на Linux, поэтому я не могу напрямую общаться с DLL. Я не мог найти никакого существующего решения, поэтому я рассматриваю возможность написания моста на основе сокетов между Linux и Windows, однако я уверен, что это не такая уникальная проблема, и кто-то должен был сделать это раньше.
знаете ли вы о каком-либо решении что позволяет вызывать функции DDL Windows из приложения C на Linux? Он может использовать вино или отдельный ПК с Windows - не имеет значения.
заранее большое спасибо.
любое решение будет нуждаться в "удаленном" уровне на основе TCP/IP между DLL, которая работает в "windows-подобной" среде, и вашим приложением linux.
вам нужно будет написать простое приложение для ПК, чтобы предоставить функции DLL, используя протокол homebrew или, возможно, протоколы XML-RPC, SOAP или JSON. The файлом remobjects SDK для может помочь вам - но может быть перебор.
Я бы придерживался "реального" или виртуализированного ПК. Если вы используете Wine, разработчики DLL вряд ли окажет поддержку.
получить сниффер и узнать протокол. Именно это я и делаю.
хотя этот вопрос довольно старый, тема, видимо, не потеряла своей актуальности. Если вы можете использовать или используете Python . вот мое решение.
Я написал небольшой модуль Python для вызова в DLL Windows из Python на Linux. Он основан на IPC между обычным процессом Python Linux/Unix и процессом Python на основе вина. Поскольку я сам нуждался в нем в слишком многих различных случаях использования / сценариях, я разработал его как "общий" ctypes модуль drop-in замена, которая делает большую часть необходимой сантехники автоматически в фоновом режиме.
Пример: Предположим, вы находитесь в Python на Linux, у вас установлено Wine, и вы хотите позвонить в msvcrt.dll (библиотека времени выполнения Microsoft C). Вы можете сделать следующее:
Это все еще немного грубо вокруг краев (т. е. альфа и небезопасно), но работает большинство типов параметров (включая указатели).
иногда лучше выбрать небольшого поставщика над большим поставщиком, потому что размер вашего бизнеса даст вам больше веса для них. Мы, безусловно, нашли это с поставщиками AV engine.
Если вы достаточно важны для них, они должны предоставить либо документированный, поддерживаемый протокол, сборку библиотеки Linux, либо исходный код библиотеки.
в противном случае вам придется запустить окно Windows в цикле с помощью RPC, как отмечали другие, что скорее всего, будет очень неудобно, особенно если вся остальная инфраструктура работает на Linux.
будет ли поставщик поддерживать использование своей библиотеки в виртуальной машине Windows? Если производительность не критична, вы можете это сделать.
вызов самих функций DLL, конечно, только верхушка айсберга. Что делать, если DLL вызывает Win32, то у вас будет довольно массивная проблема с связыванием. Я думаю, вино может помочь вам там, не уверен, что они обеспечивают решение.
IMO, лучше всего использовать сокеты. Я уже делал это раньше, и это работает как шарм.
прошло несколько лет с тех пор, как был задан вопрос, но вот другой подход. Использовать objdump -d чтобы разобрать DLL. Вы можете сделать чистый, unadultrated мусор, или код, полный вызовов Windows, или оба. Функции часто разделяются серией push инструкции и заканчиваются на ret инструкция.
Проблема следующая: В свое время мы на фирме написали приложение под Виндовс. Теперь стоит задача переписать его под Линух. Проблема в том, что в этом приложении используется длл-ка от стороннего производителя. Исходников длл-ки нет. Поэтому хотел спросить: как можно сделать так, чтобы можно было вызывать функции этой длл-ки из под Линух.
Можно попытаться поковырять WINE на этот счет, есть ли у него интерфейсы вызова.
Ещё MPEG-4 плееры под Линукс активно пользуют виндовые ДЛЛ.
>Ещё MPEG-4 плееры под Линукс активно пользуют виндовые ДЛЛ.
дык они вроде как не совсем виндовые используют, всмысле это не те же самые кодеки что ставятся под вин
>дык они вроде как не совсем виндовые используют, всмысле это не те
>же самые кодеки что ставятся под вин
А какие же? Самые настоящие dll'ки из виндов, если нет нативного
кодека, то минипорт из wine в плеерах позволяет как раз использовать
виндовую dll'ку, квиктайм например так юзают.
Я так понял, есть следующие варианты решения моей проблемы: 1) Написать маленькое Виндовс-приложение, которое содержит вызовы к моей Windows длл-ке. Это приложение работает например через командную строку. Опрашивая определенный параметр в коммандной строке приложение вызывает определенную функцию длл-ки. Порядок работы с длл-кой я вижу таким: моя линуховая прога вызывает виндовую прогу через Wine с определенным списком параметров коммандной строки. Виндовая прога дергает нужную функцию длл-ки и возвращает результат (интересно, как?). 2) Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я так понял, можно взять бинарную длл-ку без исходников, и WineLib может сделать из нее линуховый бинарник? 3) Лучшим выходом из положения было-бы переписать длл-ку самостоятельно. Вот только проблема в чем. Эта длл-ка - это длл-ка от стороннего производителя. Она реализует часть функций набора компонент для сжатия файлов ZipTV. В частности, мы используем алгоритм BlackHole для упаковки файлов. От использования этого алгоритма мы отказаться не можем. Этот алгоритм является фирменным закрытым алгоритмом производителя этих компонент для Дельфи. Поэтому переписать нам этот алгоритм не получится. Я пытался найти библиотеку, реализующую этот алгоритм для Линуха. Так и не нашел :(
>2) Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я
>так понял, можно взять бинарную длл-ку без исходников, и WineLib
>может сделать из нее линуховый бинарник?
Так собственно и cделано в mplayer, xine, aviplayer.
>Она реализует часть функций набора компонент для сжатия файлов
>ZipTV. В частности, мы используем алгоритм BlackHole для упаковки
>файлов. От использования этого алгоритма мы отказаться не можем.
>Этот алгоритм является фирменным закрытым алгоритмом производителя
>этих компонент для Дельфи
Ну это совсем такой же случай, как и с плеерами, можно взять
рипнутый вине из любого плеера, который работает с дллками и
написать свой врапер, сошку слинкованную с libwine.a из рипнутого
wine, далее просто пишите свою программу, которая будет работать с
этой либой. Есть только одна проблема, может оказаться так, что в
рипнутой wine не будет нужных виндузячих API функций, тогда придется
их брать из полного wine, или вообще не парится и взять libwine из
полной версии wine сразу, это позволит использовать большое кол-во виндузячих функций, а так же сетевую поддержку.
>>Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я >>так понял, можно взять бинарную длл-ку без исходников, и WineLib >>может сделать из нее линуховый бинарник? >Так собственно и cделано в mplayer, xine, aviplayer. Я тут рылся в документации WineLib и насколько я понял, WineLib позволяет делать Виндовые библиотеки под Линух только при наличии исходников. У меня же исходников длл-ки нет :(.
>Ну это совсем такой же случай, как и с плеерами, можно взять >рипнутый вине из любого плеера, который работает с дллками и >написать свой врапер, сошку слинкованную с libwine.a из рипнутого >wine, далее просто пишите свою программу, которая будет работать с >этой либой. Есть только одна проблема, может оказаться так, что в >рипнутой wine не будет нужных виндузячих API функций, тогда придется >их брать из полного wine, или вообще не парится и взять libwine из >полной версии wine сразу, это позволит использовать большое кол-во >виндузячих функций, а так же сетевую поддержку. Звучит сложно. Но, если другого варианта не будет, то придется так.
Млин, повторюсь, ато получилось непонятно:
>>Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я >>так понял, можно взять бинарную длл-ку без исходников, и WineLib >>может сделать из нее линуховый бинарник? >Так собственно и cделано в mplayer, xine, aviplayer.
Я тут рылся в документации WineLib и насколько я понял, WineLib позволяет делать Виндовые библиотеки под Линух только при наличии исходников. У меня же исходников длл-ки нет :(.
>Ну это совсем такой же случай, как и с плеерами, можно взять >рипнутый вине из любого плеера, который работает с дллками и >написать свой врапер, сошку слинкованную с libwine.a из рипнутого >wine, далее просто пишите свою программу, которая будет работать с >этой либой. Есть только одна проблема, может оказаться так, что в >рипнутой wine не будет нужных виндузячих API функций, тогда придется >их брать из полного wine, или вообще не парится и взять libwine из >полной версии wine сразу, это позволит использовать большое кол-во >виндузячих функций, а так же сетевую поддержку. Звучит сложно.
Собирать при помощи вот такой команды:
На выходе будет файл с названием dllrun.exe, запускать его.
Приветствую, Alexey_VL, вы писали:
Можно озвучить — для чего? Что в той длл такого?
S>Можно озвучить — для чего? Что в той длл такого?
В DLL драйвер под Виндос для устройства на СОМ-порте, который можно самостоятельно написать и под Linux, но это потребует времени. Задача как можно быстрее начать работать с устройством для демонстрации оного. В дальнейшем уже можно будет сделать нормально, написав драйвер под Linux. Ну и вообще для общего развития интересно — неужели нет проги-эмулятора, позволяющей работать с виндовскими длл-ками в Линуксе, с учетом существования WINE
Мафиозная диктатура это нестабильность. Если не мафиозная диктатура, то Конституция и демократия.Здравствуйте, Alexey_VL, Вы писали:
S>>Можно озвучить — для чего? Что в той длл такого?
A_V>В DLL драйвер под Виндос для устройства на СОМ-порте
А оная DLL небось через драйвер COM-порта работает? И как вы собираетесь виндовой DLL лазить в устройство через линуксовый драйвер COM-порта?
Приветствую, Alexey_VL, вы писали:AVL> S>Можно озвучить — для чего? Что в той длл такого?
AVL> В DLL драйвер под Виндос для устройства на СОМ-порте, который можно самостоятельно написать и под Linux, но это потребует времени. Задача как можно быстрее начать работать с устройством для демонстрации оного. В дальнейшем уже можно будет сделать нормально, написав драйвер под Linux.
Советую сразу начинать писать драйвер, емнип там это нетрудно.
А демонстрацию лучше на виндах демонстрируйте, раз уж там готовое есть.
AVL>Ну и вообще для общего развития интересно — неужели нет проги-эмулятора, позволяющей работать с виндовскими длл-ками в Линуксе, с учетом существования WINE
А оно надо? Оно ненадо. Да и вредно.
Здравствуйте, Alexey_VL, Вы писали:
A_V>Я так понимаю, что мне winelib не подойдет, потому что у меня Linux-приложение, которое я не могу скомпилировать как виндовское с помощью Winelib. Исходников dll-ки у меня тоже нет.
Насколько я понимаю, вот эти самые winegcc и wineg++ никоим образом не запрещают использовать обычные линуксовые библиотеки и системные вызовы. Т.е. если собирать программу при помощи winegcc, то можно использовать как WinAPI, так и линуксовые API.
Код, необходимый для инициализации WINE, winegcc генерирует сам.
_>А оная DLL небось через драйвер COM-порта работает? И как вы собираетесь виндовой DLL лазить в устройство через линуксовый драйвер COM-порта?
Хм, а собственно почему виндовой? Я так понимаю WINE подменяет вызовы виндос длл-ок на свои реализации. Думаю kernel32 входит в число длл-ок вызовы которых заменили.
Мафиозная диктатура это нестабильность. Если не мафиозная диктатура, то Конституция и демократия.S>А демонстрацию лучше на виндах демонстрируйте, раз уж там готовое есть.
Суть в том, что продемонстрировать надо работу Linux-программы. Так что виндос тут не подходит.
AVL>>Ну и вообще для общего развития интересно — неужели нет проги-эмулятора, позволяющей работать с виндовскими длл-ками в Линуксе, с учетом существования WINE
S>А оно надо? Оно ненадо. Да и вредно.
Хм, ну мне вот сейчас например надо. И судя по количеству аналогичных вопросов в нете, не только мне. Это может и не здорово для использования как архитектурное решение, но в плане временно поставить стороннюю длл-ку в свое Линукс приложение при портировании очень даже неплохо — можно сразу смотреть что получается.
Мафиозная диктатура это нестабильность. Если не мафиозная диктатура, то Конституция и демократия.LS>Насколько я понимаю, вот эти самые winegcc и wineg++ никоим образом не запрещают использовать обычные линуксовые библиотеки и системные вызовы. Т.е. если собирать программу при помощи winegcc, то можно использовать как WinAPI, так и линуксовые API.
LS>Код, необходимый для инициализации WINE, winegcc генерирует сам.
Угу, дочитал Wine-wiki до ответа на свой вопрос. А если у меня только часть исходников Linux-проги, которая используются для собирания so библиотек — никаких подводных камней не возникнет при стыковке с основной частью приложения, которая собрана обычным gcc?
Мафиозная диктатура это нестабильность. Если не мафиозная диктатура, то Конституция и демократия.Здравствуйте, Alexey_VL, Вы писали:
A_V>Угу, дочитал Wine-wiki до ответа на свой вопрос. А если у меня только часть исходников Linux-проги, которая используются для собирания so библиотек — никаких подводных камней не возникнет при стыковке с основной частью приложения, которая собрана обычным gcc?
Я думаю, чтобы проблем не было, нужно итоговый исполняемый файл линковать при помощи winegcc/wineg++ — чтобы были прилинкованы все нужные библиотеки.
LS>Я думаю, чтобы проблем не было, нужно итоговый исполняемый файл линковать при помощи winegcc/wineg++ — чтобы были прилинкованы все нужные библиотеки.
В итоге нашел все ответы на свои вопросы в Wine-wiki. Спасиб за ссылку Вот похоже наиболее оптимальный подход для решения задачи по использованию длл-ки в Линукс приложении (из Wine-wiki):
A programmer asked Jun 2007 Wine devel]: [How can I write a shared library that uses Wine and can be called from a non-winelib app?]
S. Dossinger: your plugin, that loads the dll, needs to run in Wine's environment in order to be able to load the dll. So you have to write a winelib dll. If the plugin is loaded as a library in your host app, the whole host app would have to be a winelib app. Not good So you can split your plugin into two parts, one is the plugin that runs in the host app, the other one is a seperate winelib application that runs in a seperate process and loads the win32 dll. That way the dll gets the virtual memory setup it needs. The two parts of your plugin can use any Unix IPC techniques you feel like using — sockets, pipes, shared memory, semaphores, whatever. You could forward function calls using pipes, transport bigger blobs using shared memory, and synchronise everything using semaphores(and implicit pipe synchronisation).
Как запускать Windows dll-ку из под Linux
Всем привет!
Проблема следующая: В свое время мы на фирме написали приложение под Виндовс. Теперь стоит задача переписать его под Линух. Проблема в том, что в этом приложении используется длл-ка от стороннего производителя. Исходников длл-ки нет. Поэтому хотел спросить: как можно сделать так, чтобы можно было вызывать функции этой длл-ки из под Линух.Заранее спасибо
Виталий Б.
>Как запускать Windows dll-ку из под Linux
>Всем привет!
>Проблема следующая: В свое время мы на фирме написали приложение под Виндовс.
>Теперь стоит задача переписать его под Линух. Проблема в том, что
>в этом приложении используется длл-ка от стороннего производителя. Исходников длл-ки нет.
>Поэтому хотел спросить: как можно сделать так, чтобы можно было вызывать
>функции этой длл-ки из под Линух.
>
>Заранее спасибо
>
>Виталий Б.Советую посмотреть в сторону Wine. Должен заметить, что
внедрить оную DLLку в Linuxовый процесс вам не удастся.
Либо полностью Виндозное приложение, запускаемое в
эмуляторе, либо Линуксовый процесс, запускающий эмулятор
для выполнения маааленького участка кода, в коем используется
эта DLLка и передающего результат Линуксовому процессу.Успехов!
Я так понял, есть следующие варианты решения моей проблемы:
1) Написать маленькое Виндовс-приложение, которое содержит вызовы к моей Windows длл-ке. Это приложение работает например через командную строку. Опрашивая определенный параметр в коммандной строке приложение вызывает определенную функцию длл-ки. Порядок работы с длл-кой я вижу таким: моя линуховая прога вызывает виндовую прогу через Wine с определенным списком параметров коммандной строки. Виндовая прога дергает нужную функцию длл-ки и возвращает результат (интересно, как?).
2) Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я так понял, можно взять бинарную длл-ку без исходников, и WineLib может сделать из нее линуховый бинарник?
3) Лучшим выходом из положения было-бы переписать длл-ку самостоятельно. Вот только проблема в чем. Эта длл-ка - это длл-ка от стороннего производителя. Она реализует часть функций набора компонент для сжатия файлов ZipTV. В частности, мы используем алгоритм BlackHole для упаковки файлов. От использования этого алгоритма мы отказаться не можем. Этот алгоритм является фирменным закрытым алгоритмом производителя этих компонент для Дельфи. Поэтому переписать нам этот алгоритм не получится. Я пытался найти библиотеку, реализующую этот алгоритм для Линуха. Так и не нашел :(
>Я так понял, есть следующие варианты решения моей проблемы:
>1) Написать маленькое Виндовс-приложение, которое содержит вызовы к моей
>Windows длл-ке. Это приложение работает например через командную строку.
>Опрашивая определенный параметр в коммандной
>строке приложение вызывает определенную функцию длл-ки.
>Порядок работы с длл-кой я вижу таким: моя линуховая прога вызывает
>виндовую прогу через Wine с определенным списком параметров коммандной строки.
>Виндовая прога дергает нужную функцию длл-ки
>и возвращает результат (интересно, как?).Вполне работоспособный вариант. Проблемы будут как раз с обменом данными
между Linux-овой и Windoze-ной частями.
Можно поплясать вокруг временных файлов либо (как бы смешно это ни звучало)
вокруг сокетов семейства AF_INET.>2) Использовать WineLib для перекомпиляции моей виндовой длл-ки. Я так понял, можно
>взять бинарную длл-ку без исходников, и WineLib может сделать из нее
>линуховый бинарник?Как раз это и есть невозможное дело. Употребить WineLib можно _только_
при наличии исходных кодов той части, коя с ним собирается.>3) Лучшим выходом из положения было-бы переписать длл-ку самостоятельно.
>Вот только проблема в чем. Эта длл-ка - это длл-ка от стороннего производителя. Она
>реализует часть функций набора компонент для сжатия файлов ZipTV. В частности,
>мы используем алгоритм BlackHole для упаковки файлов. От использования этого алгоритма
>мы отказаться не можем. Этот алгоритм является фирменным закрытым алгоритмом
>производителя этих компонент для Дельфи. Поэтому переписать нам этот алгоритм не
>получится. Я пытался найти библиотеку, реализующую этот алгоритм для Линуха. Так
>и не нашел :(Типичный пример отсутствия предварительного (до выбора архитектурных и, в данном
случае, алгоритмических решений) анализа направлений развития софта. Здесь можно
сказать нехилое спасибо Wine за то, что он есть. Говоря откровенно, возможность
бинарника для одной ОС функционировать в совершенно другой, реализующей
принципиально другие наборы API - большая редкость.
Игры, созданные с использованием Unity3D для Linux, содержат .dll файлы в папке с данными GameDataFolder/Managed .
Что странно, потому что я думал, что Linux использует .so файлы вместо .dll файлов.
(То же самое относится и к приложениям Android-Unity3D.)
Обратите внимание, что у вас также есть несколько бесплатных приложений (не только игр) на основе Mono Framework, доступных в репозиториях Ubuntu. Например: сорванец.
Также обратите внимание, что расширения файлов, в том числе .dll и .so , не имеют смысла в Linux. Они используются только для нашего удобства. @ray Можешь объяснить? Я думал, что они все еще являются стандартом для передачи информации о типе файла, поэтому не бессмысленны? @FynnMazurkiewicz: Это скорее вопрос слегка отличающихся традиций проектирования, чем одного центрального атрибута, который применяет любая из систем. Фактически, и ядро Windows, и динамический компоновщик Linux с удовольствием загрузят совместно используемую библиотеку (в их соответствующих форматах) независимо от того, оканчивается ли ее имя на .dll или .so или что-то еще. По историческим причинам LoadLibrary в системный вызов Windows , в некоторых случаях будет добавить «.dll» к имени файла , если он не имеет расширение уже, но это не так, как это обычно используется . @ray не совсем: gcc не найдет предоставленную библиотеку, например, -lm если имя ее файла не заканчивается .so или .a или ее версионные варианты.Эти .dll файлы GameDataFolder/Managed принадлежат к родной код программы , которая использует Mono внутренне.
Игровой движок Unity встраивает Mono (даже на большинстве платформ Windows).
Как игровой движок Unity использует Mono
Другие ситуации, когда вы можете увидеть .dll файлы на Ubuntu
Были описаны две ситуации, когда вы можете увидеть .dll файл в Ubuntu:
Есть два других достаточно распространенных случая, когда вы можете увидеть .dll файл в Ubuntu:
Это не попытка исчерпывающего перечисления всех обстоятельств, когда вы можете столкнуться с .dll Ubuntu. (Например, это также может быть библиотека OS / 2. ) Однако я считаю, что эти четыре случая являются наиболее распространенными.
Читайте также: