Diskussion:Virtual 8086 Mode

VM86-Mode wie ein 8086 – oder 80286, 80386

Im Virtual 8086 Modus verhält sich der Prozessor aus Programmsicht doch wohl eher wie ein 80386, weil die 32 Bit-Register und 32 Bit-Befehle damit ebenfalls, so wie auch schon im Real-Adressmode, bereits auf einem 803686er verfügbar sind und damit auch verwendet werden können. […] Dirk Wolfgang Glomp (nicht signierter Beitrag von 92.224.129.193 (Diskussion) 11:27, 10. Okt. 2013 (CEST))

Das stimmt. im Virtual86-Modus sind die 386er Befehle natürlich weiterhin verfügbar. Es ist also aus Programmsicht (fast) wie ein 80386er im Real Mode. --RokerHRO (Diskussion) 13:16, 13. Okt. 2013 (CEST)

REAL-Mode, Protected-Mode und V86-Mode sind Adressmodelle, welche die Art und Weise beschreiben, wie aus der virtuellen Adresse im Code die physikalische gebildet wird. Der REAL-Mode ist damit kein 16 Bit Mode, wie er gerne bezeichnet wird. Erst im Long-Mode (EM64T) ändert sich auch der Umgang mit dem Befehlssatz. Die BCD-Instruktionen entfielen, 3-Adressbefehle wurden eingeführt und auch der Registersatz veränderte sich. 79.212.141.202 15:04, 19. Nov. 2017 (CET)

Es gibt sehr wohl 16- und 32-Bit-Modi bei x86!

Im 16-Bit-Modus ist die Default-Wortbreite eben 16 Bit (kann aber ab 386er mit dem "Operand Size Präfix" 66 auf 32 Bit geändert werden), und das Mod-R/M-Byte hat eine andere Bedeutung als im 32-Bit-Modus.

So bedeuten die Bytes 00 00 im 16-Bit-Modus ADD [BX+SI], AL, im 32-Bit-Modus dagegen ADD [EAX], AL. Mit dem "Address Size Prefix" 67 kann man im 16-Bit-Modus auf den 32-Bit-Adressierungsmodus wechseln und umgekehrt.

Real Mode und Virtual 8086 Mode sind immer 16-Bit-Modi (kann halt durch 66 und 67 Präfix für den nachfolgenden Befehl auf 32 Bit geändert werden), im Protected Mode bestimmt ein Bit im Code Segment Deskriptor die Default Operand Size und Default Adress Size.

--RokerHRO (Diskussion) 00:10, 20. Nov. 2017 (CET)

/* Nutzung */ DOS-Box in MS-DOS Eingabeaufforderung umbenannt

