Windows XP fait son apparition sur Hacker News grâce à un émulateur Itanium qui ressuscite un avenir avorté

Windows XP a fait son apparition sur Hacker News après qu’un émulateur a démarré sa rare édition Itanium de 2002, alors même que cette plateforme résistait à toute émulation pratique depuis des décennies.

Cette prouesse est moins aboutie que ne le laisse penser le bureau XP familier. L’installation reste lente, la prise en charge matérielle est incomplète, et les applications 32 bits ordinaires révèlent les faiblesses héritées de la conception initiale d’Intel.

C’est cette friction qui constitue la véritable histoire. Microsoft et Intel avaient autrefois présenté Itanium comme un socle pour l’informatique 64 bits haut de gamme. Aujourd’hui, des bénévoles reconstruisent cet avenir à partir d’une documentation incomplète et d’une traduction méticuleuse des instructions.

Le récit pratique qui a atteint la première page de Hacker News illustre le mélange de progrès et de frustration qui en résulte. Un système d’exploitation oublié fonctionne désormais sans sa station de travail d’origine, mais il se comporte difficilement comme une machine virtuelle normale.

Cet épisode ravive également une ancienne compétition architecturale. Itanium demandait aux logiciels de s’adapter à un nouveau jeu d’instructions. AMD64, ensuite standardisé sous le nom x86-64, préservait la compatibilité avec la base logicielle x86 existante.

La voie évolutive d’AMD a conquis le marché de masse. Le nouvel émulateur permet aux développeurs d’examiner l’alternative depuis le logiciel censé la valider.

Pourquoi Windows XP pour Itanium est réapparu sur Hacker News

Le changement immédiat est qu’un système d’exploitation autrefois lié à un matériel Itanium rare peut désormais démarrer grâce à une émulation logicielle expérimentale.

Windows XP 64-Bit Edition n’était pas l’édition x64 dont beaucoup se souviennent. La version originale de 2002 ciblait IA-64, le jeu d’instructions 64 bits incompatible Itanium d’Intel.

Cette distinction est importante, car une machine virtuelle x86 ordinaire ne peut pas exécuter du code IA-64. La virtualisation permet normalement à un système invité de réutiliser le jeu d’instructions du processeur hôte. L’émulation doit reproduire en logiciel un processeur différent et son matériel environnant.

Jusqu’à récemment, l’accès à la première édition Itanium de XP exigeait généralement une machine Merced encore fonctionnelle. Merced était le nom de code de la première génération commerciale d’Itanium d’Intel.

Ces stations de travail sont de plus en plus rares. Elles comportent également des supports de stockage vieillissants, des micrologiciels propriétaires, des composants inhabituels et d’autres sources potentielles de défaillance.

Un effort de préservation avait documenté le problème des années avant la percée actuelle. Son plan de prise en charge de Merced décrivait le matériel physique et les anciens logiciels de simulation comme des fondations inadéquates à long terme.

Le projet a identifié plusieurs éléments manquants. Parmi eux figuraient des copies de micrologiciels, le comportement du processeur, la logique de la plateforme et un modèle de système complet capable de démarrer le système d’exploitation.

Des travaux récents ont changé la situation. Le développeur Yufeng Gao, avec l’aide de gdwnldsKSC, a produit un traducteur expérimental du jeu d’instructions IA-64 et un émulateur de système.

La version 0.1 démarrerait Windows XP 64-Bit Edition et Windows Server 2003 pour Itanium. Elle peut également amener certaines configurations Linux jusqu’à un shell, même si la compatibilité reste limitée.

Cela suffit à faire passer le projet au-delà des captures d’écran et de l’analyse statique de disques. Les chercheurs peuvent observer l’exécution du système d’exploitation, examiner ses hypothèses et tester des logiciels dans l’environnement processeur pour lequel ils étaient conçus.

La percée reste facile à mal interpréter. Elle ne rend pas Itanium XP pratique, rapide ou adapté à un usage quotidien.

Les premiers rapports comparent ses performances sur un hôte Ryzen 5000 à celles d’un ordinateur de l’ère des 486. Cette comparaison est anecdotique, mais elle décrit mieux l’expérience actuelle qu’une affirmation de succès sans benchmark.

