Загрузка 32 bit DLL в 64 bit DLL

Доброго дня,

в своем предыдущем посту я озадачивался вопросом о том, как можно прикрутить DLL файл в проект visual studio, для доступа к функциям библиотеки. Получил очень хороший ответ, разобрался в нем и реализовал небольшое консольное приложение для тестирование функциональности DLL.

Как же в последствии выяснилось, библиотека существует только в 32 разрядном виде и возможностей генерирования у разработчиков этой библиотеки, ее в 64 bit не существует в принципе.

По моему заданию мне нужно разработать 64 bit DLL (своего рода компонентный блок типа блока из simulink), в котором будут реализована вся функциональность 32 битной предоставленной мне библиотеки.
То есть как ни крути, а грузить ее в 64 битный процес надо...

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

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

Может кто-нибудь из форумчан сталкивался с подобной задачей и имеет некоторые наработки в ней?

Мне как новичку в c++ довольно сложно разобраться со статьей:
http://blog.mattmags.com/2007/... -bit-code/

чтобы тотчас же применить на практике теоретический рецепт.

0

Не проще будет написать приложение-обёртку и общаться с ним по любому удобному IPC?

Добавлено через 49 секунд
Проглядел по диагонали статью по ссылке, там как раз об этом и говорят.

0

Сообщение от NoMasters Не проще будет написать приложение-обёртку и общаться с ним по любому удобному IPC? Добавлено через 49 секунд Проглядел по диагонали статью по ссылке, там как раз об этом и говорят.

Так вот в том то вся и проблема, что не хватает для этого опыта, примера же найти не смог...
И, как следствие, обратился к более опытному сообществу...

0

Сообщение от ustus_alex По моему заданию мне нужно разработать 64 bit DLL (своего рода компонентный блок типа блока из simulink), в котором будут реализована вся функциональность 32 битной предоставленной мне библиотеки. То есть как ни крути, а грузить ее в 64 битный процес надо.

Грузить 32-битную dll в 64-битный процесс ? Забудьте.

Сообщение от ustus_alex Несколько дней курил мануалы на просторах msdn, stackoverflow и других ресурсов, но так и не нашел реализованного решения, в виде небольшого примера как это делается.

Соберите библиотеку под платформу x64.
Для ее клиентов это будет наилучшим вариантом, чем всякие грабли в
виде суррогатных процессов, IPC и прочего.

1

с MSDN

A 32-bit DLL cannot be injected into a 64-bit process, and a 64-bit DLL cannot be injected into a 32-bit process.

0

Сообщение от Убежденный Грузить 32-битную dll в 64-битный процесс ? Забудьте. Соберите библиотеку под платформу x64. Для ее клиентов это будет наилучшим вариантом, чем всякие грабли в виде суррогатных процессов, IPC и прочего.

в том то и проблема, что библиотеку 32bit не перекомпилировать в 64bit, так как даже у ее разработчиков нет исходного кода на с++. A, все из-за того, что библиотека генерируется одной очень редко распространненой программой на основе заложенной туда математической модели (что то вроде модели из блоков в matlab simulink) и программа эта доступна только в 32 битном виде и в ней нет заложенных функций генерации 64 битной библиотеки.
Отсюда и мучения с поисками примеров создания суррогатных процессов.
Без них мне никак не обойтись..

0

Сообщение от ustus_alex Так вот в том то вся и проблема, что не хватает для этого опыта, примера же найти не смог...

Опыта обмена данными между процессами? В простейшем варианте делов-то передать входные данные и забрать выходные.
Между тем, что мешает собирать основную софтину только под 32 бита? Пользователям проприетарщины не привыкать.

0

Сообщение от NoMasters Опыта обмена данными между процессами? В простейшем варианте делов-то передать входные данные и забрать выходные. Между тем, что мешает собирать основную софтину только под 32 бита? Пользователям проприетарщины не привыкать.

Да, именно так, опыта в межпроцессорном взаимодействии нет вообще.
И, до прошлой недели, не было вообще никакого опыта с работой с dll файлами.
Но, как говорится опыт дело наживное... особенно в условиях поставленной задачи.
Основную софтину 32 битную не взять, доступна только 64 битная...
Конечными же пользователями является только мой отдел.
Отсюда и столько никому не нужных заморочек.
Ну, а чтобы было понятнее, что за задача стоит..
Есть программа похожая отдаленно на симулинк, каждой компонент который называется фильтром(dll файл).
мне нужно из ранее написанного фильтра (64 bit ) получить в мой фильтр (64 bit ) поток данных с CAN шины, в потоке выделить нужный сигнал и произвести с ним цифровую обработку на основе предоставленной мне ранее dll (32 bit) , результат анализа передать в следующий за моим фильтром фильтр (64bit) .

