Wie war Multitasking in älteren Windows-Versionen möglich?
In Anbetracht der Tatsache, dass DOS ein Single-Tasking-Betriebssystem war und die Beziehungen zu früheren Windows-Versionen geknüpft waren, wie haben frühere Windows-Versionen es geschafft, Multitasking durchzuführen? Der heutige Q & A-Beitrag von SuperUser beschäftigt sich mit den Antworten auf diese Frage.
Die heutige Question & Answer-Sitzung wird dank SuperUser zur Verfügung gestellt - einer Unterteilung von Stack Exchange, einer Community-basierten Gruppierung von Q & A-Websites.
Windows 95-Screenshot mit freundlicher Genehmigung von Wikipedia.
Die Frage
SuperNutzer-Leser LeNoob möchte wissen, wie ältere Windows-Versionen als Multitasking-Systeme ausgeführt werden konnten:
Ich habe gelesen, dass DOS ein Single-Tasking-Betriebssystem ist. Wenn ältere Versionen von Windows (auch Windows 95?) Lediglich Wrapper für DOS wären, wie könnten sie dann als Multitasking-Betriebssystem ausgeführt werden??
Gute Frage! Wie konnten ältere Windows-Versionen als Multitasking-Systeme ausgeführt werden??
Die Antwort
SuperUser-Mitwirkende Bob und Pete haben die Antwort für uns. Zunächst einmal, Bob:
Windows 95 war weit mehr als "nur ein Wrapper" für MS-DOS. Raymond Chen zitiert:
- MS-DOS diente zwei Zwecken in Windows 95: 1.) Es diente als Bootloader. & 2.) Es fungierte als 16-Bit-Gerätetreiber-Layer.
Tatsächlich hat Windows 95 fast alle MS-DOS-Programme mit einem Haken versehen / überschrieben, wobei es als Kompatibilitätsebene verwendet wird, während es selbst das schwere Anheben übernimmt. Außerdem wurde ein vorbeugendes Multitasking für 32-Bit-Programme implementiert.
Vor Windows 95
Windows 3.x und älter waren meistens 16-Bit (mit Ausnahme von Win32s, einer Art Kompatibilitätsschicht, die 16 und 32 überbrückt, aber wir werden das hier ignorieren), waren eher von DOS abhängig und verwendeten nur kooperatives Multitasking - das ist der Punkt, an dem sie kein laufendes Programm zum Ausschalten zwingen; Sie warten darauf, dass das laufende Programm die Kontrolle übernimmt (im Grunde sagen Sie "Ich bin fertig"), indem Sie dem Betriebssystem sagen, dass es das nächste wartende Programm ausführen soll..
- Multi-Tasking war wie in früheren Versionen von MacOS kooperativ (allerdings im Gegensatz zu Multi-Tasking-DOS 4.x, das ein vorbeugendes Multitasking beinhaltete). Eine Aufgabe musste sich dem Betriebssystem ergeben, um eine andere Aufgabe zu planen. Die Erträge wurden in bestimmte API-Aufrufe eingebaut, insbesondere für die Nachrichtenverarbeitung. Solange eine Aufgabe Nachrichten rechtzeitig verarbeitet hat, war alles großartig. Wenn eine Task die Verarbeitung von Nachrichten beendet hat und mit der Ausführung einer Verarbeitungsschleife beschäftigt war, war das Multitasking nicht mehr möglich.
Windows 3.x-Architektur
Wie würden frühe Windows-Programme die Kontrolle übernehmen:
- Windows 3.1 verwendet kooperatives Multitasking. Dies bedeutet, dass jede Anwendung, die gerade ausgeführt wird, angewiesen wird, eine Nachrichtenwarteschlange regelmäßig zu überprüfen, um herauszufinden, ob eine andere Anwendung die Verwendung der CPU anfordert diese Anwendung. Viele Windows 3.1-Anwendungen würden die Nachrichtenwarteschlange jedoch nur selten oder gar nicht überprüfen und die Kontrolle über die CPU so lange ausüben, wie sie es benötigt. Ein vorbeugendes Multitasking-System wie Windows 95 nimmt die CPU-Kontrolle von einer laufenden Anwendung ab und verteilt sie an diejenigen, die eine höhere Priorität haben, je nach den Anforderungen des Systems.
Quelle
Alles, was DOS sehen würde, ist, dass diese einzige Anwendung (Windows oder andere) ausgeführt wird, die die Kontrolle weitergibt, ohne zu beenden. Theoretisch kann das vorbeugende Multitasking möglicherweise ohnehin über Echtzeituhr und Hardware-Interrupts implementiert werden, um dem Scheduler zwangsweise die Kontrolle zu geben. Wie Tonny kommentiert, wurde dies tatsächlich von einigen Betriebssystemen ausgeführt, die auf DOS laufen.
386 erweiterter Modus?
Hinweis: Es wurden einige Kommentare dazu abgegeben, dass der erweiterte 386-Modus von Windows 3.x 32-Bit ist und das vorbeugende Multitasking unterstützt.
Dies ist ein interessanter Fall. Um den verknüpften Blogbeitrag zusammenzufassen, war der 386-Modus im Wesentlichen ein 32-Bit-Hypervisor, auf dem virtuelle Maschinen ausgeführt wurden. In einer dieser virtuellen Maschinen war der Windows 3.x-Standardmodus ausgeführt, der alle oben aufgeführten Dinge erledigt.
MS-DOS würde auch innerhalb dieser virtuellen Maschinen ausgeführt, und anscheinend waren sie zuvor mehrfach mit mehreren Aufgaben ausgestattet. Es scheint also, dass der 386 Hypervisor mit erweitertem Modus CPU-Zeitscheiben zwischen den virtuellen Maschinen teilt (von denen eine normale Version 3.x und andere, auf denen MS-DOS ausgeführt wurde, und jede VM wird ihre eigene Sache tun - 3.x würde kooperativ Multi-Task ausführen, während MS-DOS Single-Task wäre.
MS-DOS
DOS war auf Papier Single-Tasking, unterstützte jedoch TSR-Programme, die im Hintergrund blieben, bis sie durch einen Hardware-Interrupt ausgelöst wurden. Weit weg von echtem Multitasking, aber auch nicht vollständig für Einzelaufgaben.
All dieses Gerede von Bit-Ness? Ich habe nach Multi-Tasking gefragt!
Nun, genau genommen sind Bitdness und Multitasking nicht voneinander abhängig. Es sollte möglich sein, jeden Multitasking-Modus in beliebiger Bit-Art zu implementieren. Mit der Umstellung von 16-Bit-Prozessoren auf 32-Bit-Prozessoren wurden jedoch auch andere Hardwarefunktionalitäten eingeführt, die die Implementierung von vorbeugendem Multitasking möglicherweise vereinfacht hätten.
Da 32-Bit-Programme neu waren, war es auch einfacher, sie zum Laufen zu bringen, wenn sie zwangsweise ausge- schaltet wurden - was einige alte 16-Bit-Programme möglicherweise beschädigt hat.
Das ist natürlich alles Spekulation. Wenn Sie wirklich wissen möchten, warum MS in Windows 3.x (trotz des erweiterten 386-Modus) kein vorbeugendes Multitasking implementiert hat, müssen Sie jemanden fragen, der dort gearbeitet hat.
Ich wollte auch Ihre Annahme korrigieren, dass Windows 95 nur ein Wrapper für DOS ist.
Gefolgt von der Antwort von Pete:
In einem modernen Betriebssystem steuert das Betriebssystem alle Hardwareressourcen, und laufende Anwendungen werden in Sandboxen aufbewahrt. Eine Anwendung darf nicht auf Speicher zugreifen, den das Betriebssystem dieser Anwendung nicht zugewiesen hat, und sie kann nicht direkt auf Hardwaregeräte im Computer zugreifen. Wenn Hardware-Zugriff erforderlich ist, muss die Anwendung über Gerätetreiber kommunizieren.
Das Betriebssystem kann diese Steuerung erzwingen, da die CPU dazu gezwungen wird, in den geschützten Modus zu wechseln.
DOS geht dagegen nie in den geschützten Modus über, sondern bleibt im Real-Modus (*siehe unten). Im Realmodus können die laufenden Anwendungen alles ausführen, was sie möchten, d. H. Direkt auf die Hardware zugreifen. Eine Anwendung, die im Real-Modus läuft, kann der CPU jedoch auch mitteilen, dass sie in den Schutzmodus wechseln soll.
Und dieser letzte Teil ermöglicht es Anwendungen wie Windows 95, eine Multithread-Umgebung zu starten, obwohl sie grundsätzlich über DOS gestartet wurden.
DOS (Disk Operating System) war meines Wissens nicht viel mehr als ein Dateiverwaltungssystem. Es bot ein Dateisystem, Mechanismen zum Navigieren im Dateisystem, einige Werkzeuge und die Möglichkeit, Anwendungen zu starten. Es erlaubte auch einigen Anwendungen, resident zu bleiben, d. H. Maustreibern und EMM-Emulatoren. Es wurde jedoch nicht versucht, die Hardware im Computer so zu steuern, wie dies ein modernes Betriebssystem tut.
*Bei der ersten Erstellung von DOS in den 70er Jahren gab es keinen geschützten Modus in der CPU. Erst mit dem 80286-Prozessor Mitte der 80er Jahre wurde der geschützte Modus Teil der CPU.
Browsen Sie zum ursprünglichen Thread und lesen Sie die lebhafte Diskussion zu diesem Thema mithilfe des nachstehenden Links!
Haben Sie der Erklärung etwas hinzuzufügen? Sound off in den Kommentaren. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Hier geht es zum vollständigen Diskussionsthread.
