Communication interprocessus entre applications 32 et 64 bits sous Windows x64

Question

Nous souhaitons prendre en charge certains matériels qui ont été récemment arrêtés. Le pilote du matériel est une DLL C 32 bits simple. Nous n'avons pas le code source, et (pour des raisons légales) ne sommes pas intéressés par la décompilation ou l'ingénierie inverse du driver.

Le matériel envoie des tonnes de données rapidement, de sorte que le protocole de communication doit être assez efficace.

Notre logiciel est une application C++ 64 bits native, mais nous aimerions accéder au matériel via un processus 32 bits. Qu'est-ce qui est un moyen efficace et élégant pour que les applications 32 bits et 64 bits communiquent les unes avec les autres (ce qui, idéalement, n'implique pas l'invention d'un nouveau protocole)?

La solution devrait être en C/C++. Mise à jour: plusieurs répondants ont demandé des précisions pour savoir s'il s'agissait d'un pilote en mode utilisateur ou en mode noyau. Heureusement, c'est un pilote en mode utilisateur.

Answer 1

S'il s'agit d'un vrai pilote (mode kernel), vous êtes SOL. Vista x64 n'autorise pas l'installation de pilotes non signés. Il s'agit juste d'une DLL en mode utilisateur, vous pouvez obtenir une solution en utilisant l'un des mécanismes IPC standard. Tuyaux, douilles, COM hors-service, à peu près dans cet ordre. Tout fonctionne sur les vitesses de bus, aussi longtemps que vous pouvez tamponner suffisamment de données, la surcharge du commutateur de contexte ne devrait pas trop nuire.

Answer 2

This article peut être d'intérêt. Il discute du problème et suggère ensuite d'utiliser COM comme solution. Je ne suis pas un grand fan de COM mais vu son omniprésence dans l'univers Windows, il est possible que ce soit assez efficace. Vous voudrez probablement architecturer votre solution de sorte que vous puissiez traiter des données par lots (vous ne voulez pas faire un appel COM pour chaque élément de données).

Answer 3

Élégant? C++? Les appels DCOM/RPC peuvent fonctionner, ou vous pouvez créer un canal nommé et l'utiliser pour parler entre les deux processus (créer une classe CMessage, par exemple), mais attention à l'alignement des structures entre x86 et x64.

Answer 4

Je voudrais juste utiliser des douilles. Il vous permettra de l'utiliser sur IP si vous en avez besoin dans le futur, et vous ne serez pas lié à une seule API de messagerie. Si dans le futur vous souhaitez implémenter ceci sur un autre système d'exploitation ou une autre langue, vous pouvez le faire.

Answer 5

Si le pilote s'avère être un vrai pilote, nobugz a presque raison - vous allez devoir travailler beaucoup plus fort, vous n'êtes pas complètement SOL. Une solution consiste à installer Win32 sur une autre machine (ou une machine virtuelle) et à utiliser une forme de RPC, comme des sockets (comme suggéré par Pyrolistical) ou UDP ou MQ ou même Tibco Rendezvous (qui prétend supporter un très haut débit pour pour gérer les volumes de données générés par les marchés financiers - du moins c'est ce dont je me souviens dans le passé).

Answer 6

Un fichier mappé en mémoire, partagé par les deux côtés, aurait le même contenu. Le système d'exploitation devra faire quelques trucs de pointeurs intéressants pour y arriver, mais il sera probablement capable de configurer les 2 vues de telle sorte que vous ne copiez pas physiquement la mémoire. Le nombre de copies est à peu près aussi élevé que possible