Puis-je charger une DLL 32 bits dans un processus 64 bits sous Windows ?

Question

J'ai récemment mis à niveau un service Windows c# pour qu'il fonctionne comme un processus .net 64 bits. Normalement, cela devrait être trivial, mais le système utilise une DLL 32 bits écrite en C++. Il n'est pas possible de convertir cette DLL en 64 bits, j'ai donc enveloppé la DLL dans un processus .net 32 bits séparé et exposé une interface .net via remoting.

C'est une solution assez fiable, mais je préférerais faire fonctionner le système comme un seul processus. Existe-t-il un moyen de charger ma DLL 32 bits dans un processus 64 bits et d'y accéder directement (peut-être par le biais d'une sorte de couche de recouvrement) ?

Answer 1

Non, tu ne peux pas.

Windows 16 bits et 32 bits vivaient tous deux dans un espace d'adressage linéaire de 32 bits. Les termes 16 et 32 font référence à la taille du décalage par rapport au sélecteur.

...

Tout d'abord, remarquez qu'un pointeur 16 bits complet et un pointeur plat 32 bits ont la même taille. La valeur 0x0123:0x467 nécessite 32 bits, et wow, il en va de même pour un pointeur de 32 bits. Cela signifie que les structures de données contenant des pointeurs ne changent pas de taille entre leurs homologues 16 bits et 32 bits. Une coïncidence très pratique.

Aucune de ces deux observations ne s'applique au passage de 32 à 64 bits. La taille du pointeur a changé, ce qui signifie que la conversion d'une structure 32 bits en une structure 64 bits et vice versa modifie la taille de la structure . Et l'espace d'adressage 64 bits est quatre milliards de fois plus grand que l'espace d'adressage 32 bits. S'il y a de la mémoire dans l'espace d'adressage 64 bits à l'offset 0x000006fb`01234567, le code 32 bits sera incapable d'y accéder. Ce n'est pas comme si vous pouviez construire une fenêtre d'adresse temporaire, car le code plat 32 bits ne connaît pas ces fenêtres d'adresse temporaires ; ils ont abandonné les sélecteurs, vous vous souvenez ?

http://blogs.msdn.com/oldnewthing/archive/2008/10/20/9006720.aspx

Answer 2

Si votre application .NET est un site web fonctionnant sous IIS, vous pouvez contourner ce problème.

Une page Web ASP.NET exécutée sur IIS sur une machine 64 bits sera hébergée par une version 64 bits du processus w3wp.exe, et si votre page Web utilise des dlls 32 bits, votre site échouera.

Cependant, dans IIS, vous pouvez aller dans les paramètres avancés du pool d'applications qui exécute le site, et changer "Activer les applications 32 bits" en true.

Il n'est donc toujours pas en mesure d'exécuter une dll 32 bits dans un processus 64 bits, mais il exécute plutôt w3wp.exe comme un processus 32 bits.

Answer 3

Si la DLL est emballée sans le code source de la DLL, c'est impossible. Si la même DLL est là avec le code source de la DLL. Par exemple, une DLL .Net avec toute la source construite en x84 qui ne supporte que le processus 32bit. Nous pouvons facilement changer la DLL de 32bit à 64Bit en faisant la propriété de construction du code source du projet à AnyCPU ou X64 environnement de X84. Et enfin le reconstruire.