Pourquoi un SE 64 bits ne peut-il pas exécuter une application 16 bits?

38

Qu'est-ce que c'est:

  • un système d'exploitation 32 bits, lorsqu'il est installé sur un processeur 64 bits, peut exécuter d'anciennes applications 16 bits,
  • mais si vous installez un système d'exploitation 64 bits, il ne peut pas exécuter ces applications directement et nécessite une sorte d'émulation (cela ne fonctionne pas toujours parfaitement)?

Pour être plus précis, j'ai un processeur 64 bits (Intel Core 2 Duo). Quand j'avais Windows XP et Windows 7 (tous deux 32 bits) installés, ils pouvaient exécuter d'anciennes applications DOS et Windows 616 bits.

Maintenant, j'ai installé l'édition 64 bits de Windows 7. Pourquoi ne peut-il plus exécuter ces mêmes applications?

windows-7 windows 64-bit 16-bit fix1234
la source
3
Je pense que cela a moins à voir avec les bits et plus avec le système d'exploitation invité. De quels OS parlez-vous spécifiquement?
Pekka soutient GoFundMonica
Est-ce qu'il fonctionnera sous DOSBox?
Penguat
1
Il existe un utilitaire appelé DOSBOX, un émulateur 16 bits qui donne à votre programme 16 bits un ordinateur 16 bits virtuel sur lequel travailler et qui est gratuit.
Je suis d'accord avec Pekka, le fait est qu'un système 64 bits (matériel) peut exécuter du code 16 bits (diable, même un code à 1 bit si le système d'exploitation était conçu de la sorte). Le véritable problème est que le processeur ne peut pas exécuter directement le code 16 bits en raison d'éléments de taille différente, mais ces problèmes peuvent être résolus par le système d'exploitation. La limitation est une limite artificielle imposée par Microsoft pour simplifier les choses (bien qu’ils émulent toujours en 32 bits car il ya encore beaucoup de code 32 bits). Il existe d'autres systèmes d'exploitation (* nix?) Pouvant exécuter du code 16 bits sans problème.
Synetech
Vous confondez Windows avec tous les systèmes d'exploitation.
Ken Sharp

Réponses:

24

Si je comprends bien, c'est parce qu'en mode Long (x64 natif), le processeur lui-même ne prend pas en charge le passage en mode 16 bits. Voir Wikipedia . Ainsi, afin de prendre en charge le mode 16 bits, le NTVDM (couche 16 bits de Windows) devrait émuler complètement un processeur 16 bits.

Je suppose qu'ils ont pesé dans la ré-implémentation d'une couche d'émulation par rapport à l'utilisation d'un logiciel de virtualisation déjà existant (VirtualPC, VirtualBox) pour gérer cela, et il a été décidé de supprimer le VDM.

Matt Sieker
la source
6
Citant Wikipedia : les versions de Windows NT pour les architectures 64 bits (x64 et IA-64) n'incluent pas le NTVDM et ne peuvent pas exécuter d'applications DOS ou Windows 16 bits. En effet, dans un processeur x86-64, le mode virtuel 8086 est disponible en tant que sous-mode uniquement dans son mode hérité (pour les systèmes d'exploitation 16 et 32 ​​bits), et non dans le mode natif long de 64 bits. une réinitialisation matérielle de la CPU est nécessaire pour passer en mode hérité. Donc, la seule façon dont NTVDM a fonctionné jusqu'à présent n'est plus disponible et les machines virtuelles complètes sont nombreuses, donc NTVDM a été coupé.
Joey
5
Beurk, je ne peux pas croire qu'ils ont abandonné le mode V86. Vous pouvez également lancer complètement le mode réel et demander des chargeurs de démarrage 32/64 bits si vous voulez le faire.
Brian Knoblauch
5
C'est exactement ce qui est déjà arrivé, M. Knoblauch. Un ordinateur x86 moderne doté du micrologiciel EFI passe directement du mode irréel dans ses premières instructions au mode protégé 64/32 bits. Les chargeurs de démarrage sont en effet des programmes en mode protégé 64/32 bits. C'est ce que sont les applications de démarrage EFI. Aucune utilisation du mode réel ou du mode protégé v8086 dans le processus.
JdeBP
3
-1. WINE prend en charge l'exécution d'applications Windows 16 bits en mode VM86 sous Linux 64 bits. capture d'écran . Page du projet V86-64 . La réponse de Mehrdad semble être la raison la plus convaincante.
Hugh Allen
3
@HughAllen: cette page indique actuellement "La version 64 bits du noyau Linux ne prend pas en charge le mode V86 car elle n'est pas prise en charge en mode de fonctionnement natif (mode long) de ces processeurs". et "Ce patch est très expérimental ." La réponse courte est que, bien qu'il soit possible d'exécuter du code 16 bits, en quittant complètement le mode long, il n'est pas judicieux de le faire.
Harry Johnston
14

Parce que les handles 64 bits ont 32 bits significatifs :

Notez que Windows 64 bits ne prend pas en charge l'exécution d'applications Windows 16 bits.
La raison principale est que les descripteurs ont 32 bits significatifs sur Windows 64 bits.
Par conséquent, les descripteurs ne peuvent pas être tronqués et transmis à des applications 16 bits sans perte de données.

Sous Windows, les programmes transmettent des "descripteurs" au système d'exploitation et inversement (des nombres que le système d'exploitation utilise pour identifier de manière unique une ressource particulière, telle qu'une fenêtre).

Pour prendre en charge les programmes 16 bits, Windows 32 bits génère uniquement des descripteurs comportant 16 bits significatifs - les 16 bits supérieurs sont ignorés par le système d'exploitation (même si les programmes ne doivent pas en tirer parti). Donc, aucun programme ne peut interagir avec plus de 2 16 objets, ce qui est en fait assez faible.

Cependant, pour améliorer cela, Windows 64 bits a augmenté le nombre de bits significatifs dans un handle à 32. Mais maintenant, cela signifie que les handles ne peuvent pas être passés à des programmes 16 bits sans perte d'informations. Les programmes 16 bits ne peuvent donc pas s'exécuter sur Windows 64 bits.

Mehrdad
la source
3
@ Joey: Je ne comprends pas ce que vous dites. Si le système d'exploitation est Windows 64 bits, les applications 16 bits ne peuvent pas y être exécutées, point à la ligne. Je ne vois pas en quoi le fait qu'il s'agisse d'une application "DOS" ou "Windows" change quoi que ce soit ici - de toute façon, les poignées devraient être tronquées par l'application.
Mehrdad
1
Les applications DOS n'ont pas de descripteurs. En fait, ils (généralement) ne savent même pas qu'ils fonctionnent sous Windows.
Joey
1
... en fait, même le code Win16 ne devrait pas poser trop de problèmes, maintenant que j'y réfléchis. Tout ce dont vous avez besoin est une table de recherche.
Harry Johnston
1
@ HarryJohnston: Je pense que vous ratez le problème. Que proposez-vous comme ce qui devrait se passer avec votre "table de consultation" imaginaire lorsqu'une application appelle EnumWindowset qu'il y a plus de 2 ^ 16 fenêtres dans le système?
Mehrdad
1
Je parlais des poignées du noyau conformément à l'article, pas des poignées de fenêtre. Ce sont des choses complètement différentes. Est-ce que les applications 16 bits voient même les fenêtres 32 bits? Cela semble peu probable, car les structures de message sont différentes; que se passerait-il si une application 16 bits recevait un message avec un wParam 32 bits? Notez également que le nombre maximal de descripteurs
Harry Johnston
10

Pour Windows, c'est parce que les versions x86 du système d'exploitation incluent une émulation 16 bits qui leur permet d'exécuter ces processus DOS plus anciens. Dans les versions x64, ils doivent déjà émuler l'exécution x86 (ils l'appellent WoW64) pour permettre l'exécution de processus 32 bits, et je suppose que l'utilisation de Wow64 pour émuler davantage l'émulateur 16 bits a causé trop de problèmes.

Une poignée de processus 16 bits reconnus s'exécutera car l'émulation est codée en dur pour les gérer, mais le reste ne fonctionne pas car l'émulation n'est pas incluse dans x64.

Voir "Pas de code 16 bits" à l'article MSKB: http://support.microsoft.com/kb/282423

SqlRyan
la source
14
Aucune émulation n'est en cours - x86 / 64 peut exécuter ces tâches de manière native. Il y a des discussions sur l'API en cours. Microsoft a choisi cette opportunité pour abandonner une technologie très ancienne et en grande partie inutilisée.
Chris K
@Chris Kaminski - Je suis surpris qu'ils fassent cela en tant que décision d'architecture - x86 vs x64 - au lieu de dire "Très bien - c'est Windows 7 et nous n'utilisons plus de processus 16 bits". Surtout avec le "Mode Windows XP" désormais intégré à la version 7, il semble que ce soit le moment idéal pour supprimer le support, même dans la version x86.
SqlRyan
@Chris Kaminski: Après y avoir réfléchi un peu plus, je pense que cela doit être imité, pas seulement une sorte de muck API. S'il pouvait exécuter le code d'une génération de bits différente de manière native, pourquoi x64 aurait-il demandé à Wow64 d'exécuter des applications 32 bits - ces applications ne s'exécuteraient-elles pas également de manière native?
SqlRyan
@darthcoder: Le processeur ne prend tout simplement pas en charge le mode virtuel 8086 requis par NTVDM en mode long (64 bits). Par conséquent, NTVDM devrait devenir une machine virtuelle complète, émulant tout ou se faisant couper. Comme il y a déjà suffisamment de machines virtuelles (et MS en a une aussi), la décision n'a pas été difficile à prendre. Je ne pense pas que cela ait quelque chose à voir avec l'âge ou combien utilisé.
Joey
rwmnau: Pour WoW64, il n'y a pas d'émulation (sauf pour Itanium). Les processeurs x64-64 prennent toujours en charge les instructions 32 bits, de sorte que presque tout ce que Windows a à faire est de basculer le processeur en mode 32 bits et de manipuler quelques pointeurs.
Joey
3

Corrigez-moi si je me trompe, mais si j'ai bien compris, c'est simplement à cause d'un problème spécifique à Windows que NTVDM utilise le mode 8086 virtuel. Le mode de compatibilité sur les processeurs x64 (fonctionnant en mode long) prend en charge le mode protégé «propre», 16 et 32 ​​bits de ce que j'ai trouvé ici: http://en.wikipedia.org/wiki/Long_mode , mais pas certains des 386 ajouts tels que le mode virtuel 8086. Donc, il n'est probablement pas pris en charge car il est inutile pour Microsoft de reprogrammer NTVDM, ce qui nécessiterait probablement l'ajout d'émulation supplémentaire, car certaines applications en mode protégé 16 bits peuvent utiliser le 8086 virtuel, même si la plupart ne le font pas. Je suppose qu'avec suffisamment de travail, il est possible d'écrire quelque chose de plus rapidement que dosbox qui s'exécute en mode long, car les applications 16 bits prennent en charge le matériel.

MichaelS
la source
−1. L'adressage en mode 16 bits, ou segment de 16 bits, est pris en charge via la table de descripteurs locaux. . En fait, winedvm sur Linux fait exactement cela! Il y a même un remplacement non officiel appelé otvdm .
user2284570
Eh bien, selon ma compréhension, la solution Wine contient un émulateur de processeur. Donc, il n’utilise pas le mode virtuel 8086. C’est précisément la solution qui pourrait potentiellement être implémentée dans NTVDM, sans émuler le PC entier, comme le fait DOSBOX (avec Win16). Et si vous dites que le mode protégé 16 bits est pris en charge en mode long, qu’en est-il des applications en mode réel Win16?
MichaelS
Il contient un émulateur, mais si un moyen de modifier la table de descripteur local est trouvé sous Windows, aucune émulation ne serait requise. En ce qui concerne le mode réel, ils peuvent également être émulés de la même manière que Dosemu (au moins la version Linux). Ntvdm a été initialement conçu pour permettre l'exécution du programme Dos sur des plateformes telles que Mips ou PowerPc, qui étaient prises en charge dans la version précédente de Windows. C'est juste une fonctionnalité optionnelle qui doit être activée à la compilation. Et il semble que le code source ait été divulgué, ce qui a permis à quelqu'un de faire exactement cela: columbia.edu/~em36/ntvdmx64.html
user2284570
3

La situation est différente pour les applications Dos et les applications Windows 16 bits.

Pour les applications Dos, le problème est que le mode 8086 virtuel n’est pas disponible en mode long. Ceci est une limitation de l'architecture de la CPU.

Pour les applications Windows 16 bits (qui s'exécutent en mode protégé 16 bits), la raison en est que MS n'était pas prêt à effectuer le travail nécessaire pour implémenter une couche de compatibilité appropriée. Amusingly Wine est parfaitement capable d’exécuter des applications Windows 16 bits sur un Linux 64 bits.

plugwash
la source
1
c'est simplement parce qu'il n'y a pas de NTVDM dans Windows 64 bits. La CPU peut toujours exécuter du code 16 bits en mode de compatibilité. Du manuel d'Intel: "Mode de compatibilité (sous-mode du mode IA-32e) - Le mode de compatibilité permet à la plupart des applications héritées 16 bits et 32 ​​bits de s'exécuter sans
recompilation
Si je comprends bien, le mode de compatibilité autorise le mode protégé 16 bits, mais pas le mode virtuel 8086.
plugwash
2

Je pense que la raison la plus probable est que seul un pourcentage infime des propriétaires de PC souhaitent pouvoir exécuter d'anciennes applications 16 bits sur leur nouveau matériel 64 bits. Microsoft a probablement pensé que cela ne valait pas la peine de continuer à prendre en charge les applications 16 bits.

Stephen C
la source
Cela a du sens, sauf que pour Windows 7 32 bits le supporte toujours, donc apparemment cela vaut la peine d’utiliser ce qu’ils ont déjà mais de ne pas le réimplémenter (comme cela serait nécessaire pour x86-64 en raison de l’absence de mode virtual-8086
Earlz,
Je pensais que "nous ne voulons pas maintenir une base de code compliquée". S'ils restaient en 16 bits, ils auraient peut-être dû prendre en charge des logiciels datant des années 80. Cela peut inclure des hacks laids afin que Lotus 1-2-3 fonctionne toujours.
Joe Plante
@Earlz oui, mais je pense que c'est la vraie réponse car la vraie solution pour accéder à la table de descripteurs locaux pour 16 bits est de le faire directement et non via le mode V86. Microsoft n'a tout simplement pas pris la peine de porter leur code. Il existe en fait un logiciel de remplacement non officiel Ntᴠᴅᴍ conçu pour Windows 64 bits natif .
user2284570