Nur die MS-DOS Eingabeaufforderung von Windows und das DOS Window von OS/2 (siehe: https://youtu.be/k4D-9wa0m_o?t=605 da sieht man die OS/2 Oberfläche mit der Auswahlmöglichkeit) oder DOSEMU unter Linux verwenden den Virtual 8086 Mode des 386er und späterer Prozessoren mit Ausnahme von 64 Bit Betriebssystemen.
Diese Dinger heißen aber nicht "DOS-Boxen". Und ein Oberbegriff Namens "DOS-Box" ist, wie ich bereits in der Beschreibung schrieb, sehr schlecht gewählt, weil es eben ein Programm Namens DOSBox gibt, dazu komme ich gleich, und alle 3 zuerst genannten Programme keine DOSBoxen sind, sondern eben einfach nur gewöhnliche Software unter diversen Namen, die unter Ausnutzung des Virtual 8084 Modus eine Ausführung von DOS Real Mode Anwendungen ermöglichen. Einen Oberbegriffs Namens DOSBox gibt es aber nicht.
Und um zu dem Programm DOSBox zurückzukommen, dieses verwendet den Virtual 8086 Mode überhaupt nicht, sondern emuliert eine komplette CPU mitsamt einer DOS Umgebung in Software.
Das ist auf modernen 64 Bit Betriebssystemen auch gar nicht mehr anders möglich, weil diese im Long Mode Betriebsmodus, siehe X64#Betriebsmodi, keine 16 Real Mode Programme mehr unterstützen und hierfür auch kein Virtual 8086 Modus mehr verwendet werden kann, da dieser in diesem Betriebsmodus nicht mehr zur Verfügung steht.
In diesem Betriebsmodus kann eine 64 Bit CPU unter einem 64 Bit Betriebssystem nur noch ausschließlich 16 Bit Protected Mode Programme von den 16 Bit Programmen ausführen, also z.b. reine Protected Mode Programme, z.B. Win16 Programme. Der Virtual 8086 Modus wird hierfür nicht verwendet, da es nicht geht.
Und DOSEMU kann den Virtual 8086 Modus unter so einem 64 Bit OS auch nicht mehr verwenden, weswegen es dann, genau wie die DOS Box auch, die komplette CPU in Software emuliert.
Und was Bochs betrifft, das ist ein reiner Emulator. Der emuliert verschiedene x86 CPU sogar auf einer komplett anderen Architektur in Software. Z.B. auf einer ARM CPU, der verwendet den Virtual 8086 Modus also auch nicht.
Und dann noch eine Ergänzung zu OS/2. Dieses hat auch einen sogenannten "DOS Full Screen" Modus. In dem wird der Zustand von OS/2 gesichert und dann ein echtes IBM DOS im echten Real Mode, nicht im Virutal 8086 Mode, ausgeführt. Da läuft also gar kein OS/2 mehr und wenn der DOS Full Screen beendet wird, dann wird OS/2 wieder gestartet und der gesicherte Zustand zurück in den Speicher geladen. Bei Windows 9x/Me passiert übrigens genau das gleiche wo DOS dann im Fullscreen Modus gestartet wird. Man darf das nicht mit der MS-DOS Eingabeaufforderung verwechseln. Dieser Modus war z.B. für manche DOS Programme notwendige, die unter einer MS-DOS Eingabeaufforderung gar nicht funktionierten und eine richtige Real Mode DOS Umgebung mit vollem Hardwarezugriff benötigten. Bei Windows NT gibt es diese Betriebsart nicht mehr, Windows NT behält die Kontrolle und verhindert aktiv solche Wechsel in den echten Real Mode.
Für das zurückschalten der CPU in den Realmode wird im Artikel Real Mode in den Abschnitten LOADALL-Trick und PM-Trick erwähnt, der englische Artikel en:Real_mode#Switching_to_real_mode ist da aber etwas besser, da das zurückschalten in den Real Mode nicht das gleiche wie der Unreal Mode ist. Der deutsche Artikel vermischt das leider zu sehr.
Zusammenfassung:

• MS-DOS Eingabeaufforderung -> verwendet Virtual 8086 Modus, den Oberbegriff DOSbox gibt es dafür nicht.
• DOS Window von OS/2 -> verwendet Virtual 8086 Modus, den Oberbegriff DOSbox gibt es dafür nicht.
• DOSEMU von Linux -> verwendet Virtual 8086 Modus auf 32 Bit Betriebssystemen, auf 64 Bit Betriebssystemen wird die CPU emuliert. Den Oberbegriff DOSbox gibt es dafür nicht.
• Bochs -> verwendet gar keinen Virtual 8086 Modus, das ist ein echter Emulator, der x86 sogar auf fremden Architekturen z.b. ARM in Software emuliert.
• DOSBOX -> verwendet den Virtual 8086 MODUS nicht, sondern emuliert die CPU und DOS in Software. Und diese Software hat den Begriff DOSBox für sich alleine reserviert, ist aber keine Software, die den Virtual 8086 Modus verwendet, deswegen ist es Unsinn, von DOSBoxen bei Programmen, die den Virtual 8086 Modus verwenden, zu sprechen.
• DOS im Vollbild unter Win9x/Me -> Win9x/Me wird beendet, der Zustand gespeichert und ein echtes MS-DOS im echten Real Mode ausgeführt. Nach exit, wird Win9x/Me wieder geladen und der alte Zustand zurückgeholt.
• DOS Full Screen bei OS/2 -> OS/2 wird beendet, der Zustand von OS/2 gesichert und ein echtes IBM DOS im echten Real Mode ausgeführt. Nach exit, wird OS/2 wieder geladen und der alte Zustand zurückgeholt.

Ich hoffe damit wären alle Fragen beantwortet. --84.158.122.178 05:00, 23. Dez. 2021 (CET)

Ja, definitiv, danke für die umfangreiche Ausführung.

Das, was ich allerdings anmerken möchte, ist, dass es nur unter Windows 3.x/9x „MS-DOS-Eingabeaufforderung“ heißt, im Text dann aber auch für OS/2 und Linux verwendet wird. Das ist leider falsch. Dort heißt es nämlich auf Deutsch „DOS-Modus“, siehe z.B. dieses Bild. Auf Englisch hieß das DOS-Fenster unter OS/2 „DOS Window“, siehe z.B. dieses Bild. Unter Linux verwendet DOSEMU gar keine andere Bezeichnung, es läuft ja auf einer virtuellen Textkonsole (virtual/pseudo terminal).

• Windows 3.x und Windows 9x: MS-DOS-Eingabeaufforderung (COMMAND.COM)
• Windows NT: Eingabeaufforderung (cmd.exe)
• OS/2: DOS-Modus (auch cmd.exe)
• DOSEMU (Linux): DOSEMU

Der Satz: „Der VM86-Modus wurde jedoch nicht nur für die MS-DOS Eingabeaufforderung z. B. unter Windows, OS/2, Linux (über das Programm DOSEMU) benutzt, sondern auch von DOS selbst.“ suggeriert aber, dass es unter allen gelisteten Betriebssystemen MS-DOS-Eingabeaufforderung heißen würde...

‣Andreas•⚖ 11:23, 23. Dez. 2021 (CET)

Hat sich nun ja erledigt. ‣Andreas•⚖ 11:30, 23. Dez. 2021 (CET)

Ist bei einer modernen CPU von heute der Virtual 8086 Mode Teil gar keine Hardware mehr, sondern als Microcode via Mikroprogammierung realisiert?

Weiß das jemand? Auf die Frage bin ich gekommen, als ich Gestern beim Recherchieren über den "Virtual 8086 Mode" im Internet auf die Frage gestoßen bin, warum man den "Virtual 8086 Mode" Teil aus heutigen Prozessoren nicht entfernen würde, da er ja Platz auf dem Siliziumdie belegen würde und für die Ausführung von Real Mode 16 Bit Programmen unter einem 64 Bit OS wegen dem Long Mode Betriebsmodi der x64 Architektur er ohnehin keine Rolle mehr spielt und eine Emulation in Software hier dann ohnehin nützlicher wäre.
Die Frage, des warum konnte nicht eindeutig geklärt werden, viele vermuteten wegen der Abwärtskompatibilität oder weil die Fläche, die man dadurch zurückgewinnen würde, nicht der Rede wert wäre. Eine andere Möglichkeit wäre aber, und auf die bin ich selber gekommen, dass dafür gar nichts mehr in Hardware gegossen sein könnte, sondern dass das eine reine Softwaregeschichte per Mikrocodeprogrammierung sein könnte. Weiß dazu jemand näheres? --84.158.122.178 07:42, 28. Dez. 2021 (CET)

Fast der gesamte x86-Befehlssatz wird auf heutigen CPUs intern erst in Mikrocode übersetzt und ausgeführt. Das bisschen Zeug für den VM86-Mode spielt da im Vergleich zu den ganzen SSE-und AVX-Befehlen keine Rolle. Never change a running system.
CPU-intern ist der VM86-Mode sowieso nur ein "etwas anders verschalteter" 16-Bit-Protected Mode, den man ja auch noch herumschleppt und den seit dem Ende von Win3.x niemand mehr braucht. Es hat darum für die CPU-Hersteller keinen großen Mehrwert, diesen auszubauen. Es sei denn, man baut den gesamten Protected Mode aus, was Intel demnächst ja anscheinend vorhat. Diese CPUs booten dann gleich im 64 Bit Long Mode oder in einem speziellen 64-Bit-System Management Mode. --RokerHRO (Diskussion) 14:11, 27. Jun. 2023 (CEST)

Erlaubt der Virtual 8086 CPU Instruktionen eines 80286 und 80386 oder nur eines 8086?

Das sollte in dem Artikel noch geklärt werden. Vom Namen her könnte man darauf schließen, dass nur 8086 CPU Instruktionen funktionieren. Auf einem 80286 und 80386 gibt es aber noch weitere Befehle (Opcodes), die man im Real Mode verwenden kann. Sind diese im Virtual 8086 ebenso verwendbar? --93.229.167.208 10:08, 15. Jun. 2023 (CEST)

Wieso sollte das nicht so sein? Beim Virtual 86 Mode bzw. VME geht es doch nur um den Real Mode, nicht um die einzelnen Instruktionen (Befehle, OpCodes). Wenn der 286er und der 386er tatsächlich mehr Real-Mode-Befehle bietet als der originale 8086, dann sind die sicher mit dabei... (Kurze Recherche...) Und so ist es auch:

Zur Quellenlage: der 8086 hatte folgende Instruktionen noch nicht, sie wurden mit dem Nachfolger 80186 eingeführt und beim 80286 verbessert (wie einige weitere 8086-Funktionen auch): BOUND, LEAVE und ENTER.^ref

Nun, laut diesem Forum funktioniert z.B. BOUND auch im V86-Mode: Bound > int 5 in Virtual mode.

Und auch auf diesen Seiten steht, dass die Befehle im VM86 funktionieren:

• BOUND
• ENTER
• LEAVE

‣Andreas•⚖ 22:05, 15. Jun. 2023 (CEST)

Das wurde vor 10 Jahren schon einmal gefragt hier. Und beantwortet, siehe oben. :-) --RokerHRO (Diskussion) 14:07, 27. Jun. 2023 (CEST)

