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]