Нам нужно взаимодействовать со сторонним приложением, но компания, стоящая за приложением, не раскрывает протокол сообщений и предоставляет только Windows DLL для взаимодействия с.
Наше приложение основано на Linux, поэтому я не могу напрямую взаимодействовать с DLL. Я не смог найти никакого существующего решения, поэтому я подумываю написать мост на основе сокетов между Linux и Windows, однако я уверен, что это не такая уж уникальная проблема, и кто-то должен был это сделать раньше.
Известно ли вам какое-либо решение, которое позволяет вызывать функции Windows DDL из приложения C в Linux? Он может использовать Wine или отдельный компьютер с Windows - не имеет значения.
Спасибо заранее.





Вызов самих функций DLL, конечно, только верхушка айсберга. Что, если DLL вызывает Win32, тогда у вас будет довольно серьезная проблема связывания. Думаю, Wine может вам помочь, но не уверен, что они могут предложить решение.
ИМО, лучше всего использовать сокеты. Я делал это раньше, и это работает как шарм.
Это была моя первоначальная идея. Похоже, я должен идти именно так.
Любое решение будет нуждаться в уровне «удаленного взаимодействия» на основе TCP / IP между DLL, которая работает в «Windows-подобной» среде, и вашим Linux-приложением.
Вам нужно будет написать простое приложение для ПК, чтобы предоставлять функции DLL, либо с использованием домашнего протокола, либо, возможно, протоколов XML-RPC, SOAP или JSON. RemObjects SDK может вам помочь, но может оказаться излишним.
Я бы остановился на «реальном» или виртуализированном ПК. Если вы используете Wine, разработчики DLL вряд ли предложат какую-либо поддержку.
MONO также вряд ли поможет, потому что ваша DLL, вероятно, НЕ является сборкой .NET.
Иногда лучше выбрать небольшого поставщика, а не крупного, потому что размер вашего бизнеса дает вам больший вес для них. Мы определенно обнаружили это у поставщиков AV-двигателей.
Если вы достаточно важны для них, они должны предоставить либо документированный поддерживаемый протокол, либо сборку библиотеки Linux, либо исходный код библиотеки.
В противном случае вам придется запускать окно Windows в цикле с использованием RPC, как отмечали другие, что, вероятно, будет очень неудобно, особенно если вся остальная часть вашей инфраструктуры работает под Linux.
Будет ли поставщик поддерживать использование своей библиотеки в виртуальной машине Windows? Если производительность не критична, возможно, вы сможете это сделать.
Прошло несколько лет с тех пор, как этот вопрос был задан, но вот другой подход. Используйте objdump -d, чтобы разобрать DLL. Вы можете получить чистый, необработанный мусор, код, полный вызовов Windows, или и то, и другое. Функции часто ограничиваются серией инструкций push и заканчиваются инструкцией ret.
Хотя этот вопрос довольно старый, тема, видимо, не потеряла своей актуальности. Если вы можете использовать или используете Python ... вот мое решение.
Я написал небольшой модуль Python для вызова библиотек DLL Windows из Python в Linux. Он основан на IPC между обычным процессом Python для Linux / Unix и процессом Python на основе Wine. Поскольку мне он сам нуждался в слишком большом количестве различных сценариев / сценариев использования, я разработал его как «общую» заменяющую замену ctypes модуль, которая выполняет большую часть необходимой сантехники автоматически в фоновом режиме.
Пример: предположим, что вы используете Python в Linux, у вас установлен Wine и вы хотите вызвать msvcrt.dll (библиотека времени выполнения Microsoft C). Вы можете сделать следующее:
import zugbruecke as ctypes
dll_pow = ctypes.cdll.msvcrt.pow
dll_pow.argtypes = (ctypes.c_double, ctypes.c_double)
dll_pow.restype = ctypes.c_double
print('You should expect "1024.0" to show up here: "%.1f".' % dll_pow(2.0, 10.0))
Исходный код (LGPL), Пакет PyPI и документация.
Он все еще немного грубоват (т.е. альфа и небезопасен), но он обрабатывает большинство типов параметров (включая указатели).
В прошлый раз, когда я проверил, WINE можно было использовать только для размещения процессов, а не отдельных DLL внутри процесса, отличного от WINE.