Wie war Multitasking in der alten Windows-Version möglich, wenn DOS Single-Tasking ist?

23387
Arkonix

Ich habe gelesen, dass DOS ein Single-Tasking-Betriebssystem ist.

Aber wenn alte Versionen von Windows (auch Windows 95?) Nur DOS-Wrapper wären, wie könnte Windows dann als Multitasking-Betriebssystem laufen?

114
Es wird preemptives Multitasking genannt - http://support.microsoft.com/kb/117567 joeqwerty vor 10 Jahren 8
Sie werden "alt" viel besser definieren müssen. DOS + Windows 9x und DOS + Windows 3.x im "386 Enhanced Mode" unterschieden sich in dieser Hinsicht deutlich von DOS + Windows 3.x / 2.x im "Standard Mode" und "Real Mode". Und wie Joeqwerty anspielt, gab es sowohl kooperatives Multi-Tasking als auch präventives Vorgehen. Es wurden ganze Bücher darüber geschrieben, daher ist eine bestimmte Frage besser. JdeBP vor 10 Jahren 20
@joeqwerty Die tollste IMO ist, dass Microsoft die Dokumentation über antike Software online hält. Es gibt sogar Artikel zu fortgeschrittenen Themen zu älteren Versionen von MS-DOS ... Wirklich nett, um das am Leben zu erhalten. NothingsImpossible vor 10 Jahren 5
@NothingsImpossible Bist du sarkastisch? (Ich kann es nicht sagen.) Wenn nicht, könnten Sie einen Link angeben (auch wenn es sich um eine Google-Suche handelt). Ich wäre sehr dankbar. Agi Hammerthief vor 10 Jahren 0
@NigelNquande Er spricht über den ersten Kommentar von Joeqwerty. Bob vor 10 Jahren 0
DOS gibt Ihnen kein Multitasking. Sie können weiterhin vollständig Multitasking-Programme darüber schreiben, ohne die Hilfe von DOS, wie es das frühe Windows tut. Windows 95 ist sicherlich nicht nur ein "Wrapper" für DOS. Boann vor 10 Jahren 6
@NigelNquande Hallo! Ich war nicht sarkastisch, es tut mir leid, wenn es so klang. Hier ist zum Beispiel ein Artikel zum Partitionieren von Festplatten unter MS-DOS http://support.microsoft.com/kb/69912/en-us NothingsImpossible vor 10 Jahren 2
Keine Sorge, @NothingsImpossible; Es ist nur so, dass nach meiner Erfahrung Microsoft eine lästige Tendenz hat, jegliche Dokumentation über jedes ihrer Betriebssysteme (DOS-2000) zu löschen, die nicht zu den neuesten Versionen (ab XP) gehört. Daher wurde mir vorgeworfen, dass jede Dokumentation über antik erscheint Software existiert auf ihrer Website. Danke, dass Sie sich bei mir melden. Agi Hammerthief vor 10 Jahren 0
@NigelNquande Ich habe tatsächlich festgestellt, dass MS ziemlich gut in der Pflege alter Dokumentation ist. Die meisten ihrer zurückgezogenen KB-Artikel sind online (z. B. eine zufällige [Windows 3.1-KB] (http://support.microsoft.com/kb/93363) oder Dokumente des Dienstprogramms [`print] (http: //). support.microsoft.com/kb/58143) für Windows 2.1-3.0 oder [ansi.sys] (http://support.microsoft.com/kb/74578/en-us) von MS-DOS 5.0), auch nach ihre festgesetzte Frist von zwölf Monaten zum Lebensende. Es ist einfach nicht so einfach zu durchsuchen wie die aktive Produktdokumentation, Sie müssen bei Ihren Suchvorgängen bestimmte Angaben machen. Jason C vor 10 Jahren 3
Verwandte: http://superuser.com/questions/496099/was-windows-95-an-operating-system shantnu vor 10 Jahren 0
Microsoft behauptete tatsächlich, MS-DOS sei Multitasking, da im Hintergrund ein Druckauftrag ausgeführt werden könne. liftarn vor 10 Jahren 0
@SVilcans MS DOS war Multitasking, die Aufgaben konnten jedoch nicht gleichzeitig ausgeführt werden. Das Betriebssystem könnte Aufgaben planen, die jeweils ein Zeitfenster zuweisen, jedoch nicht mehrere CPUs gleichzeitig steuern. jwenting vor 10 Jahren 0
@ jwenting - Ich bin mir ziemlich sicher, dass Standard-MS-DOS * nicht * Multitasking war. Ich kenne keinen Fall, in dem MS-DOS Zeitfenster mit mehreren Aufgaben verschachtelt hat, es sei denn, Sie zählen Tricks von TSR-Programmen (Terminate and Stay Resident), die den Timer-Interrupt verwenden (und diese würden im Wesentlichen Multitasking über DOS anstatt über DOS implementieren) Unterstützung für in DOS integriertes Multitasking). antinome vor 10 Jahren 3
@joeqwerty DOS (und Windows zumindest vor Win95) waren definitiv * nicht * [präemptiv multitasked] (https://en.wikipedia.org/wiki/Preemptive_multitasking#Preemptive_multitasking). DOS selbst hat kein Multitasking, obwohl, wie Antinome feststellt, es möglich war, einige Tricks auszuführen, um den Eindruck zu erwecken, als ob Sie Multitasking machen würden. a CVn vor 10 Jahren 2
@ MichaelKjörling - Das OP fragte, wie `Windows`, einschließlich` Windows 95`, Multitasking handhabt. Ich habe auf einen TechNet-Artikel verwiesen, der ihn erklärt hat. Der Artikel ist direkt aus dem Munde des Pferdes, wenn Sie so wollen, also würde ich sagen, dass Windows 95 `pre` preemptives Multitasking verwendet. joeqwerty vor 10 Jahren 0
@Joeqwerty Ich denke, es hängt von deiner Definition von "alten Versionen von Windows" ab. Ich habe in den späten 80er Jahren einige Zeit mit dem ernsthaften Einsatz von Computern begonnen, noch bevor Windows 3.0 auf den Markt kam und der i386 verfügbar gemacht wurde. Der von Ihnen verknüpfte Artikel besagt nur, dass Windows 95 für 32-Bit-Prozesse präventives Multitasking verwendet. ** Der Punkt meines Kommentars ** war: "Wie kann Windows als Multitasking-Betriebssystem ausgeführt werden?" wird von Ihrem ersten Kommentar nicht beantwortet "Es heißt preemptives Multitasking". a CVn vor 10 Jahren 0

8 Antworten auf die Frage

161
Bob

Windows 95

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

MS-DOS diente zwei Zwecken in Windows 95.

  • Es diente als Bootloader.
  • Es fungierte als 16-Bit-Treiber für ältere Geräte.

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 das preemptive 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 mehr von DOS abhängig und verwendeten nur kooperatives Multitasking - das ist der, bei 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 das Betriebssystem anweisen, das nächste wartende Programm auszuführen).

Multitasking war wie in früheren Versionen von MacOS kooperativ (allerdings im Gegensatz zu Multitasking DOS 4.x, das präventives Multitasking aufwies). 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 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, und falls ja, Kontrolle über diese Anwendung zu geben . 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 preemptives 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 preemptives 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 preemptives Multitasking unterstützt.

Dies ist ein interessanter Fall. Um den verknüpften Blogbeitrag zusammenzufassen, war der 386-Modus im Wesentlichen ein 32-Bit-Hypervisor, der virtuelle Maschinen ausführte. 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 präemptiv Multitasking - so scheint es, dass der 386 Hypervisor mit erweitertem Modus CPU-Zeitscheiben zwischen den virtuellen Maschinen teilt (eine davon lief auf normalem 3.x und andere, auf denen MS ausgeführt wurde -DOS), und jede VM erledigt ihre eigene Sache - 3.x würde gemeinsam Multitasking ausführen, während MS-DOS Einzelaufgabe ausführen würde.

MS-DOS

DOS selbst war auf Papier Single-Tasking, unterstützte aber 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 Multitasking gefragt!

Nun, genau genommen sind Bititess und Multitasking nicht voneinander abhängig. Es sollte möglich sein, jeden Multitasking-Modus in beliebiger Bit-Qualität 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 preemptive Multitasking vereinfacht hätten.

Da 32-Bit-Programme neu sind, war es auch einfacher, sie zum Laufen zu bringen, wenn sie gewaltsam gewechselt wurden - was einige alte 16-Bit-Programme möglicherweise beschädigt hat.

Das ist natürlich alles Spekulation. Wenn Sie wirklich wissen wollen, warum MS unter Windows 3.x kein preemptives Multitasking (ungeachtet des erweiterten 386-Modus) 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.

Sehr schönes Schreiben. Wenn ich mich recht erinnere (die OS-Designklasse war vor vielen Jahren für mich), hat Windows 9x die Timer-Interrupts angehängt, um seinen eigenen Scheduler zu erzwingen, genau wie Sie es in Ihrem vorletzten Absatz vorgeschlagen haben. Es gab andere Betriebssysteme zusätzlich zu DOS, die dasselbe taten. Ich erinnere mich noch genau an AMX (Echtzeit-Betriebssystem für industrielle Anwendungen) und XINU (Lernzweck kleine Unix / Posix-ähnliche Betriebssysteme), die beide auf DOS liefen. (AMX konnte Bare-Metal auch direkt vom EPROM ausführen. Das Testen und Debuggen war unter DOS viel einfacher. Es wurde vermieden, dass EPROMS für jeden Test neu gebrannt wurden.) Tonny vor 10 Jahren 4
@Tonny Vielen Dank für die Bestätigung, dass dieses Schema möglich ist (und in der Praxis verwendet wird). Vermutlich ist der Grund, warum Windows 1-3 kein preemptives Multitasking verwendet hat, nicht so sehr der Fall, dass sie dies nicht tun konnten (MS-DOS 4 hatte es, obwohl es nicht veröffentlicht wurde) Programme. Bob vor 10 Jahren 0
Mmmmhhh In Anbetracht von Windows 1-3: Die Tatsache, dass es sich bei 8086-CPUs und höher um eine gängige Codebasis handelt, hat möglicherweise mehr damit zu tun. Die korrekte Handhabung von Ring0-3 war nur mit 80286 und höher möglich, und so verwendete Win9x Multitasking. 4DOS und andere hatten bereits ein begrenztes Multitasking unter DOS (80286 war erforderlich, wenn ich mich richtig erinnere). Sie können Win3 sogar als separaten Prozess in 4DOS ausführen. Tonny vor 10 Jahren 3
Aus Sicht von DOS lief also nur eine Anwendung - Windows, die andere 3.x-Anwendungen "enthielt" und deren parallele Ausführung basierend auf kooperativem Multitasking (freiwilliges Nachgeben) verwaltete. Kann gesagt werden, dass die Parallelität in diesem Fall von Threads auf Benutzerebene durchgeführt wurde? Arkonix vor 10 Jahren 0
Xinu lief wirklich nicht ** über DOS. Es war immerhin ein LSI-11-Betriebssystem. Die Aussage, dass es in DOS + Windows 3.x kein präventives Multitasking gab, ist false. Im 386 Enhanced Mode gab es mit freundlicher Genehmigung des VMM. Und der Quatsch über 4DOS liefert Ihnen eine häufig gegebene Antwort: [4DOS ist kein Betriebssystem] (http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/4dos-isnot-an-operating-system). html). Aussagen, die Multitasking zur Verfügung gestellt haben, sind völlig falsch. JdeBP vor 10 Jahren 1
@Tonny [MS-DOS 4.0] (http://blogs.msdn.com/b/larryosterman/archive/2004/03/22/94209.aspx) hatte präventives Multitasking und arbeitete offenbar an der 8086 (?). Beachten Sie, dass MS-DOS 4.0 nicht dasselbe ist wie [4DOS] (http://en.wikipedia.org/wiki/4DOS). Bob vor 10 Jahren 0
@JdeBP [MS-DOS 4.0] (http://blogs.msdn.com/b/larryosterman/archive/2004/03/22/94209.aspx) (anders als 4DOS) war dagegen ein Multitasking OS. Könnten Sie das präemptive Multitasking in 3.x näher erläutern? Geben Sie vielleicht eine eigene Antwort (Quelle)? Ich gebe zu, ich bin nicht sehr vertraut mit den Internen dieser Betriebssysteme, und es besteht die Möglichkeit, dass ein großer Teil meiner Antwort falsch ist - wenn ja, korrigieren Sie mich bitte! Bob vor 10 Jahren 0
* "Windows 3.x und älter waren rein 16-bit" *, da * rein * falsch ist! Schauen Sie sich [win32s] (http://en.wikipedia.org/wiki/Win32s) an und auch ohne den * 386 Enhanced Mode * hatten einige 32-Bit-Teile, zumindest Festplattentreiber für eine verbesserte E / A-Leistung. hyde vor 10 Jahren 0
@hyde Win32s ist scheinbar eine Ausnahme, obwohl es anscheinend nicht zum Kernbetriebssystem gehörte. Was den erweiterten 386-Modus angeht, wurde lediglich eine Kopie des Standards 3.x (http://blogs.msdn.com/b/oldnewthing/archive/2010/05/17/10013609.aspx) in einer VM ausgeführt, und Alle Anwendungen liefen noch unter 16-Bit-Windows. Es war praktisch ein 32-Bit-Hypervisor. Ich werde diese Informationen jedoch bearbeiten - danke, dass ich sie nachschlagen kann;) Bob vor 10 Jahren 0
@ Bob Ja, aber das ist genug, um falsch zu sagen, dass es * nur * 16 Bit war. Und diese optionalen 32-Bit-Teile haben einige Dinge wirklich verbessert, und (bei Wikipedia) waren einige bemerkenswerte Anwendungen erforderlich. hyde vor 10 Jahren 0
@hyde Richtig, vielleicht war meine Formulierung etwas stark. Fest. Bob vor 10 Jahren 0
Der 286 (ein 16-Bit-Prozessor) führte den geschützten Modus ein und damit fast alle Funktionen, die ein präventives Multitasking lohnen. Der geschützte Modus war zu dieser Zeit jedoch fast vollständig mit DOS inkompatibel (viele Annahmen im Realmodus über Segmente gelten im geschützten Modus nicht ohne viel Hacker). Das Zurückschalten in den Realmodus des 286 erforderte ein CPU-Reset. cHao vor 10 Jahren 0
Der PDP-8 unterstützte präventives Multitasking, und dies war nur ein 12-Bit-Computer. david25272 vor 10 Jahren 2
Ich würde es nicht als Hypervisor bezeichnen, da dies eine vollständige Maschinenvirtualisierung bedeuten würde. Windows 95 konnte einen Adressraum für Prozesse und einige E / A virtualisieren, die Virtualisierung war jedoch nicht abgeschlossen. david25272 vor 10 Jahren 0
@ david25272: Nahezu jeder Prozessor "unterstützt" preemptives Multitasking; Alles was es braucht, ist die Möglichkeit, Register zu speichern und zu laden und Hardware-Interrupts zu unterstützen. Aber ohne die Fähigkeit, Prozesse voreinander zu schützen, ist dies mehr Ärger als es wert ist - im Grunde nur halbherziges Threading mit allen damit verbundenen Problemen. Was den PDP-8 angeht, kümmert das niemanden. :) Es ist hier völlig irrelevant, kein DOS- oder Windows-Rechner zu sein. cHao vor 10 Jahren 0
@cHao: Das Problem war nicht so sehr die Annahme des 8086-Programmierers in Bezug auf Segmente, sondern vielmehr die Annahme der 80286-Designer bezüglich der Verwendung von Segmenten. Der 80286-Entwurf funktioniert wirklich nur gut, wenn es eine relativ kleine Anzahl von Speicherpools mit jeweils 64 KB gibt, aus denen Objekte zugewiesen werden, und Objekte können je nach ihrem Zweck in Speicherpools platziert werden, so dass alle Objekte für einen bestimmten Zweck geeignet sind im selben Pool wohnen. Im Gegensatz dazu kann der 8086 mit einer großen Anzahl kleiner Segmente effizient arbeiten. Einige Anwendungen können ... supercat vor 10 Jahren 0
Verwenden Sie mehr unterschiedliche Segmente, als der Deskriptor 80286-Segment verarbeiten kann (begrenzt auf 16.384 Einträge). Wenn Sie zulassen, dass sich jedes Objekt in einem eigenen Segment befindet, müssen sich Anwendungen nicht umständliches Verhalten sorgen, z. B. in der Nähe von Speicheradressen, die ein Vielfaches von 65.536 Byte sind. Wenn dagegen eine Anwendung zweiunddreißig 32K-Segmente erstellt, erstellt dies effektiv alle 32K eine Grenze, die Objekte nicht ohne weiteres überspannen können. supercat vor 10 Jahren 0
@cHao - Ich habe gerade kommentiert, dass CPU-Funktionen (z. B. die Möglichkeit, Speicherverwaltungsanweisungen abzufangen), die (wie Sie darauf hinweisen) vorbeugendes Multitasking sinnvoll machen, vor 32-Bit-CPUs in der Nähe lagen. Der PDP-8 war nur ein Beispiel für eine frühe CPU mit diesen Funktionen. david25272 vor 10 Jahren 0
@ david25272: Ahh. Aus irgendeinem Grund habe ich am Ende gelesen, dass es so aussieht, als ob "Sie x86-Junkies denken, Sie hätten alles erfunden." :) cHao vor 10 Jahren 0
@supercat: Das Problem ist * genau *, wie vorhandene Segmente im Real-Modus-Code funktionieren. Um es klar zu sagen, ich meine nicht "schlecht" als eine schlechte Sache - es ist durchaus richtig, davon auszugehen, dass Segmente wie im 8086 funktionieren, wenn das Betriebssystem, für das Sie schreiben, den Prozessor im Grunde als schickes 8086 verwendet konnte nicht alle diese Annahmen unterstützen und trotzdem den Adressraum erweitern. Bis heute ist es immer noch nicht möglich - der virtuelle 8086-Modus emuliert im Wesentlichen nur den realen Modus mit den damit verbundenen Einschränkungen (und ein paar weitere beziehen sich in erster Linie auf die Gründe für den geschützten Modus). cHao vor 10 Jahren 0
@cHao: Durch den geschützten Modus konnte der Adressraum erweitert werden, während die 16-Bit-Segmentregister in einen ~ 3-Bit- "Selektor" und einen skalierten Offset von 13 Bit aufgeteilt wurden. Eine Hardwareadresse wird berechnet, indem der 13-Bit-Skalierungsversatz um einen von 8 konfigurierbaren Beträgen verschoben wird, einer von 8 konfigurierbaren Basiswerten hinzugefügt wird und dann ein 16-Bit-Offset hinzugefügt wird. Der Modus könnte mit den meisten PC-Realmodus-Codes hochgradig kompatibel sein, wenn alle Segmente außer 0xC000-0xDFFF für die 4-Bit-Skalierung konfiguriert und in einem Abstand von 128 KB angeordnet sind. supercat vor 10 Jahren 0
@cHao: Eine solche Architektur ist eigentlich das, was ich in heutigen Computern gerne sehen würde (obwohl sie wahrscheinlich 4 + 28 oder 5 + 27 Bit-Segmentregister verwendet). Ein solcher Entwurf würde es einem Framework wie der JVM oder .NET ermöglichen, auf Hunderte von Gigabyte Arbeitsspeicher zuzugreifen, während 32-Bit- statt 64-Bit-Objektreferenzen verwendet werden, wodurch die Cache-Leistung verbessert wird. supercat vor 10 Jahren 0
26
Hennes

Es wurde ständig ein einzelnes Programm ausgeführt, das als Fenster bezeichnet wurde. Dieser verteilt die CPU-Zeit (und andere Ressourcen) zwischen verschiedenen Programmen.

Betrachten Sie diese Analogie:

Sie haben ein Büro, das zu dieser Zeit nur eine Person haben kann (diese Person wird Herr oder Frau DOS genannt). Diese Person arbeitet zu einer Zeit an einer Sache. ZB ruft er eine einzelne Person an und beginnt mit ihm rund um die Uhr zu chatten.

Jetzt ersetzen Sie diese Person durch Herrn Sekretär. (Fenster). Es wird jemanden anrufen und ständig mit ihm sprechen (immer noch eine einzige Aufgabe). Nach einiger Zeit wird die andere Person sagen: "Ich habe jetzt genug gesprochen. Sprich mit jemandem und ruf mich ein bisschen an".

Herr Sekretär wird die andere Person anrufen. Chatte mit dieser Person, bis diese Person dasselbe sagt. Dann wird die nächste Person angerufen, bis sie am Ende der Liste der Personen ist, mit denen gesprochen werden soll. Zu diesem Zeitpunkt wird es wieder oben beginnen.

  • Technisch wird dies als kooperatives Multitasking bezeichnet. Die andere Person muss angeben, dass sie genügend CPU-Zeit hat. Wenn man das nicht tut, fällt alles auseinander.
  • Moderne Systeme sind viel intelligenter. Einschließlich präventives Multitasking. Denken Sie an die Sekretärin, die einen Wecker stellt und die andere Person nach 5 Minuten abschaltet. "Das ist nett, Jane. Aber ich muss jetzt mit Joe sprechen. Ich rufe dich ein bisschen zurück. - Klick."

Wenn Sie mehrere Prozessoren hinzufügen, wird es noch komplizierter. :)

Meinen Sie in Ihrem ersten Punkt nicht kooperatives / nicht präemptives Multitasking? Interessanterweise führte Windows 95 auch präemptives Multitasking für 32-Bit-Programme ein. Es war nicht so sehr ein Wrapper für DOS, da es ein Betriebssystem war, das DOS als Bootloader verwendete, jedoch einen großen Teil davon ersetzt (ausreichend für 16-Bit / DOS-Programmunterstützung). Bob vor 10 Jahren 1
Herr oder vermisst, warum nicht 'Dr.' DOS? gtrak vor 10 Jahren 0
"Es wurde kontinuierlich ein einzelnes Programm ausgeführt ... Dieses verteilt die CPU-Zeit (und andere Ressourcen) zwischen verschiedenen Programmen." kann das nicht über ein Betriebssystem gesagt werden? Obwohl die Frage impliziert, dass MS-DOS dies nicht konnte. Ich bin strikt gegen Analogien / Metaphern, wenn technische Details der Technik nicht verwendet werden. Ok, jetzt wissen wir, wie ein hypothetisches Büro funktioniert? Das erklärt die Antwort auf die Frage nicht wirklich. Celeritas vor 10 Jahren 1
13
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 wechselt dagegen nie in den geschützten Modus, sondern bleibt im Real-Modus *. Im realen Modus können die laufenden Anwendungen alles ausführen, was sie möchten, z. B. direkt auf Hardware. Eine Anwendung, die im Real-Modus läuft, kann der CPU jedoch auch mitteilen, dass sie in den Schutzmodus wechseln soll.

Und mit diesem letzten Teil können Anwendungen wie Windows 95 eine Multithreading-Umgebung starten, obwohl sie grundsätzlich über DOS gestartet wurden.

DOS (Disk Operating System) war, afaik, 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, z. B. Maustreiber und EMM-Emulatoren. Es wurde jedoch nicht versucht, die Hardware im Computer so zu steuern, wie dies ein modernes Betriebssystem tut.

* Als DOS erstmals in den 70er Jahren erstellt wurde, war der geschützte Modus in der CPU nicht vorhanden. Erst als der 80286-Prozessor in den 80er Jahren den geschützten Modus in die CPU integriert hat.

Beachten Sie, dass die CPUs zu dieser Zeit keinen geschützten Modus hatten. jwenting vor 10 Jahren 2
@jwenting - guter Punkt, ich habe eine Notiz dazu hinzugefügt Pete vor 10 Jahren 1
6
supercat

Vor Windows 3.x, der ersten Version mit Multitask-DOS-Anwendungen, gab es Programme wie DesqView, die dies ebenfalls tun konnten. Wenn beispielsweise drei DOS-Sitzungen gleichzeitig ausgeführt wurden, erstellt DesqView vier virtuelle Maschinen. Die drei DOS-Sitzungen würden denken, dass sie die gesamte Maschine "besessen" hatten, mit der Ausnahme, dass keine von ihnen tatsächlich Dateieingaben ausführte. Stattdessen würde die Version von DOS, die in jeder Sitzung ausgeführt wird, mit einem Patch versehen, sodass alle Anforderungen für Datei-E / A an eine spezielle Sitzung weitergeleitet werden, die diesem Zweck gewidmet ist. Da die Textmodus-Hardware des PCs den Inhalt eines Speicherbereichs kontinuierlich als Zeichen anzeigen würde; DesqView könnte jeder Sitzung einen eigenen virtuellen Bildschirm zuweisen, indem sie den 0xB8000-0xB9FFF-Bereich jeder Sitzung in ihrem eigenen RAM-Bereich abbildet. und periodisches Kopieren des Bereichs der aktuellen Anwendung in den physischen Bildschirmpuffer. Die grafische Unterstützung war viel schwieriger, da 256 KB RAM auf der Anzeigetafel mit einem Adressraum von 64 KB, einigen E / A-Registern und einiger "interessanter" Hardware gesteuert wurden, für die in bestimmten Sequenzen Dinge gelesen und geschrieben werden mussten. Wenn im Textmodus eine Anwendung etwas in den Textpuffer geschrieben hat, konnte DesqView ein Flag setzen, das darauf hinweist, dass es beim nächsten Timer-Tick in die Anzeige kopiert werden sollte. Nur das erste Schreiben in den Textpuffer innerhalb eines bestimmten Zeitstrichs würde das Eingreifen von DesqView erfordern. Alle anderen würden bis zum nächsten Timer-Tick konsolidiert. weil 256 KB RAM auf der Anzeigetafel mit einem Adressraum von 64 KB, einigen E / A-Registern und einiger "interessanter" Hardware gesteuert wurden, die das Lesen und Schreiben von bestimmten bestimmten Sequenzen erfordern. Wenn im Textmodus eine Anwendung etwas in den Textpuffer geschrieben hat, konnte DesqView ein Flag setzen, das darauf hinweist, dass es beim nächsten Timer-Tick in die Anzeige kopiert werden sollte. Nur das erste Schreiben in den Textpuffer innerhalb eines bestimmten Zeitstrichs würde das Eingreifen von DesqView erfordern. Alle anderen würden bis zum nächsten Timer-Tick konsolidiert. weil 256 KB RAM auf der Anzeigetafel mit einem Adressraum von 64 KB, einigen E / A-Registern und einiger "interessanter" Hardware gesteuert wurden, die das Lesen und Schreiben von bestimmten bestimmten Sequenzen erfordern. Wenn im Textmodus eine Anwendung etwas in den Textpuffer geschrieben hat, konnte DesqView ein Flag setzen, das darauf hinweist, dass es beim nächsten Timer-Tick in die Anzeige kopiert werden sollte. Nur das erste Schreiben in den Textpuffer innerhalb eines bestimmten Zeitstrichs würde das Eingreifen von DesqView erfordern. Alle anderen würden bis zum nächsten Timer-Tick konsolidiert. DesqView könnte ein Flag setzen, das darauf hinweist, dass es beim nächsten Timer-Tick in die Anzeige kopiert werden sollte. Nur das erste Schreiben in den Textpuffer innerhalb eines bestimmten Zeitstrichs würde das Eingreifen von DesqView erfordern. Alle anderen würden bis zum nächsten Timer-Tick konsolidiert. DesqView könnte ein Flag setzen, das darauf hinweist, dass es beim nächsten Timer-Tick in die Anzeige kopiert werden sollte. Nur das erste Schreiben in den Textpuffer innerhalb eines bestimmten Zeitstrichs würde das Eingreifen von DesqView erfordern. Alle anderen würden bis zum nächsten Timer-Tick konsolidiert.

Im Gegensatz dazu erfordert der Virtualisierungsgrafikmodus, dass DeskView jedes einzelne Schreiben in den Anzeigespeicher oder in E / A-Register einfängt. Da dies das Einschreiben des Speichers um einen Faktor von etwa 100 verlangsamen würde und Grafikprogramme wesentlich mehr Daten als Textprogramme schreiben mussten, war die Virtualisierung der meisten Grafiksoftware in Echtzeit nicht praktikabel. Stattdessen wurde für Grafiken eine nicht-Vordergrundanwendung verwendet, bei der versucht wurde, Grafiken anzuhalten, bis sie zur Vordergrundanwendung wurde, und dann die volle Kontrolle über den Bildschirm zu übernehmen. Wenn die Steuerung zu einer anderen Anwendung wechselt, versucht DesqView, den Zustand aller Grafikregister zu kopieren und dann zu wechseln. Beim Zurückschalten zur grafischen Anwendung stellt DesqView den gespeicherten Zustand wieder her.

In gewisser Weise waren nicht-grafische DOS-Anwendungen mit Multitasking einfacher als Windows-Multitasking-Anwendungen, da nur sehr wenige Ressourcen gemeinsam genutzt wurden und die Anwendungen nicht miteinander interagieren mussten. Im Gegensatz dazu ist es unter Windows notwendig, sich mit Dingen wie der Zwischenablage oder der Möglichkeit zu befassen, dass sich die Fenster eines Programms so bewegen, dass andere Fenster verdeckt werden. Windows 95 war die erste Version von Windows, die solche Einschränkungen überwinden konnte, indem sie beispielsweise ein Fenstersystem enthielt, bei dem ein Bildschirmbereich nicht mehr verfügbar war, während Code versucht wurde, sich darauf zu beziehen (was dazu führte, dass die Zeichnung ausgeblendet wurde ).

Vielen Dank, dass Sie mich an DesqView erinnert haben. Ich habe es die ganze Zeit benutzt, hatte es aber völlig vergessen. Emmet vor 10 Jahren 0
3
Dan Horvat

Multitasking ist nichts anderes als eine Illusion, Anwendungen gleichzeitig auszuführen. Es wird als gleichzeitige Ausführung auf Ihrer Seite wahrgenommen, aber tatsächlich teilen die Prozesse A, B und C die CPU-Zeit in dieser Reihenfolge: A, B, C, A, B, C, A, B ... sie schalten einfach ein und sehr schnell aus. Derzeit laufen keine zwei Prozesse gleichzeitig.

Es ist also durchaus möglich, MS-DOS-Multitasking zu erstellen, indem ein Prozess angehalten wird, der nächste für eine kurze Zeit ausgeführt wird, der eine angehalten wird, zum ersten Prozess zurückgesprungen wird und so weiter.

Multitasking ist nur eine clevere Funktion, die entwickelt wurde, als CPUs schnell genug waren, um sich durch diese Prozesse zu drehen und sie dem Endbenutzer gleichzeitig erscheinen zu lassen.

Für diejenigen, die sich erinnern, wurden Spiele immer noch unter DOS4GW ausgeführt, da Windows einfach zu langsam war.

und zum größten Teil funktionieren die Betriebssysteme bis heute noch. Deshalb können Sie beispielsweise 10 Dinge "gleichzeitig" auf einer 4-Kern-CPU ausführen. jwenting vor 10 Jahren 1
Es ist nicht wirklich so, dass "CPUs schnell genug waren". Es war möglich, Multi-Tasking-Betriebssysteme für mehrere Benutzer auf einem '286-System (z. B. * Coherent * von The Mark Williams Company, ein feines Betriebssystem, das 1983 in PC eingeführt wurde) auszuführen. MS-DOS- und Windows-Versionen (nicht NT) bis einschließlich "Millenium" waren wirklich von jedem objektiven Standard, sogar den technischen Standards der Zeit, abscheulich. Sobald MS-DOS jedoch von IBM als Standard für PCs festgelegt wurde, Das Marketing und die Dynamik von Microsoft (von einem kriminellen Missbrauch ihrer Monopolmacht ganz zu schweigen) haben den besseren Wettbewerb für sehr lange Zeit ausgeschlossen. Emmet vor 10 Jahren 2
* "Multitasking ist nur eine clevere Funktion, die entwickelt wurde, als CPUs schnell genug waren ..." * Sie meinen, der [Apollo Guidance Computer war ein Multitasking-Design] (https://en.wikipedia.org/wiki/Apollo_Guidance_Computer) #Software)? a CVn vor 10 Jahren 2
Mit "CPUs" habe ich die Massenproduktion gemeint, und mit "Multitasking" meinte ich das Multitasking von PC-Anwendungen. Und schließlich meinte ich mit dem "Endbenutzer" das Kind hinter dem PC, nicht den Astronauten. Ein großes Lob für den interessanten Kommentar. Dan Horvat vor 10 Jahren 1
0
Thoth

Obwohl es sich nur auf eine Aufgabe konzentrieren kann, ist es ein einfacher Schritt, schnell von einer zur anderen zu wechseln. Auf diese Weise schien es, dass es Multitasking war, aber in Wahrheit konzentrierte es sich nur auf 1, dann auf einen anderen, dann auf einen anderen usw.

Sie kombinieren _Multitasking_ mit _Multiprozessor-Computing_ dort. In der Computerwelt ist das Wechseln zwischen mehreren Aufgaben sehr schnell ein Multitasking. Die übliche Definition ist keine _demand_-parallele Ausführung. Verschiedene "alte Versionen von Windows" führten Multitasking unterschiedlich aus, abhängig davon, in welcher Windows-Version, in welchem ​​Modus sie ausgeführt wurde und ob überhaupt überhaupt DOS-basiert war. (Windows NT 3.1 ist älter als DOS + Windows 95 und könnte SMP ausführen.) Wie ich in einem anderen Kommentar darauf hingewiesen habe, wurden ganze Bücher darüber geschrieben. Das ist wirklich nicht die beste 2-Satz-Zusammenfassung. JdeBP vor 10 Jahren 0
@JdeBP ... Ich kenne den Unterschied zwischen Multitasking und Multiprozessor, da ich hauptsächlich noch Single-Core-Prozessoren verwende! Computer arbeiten seriell. Echte Parallele werden nur beim Quanten-Computing gesehen. Thoth vor 10 Jahren 0
0
Bill K

Eine Sache, die ich hier nicht erwähnt habe, ist irgendwie interessant:

Windows 3.0 war kein vorbeugendes Multitasking-System, es war kooperativ wie alle MacOS-Versionen, bis OS X-One-App von einem Anruf zurückkehren musste, bevor eine andere App eine Aktion ausführen konnte.

Der Kommentator erinnerte mich jedoch daran, dass DOS-Apps mehrere Aufgaben hatten. Dies liegt daran, dass sie nicht in "kooperativ" Multi-Task geschrieben wurden (dies muss immer in Systemen eingebaut sein, die sie verwenden).

Zu dieser Zeit gab es Programme namens TSRs (Terminate-Stay Resident), die die heutigen Gerätetreiber ersetzten. Diese Treiber würden unabhängig laufen - im Allgemeinen in ihrem eigenen Thread, indem sie sich in einen der Event-Handler des Betriebssystems einfügen. Windows wusste im Allgemeinen nichts davon, sie liefen auf einer niedrigeren Ebene.

Dies waren nicht wirklich Windows-Apps, aber es war, wie alle Threading-Aktivitäten vor Windows 3.1 stattfanden, z. B. Druckertreiber, Com-Treiber usw.

Obwohl Windows 3.1 Multitasking war, war DOS zwar nicht, aber Windows 3.1 schob DOS einfach aus dem Weg und übernahm es, als es gestartet wurde (damals haben Sie Windows oft von einer DOS-Eingabeaufforderung aus gestartet).

Windows 3.0 unterstützte preemptives Multitasking von DOS-Anwendungen, wenn es auf einem 386-Prozessor oder höher ausgeführt wird. Nur Windows-Anwendungen wurden kooperativ multitaskiert. Jules vor 10 Jahren 0
Oh, das ist richtig - ich habe damals Windows-Apps programmiert und habe nicht wirklich an DOS gedacht. DOS-Apps wurden anders behandelt - danke, dass Sie darauf hingewiesen haben. Bill K vor 10 Jahren 0
-8
javathunderman

Gute Frage. In MS-DOS war der Kernel monolithisch, was bedeutet, dass er nur eine Aufgabe zu einem Zeitpunkt erledigte, im Gegensatz zum neuen, modernen Kernel, der in Windows 9x und der aktuellen Version implementiert wurde. Sie können hier mehr erfahren .

-1 Sie vermuten, dass ein monothithisches Betriebssystem keinen Multitasking ausführen kann - das ist absolut falsch. Linux ist FAMOUSLY monothithic Kernel (es gab eine berühmte Debatte zwischen linus torvalds und andrew tanenbaum), aber Linux kann offensichtlich mehrere Aufgaben erfüllen. Hier ist ein Link, der zeigt, dass Linux monolithisch ist: http://stackoverflow.com/questions/1806585/why-is-linux-called-a-monolithic-kernel barlop vor 10 Jahren 11
Monolithisch bedeutet nicht, was Sie denken. Thorbjørn Ravn Andersen vor 10 Jahren 4

Verwandte Probleme