Wie war Multitasking in älteren Windows-Versionen möglich?

Wenn man bedenkt, dass DOS ein Single-Tasking-Betriebssystem war und es mit frühen Windows-Versionen verbunden war, wie haben frühere Versionen von Windows es geschafft, Multitasking zu erreichen? Der heutige SuperUser Q&A-Post befasst sich mit den Antworten auf diese Frage.

Die Frage

SuperUser-Leser LeNoob möchte wissen, wie ältere Windows-Versionen als Multitasking-Systeme laufen konnten?:

Ich habe gelesen, dass DOS ein Single-Tasking-Betriebssystem ist. Aber wenn ältere Versionen von Windows (einschließlich Windows 95?) nur Wrapper für DOS wären, wie könnten sie dann als Multitasking-Betriebssystem laufen?

Gute Frage! Wie haben es ältere Windows-Versionen geschafft, als Multitasking-Systeme zu laufen?

Die Antwort

Die SuperUser-Mitwirkenden Bob und Pete haben die Antwort für uns. Zuerst, Bob:

Windows 95 war weit mehr als „nur ein Wrapper“ für MS-DOS. Zitat von Raymond Chen:

• MS-DOS diente in Windows 95 zwei Zwecken: 1.) Es diente als Bootloader. & 2.) Es fungierte als die 16-Bit-Legacy-Gerätetreiberschicht.

Windows 95 hat eigentlich fast alles MS-DOS überschrieben und es als Kompatibilitätsschicht beibehalten, während es die ganze schwere Arbeit selbst erledigt. Es implementiert auch präventives Multitasking für 32-Bit-Programme.

Prä-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 das werden wir hier ignorieren), waren stärker von DOS abhängig und verwendeten nur kooperatives Multitasking – das ist diejenige, bei der sie ein laufendes Programm nicht zum Umschalten zwingen; Sie warten, bis das laufende Programm die Kontrolle übergibt (im Grunde sagen Sie „Ich bin fertig“, indem Sie dem Betriebssystem sagen, dass es das nächste wartende Programm ausführen soll).

• Multitasking war kooperativ, genau wie in alten Versionen von MacOS (allerdings im Gegensatz zu Multitasking DOS 4.x, das präventives Multitasking aufwies). Eine Aufgabe musste dem Betriebssystem weichen, um eine andere Aufgabe zu planen. Die Erträge wurden in bestimmte API-Aufrufe integriert, insbesondere in die Nachrichtenverarbeitung. Solange eine Aufgabe Nachrichten zeitnah verarbeitete, war alles super. Wenn eine Aufgabe die Verarbeitung von Nachrichten beendete und damit beschäftigt war, eine Verarbeitungsschleife auszuführen, gab es kein Multitasking mehr.

Windows 3.x-Architektur

Wie frühe Windows-Programme die Kontrolle übernehmen würden:

• Windows 3.1 verwendet kooperatives Multitasking – das bedeutet, dass jede laufende Anwendung angewiesen wird, regelmäßig eine Nachrichtenwarteschlange zu überprüfen, um herauszufinden, ob eine andere Anwendung die CPU-Nutzung anfordert, und wenn ja, die Kontrolle an diese Anwendung. Viele Windows 3.1-Anwendungen überprüfen die Nachrichtenwarteschlange jedoch nur selten oder gar nicht und monopolisieren die CPU-Steuerung so lange wie erforderlich. Ein präventives Multitasking-System wie Windows 95 entzieht einer laufenden Anwendung die CPU-Steuerung und verteilt sie an diejenigen, die je nach Systemanforderungen eine höhere Priorität haben.

Quelle

Alles, was DOS sehen würde, ist diese einzelne Anwendung (Windows oder andere), die ausgeführt wird und die die Kontrolle weitergibt, ohne sie zu beenden. Theoretisch kann präemptives Multitasking möglicherweise sowieso auf DOS implementiert werden, indem eine Echtzeituhr und Hardware-Interrupts verwendet werden, um dem Scheduler die Kontrolle zu erzwingen. Wie Tonny Kommentare, dies wurde tatsächlich von einigen Betriebssystemen durchgeführt, die auf DOS ausgeführt wurden.

386 Erweiterter Modus?

Hinweis: Es gab einige Kommentare zu 386 erweiterter Modus von Windows 3.x ist 32-Bit und unterstützt präemptives Multitasking.

