12Sep

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

click fraud protection

Wenn man bedenkt, dass DOS ein Single-Tasking-Betriebssystem war und die Verbindungen zu früheren Windows-Versionen hatte, wie schafften es frühere Versionen von Windows, Multitasking zu erreichen? Die heutige SuperUser Q & A-Post befasst sich mit den Antworten auf diese Frage.

Heutige Frage &Die Antwortsitzung kommt dank SuperUser, einer Unterteilung von Stack Exchange, einer Community-gesteuerten Gruppierung von Q & A-Websites, zu uns.

Windows 95 Screenshot mit freundlicher Genehmigung von Wikipedia.

Die Frage

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

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 konnten ältere Windows-Versionen als Multitasking-Systeme ausgeführt werden?

Die Antwort

SuperUser Mitwirkende Bob und Pete haben die Antwort für uns. Zuerst, Bob:

instagram viewer

Windows 95 war weit mehr als "nur ein Wrapper" für MS-DOS.Raymond Chen zitieren:

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

Windows 95 hat tatsächlich fast alle MS-DOS-Geräte gehakt / übergewichtet und sie als Kompatibilitätsschicht beibehalten, während sie selbst das schwere Heben durchgeführt hat. Es wurde auch präemptives Multitasking für 32-Bit-Programme implementiert.

Pre-Windows 95

Windows 3.x und älter waren meistens 16-Bit( mit Ausnahme von Win32s, eine Art Kompatibilitätsschicht, die 16 und 32 überbrückt, aber wir werden das hier ignorieren), waren mehr von DOS abhängig, undverwendet nur kooperatives Multitasking - das ist das eine, wo 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 ich dem Betriebssystem sage, dass es das nächste Programm, das wartet, ausführt).

  • Multitasking war kooperativ, genau wie in alten Versionen von MacOS( allerdings im Gegensatz zu Multitasking DOS 4.x, welches präemptives Multitasking hatte).Eine Aufgabe musste dem Betriebssystem überlassen werden, um eine andere Aufgabe zu planen. Die Renditen wurden in bestimmte API-Aufrufe integriert, insbesondere in die Nachrichtenverarbeitung. Solange eine Aufgabe zeitnah verarbeitet wurde, war alles super. Wenn eine Task die Verarbeitung von Nachrichten beendete und mit der Ausführung einer Verarbeitungsschleife beschäftigt war, war Multitasking nicht mehr möglich.

Windows 3.x Architektur

Wie schnell Windows-Programme die Kontrolle übernehmen:

  • Windows 3.1 verwendet kooperatives Multitasking - das bedeutet, dass jede laufende Anwendung angewiesen wird, regelmäßig eine Nachrichtenwarteschlange zu überprüfen, um festzustellen, ob sie vorhanden istEine andere Anwendung fragt nach der Verwendung der CPU und, falls dies der Fall ist, um die Steuerung für diese Anwendung zu ermöglichen. Viele Windows 3.1-Anwendungen würden jedoch die Nachrichtenwarteschlange nur selten oder gar nicht überprüfen und die Steuerung der CPU so lange beanspruchen, wie sie benötigt wird. Ein präventives Multitasking-System wie Windows 95 wird die CPU-Kontrolle von einer laufenden Anwendung wegnehmen und sie an diejenigen verteilen, die eine höhere Priorität haben, basierend auf den Systemanforderungen.

Quelle

Alle DOS würde sehen, dass diese einzelne Anwendung( Windows oder andere) ausgeführt wird, die Kontrolle ohne zu beenden weitergeben würde. Theoretisch kann präventives Multitasking unter Verwendung einer Echtzeituhr und Hardware-Interrupts möglicherweise trotzdem auf DOS implementiert werden, um dem Scheduler zwangsweise die Kontrolle zu geben. Wie Tonny bemerkt, wurde dies tatsächlich von einigen Betriebssystemen getan, die auf DOS laufen.

