Межпроцессное взаимодействие между 32- и 64-разрядными приложениями в Windows x64

Question

Мы хотели бы поддержать некоторое оборудование, которое недавно было снято с производства.Драйвер для аппаратного обеспечения представляет собой обычную 32-разрядную C DLL.У нас нет исходного кода, и (по юридическим причинам) мы не заинтересованы в декомпиляции или обратном проектировании драйвера.

Аппаратное обеспечение быстро отправляет тонны данных, поэтому протокол связи должен быть довольно эффективным.

Наше программное обеспечение представляет собой собственное 64-разрядное приложение на C ++, но мы хотели бы получить доступ к оборудованию через 32-разрядный процесс.Каков эффективный и элегантный способ взаимодействия 32-разрядных и 64-разрядных приложений друг с другом (который, в идеале, не требует изобретения нового протокола)?

Решение должно быть на C / C ++.

Обновить:несколько респондентов попросили уточнить, был ли это драйвер пользовательского режима или режима ядра.К счастью, это драйвер пользовательского режима.

Answer 1

Если это настоящий драйвер (режим ядра), то вы SOL.Vista x64 не позволяет устанавливать неподписанные драйверы.Если это всего лишь библиотека DLL пользовательского режима, вы можете получить исправление, используя любой из стандартных механизмов IPC.Трубы, розетки, нерабочий КОМ, примерно в таком порядке.Все это работает на скоростях шины, так что до тех пор, пока вы можете буферизировать достаточное количество данных, накладные расходы на переключение контекста не должны слишком сильно сказываться.

Answer 2

Я бы просто использовал сокеты.Это позволило бы вам использовать его по IP, если вам это понадобится в будущем, и вы не будете привязаны к одному API обмена сообщениями.Если в будущем вы захотите реализовать это на другой операционной системе или языке, вы можете.

Answer 3

Эта статья может представлять интерес.В нем обсуждается проблема, а затем предлагается использовать COM в качестве решения.Я не большой поклонник COM, но, учитывая его повсеместное распространение во вселенной Windows, вполне возможно, что он может быть достаточно эффективным.Вероятно, вы захотите спроектировать свое решение таким образом, чтобы можно было выполнять пакетную обработку данных (вы не хотите выполнять один COM-вызов для каждого элемента данных).

Answer 4

Элегантный?C++?Вызовы DCOM / RPC для себя могут сработать, или вы могли бы создать именованный канал и использовать его для обмена данными между двумя процессами (возможно, создать "класс CMessage" или что-то в этом роде), хотя следите за разным выравниванием структуры между x86 и x64.

Answer 5

Если водитель действительно окажется настоящим водителем, нобугз почти прав - вам придется работать намного усерднее, вы не совсем SOL.Одним из решений является установка Win32 на какой-либо другой компьютер (или виртуальную машину), а затем использование какой-либо формы RPC, такой как сокеты (как предложено Pyrolistical) или UDP, или MQ, или даже Tibco Rendezvous (которая утверждает, что поддерживает очень высокую пропускную способность для обработки объемов данных, генерируемых финансовыми рынками - по крайней мере, это то, что я помню по старым временам).

Answer 6

Файл с отображением в память, совместно используемый обеими сторонами, будет иметь одинаковое содержимое.ОС придется выполнить некоторые интересные действия с указателями, чтобы это произошло, но, вполне вероятно, она сможет настроить 2 вида таким образом, чтобы вы физически не копировали память.Нулевые копии - это примерно то же самое, что и получается