Le code écrit sous Vista 64 est-il compatible sur un système d'exploitation 32 bits ?

Question

Nous recevons de nouvelles machines de développement et passons à Vista 64 Ultimate pour profiter de nos 8 Go de RAM.Notre responsable veut que nous fassions tous les développements sur des machines virtuelles 32 bits pour nous assurer qu'il n'y aura aucun problème avec la mise en production de notre code.

Existe-t-il un moyen de garantir que les programmes résultants fonctionneront sur les systèmes d'exploitation 32 bits ?Cela ne me dérange pas d'utiliser des machines virtuelles, mais je n'aime pas la façon dont elles vous forcent à revenir dans une vue de type moniteur "unique".J'aime déplacer mes barres d'outils VS vers mon autre moniteur.

MODIFIER:Nous utilisons Visual Studio 2005 et 2008, VB.NET et/ou C#

MODIFIER:Utiliser Harpreet répondre, voici les étapes que j'ai utilisées pour configurer mon IDE Visual Studio pour compiler x86/32 bits :

1. Cliquez sur Créer et ouvrez le Gestionnaire de configuration
2. Sélectionnez la liste déroulante Plateforme de solution active
3. Sélectionnez x86 s'il est dans la liste et passez à l'étape 5, sinon sélectionnez <New...>
4. Dans la boîte de dialogue Nouvelle plateforme de solution, sélectionnez x86 et appuyez sur OK.
5. Vérifiez que la plateforme sélectionnée pour tous vos projets est x86
6. Cliquez sur Fermer.

Apprécier.

Merci, Keith

Answer 1

Je fais du développement sur des machines 64 bits pour Windows 32 bits.Ce n'est pas un problème.Vous devez vous assurer que vos projets sont configurés pour être compilés en mode x86 afin d'être conservateur.Vous voudrez parcourir chaque projet de la solution et vérifier cela.Vous pouvez également utiliser le paramètre AnyCPU, mais c'est un peu plus risqué car il fonctionnera différemment sur votre machine de développement qu'une machine 32 bits.Vous voulez bien sûr éviter le mode 64 bits.

Les problèmes que j'ai rencontrés sont des pilotes qui ne fonctionnent pas lorsque l'application est compilée pour 64 bits (explicitement 64 bits ou AnyCPU compilé et exécuté sur Windows 64 bits).Ces problèmes sont complètement évitables en s'en tenant à la compilation x86.Cela devrait révéler toutes les failles de vos machines de développement.

Idéalement, vous pourriez configurer un environnement de construction et de test qui pourrait être exécuté fréquemment sur une machine 32 bits.Cela devrait rassurer votre direction et vous permettre d'éviter la VM comme bureau.

Answer 2

Tant que vous compilez vos exécutables en 32 bits, ils fonctionneront sur les machines Windows 32 bits et 64 (garanti).L'utilisation de machines de développement 64 présente l'avantage de pouvoir commencer à tester votre code avec une compilation 64 bits (pour vérifier des éléments tels que des pointeurs convertis en entiers 32 bits), facilitant ainsi la transition vers 64 bits à l'avenir (si votre entreprise choisit faire une version 64 bits).

Answer 3

La compilation pour un système d'exploitation 64 bits est une option du compilateur.Vous pouvez absolument compiler un exe 32 bits à partir de Vista 64 bits.Lorsque vous exécutez l'application, vous pouvez alors voir dans le TaskManager qu'il y a un "*32" à côté du processus... cela signifie qu'il est en 32 bits ;)

Je pense que vos managers ont besoin de plus d'éducation sur ce que signifie réellement le système d'exploitation 64 bits :)

Answer 4