La prise en charge graphique constitue une autre limite. Des utilisateurs ont indiqué devoir recourir à l’accès Bureau à distance ou à des modes d’affichage à faible nombre de couleurs, car un chemin graphique émulé adapté reste inachevé.

L’installation peut donc sembler hostile. Un émulateur doit reproduire suffisamment de comportements du processeur, du micrologiciel, du stockage, des interruptions et des périphériques pour qu’un système d’exploitation propriétaire puisse progresser.

Une défaillance peut ressembler à un problème de XP alors que le véritable défaut se situe dans le chipset virtuel. Elle peut aussi apparaître dans l’émulateur lorsque Windows attend un comportement matériel non documenté.

Cela explique l’expression « unbridled rage ». Démarrer le bureau représente une étape majeure, mais y parvenir peut exiger des débogages répétés à travers plusieurs couches de technologies historiques.

La discussion sur Hacker News compte parce qu’elle relie deux communautés. Les amateurs de rétro-informatique veulent accéder à une version inhabituelle de Windows, tandis que les développeurs d’émulateurs y voient une cible difficile de validation architecturale.

Windows est précieux pour cette validation, car il sollicite un ensemble de fonctionnalités processeur différent de Linux. L’obtention d’un shell Linux fonctionnel ne garantit pas que l’installation de Windows, ses pilotes ou ses applications se comporteront correctement.

L’attention de la première page remet également en cause une ancienne hypothèse. En janvier 2026, les réponses de la communauté affirmaient encore couramment que l’exécution de cette édition de XP nécessitait du matériel IA-64 physique.

Six mois plus tard, des émulateurs expérimentaux la démarraient. Ce changement ne correspond pas au lancement d’un produit grand public, mais il constitue un événement important pour la préservation.

L’édition de 2002 préserve le pari le plus ambitieux d’Intel

Windows XP pour Itanium est important parce qu’il consigne un moment où Intel s’attendait à ce que la compatibilité logicielle cède la place à un nouveau modèle de processeur.

Intel et Hewlett-Packard ont développé IA-64 autour du parallélisme explicite au niveau des instructions. Le processeur dépendait largement des compilateurs pour identifier les opérations pouvant s’exécuter ensemble.

Cette approche différait des processeurs x86 conventionnels, qui découvraient dynamiquement de nombreuses possibilités d’ordonnancement lors de l’exécution de programmes existants. Itanium transférait davantage de responsabilité vers les logiciels et le compilateur.

L’approche promettait des avantages pour des charges de travail techniques soigneusement optimisées. Elle augmentait aussi la charge pesant sur les développeurs de compilateurs, les équipes de systèmes d’exploitation, les éditeurs d’applications et les clients.

Microsoft a commencé à collaborer avec Intel sur l’informatique 64 bits en 1996. En 2001, l’entreprise a fourni la prise en charge de Windows XP pour le processeur Itanium de première génération.

La première version utilisait la base de code de Windows XP et portait le numéro de build 2600. Son numéro de version familier masquait une plateforme binaire radicalement différente.

Les applications IA-64 natives devaient être compilées spécifiquement pour Itanium. Les applications Windows 32 bits standard dépendaient d’un mécanisme de compatibilité plutôt que de s’exécuter nativement comme des logiciels x86 ordinaires.

Ce mécanisme pouvait préserver un certain accès aux applications existantes, mais il n’effaçait ni les coûts de performance ni les problèmes de compatibilité. Les pilotes constituaient une frontière encore plus stricte.

Un pilote Windows compilé pour x86 ne pouvait pas simplement contrôler du matériel depuis un noyau IA-64. Les fournisseurs devaient proposer des pilotes spécifiques à cette architecture pour un marché comptant relativement peu de machines.

Cela a créé un problème de plateforme bien connu. Les clients voulaient des applications et des périphériques avant d’acheter des stations de travail, tandis que les fournisseurs voulaient des clients avant de financer des portages.

