Warum kann ein 64-Bit-Betriebssystem keine 16-Bit-Anwendung ausführen?

38

Warum ist es das:

Auf einem 32-Bit-Betriebssystem, das auf einer 64-Bit-CPU installiert ist, können alte 16-Bit-Anwendungen ausgeführt werden.
Wenn Sie jedoch ein 64-Bit-Betriebssystem installieren, können diese Anwendungen nicht direkt ausgeführt werden und benötigen eine Emulation (die nicht immer einwandfrei funktioniert).

Genauer gesagt habe ich einen 64-Bit-Prozessor (Intel Core 2 Duo). Wenn ich Windows XP und Windows 7 (beide 32-Bit) installiert hatte, konnten sie alte DOS- und 616-Bit-Windows-Anwendungen ausführen.

Jetzt habe ich die 64-Bit-Edition von Windows 7 installiert. Warum können dieselben Anwendungen nicht mehr ausgeführt werden?

— fixer1234
quelle

3

Ich denke, das hat weniger mit den Bits zu tun als mehr mit dem Gastbetriebssystem. Auf welche Betriebssysteme beziehen Sie sich konkret?

— Pekka unterstützt GoFundMonica

Läuft es unter DOSBox?

— Pinguin

1

Es gibt ein Hilfsprogramm namens DOSBOX, einen 16-Bit-Emulator, der Ihrem 16-Bit-Programm einen virtuellen 16-Bit-Computer zur Verfügung stellt und kostenlos ist.

Ich stimme mit Pekka, die Tatsache ist , dass ein 64-Bit (Hardware) System kann 16-Bit - Code ausführen (Heck, sogar 1-Bit - Code , wenn das Betriebssystem so entworfen wurde). Der eigentliche Haken dabei ist, dass die CPU den 16-Bit-Code aufgrund verschiedener Zeigergrößen nicht direkt ausführen kann , diese Probleme jedoch vom Betriebssystem entfernt werden können. Es handelt sich um eine künstliche Einschränkung, die Microsoft eingeführt hat, um die Dinge zu vereinfachen (obwohl sie immer noch 32-Bit emuliert haben, weil es immer noch so viel 32-Bit-Code gibt). Es gibt andere Betriebssysteme (* nix?), Die problemlos 16-Bit-Code ausführen können.

— Synetech

Sie verwechseln Windows mit allen Betriebssystemen.

— Ken Sharp

24

Meines Erachtens liegt dies daran, dass die CPU im Long-Modus (x64 native) den Wechsel in den 16-Bit-Modus nicht unterstützt. Siehe Wikipedia . Um den 16-Bit-Modus zu unterstützen, müsste NTVDM (die 16-Bit-Schicht in Windows) einen 16-Bit-Prozessor vollständig emulieren.

Ich nehme an, sie haben abgewogen, eine Emulationsebene neu zu implementieren, anstatt eine bereits vorhandene Virtualisierungssoftware (VirtualPC, VirtualBox) zu verwenden, und es wurde beschlossen, den VDM zu kürzen.

— Matt Sieker
quelle

6

Zitat aus Wikipedia : Versionen von Windows NT für 64-Bit-Architekturen (x64 und IA-64) enthalten kein NTVDM und können keine DOS- oder 16-Bit-Windows-Anwendungen ausführen. Dies liegt daran, dass in einer x86-64-CPU der virtuelle 8086-Modus nur in seinem Legacy-Modus (für 16- und 32-Bit-Betriebssysteme) als Untermodus verfügbar ist, nicht im systemeigenen 64-Bit-Modus. Ein Hard-Reset der CPU ist erforderlich, um in den Legacy-Modus zu wechseln. Die einzige Möglichkeit, wie NTVDM bisher funktioniert hat, ist nicht mehr verfügbar, und es gibt jede Menge vollwertige VMs. Daher wurde NTVDM gekürzt.

— Joey

5

Ich kann nicht glauben, dass sie den V86-Modus verloren haben. Wäre es auch möglich, den Real-Modus vollständig zu deaktivieren und dafür 32/64-Bit-Bootloader zu fordern.

— Brian Knoblauch

5

Genau das ist schon passiert, Herr Knoblauch. Ein moderner x86-Computer mit EFI-Firmware wechselt in den ersten Anweisungen direkt vom unrealen Modus in den geschützten 64/32-Bit-Modus. Die Bootloader sind in der Tat 64/32-Bit-Programme im geschützten Modus. Genau das sind EFI-Startanwendungen. Im gesamten Prozess wird weder der Real-Modus noch der v8086-geschützte Modus verwendet.