Pas une réponse à votre question, mais peut-être une solution à votre problème :VirtualBox (et probablement d'autres) prend en charge le mode "intégration transparente", qui vous donne simplement une deuxième barre de démarrage et vous permet de faire glisser les fenêtres librement.

De plus, et c'est une réponse à votre question, cela dépend de vos paramètres de compilation.Vous pouvez compiler pour différents environnements et vous pouvez parfaitement compiler des programmes 32 bits sur un système 64 bits avec Visual Studio.Je ne peux pas vous dire comment, mais je suis sûr qu'un gourou de Visual Studio pourrait vous aider.

Answer 5

Nous développons une application 32 bits utilisant VS 2005 (bientôt 2008) et venons d'acheter de nouvelles machines avec XP Pro x64 ou Vista Business 64 bits afin de pouvoir profiter de la RAM supplémentaire tout en gardant un œil sur le possibilité de faire un portage 64 bits si cela devient commercialement nécessaire.Nous n'avons eu aucun problème avec cela, à part peaufiner certains scripts dans notre environnement de développement, etc.

Les développeurs qui n'ont pas été inclus dans ce cycle de mise à niveau utilisent toujours des machines 32 bits, ceux-ci devraient donc rencontrer des problèmes lorsque les tests unitaires et la suite de tests d'application sont exécutés systématiquement avant un enregistrement.

Ce que nous faisons également, c'est nous assurer que nous disposons d'un ensemble de machines de « construction de test » composées de configurations « typiques » (XP/Vista, 2/4/8 cœurs, etc.) qui construisent et testent des ensembles d'enregistrements. - nous disposons de différentes suites de tests pour la stabilité, les performances, etc.- avant leur ajout à la zone d'intégration proprement dite.Encore une fois, ceux-ci n’ont rencontré aucun problème lors de l’exécution d’une application 32 bits construite sur un système d’exploitation 64 bits.

Quoi qu'il en soit, comme d'autres l'ont déjà dit, je ne m'attendrais pas à ce que ce soit un problème car c'est le compilateur qui génère le code approprié pour le système d'exploitation cible, quel que soit le système d'exploitation sur lequel le compilateur s'exécute réellement.

Answer 6

ouais, comme Adam le disait.Il y a 3 options :MSIL (par défaut), x64 et x86.Vous pouvez cibler x64 et il générera des DLL spécifiquement pour les systèmes 64 bits, ou vous pouvez créer x86 qui fonctionnera sur 32 bits et 64 bits, mais aura les mêmes restrictions que 32 bits sur un système 64 bits.

MSIL laissera essentiellement le JITer émettre l'instruction spécifique à la plate-forme (avec une légère pénalité de performances par rapport à une image native)

MODIFIER:pas de langage, donc je parle de langages framework .net comme vb.net et c#, c++ est un animal complètement différent.

Answer 7

J'ai trouvé ça aujourd'hui :

http://www.brianpeek.com/blog/archive/2007/11/13/x64-development-with-net.aspx

Développement x64 avec .NET

Plus tôt cette année, j'ai opté pour un système d'exploitation 64 bits - Vista Ultimate x64 pour être exact.Pour l'essentiel, ce processus a été relativement indolore, mais il y a eu quelques ratés en cours de route (pilotes compatibles x64, principalement, mais ce n'est pas le but de cette discussion).

Dans le monde du développement x64, il y a eu quelques points difficiles que j'ai pensé souligner ici.Cette liste va probablement s'allonger, alors attendez-vous à de futurs articles sur le sujet.

Dans le monde merveilleux du développement .NET, les applications et les assemblys peuvent être compilés pour cibler diverses plates-formes.Par défaut, les applications et les assemblys sont compilés en tant que Any CPU dans Visual Studio.Dans ce scénario, le CLR chargera l’assembly quelle que soit la cible par défaut de la machine sur laquelle il est exécuté.Par exemple, lors de l'exécution d'un exécutable sur une machine x64, il sera exécuté comme un processus 64 bits.

Visual Studio fournit également 3 cibles de plateforme spécifiques :x86, x64 et Itanium (IA-64).Lors de la création d'un exécutable en tant que cible spécifique, il sera chargé en tant que processus de ce type.Par exemple, un exécutable ciblé x86 exécuté sur une machine x64 s'exécutera en tant que processus 32 bits utilisant la couche CLR 32 bits et WOW64.Lorsque les assemblys sont chargés au moment de l'exécution, ils ne peuvent être chargés par un processus que si leur cible correspond à celle du processus d'hébergement ou si elle est compilée en tant que Any CPU.Par exemple, si x64 a été défini comme cible d’un assembly, il ne peut être chargé que par un processus x64.

Cela est entré en jeu dans quelques scénarios pour moi :

• XNA - XNA est disponible uniquement sous la forme d'un ensemble d'assemblys 32 bits.Par conséquent, lors du référencement des assemblys XNA, l’exécutable/l’assembly qui les utilise doit être ciblé sur la plate-forme x86.S'il est ciblé comme x64 (ou comme Any CPU et exécuté sur une machine 64 bits), une erreur sera générée lors de la tentative de chargement des assemblys XNA.

• Microsoft Robotics Studio - Le XInputGamepadService utilise XNA en interne pour communiquer avec le contrôleur Xbox 360.Voir au dessus.

• DirectX géré - Bien que ce soit déjà obsolète et remplacé par XNA, il a toujours son utilité.Les assemblys ne sont pas marqués pour une cible spécifique, cependant j'ai eu des difficultés avec les exceptions de mémoire, notamment avec l'assembly Microsoft.DirectX.AudioVideoPlayback.

• Phidgets - Selon la bibliothèque que vous téléchargez et quand, elle peut ou non être marquée comme 32 bits uniquement.La version actuelle (11/8/07) est marquée comme telle et nécessite donc un processus 32 bits pour l'héberger.Le moyen le plus simple de déterminer si un exécutable ou un assembly est destiné à une plate-forme spécifique consiste à utiliser l'application corflags.Pour l'utiliser, ouvrez une invite de commande Visual Studio à partir de votre menu Démarrer et exécutez-la sur l'assembly que vous souhaitez vérifier.

Le moyen le plus simple de déterminer si un exécutable ou un assembly est destiné à une plate-forme spécifique consiste à utiliser l'application corflags.Pour l'utiliser, ouvrez une invite de commande Visual Studio à partir de votre menu Démarrer et exécutez-la sur l'assembly que vous souhaitez vérifier.