dos_crux


 BACK ..

 DIE CRUX MIT DEM DOS


    Mit der Stabilität von Windows 3.x, 9x und Me (alle sind DOS-Basiert)
           steht es nicht immer zum Besten. Einer der Gründe wird hier
           betrachtet.

    Die Basis von Windows und DOS war nie für heutige Rechner konzipiert.
    Der IBM PC hatte eine extern 8 Bit breite CPU (Intel 8088 an 4,77 MHz)
    und wurde mit 64 Kbyte RAM ausgeliefert. Nur ein Benutzer sass vor dem
    Textbildschirm, und so war es akzeptabel, dass sich Betriebssystem und
    Programme die Kontrolle über den Rechner teilen. Streng betrachtet ist
    DOS gar kein Betriebssystem, weil es nicht die Kontrolle über Hardware
    und laufende Programme besitzt. DOS ist ein speicherresidenter
    Programmlader. Nur grundlegende Dienste wie Datei öffnen, lesen,
    schreiben, Zeichen ausgeben und einlesen kann DOS selbst. UNIX-Systeme
    (BSD, Solaris, HP-UX, ...) und UNIX-Ähnliche Betriebssysteme (Linux,
    Hurd, QNX, ...) übernimmt die Kontrolle u:ber die Hardware und
    gestattet Programmen nur Zugriff durch Benutzung der Gerätetreiber.
    Auf diese Weise können mehrere Programme auf Geräte zugreifen. DOS hat
    damit kein Problem, es kann ja nur ein Programm laufen. Eines musste
    es aber auch mehrfach können: Interrupts abarbeiten. Die Routine, die
    den Interrupt abarbeitet, benötigt mit unter die Hilfe einer
    Systemfunktion. Falls das vom Interrupt unterbrochene Programm jedoch
    ebenfalls diese Funktion gerufen hatte, entsteht reentrant, sie
    stürzten ab. Microsoft machte einige Routinen reentrant, aber nicht
    alle. Letztere sind heute mit einer Semaphore (Ampel) gesichert, deren
    Zustand über ein undokumentiertes Rentranz-Flag pru:fbar ist.
    Mit solchen Tricks arbeitet DOS/Windows (bis einschliesslich "Me") bis
    heute. DOS hat keine Prozessisolation, weil es nur einen Prozess
    kennt. Die Folge ist, dass das Betriebssystem schutzlos gegen Viren
    oder unabsichtliche Angriffe (Bugs) ist. Auch muss DOS zusehen, wenn
    ein Programm Hardware direkt bedient. Als DOS entwickelt wurde, gab es
    viele Programme für CP/M. Sie waren fu:r einen 16 Bit breiten
    Adressraum geschrieben (maximal 64 Kbyte). Damit sie leicht portiert
    werden konnten, entschied sich Intel, zusätzlich 8 Bit einzuführen, in
    Form von zwei um acht Bit verzahnten 16-Bit-Zahlen (Segment und
    Offset). DOS macht dies bis heute so, obwohl Intel längst besseres
    anbietet (Flat Memory Model). DOS-Programme müssen in maximal 64
    Kbyte-grosse Blöke zersägt werden, was die Programmierung kompliziert
    und anfällig macht.
    Daran krankt der 16-Bit-Modus von Windows noch immer, aber Windows
    beherrscht heute Flat Memory. Seit Windows 95 ist der 32-Bit-Modus
    erwünscht, aber nie erzwungen worden. Die Folge: Ein reines
    95/98-System kann superstabil sein. Ein einziges 16-Bit-Programm macht
    es instabil, und wenn es nur der Bildschirmschoner ist. 16- und
    32-Bit-Modus unterscheidet noch ein Feature: 16-Bit-Programme arbeiten
    kooperativ, sollen die Kontrolle also von sich aus weitergehen. Tun
    sie es nicht, zwingt sie nichts. Ein modernes Betriebssystem (UNIX
    oder UNIX-Ähnlich) arbeitet mit preemptivem multitasking. Das System
    erzwingt den Wechsel der Programme. So kann kein Programm zuviel
    Rechenleistung erhalten und ein Absturz nicht den Rest des Systems
    anhalten. Kritisch wird es ebenfals in Windows, wenn sich ein 16- und
    ein 32-Bit-Programm unterhalten müssen.
    (in Anlehnung an PC PROFESSIONELL 1/2001 Seite 24)


   [IMG]