J'écris un pilote de système de fichiers en espace utilisateur sous Windows et les conversions d'endianité sont quelque chose que j'ai traité, car ce système de fichiers particulier stocke toujours des valeurs au format little-endian et le pilote est censé les convertir (si nécessaire) pour le CPU c'est en cours d'exécution. Cependant, je me demande si je dois même m'inquiéter des conversions d'endianité, car pour autant que je sache, Windows de bureau ne prend en charge que les architectures peu endiennes (IA32, x86-84, etc.), et donc, sur le disque les valeurs little-endian sont parfaitement fines sans conversion. Cette observation est-elle exacte et, dans l'affirmative, est-il généralement acceptable de supposer que Windows fonctionnera toujours sur du matériel peu endian? De plus, est-il même possible (en 2011) d'exécuter Windows sur un émulateur big-endian ou quelque chose, de sorte que l'on pourrait même tester les problèmes d'endianness?
Edit: Pour plus de clarté, la façon dont mon code fonctionne actuellement, je fais une vérification de l'endianité au démarrage, puis chaque fois que je charge une valeur sur le disque, je l'exécute via une fonction en ligne qui utilise un intrinsèque pour changer l'endianité si l'architecture est big-endian. Le problème est que je ne sais pas si j'ai pu manquer un ou plusieurs de ces endroits où j'avais besoin de faire une conversion et la façon la plus simple de voir si j'ai foiré est d'exécuter le programme sur une architecture big-endian. Je suis donc intéressé à savoir (a) s'il est même nécessaire de faire ces vérifications car Windows ne fonctionne généralement pas sur des plateformes peu endiennes (aujourd'hui de toute façon), et (b) comment je pourrais éventuellement tester mon code, vu que je ne peux pas penser à un moyen d'exécuter Windows sur une architecture big-endian, et inverser manuellement tous les valeurs multi-octets sur le disque impliquent toujours un processus manuel que je pourrais bien bousiller.
Toutes les versions de Windows que vous verrez sont en petit bout, oui. Le noyau NT fonctionne en fait sur une architecture big-endian même aujourd'hui .
Modifier après une question modifiée:
A) Non, il n'est pas nécessaire de vérifier l'endianité si votre seule cible est Windows x86 ou x64. Je ne passerais même pas le temps à vérifier l'endianité dans ce cas.
B) Si vous voulez vérifier la prise en charge bi-endienne de votre code, je recommande de le diviser en bibliothèques qui sont elles-mêmes compilables sur plusieurs plates-formes. Ensuite, compilez et exécutez le code sur votre version Linux préférée qui prend en charge le big-endian et voyez si cela fonctionne. Je n'ai pas encore entendu parler d'un compilateur ou d'un logiciel capable de détecter les problèmes bi-endiens.
Réponse originale:
Pour autant que je sache, il n'y a pas de versions de bureau ou de serveur de Windows qui prennent en charge le big-endian. Les processeurs Itanium (qui je crois ont toujours été appelés IA 64, pas IA32 mais je peux me tromper) ont la possibilité de fonctionner en big-endian mais Windows ne le prend pas en charge.
Cela ne veut pas dire que Windows 8 sera petit-boutiste uniquement car Windows 8 cible les processeurs ARM.
Si pour une raison quelconque, vous êtes sous Windows (#ifdef _WIN32) et big-endian, inversez simplement les structures de données lorsque vous chargez à partir du disque et enregistrez toujours au format little-endian, ce qui est beaucoup plus courant.