— JdeBP

3

-1. WINE unterstützt die Ausführung von 16-Bit-Windows-Apps im VM86-Modus unter 64-Bit-Linux. Screenshot . V86-64-Projektseite . Mehrdads Antwort scheint der zwingendere Grund zu sein.

— Hugh Allen

3

@HughAllen: Auf dieser Seite steht derzeit "Derzeit wird der V86-Modus von der 64-Bit-Version des Linux-Kernels nicht unterstützt, da er im systemeigenen Betriebsmodus (Langmodus) dieser Prozessoren nicht unterstützt wird." und "Dieser Patch ist sehr experimentell ." Die kurze Antwort lautet: Obwohl es möglich ist , 16-Bit-Code auszuführen, ist dies nicht sinnvoll , wenn der lange Modus vollständig beendet wird .

— Harry Johnston

14

Da 64-Bit-Handles 32 signifikante Bits haben :

Beachten Sie, dass 64-Bit-Windows das Ausführen von 16-Bit-Windows-Anwendungen nicht unterstützt.
Der Hauptgrund ist, dass Handles unter 64-Bit-Windows 32 signifikante Bits haben.
Daher können Handles nicht ohne Datenverlust abgeschnitten und an 16-Bit-Anwendungen übergeben werden.

In Windows übergeben Programme "Handles" an das Betriebssystem und umgekehrt (dies sind Zahlen, mit denen das Betriebssystem eine bestimmte Ressource, z. B. ein Fenster, eindeutig identifiziert).

Zur Unterstützung von 16-Bit-Programmen generiert 32-Bit-Windows nur Punkte mit 16 signifikanten Bits. Die 16 oberen Bits werden vom Betriebssystem ignoriert (auch wenn Programme diese Tatsache nicht ausnutzen sollen). Daher kann kein Programm mit mehr als 2 ¹⁶ Objekten interagieren , was eigentlich ziemlich niedrig ist.

Um dies zu verbessern, hat 64-Bit-Windows die Anzahl der signifikanten Bits in einem Handle auf 32 erhöht. Dies bedeutet jedoch, dass Handles nicht ohne Informationsverlust an 16-Bit-Programme übergeben werden können. Daher können 16-Bit-Programme nicht unter 64-Bit-Windows ausgeführt werden.

— Mehrdad
quelle

3

@ Joey: Ich verstehe nicht, was du sagst. Wenn das Betriebssystem 64-Bit-Windows ist, können 16-Bit-Anwendungen nicht darauf ausgeführt werden. Ich verstehe nicht, wie die Tatsache, dass es sich um "DOS" - oder "Windows" -Anwendungen handelt, hier irgendetwas ändert - so oder so müssten Handles von der Anwendung abgeschnitten werden.

— Mehrdad

1

DOS-Anwendungen haben keine Handles. Tatsächlich wissen sie (normalerweise) nicht einmal, dass sie unter Windows laufen.

— Joey

1

... eigentlich sollte sogar Win16-Code kein allzu großes Problem sein, jetzt wo ich darüber nachdenke. Alles was Sie brauchen, ist eine Nachschlagetabelle.

— Harry Johnston

1

@ HarryJohnston: Ich denke, Sie vermissen das Problem. Was soll mit Ihrer imaginären "Nachschlagetabelle" geschehen, wenn eine Anwendung aufruft EnumWindowsund sich mehr als 2 ^ 16 Fenster im System befinden?

— Mehrdad

1

Ich sprach über Kernel-Handles gemäß dem Artikel, nicht über Fenster-Handles. Das sind ganz andere Dinge. Sehen 16-Bit-Anwendungen überhaupt 32-Bit-Fenster? Es erscheint unwahrscheinlich, da die Nachrichtenstrukturen unterschiedlich sind. Was würde passieren, wenn einer 16-Bit-App eine Nachricht mit einem 32-Bit-wParam gesendet würde? Beachten Sie außerdem, dass die maximale Anzahl der Fenstergriffe laut msdn.microsoft.com/en-us/library/windows/desktop/…

— Harry Johnston,

10

