Hat unter DOS bei einem Neustart via Klammergriff (STRG+ALT+ENTF) das Betriebssystem die Kontrolle über den Neustart?
-
Also löst das OS dann nach drücken von STRG+ALT+ENTF den Neustart aus oder ist das eine reine Hardware- oder BIOS-geschichte die unter Windows mit Aufrufen des Taskmanagers nur unterdrückt wird?
-
Das ist eine BIOS-Geschichte, ein OS im Realmode (also unter anderem gewisse Versionen von MS-DOS) hat an der Stelle nichts mehr zu melden. Es ist aber auch keine Hardwarefunktion; funktioniert das BIOS nicht mehr, muss ein Hardwarereset gemacht werden. Im Protected Mode (also so ziemlich jedes zeitgenössische OS) ist das Ganze eine Sache des OS und macht ja in aller Regel auch ganz was anderes als ein Softreset.
Macht auch jeweils Sinn, wenn man bedenkt, wer bei den jeweiligen Modi die Kontrollinstanz ist.
-
Ah, okay.
Wie ist das aber mit DOS Extender DOS/4GW oder wie die nochmal hießen?
Die wechseln die CPU meines Wissens nach ja in den Protected Mode um, womit die Programmierung einfacher wurde und mehr Speicher als die 640k Verfügbar wurden.
-
Das habe ich mich auch gefragt, als ich über die erste Antwort nachdachte. Ich weiß es nicht. Wenn die DOS-Extender wirklich in den richtig echten 386 protected mode schalten, dann sollten sie selber für die Tastenkombination zuständig sein. Und wahrscheinlich würden sie diese einfach ignorieren.
Es ist bloß mindestens 15 Jahre her, dass ich ein Spiel unter DOS gestartet habe, daher kann ich mich nicht mehr klar erinnern, was man tat, wenn es mal hing. Ich meine Hardware-Reset, aber ich bin mir nicht sicher. Und da ich auch schon lange keinen Rechner mehr habe, der nativ DOS ausführen kann (oder zumindest nicht ohne übermäßigen Aufwand) kann ich es auch nicht mehr ausprobieren.
-
SeppJ schrieb:
Das habe ich mich auch gefragt, als ich über die erste Antwort nachdachte. Ich weiß es nicht. Wenn die DOS-Extender wirklich in den richtig echten 386 protected mode schalten, dann sollten sie selber für die Tastenkombination zuständig sein. Und wahrscheinlich würden sie diese einfach ignorieren.
Es gibt keinen anderen als den richtig echten 386 protected mode. Es gibt aber den real mode und den virtual real mode. Die Frage ist daher, ob DOS-Extender wieder in den real mode oder in den virtual real mode geschaltet sind, nachdem sie ihre Arbeit im protected mode verrichtet haben. Der virtual mode ist "sauberer", aber langsamer, weil für jede Interaktion mit der Hardware (die man im real mode einfach so machen kann) eine Hardware-Exception ausgelößt wird, die vom PM-Betriebssystem abgehangen und simuliert werden muss.
EMM386.exe aber hat zumindest genau das getan - in den PM gewechselt und einem sog. VM86-Task (ein Prozess, der das virtual real mode-Status Flag gesetzt hatte) erstellt, in dem das OS dann lief. Wurde aber auf HW-Resourcen zugegriffen, wurde eine CPU-Exception ausgelöst und die Funktion musste emuliert werden. Die logische Konsequenz daraus ist, dass zumindest EMM386.exe den Klammergriff emuliert hat.
Aber jetzt wird es interessant: mit dem 486 wurden Interrupt-Routinen eingeführt, die komplett im VM abgearbeitet werden konnten, ohne dass eine Exception ausgelöst und der Switch in den PM durchgeführt werden musste. Ob die Extender darauf programmiert wurden, diese Features zu nutzen? Ich weiß es nicht.
Long story short: es hängt von dem jeweiligen Extender (RM vs. VM), der CPU (386 vs. 486 u. älter), und dann noch mal von der späteren Implementierung der Interrupt-Routinen ab, ob das BIOS oder das OS den Klammergriff abfängt.
-
dachschaden schrieb:
Aber jetzt wird es interessant: mit dem 486 wurden Interrupt-Routinen eingeführt, die komplett im VM abgearbeitet werden konnten, ohne dass eine Exception ausgelöst und der Switch in den PM durchgeführt werden musste. Ob die Extender darauf programmiert wurden, diese Features zu nutzen? Ich weiß es nicht.
Das ist interessant.
Wenn sie darauf programmiert wurden, dann konnten die meisten Extender aber zumindest beides, denn die meisten Spiele die so einen Extender verwendeten setzten nur einen 386er voraus, keinen 486er.
Also musste der Extender zumindest auf einem 386er laufen.Für mich stellt sich jetzt nur die Frage.
Wären die Realmode Spiele auf meinem 486er etwas schneller gewesen, wenn ich den EMM386 nicht geladen hätte?Wenn ja, dann finde ich das schade, dass man von keinem Spiel darauf hingewiesen wurde.
Ich habe mir damals mit der DOS Startmenu Option nämlich 5 Konfigurationen angelegt, die praktisch alles abdeckten was es an Software und Spiele gab.Also:
1. EMM386
2. ohne EMM386 für die Spiele die danach verlangten
3. EMM386 + CD-ROM Treiber
4. ohne EMM386 + CD-ROM Treiber
5. Windows 3.1Da wo es ging, wurde alles von mir grundsätzlich in den oberen Speicherbereich geladen und damit hatte ich jede Menge freien Speicherplatz unterhalb von 640 KB.
Das dumme ist jetzt nur, meistens habe ich MODE 1 gestartet, wenn anderes nicht nötig war, also wurde EMM386 geladen und die Spiele liefen somit im langsamen virtual mode, wenn das, was in der WP steht, so mit EMM386 stimmt.
Hätte ich das damals vorher gewusst, dann hätte ich vielleicht noch das ein oder andere frame mehr rausgekitzelt.Zum Glück hatte ich aber zumindest keinen 386er, sondern gleich einen 486er.
Also dürften eventuell die im 486er für den VM Mode eingeführten Interruptbehandlungen geholfen haben und weniger Exceptions geworfen worden.Long story short: es hängt von dem jeweiligen Extender (RM vs. VM), der CPU (386 vs. 486 u. älter), und dann noch mal von der späteren Implementierung der Interrupt-Routinen ab, ob das BIOS oder das OS den Klammergriff abfängt.
Danke für die Antwort.
-
Wenn du ein Real Mode Spiel auf einem 386er ausgeführt hättest, wäre mangelnde Geschwindigkeit dein geringstes Problem gewesen. Im Gegenteil, musste man damals den Rechner absichtlich ausbremsen (ein Turbo-Knopf ist in erster Linie das Gegenteil: Ein Langsam-mach-Knopf), damit die Programme überhaupt liefen, weil die viel zu hohe CPU-Geschwindigkeit deren Timing durcheinander gewürfelt hat.
-
SeppJ schrieb:
Wenn du ein Real Mode Spiel auf einem 386er ausgeführt hättest, wäre mangelnde Geschwindigkeit dein geringstes Problem gewesen. Im Gegenteil, musste man damals den Rechner absichtlich ausbremsen (ein Turbo-Knopf ist in erster Linie das Gegenteil: Ein Langsam-mach-Knopf), damit die Programme überhaupt liefen, weil die viel zu hohe CPU-Geschwindigkeit deren Timing durcheinander gewürfelt hat.
Das kann man so pauschal nicht sagen.
3d Spiele profitierten problemlos von einem schnelleren Rechner und diese habe ich damals überwiegend gespielt.Das mit dem Turbo-Knopf und sonstigen Softwarebremsen ist mir durchaus bekannt.
Richtig ist allerdings, dass es auch ein paar wenige 3d Spiele gab, die die Zeitroutinen nicht von einer Uhr abhängig machten, sondern von irgendeiner Schleife die x mal durchlief und dann auf den schnelleren Rechnern zu schnell liefern, aber nicht alle Spiele waren so.
Dieses Problem hatte ich nur bei "Battle of Britain Their findest hour" und Wing Commander 1.
Bei Gunship 2000 und M1 Tank Platoon profitierte ich vom schnelleren Rechner, das ergab nämlich mehr fps.
Bei F-19 Stealth Fighter weiß ich es nicht mehr und bei F-117A Nighthawk habe ich es auch vergessen.Und die Spiele die danach kamen, z.b. Aces of the Pacific oder F-15 Strike Eagle 3 verwendeten alle irgendeinen Extender.
-
Ich kann mich noch an "Dungeon Keeper" erinnern, das bei schnelleren Pentium-Rechnern dann auch schneller lief (z.B. Vampir und Iron Maiden bewegten sich im Turbo-Modus
-
Th69 schrieb:
Ich kann mich noch an "Dungeon Keeper" erinnern, das bei schnelleren Pentium-Rechnern dann auch schneller lief (z.B. Vampir und Iron Maiden bewegten sich im Turbo-Modus
Dungeon Keeper kam erst 1997 heraus.
Das verwendete bestimmt irgendeine Form von DOS Extender und somit den protected Mode der CPU um genug RAM zu haben.Die ganzen reinen Real Mode Spiele dürften alle vor 1991 rausgekommen sein.
Sobald ein Spiel aber einen 386er und mindestens MS-DOS 5.0 verlangte kann man Pi mal Daumen davon ausgehen, dass es kein echtes Real Mode Spiel mehr ist.
