Bonnes raisons de conserver les systèmes d'exploitation Microsoft Windows 32 bits

Cette question date de 2012. Si vous lisez ceci en 2019 ou après, la réponse est vraiment: Non. En 2019, il n'y a aucune bonne raison de maintenir des systèmes d'exploitation de bureau 32 bits.

Question originale ci-dessous:

Le logiciel serveur est en version 64 bits depuis un certain temps déjà (depuis Server 2008 R2 pour Windows et même pour Exchange et Sharepoint) et même Ubuntu vous éloigne des versions 32 bits pour les systèmes d'exploitation de leurs serveurs.

Mais existe-t-il une bonne raison quantifiable de conserver un système d’exploitation de bureau 32 bits? Nous préparons nos images Windows 8 pour les (malheureux?) Quelques-uns qui adopteront tôt.

La majorité de nos ordinateurs de bureau ont 4 Go ou moins de RAM, mais j'aimerais ne plus avoir à prendre en charge le support d’un système d’exploitation à saveur de 32 bits.

Une raison pour laquelle je devrais?

• 32 bits peuvent être légèrement plus rapides dans certains cas d'utilisation - les adresses plus petites signifient un code visuellement plus compact, ce qui signifie une efficacité accrue du cache. Dans les tests de référence que j'ai observés, cette efficacité a tendance à être éclipsée par la plus grande efficacité de calcul de 64 bits dans les environnements de calcul intensif. Mais 32 bits gagne parfois de temps en temps sur certains points de repère. YMMV. L'âge de vos logiciels est important, car les versions les plus récentes tirent parti d'éléments 64 bits, contrairement aux versions plus anciennes.

• Un code plus compact signifie moins d'espace disque. Il suffit de télécharger les images ISO de votre système d'exploitation préféré en versions 64 et 32 ​​bits pour voir la différence. Ce n'est pas trivial. C'est également beaucoup plus une fois que vous décompressez les fichiers binaires. Comme l’a souligné OrangeDog : Une grande partie de cette consommation d’espace provient du fait que les systèmes d’exploitation 64 bits livrent des bibliothèques 32 bits en plus de celles 64 bits.

• Vous obtenez toujours une meilleure compatibilité avec les composants et logiciels hérités avec 32 bits. Cela est particulièrement visible dans les systèmes qui compilent de manière dynamique sur la machine hôte tout en extrayant des bibliothèques binaires tierces. Le framework .NET de Microsoft en est un bon exemple: bien que les programmes soient théoriquement indépendants de l’architecture, chaque fois que vous vous connectez à un fichier binaire natif, vous vous connectez à un arc ou à l’autre. De nombreux développeurs ne savent même pas que cela se produit et expédient des composants de production qui ne fonctionneront pas sur des systèmes 64 bits sans quelque modification que ce soit, demandant explicitement à .NET de s'exécuter en mode 32 bits. La plupart des gens ne savent pas comment faire cela.

• Comme l'a souligné Daniel B: Le développement Windows .NET sur des machines 64 bits vous laisse exposé à une incohérence frustrante dans laquelle, dans certaines circonstances, les exceptions sont masquées par le système d'exploitation.

• Matériel hérité. Vous ne pouvez pas exécuter de pilote 32 bits sur un noyau 64 bits.

Rien de tout cela ne constitue un spectacle pour la plupart des gens. Néanmoins, vous devez décider de la manière dont ces facteurs affectent votre environnement.

La seule raison pour laquelle je peux penser à conserver un système d'exploitation de bureau 32 bits est si vous utilisez de vieux programmes 16 bits (par exemple, DOS) et que vous ne disposez pas de la version Windows qui prend en charge Windows Virtual PC.

(Et même alors, j'installerais un système d'exploitation 64 bits et utiliserais quelque chose comme DOSbox).

Edit: il existe en fait une autre raison: le matériel qui ne parvient pas à gérer plus de 4 Go d'espace d'adressage. Par exemple, FireWire essaye de faire du DMA. Ou tout matériel (ancien) sans pilotes 64 bits.