Unter Windows ist dies darauf zurückzuführen, dass die x86-Versionen des Betriebssystems eine 16-Bit-Emulation enthalten, mit der ältere DOS-Prozesse ausgeführt werden können. In den x64-Versionen müssen sie bereits die x86-Ausführung emulieren (sie nennen es WoW64), damit 32-Bit-Prozesse ausgeführt werden können, und ich vermute, dass die Verwendung von Wow64 zur weiteren Emulation des 16-Bit-Emulators zu viele Probleme verursacht hat.

Eine Handvoll erkannter 16-Bit-Prozesse werden ausgeführt, da die Emulation für ihre Verarbeitung hartcodiert ist. Der Rest funktioniert jedoch nicht, da die Emulation nicht in x64 enthalten ist.

Siehe "Kein 16-Bit-Code" im MSKB-Artikel: http://support.microsoft.com/kb/282423

— SqlRyan
quelle

14

Es findet keine Emulation statt - x86 / 64 kann diese Dinge nativ ausführen. Es gibt jedoch API-Thunking. Microsoft hat diese Gelegenheit genutzt, um eine deutlich veraltete und größtenteils unbenutzte Technologie aus dem Verkehr zu ziehen.

— Chris K

@Chris Kaminski - Ich bin überrascht, dass sie das als Architekturentscheidung tun würden - x86 gegen x64 - im Gegensatz zu der Aussage "Okay, es ist Windows 7, und wir führen keine 16-Bit-Prozesse mehr aus". Insbesondere mit dem jetzt in 7 eingebetteten "Windows XP-Modus" scheint es der perfekte Zeitpunkt zu sein, die Unterstützung auch in der x86-Version zu verringern.

— SqlRyan

@Chris Kaminski: Nachdem ich darüber nachgedacht habe, denke ich, dass es eine Emulation sein muss, nicht nur eine Art API-Mucking. Wenn Code eines anderen Bitbuilds nativ ausgeführt werden könnte, warum sollte dann x64 Wow64 haben, um 32-Bit-Apps auszuführen - würden diese nicht auch nativ ausgeführt werden?

— SqlRyan

@darthcoder: Die CPU unterstützt den für NTVDM erforderlichen virtuellen 8086-Modus im Long-Modus (64-Bit) einfach nicht. Daher müsste entweder NTVDM eine vollständige VM werden, die alles emuliert oder gekürzt wird. Da es bereits genügend VMs gibt (und MS auch), war dies keine schwere Entscheidung. Ich glaube nicht, dass es etwas damit zu tun hat, wie alt das war oder wie oft es benutzt wurde.

— Joey

rwmnau: Für WoW64 gibt es keine Emulation (außer für Itanium). x64-64-CPUs unterstützen immer noch die 32-Bit-Anweisungen, sodass fast alles, was Windows tun muss, darin besteht, die CPU in den 32-Bit-Modus zu versetzen und mit ein paar Zeigern herumzuspielen.

— Joey

3

Korrigieren Sie mich, wenn ich falsch liege, aber nach meinem Verständnis verwendet NTVDM nur aufgrund eines Windows-spezifischen Problems den virtuellen 8086-Modus. Der Kompatibilitätsmodus auf x64-Prozessoren (im langen Modus ausgeführt) unterstützt den vollständigen, 'sauberen' geschützten 16- und 32-Bit-Modus von dem, was ich hier gefunden habe: http://en.wikipedia.org/wiki/Long_mode , aber nicht einige der 386 Ergänzungen wie der virtuelle 8086-Modus. Daher wird es höchstwahrscheinlich nicht unterstützt, weil es sich nicht auszahlt, wenn Microsoft NTVDM neu programmiert. Dies würde wahrscheinlich das Hinzufügen einer weiteren Emulation erfordern, da einige 16-Bit-Anwendungen im geschützten Modus virtuelles 8086 verwenden können, auch wenn die meisten dies nicht tun. Ich nehme an, mit genügend Arbeit ist es möglich, etwas zu schreiben, das schneller ist als die Dosbox, die im Long-Modus läuft, da es Hardware-Unterstützung für 16-Bit-Apps gibt.

— MichaelS
quelle

−1. Die Adressierung im 16-Bit-Modus (16-Bit-Segment) wird über die lokale Deskriptortabelle unterstützt. . Tatsächlich macht winedvm on unter Linux genau das! Es gibt sogar einen inoffiziellen Ersatz namens otvdm .

— User2284570