Dies ist ein interessanter Fall. Um das verlinkte zusammenzufassen Blogeintrag, 386 Enhanced Mode war im Grunde ein 32-Bit-Hypervisor, der virtuelle Maschinen ausführte. Auf einer dieser virtuellen Maschinen lief der Windows 3.x-Standardmodus, der alle oben aufgeführten Aufgaben erledigt.

MS-DOS würde auch innerhalb dieser virtuellen Maschinen laufen, und anscheinend waren sie präventiv Multitasking-fähig – es scheint also, dass der 386-Hypervisor im erweiterten Modus die CPU-Zeitscheiben zwischen den virtuellen Maschinen teilt (von denen eine normale 3.x und lief). andere, auf denen MS-DOS ausgeführt wurde), und jede VM macht ihr eigenes Ding – 3.x würde kooperativ Multitasking betreiben, während MS-DOS Singletasking wäre.

MS-DOS

DOS selbst war auf dem Papier Single-Tasking, hatte aber Unterstützung für TSR Programme, die im Hintergrund bleiben würden, bis sie durch einen Hardware-Interrupt ausgelöst werden. Weit entfernt von echtem Multitasking, aber auch nicht vollständig Singletasking.

Das ganze Gerede von Bitness? Ich fragte nach Multitasking!

Nun, streng genommen sind Bitness und Multitasking nicht voneinander abhängig. Es sollte möglich sein, jeden Multi-Tasking-Modus in jeder Bit-Nheit zu implementieren. Der Wechsel von 16-Bit-Prozessoren zu 32-Bit-Prozessoren führte jedoch auch andere Hardwarefunktionen ein, die die Implementierung von präventivem Multitasking hätten erleichtern können.

Da 32-Bit-Programme neu waren, war es außerdem einfacher, sie zum Laufen zu bringen, wenn sie gewaltsam ausgetauscht wurden – was möglicherweise einige ältere 16-Bit-Programme beschädigt hat.

Natürlich ist das alles Spekulation. Wenn Sie wirklich wissen möchten, warum MS in Windows 3.x (trotz des erweiterten Modus 386) kein präventives Multitasking implementiert hat, müssen Sie jemanden fragen, der dort gearbeitet hat.

Außerdem wollte ich Ihre Annahme korrigieren, dass Windows 95 nur ein Wrapper für DOS war.

Gefolgt von der Antwort von Pete:

In einem modernen Betriebssystem kontrolliert das Betriebssystem alle Hardware-Ressourcen, und laufende Anwendungen werden in Sandboxen gehalten. 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 Hardwarezugriff erforderlich ist, muss die Anwendung über Gerätetreiber kommunizieren.

Das Betriebssystem kann diese Kontrolle erzwingen, da es die CPU zum Eingeben zwingt Sicherheitsmodus.

DOS hingegen geht nie in den geschützten Modus, sondern bleibt im Real-Modus (*siehe unten). Im Real-Modus können die laufenden Anwendungen alles ausführen, was sie wollen, dh direkt auf Hardware zugreifen. Eine im Realmodus ausgeführte Anwendung kann der CPU jedoch auch mitteilen, in den geschützten Modus zu wechseln.

Und dieser letzte Teil ermöglicht es Anwendungen wie Windows 95, eine Multithread-Umgebung zu starten, obwohl sie im Grunde von 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 Tools und die Möglichkeit, Anwendungen zu starten. Es ermöglichte auch, dass einige Anwendungen resident bleiben, dh Maustreiber und EMM-Emulatoren. Es wurde jedoch nicht versucht, die Hardware im Computer so zu steuern, wie es ein modernes Betriebssystem tut.

*Als DOS in den 1970er Jahren zum ersten Mal entwickelt wurde, existierte der geschützte Modus in der CPU nicht. Erst mit dem 80286-Prozessor Mitte der 1980er Jahre wurde der Protected Mode Teil der CPU.

Stöbern Sie unbedingt im Original-Thread und lesen Sie sich die lebhafte Diskussion zu diesem Thema über den unten stehenden Link durch!

Möchten Sie der Erklärung noch etwas hinzufügen? Ton aus in den Kommentaren. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange-Benutzern lesen? Sehen Sie sich hier den vollständigen Diskussionsthread an.