Re: Wozu noch DOS?

Udo Kuhnt wrote:
Stefan Reuther schrieb:
Und das geht auch noch, wenn der Task den Tastaturinterrupt übernommen
hat und wild im Speicher rumschreibt?

Und wie soll ein Task das machen, wenn er nur auf seinen eigenen
Adreßraum Zugriff hat und die Interrupts von der globalen Interrupt
Descriptor Table gesteuert werden, die nur vom Betriebssystem
kontrolliert wird? Ein Anwendungsprogramm läuft im PM nun mal in Ring
3 und hat damit keinerlei Möglichkeit, auf diese Systemdatenstrukturen
zuzugreifen.

Ich kann die Grenze nicht genau definieren, aber sowas ist für mich
irgendwann kein DOS mehr.

Ansichtssache - da könnte man ja auch sagen, es sei seit der
Einführung des hierarchischen Dateisystems kein DOS mehr, weil MS-DOS
1.0 das damals noch nicht unterstützt hat. ;-)

Wie gesagt, ich kann es nicht genau definieren. "Ein DOS" ist für mich
etwas, dass die API und die Möglichkeiten von ca. MS-DOS 5.0 bietet.

DOS entwickelt sich eben weiter, so wie andere Betriebssysteme auch.
DR-DOS besitzt diese Fähigkeiten schon seit mindestens zwölf Jahren.

Irgendwann ist es eben nicht mehr das, was ich ein "klassisches DOS"
nennen würde. Windows ME ist ja auch eine Fortentwicklung von MS-DOS,
nur würde ich es dank Nichtverfügbarkeit des Realmode mit normalen
Mitteln nicht mehr als "klassisches DOS" bezeichnen.

Der Vorteil von DOS ist doch, daß alle Hardware-Sauereien möglich sind.

Ach, gerade hast Du das noch als Nachteil bezeichnet. ;-)

Es ist Vor- und Nachteil zugleich. Vorteil: DOS steht nicht im Weg rum,
wenn ich abstruse Dinge machen will. Nachteil: DOS hindert mich nicht
dran, dumme Sachen zu machen.

Ein DOS-Multitasker muß nun entweder
- alle Hardware virtualisieren. Damit ist kein Zugriff mehr auf Hardware
möglich, die der Multitasker nicht kennt. Dafür ist es stabil.
- nur wohlbekannte Hardware (Timer, Tastatur, Bildschirm, Platte)
virtualisieren und den Rest durchgehen lassen. Damit läßt sich das
System einfach abschießen, indem man eine dem Multitasker unbekannte
Komponente (unbeabsichtigt) amok laufen läßt. Und sei es sowas
simples wie ein DMA beim Aufnehmen von der Soundkarte, der Speicher
überschreibt.

Stimmt zwar, ist aber für die Frage nach der grundlegenden Stabilität
nicht relevant. Immerhin kann der Benutzer ja selbst entscheiden, ob er
den Zugriff zuläßt, indem er einen passenden Treiber installiert oder
nicht.

Da kenne ich mich dann mit DR-DOS nicht aus, aber in DOS war es ja
eigentlich immer so, dass es nur für wenige Hardware-Klassen überhaupt
Treiberschnittstellen gab (Blockdevices, IFS, Netzwerk, ein bisschen
Grafik). Sowas wie Sound, Drucker, Joysticks machten immer die
Anwendungen selbst, und die können nicht miteinander kommunizieren, weil
es unter klassischem DOS halt keine zweite Anwendung zum damit-
kommunizieren gibt :)

Wenn die Hardware virtualisiert war, sollte nach dem Beenden des Tasks
nichts davon zurückbleiben. Mal abgesehen davon, daß Linux es auch
nicht schafft, nach einem Absturz von X-Windows den Textbildschirm
wiederherzustellen; da helfen nur Tools, die die Hardware wieder
richtig hinprogrammieren.

Da es sich beim X-Server um den in einen User-Task ausgelagerten
Grafiktreiber handelt. Wenn dir in einem anderen System der
Grafiktreiber wegsemmelt, siehst du genauso alt aus.

Ich würde es eher als Anwendungsprogramm mit integriertem Treiber
bezeichnen. Der Unterschied ist der, daß Du zwar X-Windows neu laden
kannst, aber Dein Textmodus danach noch immer nicht wieder
funktioniert.

Wenn du den zweiten X-Server beendest, eigentlich schon. War jedenfalls
der dokumentierte Trick, nach einem abgesemmelten SVGALIB-Programm
wieder zu einer benutzbaren Konsole zu kommen.

Unter DOS hilft dagegen meistens ein Wechsel des Graphikmodus; oftmals
reicht auch schon ein simples CLS.

Das ist unter Linux nicht anders. Nur kommst du eben normalerweise an
INT 10/AH=00 nicht ran.

Eben - und einen eigenen Zugang dazu besitzt Linux nicht. Soweit ich
weiß, stellt der Loader den Modus einmal ein und hofft, daß danach
keiner mehr daran herumpfuscht.

Ja. Der Kernel weiß nichts vom Modus-Umschalten. Der DOS-Kernel übrigens
auch nicht. Das sind dann Anwendungsprogramme ("mode"), die den
entsprechenden INT 10/AH=00 aufrufen. Unter Linux sind das ebenfalls
Anwendungsprogramme, die dann halt direkt die Grafikkarte programmieren
(bei der SVGALIB liegt sowas bei).


Stefan

.

Relevant Pages

  • Re: Wozu noch DOS?
    ... Einführung des hierarchischen Dateisystems kein DOS mehr, ... Damit ist kein Zugriff mehr auf Hardware ... Ich würde es eher als Anwendungsprogramm mit integriertem Treiber ...
    (de.comp.os.msdos)
  • Re: Wozu noch DOS?
    ... wenn der Task den Tastaturinterrupt übernommen ... Ein Anwendungsprogramm läuft im PM nun mal in Ring ... Zwischen Messy DOS 4 und DR-DOS 7.0x liegen Welten. ... Wenn die Hardware virtualisiert war, sollte nach dem Beenden des Tasks ...
    (de.comp.os.msdos)
  • Re: Diagnose-Tool
    ... Jegliche Hardware kann man auch unter DOS sichtbar machen ... wie man sie ansprechen kann. ... DOS hat hier keine generelle hardwareseitige Einschränkung ... beim Zugriff auf irgendeine Hardware. ...
    (de.comp.os.msdos)
  • Re: Wozu noch DOS?
    ... Hardware, von denen einer unter DOS und der andere unter Linux läuft. ... Betriebssystem dazugehören? ... oder dessen Bios in kontackt treten. ... DOS, OS2, Linux oder Windows ...
    (de.comp.os.msdos)
  • Re: Hardware ansprechen
    ... Bei den ersten Rechnern war das Betriebssystem verdratet in der Hardware ... DOS system. ... Wenn du aus MSdos + Windows 3.1 ein einziges programm ...
    (microsoft.public.de.vc)