Nun, nach meinem Verständnis enthält es (Weinlösung) einen CPU-Emulator. Daher wird der virtuelle 8086-Modus nicht verwendet. Dies ist genau die Lösung, die möglicherweise in NTVDM implementiert werden könnte, ohne den gesamten PC zu emulieren, wie dies DOSBOX (mit Win16) tut. Und wenn Sie sagen, dass der 16-Bit-geschützte Modus im Langmodus unterstützt wird, was ist dann mit Win16-Real-Mode-Apps?

— MichaelS

Es enthält einen Emulator. Wird jedoch unter Windows eine Möglichkeit zum Ändern der lokalen Deskriptortabelle gefunden, ist überhaupt keine Emulation erforderlich. Über den Real-Modus können sie auch so emuliert werden, wie es Dosemu (zumindest die Linux-Version) macht. Ntvdm wurde ursprünglich entwickelt, um das Ausführen von Dos-Programmen auf Plattformen wie Mips oder PowerPc zu ermöglichen, die in früheren Windows-Versionen unterstützt wurden. Es ist nur eine optionale Funktion, die beim Kompilieren aktiviert werden muss. Und es scheint, dass der Quellcode durchgesickert ist, der es jemandem erlaubt, genau das zu tun: columbia.edu/~em36/ntvdmx64.html

— user2284570

3

Bei Dos-Anwendungen und 16-Bit-Windows-Anwendungen ist die Situation anders.

Für Dos-Anwendungen besteht das Problem darin, dass der virtuelle 8086-Modus im langen Modus nicht verfügbar ist. Dies ist eine Einschränkung der CPU-Architektur.

Bei 16-Bit-Windows-Anwendungen (die im 16-Bit-geschützten Modus ausgeführt werden) lag der Grund darin, dass MS nicht bereit war, die Arbeit zur Implementierung einer geeigneten Kompatibilitätsebene auszuführen. Amüsanterweise ist Wine perfekt in der Lage, 16-Bit-Windows-Apps unter 64-Bit-Linux auszuführen.

— Plugwash
quelle

1

Es liegt nur daran, dass es unter 64-Bit-Windows kein NTVDM gibt. Die CPU kann im Kompatibilitätsmodus weiterhin 16-Bit-Code ausführen. Von Intel Handbuch: „Kompatibilitätsmodus (Untermodus von IA-32e - Modus) - Kompatibilitätsmodus ermöglicht die meisten älteren 16-Bit und 32-Bit - Anwendungen ohne erneute Kompilierung unter einem 64-Bit - Betriebssystem laufen zu lassen“

— phuclv

Wie ich es verstehe, erlaubt der Kompatibilitätsmodus den 16-Bit-geschützten Modus, aber nicht den virtuellen 8086-Modus.

— Plugwash

2

Ich denke, der wahrscheinlichste Grund ist, dass nur ein kleiner Prozentsatz der PC-Besitzer tatsächlich in der Lage sein möchte, alte 16-Bit-Anwendungen auf ihrer neuen 64-Bit-Hardware auszuführen. Microsoft hat wahrscheinlich gedacht, dass es sich nicht lohnt, weiterhin 16-Bit-Anwendungen zu unterstützen.

— Stephen C
quelle

Dies ist sinnvoll, außer dass Windows 7 noch 32-Bit unterstützt. Es lohnt sich also anscheinend, das zu verwenden, was bereits vorhanden ist, es aber nicht erneut zu implementieren (wie es für x86-64 erforderlich wäre, da kein virtueller 8086-Modus vorhanden ist

— Earlz

Ich dachte, dass "wir keine komplizierte Codebasis pflegen wollen". Wenn sie in 16-Bit-Version bleiben, müssen sie möglicherweise Software unterstützen, die bis in die 80er Jahre zurückreicht. Dies kann hässliche Hacks beinhalten, damit Lotus 1-2-3 immer noch funktioniert.

— Joe Plante

@Earlz ja, aber ich denke, das ist die echte Antwort, da die echte Lösung für den Zugriff auf die Local Descriptor-Tabelle für 16 Bit darin besteht, sie direkt und nicht über den Vm86-Modus auszuführen. Microsoft hat sich einfach nicht die Mühe gemacht, ihren Code zu portieren. Tatsächlich gibt es einen inoffiziellen Ntᴠᴅᴍ-Softwareersatz, der für natives 64-Bit-Windows entwickelt wurde .

— User2284570