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

Question

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

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

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

Answer 4

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

Answer 5

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

Answer 6

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