Le successeur de Microsoft, lancé en 2003, ciblait Itanium 2 et utilisait la base de code de Windows Server 2003. Il s’appelait Windows XP 64-Bit Edition Version 2003 et appartenait à une lignée de builds plus récente.

Ces noms ont créé une confusion durable. Windows XP 64-Bit Edition désignait IA-64, tandis que Windows XP Professional x64 Edition a ensuite ciblé les processeurs compatibles AMD64.

Ces produits n’étaient pas interchangeables. Ils utilisaient des jeux d’instructions, des pilotes et des hypothèses de compatibilité différents.

La déclaration de lancement de 2003 de Microsoft positionnait l’édition Itanium 2 pour le calcul scientifique, l’ingénierie, l’animation et la production vidéo.

Cette cible reflétait le rétrécissement des perspectives. Itanium n’était plus un remplaçant crédible pour tous les processeurs de bureau, mais les fournisseurs voyaient encore un rôle pour lui dans les coûteuses stations de travail techniques.

Microsoft affirmait que le système d’exploitation combinerait des applications techniques complexes avec les logiciels professionnels Windows. Cette proposition reposait à la fois sur des performances natives et sur une compatibilité acceptable.

L’édition de 2002 restaurée permet aux chercheurs d’examiner directement cette proposition. Ils peuvent voir quels composants XP familiers ont survécu au portage et quelles hypothèses ont changé autour d’IA-64.

Elle préserve également un environnement précoce d’Extensible Firmware Interface. EFI, le prédécesseur des déploiements UEFI modernes, était central dans les systèmes Itanium bien avant de devenir courant sur les PC.

Cela fait de ce système d’exploitation davantage qu’une curiosité Windows. Il se situe à l’intersection de la conception des processeurs, de l’évolution des micrologiciels, de la stratégie des compilateurs et de l’économie des plateformes.

L’émulation peut révéler ces relations d’une manière que les seuls supports d’installation ne permettent pas. Une image disque préserve des octets, tandis qu’un système fonctionnel préserve des comportements.

Ces traces comportementales incluent les échecs. La lenteur de traduction des applications, l’absence de pilotes et une installation laborieuse ne sont pas des distractions par rapport à l’histoire d’Itanium.

Elles témoignent des coûts associés à une rupture architecturale nette. Le système d’exploitation montre ce qui s’est produit lorsque l’ambition d’une plateforme a rencontré une base logicielle établie.

Le véritable adversaire était la rétrocompatibilité

Itanium a perdu la compétition des stations de travail parce que son ambition architecturale ne pouvait pas surmonter la valeur pratique de l’exécution des logiciels x86 existants.

AMD a introduit une autre voie avec AMD64. Au lieu de remplacer x86, AMD l’a étendu avec des registres, de l’adressage et des modes de fonctionnement 64 bits.

Cette approche offrait aux fournisseurs de systèmes d’exploitation une voie vers des logiciels 64 bits natifs tout en conservant la prise en charge directe du jeu d’instructions x86 existant.

Intel a fini par adopter des extensions 64 bits compatibles pour ses processeurs grand public. Microsoft a ensuite aligné Windows 64 bits grand public sur l’appellation x64.

Au début de 2005, Microsoft avait cessé de développer Windows XP pour les stations de travail Itanium. Son attention s’est déplacée vers Windows XP Professional x64 Edition et les éditions x64 de Windows Server 2003.

La décision a suivi le marché du matériel. Hewlett-Packard, dernier grand fournisseur à proposer des stations de travail Itanium, avait cessé de vendre ces systèmes en septembre 2004.

Dell avait déjà retiré ses stations de travail Itanium. Alors que les principaux fournisseurs quittaient cette catégorie, Microsoft avait peu de raisons de maintenir un système d’exploitation client spécialisé.

La couverture contemporaine de cet abandon a relevé des reconnaissances inhabituellement directes de la part des entreprises concernées.

Microsoft a déclaré qu’Itanium restait plus solide sur le marché des serveurs haut de gamme. L’entreprise a identifié x64 comme la meilleure voie pour les serveurs et stations de travail grand public.

Intel a soutenu cette décision. Un représentant de l’entreprise a déclaré que les processeurs Xeon dotés de capacités 64 bits offraient un meilleur rapport performances-prix global pour les stations de travail.

