Garantir qu’un programme écrit pour Windows 32 bits est compatible avec Windows 64 bits

La meilleure explication que j’ai trouvée ici est celle qui dit essentiellement que les programmes 32 bits sont exécutés sur une couche d’émulation qui n’autorise pas l’access au système que vous obtenez des programmes natifs exécutés dans un environnement 64 bits:

http://blogs.msdn.com/oldnewthing/archive/2008/12/22/9244582.aspx

Je suppose que cela signifie que les problèmes avec des programmes tels que GTA4 proviennent de la couche d’émulation ne produisant pas les résultats attendus sur un système natif 32 bits. C’est pourquoi vous continuez à voir les mises à jour de compatibilité des versions Microsoft en permanence.

Voici ce que le MSDN a à dire à ce sujet:

http://msdn.microsoft.com/en-us/library/bb427430(VS.85).aspx

Il y a beaucoup de désinformation sur ce sujet.

Lorsqu’une application 32 bits est exécutée sur des fenêtres 64 bits:

• La plupart des problèmes de compatibilité surviennent lorsque l’application tente d’installer un pilote en mode kernel. Un pilote 32 bits ne peut pas être installé sur le système d’exploitation 64 bits. C’est certainement le problème avec un pare-feu. Il essaie de se connecter à la stack de pilotes TCP / IP.
• IL N’Y A PAS D’ÉMULATEUR! Le code object 32 ​​bits est exécuté par le processeur complètement en mode natif à pleine vitesse.
• Il n’y a pas de support pour l’ancien code 16 bits. Cela a brisé beaucoup d’installateurs.
• L’access aux bons dossiers n’est généralement pas un problème. Lorsqu’un programme 32 bits ouvre un fichier, par exemple% windir% \ system32 \, le système d’exploitation le redirige automatiquement vers% windir% \ syswow64. La même chose pour certaines parties du registre. Il y a quelques pièges potentiels ici, mais ils vont généralement dans le sens que diverses fonctions WINAPI Get … Directory () renvoient les mêmes chaînes que dans Windows 95.
• Qu’il ait été compilé il y a 10 ans ou juste hier, les pointeurs C / C ++ sont toujours 32 bits (4 octets) et tout le code qui vient de supposer cela – y compris SendMessage ()! — fonctionne encore. Le problème du pointeur sur 8 octets n’apparaît pas dans l’image jusqu’à ce que vous commenciez à convertir en compilateurs 64 bits.

Les pilotes sont une autre histoire que les programmes: http://support.microsoft.com/kb/896456

Zone Alarm utilise un pilote spécial de 32 bits créé par Check Point pour effectuer la surveillance. C’est probablement ce qui crée le problème avec cette application. Quant à Grand Theft Auto 4? Je n’ai aucune idée.

Il peut y avoir un certain nombre de raisons.

Toute application qui est programmée à un niveau bas peut s’attendre à un registre de 32 bits. Le pilote Zone Alarm publié par novatrust est un bon exemple. GTA4 utilise peut-être assembly pour améliorer les performances à plusieurs points, ce qui peut entraîner quelque chose ou même simplement en supposant 32 bits sur C ++. Par exemple, prenez le code suivant:

struct GPoint { int x; int y; } // Array of twenty GPoints GPoint[] myArr = malloc(20 * sizeof(GPoint); GPoint* myPointer = myArr; int index = GetIndexAffectedPoint(); // Invert X and Y for the point myPointer += 8*index; swap(myPointer); 

Je sais que l’exemple est assez naïf, mais de toute façon, dans ce code, vous supposez que struct est long de 8 octets (4 octets de l’entier x et 4 octets pour l’entier y) mais dans un système 64 bits est en réalité deux fois plus long vous finirez par échanger le mauvais point … des choses comme ça se produisent souvent sur des langages de bas niveau, surtout lorsque vous essayez d’améliorer les performances …

Les applications de sécurité sont un mauvais exemple. Ils exécutent tous des choses non sockets en charge contre les choses non documentées. Les changements entre une version 32 bits de Windows et la suivante sont suffisants pour les briser, ne pas passer à la version 64 bits.

Cela dit, il existe des correctifs de compatibilité qui corrigent votre code sur 32 bits, ce qui n’est pas le cas lorsque l’application est 64 bits . C’est parce que Microsoft suppose que vous l’avez testé sur 64 bits.

Un résultat obtenu est avec les applications .NET . Lorsqu’il est exécuté sur un système 32 bits, l’exe est jeté sur 32 bits – où il y a des cales de compatibilité pour réparer vos bogues. Si votre client s’exécute sur un système 64 bits, l’exécutable sera jeté sur 64 bits, où les shims de compatibilité qui vous étaient protégés ne sont plus présents.

Chris Jackson a eu un bon blog à ce sujet: Shimming Applications sur Windows Vista 64 bits

Le problème est probablement les pilotes. Avec les jeux, il s’agit probablement d’une sorte de système DRM visqueux. Essayez d’obtenir le crack sans CD pour le jeu afin de pouvoir l’exécuter sans DRM.

Considérations relatives à la migration de 32 à 64 bits

EDIT : Lien alternatif

Si vous utilisez le système de fichiers ou le registre, vérifiez que vous accédez aux bons dossiers . En tant que programme x86, vous souhaiterez probablement accéder à “Program Files (x86)”, “SysWOW64”, “WOW6232Node” et à de tels dossiers au lieu de x64.

Les produits avec des applications x86 telles que Norton et Zone Alarm de Check Point ne parviennent pas à exécuter leur pilote x86, car le pilote doit x64 pour pouvoir être exécuté par le système d’exploitation.