En tant que programmeur, de quoi dois-je m’inquiéter lors du passage à des fenêtres 64 bits?

Des articles:

20 problèmes de portage du code C ++ sur la plate-forme 64 bits

Les problèmes oubliés du développement de programmes 64 bits

64 bits, Wp64, Visual Studio 2008, Viva64 et tout le rest …

Détection de pièges lors de la migration du code C et C ++ vers Windows 64 bits

Architecture AMD64 (EM64T)

Et

Outil Viva64 – pour vérifier les programmes 64 bits:

Viva64: qu’est-ce que c’est et pour qui est-ce que c’est?

En ce qui me concerne, le plus important pour porter du code C / C ++ sur Windows 64 bits est de tester votre application avec les allocations MEM_TOP_DOWN activées (valeur de Registre AllocationPreference ) comme décrit dans MEM_TOP_DOWN 4 gigaoctets :

Pour forcer les allocations à allouer des adresses supérieures avant les adresses inférieures à des fins de test, spécifiez MEM_TOP_DOWN lorsque vous appelez VirtualAlloc ou définissez la valeur de Registre suivante sur 0x100000:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\Memory Management\AllocationPreference

Quand est-ce important?

• Si vous avez des fichiers EXE 32 bits créés avec l’option d’éditeur de liens /LARGEADDRESSAWARE (ou qui ont l’indicateur IMAGE_FILE_LARGE_ADDRESS_AWARE dans leurs en-têtes PE par d’autres moyens, tels que editbin.exe ), ils reçoivent 4 Go de données virtuelles. espace d’adressage dans Windows 64 bits, et vous devez les tester avec le jeu de valeurs de Registre AllocationPreference .
• Si vous avez des DLL 32 bits existantes pouvant être chargées par des fichiers EXE de grande taille, vous devez les tester avec le jeu de valeurs de Registre AllocationPreference .
• Si vous recomstackz votre code C / C ++ dans un fichier EXE ou DLL 64 bits, vous devez le tester avec la valeur de Registre AllocationPreference .

Si votre application C / C ++ appartient à l’une de ces trois catégories et que vous ne testez pas avec les allocations MEM_TOP_DOWN , il est très peu probable que le test détecte des bogues de troncature / signature du pointeur dans votre code.

La deuxième chose la plus importante, si vous utilisez MSVC et que vous recomstackz du code C / C ++ pour 64 bits, consiste à utiliser l’option de compilation /Wp64 pour votre version 64 bits :

• Cela amènera le compilateur à émettre des avertissements pour les types de caractères qui tronquent les pointeurs ou à étendre les types entiers plus petits en pointeurs (même si reinterpret_cast ou une dissortingbution de style C est utilisée), ainsi que quelques autres problèmes de portage 64 bits.
• Oui, la documentation indique qu’au lieu de comstackr avec /Wp64 vous devez utiliser un compilateur qui cible une plate-forme 64 bits, mais cela ne suffira pas à résoudre les problèmes de troncature / extension de pointeur au moment de la compilation. L’utilisation d’un compilateur ciblant 64 bits et l’ activation de l’option de compilation /Wp64 pour la génération 64 bits entraînera de nombreux problèmes de troncature / extension au moment de la compilation, ce qui vous fera gagner du temps à long terme.
• Malheureusement, avec MSVC 2008, cela produira également un “avertissement de ligne de commande” pour chaque unité de traduction indiquant que l’option /Wp64 est obsolète. Je peux voir pourquoi l’option est obsolète pour les versions 32 bits (où c’est un hack maléfique qui nécessite l’annotation de nombreux typedefs), mais il est regrettable qu’elle soit également déconseillée pour les versions 64 bits (où elle est réellement utile).

Il peut être plus facile de migrer du code .NET si vous avez 100% de “type code géré sécurisé”. Vous pouvez simplement le copier sur la plate-forme 64 bits et l’exécuter avec succès sous le CLR 64 bits. Vérifiez ce lien MSDN lors de la migration du code managé 32 bits en 64 bits.

