Envelopper une extension de shell COM 32 bits dans un encapsuleur DLL 64 bits «mince»

Le principe:

J’ai une ancienne extension de shell COM 32 bits (écrite en C ++). Après des années d’incompatibilité avec les nouveaux systèmes 64 bits, nous le mettons à jour pour fonctionner dans un environnement Windows 64 bits.

L’astuce:

La DLL COM 32 bits contient des dépendances sur des bibliothèques tierces pour lesquelles aucune version 64 bits n’est disponible . En tant que tel, nous ne pouvons pas simplement recomstackr en 64 bits. Compte tenu de cette ressortingction, nous avons décidé que l’approche la plus simple serait de créer une DLL 64 bits «mince»; essentiellement une DLL vide définissant uniquement les interfaces requirejses et redirigeant tous les appels vers la DLL COM 32 bits sous-jacente.

Je crois que cette communication entre une DLL COM 64 bits et une DLL COM 32 bits est possible, grâce à l’utilisation de substituts COM. Malheureusement, cela semble être un sujet très spécifique / de niche, et je n’ai pas pu trouver beaucoup de ressources sur la façon d’appeler des API COM 32 bits à partir d’une DLL COM 64 bits.

Questions:

  • Est-ce que cette «enveloppe COM mince» est une approche raisonnable pour activer les fonctionnalités 64 bits d’une DLL COM 32 bits?
  • Y a-t-il une raison pour laquelle cette approche ne fonctionnerait pas spécifiquement pour les extensions de shell Windows?
  • Les définitions d’interface 64 bits utiliseraient-elles des GUID identiques à leurs homologues 32 bits?
  • Est-ce une stratégie qui a été documentée dans le passé?
  • Existe-t-il de bonnes ressources pour appeler une API COM 32 bits à partir d’une DLL COM 64 bits?

Clarifications:

Cette question présente un certain nombre d’aspects qui la rendent unique, la distinguant de la question ” Utiliser des extensions shell 32 bits dans Windows 7 64 bits “.

Je ne vous demande pas si une extension de shell 32 bits peut être chargée dans un processus d’exploration 64 bits, comme le fait la question référencée. Je vous demande plutôt s’il est possible de créer une implémentation 64 bits mince de la DLL , qui sert de pont entre le processus de l’explorateur 64 bits et l’implémentation 32 bits.

Pour être clair, ce n’est pas possible .

entrer la description de l'image ici

Mais peut être que c’est ?

entrer la description de l'image ici

Oui, il est faisable avec DCOM et vos pires problèmes seront la configuration des permissions pour le “composant” DCOM et le travail de marshaling des données.

Est-ce que cette «enveloppe COM mince» est une approche raisonnable pour activer les fonctionnalités 64 bits d’une DLL COM 32 bits?

Oui, nous l’avons fait une fois lorsque nous avons dû fournir un serveur COM in-proc avec des implémentations 32 bits et 64 bits. Nous avions essentiellement un tel serveur léger qui serait implémenté à la fois en 32 et 64 bits (le consommateur chargerait le serveur approprié) et redirectait les appels vers un serveur outproc 32 bits hébergé dans DCOM.

Y a-t-il une raison pour laquelle cette approche ne fonctionnerait pas spécifiquement pour les extensions de shell Windows?

Vous ne pourrez peut-être pas définir les permissions de configuration pour le serveur outproc. Très probablement, cela fonctionnera. Ne peut imaginer aucune autre raison.

Les définitions d’interface 64 bits utiliseraient-elles des GUID identiques à leurs homologues 32 bits?

Oui. Une interface COM est un contrat. Vous pouvez avoir autant d’implémentations d’un contrat que vous le souhaitez.

Existe-t-il de bonnes ressources pour appeler une API COM 32 bits à partir d’une DLL COM 64 bits?

Rien de spécial requirejs. Appelez simplement CoCreateInstance() avec CLSCTX_ALL et ça y est.

Votre principale préoccupation sera le marshaling. Vous devez regrouper les données entre le client et le serveur qui seront désormais dans différents processus. Votre meilleur pari est d’utiliser marshaling Automation (aka marshaling typelib). S’il arrive que l’interface d’origine ne soit pas compatible avec l’automatisation, essayez d’introduire une nouvelle interface compatible avec Automation et votre wrapper servira alors d’adaptateur. Il se peut que vous ne puissiez pas concevoir une nouvelle interface compatible avec Automation pour votre tâche, mais essayez ceci car c’est votre meilleur pari.

Lorsque quelque chose ne fonctionne pas – quelque chose ne se mars pas, certains fichiers dépendants ne sont pas trouvés – utilisez Process Monitor pour voir ce qui se passe en échec.

Nous avons une application 64 bits qui utilise avec succès des applications COM 32 bits uniquement (comme celles VB6). Cela semble compliqué, mais pour l’essentiel, il vous suffit d’append quelques entrées de registre pour le composant COM que vous essayez d’utiliser et vous pouvez ensuite l’utiliser. Vous pouvez voir les détails ici:

http://www.gfi.com/blog/32bit-object-64bit-environment/ http://www.codeproject.com/Tips/267554/Using-bit-COM-Object-from-bit-Application

Donc oui, ça va marcher, mais bien sûr, il y a une complexité supplémentaire, et les solutions simples sont généralement les meilleures.

Alternativement, vous pouvez toujours envelopper la fonctionnalité 32 bits en tant que service ou quelque chose du genre et y accéder de cette manière. Ou comme un exécutable et utiliser un fichier texte ou quelque chose pour communiquer.