Chargement/interaction avec une DLL COM vb6 à partir d'une application 64 bits

Question

Je travaille sur une application qui contient plus de quelques DLL écrites en VB6. Le code VB6 inclut les DLL COM et les contrôles ocx. Le reste du code est en C++ et C#. On m'a assigné la tâche de rendre la base de code d'application compatible avec les architectures 64 bits. Des charges de matériel d'aide sont disponibles pour le code C/C++ donc ce n'est pas un problème à portée de main. Mais il n'est pas facile de réécrire tout ce code vb6 en .net ou dans une autre langue pour le rendre compatible avec 64bit. Je ne comprends pas non plus toute la logique sous-jacente, donc supposons simplement que la réécriture est hors de question. D'autre part, nous savons tous que les dll VB6 ne fonctionneront pas dans un environnement 64 bits. Alors, quelles sont mes options.

1) convertir chaque dll en un EXE qui sera chargé en 32 bits et il peut interagir avec mon reste d'application 64 bits via des interfaces COM. Prévoyez-vous des problèmes avec cette approche?

2) Je modifie le registre et charge toutes les DLLs VB6 hors processus, les charge dans dllhost. 3) Faire un seul exe 32 bits, renvoyer tous ces dll VB6 dans cet exe et charger cet exe dans l'espace d'adressage 32 bits et la partie 64 bits de mon application communique avec l'exe 32 bits.

Le problème majeur qui vient à l'esprit avec toutes les approches mentionnées ci-dessus est quoi faire avec les contrôles OCX ????

Des idées? Si aucune nouvelle idée que celle mentionnée ci-dessus ne sera préférée par vous et pourquoi?

Answer 1

Si vous avez beaucoup de code VB6 existant qui fonctionne en cours de traitement, je vous demanderais d'abord si la migration en 64 bits en vaut vraiment la peine. 64 bits présente de nombreux avantages pour les applications serveur, mais pour les applications de bureau, 32 bits est souvent suffisant. Et comme on peut s'attendre à ce que WOW64 soit disponible pendant au moins une décennie, il y a peu d'arguments contre l'exécution d'applications 32 bits sur Windows 64 bits. Le point est, bien qu'il soit possible qu'en utilisant des serveurs externes, vous puissiez modifier votre application pour qu'elle fonctionne au moins partiellement en mode 64 bits, cela aura probablement un impact significatif sur les performances (et aussi sur les frais généraux de mémoire). Les chances sont que le client n'a donc absolument aucun avantage à choisir la version 64 bits de votre application.

Cela dit, je dirais 2) ou 3) serait le choix naturel. 2) est certainement plus facile à implémenter, mais 3) vous donne plus de contrôle sur le nombre de serveurs out-or-process qui doivent être créés et comment leur durée de vie est gérée.

Answer 2

Je migre de SQL 2000 x86 vers SQL 2008 x64.

Ici, nous sommes confrontés à un problème similaire. J'ai décidé d'utiliser DCOM.

Comment ça marche?

Un serveur 32 bits hébergera l'ensemble et la machine 64 bits appellera en utilisant DCOM.

Il y a une pénalité de performance. BTW, l'effort par rapport à la réécriture ... mérite certainement d'être fait. :)

Cordialement, Marcos Lima