Cette réponse concédait de fait la compétition principale. Itanium a survécu dans les serveurs, mais l’avenir plus large des stations de travail Windows appartenait aux processeurs 64 bits compatibles x86.

Le contraste ne se résumait pas à Intel contre AMD. Il s’agissait d’une compétition entre le remplacement d’une architecture établie et son extension.

Itanium demandait aux clients de tolérer de nouveaux binaires, de nouveaux pilotes, un comportement de performance différent et des choix matériels plus restreints. AMD64 leur permettait de conserver une bien plus grande partie de leur environnement existant.

La rétrocompatibilité paraît souvent inélégante aux concepteurs de systèmes. Elle préserve d’anciennes instructions, des modes de fonctionnement et des contraintes d’implémentation qu’une conception épurée pourrait écarter.

Pour les utilisateurs, cependant, la compatibilité représente un investissement accumulé. Chaque application, pilote, processus de déploiement, guide de dépannage et employé formé contribue à cette valeur.

Windows a amplifié cet effet, car sa force provenait d’un vaste écosystème matériel et logiciel. Une transition de processeur qui affaiblissait cet écosystème affaiblissait aussi la raison de choisir Windows.

L’émulateur recrée les conséquences. Les composants IA-64 natifs peuvent s’exécuter dans leur modèle prévu, mais les logiciels x86 ordinaires franchissent une frontière de compatibilité.

Cette frontière devient particulièrement visible lorsque le processeur émulé est déjà lent. Superposer une traduction x86 à l’intérieur de l’émulation IA-64 peut multiplier le coût réel.

Le résultat démontre pourquoi les benchmarks de processeurs n’ont jamais raconté toute l’histoire. Une station de travail existe pour exécuter la charge de travail complète d’un client, et non un exécutable natif isolé.

Les pilotes aggravent le problème. Un processeur haut de gamme offre peu de valeur si le système d’exploitation ne dispose pas d’une prise en charge adaptée pour le stockage, les graphismes, le réseau ou les équipements spécialisés.

AMD64 a réduit ce risque de transition parce que les fabricants pouvaient s’appuyer sur une architecture PC familière. Les stations de travail Itanium exigeaient un engagement envers une plateforme plus réduite et moins prévisible.

Cette histoire reste pertinente au-delà du rétrocoding. Les fournisseurs de plateformes modernes demandent encore aux développeurs d’adopter de nouveaux jeux d’instructions, frameworks applicatifs, accélérateurs et environnements d’exécution.

Les transitions de processeurs d’Apple ont réussi en partie parce que l’entreprise contrôlait le matériel, les systèmes d’exploitation, les outils de développement et la distribution. Elle a également investi massivement dans la traduction durant la migration.

Les fournisseurs de cloud peuvent introduire des processeurs personnalisés derrière des services gérés. Les clients peuvent utiliser une interface applicative sans être confrontés à chaque différence architecturale.

Itanium a fait face à un environnement plus rude. Microsoft, Intel, HP, les éditeurs de logiciels indépendants, les fabricants d’appareils et les acheteurs d’entreprise avaient tous des incitations et des calendriers distincts.

Aucun participant ne pouvait garantir une masse critique. Une fois les fournisseurs de stations de travail retirés, l’argument logiciel s’est rapidement dégradé.

L’édition XP restaurée rend cet échec de l’écosystème tangible. Son bureau semble familier, mais les logiciels qui le sous-tendent appartiennent à une plateforme incompatible que le marché a abandonnée.

Ce que l’émulateur ne prouve toujours pas

Un démarrage réussi prouve un comportement important du processeur et de la plateforme, mais n’établit pas encore une émulation Itanium complète, précise ou durable.

La version 0.1 doit être considérée comme une étape alpha. Que Windows atteigne un bureau est impressionnant, même si de nombreux chemins d’exécution peuvent rester non testés.

Un émulateur peut implémenter suffisamment de comportements pour le démarrage tout en gérant mal des instructions peu courantes, des conditions de temporisation, l’ordonnancement mémoire, les exceptions ou les opérations multiprocesseurs.