Paraleller Ablauf

Diese Aussage

Im Protected Mode können mehrere Programme – so genannte Tasks – quasi parallel ablaufen.

Ist so nicht richtig. Ob ein Programm "quasi" parallel neben anderen Programmen ablaufen soll, entscheidet allein das Betriebssystem und dessen Design, also ob es Multitasking im Design berücksichtigt hat. Der Protected Mode stellt nur sicher, dass jeder Prozess seinen eigenen Speicherbereich hat und er den Code, der ein höheres Privilegienlevel benötigt, z.B. der Code des Betriebssystems in Ring0, nicht lesen, beschreiben und verändern kann. --93.229.163.76 01:33, 22. Okt. 2023 (CEST)

Jain. Darum ja auch "quasi parallel", denn wie schon im Artikel Multitasking beschrieben, laufen die mehreren Tasks auf einer Einprozessormaschine nicht wirklich parallel, sondern eben nur scheinbar parallel, weil sie – vom Betriebssystem und dem Timer-Interrupt gesteuert – abwechselnd Rechenzeit bekommen, ohne dass die Tasks das selber bemerken oder verhindern könnten (außer das Betriebssystem bietet eine API dafür an. ;-)) --RokerHRO (Diskussion) 21:30, 29. Okt. 2023 (CET)