Btw, hanselman a blogué sur le sujet récemment.

Si vous parlez de programmes 32 bits, vous n’avez pratiquement rien à craindre, car Windows 64 les exécutera sous forme d’émulation 32 bits. Tout problème avec les futures versions de Windows (par exemple Windows 7) est susceptible d’être une incompatibilité plutôt qu’avec un système d’exploitation 64 bits.

Cependant, si votre code managé est compilé pour la plate-forme cible “Any CPU” et que vous effectuez des appels dans du code non géré (par exemple, PInvoke) ou que vous dépendez d’autres assemblys, il y a certaines choses à savoir. Le post de Scott Hanselman sur le CLR x86 / x64 couvre cela et constitue une bonne explication du CLR sur Win32 / 64.

Lors du développement de programmes natifs 64 bits, le Guide de programmation pour Windows 64 bits est un bon guide. Cela dépend en grande partie des pointeurs et de la taille des types de données 🙂

Les programmes 32 bits fonctionneront bien sur les fenêtres 64 bits. Tant que vous ne faites pas de développement de type pilote de périphérique, bien sûr.

Si vous comstackz votre logiciel en tant que logiciel 64 bits la première fois, vous devez vous occuper de:

• un pointeur a une largeur de 64 bits, tandis qu’un int est de 32 bits. Ne stockez pas de pointeurs en pouces, votre code sera cassé.
• Le processus 64 bits nécessite des DLL 64 bits. Si vous dépendez de DLL tierces, assurez-vous qu’elles sont également fournies en 64 bits. Si vous avez besoin de communiquer entre un processus 32 bits et un processus 64 bits, vous aurez besoin de plusieurs méthodes IPC sous Windows. Les fonctions d’appel directement sont hors de question.
• Les répertoires système sur Windows 64 bits sont différents de ceux sur Windows 32 bits. Si vous avez des chemins d’access codés, vous devrez peut-être les vérifier à nouveau.

Si vous faites l’injection de DLL pour une raison quelconque, vous aurez des problèmes.

Du sharepoint vue C / C ++ ….

Une chose évidente est que la taille d’un int deviendra 8 octets au lieu de 4 octets. Si l’un de vos codes dépend de cela, vous pouvez obtenir des résultats inattendus. Les alignements de structure et variables peuvent être décalés. Vous pourrez peut-être le surmonter avec un pack #pragma, mais je ne parle pas très bien les alignements et les emballages.

Si vous utilisez des unions avec ints, le comportement peut changer.

Si vous utilisez des structures de champs de bits, sur la base de ints, les 32 bits supplémentaires risquent de créer une confusion. Le signe ne sera pas là où vous pensiez que c’était.

Si vous codez des constantes hexadécimales et attendez que les signes deviennent négatifs, vous pouvez avoir des problèmes. L’exemple 0x8000000 est un nombre négatif en tant que journal ou entier 32 bits. 0x80000000 comme un entier sur une plate-forme de 64 bits est un nombre positif. pour définir directement le bit de signe, vous devez utiliser 0x80000000 00000000 (espace intégré pour la lisibilité uniquement)

Aussi, je m’attends à ce que size__t se développe de manière appropriée. Si vous effectuez des allocations basées sur MAX_INT, elles seront beaucoup plus importantes.

Pour éviter ce type d’anomalies de taille, je m’en tiens généralement à des longs plutôt qu’à des ints.

L’émulation 32 bits est-elle vraiment à l’épreuve des balles? J’ai vu que le registre est présenté un peu différemment. Je me demande juste ce que les choses typiques ne fonctionnent pas …

En outre, le répertoire C: \ windows \ SYSTEM32 peut uniquement contenir des DLL 64 bits. Si vous avez une DLL 32 bits, vous devez la placer dans C: \ windows \ syswow64 \