Tout ce qui fonctionnera sous Windows 8 est déjà compatible 64 bits, à moins d’avoir des netbooks Intel Atom de première génération (et j'en doute fort). C'est à peu près la seule chose à laquelle je peux penser.

AMD a publié son premier Opteron compatible 64 bits en 2003; et depuis lors, pratiquement tous les processeurs qu’ils ont fabriqués étaient compatibles 64 bits.

Un an plus tard, Intel sortait son premier Xeon 64 bits (Nocona) en 2004 et étendait à peu près toute la gamme de produits d’ici à 2006. Hormis les premiers puces Atom susmentionnées, chaque processeur Intel est aujourd’hui à 64 bits.

Wikipedia a une liste de processeurs en panne si vous êtes intéressé par l'histoire ancienne .

Compatibilité avec le logiciel / matériel ancien.

Si tout fonctionne sous x64, je ne me soucierais pas de 32 bits.

Les adresses de mémoire dans une machine 64 bits prennent naturellement 64 bits. Ces mêmes adresses prennent 32 bits sur une machine 32 bits. Dans certaines circonstances assez exceptionnelles, cette "augmentation" du nombre de bits nécessaire peut être la différence entre de bonnes performances et de mauvaises performances sur une machine limitée en mémoire.

Au-delà de cela, étant donné que vous exécuterez probablement un logiciel 32 bits sur une machine, de toute façon, et que la prise en charge 32 bits fonctionne relativement bien sur les machines 64 bits, les différences matérielles ne changent pas. De temps en temps, vous trouverez un périphérique hérité qui ne possède pas de pilote matériel 64 bits, mais c'est maintenant très rare en raison des systèmes d'exploitation 64 bits disponibles depuis plus de 10 ans.

Un point à considérer est que de nombreuses applications 32 bits plus anciennes sont plus anciennes que les autres. Du côté du système d’exploitation Windows, une application 32 bits risque d’être confuse si elle recherche des fichiers dans "Program Files" qui se trouvent maintenant dans "Program Files (x86)". De même, certains éléments du registre peuvent nécessiter une attention manuelle. Encore une fois, il s’agit davantage d’applications légèrement erronées qui ont maintenant besoin de votre aide pour "trouver" des choses qui auraient "fonctionné" si la machine était en 32 bits.

Beaucoup de gens ignorent que les programmes et bibliothèques 64 bits occupent plus de mémoire que leurs équivalents 32 bits.

Par exemple, lors de l'utilisation de machines virtuelles à faible mémoire, il est conseillé d'utiliser des systèmes d'exploitation 32 bits pour optimiser la disponibilité de la mémoire sur cette machine virtuelle.

En parlant d’Ubuntu, nous exécutons LTS en 64 bits 12.04 sous LTSP depuis maintenant quelques semaines.

Le seul problème que nous ayons rencontré pour les bêta-testeurs initiaux est que les terminaux LTSP que nous utilisons (Dell GX2xx) nécessitent un noyau 32 bits et que nous devons donc compiler un deuxième noyau LTSP et gérer deux fois plus de packages pour les deux architectures. .

LTSP étant tout à fait un cas limite, je pense que 64 bits est assez prêt à fonctionner à moins que vos tests ne montrent un défaut.

Bien que je recommande personnellement de passer à la version 64 bits dès que possible et de mordre la balle au plus vite, cela ne sera pas sans conséquence pour votre équipe de support informatique. Si la bande passante de l'équipe de support est déjà utilisée au maximum (c.-à-d. Déjà en sous-effectif), je considérerais en fait d'attendre.

C'est donc une réponse qui concerne les ressources humaines, pas seulement les logiciels / compatibilité.

Le déploiement doit bien sûr être soigneusement planifié (de préférence graduel plutôt que tout à la fois). Il y aura des problèmes "découverts" qui prendront des heures à résoudre par utilisateur. Une fois que les problèmes les plus courants ont été identifiés, les "instructions" peuvent guider des résolutions plus rapides pour les appels de support et le libre-service.

La plupart du temps (par exemple), je pense à tous les problèmes de compatibilité 32 et 64 bits entre le système d'exploitation, un progiciel spécifique et les plugins associés., par exemple en installant des navigateurs 32 bits et 64 bits (et / ou plusieurs navigateurs) sur un seul système d'exploitation 64 bits, des raccourcis pour "exécuter en tant qu'administrateur" ou "exécuter en tant qu'utilisateur normal", ainsi que des options pour un 32 et plug-in 64 bits pour ces navigateurs (ou parfois limité à des plug-ins 32 bits ne fonctionnant que dans une version du navigateur), ce qui interrompt les applications et les flux de travail créés à partir de ces plug-ins. (Par "plugins", j'entends n'importe quoi, de Java au flash, en passant par les lecteurs de PDF intégrés et les logiciels de conférence Web - construits en interne ou largement disponibles, à la fois commerciaux et gratuits.) Vous pouvez essayer de tester tous ces problèmes, mais difficile de prédire si un utilisateur installera par inadvertance le plug-in B avant le plug-in A, ce qui donnera un résultat différent de celui d'un autre utilisateur qui installera le plug-in A avant le plug-in B (

La seule raison de conserver les versions 32 bits de ... any ... est de prendre en charge les applications et systèmes "hérités". Si vous pouvez tout exécuter sur des systèmes d’exploitation 64 bits, considérez-vous chanceux et passez à autre chose. Vous pourriez ressembler à des SA médiocres qui évoluent dans un environnement d'entreprise pour une entreprise non technologique, où le plan de migration de la base d'utilisateurs de XP vers Windows 7 commence au troisième trimestre 2014.

< pleure >

Quoi qu'il en soit, je ne sais pas à propos de Shift+ Del, et je les laisserais probablement ignorés dans certains coins de l'environnement, au cas où l'innommable se produirait et que vous vous retrouviez dans le besoin Windows XPde quelque chose. Arrêtez définitivement de vous soucier de maintenir, mettre à jour, tester ou autre chose sur eux, mais gardez-les au cas où vous en auriez besoin. Il est arrivé l'autre jour qu'un client voulait que je soutienne une Windows 2000PdS, ce que je pouvais, parce que je n'ai pas soufflé toutes mes Server 2000images quand Server 2003je les ai publiées (et je le voulais vraiment aussi).

Même si vous priez et espérez que le temps n'arrive jamais, il est toujours agréable de disposer de ces informations "au cas où", et les coûts pour les conserver sont si minimes que je pense qu'il est insensé de ne pas le faire.

Ayant eu des problèmes considérables dus à des problèmes de logiciel hérités, je ne peux que dire que tout ce que vous exécutez puisse être exécuté sur un système d’exploitation 64 bits. Si tel est le cas, vous n'avez aucune raison de ne pas migrer, en supposant que l'octroi de licence n'est pas un facteur.

Dans mon cas, j'ai pu reconfigurer les systèmes de sorte que toutes les applications 32 bits seulement puissent s'exécuter sur le même ordinateur, permettant ainsi à tous les autres postes de travail d'être au format 64 bits. Finalement, j'ai même migré cette machine 32 bits vers une machine virtuelle sur Virtualbox s'exécutant sur un hôte Debian, principalement parce que sa capacité était suffisante et que je voulais réduire le nombre de boîtes.

Toutes les machines ci-dessus et plusieurs machines virtuelles ne peuvent pas exécuter de code x64 bits si le CPU ne prend pas en charge la virtualisation (par exemple, la fonctionnalité VT-x).

Plusieurs processeurs 64 bits moins chers, dépourvus de VT-x, etc., sont toutefois attrayants pour les clusters «faits maison».

De wikipedia :

Intel n'a pas ajouté de prise en charge de la segmentation à son implémentation x86-64 (Intel 64), rendant la virtualisation logicielle 64 bits impossible sur les processeurs Intel, mais la prise en charge d'Intel VT-x permet la virtualisation assistée par matériel 64 bits sur la plate-forme Intel.