386 Erweiterter Modus?

Hinweis: Es gab einige Kommentare zum erweiterten 386-Modus von Windows 3.x als 32-Bit-Version und unterstützt präemptives Multitasking.

Dies ist ein interessanter Fall. Um den verknüpften Blogpost zusammenzufassen, war der erweiterte 386-Modus im Grunde ein 32-Bit-Hypervisor, auf dem virtuelle Maschinen ausgeführt wurden. Auf einer dieser virtuellen Maschinen lief der Standardmodus von Windows 3.x, der all die oben genannten Dinge erledigt.

MS-DOS würde auch innerhalb dieser virtuellen Maschinen laufen, und anscheinend waren sie präemptiv multi-tasked - so scheint es, dass der erweiterte Hypervisor 386 CPU-Zeitscheiben zwischen den virtuellen Maschinen teilt( von denen eine normale 3.x liefund andere, die MS-DOS ausgeführt haben), und jede VM wird ihre eigene Sache machen - 3.x würde kooperativ Multi-Task, während MS-DOS Single-Task wäre.

MS-DOS

DOS selbst war Single-Tasking auf dem Papier, aber es hatte Unterstützung für TSR-Programme, die im Hintergrund bleiben würde, bis sie durch einen Hardware-Interrupt ausgelöst werden. Weit davon entfernt, wirklich Multitasking zu betreiben, aber auch nicht voll single-tasked.

All dieses Gerede von Bit-Ness? Ich fragte nach Multitasking!

Eigentlich sind Bit-Ness und Multitasking nicht voneinander abhängig. Es sollte möglich sein, irgendeinen Multitasking-Modus in irgendeiner Bit-Form zu implementieren. Mit der Umstellung von 16-Bit-Prozessoren auf 32-Bit-Prozessoren wurde jedoch auch eine andere Hardwarefunktionalität eingeführt, mit der sich präemptives Multitasking einfacher implementieren ließe.

Da 32-Bit-Programme neu waren, war es einfacher, sie zum Laufen zu bringen, wenn sie zwangsweise ausgeschaltet wurden - was einige ältere 16-Bit-Programme zerstört haben könnte.

Natürlich ist das alles Spekulation. Wenn Sie wirklich wissen wollen, warum MS in Windows 3.x kein präemptives Multitasking implementiert hat( ungeachtet des erweiterten 386-Modus), 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 ist.

Gefolgt von der Antwort von Pete:

In einem modernen Betriebssystem steuert das Betriebssystem alle Hardwareressourcen und laufende Anwendungen werden in Sandboxes gespeichert. 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 OS kann dieses Steuerelement erzwingen, da es die CPU in den geschützten Modus versetzt.

DOS hingegen tritt nie in den geschützten Modus ein, sondern bleibt im Real-Modus( * siehe unten).Im realen Modus können die laufenden Anwendungen alles ausführen, was sie wollen, d. H. Direkt auf die Hardware zugreifen. Eine Anwendung, die im Realmodus ausgeführt wird, 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, soweit ich weiß, 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 blieben, d. H. Maustreiber und EMM-Emulatoren. Aber es hat nicht versucht, die Hardware im Computer so zu steuern, wie es ein modernes Betriebssystem tut.

* Als DOS in den 1970er Jahren zum ersten Mal erstellt wurde, war der geschützte Modus in der CPU nicht vorhanden. Erst mit dem 80286 Prozessor Mitte der 1980er Jahre wurde der geschützte Modus Teil der CPU.

Stellen Sie sicher, dass Sie zum ursprünglichen Thema wechseln und lesen Sie die lebhafte Diskussion zu diesem Thema mit dem folgenden Link!

Haben Sie etwas zur Erklärung hinzuzufügen? Ton in den Kommentaren ab. Möchten Sie mehr Antworten von anderen technisch versierten Stack Exchange Benutzern lesen? Sehen Sie sich den vollständigen Diskussionsfaden hier an.