0

Сообщение от ustus_alex в том то и проблема, что библиотеку 32bit не перекомпилировать в 64bit, так как даже у ее разработчиков нет исходного кода на с++.

Тогда Вам нужно сделать примерно следующее - собрать 64-битную версию dll-ки с точно
таким же API, как у 32-битной, чтобы 64-битные клиенты могли ее свободно загружать и
использовать, а настоящую 32-битную версию dll-ки загрузить в свой 32-битный процесс.
А потом наладить передачу данных между 64-битной dll-кой, загруженной в клиентский
64-битный процесс, и 32-битной dll-кой, загруженный в свой 32-битный процесс.

Последовательность вызовов в этом случае будет такой: клиент (64-бит), загрузив
64-битную dll-ку, будет вызывать оттуда некоторые функции, но реально эти функции
будут всего лишь "заглушками", которые сериализуют данные и передают вызов в
32-битный процесс, в который загружена настоящая 32-битная dll. В этом процессе
вызываются настоящие функции и выполняется реальная работа, после чего параметры
сериализуются обратно, в вызывающий процесс, и в итоге клиент получает результат.
Все так, как если бы он загружал настоящую 64-битную dll, если бы она существовала.

Не факт, что это удастся так легко реализовать. Например, если какая-то функция dll
возвращает указатель, Вам нужно будет воссоздать объект, на который он указывает, в
контексте вызывающего процесса. Есть и другие потенциальные проблемы - с синхронизацией,
например, или правами доступа к объектам.

1

Сообщение от Убежденный Тогда Вам нужно сделать примерно следующее - собрать 64-битную версию dll-ки с точно таким же API, как у 32-битной, чтобы 64-битные клиенты могли ее свободно загружать и использовать, а настоящую 32-битную версию dll-ки загрузить в свой 32-битный процесс. А потом наладить передачу данных между 64-битной dll-кой, загруженной в клиентский 64-битный процесс, и 32-битной dll-кой, загруженный в свой 32-битный процесс. Последовательность вызовов в этом случае будет такой: клиент (64-бит), загрузив 64-битную dll-ку, будет вызывать оттуда некоторые функции, но реально эти функции будут всего лишь "заглушками", которые сериализуют данные и передают вызов в 32-битный процесс, в который загружена настоящая 32-битная dll. В этом процессе вызываются настоящие функции и выполняется реальная работа, после чего параметры сериализуются обратно, в вызывающий процесс, и в итоге клиент получает результат. Все так, как если бы он загружал настоящую 64-битную dll, если бы она существовала. Не факт, что это удастся так легко реализовать. Например, если какая-то функция dll возвращает указатель, Вам нужно будет воссоздать объект, на который он указывает, в контексте вызывающего процесса. Есть и другие потенциальные проблемы - с синхронизацией, например, или правами доступа к объектам.

Да уж, чувствую с последним абзацем задача становится вообще практически невыполнимой...
Одна из функций в dll возвращает указатель на структуру, содержащую в себе элементы с указателями на другую структуру, а другая структура сожержит еще один указатель типа : const char * name.
Чтобы вывести значение этого указателя на константу, содержащего в себе информацию зашитую в dll о названии входов и выходов, мне потребовалось два дня эксперементов и чтения книг...

0

Сообщение от ustus_alex Да уж, чувствую с последним абзацем задача становится вообще практически невыполнимой.

Технология COM умеет решать такие проблемы, там данные легко могут передаваться
через границы процессов любой разрядности, причем сами процессы могут быть
запущены на разных машинах... Но для этого Ваша dll-ка сама должна быть
COM-объектом, использовать только COM-совместимые типы и иметь библиотеку
типов (tlb), иначе ничего не выйдет.

1

Тоже стало интересно как такое сделать.

Сообщение от ustus_alex Мне как новичку в c++ довольно сложно разобраться со статьей: https://blog.mattmags.com/2007... -bit-code/

Да там нету примеров через что крутить и с чего начать.

0

Сообщение от Убежденный Технология COM умеет решать такие проблемы, там данные легко могут передаваться через границы процессов любой разрядности, причем сами процессы могут быть запущены на разных машинах... Но для этого Ваша dll-ка сама должна быть COM-объектом, использовать только COM-совместимые типы и иметь библиотеку типов (tlb), иначе ничего не выйдет.

как создать библиотеку COM?

0