Les systèmes d’exploitation constituent des tests utiles parce qu’ils sollicitent des fonctions privilégiées du processeur. Ils ne peuvent toutefois pas couvrir chaque interaction avec une application ou un matériel.

Les performances restent également une contrainte centrale. Les rapports faisant état d’une vitesse comparable à celle d’un 486 sur un hôte Ryzen 5000 indiquent que le système actuel privilégie la correction et l’avancement plutôt que la commodité.

C’est compréhensible pour une implémentation précoce. IA-64 présente des défis de traduction inhabituels, car les bundles d’instructions exposent des décisions d’exécution parallèle encodées par le compilateur.

Un émulateur doit décoder ces bundles, reproduire l’état architectural, gérer la spéculation et préserver le comportement des exceptions. Optimiser un chemin peut introduire ailleurs des défauts de correction subtils.

L’état actuel du logiciel exige également une présentation prudente. Les premières couvertures indiquaient que le code de l’émulateur dédié n’était pas immédiatement disponible, sa publication étant promise après nettoyage.

Un fork QEMU distinct a également revendiqué des progrès IA-64, y compris la prise en charge de versions ultérieures de Windows pour Itanium. Il s’agit d’efforts distincts qui ne doivent pas être considérés comme une seule implémentation vérifiée.

L’annonce de l’émulateur a mentionné les deux projets tout en précisant explicitement que le travail QEMU séparé n’avait pas été vérifié indépendamment par son auteur.

Cette distinction importe pour la préservation. Le code open source peut être audité, réparé et porté après le départ de son développeur d’origine.

Un binaire privé ou un dépôt inachevé offre une protection à long terme plus faible. Il peut démontrer la faisabilité sans garantir que de futurs chercheurs pourront reproduire le résultat.

Le firmware crée une autre incertitude. Un émulateur de système complet dépend souvent d’un firmware de plateforme dont les droits de licence, la provenance et de redistribution diffèrent du code de l’émulateur.

Les supports d’installation de Windows présentent des contraintes juridiques similaires. Préserver les connaissances d’exécution n’accorde pas automatiquement l’autorisation de distribuer des images propriétaires de systèmes d’exploitation.

Les utilisateurs ont également besoin de l’édition appropriée. La version de 2002 pour Itanium de première génération et la version de 2003 pour Itanium 2 ciblent des générations de plateformes différentes.

Une configuration qui démarre une image peut échouer avec l’autre. Appeler l’un ou l’autre produit « XP 64 bits » sans identifier IA-64 ajoute davantage de confusion.

La fidélité matérielle demeure également incomplète. Un bureau atteint par accès à distance ne prouve pas que les modèles graphiques, audio, réseau, de stockage et de périphériques correspondent à une station de travail historique.

Ces lacunes limitent les tests pratiques d’applications. Un programme peut démarrer, puis échouer lorsqu’il atteint un périphérique non implémenté ou un service du système d’exploitation.

Il n’existe pas non plus de base permettant de considérer cet environnement comme sécurisé. Windows XP est obsolète, et cette édition inhabituelle ne dispose pas des outils matures disponibles pour les versions historiques grand public de Windows.

Toute expérimentation doit rester isolée des réseaux et données non fiables. L’émulateur est un environnement de recherche, pas une plateforme informatique prise en charge.

Ces réserves ne diminuent pas la réussite. Elles définissent ce qui vient après un écran de démarrage visuellement convaincant.

Les projets de préservation deviennent durables lorsque d’autres peuvent compiler le code, reproduire la configuration, vérifier les résultats des tests et documenter les artefacts nécessaires.

Une capture d’écran lance la conversation. La reproductibilité la transforme en infrastructure.

Trois signaux à surveiller après l’attention de Hacker News

La prochaine phase dépend du code public, de tests sur un plus grand nombre de systèmes d’exploitation et de gains de vitesse mesurables sans sacrifier la correction.

Le premier signal est une publication du code source reproductible. Le projet de Gao a indiqué que du code nettoyé deviendrait disponible dans son dépôt de développement.

Une publication utile nécessite plus que des fichiers source. Elle doit identifier les dépendances de compilation, les plateformes hôtes, les exigences de firmware, les images disque prises en charge et les limitations connues.

Si des utilisateurs indépendants peuvent reproduire le démarrage de Windows XP, l’argument en faveur de la préservation devient bien plus solide. Si le projet ne reste disponible qu’à travers des démonstrations, sa valeur à long terme demeure incertaine.

Le code public permettrait également aux spécialistes d’inspecter le comportement IA-64. Ils pourraient comparer les décisions d’implémentation à la documentation Intel et tester les cas limites présumés du processeur.

Le deuxième signal est une prise en charge plus large des systèmes invités. Windows Server 2003 et XP fournissent déjà des tests significatifs, tandis que Linux donne accès au code source et aux outils de diagnostic.

OpenVMS et HP-UX présenteraient des défis différents. Tous deux sont devenus des éléments importants de l’identité d’entreprise ultérieure d’Itanium, mais les rapports actuels indiquent qu’ils ne démarrent pas.

Gentoo atteindrait un shell avec Linux 6.6 ou une version antérieure sous l’émulateur expérimental. Cela fournit une autre surface de test, même si un shell n’équivaut pas à une prise en charge matérielle complète.

Les progrès sur des systèmes d’exploitation sans lien entre eux réduiraient la probabilité que l’émulateur ne satisfasse que le chemin de démarrage d’un seul invité. Ils indiqueraient un modèle de processeur et de plateforme plus général.

Le troisième signal est un test de performances transparent. La première comparaison avec un 486 exprime la frustration, mais des benchmarks reproductibles révéleraient où le temps est réellement dépensé.

Les développeurs doivent séparer les coûts de traduction du processeur des délais du firmware, du stockage émulé, des limitations graphiques et de la compatibilité x86 imbriquée.

Un profil pourrait montrer qu’un petit groupe d’instructions domine le temps d’exécution. Il pourrait au contraire révéler des mécanismes architecturaux qui résistent à une traduction dynamique directe.

Le travail sur les performances mettra à l’épreuve le principal compromis du projet. Une traduction plus rapide n’a de valeur que lorsque l’émulateur préserve le comportement attendu par les logiciels historiques.

Le résultat affecte aussi l’accessibilité. Un système qui démarre en plusieurs heures peut aider des chercheurs dévoués, tandis qu’une version plus rapide peut soutenir les salles de classe, les musées et l’analyse automatisée de logiciels.

La documentation communautaire mérite autant d’attention que le code. La vague d’intérêt actuelle s’estompera si les chercheurs ne consignent pas les configurations, les messages d’erreur et les correctifs sous une forme consultable.

Une base de connaissances consultable peut aider les groupes d’ingénierie à relier manuels, notes de test, détails du firmware et décisions de débogage. La préservation dépend autant du contexte conservé que des binaires conservés.

Le même principe s’applique à cet émulateur. Ses auteurs reconstruisent des hypothèses réparties entre les manuels de processeur, le comportement du système d’exploitation, le firmware et l’ancien matériel.

L’attention de Hacker News peut attirer des contributeurs disposant d’expertises ou de machines manquantes. Elle peut aussi créer une pression en faveur de conclusions prématurées fondées sur des captures d’écran.

Les lecteurs devraient donc observer les preuves, et non l’enthousiasme. Une version source taguée, une reproduction indépendante et des tests sur plusieurs systèmes invités renforceraient chacun l’argument.

Ne pas atteindre ces étapes n’effacerait pas la réussite du démarrage. Cela laisserait le projet comme une démonstration remarquable plutôt qu’une plateforme de préservation fiable.

Windows XP pour Itanium fonctionne désormais suffisamment pour exposer le futur qu’Intel avait imaginé. La question est de savoir si ce futur retrouvé deviendra reproductible, inspectable et utilisable par quiconque au-delà de ses premiers sauveteurs.

Suivez les dépôts, comparez les résultats de tests indépendants et consignez les échecs avec autant de soin que les démarrages réussis. Pour ce pan de l’histoire de l’informatique, les échecs expliquent pourquoi la plateforme compte.