###########################################################################
  ###########################################################################                                      [8Bit ASCII, CP437/850, 77 Zeichen/Zeile]


                                             "Mehrheiten zementieren das
                                             Bestehende; Fortschritt ist
                                             nur über Minderheiten möglich."
                                             Bertraud Russel (1872-1970),
                                             engl. Mathematiker u. Philosoph





   N     N  W     W  DDDDD      OOO     SSSSSS          TTTTTTT  I  PPPPPP
   NN    N  W     W  D    D    O   O   S                   T     I  P     P
   N N   N  W     W  D     D  O     O  S                   T     I  P     P
   N  N  N  W     W  D     D  O     O   SSSSS   #######    T     I  PPPPPP
   N   N N  W     W  D     D  O     O        S             T     I  P
   N    NN   W W W   D    D    O   O         S             T     I  P
   N     N    W W    DDDDD      OOO    SSSSSS              T     I  P      s








                     Tips & Tricks rund um Novell DOS 7,
                    mit Blick auf undokumentierte Details,
                             Bugs und Workarounds







                              von Matthias Paul




                                                                             
  ###########################################################################
  ###########################################################################


   NWDOSTIP.TXT             Version 3  Ausgabe 157

                       Copyright (C) 05/1994-07/1997 bei

                                Matthias Paul
                                Ubierstraße 28
                                D-50321 BRÜHL
                                DEUTSCHLAND

                  Dieses Werk ist urheberrechtlich geschützt.
                           Alle Rechte vorbehalten!

   EMail:             <Matthias.Paul@post.rwth-aachen.de>;
                      (<Paul-Ma@reze-1.rz.rwth-aachen.de>;)

   Letzte Änderung:             1997-07-30 -mp

  ---------------------------------------------------------------------------

   Diese ständig aktualisierte Datei enthält Hinweise, die für die Benutzer
   von Novell DOS 7 (bis Update 15, Januar 1996) und Caldera OpenDOS 7.01,
   sowie für Personal NetWare 1.0 (bis Update 5, inklusive VLM-Update 4,
   NWDLL Update 2 und WINDR Update 3 und VLM-Kit 1.21), aber in vielen
   Dingen auch für Benutzer anderer DOS-Betriebssysteme und ganz allgemein
   für DOS-/Windows-Programmierer interessant sein dürften.

   Dabei wird auch auf evtl. bestehende Kompatibilitätsprobleme und deren
   Beseitigung, sowie auf Optimierungsmöglichkeiten in Verbindung mit
   bestimmten Anwendungen, älteren DR DOS-Versionen und den Alternativ-
   Kommandoprozessoren 4DOS/NDOS eingegangen. Außerdem werden Lösungen
   vorgestellt, wie man in Batchjobs und eigenen Programmen die zusätzlichen
   Funktionen von Novell DOS möglichst so ausnutzen kann, daß dabei keine
   problematischen Wechselwirkungen mit anderen DOS-Systemen (wie MS-DOS/
   PC-DOS) auftreten (und umgekehrt). Weitere Hinweise zu Novell DOS finden
   sich u.a. in der Datei NWDOS7UN.TXT.

   Obwohl es sicherlich (wie in jeder Software) auch in Novell DOS 7 einige
   Bugs gibt (die meisten wurden in der Zwischenzeit im Rahmen von Updates
   gefixt), wurden in manchen Büchern auch angebliche Systemfehler be-
   schrieben, die eigentlich nur auf eine falsche Konfiguration zurück-
   zuführen sind. Deshalb soll dieses Dokument auch mit einigen Vorurteilen
   aufräumen und zeigen, wie man Novell DOS zu Dingen überreden kann, die
   (nicht nur für MS-DOS Benutzer) nicht unbedingt offensichtlich sind und
   die teilweise weit über die Möglichkeiten der Konkurrenz hinausgehen.

   Bis auf ganz wenige Ausnahmen gelten die hier wiedergegebenen Fakten auch
   für den am 1997-02-03 freigegebenen Nachfolger von Novell DOS 7, für
   Caldera OpenDOS 7.01; insofern behält dieser Text weiterhin Aktualität!
   Da ein Großteil dieses Textes unter Novell DOS 7 entstanden ist, wird
   derzeit meist noch nicht explizit auf Caldera OpenDOS 7.01 verwiesen.
   Soweit bisher untersucht, können Sie dies jedoch in 99% aller Fälle
   einfach stillschweigend annehmen!


  ---------------------------------------------------------------------------

   Die in diesem Dokument wiedergegebenen Fakten und Ansichten basieren
   zum weitaus größten Teil auf unabhängigen eigenen Nachforschungen und
   Erfahrungen mit dem Betriebssystem, die hier und da durch ergänzende
   Hinweise aus der Fachliteratur, Zeitschriften oder anderen Quellen
   vervollständigt und durch vielfältige Versuche, übermittelte Erfahrungs-
   berichte und Diskussionen abgesichert wurden. Einige Hinweise fußen auch
   nur auf unbestätigten Vermutungen (darauf wird an den entsprechenden
   Stellen hingewiesen). Es gibt also noch verschiedene Lücken zu schließen
   und ich bin für jede Mithilfe dankbar (besonders durch die Veröffent-
   lichung der Quelltexte der ehemaligen Digital Research Betriebssystem-
   palette werden sich die noch verbliebenen Fragen und Ungenauigkeiten in
   naher Zukunft definitiv beantworten lassen können).

   Diese Datei stellt kein offizielles Dokument der Hersteller dar.

    HAFTUNGSAUSSCHLUSS:

     DIE ANWENDUNG DER TIPS GESCHIEHT AUSDRÜCKLICH AUF IHRE EIGENE
     GEFAHR UND IHR RISIKO! MIT DIESEN DOKUMENTEN WERDEN KEINE HARD-
     ODER SOFTWARE-EIGENSCHAFTEN ZUGESICHERT.
     ICH (DER AUTOR) ÜBERNEHME KEINERLEI GEWÄHR, GARANTIE ODER
     VERANTWORTUNG FÜR DIE RICHTIGKEIT DER INFORMATIONEN, FÜR DIE
     TAUGLICHKEIT AUF BESTIMMTEN SYSTEMEN, FÜR RECHTLICHE FRAGESTELLUNGEN,
     NOCH FÜR IRGENDETWAS ANDERES, WEDER EXPLIZIT NOCH IMPLIZIT!
     ICH HAFTE AUCH NICHT FÜR VERLUSTE ODER SCHÄDEN JEGLICHER ART, DIE
     DURCH DIE ANWENDUNG DIESER INFORMATIONEN ENTSTEHEN KÖNNTEN, NOCH
     GEHE ICH IRGENDEINE VERPFLICHTUNG IHNEN GEGENÜBER EIN!
     GEGEN MICH KÖNNEN KEINERLEI ANSPRÜCHE GELTEND GEMACHT WERDEN!

   Auch Novell oder Caldera werden Ihnen i. allg. keinen Support etc.
   bei Verwendung undokumentierter Details geben, nichtsdestotrotz sind
   diese Details manchmal sehr interessant und nützlich.

   Bitte beachten Sie weitere Hinweise in der Datei README.1ST, denn wenn
   Sie weiterlesen, erklären Sie sich automatisch mit diesen Bestimmungen
   einverstanden!

   Verwendete Warenzeichen etc. sind Eigentum der jeweiligen Eigentümer.


  ---------------------------------------------------------------------------

   Die kostenfreie Weitergabe der unveränderten Datei zu nicht kommerziellen
   Zwecken ist ausdrücklich erlaubt, sofern dies in Form der unveränderten
   Original-Distribution MPDOSTIP.ZIP geschieht. Jede andere Form der
   Weitergabe oder Übersetzung (auch auszugsweise oder in modifizierter oder
   bearbeiteter Form gleich welcher Art), sowie eigenständige Änderungen
   sind nicht gestattet, es sei denn, ich habe dazu vorher meine ausdrück-
   liche schriftliche Zustimmung gegeben.
   Die Veröffentlichung dieser Informationen (auch ausschnittsweise oder
   in veränderter Form) in anderen Listen, Büchern, Zeitschriften, auf
   CD-ROMs, in Online-Dokumenten o.ä., bzw. als Beilage oder Werbung für
   irgendein Produkt (z.B. Rechner- oder Software-Verkauf) erfordert
   meine vorherige schriftliche Zustimmung.
   Bei Nichtbeachtung behalte ich mir rechtliche Schritte vor!
   Alle Rechte vorbehalten!

   Sollten Sie diese Datei nicht kostenlos erhalten haben oder sollte bei
   Ihnen der Eindruck erzeugt worden sein, es handele sich hierbei um eine
   Ersatzdokumentation oder zum Lieferumfang irgendeines Produkts zugehörig,
   teilen Sie mir dies bitte mit. Ich möchte verhindern, daß, wenn ich
   aus dem Projekt *in dieser Form* schon keinen finanziellen Gewinn ziehen
   möchte, es andere versuchen. Schließlich stecken einige tausend Arbeits-
   stunden in der Erarbeitung und Aufbereitung des Materials.

   Ich habe mich bemüht, die Informationen so vollständig, eindeutig und
   korrekt wie nur möglich darzustellen. Trotzdem bin ich mir sicher, daß
   dieses Dokument noch sachliche oder anderweitige Fehler enthält (nicht
   zuletzt aufgrund der Tatsache, daß ein Großteil dieses Textes zu stark
   vorgerückter Stunde entstanden ist...). Deshalb:
   Für Hinweise auf Fehler, unverständliche Formulierungen oder weitere
   Tips und Tricks bin ich jederzeit dankbar. Auch andere Rückmeldungen
   sind sehr willkommen.

   Regelmäßige Updates meiner Tips & Tricks Dokumente zu Novell DOS,
   DR DOS, MS-DOS/PC-DOS und verschiedenen Anwendungsprogrammen,
   sowie die in diesem Text erwähnten FreeWare-Utilities gibt es
   entweder direkt auf meiner WWW-Seite oder z.B. auf dem FTP-Server
   der Uni Stuttgart:

    URL: http://www.rhrz.uni-bonn.de/~uzs180/mpdokger.html
                                    [^ hier steht eine Tilde, ASCII-126]

    URL: ftp://ftp.uni-stuttgart.de/...
                               ...pub/systems/msdos/util/system/mpdostip.zip

   Weitere Bezugsquellen entnehmen Sie bitte der beiliegenden Datei
   README.1ST.

                                                                             
  ###########################################################################
  ###########################################################################

  I. EINFÜHRUNG:
  ==============

  ---------------------------------------------------------------------------

  I.1. Inhalt: [97-04-13]
  =======================

   i. Vorbemerkungen:
   ------------------

   Diese Datei hat über die Jahre riesige Ausmaße angenommen. U.U. ist Ihr
   Editor/Textbetrachter nicht einmal mehr in der Lage, die komplette Datei
   einzuladen: Novells EDIT, der <F3>-Betrachter des Norton Commanders (NC),
   aber auch Editore wie SemWares TSE oder die von RIT Labs' DOS Navigator
   (DN) oder Borland Pascals BP 7.0 haben hier normalerweise keine Probleme
   (einige Randbedingungen vorausgesetzt); leider ist EDIT von MS-DOS bis
   einschließlich 6.22 nicht in der Lage, Dateien mit solchen Ausmaßen zu
   bearbeiten; mit MS-DOS 7 hatten die Entwickler wohl in Einsehen, denn
   nun unterstützt auch MS-DOS EDIT größere Dateien... ;-)

   Für den Notfall liegt meinem Tips & Tricks Paket ein kleiner, wenn auch
   spartanischer Public-Domain-ASCII-Textbetrachter namens SEE.COM bei,
   der auch problemlos beliebig große Dateien anzeigen kann.

   Ein Ausdruck würde einige hundert Seiten beanspruchen (derzeit ca.
   400 DIN/A4-Seiten). Deshalb stelle ich - stellvertretend für Sie -
   die wichtigste Frage zuerst:

   "Muß ich mir das wirklich antun, all dies durchzulesen...?"

   Als Autor dieses Textes kann meine Antwort natürlich nur sein:

   "Ja, falls Sie sich noch zu den DOS Benutzern zählen oder (im Idealfall)
    sogar Novell DOS, Caldera OpenDOS oder DR DOS einsetzen..." ;-)

   Wenn Sie diese Datei nicht lesen, entgehen Ihnen mit Sicherheit eine
   unglaubliche Fülle bisher nirgendwo sonst verzeichneter undokumentierter
   Informationen sowie eine Vielzahl Tips und Tricks rund um Novell DOS
   inklusive vieler allgemeingültiger Hinweise, die sich auch Benutzer
   von MS-DOS/PC-DOS zu Gemüte führen sollten.

   Allerdings muß ich auch zugeben, daß nicht alle Informationen jeden
   Leser interessieren werden. In der üblichen Literatur wird häufig eine
   80/20 Regelung angestrebt (d.h. 80% allgemein interessante Themen sollen
   abgehandelt werden; der 20% Themenanteil 'für Spezialisten' fällt unter
   den Tisch). Dies sind aber meist die Punkte, wo die Probleme anfangen
   und die Praxislösungen schmerzlich vermißt werden (nicht nur von den
   Spezialisten). (Schon oft habe ich mich über tausendseitige Wälzer
   geärgert, die dann, wenn man wirklich konkrete Auskünfte sucht, immer
   noch keine brauchbaren Hinweise geben und sich in Oberflächlichkeiten
   ergehen...).
   In diesem Dokument habe ich deshalb auf keinerlei derartige Faustregel
   Rücksicht genommen, sondern - eher im Gegenteil - versucht, die dadurch
   entstandenen Dokumentationslücken durch eigene Recherchen zu schließen
   (soweit ich sie schließen konnte...). Ehrlich gesagt, auch ich habe mich
   schon manches Mal gefragt, ob dies an der einen oder anderen Stelle nicht
   doch etwas in Pedanterie ausartet, andererseits habe *ich* diese Details
   während der täglichen Arbeit oft schmerzlich vermißt, so daß es anderen
   Benutzern vielleicht ähnlich geht, wenn sie ein Betriebssystem wirklich
   bis zum Letzten ausnutzen wollen/müssen.
   Manchem mag diese Form der Dokumentation auch wieder nur bruchstückhaft
   vorkommen (was auch stimmt), aber man nehme sich einfach das DOSBOOK oder
   die auf dem Buchmarkt vorhandene Literatur und schlage ein beliebiges
   Kapitel auf. In den meisten Fällen werden sich die Informationen
   ergänzen, nicht aber überschneiden.
   Das Standardverhalten und offensichtliche Eigenschaften sind in der
   einschlägigen Literatur (und im DOSBOOK) ausführlichst dokumentiert;
   dies braucht nicht ein weiteres Mal wiederholt zu werden. Nur an Stellen,
   wo es mir auch um eine 'geschlossene' Darstellung eines Themas ging, habe
   ich auch das dokumentiert, was eigentlich für den einigermaßen erfahrenen
   Benutzer (und Leser der offiziellen Dokumentation) als bekannt voraus-
   gesetzt werden kann.

   Dieser Text befaßt sich mit der Benutzerseite des Betriebssystems.
   Auf die API-Ebene und interne Datenstrukturen wird nur sehr begrenzt
   eingegangen; hierfür sei auf die von Ralf Brown gepflegte umfangreiche
   Interrupt-Liste INTERxx verwiesen, z.B. zu beziehen über:

    URL: http://www.pobox.com/~ralf/files.html
    URL: ftp://cs.cmu.edu/afs/cs.cmu.edu/user/ralf/pub/inter*.zip
    URL: ftp://ftp.uni-stuttgart.de/pub/systems/msdos/util/interxx/*.*
    URL: ftp://ftp.leo.org/pub/comp/platforms/pc/msdos/doc/interrupt/*.*
    URL: http://www.leo.org/pub/comp/platforms/pc/msdos/doc/

   Eine Ausnahme hiervon ist die Struktur der Verzeichniseinträge
   bei DELWATCH und PASSWORD (in Kapitel II.4. und II.21.), um hier
   ein für allemal die über die gesamte Literatur herrschende Konfusion
   zu beenden, was besonders im Hinblick auf DR DOS 6.0 Owner-IDs,
   OS/2 Extended Attributes und MS-DOS 7 neues ACCDATE= und den
   Long-Filename-Support wichtig ist, damit neue Implementierungen auf
   Novell DOS/DR DOS Rücksicht nehmen können...
   Andere Ausnahmen sind die quantitativen Bemerkungen zum Aufbau der
   DOS-Datenstrukturen (wichtig für Optimierungen in CONFIG.SYS) und
   insbesondere der CONFIG.SYS Vorab-Umgebung (in Verbindung mit SET=
   und meinem Utility SETENV.COM), außerdem Hinweise zur CDS (in Ver-
   bindung mit LASTDRIVE= und Lademöglichkeiten von NWCDEX in CONFIG.SYS
   mit meinem INSTCDEX.EXE Utility).

   Sollten in diesem Text Funktionen der DOS-Versionen verschiedener
   Hersteller gegenübergestellt werden, so bezieht sich dabei die Angabe
   "MS-DOS" ohne explizite Angabe der Versionsnummer i. allg. auf MS-DOS
   bis einschließlich 6.22. (Zumindest bis einschließlich MS-DOS 5 gilt
   dies auch für die PC-DOS Version, danach können Differenzen auftreten.)
   Der MS-DOS 7 Anteil aus MS Windows95 hat - obwohl als Ganzes eher stark
   beschnitten - eine ganze Reihe der sinnvollen internen Erweiterungen
   des Kernels von Novell DOS 7 adaptiert (zum Zeitpunkt der Auslieferung
   von Novell DOS 7 waren MS-DOS 6.0 und 6.20 aktuell). Daher weicht
   MS-DOS 7 in recht vielen Punkten von seinen Vorgängern ab und muß
   häufig gesondert betrachtet werden (was aber nur begrenzt Thema dieser
   Datei ist). Ist von unterschiedlichen Novell DOS 7 Updates die Rede,
   bezieht sich die Angabe eines Updates bei der Beschreibung eines be-
   stimmten Verhaltens, sofern nicht ausdrücklich anders angegeben, meist
   auch auf alle vorherigen Updates, d.h. die Angabe soll nur ausdrücken,
   daß ich das Verhalten mit (oder bis zu) einem bestimmten Update über-
   prüft habe.

   Bitte betrachten Sie das folgende Inhaltsverzeichnis mit Vorsicht.
   Es liegt in der Natur einer Tips & Tricks Liste, daß viele Tips über
   das gesamte Dokument verstreut sind und nicht immer unbedingt an der
   Stelle auftauchen, an der Sie anhand des Inhaltsverzeichnisses danach
   suchen. Einige der Unterkapitel sind so umfangreich, daß eine weitere
   Unterteilung den Rahmen des Inhaltsverzeichnisses um Größenordnungen
   gesprengt hätte. Insofern gibt das Verzeichnis in seiner derzeitigen
   Form nur einen verzerrten Eindruck vom wahren Inhalt dieser Datei. Auf
   ein Stichwortverzeichnis und eine Seitennummerierung wurde zugunsten
   der Aktualität verzichtet. Es empfiehlt sich daher, immer das komplette
   Dokument nach einem Schlüsselwort abzusuchen, um einen möglichst
   vollständigen Eindruck zu bekommen (teilweise gibt es dadurch auch
   Mehrfacherwähnungen und Querverweise). Zur Erleichterung für Leser,
   die nach bestimmten Informationen suchen, habe ich mich bemüht,
   einigermaßen sinnvolle Stichworte zu vergeben.

   Damit Sie auch bei ständiger Aktualisierung Notiz von Neuigkeiten
   nehmen können, ohne jedesmal das gesamte Dokument durchlesen zu müssen,
   erscheint ab sofort jeweils nach der Kapitelüberschrift das letzte
   Aktualisierungsdatum [in eckigen Klammern], sofern größere Neuerungen
   eingearbeitet wurden.

   Zusätzlich sind im folgenden Inhaltsverzeichnis einige Kapitel mit
   Attributen versehen:

   [i] =  Für Schnelleser: Ein möglichst guter Einstieg in die
          wichtigsten Zusatzinformationen und Tips, die man als
          Anwender von Novell DOS 7 wissen sollte.
   [u] =  Enthält Hinweise auf undokumentierte Eigenschaften des Systems

                                                                             
   ii. Übersicht:
   --------------

   I.    EINFÜHRUNG

            1. Inhalt
                  i. Vorbemerkungen
                 ii. Übersicht
            2. Novell DOS 7 Updates                                      [i]
                  i. Bezugsquellen
                 ii. Derzeit aktuelle Updates
                iii. Entpacken der Updates
                 iv. Hinweise zu den einzelnen Novell DOS 7 Updates
                  v. Weitere Hinweise
            3. Novell DOS 7 Bug-Reporte/Feedback/Diskussionsforen
                  i. Bug-Reporte Personal NetWare (Novell)
                 ii. Bug-Reporte DR DOS/Novell DOS/Caldera OpenDOS (Caldera)
                iii. Diskussionsforen
            4. Novell DOS 7 - eine (persönliche) Kurzkritik - mit Grabrede
            5. Caldera OpenDOS 7.01 - erste Erfahrungen                \ [i]

   II.   ALLGEMEINES

            1. SwitChar-Support                                          [u]
                  i. SwitChar - Was ist denn das?
                 ii. Übersicht über unterschiedliche SwitChar-Unterstützung
            2. Konfigurationsdateien CONFIG.SYS und AUTOEXEC.BAT umgehen [i]
            3. CD-ROMs und Cache                                         [i]
            4. Undokumentierte Eigenschaften externer Kommandos          [iu]
            5. Undokumentierte Möglichkeiten von DEBUG                   [iu]
                  i. Inkompatibilitäten zu MS-DOS DEBUG
                 ii. Grundsätzliche Verbesserungen
                iii. Undokumentierte Kommandos und Optionen
                 iv. Weitere Hinweise und spezielle Möglichkeiten
            6. STACKER beim Booten nicht laden                           [u]
            7. STACKER auf Version 4 updaten
            8. Rechnerkopplung über Punkt-zu-Punkt-Verbindungen          [i]
            9. Erweiterte Kommandozeilen-Syntax am Prompt                [iu]
           10. Gemischte DOS-Systeme
           11. Interne Kommandos und Optionen von COMMAND.COM            [iu]
                  i. Aufrufoptionen
                 ii. Hinweise für Kommando-Syntax interner Kommandos
                iii. Hinweise zu internen Kommandos
           12. Hinweise zum Editieren am COMMAND.COM Prompt
           13. Patchen der US-Version auf deutsche Ja/Nein-Abfragen
           14. Hinweise zu VERIFY                                        [i]
           15. Unter Novell DOS 7 lauffähige MS-DOS 6.22 Kommandos
           16. Landessprachliche Unterstützung                           [iu]
                  i. Einrichtung von Codeseiten
                 ii. Tips zum 'Nachrüsten' fehlender Geräte oder Codeseiten
                iii. Landescodes und Keyboard-Kürzel
                 iv. Codeseiten
                  v. Internationale Batchjobs
           17. Zögerlicher Platten-/Diskettenzugriff unter Novell DOS/DR DOS
           18. Mit STACKER Hauptspeicher 'virtuell' verdoppeln...
           19. Einstellungen in Novell DOS 7 .INI-Dateien                [iu]
           20. Nicht erlaubte Zeichen in Dateinamen
           21. Physik der Verzeichniseinträge unter Novell DOS           [iu]

   III.  CONFIG.SYS

            1. Undokumentierte Direktiven und Eigenschaften              [iu]
                  i. Allgemeine Einstellungen
                 ii. Laden von Gerätetreibern und TSR-Programmen
                iii. Kommentare, Meldungen, Bildschirmsteuerung
                 iv. Benutzereingaben, Zeitsteuerung, Default-Verhalten
                  v. Konfigurationsmenüs, Verzweigungen, Blockbildung
                 vi. Fehlermanagement
            2. Undokumentierte Möglichkeiten von LASTDRIVE=              [iu]
            3. Verhalten von ECHO=
            4. Hinweise zu DEVICE=/DEVICEHIGH=                           [u]
            5. Möglichkeiten von INSTALL=                                [iu]
            6. Hinweise zur Vorab-Umgebung in Verbindung mit 4DOS
            7. Novell DOS Boot-Menüs aus der Sicht von MS-DOS
                  i. [MENU], [COMMON], MENUITEM=, MENUDEFAULT=
                 ii. INCLUDE=
                iii. SUBMENU=
                 iv. MENUCOLOR=

   IV.   AUTOEXEC.BAT UND BATCHJOBS

            1. Bug in ECHO. (behoben)
            2. Fehler bei Abfrage von Variablen, die mehrere Parameter
               enthalten (behoben)
            3. Abfrage von geladenen Gerätetreibern                      [iu]
            4. Novell DOS Kompatibilität unter 4DOS erhöhen              [i]
            5. MEM /FREE und /MODULE bei Novell DOS nachrüsten
            6. Batchjobs und Umleitungen                                 [i]
            7. Spezielle Umgebungsvariablen von Novell DOS/DR DOS        [iu]
            8. Novell DOS aus Batchjobs heraus erkennen                  [i]
                  i. Novell DOS COMMAND.COM als Master-Kommandoprozessor
                 ii. Novell DOS Kernel unter 4DOS 5.0+
                iii. Sekundäres 4DOS unter Novells COMMAND.COM

   V.    SPEICHER-MANAGEMENT

            1. Bessere Speicherausnutzung durch Option /USE bei HIMEM/EMM386
                  i. HIMEM.SYS                                         \ [iu]
                 ii. EMM386.EXE
            2. Zusätzliche Optionen von EMM386.EXE                       [u]
            3. Zusätzliche Optionen von HIMEM.SYS                        [u]
            4. Bessere Speicherausnutzung mit selbsthochladenden Programmen
            5. Hinweise zu LH/LOADHIGH/HILOAD                            [u]
            6. Video-Speicher für Programme nutzen                       [iu]
                  i. Erweiterung des konventionellen Speichers (MEMMAX +V)
                 ii. Erweiterung des UMB-Speichers (MEMMAX +U)
                iii. Kombinationen/Beispiele
            7. UMB-Region-Support                                        [iu]
            8. Tuning-Tips für 4DOS-Benutzer

   VI.   NETZWERK

            1. Netzwerk-Hardware                                         [i]
            2. PNW-Software-Einrichtung                                  [i]
            3. Mehrere PNW-Server in einem Netz                          [u]
            4. PNW Login-Skripte in Multi-Konfigurationen
            5. NETWARS als Netzanalyse-Werkzeug
            6. PNW und Dateiattribute
                  i. PNW und Dateiattribute von DOS
                 ii. Mit PNW Systemdateien über's Netz löschen
            7. Tips für Paßwörter                                        [i]
            8. PNW ohne Novell DOS 7 installieren                        [i]
            9. Hinweise zu NET.EXE                                       [u]
           10. Hinweise zur Universal Naming Convention (UNC)            [i]
           11. PNW-Server und Sharing von Wechselmedien
           12. NET.CFG Parameter                                         [u]

   VII.  MULTITASKING UND PROZESSUMSCHALTUNG

            1. Fehlverhalten von TASKMGR mit älteren Maustreibern (behoben)
            2. Undokumentierte Einstellungen für den TASKMGR             [iu]
                  i. Multitasker
                 ii. Prozeßumschalter
            3. Novell DOS TASKMGR und 4DOS kombinieren                   [i]
            4. TASKMGR Multitasker in Verbindung mit 4DOS aus Batchjobs  [i]
               aktivieren
            5. TASKMGR & Multiuser-Betrieb                               [u]
            6. TASKMGR und LOCK
            7. Tastaturprobleme unter dem multitaskenden TASKMGR

   VIII. NOVELL DOS 7 UND MS WINDOWS 3.xx

            1. Novell DOS und MS Windows 3.xx kombinieren                [i]
                  i. Der AARD-Code - eine peinliche 'Historie'
                 ii. Modifikationen am Windows-System durch Novell DOS SETUP
                iii. Netzwerk (PNW) Einrichtung für Windows
                 iv. Weitere Hinweise
            2. Novell DOS, MS Windows 3.xx und Genius-Maustreiber 10.20
            3. Novell DOS und MS Windows 3.xx Netzinstallation           [i]
            4. Windows-Maus in DOS-Boxen im Fenster benutzen             [iu]

   IX.   LITERATUR

            1. Novell DOS 7 Handbuch
            2. Das große Buch zu Novell DOS 7 (Data Becker)
            3. Novell DOS 7 - Das Kompendium (Markt & Technik)           [u]
            4. Novell DOS 7 und Personal NetWare (Addison Wesley)        [u]
            5. Novell DOS 7 - Networking, Multitasking, Systemoptimierung [u]
            6. Undocumented DOS (Addison Wesley)                         [u]
            7. DOS 5 für Programmierer (Addison Wesley)                  [u]
            8. Weitere Literatur
            9. c't/iX Artikel                                            [u]
           10. Andere Zeitschriftenartikel
           11. Interessante Web-Sites bezüglich Novell DOS               [i]


   Weitere Tips (besonders zu COMMAND.COM internen Befehlen) finden sich
   auch in NWDOS7UN.TXT, z.B. über:

   -  COMMAND Hilfesystem
   -  Sprachumfang in Batchjobs
   -  CD-ROM-Einbindung
   -  VIEWMAX (ein GEM-konformer Desktop) auf höhere Video-
      Auflösungen konfigurieren und in Verbindung mit TASKMGR
      zu graphischer Multitasking-Oberfläche kombinieren

                                                                             
  ---------------------------------------------------------------------------

  I.2. Novell DOS 7 Updates: [97-05-05]
  =====================================

   Stichworte: NWDOS, PNW, VLM, Updates, Tutorials, FTP, NetWire, WWW,
               FaxBack, INSTALL, SETUP, SETUP2, PNUNPACK, UNSECURE,
               YESCHAR=, History, DPMS, MEMMAX, Bugs

   Jeder lizensierte Besitzer von Novell DOS darf bei Novell kostenlos
   Updates downloaden, die kostenlos weiterverteilt werden dürfen,
   sofern sie nicht modifiziert werden. Beachten Sie die Hinweise,
   die beim Entpacken der Archive angezeigt werden, sowie die dort
   beiliegenden Textdokumente.

   Als Angehöriger einer Ausbildungsstätte, Student oder Schüler,
   aber auch als Angehöriger einer von Caldera anerkannten religiösen
   und caritativen Einrichtung können Sie nun auch bei Caldera den
   Nachfolger von Novell DOS 7, Caldera OpenDOS 7.01 downloaden und
   kostenlos benutzen (näheres siehe Kapitel I.3.).

   i. Bezugsquellen:
   -----------------

   Die Updates zu Novell DOS sind z.B. im Internet über FTP zu finden:

    Primärquellen (ndos7 bedeutet hier "Novell DOS", nicht etwa NDOS):

     URL: http://support.novell.com/home/desktop/nd7/*.*
                                             .../pnw/*.*
                                             .../nwl/*.*
                                             .../dr6/*.*
                                .../home/client/doswin/*.*
     URL: ftp://ftp.novell.de/pub/updates/dsktop/ndos7/*.*
                                             .../pn10/*.*
                                             .../nwl11/*.*
                                             .../drdos60/*.*
     URL: ftp://ftp.novell.com/pub/updates/...

    Sekundärquellen:

     URL: ftp://ftp.uni-paderborn.de/msdos/novell/public/dsktop/...
     URL: ftp://ftp.uni-stuttgart.de/pub/systems/msdos/util/novell/...
     URL: ftp://ftp.leo.org/pub/comp/platforms/pc/???
     URL: http://www.leo.org/pub/comp/platforms/pc/???

    Der Durchsatz beim US-Server ftp.novell.com ist paradoxerweise
    besonders nachmittags und nachts sehr viel höher als beim deutschen
    ftp.novell.de, der ganz allgemein als sehr langsam eingestuft werden
    kann!!! Extrem schnell ist allerdings der Server der Uni Paderborn,
    der einen Novell-Mirror enthält, der offenbar ca. einmal jährlich
    aktualisiert wird (05/1996, und daher im Moment ausgesprochen
    aktuelle Dateien enthält). Der Server der Uni Stuttgart, auch
    sehr schnell, verfügt ebenfalls derzeit (05/1996) über aktuelle
    Novell DOS 7 und PNW Updates.

    User-Login bei FTP: ANONYMOUS
    Paßwort bei FTP   : Ihre EMail-Adresse

   über Gopher

    <gopher.novell.com>

   oder über WWW:

    URL: http://www.novell.de/            (Deutschland)
    URL: http://netwire.novell.de/        (Deutschland)
    URL: http://www.novell.com/           (USA)
    URL: http://support.novell.com/home/  (USA)
    URL: http://netwire.novell.com/       (USA)

   Die Updates liegen an unterschiedlichen Stellen, befinden sich
   jedoch größtenteils in der Netwire-Sektion 1 oder in der Update-Ära
   und heißen

    D70xyy.EXE   Novell DOS Update.
    P10xyy.EXE   Personal NetWare Update (siehe Hinweise weiter unten!!!)
    VLMUPy.EXE   VLM-Update und Client-Software (auch für PNW)
    WINDRy.EXE   Notwendige Updates für Windows-Support nach VLM-Update
    NWDLLy.EXE   mit  x =  g (Deutschland)  s (Spanien)
                           u (USA)          i (Italien)
                           f (Frankreich)
                           j (Japan, habe ich aber bisher noch nie gesehen,
                             zumindest eine japanische PNW-Ausgabe soll es
                             aber wirklich geben...)
                     yy =  Update-Nummer

   Um sich über die Verfügbarkeit von Updates zu informieren, können Sie
   im Internet auch Suchdienste wie Archie in Anspruch nehmen
   (z.B. <archie.th-darmstadt.de>) oder auf den WWW-Seiten bei Novell USA
   eine entsprechende Suchanfrage nach der jeweiligen Datei aufgeben
   (URL: http://netwire.novell.com/FileUpdt).

   Es ist jeweils nur das letzte Update notwendig, das im allg. alle
   vorherigen Updates enthält. Allerdings kam es schon mehrfach vor,
   daß Dateien 'vergessen' wurden. Daher sollten Sie in jedem Fall die
   HISTORY.TXT Dateien der einzelnen Updates aufbewahren und beim Update
   vergleichen. Nur so können Sie sicherstellen, daß Sie nicht versehentlich
   ein altes Update löschen, obwohl es Dateien enthält, die im Nachfolge-
   Update nicht enthalten sind.

   Seit P10x05.EXE wird zusätzlich noch VLMUPx.EXE, u.U. auch noch
   WINDRx.EXE und NWDLLx.EXE erwartet. Ein DPMS-Update gibt es auch
   einzeln unter dem Namen DPMSUP.EXE, allerdings ist dieses Paket
   nicht so aktuell wie das Novell DOS 7 Update. Normalerweise wird
   für PNW das sehr umfangreiche 'Novell Client Kit for DOS & Windows'
   (6 Disketten) nicht benötigt, da die wichtigsten Dateien für DOS,
   Windows und PNW auch in den schon angesprochenen Updates enthalten
   sind. Im Einzelfall mag es dennoch sinnvoll sein, das komplette
   Client Kit zu besorgen (ehemals VLMKT1.EXE - VLMKT6.EXE für VLM-
   Stufe 1.20B, seit 11/1996 nun VLM121_1.EXE - VLM121_6.EXE für
   VLM-Stufe 1.21, für TCP/IP mit PNW auch noch TCP16.EXE).
   Dort finden sich z.B. auch Message-Dateien in anderen Sprachen,
   Codeseiten-Dateien für andere Länder, ein paar VLMs mehr, etwas neuere
   RPL-Treiber, sehr viel mehr MLID-Treiber, auch für SLIP und PPP.
   Achtung: Teilweise sind in den neueren Paketen aber auch Treiber
   weggefallen, z.B. findet sich der Treiber SLIP_PPP.COM in VLMKT6.EXE,
   nicht aber mehr im VLM121_?.EXE Paket.
   Derzeit (02/1997) ist das Client Kit bereits auf dem VLM-Stand 1.21
   (wie bei IntranetWare und NetWare 4.11), während VLMUP4.EXE auf dem
   VLM-Stand 1.20B war.

   Das recht neue Client32 Paket für DOS/Windows (8 Disketten, z.B. in
   DWDEU_N2.EXE und DWDEU_L2.EXE - nicht zu Verwechseln mit dem bereits
   einige Monate länger existierenden Produkt für MS Windows95) enthält
   eine Reihe zusätzlicher Unicode-Dateien und allerhand DOS- und Windows-
   Netztreiber in erheblich neueren Versionen als noch in P10x05.EXE (z.B.
   LSL.COM, VNETWARE.386, usw.); gegenüber VLM121_?.EXE scheint es aber
   keine aktuelleren Dateien mehr zu geben.
   Möchte man diese Treiber verwenden, sollte man sie allerdings unbedingt
   manuell mit NWUNPACK/PNUNPACK entpacken und installieren, da das bei-
   liegende INSTALL-Programm natürlich den neuen, wirklich sehr speicher-
   platzschonenden Client auf der Basis von NIOS.EXE installiert.
   Leider kann dieser sich bis auf 2 - 5 KByte auslagernde 32Bit-Client
   (ODI32/NIOS+NLMs) aber außer NetWare 2.xx, 3.xx und 4.xx nicht auch mit
   PNW 1.0 verwendet werden. Auf einem reinen Client-Rechner fehlt eine
   passende LOGIN-Möglichkeit auf einen PNW-Server, da PNWs NET.EXE nur
   mit VLM.EXE läuft, VLM.EXE und VLMs aber nicht mit dem neuen NIOS.EXE;
   andere Tools erwarten PNW.VLM, das damit natürlich ebenfalls nicht zur
   Verfügung steht...
   Die Verwendung einzelner aktualisierter Dateien, sofern sie schon bei
   PNW 1.0 existierten, scheint hingegen auch mit einem Client auf der
   Basis von ODI/VLM+VLMs unproblematisch zu sein. Vielleicht hat ja jemand
   schon ausführliche Erfahrungen hiermit gesammelt?

   Jedenfalls läßt Novell in diesem Bereich dem Benutzer nach wie vor
   viel Spielraum für 'Experimente', welche Dateien aus welchen Paketen
   denn jetzt am besten zusammenpassen. ;-)

   Meistens funktioniert's trotzdem, aber eben nicht immer. Achten Sie
   also unbedingt auf das Dateidatum und besser die interne Versionsnummer
   (da das Datum teilweise nicht stimmt). Zur Ausgabe der internen
   Versionsnummern können Sie z.B. VERSION.EXE verwenden.


   ii. Derzeit aktuelle Updates:
   -----------------------------

   D70G15.EXE und P10G05.EXE sind die letzten Updates zu Novell DOS 7 bzw.
   Personal NetWare 1.0. Zusätzlich brauchte man früher für PNW VLMUP4.EXE,
   mit Windows auch noch WINDR3.EXE und NWDLL2.EXE. Mittlerweile sollte man
   stattdessen das Client-Kit VLM121_1.EXE - VLM121_6.EXE (VLM-Stand 1.21)
   verwenden, die wesentlich aktueller sind.

   Das Update D70G11.EXE sollten Sie trotzdem aufbewahren, da hier Dateien
   enthalten sind, die in späteren Updates wieder fehlen.

   P10G05.EXE (Januar 1995) enthält einige Dateien (DPMS.EXE), die durch
   spätere Novell DOS Updates mittlerweile völlig überholt sind. Achten
   Sie darauf, daß Sie die entsprechenden Dateien aus jüngeren Novell DOS
   Updates nicht überschreiben.
   Mittlerweile gibt es auch von der Datei P10G05.EXE unterschiedliche
   Versionen: Die ältere Version enthielt das komplette Update-Paket,
   die mir bekannten aktuelleren Versionen (die offenbar keine neuen
   Fixes enthalten) sind erheblich kleiner (nur 200 - 300 KByte, statt über
   500 KByte) und sollten daher über das amerikanische Update P10U05.EXE
   installiert werden, das nach wie vor in vollem Umfang ausgeliefert wird.
   Am besten vergleichen Sie die Dateigröße von P10U05.EXE und P10G05.EXE
   direkt beim Download; sollten sie sich um mehr als vielleicht 150 KByte
   voneinander unterscheiden, sollten Sie die einzelnen Dateien genauer
   untersuchen.

   Alternativ dazu gibt seit 1995 statt P10G05.EXE und den anderen
   NetWare Updates auch speziell für PNW vorbereitete englischsprachige
   'automatisierte' Updates (PNWUPD.EXE für DOS und PNWUPW.EXE für
   Windows), sowie einen speziellen NET.EXE-Fix für XTs (PNXTFX.EXE).
   Diese Pakete waren ursprünglich noch auf dem Stand von VLMUP2.EXE
   (später VLMUP3.EXE), die derzeit erhältlichen Versionen sind aber
   bereits auf VLMUP4.EXE upgedatet worden. PNWUPD.EXE (04/1996) enthält
   zwar einerseits eine mittlerweile uralte Version von DPMS.EXE (aus
   P10U05.EXE), andererseits aber auch eine neuere Version von NET.EXE
   (v1.05 statt v1.03, wie noch in P10U05.EXE), und erste Hinweise
   bezüglich des Zusammenspiels mit MS Windows95!
   Offenbar werden die P10xyy.EXE Archive also nicht mehr weiter gepflegt.

   Zur Analyse von Kommunikationsproblemen in Netzen gibt es ein Paket
   namens COMCHK.EXE, das ein Analysewerkzeug enthält.

   Für Remote Program Load (RPL) (Booten von Diskless-Workstations) gibt es
   seit einiger Zeit auch noch ein Archiv namens RPLKT3.EXE (03/1996), das
   die Dateien ersetzt, die z.B. bei DR DOS 6.0 und Novell DOS 7/PNW 1.0
   beilagen. Auch die Dokumentation dazu ist etwas umfangreicher, wenn auch
   immer noch nichts für Laien...

   Offenbar werden alle diese Dateien (ohne eigene Versionsnummer) still-
   schweigend upgedatet, so daß man alle paar Monate überprüfen sollte, ob
   es vielleicht eine neuere Version der Archive gibt. Dabei ist problema-
   tisch, daß das Dateidatum auf den FTP-Servern in der Regel das Upload-
   Datum ist, das nicht unbedingt dem Erzeugungsdatum entsprechen muß.

   Novells Konventionen sind über die letzten Jahre hinweg in einigen
   Punkten inkonsistent gewesen (neuere Dateidaten mit alten Dateiinhalten,
   gleiche Treiberdateien mit unterschiedlichem Datum, unterschiedliche
   Namenskonventionen, unterschiedliche Versionen auf unterschiedlichen
   FTP-Servern, Unterschiede zwischen landessprachlichen Versionen), so
   daß ich hier nur 'ad hoc'-Erfahrungswerte mitteilen kann.

   Novell gibt auch eine eigene Sammlung von Tips & Tricks heraus, die
   ursprünglich dem FaxBack-System (Telefon-Nr. +1 (800) 228-9960 oder
   +1 (801) 429-3239) von Novells BBS entstammten, aber nun auch im
   Internet verfügbar sind:

    ND7TID.EXE
    PNWTID.EXE
   (DR6TID.EXE und NWLTID.EXE für DR DOS 6.0 und NetWare Lite)

   Auch diese Archive werden ab und zu aktualisiert (was aber jetzt schon
   lange nicht mehr geschehen ist), sobald neue Dokumente verfügbar werden.
   Im Großen und Ganzen sind diese Archive äußerst empfehlenswert, da sie
   von einfachen Fragestellungen (etwa: "Was ist DOS?", "Der Aufbau eines
   PCs", "Die verschiedenen Standards zur Speicherausnutzung") über
   Beispielkonfigurationen und Antworten auf häufig gestellte Fragen bis
   hin zu ausführlichen Leitfäden (etwa zur Kombination von Novell DOS 7 mit
   IBM OS/2 2.x+ (funktioniert bis auf systembedingte Einschränkungen), für
   Remote Booting von Diskless Workstations mit PNW, oder der Koexistenz von
   Novell DOS 7/PNW mit MS Windows95) sehr viele Problemstellungen rund um
   das gesamte System abdecken. Das Spektrum der über WWW online abzu-
   rufenden TID-Reporte ist derzeit (05/1996) sehr viel umfangreicher, als
   die obigen Download-Pakete.
   In diesem Zusammenhang bietet Novell USA über WWW die Möglichkeit, auch
   *selbst* TID-Reporte für Novell zu verfassen. Novell gibt als Begründung
   dafür an, daß (auch) sie bemerkt hätten, daß manche Anwenderprobleme mit
   ihrer Software auch einfach an fehlender oder irreführender Dokumentation
   liegen, oder daß manche Problemlösung sich ganz einfach den üblichen
   Dokumentationsmöglichkeiten entzieht, d.h. nur von den Benutzern in der
   Praxis gefunden werden kann...

   Zu Novell DOS 7 gibt es wohl noch eine ganze Reihe einführender Tutorials
   zu verschiedenen Themengebieten (MEM_TUT.EXE, STAC_TUT.EXE, TMGR_TUT.EXE,
   NWCH_TUT.EXE, DOPT_TUT.EXE, SEC_TUT.EXE, FLNK_TUT.EXE). Diese können per
   Modem von Novells BBS (USA) geordert werden (+1 (801) 221-5197 oder
   +1 (801) 225-4444), und sind anscheinend nicht auf den FTP-Servern im
   Internet zu finden.

   Auch zu PNW gibt es zwei Tutorials (DOSTUTOR.EXE und WINTUTOR.EXE), die
   auf einer Zusatzdiskette zu PNW liegen. Die üblicherweise in Deutschland
   ausgelieferten Novell DOS 7 Original-Pakete (7 Disketten, etwa von Mail
   Elektronik) enthalten diese Diskette aber nicht, in OEM-Versionen (etwa
   von DataExpert) sind sie jedoch auf einer achten Diskette zu finden.
   Falls Sie diese Tutorials haben möchten, wenden Sie sich bitte an Ihren
   Novell-Händler, der Sie Ihnen höchstwahrscheinlich kostenlos besorgen
   können wird.
   Seit 1997-02-03 können Sie die Tutorials zu PNW jedoch auch bei Caldera
   downloaden (PNWTUTOR.EXE):

    URL: http://www.caldera.com/dos/

   Seit einiger Zeit gibt es auch ein Paket, das aus den 3,5" Original-
   Installationsdisketten von Novell DOS 7 ein SETUP für PNW ohne Novell DOS
   generiert. Dieses Paket heißt:

    D72PNW.EXE     (sprich: "DOS 7 to PNW")

   und ist damit eine sehr kostengünstige Möglichkeit, an eine Personal
   NetWare Lizenz zu kommen (da Novell DOS 7 + PNW 1.0 inklusive Handbuch
   und Tutorial teilweise schon für DM 15,- in Aktionsverkäufen über den
   Ladentisch geht.) Das gleichwertige separate Produkt PNW 1.0 war (und
   ist) gegenüber dem Bundle mit Novell DOS 7 paradoxerweise schon immer
   teurer...
   Mit Caldera OpenDOS 7.01 erhalten Sie als Angehöriger einer Ausbildungs-
   einrichtung, Student oder Schüler jedoch Personal NetWare 1.0 kostenlos
   (siehe Kapitel I.3.).


   iii. Entpacken der Updates:
   ---------------------------

   Diese Archive sind selbstentpackend, was normalerweise besonders
   praktisch ist. Andererseits gibt es nicht wenige DOS-Rechner, die
   nicht genug freien Platz auf der Festplatte haben, um 'mal eben'
   ein paar MegaByte zur Ablage bereitzustellen. Oder es stellt sich die
   Situation, daß Sie nur ganz bestimmte Dateien aus dem Update benötigen,
   etwa wenn Sie zum Vergleich der Sprachen eine Datei aus allen landes-
   sprachlichen Updates benötigen. Kein Problem: Rufen Sie die .EXE-Datei
   mit Option /? auf! Es erscheint ein Hilfeschirm, der alle Optionen des
   integrierten Archivprogramms erläutert.

   Um es kurz zu machen, ein Beispiel:

    D70G15.EXE -e -s c:\tmp command.com

   entpackt nur die Datei COMMAND.COM nach C:\TMP (evtl. statt -e auch -x
   angeben, siehe auch GETD70.BAT in Kapitel II.16.).

   Möchten Sie mit ARJ arbeiten, können Sie die .EXE-Datei auch einfach zu
   .ARJ umbenennen. ARJ kann darin enthaltene Dateien mit den üblichen
   Optionen entpacken (innerhalb des Norton Commanders ist dies allerdings
   wegen des anderen Dateikopfes nicht möglich).


   iv. Hinweise zu den einzelnen Novell DOS 7 Updates:
   ---------------------------------------------------

   Bei Update 11 (1995-01-31) von Novell DOS liegen auch die Dateien
   INSTALL.EXE, SETUP.EXE und SETUP2.EXE dem Paket bei. Im Update 12
   (D70U12.EXE) und später fehlen diese Dateien wieder, d.h. man sollte
   eine Kopie dieses Updates oder dieser Dateien aufbewahren (allerdings
   funktionierte auf meinem Testsystem die neue Fassung von SETUP2.EXE
   nicht, wenn man sie über SETUP aufruft). Das Update 11 bringt alle
   Updates und Patches bis Anfang 1995 zusammen.

   Mit Update 12 (1995-02-17) wurden eine Reihe Schönheitsfehler beseitigt
   und die Speichermanager nochmals überarbeitet.

   Bei Update 13 (1995-05-08) wurde der Speichermanager nochmals über-
   arbeitet (besonders im Hinblick auf DOS-Extender nutzende Applikationen
   wie Borland IDEs). Dieses Update ermöglicht äußerst stabil laufende
   Systeme. Mit diesem Update wurde auch eine überarbeitete Fassung von
   MEMMAX ausgegeben, mit der es auch wieder möglich ist, die Aktivierung
   der drei Speicherbereiche auch unter 'Sekundär'-Shells wie 4DOS.COM /P
   (über COMMAND.COM /P) zu ändern (diese Möglichkeit war aufgrund damals
   bestehender Schwierigkeiten in einem früheren Update (9???) entfernt
   worden).

   Update 14 (1995-08-11, Englisch) bringt recht massive Überarbeitungen
   aller Speichermanager und Utilities. EMM386 unterstützt nun auch
   Memory-Backfilling (zumindest bis in den Video-Speicher; AST EEMS
   wird aber wohl weiterhin nicht unterstützt, aber das gilt auch für
   die allermeisten anderen DOS-Speichermanager) und UMB-Regions. Die
   Möglichkeiten für Video-UMBs wurden erweitert.
   Leider stellten sich auf verschiedenen Systemen mit der aktuellen
   Version von DPMS 1.42 verschiedene Probleme ein, so daß ich empfehle,
   diese Version nicht zu verwenden und stattdessen die alte aus Update 13
   weiter zu verwenden (oder Update 15 zu verwenden).
   Die Probleme zeigten sich z.B. auf verschiedenen Systemen (zwei alte
   286er ohne UMBs, aber mit Extended Memory (und HMA), und ein 486er)
   durch Absturz während der Initialisierungsphase.
   Auf zwei anderen Rechnern (386er) gab es EMM386-Schutzfehler während
   des Einloggens ins PNW-Netz oder später.
   Dieses Paket enthält noch die aktualisierten Dateien PRINT.COM,
   SETFIFO.EXE, TREE.EXE, XDEL.EXE und XDIR.EXE, die (wohl versehentlich)
   in der ersten Version des folgenden Updates 15 fehlen. Daher sollte
   man dieses Update aufbewahren, falls Sie nicht bereits das Update 15
   aus dem Januar 1996 haben.

   Update 15 (1995-12-05, 984.594 Bytes) löst die DPMS-Probleme durch
   ein weiteres Update (1.43) dieses Treibers. Ansonsten wurden einige
   Änderungen an den Speichermanagern vorgenommen (EMM386 3.1 -
   eigentlich sollte es besser 3.10 heißen -) und einige Fixes (z.B.
   SwitChar und <F5>/<F8>-Handling) und Größenoptimierungen in den
   Kernel-Dateien (IBMBIO.COM und COMMAND.COM) bewerkstelligt. Dabei
   wurde höhere Kompatibilität zu MS-DOS angestrebt (DIR unterstützt
   jetzt auch Tausender-Separatoren, Medien-Seriennummer werden
   unterstützt). Das Update 15 ist durchweg zu empfehlen, mal davon
   abgesehen, daß die Dateien PRINT.COM, SETFIFO.EXE, TREE.EXE, XDEL.EXE
   und XDIR.EXE aus unerfindlichen Gründen fehlen (und aus Update 14
   entnommen werden sollten).

   Es gibt mittlerweile auch eine Version von D70G15.EXE vom 1995-12-21 bis
   1996-03-01 (1.046.550 Bytes), die diese fehlenden Dateien und noch einige
   weitere Fixes (FCBs) enthält. Da Novell in 07/1996 "DR DOS" an Caldera
   übergeben hat, dürfte dies auch das letzte Update zu Novell DOS 7 sein,
   das von Novell zu erwarten war. Zwar sind selbst in dieser Release noch
   einige (meist reichlich an den Haaren herbeigezogene) Bugs enthalten
   (*Setzen* des undefinierten Landescodes 0 führt zum Absturz, UpCase von
   Zeichenketten der Länge 0 führt zum Absturz u.ä.), aber mir sind keine
   ernsthaften Praxisprobleme mit dieser Version bekannt (wenn, dann würde
   ich in dieser Datei an den entsprechenden Stellen darauf hinweisen).
   Also eine runde Sache und sehr zu empfehlen.
   Caldera hat u.a. auch angekündigt, weiterhin Detailpflege an Nachfolge-
   produkten von Novell DOS zu betreiben und Caldera OpenDOS 7.01 wurde
   am 1997-02-03 freigegeben; näheres dazu in den Kapiteln I.3., I.4., I.5.
   und IX.11.


   v. Weitere Hinweise:
   --------------------

   INSTALL.EXE und SETUP.EXE sind bei Novell DOS identisch; je nachdem, wie
   die Datei genannt wird, erfüllt sie aber einen andere Funktion:
   Heißt die Datei INSTALL.EXE, so wird entweder ein System von den
   Installationsdisketten auf die Festpatte installiert oder es besteht die
   Möglichkeit, Boot-Disketten zu erzeugen, auch ohne, daß man dafür unter
   Novell DOS gebootet haben müßte.
   Dabei wird u.a. eine Datei SETUP2.EX_ als SETUP2.EXE auf die Festplatte
   kopiert und dort entpackt. Diese Datei wird dann später aufgerufen.
   Durch INSTALL wird zwar das gesamte System (je nach Wahl mit PNW und
   Windows-Tools) installiert, jedoch nur sehr rudimentär eingerichtet.
   Leider kann man die Windows-Programme nicht installieren, wenn man kein
   Windows-Verzeichnis angibt. Außerdem muß man anscheinend zusätzlich PNW
   installieren.
   INSTALL.EXE wird während der Installation in SETUP.EXE umbenannt.
   Nach der Installation mit INSTALL muß man den Rechner neu booten und
   kann dann durch Aufruf von SETUP mit der Feineinstellung fortfahren
   (das Security-System, PNW-Initialisierung und STACKER lassen sich nur
   über SETUP aktivieren). Auch später kann man SETUP zum Ändern von
   Systemeinstellungen verwenden.

   Auf die Harddisk brauchen Sie also nur SETUP.EXE und SETUP2.EX_ zu
   kopieren. Für den Fall einer Installation von den Original-Disketten
   bewahren Sie die neue Version von INSTALL.EXE auf. Die Datei
   SETUP2.EX_ ist noch gepackt und läßt sich leider auch nicht mit
   EXPAND (von MS-DOS etc.) entpacken. Hierfür wird das Programm PNUNPACK
   von der Installationsdiskette 1 benötigt (Hilfe erhalten Sie mit
   PNUNPACK /?). Um das System zu vervollständigen, können Sie bei dieser
   Gelegenheit die Dateien PNUNPACK.EXE und UNSECURE.EXE auch direkt auf
   die Harddisk kopieren (UNSECURE wird benötigt, wenn Sie wieder auf ein
   abgesichertes System zugreifen wollen - insofern ist es auf der Platte
   eigentlich unnütz, aber auf diese Weise wird ein vollständiges Backup
   des Systems erleichtert).

   Möchten Sie nur den PNW-Teil von Novell DOS 7 installieren, reicht
   es aus, die Novell DOS 7 Disketten auf die Festplatte zu kopieren
   und die Datei SETUP2.EX_ entsprechen obiger Prozedur zu entpacken
   und in SETUP.EXE umzubenennen. Nach dem Aufruf kann man PNW ohne
   Novell DOS 7 installieren (denn SETUP2 übernimmt die Feineinstellung
   und die Installation einzelner Features wie PNW, Security etc.,
   wohingegen INSTALL das Grundsystem bootfähig macht). Seit kurzem
   gibt es von Novell auch eine offizielle Lösung für dieses Unterfangen.
   Näheres siehe Kapitel VI.8.

   Noch ein Hinweis: In einigen Computerzeitschriften wurden bestimmte
   Interrupts reklamiert, die Novell DOS 7, obwohl es sich vom API her
   als 6.0 ausgibt, noch nicht unterstützt. Einen großen Teil dieser Dinge
   habe ich mit Update 13-15 nachvollzogen und dabei herausgefunden, daß
   zumindest jetzt ein Großteil dieser fehlenden Funktionen unterstützt
   wird (abgesehen von manchen proprietären APIs, die nur bestimmte
   Dienstprogramme betreffen und eigentlich nur vom jeweiligen Programm
   selbst sinnvoll genutzt werden können). Hier sind kaum Kompatibilitäts-
   einschränkungen zu erwarten, bzw. Applikationen, die auf solchen Dingen
   basieren, kann man getrost als 'nicht vollständig kompatibel' zu DOS
   bezeichnen. Im Zweifelsfall sollte man die Interrupt-Liste von Ralf Brown
   in einer aktuellen Version zu Rate ziehen (s.o.).

                                                                             
  ---------------------------------------------------------------------------

  I.3. Novell DOS 7 Bug-Reporte/Feedback/Diskussionsforen: [97-04-23]
  ===================================================================

   Stichworte: Bugs, Reports, Novell European Support Center (ESC), EMail,
               CompuServe, Maiser, NOVELL-DE

   i. Bug-Reporte Personal NetWare (Novell):
   -----------------------------------------

   Der folgende Absatz bezieht sich nach der Übernahme des ehemaligen DR DOS
   (zu dem auch Novell DOS zählt) durch Caldera nur noch auf Personal
   NetWare, und nicht mehr auf Novell DOS 7 (für Bug-Reporte zu Novell DOS
   beachten Sie bitte Abschnitt ii.):

   Wenn Sie selbst Bugs entdecken, schreiben Sie sie bitte auf und schicken
   Sie sie an die Administratoren der obigen Novell FTP-Server (eine bessere
   Anlaufstelle für Bug-Reporte ist mir jedenfalls nicht bekannt). Die
   Informationen werden von dort weitergeleitet - zumindest habe ich
   meine bisherigen Reporte an diese Adresse geschickt und die jüngsten
   Updates lassen erkennen, daß meine Informationen tatsächlich ihr Ziel
   erreicht haben... ;-)  Also z.B.:

    <ftp@ftp.novell.com>;

    - Die Texte müssen hierfür natürlich in Englisch verfaßt werden.
    - Ca. seit Anfang des Jahres 1996 bekommt man offenbar bei dieser
      Adresse keine Empfangsbestätigung mehr (wie dies früher üblich war),
      Reporte kommen aber auch nicht zurück und verschwinden hoffentlich
      nicht im 'Black Hole'...
      Ob es eine neue und bessere Anlaufstelle gibt, ist noch unklar.

   Über CompuServe und MSN soll es möglich sein, Bug-Reporte folgendermaßen
   abzusetzen:

    GO NODESKTOP     in Library 1 des Novell Forums gehen
    Formular SPR.ZIP ausfüllen und abschicken (evtl. auch GO NETWIRE).

   Wahrscheinlich kann man Bug-Reporte auch über die "Kommentar"-Adressen
   der jeweiligen Web-Seiten absetzen, überprüft habe ich dies noch nicht.

   Zumindest in den USA gibt es auch eine Möglichkeit, über Novells BBS
   in Kontakt mit Entwicklern zu treten. Näheres ist unbekannt.

   Und was machen, wenn Sie keinen Zugang zu elektronischer Post haben?
   (soll's ja noch geben...)

   Für dringende Probleme sollten Sie sich an den Novell European Support
   Center (ESC) in Düsseldorf wenden, die Adresse ist (Stand 06/1994):

    Novell Deutschland
    Monschauer Straße 12
    D-40549 Düsseldorf
    DEUTSCHLAND

    Tel.: +49 (211) 5631-0

   In den USA und Kanada gibt es einen interaktiven "Ask Novell" Service
   für registrierte Benutzer, der aber wohl nicht für Bug-Reporte zuständig
   ist. Man erreicht ihn über die folgende Nummer:

    Tel.: +1 (800) 768-9771  (dort Option "3" für PNW
                             oder Option "4" für Novell DOS wählen)

   Mehr oder weniger durch Zufall habe ich auf dem Rückdeckel des
   Novell DOS 7-Handbuches die Adresse der Hauptniederlassung von
   Novell USA gefunden. Ich denke, notfalls ist auch diese Adresse
   eine Anlaufstelle:

    Novell, Inc.
    122 East 1700 South
    Provo, Utah 84606
    USA

    +1 (801) 429-7000  (Diese in den USA kostenlosen Servicenummern sind von
    +1 (800) 453-1267  Deutschland aus nur manuell über einen Operator einer
                       US-Telefongesellschaft erreichbar und von hier aus
                       alles andere als kostenlos! Dies gilt auch für die
                       andere 800 und 801 Nummern in diesem Kapitel!)

   Sie können die Bug-Reporte auch an mich senden, ich werde sie weiter-
   leiten, sofern sie mir aussagekräftig genug erscheinen.


   ii. Bug-Reporte DR DOS/Novell DOS/Caldara OpenDOS (Caldera):
   ------------------------------------------------------------

   Bug-Reporte für Novell DOS 7, Caldera OpenDOS (auch im Zusammenspiel
   mit Personal NetWare) müssen in Zukunft an die ebenfalls in Provo
   ansässige Caldera Inc., der Firma von Bryan Sparks (der vorher maß-
   geblich an der Entwicklung des Personal NetWare 1.0 Servers beteiligt
   war) und Novell-Mitbegründer Raymond J. Noorda (Novells CEO zu deren
   'DR DOS Zeiten' (1991-1994)), statt an Novell geschickt werden, da
   Novell nach immerhin 15 größeren Updates (teilweise mit mehreren
   Sub-Updates) Anfang 1996 endgültig die Pflege von Novell DOS 7 ein-
   gestellt hat.

   Caldera Inc. (die auch einen kommerzielle Abkömmling des FreeWare-Unix-
   Betriebssystems Linux anbieten) haben in 07/1996 von Novell sämtliche
   Rechte an den ehemaligen Digital Research Betriebssystemen übernommen
   und haben angekündigt, ein um Internet-Fähigkeiten und eine Reihe
   anderer Funktionen erweitertes 'Novell DOS' inklusive Personal NetWare
   unter dem neuen Namen Caldera OpenDOS wieder auf den Markt bringen zu
   wollen. Als erster Sproß dieser Familie wurde das mit Novell DOS 7
   praktisch identische Caldera OpenDOS 7.01 am 1997-02-03 freigegeben
   und kann - für Angehörige von Ausbildungsstätten sowie für Studenten und
   Schüler kostenlos (!) - im Internet bezogen werden. Nachdem am 1997-04-21
   der unabhängigen DJGPP/OpenDOS-Entwicklergruppe eine Vorabversion der
   Quelltexte der OpenDOS-Systemdateien zur Ansicht gestellt wurde, folgte
   die offizielle Ausgabe der Quelltexte am 1997-05-05.
   Angefangen mit den Quellen des System-Kernels sollen Stück für Stück
   sämtliche Quelltexte von Caldera OpenDOS gefolgt von sämtlichen
   vorherigen Digital Research Betriebssystemen im Internet öffentlich
   zugänglich gemacht werden, so daß sich jeder (Firmen als auch Privat-
   personen) an der Weiterentwicklung von DOS beteiligen kann. Eine CD-ROM
   Fassung ist ebenfalls verfügbar. Näheres hierzu auf meinen Web-Seiten,
   sowie in Kapitel I.5. und IX.11.

   Außerdem hat Caldera die Antitrust-Prozesse gegen Microsoft wieder-
   aufgerollt, da Digital Research & Novell laut Calderas Aussagen einen
   Marktanteil von über 20% im DOS-Bereich hätten erzielen können, wenn
   der Monopolist Microsoft nicht, so die Anwälte der Caldera Inc.,
   "durch ungesetzliche Handlungen und räuberische Praktiken dem Wett-
   bewerb, dem Verbraucher und der Innovation" geschadet hätte.

   Man darf gespannt sein... ;-)

   Nähere Hinweise hierzu und rund um Caldera OpenDOS finden sich auf:

    URL: http://www.caldera.com/         Startseite, auch Linux
    URL: http://www.caldera.com/dos/     speziell Caldera OpenDOS
    URL: http://www.caldera.co.uk/       UK Development Centre
    URL: http://caldera.co.uk/                   ""

    URL: http://www.delorie.com/opendos/ "DJ's OpenDOS stuff" enthält
                                         eine inoffizielle FAQ von
                                         Alaric B. Williams
                                         <alaric@abwillms.demon.co.uk>;
                                         und andere Hintergrund-Infos,
                                         die von DJ Delorie
                                         <dj@delorie.com>;,
                                         dem Entwickler von DJGPP,
                                         zusammengestellt wurden.
    URL: http://www.deltasoft.com/       Inoffizielle OpenDOS-Homepage
                                         von Marek 'Mark' Habersack
                                         <grendel@ananke.amu.edu.pl>;.
    URL: http://null.musc.edu/opendos/   "OpenDOS known bug list"
                                         von Paul W. Brannan
                                         <brannanp@musc.edu>;.
    URL: http://www.pipo.com/plug/COD.html  Kommentare des französischen
                                         Clubs PLUG zu OpenDOS von
                                         Frédéric Renet <fred@waw.com>;
                                         und Vincent Renardias
                                         <vincent@waw.com>;.
    URL: http://www.naf.cz/arachne/english.htm  ARACHNE, der zukünftige
                                         Web-Browser 'WebSpyder' für
                                         OpenDOS der xChaos SoftWare
                                         von Michael Polak
                                         <xchaos@main.naf.cz>;.

   Anlaufstellen u.a. für Caldera OpenDOS, Novell DOS und DR DOS sind:

    <info@caldera.com>;         Allgemeine Infos und Kontaktaufnahme
    <dos.support@caldera.com>;  Support speziell für OpenDOS
    <techinfo@caldera.com>;     u.a. für Hinweise bzgl. OpenDOS FAQ
    <bugs@caldera.com>;         Bug-Reporte
    <comments@caldera.com>;     Kommentare

    URL: http://www.caldera.com/problem_form.html Formular für Bug-Reporte

   Wie schon früher, gilt auch jetzt noch mein privates Angebot, als
   Sammelstelle für (ernsthafte und detaillierte) Bug-Reporte zu dienen,
   die ich dann weiterleiten werde. Weiterhin schwebt mir etwas wie eine
   'Caldera OpenDOS User & System Designer Group' vor, vielleicht hat ja
   jemand Anregungen...

   Auf meinen Web-Seiten finden Sie weitere aktuelle und interessante Links,
   z.B. zu anderen FreeWare-Programmen für OpenDOS und Novell DOS.


   iii. Diskussionsforen:
   ----------------------

   Ein Diskussionsforum für offene Fragen finden Sie evtl. in der deutschen
   Novell Mailing-Liste (die sich allerdings hauptsächlich mit NetWare und
   nur am Rande mit anderen Novell Produkten beschäftigt und sich wohl auch
   nicht mehr für Calderas OpenDOS zuständig fühlen wird). Der derzeitige
   Moderator ist Klaus Arpe <Klaus.Arpe@etech.fh-hamburg.de>;.

   Wenn Sie in dieser (weitestgehend deutschsprachigen) Mailing-Liste
   Novell DOS- oder Personal NetWare-Spezifisches diskutieren, verwenden
   Sie bitte als Subjekt-Kürzel ein vorangestelltes "ND7:" bzw. "PNW:".
   Durch diese Konvention können die einzelnen Themen besser auseinander-
   gehalten werden und die Wahrscheinlichkeit ist größer, daß Ihre Anfrage
   nicht in der Masse der anderen Anfragen untergeht.

   Bei der Mailing-Liste kann man sich folgendermaßen anmelden:

    Mail-Adresse: maiser@pool.uni-mannheim.de
    Subject:
    Text: SUBSCRIBE NOVELL-DE

   Das Abmelden funktioniert wie folgt:

    Mail-Adresse: maiser@pool.uni-mannheim.de
    Subject:
    Text: UNSUBSCRIBE NOVELL-DE

   Die eigentliche Diskussion läuft über eine *andere* Mail-Adresse (was
   viele Newcomer immer wieder übersehen...), nämlich:

    Mail-Adresse: NOVELL-DE@pool.uni-mannheim.de
    Subject: ND7: Thema... (Beispiel)
    Text: ...

   Ein aus dieser Liste zusammengestelltes FAQ (Frequently Asked Questions)
   betreut Thomas Demmer <demmer@lstm.ruhr-uni-bochum.de>; (enthält derzeit
   allerdings keine Novell DOS- oder PNW-spezifischen Fragen):

    URL: http://www.lstm.ruhr-uni-bochum.de/nwfaq/faq.html
    URL: ftp://ftp.lstm.ruhr-uni-bochum.de/pub/netware/faq/faq.ps

   Für das FIDOnet hat Stefan Braunstein (<sbraunst@t-online.de>;,
   <sbaunst@aol.com>;, FIDOnet 2:2476/709) ein FAQ zusammengestellt,
   das einige Novell DOS-/PNW- und NetWare Lite-Tips enthält (etwa
   zur Kombination von PNW/NetWare Lite mit Windows 3.xx, WfW 3.11,
   Windows95 oder OS/2 2.xx und Warp 3):

    nwft_jmm.arj ist die ASCII-Version (J=letzte Jahresziffer, MM=Monat)
    nwfx_jmm.arj ist eine EXE-Version

    URL: ftp://allegro.biblio.etc.tu-bs.de/pub/novell/nwf?_???.arj
    URL: ftp://fnovbzs.tu-graz.ac.at./pub/novell/faq/nwf?_???.arj

   Dieses FAQ wurde von Jörg Napp <j.napp@hsp.owl.de>; zu einem
   HTML-Dokument konvertiert und wird online angeboten:

    URL: http://royal.owl.de/~joerg/novell/faq

   Auch für die amerikanische Novell Mailing-Liste gibt es ein FAQ von
   Floyd Maxwell <floyd@direct.ca>;, das allerdings noch keine Novell DOS
   Themen enthält (offenbar ist diese Adresse nicht mehr gültig (02/1997)):

    URL: ftp://netlab2.usu.edu/misc/faq.txt
    URL: ftp://ftp.salford.ac.uk/network/misc/novell.faq

   Zu Caldera OpenDOS existieren ebenfalls verschiedene Mailing-Listen.
   Zunächst die offizielle Mailing-Liste von Caldera:

    URL: http://www.caldera.com/mailing-lists/index.html
                                          .../Caldera-OpenDOS-Info.html

   Man kann sich dort wie folgt anmelden:

    Mail-Adresse: Caldera-OpenDOS-Request@caldera.com
    Subject:
    Text: SUBSCRIBE

   Das Abmelden funktioniert wie folgt:

    Mail-Adresse: Caldera-OpenDOS-Request@caldera.com
    Subject:
    Body: UNSUBSCRIBE

   Die eigentliche Diskussion läuft in englischer Sprache auch hier über
   eine andere Adresse ab, nämlich:

    Mail-Adresse: Caldera-OpenDOS@caldera.com
    Subject: Thema...
    Body: ...

   Weiterhin gibt es noch drei 'inoffizielle' Mailing-Listen zum Thema,
   gewartet von DJ Delorie <dj@delorie.com>; (früher von Gene Buckle
   <geneb@wa.net>;). Die Anmeldung erfolgt wie folgt:

    Mail-Adresse: listserv@delorie.com
    Subject: OpenDOS mailing list
    Body: SUBSCRIBE opendos
    oder  SUBSCRIBE opendos-developer
    oder  SUBSCRIBE opendos-support

   Die Abmeldung geschieht analog. Die Diskussion selbst läuft über
   <opendos@delorie.com>;, <opendos-developer@delorie.com>;, bzw.
   <opendos-support@delorie.com>; ab. Die Zustellung ist auch in
   täglichen oder wöchentlichen Intervallen möglich, hierzu gibt
   es auch ein praktisches Anmeldungsformular:

    URL: http://www.delorie.com/opendos/archives/subscribe.html

   Eine offizielle OpenDOS FAQ wird von Caldera herausgegeben:

    URL: http://www.caldera.com/tech-ref/opendos/faq/faq.html

   Diverse inoffizielle FAQs wurden oben schon erwähnt.

   Außerdem sind die englischsprachigen Usenet-Newsgroups wie z.B.
   URL: news:comp.os.msdos.programmer, URL: news:comp.os.msdos.misc oder
   URL: news:comp.os.msdos.applics sicherlich gute Anlaufstellen für Frage-
   stellungen rund um jedes DOS, auch im Zusammenspiel mit Hardware, Windows
   und teilweise auch mit Netzen. Weitere Hinweise finden sich vereinzelt
   auch über die üblichen WWW-Suchdienste. Eigene Newsgroups für OpenDOS
   sind geplant.

                                                                             
  ---------------------------------------------------------------------------

  I.4. Novell DOS 7 - eine (persönliche) Kurzkritik - mit Grabrede:
  ====================================================[97-04-12]===

   Stichworte: Über den Autor, Konzept DOS, Grenzen, Alternativen, Zukunft,
               Philosophie

   Vorbemerkung: Durch die jüngsten, äußerst interessanten Entwicklungen
                 bezüglich der Zukunft von Novell DOS werden einige Passagen
                 dieses 'Stoßgebetes' im positiven Sinne etwas relativiert.
                 Durch die Ankündigungen von Caldera fühle ich mich in
                 meiner Meinung voll bestätigt. Eine gründliche Über-
                 arbeitung dieser 'einsamen Predigt' wird vorgenommen,
                 sobald die Wünsche wirklich erhört und Versprechen
                 eingelöst wurden...
                 Sollte die Grabrede verfrüht gewesen sein? ;-)    (09/1996)

   "Der Verfasser einer solch' gewaltigen Tips & Tricks Sammlung
   wird sich sicherlich etwas bei seiner Arbeit gedacht haben",

   werden Sie jetzt vermuten... ;-)

   Ganz recht. Aber trotzdem bin ich mit Novell in keiner Weise involviert,
   d.h. all dies ist aus rein persönlichem Interesse an einer möglichst
   leistungsfähigen DOS-Umgebung entstanden (quasi als entsprechend aufbe-
   reitetes 'Abfallprodukt' einer internen Dokumentation von Fragen und
   Antworten, die während meiner Arbeit mit dem System auftraten). Durch
   die Veröffentlichung möchte ich meine Erfahrungen mit Ihnen teilen und
   bin auch auf Ihr 'Input' gespannt. Damit Sie sich ein grobes Bild machen
   können, ein paar Anmerkungen...

   Als hardware-orientierter 'Power-User' (oder eher 'Systemprogrammierer')
   und Netzwerkbetreuer (im Nebenjob) habe ich im Laufe der Jahre mit so
   ziemlich allen MS-DOS, PC-DOS und DR DOS Versionen auf unterschiedlich-
   sten Rechnern Erfahrungen gesammelt. Ich zähle zu den Unverbesserlichen,
   die eine komfortable Kommandozeile und trickreiche Möglichkeiten weit
   mehr schätzen als eine graphische Oberfläche mit Maussteuerung, ganz
   einfach deshalb, weil ich die meisten Dinge damit viel präziser und
   schneller erledigen kann (zugegeben - nicht alles). Nicht, daß Sie mich
   mißverstehen: Graphische Oberflächen haben auch unbestrittene Vorteile,
   aber viele Bedienungsabläufe in den 'real existierenden' Oberflächen sind
   derart unergonomisch in der Handhabung, daß ich lieber ein paar (von mir
   aus auch kryptische, aber irgendwann doch geläufige) Befehle am Prompt
   tippe und der Computer dann meinen Anweisungen folgt, anstatt umgekehrt
   die permanente Entmündigung durch eine Oberfläche zu ertragen, die einem
   aufzwingt, auf die Fenster zu *reagieren*, statt im ursprünglichen Sinne
   zu *agieren*. Das Beste wäre ein ausgewogener Mittelweg: eine Fenster-
   oberfläche für graphische Anwendungen und Anfänger, ein leistungsstarker
   Prompt für Profis und vor allem: möglichst hohe Performance auch auf
   leistungsschwächeren Rechnern...


   Nun aber zurück zum Thema:

   Natürlich darf man nicht übersehen, daß das 'Konzept DOS' von seiner
   Basis her schon seit etlichen Jahren völlig ausgereizt scheint (z.B. die
   eigentlich irrwitzigen Mechanismen zur Minderung der akuten Speichernot
   unter DOS - für DOS-Benutzer eine 'perverse' Selbstverständlichkeit),
   genauso wie die zugrundeliegende Hardware-Architektur, die noch in der
   'Home-Computer-Ära' entstand und alle seine absurden Versuche, sie auf
   den heutigen Bedarf aufzubohren. Kompatibilität über alles!

   Es gibt heute wesentlich bessere Konzepte im Hard- und Software-Bereich,
   allerdings sind sie bisher gegenüber DOS/Windows basierten x86-PCs immer
   noch Nischenlösungen geblieben. Für die DOS-Kommandozeile und für viele
   der abertausend Programmlösungen gibt es bei Weitem noch keine Allround-
   Entsprechung in den neueren, auf den PC-Markt abzielenden Betriebs-
   systemen:

   - MS Windows 3.xx/ Bisher keine eigene Kommandozeile und damit fast
     MS Windows95     indiskutabel als Ersatz, höchstens als Ergänzung.
                      Dies hat sich mit MS Windows95, trotz mancher
                      Detailverbesserungen, bis auf den START-Befehl
                      eigentlich nicht geändert. Die DOS-Wurzeln wurden
                      zwar kaschiert (z.B. LOGO=1), sind aber nach wie
                      vor sehr deutlich erkennbar. MS Windows95 ist bei
                      Weitem noch kein vollständiges 32Bit-Betriebssystem.
                      Auch die Realisierung des Multitaskings ist nicht
                      State-of-the-Art, obwohl es mit MS Windows95 schon
                      etwas besser als bisher geworden ist.
                      Die DOS-Box selbst hat zwar gegenüber der von
                      MS Windows 3.xx zugelegt, andererseits ist das
                      integrierte MS-DOS 7 vom Leistungsumfang gegenüber
                      MS-DOS 6.22 reichlich beschnitten. Eine der wenigen
                      Innovationen ist die durch die Ausführung unter
                      MS Windows95 mögliche Verlagerung mancher besonders
                      speicherfressenden Treiber in den Protected Mode und
                      etwas verbesserte Hochlade-Möglichkeiten; alles Dinge,
                      die Benutzer von Novell DOS 7 schon lange kennen (und
                      dort auch ganz ohne den Zwang zu Windows realisiert
                      sehen). Außerdem häufig recht labil und - immer noch -
                      konzeptionell undurchsichtig.
   - IBM OS/2 Warp    Wie MS Windows95 recht hohe Hardware-Anforderungen,
                      aber dafür gut durchdachtes Konzept, sauberes pre-
                      emptives Multitasking und mittlerweile sehr stabil.
                      Neben OS/2-Applikationen können auch Windows 3.xx
                      Anwendungen problemlos auf demselben Desktop ausge-
                      führt werden (auch mit Win32s). Bietet eigene
                      Kommandozeile plus gute DOS-Emulation sowie die
                      Möglichkeit, gleichzeitig beliebige 'echte' DOS-
                      Versionen (auch Novell DOS) unter OS/2 zu booten.
                      Ist zwar multiplattformfähig, aber derzeit sind alle
                      außer der Intel-PC-Version auf Eis gelegt. Die brand-
                      neue Version 4 "Merlin" vollzieht die neusten Er-
                      weiterungen von MS Windows95 nun nicht mehr auf
                      Binärcodeebene nach und geht jetzt eigene Wege (vgl.
                      DAPIE alias Open32), leider mit ungewisser Zukunft.
   - MS Windows/NT    Hochentwickeltes und ernstzunehmendes, aber auch sehr
                      leistungshungriges Betriebssystem mit Zukunft (Die
                      Release-Version 4 ist allerdings ab einer sinnvollen
                      Speicherbestückung sogar schneller als MS Windows95).
                      Technologisch zwar durchdachter als die anderen
                      Windows-Versionen, aber in manchen Punkten (z.B. WPS)
                      immer noch hinter IBM OS/2 angesiedelt und leider
                      vergleichsweise schlechte DOS-Emulation. Wird zwar
                      für verschiedene Rechnerplattformen angeboten, aber
                      auch hier liegen einige Versionen auf Eis.
   - Linux            Offenes FreeWare-Unix-System, sehr interessant
                      und mittlerweile sehr ausgereift. Hat mit dem
                      Kernel 2.0 eigentlich alle Nachteile herkömmlicher
                      monolithischer Unix-Systeme in der Praxis überwunden
                      und die diesbezüglichen Vorurteile widerlegt.
                      Bietet eine recht fortgeschrittene PC-Emulation
                      (DOSEMU) für DOS, einen noch rudimentären Windows-
                      Emulator (WINE) und ist absolut multiplattformfähig
                      (die Urversion war allerdings nur für 386er und höher
                      geplant, die äußerst effektiv ausgereizt werden).
                      Multitasking-/Multiuser-Fähigkeiten und ein X-Window-
                      System sind für Unix inzwischen selbstverständlich.
                      Extrem flexible und umfangreiche Treiberunterstützung.
                      Durch hohes Engagement der weltweiten aktiven Ent-
                      wickler- und Benutzergemeinde kurze Antwortzeiten
                      bezüglich Erweiterungen, Fixes, etc.
                      Konzeptionelle Umgewöhnung ist notwendig, aber für
                      einen echten 'Massenmarkt' wohl noch etwas zu um-
                      ständlich in der Handhabung. In jüngster Zeit haben
                      sich aber auch hier einschneidende Fortschritte
                      für den Otto-Normal-Benutzer ergeben, auch gerade
                      durch den kommerziellen Linux-Abkömmling Caldera
                      OpenLinux bzw. dessen Vorläufer Caldera Network
                      Desktop der Caldera Inc., die in 07/1996 auch die
                      Rechte an DR DOS etc. von Novell übernommen haben.
                      Das geplante Caldera OpenLinux soll neben Suns Wabi
                      (einer weitentwickelten Windows-Emulation) über
                      DOSEMU auch OpenDOS, den Nachfolger von Novell DOS,
                      enthalten. Wird zunehmend zu einer ernsthaften
                      'Bedrohung' für andere etablierte Systeme werden -
                      mit Recht.

   DOS in seiner bisherigen Form ist schon lange 'tot' - aber es wird uns
   in der einen oder anderen Art und Weise noch etliche Jahre begleiten.

   Allgemein akzeptiert ist die Tatsache, daß die Entwicklung von MS-DOS -
   entgegen offiziellen Verlautbarungen - spätestens seit der Version 5 zu
   großen Teilen nur noch durch den Konkurrenzdruck durch DR DOS/Novell DOS
   fortgeschritten ist. Die meisten konzeptionellen Erweiterungen waren
   seitdem zuerst in DR DOS zu finden und wurden in leicht abgewandelter
   Form vom übermächtigen MS-DOS adaptiert.

   Hier ein äußerst grober zeitlicher Überblick:

     Datum:     Version:      Einführung verschiedener neuer Features:

     1984-1986  DOSPlus 1.2, 2.1x
     1987-1989  DR DOS 3.4x   ROMable; Festplatten > 32 MByte
                              (bis 512 MByte); GEM; INSTALL=; Paßwörter;
                              Ganzseiten-Editor EDITOR; OEM-Versionen;
                              DBCS-Support vorbereitet
     04/1988    MS-DOS 4.0x   Festplatten > 32 MByte (2 GByte, FAT16);
                              INSTALL=; DBCS-Support
     08/1990    DR DOS 5.0    Hochlademöglichkeiten (HIDOS=ON) inklusive
                              CDS; Kernel, einige Tools und ein Großteil
                              der DOS-Datenbereiche können sogar in die
                              HMA geladen werden; VIEWMAX; DBCS-Support;
                              Festplatten bis 2 GByte (FAT16); usw.
     03/1991                  Beginn der Arbeiten an DR DOS 'Buxton'
     06/1991    MS-DOS 5.0    ROMable; gegenüber DR DOS vergleichsweise
                              eingeschränkte Hochlademöglichkeiten
                              (DOS=HIGH etc.); begrenzte Nutzung der HMA;
                              Prozeßumschalter (nur in Verbindung mit
                              DOS-Shell); funktionsfähiges FAT16
     09/1991    DR DOS 6.0    Datenkompression (SUPERSTOR); NetWare Lite;
                              CONFIG.SYS SET= und andere Erweiterungen;
                              Boot-Menüs; Prozeßumschalter (TASKMAX),
                              *auch* in Kombination mit VIEWMAX; FILELINK;
                              usw.
     06/1992                  Beginn der Arbeiten an DR DOS 'Panther'
     10/1992    MS WfW 3.1    MS Windows for Workgroups 3.1
     03/1993    DR DOS 6.0    "Business Update" für Windows 3.1; u.a. echte
                              CDS
     04/1993    MS-DOS 6.0    Datenkompression (DBLSPACE); CONFIG.SYS SET=;
                              Boot-Menüs; INTERLINK
     Ende 1993  Novell DOS 7  US-Ausgabe; Personal NetWare; DPMS (DOS
                              Protected Mode Services) inklusive 32Bit-
                              Unterstützung, eigener DPMI-Server unter DOS;
                              preemptives Multitasking (TASKMGR+EMM386),
                              sogar bei gleichzeitigem Betrieb mehrerer
                              DOS-Extender-Applikationen; NWCACHE mit
                              adaptivem Cache; LASTDRIVE=32; fortge-
                              schrittene Datenkompression (STACKER), usw.
        1994    MS-DOS 6.2    Verbesserter SMARTDRV und sicherer DBLSPACE;
                              Wegfall vieler DOS-Utilities
     03/1994    Novell DOS 7  Deutsche Ausgabe des Betriebssystems
     03/1994    MS-DOS 6.21   ohne DBLSPACE
     1994-05-31 Update 4      Novell DOS 7 (Englisch)
     08/1994    MS-DOS 6.22   nun mit DRVSPACE
     12/1994    Update 10     Novell DOS 7
     01/1995    Update 11     Novell DOS 7
     04/1995    Update 12     Novell DOS 7
     05/1995    Update 13     Novell DOS 7
     08-09/1995 Update 14     Novell DOS 7
     10/1995    MS Windows95  MS-DOS 7; endlich Hochlademöglichkeiten von
                              CDS und ebenfalls Protected Mode DOS-Treiber,
                              allerdings nur unter Windows95; LASTDRIVE=32;
                              Long-Filenames; stark eingeschränkter Code-
                              page-Support; Wegfall aller Zukäufe und
                              vieler traditioneller DOS-Utilities
     12/1995    Update 15     erste Version des Update 15 zu Novell DOS 7
     01/1996    Update 15/2   letztes Update zu Novell DOS 7
     1996-07-23               Caldera übernimmt Novell DOS, DR PalmDOS,
                              DR DOS, DR Multiuser DOS, GEM und CP/M von
                              Novell.
     1996-09-10               Caldera kündigt OpenDOS an und will später
                              auch die Quelltexte veröffentlichen.
     1997-02-03  OpenDOS 7.01 Caldera gibt die englische Version
                              von Caldera OpenDOS 7.01 offiziell frei,
                              die allerdings noch fast identisch mit
                              Novell DOS 7 ist. Die Benutzung ist für
                              Ausbildungsstätten, Studenten, Schüler sowie
                              für Angehörige von caritativen oder religiösen
                              Einrichtungen kostenlos!
     1997-05-05  OpenDOS 7.01 Offizielle Ausgabe der Kernel-Quelltexte
                              (M.R.S.) (Stand der Quellen von 12/1994,
                              damit kurz vor dem Novell DOS 7 Update 11)

   Gerechterweise muß man auch sagen, daß es auch einige kleinere neue
   MS-DOS Features gibt, die Novell DOS leider nicht aufweist - wie die
   seit MS-DOS 6.22 und 7 bessere Multilingual-Unterstützung und einige
   gute Ansätze im Ergonomiebereich - aber da hatte Novell DOS schon länger
   die Nase vorn. Gut so. Konkurrenzdruck scheint das einzige Mittel zu
   sein, daß kommerzielle Anbieter sich nicht auf ihren Lorbeeren ausruhen.
   Daß es auch anders geht (nämlich mit Idealismus), zeigt das Linux-Projekt
   (und vielleicht bald das ebenfalls unter der "GNU General Public License"
   stehende FreeDOS, in Zukunft noch unterstützt durch Caldera OpenDOS,
   denn Caldera-Repräsentaten sehen in FreeDOS die größte 'noch lebende'
   Entwicklergemeinschaft für hochkarätige DOS-Betriebssystemtechnik und
   wollen von daher auch mit dem FreeDOS-Team zusammenarbeiten).
   Aus diesem Grund ist es auch äußerst wichtig, daß es auch zu Windows
   (und sei es noch so 'gut') eine starke Konkurrenz gibt. Dies erfordert
   meines Erachtens auch einen Bewußtseinswandel bei den zuständigen
   Entscheidungsträgern, nämlich nicht nur kurzsichtig den vermeintlichen
   'Standard' zu sehen, sondern auch aktiv die Konkurrenz von Monopolisten
   zu unterstützen, um damit zum Vorteil aller Entwickler und Anwender einen
   wirklichen, d.h. stabilen und dokumentierten Standard und eine Weiter-
   entwicklung zu sichern. Was glauben Sie, wäre aus MS-DOS geworden, hätte
   es Digital Research und DR DOS nie gegeben (abgesehen davon, daß MS-DOS
   1.xx sowieso ein in einigen interessanten Punkten erweiterter Clone von
   Digital Researchs CP/M war)? Oder: Können Sie (als Software-Entwickler,
   versteht sich) von sich behaupten, die Interna von MS Windows wirklich
   zu verstehen? (Falls ja: Wo haben Sie die Dokumentation her? Falls nein:
   Und warum nicht?)

   Dieses Problem wurde überdeutlich bei der Akzeptanz von DR DOS/
   Novell DOS. Jeder sprach davon; die Einführung von Novell DOS 7
   löste eine regelrechte Euphoriewelle aus: "Endlich eine echte
   Konkurrenz zum in den Dornröschen-Schlaf verfallenen MS-DOS, mit
   vielen zukunftsweisenden Ideen". Obwohl Novell DOS (im Gegensatz
   zu den Vorgängern zum ersten Mal) sogar auf recht breiter Basis
   in öffentlichen Einrichtungen und Instituten akzeptiert wurde (wohl
   auch wegen der NetWare-Anbindung) und ganz offensichtlich auf dem
   Wege war, MS-DOS in Zukunft starke Konkurrenz zu bieten, wurde die
   Weiterentwicklung schon recht bald nach diesem 'Aufbäumen' einge-
   stellt (Bugfixes, Updates und die Auslieferung wurden endgültig erst
   im Frühjahr 1996 nach immerhin 15 größeren Updates gestoppt). Dieses
   'Kippen' von NWDOS 7 geschah einerseits im Rahmen des schon ange-
   deuteten Managementwechsels bei Novell (der Novell-Mitbegründer
   Raymond J. Noorda verließ Novell, um sich in 10/1994 an der Gründung
   von Caldera zu beteiligen, sein Nachfolger Robert J. Frankenberg trat
   in 08/1996 nach etlichen Turbulenzen in Novells Kursstrategie als CEO
   und Präsident zurück und ist nun von Joseph Marengi als Präsident und
   von Eric Schmidt als CEO abgelöst), nach Insider-Infos aber auch in einer
   stillen Übereinkunft mit Microsoft, die sich im Gegenzug weitestgehend
   aus dem Netzwerkbereich heraushalten wollten (wobei sich jeder selbst
   seinen Teil dazu denken mag).

   Obwohl Novell DOS 7 bei Weitem noch nicht als das 'ideale' DOS gelten
   kann, ist es meiner persönlichen Meinung nach auf gutem Wege gewesen,
   die beste Alternative zu werden. Die Kompatibilität ist (im Vergleich
   zu DR DOS) nochmals stark verbessert worden, allerdings wurden
   zumindest in den ersten ausgelieferten Versionen noch nicht alle
   der neuen Systemaufrufe von MS-DOS unterstützt - aber selbst dies
   war für die überwiegende Mehrzahl der Programme völlig unkritisch.
   Viele der Novell DOS 7 angelasteten Fehler waren bereits beim Er-
   scheinen der deutschen Ausgabe (einige Monate nach der US-Ausgabe)
   korrigiert.
   Das Erscheinungsbild machte auf mich zunächst einen äußerst homogenen
   Eindruck, der erst im Laufe der Zeit etwas dadurch getrübt wurde,
   daß bei der Einbindung von Fremd-Utilities und in der - trotzdem sehr
   guten - Dokumentation wohl doch unter großem Zeitdruck kleinere
   Nachlässigkeiten (bezüglich der Konfigurationsdateien und des Benutzer-
   Interfaces) begangen wurden. Eine hypothetische Revision (etwa 7.1)
   hätte solche kosmetischen Feinheiten beseitigen und sehr leicht einige
   der neusten 'oberflächlichen' Erweiterungen von MS-DOS 6.22 (und 7)
   (verbesserte landessprachliche Unterstützung, neue Codeseiten, neue
   KEYB Möglichkeiten, Unterstützung für einige neue Druckertypen) der
   Vollständigkeit halber hinzufügen können (interne Korrekturen sind im
   Rahmen der Updates mittlerweile weit gediehen), aber diese Chance wurde
   von Novell nicht genutzt. Ansonsten steht NWDOS 7 in seiner internen
   Realisierung meiner Meinung nach auf wesentlich sicheren Füßen als
   MS-DOS (auch außerhalb der Bereiche Multitasking und NetWare), wie
   kleine Details (zum Beispiel in dieser Datei) immer wieder zeigen.
   Gleichzeitig ergibt es sich durch (sinnvolle) Abweichungen zwangsläufig,
   daß nicht jedes noch so unwichtige Detail zu 100% nachgebildet wurde.

   Es gab in den ersten Ausgaben wohl teilweise Probleme mit einigen ernst-
   haften Bugs und Inkompatibilitäten, sowie einige Performance-Probleme mit
   seriellen Schnittstellen, dem Floppy- und CD-ROM-Zugriff und damit, daß
   manche wirklich extrem unsauberen Applikationen (wie etwa manche Spiele)
   als ungerechter Kompatibilitätstest herhalten mußten. Eigentlich sind
   diese Applikationen im Sinne von DOS-Standards nicht 'bug-frei' - und daß
   sie unter MS-DOS laufen, liegt eigentlich mehr an der jeweiligen Test-
   plattform der Entwickler (eben MS-DOS), als an Fehlern in Novell DOS.
   Zumindest potentiell steht solchen Programmen jedenfalls nichts im Wege,
   um unter Novell DOS 7 ausgeführt zu werden. Jedenfalls bildet Novell DOS
   auch die undokumentierten Systemstrukturen des Kernels von MS-DOS zu
   95% und die API-Funktionen der Version 6 zu vielleicht 90% nach (je nach
   Standpunkt und Sichtweise etwas mehr oder gar mehr) und unterscheidet
   sich vom Original nur minimal in der Handhabung dieser Strukturen und
   Routinen (meist durch sinnvolle Erweiterungen). Diese Abweichungen sind
   nicht wesentlich größer als sie auch zwischen den einzelnen MS-DOS
   Versionen selbst existieren (als Extrembeispiele seien MS-DOS 4 und
   MS-DOS 7 genannt), daher liegen Kompatibilitätsprobleme daran, daß manche
   Entwickler einfach unzulässige Annahmen bezüglich des Systems machen und
   ihre Software nur unter einer DOS-Version testen. Gleiches galt für die
   Probleme mit frühen Versionen des DPMI-Supports, ganz einfach deshalb,
   weil die DPMI-Spezifikation 0.9 hier vieles offen läßt und Novell es
   eben anders realisiert hatte als Microsoft). Auch zum gegenwärtigen
   Zeitpunkt gibt es noch vereinzelte Ungereimtheiten.
   Aber: Wieso fragt eigentlich niemand, warum MS-DOS keine der vielen
   zusätzlichen Systemaufrufe von DR DOS/Novell DOS unterstützt?

   Meiner Meinung nach liegt vieles auch an der oben beschriebenen Ignoranz
   der restlichen Software-Industrie gegenüber der internen Realisierung
   der Sonderfunktionen von DR DOS/Novell DOS, wie etwa Paßwörter (manche
   Utilities meckern selbst in aktuellen Versionen immer noch angebliche
   Fehler in der Festplattenstruktur an, akzeptieren keine mit Semikolon
   eingeleiteten Paßwörter in ihren Dateieingabemasken oder begrenzen Pfade
   auf maximal 67 Zeichen (wie unter MS-DOS von jeher und nun mit der
   Einführung der MS-DOS-typischen CDS auch bei Novell DOS 7) - eigentlich
   sehr peinlich für deren Hersteller und nicht für Novell, schließlich
   existieren Paßwörter und überlange Pfade spätestens ab DR DOS 3.40 von
   1987), die Löschverfolgung (dto.), das Multitasking (Probleme mit
   alternativen Kommandoprozessoren); alles Dinge, die eigentlich relativ
   einfach in den Griff zu bekommen wären, wenn nur der entsprechende Wille
   dahinter stünde (mit der entsprechenden Erfahrung möchte ich sogar
   behaupten, daß der dazu notwendige Aufwand sogar leicht von einigen
   enthusiastischen Hobbyprogrammierern erbracht werden könnte - in
   Ermangelung der Quelltexte bis zur Übernahme von DR DOS durch Caldera
   aber leider unmöglich...)

   Es stünden noch eine Reihe von Verbesserungen auf dem Wunschzettel des
   Power-Users und DOS-Fans. Im Rahmen des Multitaskings und Speicher-
   managements, als auch der Kommandozeilenflexibilität lassen sich gerade
   durch die bisherigen Erweiterungen noch viele andere Dinge erahnen,
   wenn bereits angedachte Konzepte konsequent über das ganze System
   durchgezogen würden. Manchmal habe ich den Eindruck, daß gerade die
   Umgehung der Mängel auf kuriosem Weg - unter DOS Gang und Gebe - trotz
   Beschränkung der zugrundeliegenden Mittel und Möglichkeiten den DOS-
   Benutzer zum echten 'Fan' machen kann...
   Die Einlösung in irgendeinem anderen DOS ist wohl kaum noch zu erwarten,
   außer vielleicht im derzeit noch sehr rudimentären, aber schnell heran-
   wachsenden FreeDOS (dort wird auch immer wieder über einen multitaskenden
   Protected Mode DOS 32Bit-Kernel nachgedacht, der die einzelnen Treiber
   und Programme in virtuellen Maschinen laufen lassen könnte - auch wenn
   das definitiv nicht das erklärte Ziel der ersten User-Release ist), denn
   ohne Konkurrenz wird sich wohl auch MS-DOS nur noch auf die Version 7 als
   Kompatibilitätsbox unter MS Windows95 gerettet haben. Schade.

   Meiner Meinung nach ist auch heute noch trotz der massiven Verbreitung
   der Betriebssysteme mit graphischen Oberflächen der Markt für DOS da
   und es besteht ein echtes Bedürfnis nach einer gründlich in allen Be-
   langen überarbeiteten 'Version 8', die vor allem in Richtung Flexibi-
   lität des Benutzer-Interfaces aufgewertet werden müßte: Erweiterte
   Kommandozeile á la 4DOS und mit REXX-Support (und sei es auch als
   Ergänzung einer graphischen Benutzeroberfläche), mehr Detail-Featurismus
   der Betriebssystem-Utilities, weiter verbesserte Landesunterstützung
   (Qualität und Quantität), neue Netzwerkfunktionen besonders in Verbindung
   mit 'Plug-In' Datei-Systemen (HPFS, NTFS, VFAT, FAT32, etwas wie 'UNC'
   zum Navigieren im Internet und in lokalen Archiven), erweiterter
   Hardware-Support (z.B. hohe Textmodi auch mit Codeseitenumschaltung,
   Unterstützung für neuere Drucker)...
   Es gibt einfach Milliarden PC-kompatibler Rechner in aller Welt, davon
   ein Großteil nicht leistungsfähig genug, um die neuen Ressourcenfresser
   zufriedenzustellen, aber prinzipiell leistungsfähig genug, um damit die
   täglichen Aufgaben zu erledigen. Ein Teil davon wird nur deshalb nicht
   mehr benutzt, weil mittlerweile passend aktualisierte Betriebssysteme
   und Anwendungen fehlen, aber nach aktuellen Umfragen sind auch heute
   noch (1997) 'zig Millionen 'alter' Rechner im harten Einsatz. Dies
   gilt erst recht für die Länder abseits unserer schnellebigen Industrie-
   nationen.

   Dies bestätigt auch die starke Nachfrage nach Calderas OpenDOS 7.01,
   wo alleine in den ersten drei Tagen nach der Freigabe angeblich
   19.000 Downloads verzeichnet wurden, und dies, obwohl es in der
   Anfangszeit noch arge Probleme gab, da Calderas Internet-Server unter
   der Last fast zusammengebrochen wäre.

   Das DOS irgendwann einmal nicht mehr weiterentwickelt werden würde, ist
   absolut einsichtlich. Für meine Begriffe ist Novells Entscheidung zum
   Kippen des noch bis in die CP/M-Zeit (1976) traditionell verankerten
   NWDOS 7 aber wenigstens eine komplette Major-Release zu früh gekommen.
   Vermutlich stehe ich mit dieser Ansicht unter den überzeugten NWDOS 7
   Benutzern nicht alleine da...

   [Und nun lesen Sie ruhig in Kapitel I.5. und IX.11. weiter... ;-) ]

                                                                             
  ---------------------------------------------------------------------------

  I.5. Caldera OpenDOS 7.01 - Erste Erfahrungen: [97-02-14]
  =========================================================

   Stichworte: Caldera OpenDOS, Update von Novell DOS 7, NWCACHE, PNUNPACK,
               NETWARS, NWDRAW, MLID-Treiber, Versionsnummernpolitik

   An dieser Stelle möchte ich - ganz kurz - erste Erfahrungen mit
   dem neuen Caldera OpenDOS 7.01 wiedergeben. Diese Version ist mit
   Novell DOS 7 praktisch identisch, so daß Sie nahezu alle Fakten aus
   diesem Dokument auch auf dieses System anwenden können!

   Dabei wurden in Caldera OpenDOS 7.01 bereits die Änderungen einiger
   Novell DOS 7 Updates eingearbeitet. Caldera OpenDOS 7.01 ist derzeit
   irgendwo auf dem Niveau vor Update 11 (von Januar 1995), d.h. die
   teilweise durchaus signifikanten Änderungen und Erweiterungen, die
   bis zum Novell DOS 7 Update 15/2 (Januar 1996) 'unter's Volk gebracht'
   wurden, sind in Caldera OpenDOS 7.01 leider noch nicht enthalten
   (siehe Kapitel I.3.)!

   Wenn Sie ein gut gewartetes Novell DOS 7 System haben, gibt es also
   derzeit keinen Grund zum Wechsel auf Caldera OpenDOS, was sich aber
   spätestens dann ändert, wenn Caldera die restlichen Patches übernommen
   hat und - wie angekündigt - damit beginnt, neue Funktionen in Caldera
   OpenDOS einzubauen.

   Caldera OpenDOS 7.01 entspricht vom Lieferumfang dem englischen
   Novell DOS 7 System inklusive Novells Personal NetWare 1.0 (wobei
   hier bezüglich der Updates ähnliches gilt), mit STACKER und all den
   anderen praktischen Tools, allerdings ohne Search & Destroy von Fifth
   Generation und Fast-Backup von Fifth Generation/Symantec. Ansonsten
   liegen neue Fassungen von NWCACHE (siehe unten!) und PNUNPACK, sowie
   eine stark erweiterte Fassung von NETWARS und ein Konstruktions-Tool
   für eigene Raumschiffe bei.
   Die MLID-Treiber der mitgelieferten Personal NetWare überschneiden sich
   erstaunlich wenig mit den Treibern aus aktuellen Novell-Updates (z.B.
   VLM121_?.EXE), die allerdings durch die Bank weg sehr viel aktueller
   sind. Falls Sie auf der Suche nach einem exotischen MLID-Treiber sind,
   sollten Sie also in jedem Fall das jeweils andere Paket durchforsten.

   Äußere Änderungen bestehen lediglich aus Feinheiten wie geänderten
   Namen ("Caldera OpenDOS" statt "Novell DOS"), neuen Variablen (etwa
   %OPENDOSCFG% statt %NWDOSCFG%), geänderten Dateien (wie OPENDOS.INI
   statt NWDOS.INI oder OPENDOS.386 statt NWDOS.386) und einem anderen
   Installationsverzeichnis (C:\OPENDOS\ statt C:\NWDOS\).

   Die VER-Ausgabe und die COMMAND.COM Startmeldung melden

    "Caldera OpenDOS 7.01"

   wobei das ".01" hier lediglich hinten angehängt wurde (siehe bei VER
   in Kapitel II.11.).

   Vom API-Level unterscheidet sich diese erste OpenDOS-Version nicht
   von Novell DOS 7, d.h. sie enthält nach wie vor den CP/M-BDOS-Kernel
   114 (72h) und entspricht der DOS-API-Ebene 6.0.

   Für Benutzer anderer DOS-Betriebssysteme lohnt sich der Umstieg auf
   Caldera OpenDOS 7.01 mit Sicherheit, da auch die Novell DOS 7 Updates
   unter Caldera OpenDOS 7.01 laufen, wenn man zusätzlich Variablen
   wie %NWDOSCFG% einrichtet und Dateien wie NWDOS.INI bereitstellt.

   Daher empfehle ich derzeit allen Umsteigern nach der Installation von
   Caldera OpenDOS 7.01 das Novell DOS 7 Update 15/2 D70U15.EXE oder
   D70G15.EXE (beide von Januar 1996), sowie das Personal NetWare Update 5
   P10U05.EXE (bei der deutschen Version P10G05.EXE in jedem Fall über
   das englische Update 5 P10U05.EXE installieren!) plus VLM121_1.EXE
   bis VLM121_6.EXE einzusetzen. Diese Archive können Sie auf Novells
   Servern kostenlos beziehen, sofern Sie über eine Novell DOS 7 oder
   Personal NetWare 1.0 Lizenz verfügen (siehe Kapitel I.2.). Nach dem
   Einrichten der oben erwähnten Variablen und Konfigurationsdateien, die
   einige der Novell DOS 7 Programme aus den Updates referenzieren,
   funktionieren diese Updates problemlos. Allerdings sollten Sie
   nicht die COMMAND.COM Versionen beider Betriebssysteme im laufenden
   Betrieb wechseln (etwa mit EXIT), dies kann zum Absturz führen.

   Benutzer von Novell DOS 7, die vorerst noch nicht umsteigen wollen,
   können natürlich auch Calderas neue Versionen von NWCACHE (siehe
   unten!), PNUNPACK und NETWARS unter Novell DOS nutzen.

   Die Zukunft von DOS liegt so oder so mit Sicherheit bei Caldera OpenDOS!

   Es folgt eine Übersicht über den Stand der Versionsnummern vom
   englischen Caldera OpenDOS 7.01 (vom 97-02-03) mit einem optimal ge-
   warteten deutschen Novell DOS 7 System mit Update 15/2 (Januar 1996).
   Ein '+' gibt an, welche Datei aktueller ist (sofern man davon ausgehen
   kann, daß die Versionsnummern inklusive aller Seitenlinien bezüglich
   der Novell DOS 7 Patches nachgehalten wurden, was aber offenbar zumindest
   für NWCACHE nicht gilt). Interessant ist, daß derzeit nur NETWARS und
   evtl. auch PNUNPACK bei Caldera OpenDOS 7.01 in funktional neueren
   Versionen als noch bei Novell DOS 7 Update 15/2 vorliegen, aber sehr
   viele Programme aus den älteren Novell DOS Updates den Caldera OpenDOS
   Programmen noch um einige Unterversionsnummern voraus sind. Zu NWCACHE
   ist anzumerken, daß die Version von Caldera OpenDOS 7.01 zwar die höhere
   Versionsnummer 1.02 trägt, aber immer noch den kleinen Fehler in der
   Statistikausgabe enthält, der bei Novell DOS mit dem Update auf Version
   1.01 beseitigt wurde. Andere 'Verbesserungen' konnte ich derzeit noch
   nicht ausmachen: NWCACHE 1.02 kann nach wie vor keine CD-ROMs cachen
   (siehe Kapitel II.4.).
   Hier scheint sich also ein Wildwuchs der Versionsnummern anzubahnen,
   dem hoffentlich noch vor der nächsten Release von Caldera OpenDOS
   Einhalt geboten wird. Sonst wäre das Chaos vorprogrammiert...

   Tabelle:

    Programm:            Novell DOS 7:  Caldera OpenDOS 7.01:
                         (Update 15/2)

     APPEND.EXE               1.00          1.00
     ASSIGN.COM               1.05 +        1.04
     ATTRIB.EXE               1.44          1.44
     BACKUP.COM               1.09          1.09
     CHKDSK.EXE               1.21 +        1.2
     CHOICE.COM               1.00          1.00
     COMP.COM                 1.07          1.07
     CREATE.COM               3.10          3.10
     CURSOR.EXE               1.01          1.01
     DEBUG.EXE                1.42 +        1.40
     DELPURGE.EXE             1.02 +        1.00
     DELWATCH.EXE             2.1           2.1
     DISKCOMP.COM             2.04 +        2.03
     DISKCOPY.COM             2.04 +        2.03
     DISKMAP.EXE              1.00          1.00
     DISKOPT.EXE              2.00          2.00
     DOSBOOK.EXE              2.00          2.00
     DOSKEY.EXE               0.01          0.01
     DPMI.EXE                 1.00          1.00
     DPMS.EXE                 1.43 +        1.3
     DRIVER.SYS               2.00          2.00
     EDIT.COM                 2.01 +        2.00
     EMM386.EXE               3.10/3.1 +    3.06
     EMMXMA.SYS               1.3           1.3
     EXE2BIN.EXE              1.01 +        1.00
     FASTOPEN.COM             1.00          1.00
     FC.COM                   1.03          1.03
     FDISK.COM                1.76 +        1.75
     FILELINK.EXE             3.01 +        3.00
     FIND.EXE                 1.47          1.47
     FORMAT.COM               2.06 +        2.05
     GRAFTABL.COM             1.01          1.01
     GRAPHICS.COM             1.01          1.01
     HIMEM.SYS                2.32 +        2.3
     JOIN.EXE                 1.00          1.00
     KEYB.COM                 2.12 +        2.09
     LABEL.COM                1.34          1.34
     LOCK.EXE                 2.01          2.01
     MEM.EXE                  1.11 +        1.08
     MEMMAX.COM               2.01 +        2.0
     MODE.COM                 1.27          1.27
     MORE.COM                 --            --
     MOVE.EXE                 1.03          1.03
     NETWARS.EXE              2.06          2.0  + (wohl eher 3.0!!!)
     NLSFUNC.EXE              3.03 +        3.02
     NWCACHE.EXE (1.01.1)     1.01 +        1.02 + ??? (siehe oben!!!)
     NWCDEX.EXE               2.81 +        2.50
     PASSWORD.EXE             2.00          2.00
     PNUNPACK.EXE             2.00          3.00 +
     PRINT.COM                1.21          1.21
     RECOVER.COM              1.02          1.02
     RENDIR.EXE               1.00          1.00
     REPLACE.EXE              1.47          1.47
     RESTORE.COM              2.02          2.02
     SCRIPT.EXE               1.04          1.04
     SECURITY.OVL/NWLOGIN.EXE 1.02          1.02
     SERNO.EXE                0.01          0.01
     SETFIFO.EXE              1.00 +        --
     SETVER.EXE               1.00          1.00
     SHARE.EXE                2.04 +        2.02
     SORT.EXE                 1.36          1.36
     SUBST.EXE                1.03 +        1.02
     SYS.COM                  1.37 +        1.36
     TASKMGR.EXE              2.02          2.02
     TOUCH.EXE                1.44          1.44
     TREE.COM                 1.61          1.61
     UNDELETE.EXE             2.01 +        2.00
     UNFORMAT.COM             1.01          1.01
     UNINSTAL.EXE             2.00          2.00
     XCOPY.EXE                1.52          1.52
     XDEL.EXE                 1.46          1.46
     XDIR.EXE                 2.06          2.06

     SERVER.EXE               1.23 +        1.20

                                                                             
  ###########################################################################
  ###########################################################################

  II. ALLGEMEINES:
  ================

  ---------------------------------------------------------------------------

  II.1. SwitChar-Support: [97-03-25]
  ==================================

   Stichworte: SwitChar, SWITCHAR=, Interrupts, PROMPT, Unix, AMIS, 4DOS

   i. SwitChar - Was ist denn das?
   -------------------------------

   Normalerweise müssen Parameter unter DOS mit '/' eingeleitet werden,
   viele Programme erlauben jedoch zusätzlich noch '-' (oder '+', '\').
   Unter Unix werden Parameter normalerweise mit '-' eingeleitet, Pfadnamen
   enthalten dagegen '/' statt des unter DOS üblichen '\'.
   Manche Programme weisen diese Parametereinleitungszeichen jedoch zurück
   und verwenden entweder festverdrahtet '/' oder - besser - eine interne
   Systemvariable namens SwitChar, die normalerweise ebenfalls '/' angibt.
   Über diese Funktion ist es möglich, das Parametereinleitungszeichen zu
   ändern und den individuellen Vorlieben oder der Aufruf-Syntax der
   Applikation anzupassen.

   Im Gegensatz zu den heutigen MS-DOS-Versionen unterstützt Novell DOS 7
   (wie auch FreeDOS, OS/2, DR DOS 3.41-6.0, Caldera OpenDOS 7.01, PTS/DOS,
   S/DOS und MS-DOS 2.00-4.xx) nach wie vor die sog. SwitChar-Funktion
   (INT21h/AX=3700h). Bei MS-DOS 2.00 gab es einmal (und bei PTS/DOS alias
   S/DOS gibt es noch) eine zugehörige CONFIG.SYS Direktive SWITCHAR=.
   CCI Multiuser DOS 7.22 Gold unterstützt die SwitChar-Funktion nicht.
   (Mit einem Ubdate zu OpenDOS 7.01 wird die SWITCHAR= Direktive wieder
   eingeführt werden.)

   Über ein kleines Utility, das die Einstellung von SwitChar ändert, kann
   das System auf eine andere Behandlungsweise umgeschaltet werden (typisch
   für solche Utilities ist z.B. das beiliegende SWITCHAR.COM).

   Auch bei MS-DOS 5.00+ kann man die SwitChar-Funktionalität wieder nach-
   rüsten, indem man ein spezielles TSR (ebenfalls namens SWITCHAR) von
   Ralf Brown <ralf@pobox.com>; (aus dem Demopaket zu seiner AMIS-
   Spezifikation, z.B. URL: http://www.pobox.com/~ralf/files.html) lädt.

   Die aktuelle Einstellung kann man z.B. bei 4DOS mit SETDOS oder bei
   Novell DOS 7 COMMAND.COM (und DR DOS 5.0/6.0 COMMAND.COM, nicht aber
   bei DR DOS 3.41) über einen Trick mit CD abfragen und mit der ermittelten
   Einstellung zur weiteren Verwendung eine Umgebungsvariable belegen
   (siehe auch MEM.BAT):

    SWC.BAT (siehe auch die beiliegende Datei, die evtl. aktueller ist):

     @ ECHO off > \dev\nul
       REM -----------------------------------------------------------------
       REM SWC.BAT  v2.07  Copyright (C) 1995-1997 by Matthias Paul
       REM Evaluates current SwitChar setting from system or %switchar%
       REM environment variable, using, if available, special features of
       REM DR DOS 6.0, Novell DOS 7, and Caldera OpenDOS COMMAND.COM and/or
       REM 4DOS/NDOS, if available. Returns result in environment variable
       REM %switch%. Should run on any DOS 3.3+. If SWC.BAT cannot determine
       REM the current SwitChar, it returns default SwitChar '/'.
       REM Last edit: 1997-04-11 -mp [Matthias.Paul@post.rwth-aachen.de]
       REM -----------------------------------------------------------------
       FOR %%x IN (swc.btm SWC.BTM) DO IF "%%x"=="%0" GOTO rename
       GOTO start
       :rename
       ECHO Warning: "SWC.BAT" must not be renamed to "%0"! Exiting...
       GOTO end
       :start
       IF ""=="%tmp%" SET tmp=%Temp%> \dev\nul
       IF NOT ""=="%tmp%" IF NOT EXIST %tmp%\nul MD %tmp% > \dev\nul
       BREAK on > \dev\nul
       IF EXIST %tmp%\swc.btm ECHO Warning: "%tmp%\swc.btm" is locked ...
                                 ... by another task. Waiting for release...
       :wait
       IF EXIST %tmp%\swc.btm GOTO wait
       BREAK off > \dev\nul
       IF NOT "4"=="%@Eval[2 + 2]%" GOTO no4dos
       ECHOS `SET `> %tmp%\swc.btm
       SETDOS | @ CALL FIND "SWITCH=" >> %tmp%\swc.btm
     @ CALL %tmp%\swc.btm > \dev\nul
       DEL %tmp%\swc.btm > \dev\nul
       FOR %%x IN (on ON On off OFF Off) DO IF "%%x"=="%batdbg%" ...
                                               ... BREAK %batdbg% > \dev\nul
       GOTO end
       :no4dos
       REM Check for undocumented feature of Caldera OpenDOS 7.01,
       REM Novell DOS 7, DR DOS 6.0 COMMAND.COM: If current SwitChar
       REM is not '/', the 1st '\' from CD/CHDIR and PROMPT $p path
       REM output is replaced by '/'. Since DR DOS 6.0 COMMAND.COM prior
       REM to updates 1992 did copy files with zero length, this should
       REM not be enabled for original DR DOS 6.0 COMMAND.COM of 1991.
       REM IF "DRDOS"=="%Os%" IF "6.0"=="%Ver%" GOTO drdos6
       IF NOT "NWDOS"=="%Os%" IF NOT "OPENDOS"=="%Os%" GOTO end
       :drdos6
       CD | CALL FIND "/" > %tmp%\swc.btm
       IF NOT EXIST %tmp%\swc.btm GOTO end
       BREAK on > \dev\nul
       IF EXIST %tmp%\swc.$$$ ECHO Warning: "%tmp%\swc.$$$" is locked ...
                                 ... by another task. Waiting for release...
       :wait2
       IF EXIST %tmp%\swc.$$$ GOTO wait2
       BREAK off > \dev\nul
       IF EXIST %tmp%\swc.btm COPY %tmp%\swc.btm %tmp%\swc.$$$ > \dev\nul
       IF EXIST %tmp%\swc.btm DEL %tmp%\swc.btm > \dev\nul
       IF EXIST %tmp%\swc.$$$ IF ""=="%switchar%" SET switch=-> \dev\nul
       IF NOT EXIST %tmp%\swc.$$$ SET switch=> \dev\nul
       IF EXIST %tmp%\swc.$$$ DEL %tmp%\swc.$$$ > \dev\nul
       :end
       IF ""=="%switch%" SET switch=%switchar%> \dev\nul
       IF ""=="%switch%" SET switch=/> \dev\nul
       REM To avoid a parsing bug in an older MS-DOS COMMAND.COM release
       REM

   Sobald ein anderes Zeichen als '/' eingestellt ist (üblicherweise ein
   '-', möglich ist aber jedes beliebige Zeichen), signalisiert der PROMPT
   von Novell DOS 7 und DR DOS 5.0 & 6.0 COMMAND.COM (nicht aber DR DOS
   3.41) dies durch einen veränderten Schrägstrich in seinem $p Token,
   statt dem üblichen

    c:\nwdos>

   für ein PROMPT $p$g nun also

    c:/nwdos>

   (d.h. das erste Zeichen nach der Laufwerksangabe ist '/'). Die gleiche
   Veränderung zeigt sich auch bei Ausgaben des Befehls CD/CHDIR (z.B. wenn
   man CD ohne Parameter aufruft) und kann hier sogar sinnvoll für eine
   automatische Erkennung in Batchjobs (wie oben) verwendet werden, da sich
   die Ausgabe von CD umleiten und mit FIND auswerten läßt.

   Einen verdrehten Schrägstrich kann der Benutzer also als visuelle
   Erinnerung interpretieren, daß Novell DOS COMMAND.COM nun neben '\' in
   Pfadangaben auch '/' zuläßt. Möglich wird dies dadurch, daß '/' nun
   eben nicht mehr als Parametereinleitungszeichen verwendet wird. (Auf
   API-Ebene ist diese Unterscheidung nicht notwendig. Pfade können von
   jeher sowohl mit '/' als auch mit '\' angegeben werden).
   Gleichzeitig müssen aber alle Parameter mit dem nun eingestellten
   Parametereinleitungszeichen beginnen. Falls also SwitChar auf '-'
   eingestellt ist, müssen alle Parameter mit '-', statt mit '/' anfangen.

   Soweit bisher getestet, unterstützen nahezu alle externen Novell DOS 7
   Programme (zumindest die wichtigen und häufig verwendeten, bis auf
   EXE2BIN und MEMMAX, und ab Update 15 auch alle COMMAND.COM-internen
   Kommandos) diese Umschaltung und ändern bis auf wenige Ausnahmen
   (eben z.B. die internen Befehle) sogar die entsprechende Ausgaben
   der Hilfeschirme (die bei SwitChar=- natürlich mit -? aufgerufen
   werden. ;-)
   Problematisch ist es nur, wenn der SwitChar zwar unterstützt wird,
   aber ein bestimmter Parameter dadurch mehrdeutig wird (etwa XDIR,
   XCOPY mit dem -H Parameter, der versteckte Dateien ausschließen soll,
   in Verbindung mit SwitChar=- aber mit -H für Hilfe kollidiert).
   In solchen Fällen müssen Sie entweder genau darauf achten, wo der
   Parameter steht (ein Hilfeparameter sollte an erster Position stehen,
   andere Parameter hinten), oder man muß auf SwitChar=/ zurückschalten.
   Siehe die Befehlsübersicht weiter unten. (Bei DR DOS honorieren die
   meisten externen Utilities ebenfalls SwitChar, jedoch COMMAND.COM
   offenbar nicht.)

   Anscheinend wurde die Möglichkeit des variablen SwitChar ausgerechnet
   bei COMMAND.COM selbst 'vergessen'. In der Aufruf-Syntax von COMMAND.COM
   wurde der SwitChar-Support integriert, aber die Hilfeschirme aller
   internen Befehle von COMMAND.COM müssen weiterhin mit /? aufgerufen
   werden, auch wenn der SwitChar verstellt ist (getestet mit Update 15).
   Andererseits würde es auch neue (lösbare) Probleme aufwerfen, wenn auch
   die Hilfeschirme SwitChar-abhängig wären.

   Diese undokumentierte Möglichkeit kann für manche Belange (insbesondere
   für an die Unix-Konventionen Gewöhnte) praktisch sein, da aber nicht alle
   Fremdprogramme diese Möglichkeit unterstützen, ist der Nutzen begrenzt.

   Aufruf an alle Programmierer:

   Bitte unterstützen Sie in Ihren Programmen die SwitChar-Funktion, indem
   Sie den entsprechenden Interrupt nach der aktuellen Einstellung abfragen,
   oder wenigstens die gängigsten Alternativen ('/' und '-') unterstützen.


   ii. Übersicht über unterschiedliche SwitChar-Unterstützung:
   -----------------------------------------------------------

   Da die einzelnen Novell DOS Kommandos leider höchst unterschiedlich
   auf einen veränderten SwitChar reagieren, hier eine Übersicht...

   Symptome:

    -  (1) Akzeptiert 'festverdrahtet' nur '/' als Parametereinleitung
    +  (2) Akzeptiert immer '-' und '/' als Parametereinleitung
    +  (3) Paßt sich exakt an den aktuellen SwitChar an
    ++ (4) Paßt sich an einen SwitChar an, akzeptiert aber immer auch
           noch '-' und '/' (Abweichungen möglich, z.B. beliebige Zeichen,
           oder auch gar kein SwitChar)
    -  (5) Hilfeschirm nur mit /? (andernfalls siehe oben)
    -  (6) Hilfeschirm zeigt immer '/' an (Schönheitsfehler, unkritisch)
    +  (7) Hilfeschirm paßt sich teilweise an aktuellen SwitChar an
    ++ (8) Hilfeschirm paßt sich komplett an den aktuellen SwitChar an
    +  (9) Konfliktfreie Doppeldeutigkeiten bei gleichnamigen SwitChars
           wie '-' und '+'
    - (10) Unlösbare Doppeldeutigkeiten bei gleichnamigen SwitChars wie
           '-' und '+'

   Tabelle für Aufruf-Syntax (Novell DOS 7 Kommandos, unvollständig):

    Kommandos:          Compiler:    SwitChar-Verhalten:
                                     vor Update 15   Update 15

    COMMAND.COM Aufruf  (ASM???)                     +3 -6
    COMMAND.COM interne Kommandos    -1 -5 -6        +3 -5 -6
    4DOS.COM    zum Vergleich (Helpverhalten unterschiedl.) +3 -6 -10

    APPEND.EXE          (ASM)                        -1 -5 -6 -10
    ASSIGN.COM          (BC++91)                     +3 ++8
    ATTRIB.EXE          (BC++91)                     +3 ++8 -10
    BACKUP.COM          (BC++91)                     +3 -6
    CHKDSK.EXE          (BC++91)                     +3 -6
    CHOICE.COM          (BC++91)                     +3 -6
    COMP.COM            (BC++91)                     +3 +7
    CREATE.COM                                       -1 -5 -6
    CURSOR.EXE          (BC++91)                     -1 -5 -6
    DCONVERT.COM, DCONVRT2.EXE                       +2 ++4 (alles) ??
    DEBUG.EXE           (ASM)                        +2 ++4 (alles) ??
    DELPURGE.EXE                                     +2 ++4 (alles) +9
    DELWATCH.EXE                                     -1 -5 -6
    DISKCOMP.COM                                     +3 -6
    DISKCOPY.COM                                     +3 -6
    DISKMAP.EXE                                      +2 -6
    DISKOPT.EXE                                      +3 -6
    DOSBOOK.EXE                                      +3 ++8
    DOSKEY.EXE                                       +3 ++8
    DPMI.EXE                                         -1 ++8
    DPMS.EXE                                         +2 -6
    EDIT.COM                                         +2 +7
    EMM386.EXE                                       +2 ++4 (alles)
    EXE2BIN.EXE                                      -1 -5 -6
    FBX.EXE                                          +2 ++4 -6
    FC.COM                                           +3 ++8
    FDISK.COM                                        +3 -6
    FILELINK.EXE                                     +3 ++8
    FIND.EXE            (BC++91)                     +3 ++8
    FORMAT.COM          (BC++91)                     +3 +7
    GRAFTABL.COM                                     -1 -5 -6
    GRAPHICS.COM                                     -1 -5 -6
    JOIN.EXE                                         +2 ++4 (alles) -6
    KEYB.COM                                         -1 -5 -6
    LABEL.COM                                        +3 ++8
    LOCK.EXE                                         +2 ++4 (alles) -6
    MEM.EXE                                          +3 ++8
    MEMMAX.COM                                       -1 -5 -6
    MODE.COM                                         -1 -5 -6
    MORE.COM                                         -1 -5 -6
    MOVE.EXE                                         +3 ++8
    NETWARS.EXE                                      -1 -5 -6
    NLSFUNC.EXE                                      -1 -5 -6
    NWCACHE.EXE                                      -1 -5 -6
    NWCDEX.EXE                                       +3 -6
    PASSWORD.EXE                                     +3 ++8
    PNUNPACK.EXE                                     +3 -6
    PRINT.COM                                        +3 ++8
    RECOVER.COM                                      +3
    RENDIR.EXE                                       +3 -6
    REPLACE.EXE                                      +3 ++8 ??
    RESTORE.COM                                      +3 ++8
    SCRIPT.EXE                                       -1 -5 -6
    SDRES.EXE                                        +2 -6
    SDSCAN.EXE                                       +2 -6
    SERNO.EXE                                        +3 -6
    SETUP.EXE                                        -1 -5 -6
    SETVER.EXE                                       +3 ++8
    SHARE.EXE                                        -1 -5 -6
    SORT.EXE                                         +3 ++8
    SUBST.EXE                                        +3 +7
    SYS.COM                                          +3 -6
    TASKMGR.EXE                                      +2 -6
    TOUCH.EXE                                        +3 ++8
    TREE.COM                                         +3 ++8
    UNDELETE.EXE                                     +2 ++4 (alles) ++8
    UNFORMAT.EXE                                     +2
    XCOPY.EXE           (BC++91)                     +3 ++8 -10??
    XDEL.EXE            (BC++91)                     +3 ++8
    XDIR.EXE            (BC++91)                     +3 ++8 -10

                                                                             
  ---------------------------------------------------------------------------

  II.2. Konfigurationsdateien CONFIG.SYS und AUTOEXEC.BAT umgehen:
  ===================================================[96-01-03]===

   Stichworte: Booten, <F5>, <F8>, CONFIG.SYS, SWITCHES=/N, DBLSPACE,
               DRVSPACE

   Wie MS-DOS 6.xx bietet nun auch Novell DOS 7 eine Möglichkeit, die
   Konfigurationsdateien CONFIG.SYS und AUTOEXEC.BAT zu umgehen, um z.B.
   ein absolut minimales Wartungssystem hochzuziehen, wenn ein neuer
   Treiber das übliche Booten verhindert.

   Wenn Sie während oder vor der zwei Sekunden andauernden Meldung
   'Starten von DOS...' die Taste <F5> (oder das gleichwertige <Ctrl>+<F5>)
   drücken, werden die CONFIG.SYS und AUTOEXEC.BAT Dateien komplett
   übergangen. Dabei unterbleibt beim Disketten-Boot jeglicher Zugriff
   auf die Festplatte, d.h. evtl. Boot-Probleme mit noch nicht initiali-
   sierten IDE-Festplatten sollten damit umgangen werden können (ohne
   <F5> hängt u.U. der Rechner beim ersten Zugriff auf eine ungültige
   Partitionstabelle - bei jeder DOS Version) (eine Lösung dieses Boot-
   Problems ist z.B. die Option FDISK "Master-Ladesatz schreiben",
   siehe Kapitel II.4.).

   Wenn Sie stattdessen einen Einzelschrittbetrieb fahren möchten und
   wie mit '?' vor jedem Befehl gefragt werden wollen, ob Sie ihn auch
   wirklich ausführen möchten, drücken Sie stattdessen die Taste <F8>
   (bzw. <Ctrl>+<F8>).
   Diese Möglichkeit läßt sich auch prima zum Debuggen komplexer CONFIG.SYS
   Dateien benutzen. Möchte man den Ablauf nur genau verfolgen, ohne ins
   Geschehen einzugreifen, ist das ständige Drücken auf die Ja-Taste sehr
   lästig. Mit den undokumentierten Möglichkeiten von TIMEOUT= und YESCHAR=
   kann man jedoch einen automatischen Scroll-Effekt erzielen:

    TIMEOUT=1,J
    YESCHAR=J          (mehr dazu in Kapitel III.1.)

   Zurück zum Thema:

   Bei MS-DOS können Sie im Einzelschrittbetrieb (<F8>) jederzeit mit <F5>
   alle restlichen Einträge von CONFIG.SYS und AUTOEXEC.BAT umgehen. Dies
   ist mit Novell DOS nicht möglich. Außerdem können Sie bei MS-DOS die
   beiden Tasten auch noch während der Anzeige eines Boot-Menüs drücken.
   Diese Möglichkeit gibt es bei Novell DOS ebenfalls nicht.

   Ob die erweiterten Möglichkeiten <Ctrl>+<F5> und <Ctrl>+<F8>, die bei
   MS-DOS auch DBLSPACE bzw. DRVSPACE umgehen, bei Novell DOS auch arbeiten,
   wurde nicht überprüft (auch nicht, ob STACKER sie unterstützt), es ist
   jedoch wahrscheinlich der Fall (siehe auch Kapitel II.6.). Innerhalb
   IBMBIO.COM werden sie jedenfalls genauso wie <F5> und <F8> behandelt
   (und deshalb hier auch nicht weiter erwähnt).

   Neben <F5> kann die Abarbeitung bei Novell DOS auch durch Drücken der
   <Shift>-Taste umgangen werden (was einen Vorteil hat: Die <Shift>-Taste
   läßt den Tastaturpuffer auch bei dauerhaftem Druck nicht überlaufen.
   Dadurch unterbleibt das lästige Piepsen).

   Der undokumentierte CONFIG.SYS Schalter SWITCHES=/N von MS-DOS wird
   auch bei Novell DOS (zumindest ab Update 13) ausgewertet. Damit kann
   die Behandlung von <F5> und <F8> unterbunden werden. Bei Novell DOS
   ist aber generell auch die Position der CONFIG.SYS Direktiven in dieser
   Datei ausschlaggebend. Je nachdem, wo Sie also SWITCHES= platzieren,
   können unterschiedliche Dinge passieren. Wenn Sie das Verhalten von
   MS-DOS nachbilden wollen, müssen Sie diese Anweisung in die erste
   Zeile der CONFIG.SYS Datei schreiben. Näheres zu diesem Phänomen siehe
   Kapitel III.1. Mit Update 15 hat es einige Fixes bezüglich des <F5>/<F8>-
   Handling gegeben; ob darunter auch dieses Phänomen fällt, ist noch
   nicht überprüft.

   Ab Update 15 wird eine aktivierte <F8>-Behandlung - wie bei MS-DOS -
   über die neu eingeführte Option COMMAND.COM /Y an den Kommandoprozessor
   weitergegeben (siehe Kapitel II.11.), vorher wurde offenbar ein anderes
   Verfahren verwendet.

   Das erweiterte Verhalten, das mit MS-DOS 7 eingeführt wurde, kann das
   1,5 Jahre früher eingeführte Novell DOS 7 natürlich noch nicht kennen.

                                                                             
  ---------------------------------------------------------------------------

  II.3. CD-ROMs und Cache: [97-04-02]
  ===================================

   Stichworte: CD-ROM, NWCDEX, MSCDEX, NWCACHE, SMARTDRV, DPMS, Speicher

   Dieser Abschnitt geht auf einige Besonderheiten des Cache- und CD-ROM-
   Supports unter Novell DOS 7 ein und stellt Alternativen und Workarounds
   vor, wie Sie bestimmte Probleme vermeiden können.

   Statt dem Programm MSCDEX liefert Novell ein Programm namens NWCDEX mit
   (unbedingt die aktuelle Version 2.81+ aus Update 15 verwenden).
   Dieses Programm bietet die gleichen Funktionen wie MSCDEX, allerdings
   braucht es selbst bei maximaler Größe der Puffer nur 7 KByte im ersten
   MegaByte. Dieser Teil kann auch komplett hochgeladen werden, sofern
   während der Initialisierung des Treibers mehr als 85 KByte freier
   Speicher in den UMBs verfügbar sind. Mit anderen Worten: NWCDEX muß
   sich erst mal komplett dort einnisten können! Danach kann sich NWCDEX
   unter Benutzung von DPMS bis auf 7 KByte ausgelagern (der DPMS-Treiber
   selbst benötigt ca. 1 KByte im konventionellen Speicher). DPMS arbeitet
   auch mit MS-DOS/PC-DOS, so daß der Wechsel von MSCDEX (braucht 16 KByte
   nach Auslagerung) zu NWCDEX auch für MS-DOS Benutzer sinnvoll sein kann.
   Zu PC-DOS 7 wird ebenfalls ein DPMS-Treiber ausgeliefert und auch der mit
   manchen TSRs, Netz-Clients und BIOSen ausgelieferte Protected Mode
   TSR-Server CLOAKING.EXE von Helix Software unterstützt undokumentiert
   das API von DPMS, ja sogar PTS/DOS (alias S/DOS) scheint DPMS benutzen
   zu können, so daß sich dieser Standard langsam etabliert (siehe auch
   Kapitel II.4. bei DPMS).

   (Weitere interessante Hinweise speziell zur Installation und Optimierung
   von NWCDEX finden sich in Kapitel II.4. bei NWCDEX.)

   Statt SMARTDRV bietet Novell DOS den Cache NWCACHE, der bei subjektiv
   besserer Performance und Stabilität mehr Funktionalität bietet. Unter
   anderem kann er bei Bedarf auch DOS-Programmen Speicher ausleihen
   (SMARTDRV kann dies nur bei MS Windows), bietet verzögertes Schreiben,
   verwendet adaptive Cache-Strategien und er unterstützt wie NWCDEX
   ebenfalls DPMS.

   Ein direkter Vergleich (ja, SMARTDRV funktioniert als eines der wenigen
   MS-DOS Programme auch unter Novell DOS, wohl, weil es auch bei MS Windows
   beiliegt) brachte folgendes zutage:

                  SMARTDRV   NWCACHE

   bis 640 KByte  16 KByte   0 KByte (1 KByte für DPMS)

   UMBs           12 KByte   16 KByte + 5 KByte
                             (16 KByte ist der Maximalwert des 'voraus-
                             schauenden' Puffers, der bis auf 4 KByte
                             reduziert werden kann)

    via DPMS          ---    restlicher Code ausgelagert.
                             (Ohne DPMS benötigt NWCACHE mindestens 10 KByte
                             konventionellen Speicher, also immer noch
                             weniger als SMARTDRV. Bei Verwendung von XMS
                             statt EMS steigt ohne DPMS auch der benötigte
                             Basisspeicher mit der Größe des Caches um
                             einige KiloByte an.)

   Das bedeutet, daß NWCACHE bei sinnvoller Konfiguration locker 7 KByte
   kostbaren Speicher weniger benötigt und obendrein überhaupt keinen
   konventionellen Speicher verwendet. (Es ist u.U. möglich, daß sich
   SMARTDRV in anderen Konfigurationen ebenfalls hochladen kann.)

   Ein Nachteil sei allerdings nicht verschwiegen:

   NWCACHE kann - entgegen anderslautenden Meldungen - derzeit keine
   CD-ROMs cachen (SMARTDRV kann das auch erst in der neusten Versionen zu
   MS-DOS 6.20+ (vgl. SMARTDRV /U)). Das liegt daran, daß CD-ROM-Laufwerke
   nicht über einen herkömmlichen Blocktreiber, sondern auf völlig andere
   Art und Weise - wie heutzutage auch Netzwerke - über den Umadressierer
   (Redirektor) eingebunden werden, und entfernte Netzlaufwerke puffert
   NWCACHE aus Sicherheitsgründen ebenfalls nicht. Lokale Laufwerke werden
   natürlich gepuffert, was auch der Performance eines PNW-Servers zugute
   kommt. Andere Caches, die verzögert schreiben, können auf PNW-Rechnern
   (und in anderen Netzen) zu Datenverlusten führen.

   Wenn Sie auf gecachete CD-ROMs *nicht* verzichten können, sollten Sie
   entweder einen zusätzlichen CD-ROM-Cache eines Drittanbieters benutzen
   (wie z.B. CD-Quick CDQ.EXE) oder auf die Kombination DPMS+NWCDEX+SMARTDRV
   ausweichen. Eventuell reicht es aber auch aus, die Zwischenpuffer der
   beiden CD-ROM-Treiber zu erhöhen und weiterhin NWCACHE zu verwenden.
   In diesem Fall können Sie die Einstellung /M:value (z.B. NWCDEX /M:32)
   und/oder zusätzlich die Zwischenpuffereinstellung des Hardware-Treibers
   erhöhen (häufig ebenfalls Option /M:value, z.B. für 64 XMS-Puffer bei
   Mitsumi FX-001 etc.: DEVICEHIGH=MTMCDAE.SYS /M:64 /X).
   Je nach Einstellung der anderen Optionen ist es möglich, diese Puffer,
   die teilweise sehr viel Platz benötigen, ebenfalls ins XMS auszulagern.
   Ob diese Alternative für Ihre Konfiguration annehmbare Performance bei
   besserer Speicherbilanz als die Kombination DPMS+NWCDEX+SMARTDRV bietet,
   müssen Sie selbst herausfinden. Die Kombination MSCDEX+SMARTDRV ist
   dagegen nicht besonders zu empfehlen, da die Pufferung von CD-ROMs, wie
   sie SMARTDRV vornimmt, in dieser Form nicht sehr effektiv ist und zu-
   sätzlichen Speicher kostet, der besser in einen speziellen CD-ROM-Cache
   eines Drittanbieters (s.o.) investiert wird. Oft begnügt sich ein solcher
   Cache schon mit dem Speicher, der bei MSCDEX durch Reduzierung der Puffer
   eingespart werden kann, so daß die Speicherbilanz ausgeglichen bleibt.
   Da NWCDEX aber DPMS nutzen kann und damit die Puffer ausgelagert werden
   können, tritt dieses günstige Paradoxon hier leider nicht auf.

   Sie sollten übrigens bei Benutzung von CD-ROMs (mit DMA-Nutzung) unter
   MS Windows 3.xx die Direktive DMABUFFERSIZE=128 in SYSTEM.INI [386Enh]
   eintragen (bzw. erhöhen), um die Systemstabilität zu erhöhen.

   Weitere Hinweise zu NWCDEX und NWCACHE gibt es in Kapitel II.4.

                                                                             
  ---------------------------------------------------------------------------

  II.4. Undokumentierte Eigenschaften externer Kommandos: [97-03-24]
  ==================================================================

   Stichworte: Alle externen Kommandos und Treiber

   Im folgenden Überblick sind fast *nur* nicht offensichtliche Eigen-
   schaften und undokumentierte Möglichkeiten einiger externer Novell DOS
   Kommandos und Treiber aufgeführt. Bezüglich der generellen Funktion
   und aller offiziellen Parameter (auch der bei Novell DOS neu eingeführten
   Parameter) sei auf das DOSBOOK und die /? Hilfe verwiesen.
   Ein Teil dieser Hinweise fußt lediglich auf Vermutungen (wird erwähnt),
   die noch bestätigt werden müssen. Wer also diesbezügliche Erfahrungen
   sammelt, sollte mir seine Erkenntnisse bitte übermitteln.

   ASSIGN.COM    Für die Angabe der Statusinformationen sind folgende
                 Parameter erlaubt: /S, /STA, /STATUS, andere Formen
                 sind ungültig.

                 Außerdem wird - undokumentiert - auch noch die DR DOS
                 Option /A unterstützt, die genauso wie die neue dokumen-
                 tierte Option /S eine Übersicht über die aktuellen Zu-
                 ordnungen ausgibt.

                 Die von CCI Multiuser DOS 7.22 Gold unterstützte Option
                 /B für eine Ausgabe mit vorangestelltem ASSIGN zur
                 Wiederverwendung in Batchjobs in Verbindung mit Umleitung
                 gibt es bei Novell DOS und Caldera OpenDOS 7.01 leider
                 nicht, dies kann aber leicht nachträglich implementiert
                 werden.

                 ASSIGN sollte nicht auf Netzlaufwerke angewendet werden.
                 Obwohl DOS zunächst ordnungsgemäß zu arbeiten scheint,
                 soll es zu Fehlverhalten kommen können (nicht überprüft).
                 ASSIGN sollte man nicht ohne weiteres auf die Festplatte
                 C: (bzw. das Laufwerk, von dem der Kommandoprozessor
                 geladen wird) anwenden. Nach ASSIGN ist sonst die alte
                 %ComSpec% Einstellung u.U. ungültig, der transiente Teil
                 des Kommandoprozessors kann nicht mehr nachgeladen werden
                 und DOS kann nicht mehr weiterarbeiten (vgl. Kapitel
                 IV.7.). Arbeitet man mit Novells COMMAND.COM, bekommt
                 man jedoch u.U. die Möglichkeit, einen neuen Pfad zum
                 Kommandoprozessor anzugeben, sobald Novell DOS feststellt,
                 daß die alte %ComSpec% Einstellung ungültig ist.
                 Im Gegensatz zu DR DOS' ASSIGN werden bei Novells ASSIGN
                 aus Kompatibilitätsgründen gegenüber MS-DOS die alten
                 Einstellungen gelöscht, sobald neue angegeben wurden.
                 Es gibt aber die Möglichkeit, mehrere Verknüpfungen mit
                 einem Aufruf anzugeben. Näheres hierzu im FaxBack-Infopaper
                 15196.TXT aus ND7TID.EXE.
                 In Update 12 (ASSIGN 1.05) gab es einen Fix, der
                 dafür sorgte, daß nur noch Verknüpfungen unterhalb
                 von LASTDRIVE= angezeigt werden.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok oder Hilfeschirm
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)
                  4  Syntax-Fehler

   ATTRIB.EXE    Unterstützt über die undokumentierte Syntax /U:name
                 die Angabe eines zulässigen Benutzeranmelde- oder
                 Gruppennamens (maximal 12 Zeichen lang). Diese Option
                 ist nicht in jeder Betriebssystemkonfiguration verfügbar
                 und hat in Novell/DR Multiuser-Varianten oder in Ver-
                 bindung mit lokalen Benutzerkonten oder einmaliger
                 Anmeldung eine Bedeutung, sofern die Systemabsicherung
                 aktiviert ist.

                 Sie können auch mehrere Attribute mit einem '+'/'-'-
                 Zeichen koppeln, etwa:

                  ATTRIB c:\*.* +shr

                 Haben Sie schon mal das Problem gehabt, ein Verzeichnis
                 löschen zu wollen, dessen Hidden-Attribut gesetzt war
                 (etwa C:\NWCNTL\ oder C:\SENTRY\)? Mit DIR werden solche
                 Verzeichnisse nicht angezeigt, wohl aber mit ATTRIB.
                 Allerdings kann man sie mit ATTRIB nicht löschen. Entweder
                 man verwendet dafür den Norton Commander, XDEL oder wendet
                 einen kleinen Trick an, der bei der Beschreibung von
                 PASSWORD.EXE steht...

                 MS-DOS 4.0+ unterstützte teilweise einige undokumentierte
                 Optionen (siehe MSDOSTIP.TXT: /FILESIZE, /DATE, /TIME,
                 /CODEPAGE, /CP), die Novell DOS 7 und DR DOS fremd
                 sind, vgl. aber die Möglichkeiten von Novell DOS/DR DOS
                 TOUCH.EXE.

                 Errorlevel (unvollständig):

                  0  normales Ende (MS-DOS/PC-DOS, angeblich auch bei
                     DR DOS 6.0)
                     Novell DOS 7: normales Ende oder Datei nicht gefunden
                  1  Datei nicht gefunden (MS-DOS/PC-DOS, angeblich bei
                     DR DOS 6.0)
                  3  Abbruch (MS-DOS/PC-DOS, angeblich auch DR DOS 6.0)
                 31  Novell DOS 7: Benutzerabbruch durch <Ctrl>+<Break>
                                   oder unzulässige Aufrufoption

   APPEND.EXE    Verwendet bei entsprechender Einstellung (/E) eine
                 Umgebungsvariable %Append%. Die von CCI Multiuser DOS 7.22
                 Gold unterstützte Option /B für eine Ausgabe mit voran-
                 gestelltem APPEND zur Wiederverwendung in Batchjobs in
                 Verbindung mit Umleitung gibt es bei Novell DOS und
                 Caldera OpenDOS 7.01 leider nicht, dies kann aber leicht
                 nachträglich implementiert werden.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  normales Ende
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)

   BACKUP.COM    BACKUP erstellt Sicherungskopien Ihrer Dateien.
                 Sie können ganze Festplatten und Disketten sichern oder
                 Dateiverzeichnisse, Dateigruppen und sogar einzelne
                 Dateien. Die Sicherungskopien müssen mit dem Kommando
                 RESTORE geladen werden, bevor sie als DOS-Dateien ver-
                 wendet werden können.

                 Das Kommando BACKUP ist bei Novell DOS undokumentiert
                 (abgesehen von neuerlichen Hinweisen im FaxBack-System),
                 wohl weil ein leistungsfähigeres zugekauftes Programm
                 namens FBX (FastBack Express/Plus) beiliegt (abgesehen
                 davon sind Disketten-Backups bei heutigen Festplatten-
                 kapazitäten weder vom Zeitbedarf, noch von der Anzahl der
                 nötigen Disketten kaum noch zumutbar, höchstens mit
                 Programmen wie PC-BACKUP von den PC-Tools).
                 Trotzdem, aus Kompatibilitätsgründen sind BACKUP.COM und
                 RESTORE.COM weiterhin vorhanden.
                 Dabei ist BACKUP mit MS-DOS/PC-DOS BACKUP/RESTORE Version
                 3.30 und höher vollständig kompatibel, d.h. mit RESTORE
                 können auch Fremd-Backups gelesen werden und Novells
                 BACKUP kann auch von MS-DOS RESTORE restauriert werden.
                 (Bei MS-DOS wurde BACKUP nur bis zur DOS-Version 5.0
                 ausgeliefert und war teilweise inkompatibel zur jeweiligen
                 Vorgängerversion.) Die bei MS-DOS BACKUP vorhandenen
                 Parameter (/C, /P und - undokumentiert - /HP) werden
                 von Novells BACKUP nicht unterstützt.

                 Verwenden Sie das Programm BACKUP nicht bei Platten/
                 Disketten, auf die das Kommando ASSIGN, JOIN oder SUBST
                 einwirkt (ist mehr eine Vorsichtsmaßnahme als eine
                 Bedingung).

                 Das Format der Datums-/Zeitangaben hängt von der
                 jeweiligen COUNTRY-Einstellung ab.

                 Durch Paßwort geschützte Dateien und Unterverzeichnisse
                 werden *nicht* gesichert, wenn nicht das globale Paßwort
                 gesetzt wurde, bevor BACKUP gestartet wird, und die Dateien
                 mit demselben Paßwort geschützt sind.

                 Parameterüberblick:
                 (soweit ist noch alles von DR DOS bekannt)

                  /A             Fügt neue Dateien in Sicherung ein, ohne
                                 die alten zu löschen. Damit kann auch ein
                                 vorhandenes Backup fortgesetzt werden
                                 (frühe Version von DR DOS 6.0 unterstützten
                                 dies noch nicht).
                  /D:tt.mm.jj    Seit einem best. Datum geänderte Dateien
                                 werden gesichert.
                  /F[:n]         Formatieren d. Zieldisketten (optional mit
                                 Angabe der Kapaz. n).
                  /L[:dateispez] Alle Aktionen der Sicherung werden in einer
                                 Protokolldatei (Standardname: \BACKUP.LOG)
                                 aufgezeichnet: Datum und Uhrzeit der
                                 Sicherung und die Nummer der Sicherungs-
                                 diskette, auf der jede Datei gesichert ist.
                                 Die Protokolldatei wird im Hauptinhaltsver-
                                 zeichnis der Ursprungsplatte-/diskette
                                 abgelegt. Wenn Sie den Namen einer bereits
                                 existierenden Protokolldatei im Haupt-
                                 inhaltsverzeichnis angeben, werden die
                                 neuen Protokollinformationen an die be-
                                 stehenden Daten angehängt.
                  /M             Nur seit dem letzten Sichern geänderte
                                 Dateien werden gesichert. (Mit diesem
                                 Schalter werden alle Dateien gesichert, für
                                 die das Archivierungs-Bit gesetzt ist. Dies
                                 kann natürlich mit ATTRIB manuell gesetzt
                                 werden.)
                  /S             Dateien in Unterverzeichnissen werden auch
                                 gesichert. Zur Sicherung einer ganzen
                                 Festplatte/Diskette müssen Sie sich im
                                 Hauptinhaltsverzeichnis befinden und /S
                                 angeben.
                                 Standardmäßig wird nur das *aktuelle*
                                 Inhaltsverzeichnis gesichert.
                  /T:hh:mm:ss    Seit einem bestimmten Zeitpunkt geänderte
                                 Dateien werden gesichert (mit /D).

                 Errorlevel (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 2.00+, Novell DOS 7,
                  Caldera OpenDOS 7.01, DR DOS 6.0 und CCI Multiuser DOS
                  7.22 Gold)

                  0  normales Ende
                  1  keine Dateien zur Sicherung gefunden
                  2  einige Dateien wegen Zugriffskonflikt nicht gesichert
                  3  Sicherung durch <Ctrl>+<Break> abgebrochen
                  4  Sicherung durch Fehler abgebrochen oder ungültige
                     Parameter angegeben.

                 Weitere Hinweise:

                 Der Parameter /F:format erlaubt alle (undokumentierten)
                 Varianten des FORMAT.COM /F: Kommandos, da bei der Angabe
                 dieses Parameters über die Variable %Path% das externe
                 Kommando FORMAT.COM gesucht und intern gestartet wird.

                 Der undokumentierte Schalter /U:name erlaubt die Angabe
                 eines zulässigen Benutzeranmelde- oder Gruppennamens.
                 Diese Option ist nicht unter jedem Betriebssystem ver-
                 fügbar und hat in Novell/DR Multiuser-Varianten oder
                 in Verbindung mit lokalen Benutzerkonten und einmaliger
                 Anmeldung eine Bedeutung, sofern die Systemabsicherung
                 aktiviert ist.

   CHKDSK.EXE    Novells CHKDSK wurde gegenüber früheren Versionen und
                 gegenüber MS-DOS extrem erweitert und kann von den Möglich-
                 keiten durchaus mit Programmen wie DISKFIX (PC-Tools) oder
                 NDD (Norton Utilities) mithalten, wenn es auch bei Weitem
                 nicht so komfortabel ist.

                 Trotzdem wird der Benutzer in vielen kritischen Situationen
                 über mögliche Risiken informiert und bekommt regelrechte
                 Ablaufpläne angezeigt, die ihm helfen, die jeweilige
                 Situation zu meistern.

                 Es besitzt Erkennungsmöglichkeiten für alle gängigen Multi-
                 tasker wie TASKMGR, Windows, DESQview, OS/2, als auch für
                 PNW. PNW-Server müssen nach Bestätigung automatisch beim
                 Start von CHKDSK deaktiviert werden, wenn Fehler korrigiert
                 werden sollen.

                 Verlorene Blöcke werden in Dateien namens FILExxxx.CHK
                 gespeichert.

                 CHKDSK kommt neben normalen Festplatten mit SuperStor-,
                 DoubleDisk- und insbesondere STACKER-Laufwerken zurecht.
                 Für STACKER 3 Laufwerke gibt es die Spezialparameter /D
                 und /S (interne STACKER-Überprüfung). Für den inkompa-
                 tiblen STACKER 4 wurde mit Update 13 (CHKDSK 1.21) ein
                 neuer Parameter /NS eingeführt, der STACKER-Laufwerke
                 übergeht. Diese Version enthält auch einige andere Fixes.

                 Weitestgehend unbekannt, wenn auch nicht ganz undokumen-
                 tiert ist die Tatsache, daß CHKDSK auch eine Analyse über
                 die Fragmentierung von Dateien ausgeben kann, wenn man
                 dazu als Parameter die Dateispezifikation (Wildcards
                 erlaubt) angibt. Alle spezifizierten Dateien im gewählten
                 Verzeichnis, die nicht in einem Stück auf der Platte
                 gespeichert sind, werden in einer Liste ausgegeben.
                 Um zerstückelte Dateien zusammenzufassen, kann man danach
                 z.B. DISKOPT aufrufen.

                  CHKDSK c:\*.*

                 Hierfür gab es einen Fix mit Update 15 (Januar 1996).

                 Die Angabe des Gesamtplatzbedarfs für Dateien bei CHKDSK
                 beziehen sich auf den verwendeten Speicherplatz auf dem
                 Laufwerk, wohingegen sich die Angaben bei TREE auf die
                 Dateien selbst beziehen. Die Angaben von CHKDSK sind also
                 etwas größer. (Näheres zum Thema Clusterisierung siehe bei
                 FDISK in Kapitel II.4.)

                 Obwohl Novell DOS 7 (ab einem Update) Medienseriennummern
                 unterstützt, werden diese von COMMAND.COM während des DIR-
                 Befehls nicht ausgegeben. Um die Medienseriennummer zu
                 erfahren (vorausgesetzt das Medium besitzt eine, was von
                 der DOS-Version und -Hersteller abhängt, unter dem das
                 Medium formatiert wurde), kann man CHKDSK aufrufen.

                 Achtung: Bei DR DOS 3.41 und DR DOS 5.0 besaß CHKDSK eine
                 große Anzahl Optionen, die mit DR DOS 6.0 weggefallen sind
                 (sehr viel manuelle Feineinstellung war möglich, offenbar
                 wurde auch noch CP/M unterstützt). Im Einzelnen waren von
                 dieser Ausdünnung die alten Optionen /A, /B, /C, /D, /L,
                 /M, /P, /R und /S betroffen, so daß DR DOS 6.0 CHKDSK nur
                 noch /F, /V, /H und /? unterstützte (DR DOS 5.0 CHKDSK
                 startet auch unter Novell DOS, dürfte aber nur einge-
                 schränkt verwendungsfähig sein). Novell DOS 7 hat gegenüber
                 DR DOS 6.0 CHKDSK einige neue Optionen, die teilweise mit
                 den Buchstaben der alten DR DOS 3.41/5.0 Optionen kolli-
                 dieren: /B, /D und /S.

                 Achtung: CHKDSK kommt derzeit noch nicht mit MS Windows95
                 langen Dateinamen zurecht! Caldera hat aber Abhilfe dafür
                 versprochen, die aber mit Caldera OpenDOS 7.01 noch nicht
                 mitgeliefert wird.

                 Errorlevel (verifiziert für CCI Multiuser DOS 7.22 Gold):

                   0  alles ok
                   1  es gibt offene Dateien, CHKDSK kann nicht arbeiten
                 255  CHKDSK hat einen Fehler entdeckt

   COMP.COM      Dieses Kommando bietet bei DR DOS und Novell DOS einen
                 Parameter /M:n, der die Anzahl der Unstimmigkeiten vor
                 dem Abbruch angibt (Standard ist laut DOSBOOK 10, wie
                 auch bei MS-DOS/PC-DOS, bei CCI Multiuser DOS 7.22 Gold
                 jedoch wohl 20). Der Parameter selbst existiert allerdings
                 bei MS-DOS/PC-DOS nicht (abgesehen davon, daß COMP dort
                 sowieso mit MS-DOS 6.20 abgeschafft wurde und nur noch
                 auf einer Supplemental-Disk zu finden ist).

                 Im Gegensatz zum höherentwickelten FC.COM arbeitet COMP.COM
                 immer zeichenweise, kann allerdings die Informationen auch
                 in Einheiten von Zeilen aufbereiten. Eine Resynchronisation
                 ist bei COMP.COM nicht möglich, dementsprechend fragt COMP
                 auch explizit nach (J/N), wenn sich die Dateilänge der
                 beiden Dateien unterscheidet (siehe Kapitel II.16. zur
                 Vermeidung von Problemen in Batchjobs).

                 Die von CCI Multiuser DOS 7.22 Gold bekannten Optionen
                 /B (für explizite Binärvergleiche, auch wenn die Dateien
                 nicht eine der Endungen .EXE, .COM, .SYS, .OBJ, .BIN oder
                 .LIB aufweisen), /W (für Unterdrückung von WhiteChars, d.h.
                 Leerfeldern und Tabs während eines ASCII-Vergleichs) und
                 /Gn (Anzahl der Zeilen, die vor einer Resynchronisation
                 übereinstimmen müssen, Default für n ist 5) kennt Novells
                 COMP.COM nicht, da diese Funktionen dort mit dem neueren
                 FC.COM bereitgestellt werden, das CCI Multiuser DOS noch
                 nicht kennt. Wie gesagt, Novells COMP arbeitet für alle
                 Dateien zeichenweise, also 'binär', daher sind alle drei
                 Optionen hier überflüssig.

                 Da COMP.COM standardmäßig die Unterschiede zwischen den
                 Dateien als absolute Position innerhalb der Dateien angibt,
                 ist es erwähnenswert, daß bei Novell DOS auch (neben DEBUG)
                 ein Werkzeug zur Verfügung steht, mit dem man diese
                 Informationen 'verarbeiten' kann: Novells EDIT zeigt
                 nämlich u.a. die absolute Zeichenposition an, wodurch es
                 in Textdateien besonders leicht ist, die Fundstelle zu
                 lokalisieren (siehe auch bei EDIT.COM in diesem Kapitel).

                 In der Dokumentation wird nicht erwähnt, daß COMP.COM auch
                 interaktiv eingesetzt werden kann:
                 Gibt man keine Dateispezifikationen an, fragt COMP.COM
                 von selbst nach, wobei auch hier Wildcards etc. angegeben
                 werden können.

                 Errorlevel (unvollständig):

                 (nur für Novell DOS 7 verifiziert!)

                   0  normaler Ablauf, auch falls Zieldatei nicht gefunden
                      oder bei unterschiedlich großen Dateien
                   3  Benutzerabbruch (<Ctrl>+<c> etc.)
                   4  keine Dateien oder Quelldatei nicht gefunden, oder bei
                      falscher Aufruf-Syntax

   DEBUG.EXE     Erhebliche Erweiterungen, die ein eigenes Kapitel füllen:
                 siehe Kapitel II.5.

                 Möchte man den Boot-Vorgang überwachen, kann man DEBUG.EXE
                 (wie fast jedes andere Programm auch) natürlich auch in
                 CONFIG.SYS aufrufen, z.B.:

                  INSTALL=c:\nwdos\debug.exe

                 Bugfixes mit Update 12 (DEBUG 1.41: Keine Probleme mehr
                 mit zerstörten Rootmappings, falls DEBUG von solchen Lauf-
                 werken gestartet wurde) und Update 13 (DEBUG 1.42: Fixes
                 für -I und -O Kommandos). Mit Update 14 wurde die Datei
                 nochmals verändert (ca. 1 KByte kleiner) hat aber nach
                 wie vor die Versionsnummer 1.42 und in der History sind
                 keine Änderungen erkennbar.

   DELPURGE.EXE  Ist mit MS-DOS 6.xx UNDELETE /PURGE vergleichbar, basiert
                 aber auf einem anderen Löschverfolgungskonzept (siehe
                 DELWATCH.EXE).

                 Unterstützt seit DR DOS 6.0 über die undokumentierte
                 Syntax /U:name die Angabe eines zulässigen Benutzeranmelde-
                 oder Gruppennamens (maximal 12 Zeichen lang). Diese Option
                 ist nicht unter jedem Betriebssystem verfügbar und hat
                 in Novell/DR Multiuser-Varianten oder in Verbindung mit
                 lokalen Benutzerkonten und einmaliger Anmeldung eine
                 Bedeutung, sofern die Systemabsicherung aktiviert ist.

                 DELPURGE unterstützt - wie auch Novells UNDELETE - neben
                 den dokumentierten Parametern noch eine Reihe weiterer
                 neuer Parameter (wie von MS-DOS/PC-Tools UNDELETE bekannt):

                  /ALL      identisch mit /A
                  /LIST     identisch mit /L
                  /DT       nur "Delete-Tracking-Methoden" verwenden, d.h.
                            nur die Unterstützung durch DISKMAP und DELWATCH
                            wählen. Der Sinn ist mir speziell bei DELPURGE,
                            das sich doch immer auf eine DELWATCH-Lösch-
                            verfolgung beziehen muß, nicht klar...
                  /DOS      nur "DOS-Löschmethoden" verwenden, d.h. auf
                            DISKMAP und DELWATCH verzichten.
                            Der Sinn ist mir speziell bei DELPURGE, das sich
                            doch immer auf eine DELWATCH-Löschverfolgung
                            beziehen muß, nicht klar...
                  *.*       Alles

                 Novells DELPURGE zeigt sowohl den Datums-/Zeitstempel
                 der ehemaligen Datei, als auch des Löschzeitpunktes an;
                 letzteres eine Angabe, die UNDELETE in seinen Ausgaben
                 unterschlägt.

                 Mit DELPURGE aus der Löschverfolgung genommene Dateien
                 lassen sich mit Novells UNDELETE *nicht* wieder restau-
                 rieren, denn DELPURGE trägt statt des zwischengespeicherten
                 ersten Buchstabens bei Offset +0Dh (BYTE) im reservierten
                 Bereich des jeweiligen Verzeichniseintrags ein E5h ('ó')
                 ein (daran ändert auch /DT oder /DOS nichts). Erst nachdem
                 man hier den wahren ersten Buchstaben der Datei hinschreibt
                 oder diesen Eintrag zu Null setzt, kann Novells UNDELETE
                 wieder arbeiten. Man kann aber stattdessen auch auf
                 PC-Tools 9.0 UNDEL.EXE ausweichen.
                 MS Windows95 alias MS-DOS 7 benutzt dieses Feld leider für
                 die 10 Millisekunden Einheiten des Zeitpunktes der Datei-
                 erzeugung, was UNDELETE verwirren könnte (bisher noch nicht
                 überprüft). Evtl. kann man das mit der dort neuen CONFIG.SYS
                 Direktive ACCDATE= unterdrücken und so die Kompatibilität
                 wahren.

                 Die Parameter /D:dd.mm.yy (bzw. /D:-nnn) und /T:hh:mm[:ss]
                 (in landesspezifischem Format) sind - im Gegensatz zu
                 UNDELETE (vgl. Kapitel II.4.) - bei DELPURGE exakt
                 dokumentiert und bieten wirklich nur die beschriebene
                 Funktionalität, beziehen sich also ausschließlich auf
                 den Löschzeitpunkt.
                 Da trotzdem gewisse Analogien zwischen den Parametern
                 von DELPURGE und UNDELETE bestehen, sei folgende Anmerkung
                 erlaubt: Beziehen sich die Angaben der Bereichsgrenzen bei
                 UNDELETE auf den Bereich *seit* dem angegebenen Zeitpunkt,
                 so gelten sie bei DELPURGE auf den Bereich *vor* dem ange-
                 gebenen Zeitpunkt, wie dies auch dem Wesen der beiden
                 Kommandos entspricht.

                 Während der Freigabe von entlöschbaren Dateien wird das
                 jeweilige Laufwerk gesperrt, um Deadlocks zu vermeiden.

                 Bugfixes mit Update 14 (DELPURGE 1.01: Gibt nun auch bei
                 installiertem DELWATCH korrekte Datumswerte aus) und Update
                 15 (DELPURGE 1.02: Fix für verlorene Cluster in seltenen
                 Situationen). Leider gibt es offenbar immer noch einen Bug
                 (getestet bis Update 15, Januar 1996), der dazu führt, daß
                 in seltenen Situationen bei DELPURGE /S die Meldung
                 "Bitte warten..." nicht mehr verschwindet und das System
                 hängt. In einem solchen Fall hilft Neubooten und erneutes
                 Ausführen von DELPURGE, evtl. ohne DELWATCH vorher zu laden
                 und evtl. mit "NWCACHE -". Näheres ist noch nicht geklärt.

                 Wird Novell DOS 7 DELPURGE auf Dateien angewendet, die noch
                 mit DR DOS 6.0 DELWATCH gelöscht wurden, so wird wahr-
                 scheinlich ein völlig falsches Löschdatum angezeigt
                 (1980-01-01???). Dies liegt daran, daß DR DOS 6.0 DELWATCH
                 sich in diesem Punkt von Novell DOS 7 DELWATCH unter-
                 scheidet (siehe DELWATCH).

   DELWATCH.EXE  Sollte nicht nach dem TASKMGR geladen werden.

                 Das Löschen der ersten Datei nach dem Start von DELWATCH
                 kostet u.U. einige Sekunden Zeit, wenn eine große Anzahl
                 entlöschbarer Dateien eingestellt wurde. Spätere Lösch-
                 aktionen erleiden keinen merklichen Geschwindigkeitsein-
                 bruch.

                 Man sollte versuchen, zu verhindern, daß das Temporär-
                 laufwerk bzw. -verzeichnis (%Temp%) in die Löschver-
                 folgung gerät, was leider nicht immer zu bewerkstelligen
                 ist, da die naheliegende Möglichkeit, DELWATCH einfach
                 nur für Substitut-Laufwerke zu benutzen, deswegen aus-
                 geschlossen ist, da DELWATCH nur mit physikalischen
                 Laufwerken arbeiten kann (Netzlaufwerke werden ggf. von
                 dem jeweiligen Server verwaltet, so daß trotzdem UNDELETE
                 durchaus auch für entfernte Laufwerke funktioniert). (Es
                 fehlt eine Möglichkeit, bestimmte Verzeichnisse von der
                 Erfassung der Löschverfolgung auszuschließen...). Praktisch
                 ist die Verwendung einer RAM-Disk als Temporärlaufwerk.

                 Um das meist unnötige 'Puffern' von temporären Dateien
                 zu verhindern und damit die Effektivität bezüglich der
                 Löschverfolgung zu optimieren, sollte man diese Dateien
                 von vornherein von der Löschverfolgung ausschließen, z.B.:

                  DELWATCH /E:TMP+$$$+@@@+SWP+ION+SEM+00?+IMM+$@?+~*

                 Möchten Sie hingegen eine Einschlußliste verwenden, ist es
                 ratsam, hier die Dateiendungen von Dokumenten, Datendateien
                 und Konfigurationsdateien anzugeben und auf .EXE, .COM,
                 .OVL, .DLL, .HLP, usw. zu verzichten, da diese Dateien
                 notfalls von den Original-Disketten neu installiert werden
                 können.

                 Diese Angabe der Ausschluß- oder Einschlußliste
                 (Parameter /O: und /E:, die nicht gleichzeitig erlaubt
                 sind) ist nur global für alle Laufwerke gemeinsam
                 möglich, kann aber auch nachträglich geändert werden.
                 Wie dokumentiert, können jeweils bis zu 10 Dateier-
                 weiterungen (auch mit Wildcards) angegeben werden, die
                 mit '+' voneinander getrennt werden müssen. Doch wie
                 gibt man z.B. eine 'leere' Endung an? Ganz einfach:
                 Bei Novell DOS nicht mehr dokumentiert ist nämlich die
                 Möglichkeit, daß man jede der Dateierweiterungen mit
                 einem optionalen Punkt ('.') einleiten kann (etwa:
                 /E:.SWP+.TMP). Eine leere Endung wird daher durch einen
                 einfachen Punkt spezifiziert (z.B. /E:., /E:.SWP+. oder
                 /E:.+BAK+SIK). Die Zeichen vor einem Punkt werden
                 ignoriert.

                 In der Dokumentation wird auch unterschlagen, daß die
                 Parameter /F:, /B: und /MB? für jedes Laufwerk getrennt
                 eingestellt werden können. Statt alle Laufwerke auf einmal
                 zu aktivieren, ruft man dazu DELWATCH mehrfach hinter-
                 einander für jedes Laufwerk einzeln auf, wobei die Para-
                 meter jeweils wie gewünscht angepaßt werden. Natürlich
                 gelten die Werte von /F: und /B: für jedes der aktivierten
                 Laufwerke extra, auch wenn mehrere Laufwerke auf einmal
                 angegeben werden.

                 Im DOSBOOK wird beschrieben, daß DELWATCH Dateien bis zu
                 einer einstellbaren Anzahl (mit /F:count (65535 für unbe-
                 grenzt) und davon mit gleichem Namen /B:doublets (von
                 1..65535)) in der Löschverfolgung hält, solange der Platz
                 auf dem Laufwerk dafür ausreicht. Ist die Kapazität der
                 Platte erschöpft, so werden die ältesten dieser Dateien
                 gelöscht, es sei denn, man hat die Option /F:ALL angegeben,
                 die in dieser Situation erst das explizite Entfernen von
                 Dateien aus der Löschverfolgung (Purgen) erfordert.

                 In der Praxis habe ich allerdings die Erfahrung gemacht,
                 daß diese Beschreibung sehr sinnvollen Verhaltens leider
                 in einigen Punkten *nicht* der Realität entspricht:

                 Ist die Anzahl der mit /F:count (count=1..65534) angege-
                 benen Dateien noch nicht erreicht und schon jetzt die
                 Kapazität der Platte erschöpft, so müssen auch hier erst
                 explizit Dateien aus der Löschverfolgung entfernt werden,
                 um Platz auf dem Laufwerk zu schaffen, d.h. die Option /F:
                 stellt leider gleichzeitig eine Untergrenze dar (dies
                 war auch schon bei DR DOS 6.0 so). Dies macht DELWATCH
                 mit dem eigentlich proklamierten Default-Verhalten nahezu
                 unbrauchbar, wenn die Anzahl und durchschnittliche Größe
                 der in der Löschverfolgung stehenden Dateien die freie
                 Kapazität der Platte nahezu erschöpft, was besonders bei
                 großen Werten für /F: und fast vollen Platten lästig wird.
                 Sinnvoll wäre es, hier in Zukunft Parameter zur getrennten
                 Einstellung der Unter- und Obergrenze einzuführen oder
                 zumindest die Untergrenze zu beseitigen.
                 (Sollten Sie andere Erfahrungen gemacht haben, teilen Sie
                 mir bitte Ihre Aufrufzeile von DELWATCH mit, denn - der
                 Literatur nach zu urteilen - scheint seltsamerweise außer
                 mir niemand sonst dieses Verhalten zu beobachten...)

                 Weiterhin sind die dokumentierten Sonderfälle /F:65535
                 und /F:ALL (getestet mit DELWATCH 2.1) nicht funktions-
                 fähig: /F:65535 wird als ungültiger Wert zurückgewiesen,
                 und /F:ALL führt den Rechner ins sofortige Daten-Nirwana...
                 (Bei DR DOS 6.0 wurden beide Einstellungen anstandslos
                 akzeptiert, allerdings hatte /F:65535 dort noch keine
                 Sonderfunktion. Leider arbeitet DR DOS 6.0 DELWATCH 1.0
                 jedoch unter Novell DOS 7 nicht korrekt.)

                 Und: Obwohl man auf den ersten Blick vermuten könnte,
                 mit /B: eine Möglichkeit zu haben, häufig aktualisierte
                 Dateien quasi in mehreren Versionen auf der Platte halten
                 zu können, ist dies in der Regel ein Trugschluß. Meist
                 werden dabei nämlich existierende Dateien nur durch
                 neuere Versionen überschrieben (z.B. beim COPY Befehl);
                 der Löschschutz würde aber nur aktiv, wenn die alte,
                 bereits existierende Datei vorher gelöscht würde.
                 Manchmal kann man dieses Verhalten aber in Batchjobs
                 durch explizites Löschen vor dem 'Überschreiben' er-
                 zwingen.
                 Praktischerweise gehen die meisten Editore genau so vor
                 (z.B. Novells EDIT oder SemWares QEDIT und TSE), wenn
                 sie eine bereits existierende .BAK-Datei durch eine
                 neuere Version überschreiben. Um mehrere .BAK-Dateien
                 in der Löschverfolgung zu halten, darf die Endung .BAK
                 (bzw. .SIK o.ä.) natürlich nicht mit /E: ausgeschlossen
                 werden...

                 Das Löschverfolgungskonzept von DELWATCH unterscheidet
                 sich ziemlich von dem unter PC-Tools (alias MS-DOS 6.xx
                 UNDELETE), und auch leicht von dem noch von DR DOS 6.0
                 DELWATCH verwendeten Verfahren (siehe DELPURGE und
                 UNDELETE).

                 MS-DOS UNDELETE /LOAD (von PC-Tools) verschiebt (bei
                 maximalem Schutz 'Löschüberwachung' alias 'Lösch-
                 verfolgung') die gelöschten Dateien in ein unsichtbares
                 Verzeichnis namens \SENTRY\ oder verwaltet (bei geringerem
                 Schutz 'Löschprotokoll') eine Datei PCTRACKR.DEL, die
                 Verweise auf gelöschte Dateien enthält. Die FAT-Infor-
                 mation bleibt intakt, dadurch gibt es keine Wechsel-
                 wirkungen mit anderen Festplattenpflegeprogammen. Das
                 UNDELETE-Programm muß sich dafür allerdings mit 13,5 KByte
                 resident machen.

                 DR DOS/Novell DOS verwendet ein anderes Verfahren,
                 daß in seiner Realisierung etwas leistungsfähiger und
                 flexibler, wenn auch etwas problematischer ist. Statt
                 die Dateien zu verschieben oder eine Verweisdatei auf
                 dem Laufenden zu halten (soetwas ähnliches gibt es mit
                 DISKMAP auch), werden (zumindest bei Novell DOS) nur die
                 Dateiattribute auf eine unmögliche Kombination gesetzt,
                 d.h. das Volume-Attribut wird zusätzlich gesetzt. Außerdem
                 wird der erste Buchstabe der Datei durch 05h ersetzt.
                 Erst, wenn die Dateien mit DELPURGE etc. aus der Lösch-
                 verfolgung entfernt werden, wird die übliche DOS-Lösch-
                 methode (erstes Byte E5h 'ó') verwendet. Außerdem wird
                 bei Novell DOS beim Löschen einer Datei generell auch
                 der erste Buchstabe an anderer Stelle im jeweiligen
                 Verzeichniseintrag zwischengespeichert (Offset +0Dh
                 (BYTE)). Wird eine Datei mit DELPURGE aus der Löschver-
                 folgung genommen, wird hier stattdessen E5h eingetragen,
                 wodurch die Datei für UNDELETE unsichtbar wird, obwohl
                 sie eigentlich immer noch auf herkömmlichem Wege entlösch-
                 bar wäre. In Verbindung mit Novell DOS 7 DELWATCH wird der
                 Datums-/Zeitstempel der Datei ebenfalls an andere Stelle
                 verschoben (Datum bei Offset +12h (WORD) und Zeit bei
                 Offset +10h (WORD)) und der normale Datums-/Zeitstempel
                 (Datum bei Offset +18 (WORD), Zeit bei Offset +16h (WORD))
                 durch die aktuelle Zeit (Löschdatum) ersetzt.
                 DR DOS 6.0 DELWATCH unterscheidet sich in diesem Punkt,
                 denn es läßt das Originaldatum wo (und wie) es ist und
                 verzichtet auf die Speicherung des Löschdatums. Dummerweise
                 wurde unter DR DOS 6.0 und Multiuser-Varianten das Feld bei
                 Offset +12h (WORD) noch zur Speicherung der Benutzer-ID
                 verwendet, Novell DOS 7 DELWATCH überschreibt dieses Feld
                 nun einfach mit einem Datum... (Besonders tragisch ist
                 das nicht, da es ja, wenn man einmal die Möglichkeit eine
                 Datei zu restaurieren, außer Acht läßt, nur solche Dateien
                 betrifft, die bereits gelöscht wurden, und dort sollte der
                 Eigentümer eigentlich keine große Rolle mehr spielen...
                 Bei RENAME o.ä. wird der gesamte reservierte Bereich
                 innerhalb der Verzeichnisstruktur übrigens nicht ge-
                 löscht, sondern vom System mitgeschleppt, so daß sich
                 Owner-IDs wieder reimplementieren ließen, siehe auch
                 bei PASSWORD.EXE und in Kapitel II.21.)

                 Durch die oben beschriebene Vorgehensweise ist das eigent-
                 liche Verfahren etwas schneller als bei MS-DOS/PC-DOS und
                 DELWATCH ist (mit DPMS) in der Lage, sich bis auf 464 Bytes
                 (die natürlich in UMBs liegen können) ins XMS auszulagern!
                 Die Startphase dauert allerdings bei großer Dateianzahl
                 auf einem Laufwerk recht lange, da hierfür die gesamte
                 Platte durchsucht werden muß. Andererseits sind keine
                 besonderen Dateien auf der Platte nötig und das Konzept ist
                 nicht an freien Speicher, maximale Anzahl der Dateien etc.
                 geknüpft.

                 Die Divergenzen (bezüglich MS-DOS/PC-DOS) in den Ver-
                 zeichniseinträgen sind ziemlich unkritisch, da diese
                 natürlich nicht wirklich defekt sind: Allerdings kommen
                 viele Disk-Tools von Fremdherstellern (etwa PC-Tools 9.0
                 DISKFIX, nicht aber Norton Utilities NDD) nicht absolut
                 sauber damit zurecht und meckern eine fehlerhafte Ver-
                 zeichnisstruktur an (denn innerhalb der bis zu MS-DOS 6.22
                 'reservierten' Bereiche - sonst mit Nullen gefüllt -
                 wurden von DELWATCH einige Daten eingetragen, die nun
                 DISKFIX verwundern). Wenn Sie dann 'Korrigieren' wählen,
                 werden entweder gelöschte Dateien wieder 'entlöscht',
                 oder eher, entlöschbare Dateien dauerhaft gelöscht (d.h.
                 aus der Löschverfolgung entnommen). Ich empfehle, vorher
                 DELPURGE /S laufen zu lassen, was allerdings nicht mehr
                 funktionieren mag, wenn die Struktur *wirklich* defekt ist.
                 Meist können Sie auch ganz auf solche Fremd-Tools ver-
                 zichten und z.B. Novells recht leistungsfähiges CHKDSK
                 verwenden. Alternativ dazu können Sie, wenn Sie den dafür
                 notwendigen Speicher übrig haben, statt der Benutzung von
                 DELWATCH/DELPURGE natürlich auch auf MS-DOS 6.2x UNDELETE
                 /LOAD ausweichen.

                 MS-DOS UNDELETE /LOAD ist aber nur sehr beschränkt für
                 Netzlaufwerke geeignet; es müssen volle Schreibrechte auf
                 dem Laufwerk vergeben werden, was in Netzumgebungen nur
                 sehr ungern zugestanden wird. Mit Novells Gespann aus
                 DELWATCH/UNDELETE gibt es diese Einschränkung nicht, denn
                 es arbeitet direkt mit den Mechanismen der NetWare zusammen
                 und dabei ersetzt UNDELETE z.B. das alte Novell NetWare
                 SALVAGE. Auf einem PNW-Server muß DELWATCH installiert
                 sein, damit man von einem anderen Rechner aus Novells
                 UNDELETE für Dateien auf dem PNW-Server ausführen kann.

                 Es kann vorkommen, daß Fremdprogramme den freien Platz
                 auf einem Laufwerk nicht korrekt analysieren; dies liegt
                 einfach daran, daß in der Löschverfolgung hängende Dateien
                 effektiv solange nicht gelöscht sind, bis die Dateien mit
                 DELPURGE aus der Löschverfolgung genommen werden, der
                 Diskettenplatz nicht mehr ausreicht oder eine einstellbare
                 freie maximale Anzahl von in der Löschverfolgung verweilen-
                 den Dateien überschritten wird. Mit anderen Worten: Solange
                 entlöschbare Dateien in der Löschverfolgung existieren,
                 gibt es also einen entsprechend großen 'unsichtbaren'
                 Bereich auf dem jeweiligen Laufwerk, der von der wahren
                 Kapazität verloren geht.

                 Novells DELWATCH kollidiert mit MS-DOS 7 Long-Filename-
                 Support und ACCDATE=. Für Einträge von langen Datei- und
                 Verzeichnisnamen wird die unmögliche Attributkombination
                 0Fh=Read-Only+Hidden+Systen+Volume verwendet, und dies
                 könnte mit gelöschten, aber von DELWATCH überwachten
                 Systemdateien unter Novell DOS kollidieren, bzw. MS-DOS 7
                 als defekte Long-Filename-Einträge aufstoßen...
                 Da der Long-Filename-Support allerdings mit Prüfsummen
                 arbeitet, sollte eine ordentliche Implementation über
                 solche Einträge hinwegsehen.
                 MS-DOS 7 neue CONFIG.SYS ACCDATE= Funktion benutzt jedoch
                 für die Speicherung des letzten Zugriffsdatums das gleiche
                 Feld im reservierten Bereich, das auch DELWATCH zur
                 Zwischenpufferung des Datumsanteils einer gelöschten, aber
                 noch in der Löschverfolgung stehenden Datei benutzt
                 (Offset +12h (WORD)). Obwohl diese Doppelnutzung trickreich
                 ist, könnte es hier zu Problemen kommen, wenn ein Teil vom
                 anderen nichts weiß (oder wissen will...).
                 Und auch die neuen Einträge für die Dateierzeugung über-
                 lagern Novells Einträge von DELWATCH und PASSWORD (Offset
                 +0Dh (BYTE) = 10 Millisekunden-Raster nach der Dateier-
                 zeugung, deren Zeit bei Offset +0Eh (WORD) und Datum bei
                 Offset +10h (WORD) gespeichert ist), aber dies bezieht
                 sich wohl nur auf neue Dateien unter MS Windows95.

                 Fest steht, daß bei geeigneter Rücksichtnahme in der Imple-
                 mentation alle Funktionen (Microsofts Long-Filenames &
                 ACCDATE= sowie Novells DELWATCH und Paßwörter) einiger-
                 maßen kollisionsfrei nebeneinander existieren könnten (die
                 DR DOS 6.0 Owner-IDs sind natürlich verloren, aber Novell
                 DOS 7 unterstützt diese Möglichkeit sowieso nicht mehr im
                 API). (Siehe auch bei PASSWORD.EXE und in Kapitel II.21.)

                 Caldera hat dafür aber Abhilfe versprochen, die aber mit
                 Caldera OpenDOS 7.01 noch nicht mitgeliefert wird.

                 Errorlevel (unvollständig):

                 (nur für Novell DOS DELWATCH 2.1 aus Update 15 verifiziert)

                  0  normal
                 >27 nur in Verbindung mit Option /MBL: Entspricht, nach
                     Subtraktion von 27 dem Wert der explizit mit /F:n
                     angegebenen oder implizit angenommenen Anzahl der
                     maximal in der Löschverfolgung hängenden Dateien für
                     das/die aktivierte(n) Laufwerk(e), d.h. ohne Angabe
                     von /F:n für Diskettenlaufwerke 47 (20 Dateien) oder
                     für Festplattenlaufwerke 227 (200 Dateien).

   DISKCOMP.COM  Diese beiden Kommandos werten die Variablen %Temp% und
   DISKCOPY.COM  %tmp% aus, wenn eine temporäre Auslagerungsdatei auf der
                 Harddisk erzeugt werden muß (wenn der Speicher nicht
                 ausreicht). Natürlich wird zunächst EMS- und XMS-Speicher
                 zur Zwischenpufferung verwendet (evtl. kein XMS-Speicher
                 unter Windows 3.1). Auf diese Weise wird (ab DR DOS 6.0
                 (5.0?)) das bis zu zehnmalige Diskettenwechseln beim
                 Kopieren verhindert, das bei MS-DOS bis vor 6.2 Usus war.
                 Auf diese Weise ist auch Kopieren im Hintergrund unter
                 Multitaskern möglich.

                 In diesem Zusammenhang wurde mit MS-DOS 6.2 ein neuer
                 Parameter DISKCOPY /M eingeführt, der eine völlig andere
                 Funktion als der von DR DOS & Novell DOS 7 bekannte
                 Parameter /M hat: Statt Diskettenabzugsdateien (übliche
                 Dateiendung dafür ist .IMG) zu unterstützen, wird damit
                 die Verwendung des Festplattenspeichers unterdrückt.

                 Hinweis: Beim Vergleich (DISKCOMP) von mit DISKCOPY
                 kopierten Disketten älteren Datums kann es zu Unter-
                 schieden auf Seite 0 Spur 0 kommen, obwohl die Kopie
                 fehlerfrei ist. Dieses Phänomen tritt auch bei
                 MS-DOS/PC-DOS vor 5.0 auf:

                 Fixes mit Update 14 (DISKCOMP 2.04): Beim DISKCOPY werden
                 jetzt außer der Seriennummer keine Veränderungen mehr
                 vorgenommen, so daß jetzt mit DISKCOMP keine Fehlerreporte
                 mehr nach erfolgreichem DISKCOPY auftreten. DISKCOPY
                 formatiert Floppies nur noch, falls unbedingt notwendig
                 (d.h. nicht formatiert oder anderes physikalisches Format).

                 Errorlevel für DISKCOMP (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
                  wahrscheinlich auch DR DOS 6.0)

                  0  normales Ende
                  1  Disketten verschieden
                     oder bei Novell DOS 7 auch: Vergleich nicht ausgeführt,
                     bei DR DOS 6.0 auch       : ungültiges Laufwerk,
                                                 falsche Syntax
                  2  Abbruch durch Benutzer (<Ctrl>+<c> etc.)
                  3  Hardware-Fehler, kein Vergleich durchgeführt
                  4  Initialisierungsfehler, zu wenig Speicher, Laufwerk
                     oder Syntax falsch

                 Errorlevel für DISKCOPY (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
                  wahrscheinlich auch DR DOS 6.0)

                  0  normales Ende
                  1  ungültiges Laufwerk, falsche Syntax,
                     nicht fataler Lese-/Schreibfehler
                  2  Abbruch durch Benutzer (<Ctrl>+<c> etc.)
                  3  fataler Hardware-Fehler, kein Vergleich durchgeführt,
                     kann Quelle nicht lesen oder Ziel nicht formatieren/
                     schreiben
                  4  Initialisierungsfehler, zu wenig Speicher, Laufwerk
                     oder Syntax falsch

   DISKMAP.EXE   Die angelegte Datei heißt DISKMAP.DAT und ist normalerweise
                 schreibgeschützt, aber nicht versteckt. Wird die bereits
                 existierende Datei allerdings manuell versteckt, z.B. mit

                  ATTRIB diskmap.dat +h

                 so bleiben diese Attribute auch erhalten, wenn die Datei
                 beim nächsten Aufruf von DISKMAP.EXE (nächstes Booten)
                 aktualisiert wird. DISKMAP ist kein TSR wie DELWATCH.

                 Achtung: Normalerweise sollten Programme wie DISKMAP,
                 PC-Tools' MIRROR oder Norton Utilities' IMAGE mindestens
                 bei jedem Bootvorgang des Rechners aufgerufen werden, um
                 die Verweisdateien zu aktualisieren. Im Falle eines
                 schweren Fehlers in der Festplattenorganisation, der
                 nicht behoben werden kann, ohne den Rechner zunächst zu
                 booten, sollte man diese Aufrufe jedoch temporär aus
                 AUTOEXEC.BAT entfernen, damit wenigstens die letzten noch
                 gültigen Daten nicht mit einer nun fehlerhaften Struktur
                 überschrieben werden (siehe UNFORMAT.EXE).

                 Manchmal mag es sinnvoll sein, DISKMAP bei jeder Rückkehr
                 zum Prompt aufzufrischen: Dies ist unter DR DOS 6.0
                 und Novell DOS mit PROMPT $x und %PExec% möglich, siehe
                 Kapitel II.11. und IV.7.

                 Siehe auch bei DELPURGE.EXE, DELWATCH.EXE und UNDELETE.EXE
                 in Kapitel II.4.

   DISKOPT.EXE   Unterstützt Disketten, Festplatten, SuperStor-, Double-
                 Space- und STACKER-Laufwerke und stellt einen recht
                 hochentwickelten Entfragmentierer ähnlich wie COMPRESS,
                 OPTIMIZR (PC-Tools) oder SPEEDISK (Norton Utilities) dar.

                 Multitasker wie TASKMGR und Windows als auch PNW müssen
                 vor einem Optimierungslauf beendet werden. Ein laufender
                 PNW-Server kann beim Start von DISKOPT automatisch de-
                 aktiviert werden (Frage J/N).
                 DISKOPT ist kompatibel mit allen gängigen Cache-Programmen
                 wie NWCACHE, NLCACHE, SMARTDRV 3.xx und 4.xx, PC-CACHE,
                 Norton-CACHE, HyperDisk und PC-Kwik und deaktiviert diese
                 Programme (inkompatible Cache-Programme sollten vorher
                 beendet werden).
                 Werden alte STACKER-Formate erkannt, können diese in ein
                 aktuelles und effektiveres Format umgewandelt werden.

                 Besitzt ein eingebautes Hilfesystem.

                 Zusätzliche unbekannte oder undokumentierte Parameter:

                 /RESTORE=[laufwerk:]\STACVOL.EXT stellt das STACKER-
                           Laufwerk wieder her, falls die Optimierung
                           durch Neustart oder Stromausfall unterbrochen
                           wurde (und das Laufwerk nicht aktiviert wird).

                 Undokumentierte Parameter (wie von MS-DOS DEFRAG), nur in
                 Verbindung mit STACKERs SDEFRAG, das intern DISKOPT mit-
                 verwendet, verfügbar (bei SDEFRAG /? sind u.a. diese
                 Parameter dokumentiert):

                 /GL       Ändert die erwartete Kompressionsrate
                 /GP       Erhöht die Größe des STACKER-Laufwerks
                 /BW       Schaltet Anzeige auf Monochrom
                 /LCD      Schaltet Anzeige auf LCD-Darstellung
                 /BATCH    Wartet nicht auf bestätigenden Tastendruck
                 /SKIPHIGH Lädt keine Daten in den oberen Speicher
                 /G0       (in Worten: "G-Null") Deaktiviert die graphische
                           Maus und den graphischen Zeichensatz (NewUI=Off)

                 Die Datei NWDOS.INI (über %NWDOSCFG%) enthält die Grund-
                 einstellungen für DISKOPT.
                 Spezielle Einstellungen für DISKOPT sind in der Gruppe
                 [DISKOPT] möglich (dies ist undokumentiert), ansonsten
                 werden die Einstellungen aus der Default-Gruppe [COLORS]
                 übernommen:

                  CurrentColor=
                  NewUI=on|off

                 Die offiziell vorhandene Einstellung [DISKOPT] MapColor=
                 scheint hingegen in der derzeitigen Ausgabe von DISKOPT.EXE
                 keine Bedeutung mehr zu haben.
                 Außerdem wird die Direktive [COLORS] ColorSetX= ausgewertet
                 (X=<CurrentColor> aus 1..9).

                 DISKOPT verschiebt keine Dateien mit gesetztem Hidden- oder
                 System-Attribut.

                 Nach einem Lauf von DISKOPT können nur noch solche Dateien
                 mit UNDELETE wiederhergestellt werden, die in der Lösch-
                 verfolgung von DELWATCH etc. lagen. Normal gelöschte
                 Dateien werden beim Umstrukturieren der Platte über-
                 schrieben, unter der Kontrolle von DELWATCH gelöschte
                 Dateien werden jedoch nicht sofort gelöscht, sondern sind
                 nur für normale Programme nicht mehr sichtbar. Auf diese
                 Weise werden sie aber bei derartigen Umstrukturierungen
                 wie existierende Dateien behandelt und daher umkopiert
                 statt überschrieben.

                 Sicherheitshalber sollten Sie nach einem DISKOPT-Lauf
                 den Rechner neu booten (insb. wenn Sie FASTOPEN= verwenden)
                 und DISKMAP aufrufen, um die Verweisdatei zu aktualisieren.

                 Anscheinend gibt es eine optionale Datei DISKOPTJ.EXE, die
                 in Verbindung mit dem Modus 'Japanisch' notwendig ist.
                 Näheres ist mir bisher unbekannt, eine japanische Ausgabe
                 von Novell DOS konnte ich bisher noch nirgendwo entdecken,
                 obwohl sie ursprünglich angekündigt wurde.

                 Achtung: DISKOPT kommt derzeit nicht mit langen Datei-
                 namen von MS Windows95 zurecht (wie sollte es auch?).
                 Caldera hat aber Abhilfe versprochen, die aber mit
                 Caldera OpenDOS 7.01 noch nicht mitgeliefert wird.

   DISPLAY.SYS   Die Aufruf-Syntax (inkl. undokumentierter Erweiterungen)
                 ist in Kapitel II.16. beschrieben.

                 Die Unterstützung für EGA-, MCGA- und VGA-Karten er-
                 fordert immer die Angabe der Option 'EGA', da die Code-
                 seitenunterstützung von DOS bisher auch keine besonderen
                 Funktionen der VGA ausnutzt (vom Font 16x8 einmal abge-
                 sehen). Ebenfalls siehe Kapitel II.16.

                 Die .CPI-Dateien von DR DOS 6.0 und Novell DOS 7 (DRFONT)
                 enthalten einen undokumentierten vierten Font 6x8. Dieser
                 theoretisch für Grafikmodi und Textmodi mit mehr als 43
                 Zeilen auf Super-EGAs, bzw. mehr als 60 Zeilen auf Super-
                 VGAs, vielleicht im Hinblick auf DR PalmDOS auch für
                 PalmTops mit speziellen reduzierten LCD-Anzeigen interes-
                 sante Font ist aber offenbar üblicherweise nicht freige-
                 schaltet, zumindest nicht explizit.

                 Die von MS-DOS her bekannten Dummy-Gerätetypen 'MONO' und
                 'CGA' unterstützt Novell DOS nicht; sie sind aber auch bei
                 MS-DOS funktionslos, schließlich bieten MDA, HGC und CGA
                 nur *einen* Hardware-Font (vgl. GRAFTABL.COM), der nicht
                 per Software änderbar ist.
                 Der Typ 'LCD' und die bei MS-DOS undokumentierten Unter-
                 typen 'EGA 8','EGA 14' und 'EGA 14M' werden nicht unter-
                 stützt (letztere aber auch nicht zurückgewiesen), dürften
                 aber sowieso obsolet sein, da man (fast) das Gleiche wohl
                 über die Angabe der zu installierenden Fonts erreichen
                 kann. Wie .CPI-Dateien von MS-DOS unter Novell DOS ver-
                 wendet werden können und wie damit dennoch die Unter-
                 stützung für 'LCD' bzw. 'EGA 8' möglich ist, wird in
                 Kapitel II.16. beschrieben.

                 Haben Sie sowohl eine MCGA/EGA/VGA-Karte als auch eine
                 MDA/HGC-Karte in Ihrem Rechner installiert, so scheitert
                 die Einrichtung der Codeseitenumschaltung für den Farb-
                 adapter, wenn das aktive Bildschirmsystem zum Zeitpunkt
                 des Aufrufs von DISPLAY.SYS die Monochromkarte ist. In
                 diesem Fall müssen Sie entweder die DIP-Schalter auf dem
                 Mainboard so stellen, daß die Farbkarte default-mäßig
                 gewählt wird oder Sie verwenden MODE, um vorher auf die
                 Farbkarte umzuschalten. Außerdem sollten Sie in diesem
                 Fall auch auf die Angabe einer Codeseite verzichten,
                 da sonst eine Fehlermeldung erscheint (siehe Kapitel
                 II.16):

                  CONFIG.SYS:

                   INSTALL=c:\nwdos\mode.com co80
                   DEVICE=c:\nwdos\display.sys con=(EGA,,(1,3))

                 ANSI-Treiber und andere Gerätetreiber für CON: sollten vor
                 DISPLAY.SYS geladen werden, damit diese den DISPLAY.SYS
                 Treiber nicht abkoppeln können.

                 Achtung: Die bei DISPLAY.SYS notwendige Angabe der Code-
                 seite bezieht sich auf die hardware-mäßig installierte
                 Codeseite (da DOS dies nicht überprüfen kann, muß diese
                 Angabe überhaupt erst vorgenommen werden). Auch wenn Sie
                 später mit Codeseite 850 etc. arbeiten wollen, sollten Sie
                 hier noch die Codeseite 437 angeben, die zumindest für
                 alle in den USA und West-Europa erhältlichen Grafikkarten
                 (BIOSe und Fonts) die Grundlage darstellt. Wenn Sie hier
                 eine andere Codeseite als die wirklich unterstützte
                 Hardware-Codeseite angeben und später nicht für *alle*
                 benötigten Codeseiten installierbare Codeseiten einrichten,
                 kann die Codeseitenunterstützung von DOS nicht sauber
                 arbeiten, da sie von falschen Voraussetzungen ausgeht.
                 Allerdings: Auch wenn die Hardware-Codeseite üblicherweise
                 mit der Codeseite 437 übereinstimmt (so daß die zusätzliche
                 Einrichtung einer installierbaren Codeseite 437 entfallen
                 kann), unterscheidet das Betriebssystem sehr wohl zwischen
                 einer Hardware- und einer installierbaren Codeseite:
                 Muß DOS eine vorbereitete Codeseite aktivieren, wird
                 der Font aus der zugehörigen .CPI-Datei geladen; bei
                 Aktivierung der Hardware-Codeseite wird der Font aus
                 dem BIOS der Grafikkarte benutzt. Die Hardware-Codeseite
                 ist unter der Nummer ansprechbar, die Sie bei DISPLAY.SYS
                 dafür angegeben haben. Fehlt die Angabe, nimmt DISPLAY.SYS
                 in Anhängigkeit von Grafikkarte und COUNTRY= Einstellung
                 pauschal eine Codeseite an, ohne dies wirklich überprüfen
                 zu können (normalerweise also 437).

                 Da die Einrichtung von Codeseiten mit zu den komplizier-
                 testen Angelegenheiten in der Konfiguration von DOS
                 gehört, seien ein paar zusätzliche Überlegungen erlaubt
                 (die mit Novell DOS 7 überprüft wurden):

                 Angenommen, die Hardware-Codeseite Ihrer Video-Karte
                 entspricht Codeseite 437 (fast immer der Fall), dann reicht
                 es meist aus, lediglich alle anderen zusätzlich benötigten
                 Codeseiten mit MODE con: CODEPAGE PREPARE vorzubereiten.
                 Die Anzahl der zu reservierenden Codeseiten bei DISPLAY.SYS
                 entspricht dann dieser Zahl der zusätzlichen Codeseiten.
                 Selbstverständlich können Sie auch die Codeseite 437 be-
                 nutzen, obwohl sie nicht extra vorbereitet wurde; DOS
                 schaltet dann einfach auf die Hardware-Codeseite um. Für
                 den Fall, daß Sie zusätzlich nur noch Codeseite 850 be-
                 nötigten (und dabei alle Fontgrößen), sähe die Konfigura-
                 tion etwa wie folgt aus (natürlich kann man den Treiber
                 auch hochladen):

                  CONFIG.SYS:

                   DEVICE=c:\nwdos\display.sys con=(EGA,437,(1,3))

                  AUTOEXEC.BAT:

                   MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
                   CHCP 437

                 Wenn Sie jedoch auch eine andere *Darstellung* der Code-
                 seite 437 wünschen, als sie in Ihrem Video-BIOS-EPROM
                 eingebrannt ist, können Sie die Codeseite 437 durch einen
                 Font aus einer .CPI-Datei ersetzen. Natürlich wird für
                 diesen Font eine vorzubereitende Codeseite veranschlagt,
                 was zusätzlichen Speicherplatz kostet. Angenommen, Sie
                 möchten die Darstellung der Codeseite 437 durch eine
                 andere Darstellung (z.B. einen ISO-Font) ersetzen und
                 zusätzlich noch mit der Codeseite 850 arbeiten, dann
                 müssen Sie jetzt zwei Codeseiten vorbereiten (437 und 850).
                 Die Hardware-Codeseite, die Sie - entsprechend obigen An-
                 weisungen - ebenfalls als Codeseite 437 deklariert hatten,
                 ist in dieser Konstellation nicht mehr erreichbar.
                 Im Beispiel:

                  CONFIG.SYS:

                   DEVICE=c:\nwdos\display.sys con=(EGA,437,(2,3))

                  AUTOEXEC.BAT:

                   MODE con: CODEPAGE PREPARE=((437,850) c:\nwdos\ega.cpi)
                   CHCP 437

                 Allerdings hält Sie niemand davon ab, als Kennung der
                 Hardware-Codeseite einfach eine andere Nummer als 437
                 anzugeben (die noch nicht einmal einer gültigen Codeseiten-
                 Kennung entsprechen muß). Erlaubt sind alle Zahlen von
                 0..32767. (32768..65535 sind eigentlich auch gültig, aber
                 MODE gibt diese Nummern später als negative Zahlen aus.)
                 Die Hardware-Codeseite können Sie dann später unter dieser
                 Nummer (cp) mit

                  MODE con: CODEPAGE SELECT=cp

                 erreichen, auch wenn die wahre Kennung der Hardware-Code-
                 seite (natürlich immer noch 437, schließlich hat sich
                 am EPROM-Inhalt nichts geändert) mit einer vorbereiteten
                 Codeseite überdeckt wurde. (Allerdings wird der Hardware-
                 Font nicht in allen Fällen reaktiviert, sondern offenbar
                 nur initialisiert. Näheres hierzu ist noch nicht geklärt.)
                 In obigen Beispiel:

                  CONFIG.SYS:

                   DEVICE=c:\nwdos\display.sys con=(EGA,999,(2,3))

                  AUTOEXEC.BAT:

                   MODE con: CODEPAGE PREPARE=((437,850) c:\nwdos\ega.cpi)
                   CHCP 437

                 Anmerkung: In diesem Beispiel habe ich für diese Dummy-
                 Kennung die Nummer 999 verwendet, weil diese Kennung mit
                 keiner existierenden Codeseiten-Nummer kollidiert und
                 obendrein bei Novells KEYB intern für benutzerdefinierte
                 Codeseiten reserviert ist und insofern ganz gut paßt.
                 Wie gesagt, jede beliebige Nummer ist erlaubt, da DOS
                 sowieso nicht überprüfen kann, ob die Hardware-Codeseite
                 wirklich zu dieser Nummer gehört oder nicht.

                 Aufgrund des höheren Speicherplatzbedarfs sollten die
                 zweite und dritte Alternative allerdings nur verwendet
                 werden, wenn Sie aus gutem Grund auch die Darstellung
                 des Fonts 437 verändern wollen, z.B. bei Verwendung
                 fremder .CPI-Dateien mit anderen Schriftarten, etwa wie
                 ISO-, Kursiv- oder Schreibschriften etc. Natürlich möchten
                 Sie dann die geänderte Darstellung der Schriften nicht
                 nur in den zusätzlichen Codeseiten genießen, sondern auch
                 mit Codeseite 437... Den Hardware-Font aus dem Video-BIOS
                 mit einer gleichwertigen oder gar binär identischen Font-
                 Darstellung aus einer .CPI-Datei zu überladen, ist reine
                 Speicherplatzverschwendung. Näheres hierzu auch bei
                 MODE.COM in diesem Kapitel.

                 Der Speicherbedarf von DISPLAY.SYS gliedert sich in
                 mehrere Bereiche und hängt auch von der Anzahl der zu
                 installierenden Fonts und vorzubereitenden Codeseiten ab:

                     Fonts:          Zahl der vorzubereitenden Codeseiten:
                                          1            2            3    ...
                     (6x8)           (5168 Bytes) (7728 Bytes) (10288 Bytes)
                  1:                 (+1536=)   (+2*1536=)   (+3*1536=)
                     8x8               6704 Bytes  10800 Bytes  14896 Bytes
                  2:                 (+2048=)   (+2*2048=)   (+3*2048=)
                     8x8, 14x8         8752 Bytes  14894?Bytes  21040 Bytes
                  3:                 (+3584=)   (+2*3584=)   (+3*3584=)
                     8x8, 14x8, 16x8  12336 Bytes  22064 Bytes  31792 Bytes

                 davon enthalten die eigentlichen Font-Daten pro Codeseite:

                     (6x8)            :                     (1536 Bytes)
                     8x8              : 2048               = 2048 Bytes
                     8x8, 14x8        : 2048 + 3584        = 5632 Bytes
                     8x8, 14x8, 16x8  : 2048 + 3584 + 4096 = 9728 Bytes

                 Wie Sie sehen können, lassen diese Daten übrigens darauf
                 schließen, daß der jeweils größte Font überhaupt nicht
                 innerhalb dieser Datenstruktur definiert wird, sondern
                 offenbar innerhalb des Grafikkarten-RAMs abgelegt wird
                 (das müßte es erlauben, eine eigene Darstellung eines
                 Fonts der Codeseitenunterstützung unterzuschieben, indem
                 man den Fontbereich der Grafikkarte direkt mit einem
                 eigenen Font beschreibt (nicht überprüft)) und daß der
                 Font 6x8 tatsächlich geladen wird.
                 Und: Der Speicherbedarf von DISPLAY.SYS ist trotzdem bei
                 mehr als einer vorzubereitenden Codeseite ganz beträcht-
                 lich, so daß hier noch Optimierungsspielraum insofern
                 bestünde, daß die gerade nicht benötigten Daten ausge-
                 lagert würden (z.B. XMS, EMS oder Festplatte).

                 Die gleichen Prinzipien lassen sich übrigens auch auf
                 PRINTER.SYS und .CPI-Dateien für Drucker anwenden, sind
                 dort allerdings erheblich sinnvoller, wenn auch noch
                 komplizierter zu verwenden, sobald Sie andere als die
                 standardmäßig unterstützten Drucker ansteuern möchten.
                 Weitere Informationen finden sich bei PRINTER.SYS und
                 in Kapitel II.16.

   DOSBOOK.EXE   Das Online-Handbuch zu Novell DOS - DOSBOOK - dürfte
                 normalerweise keine Bedienungsprobleme aufwerfen. Hat man
                 sich jedoch mit Querverweisen immer tiefer verschachtelte
                 Informationen durchgelesen und möchte nun zum jeweiligen
                 Hauptkontext (Inhalt, Glossar, Index) zurück, um dort das
                 nächste Thema anzuschauen, so wählen viele Benutzer aus
                 Unwissen die langsame Methode (<Alt>+<z> für 'Zurück'),
                 um sich Schritt für Schritt zurückzuhangeln.
                 Stattdessen ist es viel einfacher, in das Hilfe-Menü zu
                 gehen (<Alt>+<h>) und dort eines der drei Hauptgebiete
                 anzuwählen. DOSBOOK verzweigt dann direkt zum passenden
                 Eintrag des aktuellen Themas im gewählten Hauptkontext.
                 Z.B. findet <Alt>+<h>-<a> (für 'Inhalt') wirklich die
                 Stelle im Kontext 'Inhalt', die das aktuelle Thema
                 behandelt.

                 Die Datei NWDOS.INI enthält in der Gruppe [DOSBOOK] die
                 Grundeinstellungen des Hilfesystems:

                  InitialZoom=1   # 0=Fenster, 1=Vollbild
                                  #
                                  # DOSBook-Druckereinstellungen:
                                  #
                  PrintDevice=PRN # Druckergerätename
                  LeftMargin=8    # Anzahl leerer Spalten links vom Text
                                  # im Ausdruck (Rand für Heftung).
                  TextColumns=64  # Anzahl der Textspalten im Ausdruck.
                                  # Für breite Drucker oder Ausdrucke im
                                  # Querformat können Sie hier auch
                                  # wesentlich höhere Werte angeben.
                  LinesPerPage=62 # Verwenden Sie 0 für: Kein Seitenumbruch
                                  # im Ausdruck.
                  Underline1=45   # Zeichencode für Einzelunterstreichung
                                  # im Ausdruck, hier '-'.
                  Underline2=61   # Zeichencode für Doppelunterstreichung
                                  # im Ausdruck, hier '='.

                 sowie in [DOSBOOK] (hier undokumentiert) oder in [COLORS]

                  CurrentColor=
                  NewUI=on|off

                 Außerdem wird die Einstellung ColorSetX= aus [COLORS] aus-
                 gewertet (X=<CurrentColor> aus 1..9). Offenbar gibt es auch
                 noch eine Direktive OLHfile= für eine externe Hilfedatei
                 und eine Gruppe [DRDOS] (näheres ist noch nicht geklärt).
                 Eine meines Erachtens besonders angenehme Farbeinstellung
                 für das DOSBOOK finden Sie in Kapitel II.19.

                 Noch ein Hinweis:

                 Leider sind nicht alle Links im DOSBOOK korrekt, außerdem
                 fehlen manche wenige Optionen und Befehle komplett (z.B.
                 BACKUP und RESTORE). Deshalb sollte man in jedem Fall auch
                 'befehl /?' aufrufen, wo meist alle offiziellen Parameter
                 angezeigt werden.

                 Errorlevel (unvollständig):

                  0  alles ok
                 31  Syntax-Fehler in Parameter

   DOSKEY.EXE    Dieses TSR zur erweiterten Kommandozeileneditierung ent-
                 spricht in seinem Verhalten fast 100% dem Gegenstück von
                 MS-DOS (DR DOS/Novell DOS bot und bietet für Kommando-
                 zeileneditierung zusätzlich noch die HISTORY= Funktion ab
                 CONFIG.SYS an, die bei MS-DOS erst mit DOSKEY bereitge-
                 stellt wird, entsprechend bezieht sich die /B[UFSIZE]
                 Option auch nur auf den Makropuffer und nicht auch auf
                 den Kommandozeilenpuffer, wie im DOSBOOK fälschlicherweise
                 angegeben, vgl. Kapitel III.1. und II.12.).
                 In der deutschen Ausgabe zu Novell DOS gibt es eine
                 Datei LIESMICH.TXT, die darauf hinweist, daß die Kommando-
                 zeilenparameter von DOSKEY auch abgekürzt werden können.
                 Im DOSBOOK wird die Langform beschrieben, die zwar nicht
                 zurückgewiesen wird, in Wahrheit aber auch nicht komplett
                 ausgewertet wird, d.h. wenn der erste Buchstabe des Para-
                 meters stimmt, wird die Option schon akzeptiert.

                 Die Option /R[EINSTALL] löscht bei Novell nur alle
                 Makros, eine neue Kopie von DOSKEY wird nicht geladen.

                 Neben den in der Dokumentation beschriebenen Token $t,
                 $T (vgl. <Ctrl>+<t> in Kapitel II.11.), $l (das im der
                 deutschen Ausgabe des DOSBOOKs übrigens fälschlicher-
                 weise als $I beschrieben wurde), $L, $b, $B, $1..$9
                 funktionieren natürlich auch die anderen von MS-DOS/
                 PC-DOS bekannten Token:

                 $$   für das '$' Zeichen selbst
                 $*   für *alle* Parameter, d.h. $1 $2 $3 $4 $5 $6 $7 $8 $9

                 Zusätzlich bietet Novells DOSKEY undokumentiert noch:

                 $0   analog zum eigenen Programmnamen %0, hier also der
                      eigene Makroname.

                 Da die Dokumentation zu DOSKEY sehr lückenhaft ist, hier
                 noch ein paar Anmerkungen:

                 Mit DOSKEY ist es möglich, Aliase und Makros zu definieren,
                 dabei können auch interne Kommandos redefiniert werden.
                 Möchte man zwischenzeitlich zwischen dem Original und dem
                 Makros/Alias unterscheiden, gibt es dazu die von MS-DOS
                 bekannte Methode, dem Kommando Leerfelder voranzustellen
                 (ein vorangestelltes '@'-Zeichen muß trotzdem weiterhin
                 in der ersten Spalte stehenbleiben).
                 Nur Kommandos, die in der ersten Spalte beginnen, werden
                 ggf. als Makro/Alias ausgewertet, eingerückte Kommandos
                 immer als Originalbefehl (wichtig in Batchjobs, wenn man
                 ein bestimmtes Verhalten sicherstellen muß). (Leider
                 stimmt diese Regel für Novells Implementation nicht ganz,
                 Ausnahmen siehe unten.)

                 Interessanterweise kann man bei Novells COMMAND.COM den
                 *internen* Befehlen aber auch ein Zeichen aus '.', ';',
                 '+' und '=' voranstellen (etwa =DIR), das genauso wie ein
                 Leerfeld wirkt, solange es kein Makro/Alias gibt, das
                 ebenfalls dieses Zeichen im Befehlsnamen hat. Da hier
                 eine Reihe Fallstricke existieren und 4DOS z.B. etwas
                 anders reagiert, sei auf die ausführlicheren Hinweise
                 in Kapitel II.11. verwiesen.

                 Novells DOSKEY v0.01 hat allerdings derzeit auch noch
                 ein paar Designschwächen (Update 15):

                 - Leider funktioniert die Unterscheidung zwischen Makro/
                   Alias und Originalkommando anhand der Position in der
                   Eingabezeile bei Novell nicht ganz genauso wie bei
                   MS-DOS. Bei *internen* Kommandos kann man direkt am
                   Prompt das Originalkommando *nicht* durch ein voran-
                   gestelltes Leerfeld erreichen (als Workaround ist hier
                   allerdings z.B. ein vorangestelltes Gleichheitszeichen,
                   etwa =DIR *.* möglich). In den anderen Fällen ist das
                   Verhalten identisch.

                 - Geben Sie bei einem Makro niemals mehr als 9 Parameter
                   an, denn Parameter 10 und darüber hinaus werden auf die
                   Parameter 0 usw. zurückgefaltet, die dadurch zerstört
                   werden. Die Resultate sind völlig konfus.

                 - Das Zeichen direkt nach einem $ wird immer verschluckt,
                   auch wenn es sich nicht um ein Token handelt (ist aller-
                   dings sinnvoll, um die Kompatibilität mit zukünftigen
                   Erweiterungen zu sichern).

                 - Die Makroexpandierung arbeitet nicht, wenn der Kommando-
                   prozessor 4DOS/NDOS ist, dies gilt auch für COMMAND.COM
                   von MS-DOS. In einer temporär geladenen Kopie von
                   COMMAND.COM funktioniert allerdings alles einwandfrei.
                   4DOS bietet aber gleichwertige Ersatzfunktionen an. Wenn
                   Sie also nicht unbedingt die Kompatibilität mit DOSKEY
                   wahren müssen, brauchen Sie DOSKEY mit 4DOS/NDOS über-
                   haupt nicht zu laden.

                 - Dem '!' kommt eine Sonderfunktion als Alias für $T zu
                   und deshalb kann es nicht als normales Zeichen ver-
                   wendet werden, bzw. wird es doch verwendet, so dient es
                   als Trenner zwischen Kommandos.
                   Unter CCI Multiuser DOS ist das '!'-Zeichen in Dateinamen
                   nicht erlaubt (CCI Multiuser DOS 7.22 Gold), daher kann
                   die hier beschriebene Funktion als Trenner auch an der
                   Kommandozeile von MDOS.COM/TMP.EXE verwendet werden
                   (siehe Kapitel II.20.). Unter normalem DOS ist das
                   Ausrufezeichen aber ein gültiges Zeichen für Dateinamen,
                   daher unterstützt Novells COMMAND.COM nach außen hin
                   diese Funktion nicht! Intern arbeiten aber alle
                   COMMAND.COM Versionen der ehemaligen Digital Research
                   Linie mit dieser speziellen Funktion (schauen Sie sich
                   diesbezüglich einfach mal den Beginn von COMMAND.COM mit
                   einem Dump-Betrachter an:
                   Sie werden eine gewisse Parallele bei !date!time für den
                   Start von COMMAND.COM ohne AUTOEXEC.BAT entdecken.)
                   Partielle Möglichkeiten, mehrere Kommandos in einer
                   Zeile anzugeben, werden in Kapitel II.11. beschrieben.

                 - DOSKEY hat mit MS-DOS 7 eine Reihe mehr oder weniger
                   sinnvolle Erweiterungen erfahren, die dem 1,5 Jahre
                   früher eingeführten Novell DOS 7 natürlich noch fremd
                   sind. Zumindest die Möglichkeit eines erweiterten
                   Tastaturpuffers kann aber nach wie vor wesentlich
                   effektiver von dem erweiterten Tastaturtreiber K3PLUS
                   bzw. FreeKEYB bereitgestellt werden.

   DPMI.EXE      Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok
                  1  Aufruf von DPMI ohne Parameter bei deaktiviertem
                     DPMI (z.B. vorheriges DPMS off).

   DPMS.EXE      DPMS.EXE (Novells DOS Protected Mode Services - eine Art
                 Protected Mode DOS-Extender/-Server für TSRs) funktioniert
                 mit Prozessoren ab 286er und sollte normalerweise unmittel-
                 bar nach den anderen Speichermanagern per DEVICE= geladen
                 werden. Je nach vorhandener CPU wird entweder ein 286er-
                 Overlay oder ein 386er-Overlay (derzeit auch für höhere
                 Prozessoren) eingebunden. Unterstützt auch 32Bit-Protected-
                 Mode-Anwendungen. Der Treiber enthält auch einen virtuellen
                 Gerätetreiber für MS Windows (der evtl. für DOS-Boxen be-
                 nötigt wird, wenn dort Programme DPMS nutzen wollen???).

                 Es ist sogar möglich, DPMS.EXE erst in AUTOEXEC.BAT oder
                 später (bzw. per INSTALL= in CONFIG.SYS) zu laden. Obwohl
                 die Funktionalität identisch ist, erscheint das logische
                 Gerät DPMSXXX0 nur beim Laden als Gerätetreiber (siehe
                 Kapitel IV.3.). Da in lezterem Fall auch der Speicher-
                 bedarf geringfügig niedriger ist, empfiehlt sich in
                 jedem Fall das Laden als Gerätetreiber.

                 DPMS.EXE kann nicht hochgeladen werden. Sehr frühe
                 Versionen (noch vor Update 3) konnten zwar hochgeladen
                 werden, führten aber nur zum Absturz des Rechners, da
                 das Hochladen des Treibers schon damals nicht zulässig
                 war und nur nicht abgefangen wurde. Heutzutage alloziert
                 der Treiber während der Initialisierung absichtlich so
                 viel Speicher, daß kein Speichermanager ihn hochladen
                 kann...

                 Der Real Mode Stub des Treiber benötigt ca. 1 KByte (je
                 nach Treiberversion und geladenem Overlay 0,7 - 1,4 KByte)
                 im konventionellen Speicher, die sich - in Anbetracht des
                 enormen Speichergewinns bei DPMS-nutzenden TSRs - allemal
                 lohnen, geopfert zu werden.

                 Mit der Version 1.42 aus dem Update 14 traten auf
                 verschiedenen Testsystemen Probleme auf. Ich empfehle
                 daher entweder die Version 1.41 aus Update 13 oder die
                 neue Version 1.43 aus Update 15. Näheres siehe Kapitel I.2.

                 DPMS.EXE (zumindest die Version 1.43 aus Update 15)
                 unterstützt offenbar zwei undokumentierte Parameter,
                 deren Funktion noch nicht geklärt ist (der SwitChar ist
                 optional):

                  /N       ???
                  /O       ??? DPMS installiert nicht, scheint wie OFF zu
                               wirken.
                  /O=wert  ??? Eine Wertangabe wird nicht zurückgewiesen,
                               Funktion unbekannt ('Overlay'???).

                 Die folgenden Parameter sind zwar offensichtlich, aber im
                 DOSBOOK und der Online-Hilfe nicht erwähnt:

                  /OFF     deaktiviert DPMS-Funktionen für zu ladende TSRs.
                  /ON      reaktiviert DPMS wieder. Bereits geladene DPMS-
                           nutzende TSRs können natürlich weiterhin den
                           DPMS-Service nutzen.

                 Die Option "EMS=0" des Speichermanagers 386MAX ist nicht
                 DPMS-kompatibel. Stattdessen muß man 386MAX so umkon-
                 figurieren, daß die NOFRAME-Option verwendet wird.

                 "Und was nützt der ganze Aufwand für die Programmierung
                 von DPMS-aware TSRs, wenn nur Novell DOS 7 diesen Standard
                 unterstützt?" - Da haben Sie sich aber getäuscht!

                 Bei IBM PC-DOS 7 liegt (wohl nur wegen des dort mitge-
                 lieferten STACKER 4) nun ebenfalls ein DPMS-Treiber bei,
                 der kompatibel zu Novells DPMS ist. Allerdings sollte man
                 auch für PC-DOS 7 einen aktuell upgedateten Treiber von
                 Novell verwenden, da dieser wesentlich kleiner ist und
                 besser arbeiten soll. Es sieht so aus, als ob auch PTS/DOS
                 (alias S/DOS) DPMS nutzen kann und auch Caldera OpenDOS
                 unterstützt DPMS.

                 Helix Software entwickelte ebenfalls um 1993-1994 einen
                 Protected Mode TSR-Server namens CLOAKING (im Deutschen
                 etwas unglückliche Wortwahl, bedeutet allerdings soviel
                 wie 'Ummanteln' oder 'Tarnen') zum Auslagern ihrer
                 Netzwerk-Software ins Extended Memory. Der Hauptteil der
                 CLOAKING-nutzenden Treiber läuft dann im Protected Mode
                 und nur ein kleiner Stummel (der Stub) bleibt zur Kommuni-
                 kation mit DOS im Real Mode Adreßraum (sowohl der Stub des
                 Servers als auch der der TSRs können hochgeladen werden;
                 bei Novells DPMS muß der Stub des Servers im 640 KByte-
                 Bereich liegen). Helix entwickelte in Zusammenarbeit
                 mit Award auch CLOAKING-nutzende BIOSe und bietet den
                 CLOAKING.EXE Treiber auch für andere TSRs an. So unter-
                 stützt z.B. der Logitech-Maustreiber aus MouseWare 6.50+
                 das CLOAKING-API und benötigt so statt 27 KByte nur noch
                 1 KByte im ersten MegaByte!

                 "Ok, nun gibt es also zwei verschiedene Standards (DPMS und
                 CLOAKING) für denselben Zweck, TSRs aus dem DOS-Speicher
                 nahezu komplett auszulagern und die Vorteile des Protected
                 Mode nutzen zu können?!?"
                 Im Prinzip haben Sie Recht und es ist sicherlich aufwendig,
                 beide APIs in Ihren TSRs zu unterstützen (abgesehen davon,
                 daß es schon schwierig genug ist, überhaupt erst einmal ein
                 DPMS-SDK zu bekommen, obwohl es nicht sehr teuer ist.
                 Letzteres Problem ist mit der Übernahme von DR DOS durch
                 Caldera nun endlich gelöst...).

                 Aber: Der Helix CLOAKING.EXE Treiber (getestet Version
                 2.01 auf 386ern bis Pentiums mit EMM386 /MULTI=on /DPMI=on;
                 CLOAKING funktioniert offenbar nicht mit 286ern) unter-
                 stützt undokumentiert auch das API von DPMS (meldet sich
                 als DPMS 1.00 OEM "HELIX")!!! Dabei wird der integrierte
                 DPMS-Server selbst zum CLOAKING-nutzenden Treiber und der
                 CLOAKING-Stub benötigt nach wie vor nur 1 KByte konven-
                 tionellen Speicher!
                 Wird während der Installation von CLOAKING.EXE kein DPMS-
                 Server erkannt, so stellt CLOAKING.EXE die DPMS-Funktionen
                 default-mäßig selbst zur Verfügung. Dieser 'Cloaked DPMS-
                 Server' kostet nur ca. 100 Bytes im ersten MegaByte. Mit
                 der undokumentierten CLOAKING-Option /NODPMS kann man ver-
                 hindern, daß DPMS-Support eingebunden wird. Obwohl Sie
                 auch beide Treiber (DPMS.EXE und CLOAKING.EXE) laden
                 können (sollte es tatsächlich einmal Probleme geben),
                 reicht es deshalb normalerweise völlig aus, nur noch den
                 CLOAKING.EXE Treiber zu laden. Die DPMS-nutzenden TSRs
                 (von Novell DOS und PC-DOS etc.) können damit genauso gut
                 arbeiten, wie mit ihrem Original... Das gilt insbesondere
                 auch bei Benutzung von MS Windows 3.xx in allen Betriebs-
                 arten, obwohl CLOAKING im Gegensatz zu DPMS keinen
                 virtuellen DPMS-Gerätetreiber bereitstellt.

                 Lediglich Novells TASKMGR kommt als Multitasker an-
                 scheinend mit CLOAKING nicht zurecht: Sobald CLOAKING.EXE
                 geladen wird, stürzt er meist ab (egal, ob DPMS aktiviert
                 ist oder nicht, und unabhängig davon, von welchem Treiber
                 es zur Verfügung gestellt wird). Etwas stabiler wurde der
                 Multitasker ohne geladenen DPMS-Treiber und erst in
                 AUTOEXEC.BAT geladenem CLOAKING-Treiber (mit der Option
                 /NOSHAREV86). Wer hier der Schuldige ist (CLOAKING oder
                 TASKMGR), und ob evtl. doch noch Abhilfe in Sicht ist,
                 ist noch nicht geklärt. Hinweise willkommen!
                 Und in einer extrem unüblichen Konstellation bereitet auch
                 der PNW 1.0 SERVER.EXE manchmal Probleme, wenn er in einer
                 DOS-Box unter Windows geladen wird (siehe Kapitel VI.2.)
                 und DPMS dabei von CLOAKING zur Verfügung gestellt wird.
                 Lädt man jedoch CLOAKING über DPMS treten diese Probleme
                 nicht auf. Vielleicht gibt es ja auch schon ein Update für
                 CLOAKING.EXE (Version 2.01 von 1994)?

                 Wird der DPMS-Support von CLOAKING bereitgestellt, sollte
                 man auf keinen Fall "DPMS.EXE off" eingeben, um den DPMS-
                 Support abzuschalten. In diesem Fall kommt Helix' DPMS-
                 Treiber durcheinander (schaltet evtl. wirklich komplett ab)
                 und DPMS-nutzende Applikationen stürzen ab. Da dies auch
                 kritische Programme wie NWCACHE etc. betrifft, besteht
                 große Gefahr für die Integrität des Dateisystems, wenn Sie
                 nicht sofort neu booten!

                 Fazit: Wenn Sie DPMS-nutzende Treiber entwickeln, unter-
                 stützen Sie automatisch beide Standards und befinden sich
                 keineswegs in einer Sackgasse, sondern auf der sicheren
                 Seite! Na, denn los...

                 Infos zu DPMS und CLOAKING gibt's auch in Ralf Browns
                 Interrupt-Liste.

   DRIVER.SYS    Siehe auch bei DRIVPARM= in Kapitel III.1.

   EDIT.COM      Dieser Editor stellt (wenn Sie nicht QEDIT oder TSE ein-
                 setzen) eine sehr leistungsfähige Alternative zu vielen
                 anderen Editoren dar.

                 Die Grundkonfiguration wird der Datei NWDOS.INI über
                 %NWDOSCFG% entnommen:

                 Wenn nicht durch Einstellungen aus der undokumentierten
                 Gruppe [EDITOR] übersteuert, werden die Einstellungen der
                 Default-Gruppe [COLORS] ausgewertet (Achtung: Die Gruppe
                 [EDITOR] wird auch von PNW 1.0 NET.EXE verwendet, siehe
                 Kapitel VI.9.):

                 NewUI=on|off Pseudografikdarstellung ein/aus
                              (Unterstützung für einige spezielle VGA-
                              Karten ist in EDIT implementiert.)
                 CurrentColor=
                 ColorSetX=

                 Direktiven, die jedoch (auch) in [EDITOR] vorkommen,
                 übersteuern die jeweilige Einstellung aus der Gruppe
                 [COLORS] (ColorSetX= kann nur in [COLORS] vorkommen,
                 X=<CurrentColor> aus 1..9). Eine meines Erachtens
                 besonders angenehme Farbeinstellung für EDIT finden
                 Sie in Kapitel II.19.

                 Falls das 'NewUI' benutzt wird, so definiert EDIT einige
                 Zeichen des ASCII-Zeichensatzes um, um die pseudographische
                 Darstellung zu ermöglichen. Sie sollten sich also nicht
                 wundern, warum z.B. die Zeichen '+' (ASCII-180), '+'
                 (ASCII-193), '+' (ASCII-194) und '+' (ASCII-195) anders
                 als erwartet aussehen. Mit einigen Cirrus-VGA-Adaptern
                 soll es zu Problemen kommen, aber glücklicherweise kann
                 man bei Bedarf die herkömmliche Darstellung (NewUI=Off)
                 mittels der Option EDIT /N wählen, auch ohne dafür die
                 generelle Einstellung in der Konfigurationsdatei ändern
                 zu müssen. Falls Ihnen EDIT zu langsam erscheint, können
                 Sie auf diese Weise auch die Geschwindigkeit steigern.

                 Für die OS-Shell wird über %ComSpec% der zugehörige
                 Kommandoprozessor (meist COMMAND.COM) geladen, vgl.
                 Kapitel IV.7. Dabei wird dem Prompt über %Prompt% eine
                 '[EDIT]' Zeichenkette vorangestellt, so daß man nicht
                 vergißt, daß man in einer temporären Shell arbeitet.
                 Für den integrierten Hilfeverweis zu DOSBOOK muß die
                 Datei DOSBOOK.EXE auffindbar sein, die allerdings nur
                 benutzt, aber nicht direkt ausgeführt wird.

                 Die umfangreichen Editiermöglichkeiten von EDIT sollten
                 Sie sich nicht entgehen lassen und die entsprechende
                 Dokumentation wirklich durchlesen.

                 Innerhalb des Editors sind die üblichen WordStar-<Ctrl>-
                 Tastenkombinationen erlaubt. Da verschiedentlich behauptet
                 wurde, EDIT würde keine Möglichkeit besitzen, Dateien unter
                 einem neuen Namen zu speichern, hier die entsprechenden
                 Tastenkombinationen... (aber dies ist noch lange nicht
                 alles, was dieser Editor zu bieten hat):

                  <Ctrl>+<k>-<b>  Blockanfang markieren.
                  <Ctrl>+<k>-<k>  Blockende markieren.
                  <Ctrl>+<k>-<w>  Block schreiben (fragt nach Dateiname)
                                  Dies ist sogar als eigener Menüpunkt
                                  unter dem Menü 'Block' vorhanden!

                 Interessant ist, daß EDIT während des Editierens sowohl
                 die aktuelle Spaltenposition als auch die absolute Position
                 innerhalb der Datei (*Zeichen*) anzeigt, eine manchmal
                 wichtige Information, die selten offeriert wird (vgl.
                 COMP.COM und FC.COM in diesem Kapitel). Leider haben die
                 Entwickler darüber scheinbar vergessen, die aktuelle
                 *Zeilen*position anzuzeigen, ein Mißstand, der hoffentlich
                 in einem zukünftigen Update noch ausgebessert wird (zu-
                 mindest intern ist dafür schon beim EDITOR von DR DOS 6.0
                 die entsprechende Meldung *Zeile* vorbereitet).

                 Aus Sicherheitsgründen erlaubt EDIT nicht das Editieren
                 von Dateien mit der Endung .BAK. Diese müssen ggf. vorher
                 umbenannt werden. Ist eine bereits existierende Datei
                 (oder deren Sicherung mit der Endung .BAK) schreibge-
                 schützt, so meldet EDIT direkt beim Start, daß die Datei
                 zwar betrachtet, nicht aber editiert werden kann.
                 Ggf. müssen Sie das Read-Only-Dateiattribut vorher
                 mit ATTRIB -R entfernen, oder - umgekehrt - können Sie
                 das Editieren von vornherein verhindern, indem Sie das
                 Attribut setzen.

                 Interessant ist auch, daß EDIT im Prinzip keine Probleme
                 mit großen Dateien (mehr als 64 KByte) hat (sollte heut-
                 zutage eigentlich selbstverständlich sein, ist es aber
                 nicht, wie die Praxis immer wieder zeigt) und auch Texte
                 mit mehr als 255 Zeichen pro Zeile problemlos anzeigen
                 kann: Es wird zwar offensichtlich keine virtuelle
                 Speicherverwaltung eingesetzt (evtl. aber EMS), aber
                 solange der verfügbare Speicherplatz auf dem Temporär-
                 laufwerk (das über %Temp% referenziert wird) für zwei
                 temporäre Dateien namens ED??????.$$$ ausreicht, gibt
                 es wohl keine Grenze (evtl. wurde bei DR DOS 6.0 EDITOR
                 zusätzlich auch noch eine Datei EDCONFIG.$$$ erzeugt).
                 Jedenfalls konnte ich mehrere MByte große Dateien
                 editieren, die sogar Zeilen mit mehr als 1024 Zeichen
                 enthielten. Erst wenn der Platz auf dem Temporärlaufwerk
                 nicht für die komplette Datei ausreicht, wird EDIT unge-
                 mütlich: Wenn man beim Editieren an die entsprechende
                 Grenze stößt, erscheint dauernd die Meldung 'Diskette/
                 Platte voll' und auch das rückwärtige Editieren ist nicht
                 mehr einwandfrei möglich (in manchen Fällen wird sogar die
                 Mausunterstützung deaktiviert). Wenn Sie Sinn für Humor
                 haben, versuchen Sie einfach einmal, eine solche Datei mit
                 EDIT von MS-DOS bis einschließlich 6.22 zu laden...

                 In diesem Zusammenhang gibt es auch einen schweren Bug in
                 EDIT (getestet bis zum Update 15 von Dezember 1996, mit
                 dem Update 15 von Januar 1996 konnte ich das Verhalten
                 bisher nicht mehr reproduzieren):

                 Wenn man eine geänderte Datei zurückschreiben will,
                 bekommt die alte Datei zunächst die Endung .BAK, danach
                 wird die neue Datei zurückgeschrieben. (Eine bereits
                 existierende .BAK-Datei wird zunächst gelöscht, daher
                 können mit DELWATCH /B:nnn auch mehrere Versionen der
                 Dateien in der Löschverfolgung gehalten werden).
                 Dies funktioniert normalerweise wunderbar, auch bei
                 riesigen Dateien. Reicht allerdings der Platz auf dem
                 Laufwerk nicht mehr aus, um die alte *und* die neue Datei
                 gleichzeitig aufzunehmen, wird die neue Datei nur soweit
                 zurückgeschrieben, wie der Platz dafür reicht (evtl. hängt
                 das Auftreten des Fehlers zusätzlich noch davon ab, wo
                 das Temporärlaufwerk liegt und wo in der Datei editiert
                 wurde???)!
                 Da keine Fehlermeldung erscheint, geht man normalerweise
                 davon aus, daß alles sauber funktioniert hat. In Wirklich-
                 keit ist die Datei aber abgeschnitten (und die Änderungen
                 sind u.U. verloren). Solange man dies rechtzeitig bemerkt,
                 ist der Schaden noch erträglich. Lädt man die Datei aber
                 erneut und speichert sie wieder ab, wird die alte Original-
                 datei (jetzt .BAK) mit der neuen .BAK-Datei überschrieben
                 und damit ist ein Großteil der Arbeit unwiederbringlich
                 verloren!!! Deshalb: Bis dieser Bug behoben wurde, sollten
                 Sie unbedingt darauf achten, daß genug freier Platz auf dem
                 Laufwerk vorhanden ist. U.U. können Sie unter Zuhilfenahme
                 von Wordstar-Codes auch darauf ausweichen, die Datei auf
                 ein anderes Laufwerk zu schreiben, aber prinzipiell wird
                 die Datei auch hier abgeschnitten, wenn der Platz nicht
                 mehr reicht!!! Als partielles Workaround kann man einen
                 Batchjob schreiben, der vor dem Aufruf von EDIT den zur
                 Verfügung stehenden Platz auf dem Laufwerk überprüft und
                 nach der Beendigung von EDIT ein DIR ausführt, mit dem
                 man nach dem Editieren schnell die Dateigrößen vergleichen
                 kann (um wenigstens die .BAK-Datei zu retten), etwa:

                  EDIT.BAT:

                   @ ECHO off > \dev\nul
                     REM Rudimentäres Workaround für Novells EDIT Bug
                     REM Eine zu editierende Datei muß im aktuellen Ver-
                     REM zeichnis liegen und beim Aufruf von EDIT mit
                     REM angegeben werden. Andere Optionen müssen nach
                     REM dem Dateinamen angegeben werden.
                     REM 96-11-24 -mp
                     IF NOT "NWDOS"=="%Os%" GOTO start
                     IF ""=="%1" GOTO start
                   @ FOR %%x IN (/h /H -h -H .) DO IF "%%x"=="%1" GOTO help
                     IF "/?"=="%1" GOTO help
                     IF "-?"=="%1" GOTO help
                   @ XCOPY %1 ed$$$$$$.tmp /f > \dev\nul
                     IF ERRORLEVEL 1 GOTO error
                   @ IF EXIST ed$$$$$$.tmp DEL ed$$$$$$.tmp > \dev\nul
                     GOTO start
                     :help
                   @ EDIT.COM %1 %2 %3 %4 %5 %6 %7 %8 %9
                     GOTO end
                     :error
                     IF EXIST ed$$$$$$.tmp DEL ed$$$$$$.tmp > \dev\nul
                     ECHO Novells EDIT hat eine Bug, der zum Verlust ...
                                      ... Ihrer Originaldatei führen könnte!
                     PAUSE Sie können jetzt mit Ctrl+C abbrechen oder ...
                                      ... mit beliebiger Taste fortsetzen...
                     :start
                   @ EDIT.COM %1 %2 %3 %4 %5 %6 %7 %8 %9
                     IF ERRORLEVEL 1 ECHO Ein Fehler ist aufgetreten!
                     DIR *.*
                     :end

                 Update 14 (EDIT 2.01) enthält Fixes für das Wildcard-
                 Management in Dateiauswahlmasken (speziell die Ausgabe
                 von Unterverzeichnissen war betroffen).

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)
                  4  Syntax-Fehler

   FASTOPEN.COM  Dummy-Befehl, siehe Kapitel III.1. bei FASTOPEN=.

   FBX.EXE       Benutzt eine eigene Konfigurationsdatei FASTBACK.CFG
                 (Vorlage in DEFAULT.CFG) in %NWDOSCFG%, weicht also
                 von den sonst bei Novell DOS 7 üblichen .INI-Dateien ab.
                 Außerdem werden im c:\nwdos\ Verzeichnis Benutzer-
                 konfigurationen als .FB (DEFAULT.FB) abgelegt.
                 (DEFAULT.FB wird offenbar bei jedem Start als Makro
                 abgearbeitet.)

                 Beim Customizing von FastBackup für Novell DOS ist die
                 Möglichkeit entfernt worden, echte Makrodateien abzu-
                 speichern. Nichtsdestotrotz kann FBX FB-Makrodateien mit
                 der Endung .FB oder .FBM abarbeiten, wenn man diese als
                 Aufrufparameter angibt. Hinweise dazu kann man dem bei
                 Novell DOS beiliegenden HWTEST.FBM entnehmen, das einen
                 Hardware-Test des DMA-Controllers durchführt, für den
                 man eine leere Diskette benötigt. Das Resultat dieses
                 Tests wird offenbar teilweise auch in die .FB-Datei
                 übertragen, die über %FBP_User% referenziert wird.
                 Genaueres ist allerdings noch nicht untersucht.
                 In jedem Fall können Sie in diesen Dateien Einträge wie

                  DMASpeed("Niedrig")
                  DMAXMSDisable("Aus")

                 per Hand dem Ergebnis des Tests anpassen. Mögliche Werte
                 sind "Niedrig", "Mittel" oder "Hoch", bzw. "Aus" oder
                 "Ein". Auf diese Weise können Sie aus Ihrem Rechner die
                 optimale Leistung herausholen.
                 (Für Besitzer einer externen Fast-Backup Express Version:
                 bezüglich der vielfältigen Anpassungsmöglichkeiten via
                 Makrodateien siehe diesbezügliche Anleitung).

                 FBX unterstützt sowohl in der DOS- als auch der Windows-
                 Version auch einige Diskettensonderformate (wie 400 KByte,
                 800 KByte oder 1,28 MByte (bei 5,25") oder 800 KByte,
                 1,52 MByte oder Macintosh HFS 1,44 MByte (bei 3,5"),
                 siehe auch Kapitel III.1. bei DRIVPARM=). Der Treiber
                 FASTBACK.386 wird nur für Backup/Restore auf lokalen
                 Floppies in Windows' Erweiterten 386er Modus benötigt
                 (siehe Kapitel VIII.1.). Der Treiber kann auch unter dem
                 multitaskenden TASKMGR geladen werden, ob dies aber
                 notwendig ist, ist nicht geklärt (siehe Kapitel VII.2.).

   FC.COM        FC verwendet die Dateiendung als Kennzeichen für den
                 Dateityp und entscheidet daraufhin, ob default-mäßig ein
                 Binär- oder ASCII-Vergleich durchgeführt werden soll.

                 FC vergleicht folgende Dateitypen standardmäßig binär:
                 .EXE, .COM, .SYS, .OBJ, .BIN und .LIB. Allerdings wird
                 im Gegensatz zu MS-DOS FC zusätzlich auch .CMD binär
                 verglichen (dies wird in der FC /? Hilfe unterschlagen).
                 .CMD ist unter CP/M und Multiuser DOS eine Endung für
                 ausführbare Dateien, ist aber auch eine gültige Endung
                 für Klarschrift-Skripte unter OS/2.
                 Bei Binärvergleichen werden Unterschiede als absolute
                 Positionsangaben ausgegeben, eine Angabe die man u.U.
                 für Novells EDIT benutzen kann, um die Fundstelle schnell
                 zu lokalisieren (obwohl EDIT für echte Binärdateien
                 eigentlich nicht geeignet ist), siehe bei EDIT.COM in
                 diesem Kapitel.

                 Die Kommandozeilen-Syntax unterstützt auch zusammengefaßte
                 Parameter, wie /NP statt /N /P. Parameter mit Zahlenangaben
                 müssen in diesem Fall allerdings hinten stehen, denn sonst
                 könnte es zu Doppeldeutigkeiten kommen.

                 FC bietet neben den dokumentierten Parametern noch zwei
                 weitere undokumentierte Parameter für ASCII-Vergleiche:

                  /G:n   Aus Kompatibilität zu DR DOS: Zeilenanzahl, die
                         vor einer Synchronisation übereinstimmen muß.
                         Der Standard war bei DR DOS 6.0 noch 5, aber da
                         Novells FC aus Kompatibilitätsgründen an die
                         ansonsten identische, erst später bei MS-DOS
                         eingeführte Option /n (d.h. einfach nur die Zahl n)
                         angepaßt wurde, und dort der Standard auf 2 ein-
                         gestellt ist, dürfte dies auch hier gelten.
                         Der Doppelpunkt ist optional. Die Angabe /G ohne
                         Zahl wird zurückgewiesen.
                  /LB:n  Aus Kompatibilität zu MS-DOS: Gibt die Anzahl
                         der Zeilen des internen Puffers an, die für
                         die Synchronisation bereitgestellt werden. Der
                         Default-Wert ist bei MS-DOS/PC-DOS/DR DOS und
                         wohl auch Novell DOS 7 100 Zeilen.
                         Da /LB:n nur bei ASCII-Vergleich verwendet wird,
                         gibt es auch keine Doppeldeutigkeiten mit dem
                         Parameter /B, wenn mehrere Parameter zusammen-
                         gefaßt werden.

                 Leider ist die maximale Zeilenlänge bei ASCII-Vergleichen
                 auf 255 Zeichen beschränkt (getestet mit Update 15), in
                 diesem Punkt kann MS-DOS' FC ausnahmsweise einmal mehr...

                 CCI Multiuser DOS 7.22 Gold kennt FC.COM immer noch
                 nicht, dort wird diese Funktion aber weitestgehend von
                 einer um entsprechende Funktionen erweiterten Fassung
                 von COMP.COM übernommen.

                 Errorlevel (unvollständig):

                 (nur für Novell DOS 7 verifiziert!)

                  0  normaler Ablauf, egal ob Dateien gleich oder ungleich
                     sind, oder Hilfeschirm
                  1  Datei(en) nicht gefunden oder falsche Aufruf-Syntax
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)

   FDISK.COM     Im Gegensatz zum entsprechenden MS-DOS Kommando arbeitet
                 Novells FDISK (als auch das DR DOS FDISK) nicht nur als
                 Festplattenpartitionierer, sondern formatiert die Parti-
                 tionen auch gleich, so daß man sich FORMAT (/X bei
                 Novell DOS) sparen kann.

                 Die undokumentierte Option /MBR (und andere, siehe
                 MSDOSTIP.TXT) von MS-DOS bietet Novells FDISK nicht
                 (offenbar aber einige Fassungen von CCI Multiuser DOS),
                 dafür ist aber seit DR DOS 6.0 genau diese Funktion direkt
                 aus dem FDISK-Menü heraus erreichbar (Master-Ladesatz
                 schreiben). Dabei wird (bei Novell DOS) der alte Boot-
                 Sektor in einer (versteckten) Datei namens C:\OLDMBR.BIN
                 gesichert und kann auch wieder zurückgeschrieben werden,
                 solange man diese Datei nicht löscht.
                 Hilfreich ist diese Funktion bei Virenbefall (siehe Kapitel
                 II.4 bei SDRES) oder zum Initialisieren einer nagelneuen
                 Festplatte, die partout nicht booten will (auch nicht bei
                 Floppy-Boots, siehe Kapitel II.2.).
                 Außerdem kann man das Ganze natürlich auch andersherum
                 verwenden, um einen speziell präparierten Master-Ladesatz
                 auf die Festplatte zurückzuschreiben, ohne sich die Finger
                 mit DEBUG etc. schmutzig machen zu müssen.
                 Achtung: Da es hier immer wieder Verwechselungen gibt:
                 Der Master-Boot-Record (MBR) ist nicht dasselbe wie der
                 Boot-Record (jeden Laufwerks), der z.B. mit SYS geschrieben
                 wird (siehe bei SYS.COM in Kapitel II.4.). Wird ein neuer
                 MBR geschrieben, werden auch Boot-Manager wie Linux' LILO,
                 der OS/2 Boot-Manager oder der PTS/Boot-Manager abgehängt
                 und müssen wieder neu installiert werden. Das gleiche gilt
                 offenbar auch für MS Windows95. Eine Boot-Diskette mit den
                 notwendigen Tools sollte also vorhanden sein!

                 Es gibt seit DR DOS 3.41 einen bei Novell DOS 7 aus-
                 schließlich im DOSBOOK dokumentierten Parameter /D, der
                 beim Aufruf von FDISK angegeben werden muß, um auch das
                 Löschen von Nicht-DOS-Partitionen innerhalb des Menüs zu
                 erlauben (Die Vorgehensweise ist identisch zum Löschen
                 einer DOS-Partition). Normalerweise benötigt man zum
                 Löschen von Nicht-DOS-Partitionen das entsprechende
                 Programm des jeweiligen Betriebssystems (sollte man
                 sicherheitshalber auch verwenden, falls möglich). Ob
                 dieser Parameter allerdings wirklich noch existiert,
                 ist noch nicht genau geklärt (hab's einfach noch nicht
                 selbst gebraucht... DR DOS 6.0 FDISK hatte diese Funktion
                 allerdings mit Sicherheit noch.).

                 Ein paar generelle Hinweise zur Partitionierung von
                 Festplatten (gleichermaßen auch für MS-DOS etc. gültig):

                 Möchten Sie - als Programmierer - Ihre Programme unter
                 einer alten DOS-Version (vor 4.0) überprüfen, müssen Sie
                 alle dafür notwendigen Dateien auf der ersten Partition
                 der ersten Festplatte unterbringen. Diese Partition darf
                 nicht größer als 32 MByte sein, weil ältere DOS-Versionen
                 Partitionen nur bis zu dieser Größe handhaben können
                 ("FAT12").

                 Für heutige Rechner existiert eine ähnliche Beschränkung
                 bei einer Partitionsgröße von 504 MByte (aber nicht ver-
                 ursacht durch DOS, das mit seiner "FAT16" bis zu zwei
                 GigaByte große Partitionen verwalten kann). Selbst wenn
                 Sie diese Größe nur minimal überschreiten, werden Sie -
                 ohne zusätzliche Treiber oder ein entsprechendes BIOS -
                 nicht einwandfrei auf eine solche Partition zugreifen
                 können (Vor DR DOS 6.0 Update 1992 kamen noch nicht ein-
                 mal FDISK mit größeren Partitionen sauber zurecht).
                 Novell DOS 7 gibt hier recht aussagekräftige Meldungen,
                 bei MS-DOS kann es aber vorkommen, daß alles scheinbar
                 anstandslos funktioniert, Sie aber später permanent
                 unerklärliche Probleme beim Zugriff auf diese Platte
                 haben (Bad-Sectors etc.). Wenn Sie den Speicher für
                 einen speziellen Treiber sparen wollen oder von mehreren
                 Betriebssystemen aus auf die Partition zugreifen wollen,
                 sollten Sie in jedem Fall unter dieser Schranke bleiben.

                 Ohne hier ins Detail gehen zu wollen, sollten Sie sich
                 genau überlegen, wieviele Partitionen Sie einrichten
                 wollen. In der Regel ist die Wartung eines Systems
                 leichter, wenn Sie handliche Partitionsgrößen einstellen,
                 die z.B. noch jeweils komplett auf ein Streamer-Band
                 passen. Gerne werden runde MByte-Zahlen als Partitions-
                 größen gewählt. Man muß sich dann aber klar machen, daß
                 im FAT-Dateisystem größere Partitionen auch größere
                 Cluster-Einheiten vorschreiben. Größere Cluster (d.h.
                 mehrere zusammenhängend adressierte Sektoren auf der
                 Platte) haben den Vorteil des schnelleren Zugriffs (bei
                 Dateien, die wesentlich größer sind als die Cluster-Größe),
                 aber den Nachteil des großen Verschnitts bei Dateien, die
                 kleiner sind.
                 Beträgt die Cluster-Größe z.B. 8 KByte, so werden auf der
                 Festplatte auch für eine nur ein Byte (als auch für eine
                 8 KByte) große Datei 8 KByte belegt, für eine 8 KByte +
                 1 Byte (8097 Bytes) große Datei direkt 16 KByte, usw.
                 Der Überhang beträgt im Mittel also 4 KByte pro Datei!
                 Haben Sie also auf einem Laufwerk hauptsächlich viele
                 kleine Dateien, so sollten Sie die Cluster-Größe auch
                 möglichst klein halten, also eine eher kleine Partition
                 einrichten. Umgekehrt ist für eher wenige, dafür aber
                 sehr große Dateien eine höhere Cluster-Größe wegen der
                 höheren Zugriffsgeschwindigkeit von Vorteil. Dies gilt
                 in besonderem Maße für Laufwerke, auf denen solche
                 Riesendateien wie die Windows-Auslagerungsdatei oder
                 - als Host-Laufwerke - die Volume-Dateien eines kompri-
                 mierten Laufwerks liegen (komprimierte Laufwerke ver-
                 wenden intern meist eine dynamische Clusterisierung,
                 d.h. sie sind für die Speicherung vieler kleiner Dateien
                 besonders effizient). U.U. ist es also möglich, daß Sie
                 effektiv *mehr* Dateien (und Daten) auf eine etwas
                 *kleinere* Partition bekommen, als auf eine etwas
                 größere Partition, die dafür aber eine größere
                 Cluster-Größe aufweist. Besonders an den Grenzwerten
                 zwischen verschiedenen Cluster-Größen sollten Sie also
                 bewußt eine etwas kleinere oder größere Partitions-
                 größe wählen (wobei ich normalerweise eine ganz knapp
                 unter dem nächsten Sprung der Cluster-Größe liegende
                 Partitionsgröße bevorzuge).

                 Normalerweise gilt folgende Zuordnung, wobei teilweise ein
                 gewisser Spielraum besteht, der aber von den DOS-eigenen
                 Programmen nicht ausgewählt werden kann.

                 Partitionsgröße    FAT-Größe Sektoren/Cluster Cluster-Größe
                 ------------------ --------- ---------------- -------------
                      bis 15,9 MByte  12 Bit           8            4 KByte
                   16 -  127,9 MByte  16 Bit           4            2 KByte
                  128 -  255,9 MByte  16 Bit           8            4 KByte
                  256 -  511,9 MByte  16 Bit          16            8 KByte
                  512 - 1023,9 MByte  16 Bit          32           16 KByte
                 1024 - 2047,9 MByte  16 Bit          64           32 KByte

                 In obigem Beispiel wäre üblicherweise eine Partitionsgröße
                 von 255,9 MByte einer Partition von 256 MByte vorzuziehen,
                 weil Sie dort im Schnitt einige MegaByte mehr Daten unter-
                 bringen können (so paradox es auf den ersten Blick klingt)!
                 Die Konsequenzen einer falschen Wahl können Sie sich anhand
                 obiger Tabelle leicht selbst ausmalen (von 100% Ausnutzung
                 der Plattenkapazität im optimalen Fall bis hin zu 99,9%
                 Verschwendung im Worst-Case ist alles möglich...)
                 Unter diesem Gesichtspunkt ist übrigens die Einrichtung von
                 komprimierten Laufwerken oft selbst dann von Vorteil, wenn
                 die auf dem Laufwerk gespeicherten Daten nur wenig kom-
                 primiert werden können.

                 Die maximal zulässige Partitionsgröße ist bei Novells
                 FDISK offiziell ein GigaByte, die maximal handhabbare
                 Laufwerksgröße beträgt zwei GigaByte. Da aber DR DOS 6.0
                 schon offiziell Partitionsgrößen bis zwei GigaByte unter-
                 stützte, vermute ich, daß auch Novell DOS 7 damit zurecht
                 kommt. Meine eigenen Versuche, solche Partitionen einzu-
                 richten und mit NWCACHE zu cachen, bestätigen dies. Sollte
                 es also tatsächlich ein diesbezügliches Problem gegeben
                 haben, so ist es entweder längst gelöst oder es hängt von
                 veralteten Rechner-BIOSes oder Festplatten-Technologien ab.
                 Allerdings sollte man bei Verwendung noch größerer Fest-
                 platten der automatischen Größenbeschränkung auf 2 GByte
                 nicht trauen: Ein kleiner Bug in FDISK sorgt dafür, daß
                 die Partition geringfügig zu groß angelegt wird, was zur
                 Folge hat, daß sie sich unter DOS nicht ansprechen läßt:
                 Die unter Novell DOS formatierte Partition war exakt
                 2.146.762.752 Bytes groß, unter MS-DOS ergaben sich
                 2.146.631.680 Bytes, als exakt 128 KByte kleiner. Eventuell
                 versucht sich Novells FDISK hier in 64 KByte-Clustern, die
                 aber nur von MS Windows/NT unterstützt werden, und MS-DOS
                 CHKDSK zu einem "Division durch Null"-Fehler, Novells
                 CHKDSK lediglich zu falschen Angaben verleiten...).
                 Gibt man manuell die richtige Kapazität an und bleibt
                 dabei unter dieser Grenze, tritt das Problem nicht auf.
                 Auch MS-DOS/PC-DOS (bis 7) schaffen eine maximale
                 Partitionsgröße von zwei GigaByte. (Mit MS Windows95b,
                 dem Update 2 zu MS Windows95 (Ende 1996) wurde ein neues
                 FAT32-Modell eingeführt werden, das unter Einbüßung der
                 Kompatibilität diese Systemgrenze des FAT16-Modells löst.)

                 Novells FDISK arbeitet nicht nur mit Novell DOS 7
                 (IBMBIO.COM, IBMDOS.COM), sondern unterstützt in irgend-
                 einer Weise auch eine Reihe der alten Digital Research
                 Betriebssysteme (CCPM.SYS, DOSPLUS.SYS, NETPLUS.SYS,
                 CCPMNET.SYS, CPCDOS.SYS, CDOS.SYS, DOS.SYS, DRDOS.SYS,
                 FLEX286.SYS, FLEX386.SYS). Dazu überprüft FDISK auf
                 Multiuser-Fähigkeiten des Betriebssystems und verwendet
                 bei Bedarf sogar eine Reihe der alten CP/M-86 System-
                 aufrufe. Anscheinend gibt es eine Möglichkeit, eine
                 diesbezügliche Auswahl zu treffen (bisher aber noch
                 unbekannt, vielleicht in Verbindung mit /D).
                 Auch OS/2-, NetWare- und Unix-Partitionen werden erkannt,
                 im Zweifelsfall wird die ID ausgegeben (bei MS-DOS FDISK
                 lediglich lapidar Nicht-DOS, obwohl offenbar intern auch
                 andere Typen erkannt werden können???).

                 Menübedienung: Das Menü kann man mit <Esc> verlassen.

                 Achtung: Je nach Situation ändert sich die Durch-
                 nummerierung der einzelnen Menüpunkte, deshalb sollte
                 man sich vor jedem Tastendruck immer erst versichern,
                 daß man die richtige Ziffer drückt. Die Folgen einer
                 Fehlbedienung wären katastrophal!!! Die Menüführung
                 ist etwas anders als beim Gegenstück von MS-DOS,
                 meiner Meinung nach allerdings sinnvoller.

                 Update 15 (FDISK 1.76) enthält eine Änderung, die dafür
                 sorgt, daß die landesübergreifende Angabe von Ja/Nein-
                 Zeichen über Eingabeumleitung vereinfacht wird, indem
                 ab sofort alle anderen Zeichen als die Ja/Nein-Zeichen
                 zurückgewiesen werden (siehe auch Kapitel II.16.). Auf
                 diese Weise ist es z.B. für PC-Händler besonders einfach,
                 eine Festplatte automatisch ohne Interaktion einzurichten.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  normale Bearbeitung
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)

   FILELINK.EXE  Um das Kommando FILELINK SLAVE abzubrechen, kann man kurz
                 <Ctrl>+<c> drücken. Nach einiger Zeit stoppt FILELINK dann.
                 Achtung: Wenn der Tastaturpuffer überläuft, kann das zum
                 Hängen des Rechners führen (evtl. mit Update 13 behoben).

                 Alle Langformen der Aufrufparameter können auch als drei-
                 buchstabige Abkürzungen geschrieben werden:

                  DIRECTORY : DIR
                  DUPLICATE : DUP
                  RECIEVE   : REC
                  TRANSMIT  : TRA
                  SETUP     : SET
                  SLAVE     : SLA
                  QUIT      : QUI

                  GETFL??
                  FLDUP??

                 Holt seine Konfigurationseinstellungen aus zwei unter-
                 schiedlichen Konfigurationsdateien:

                 NWDOS.INI in %NWDOSCFG%:

                 Die Direktiven aus [FILELINK] (hier undokumentiert) oder
                 aus [COLORS] steuern die Bildschirmdarstellung:

                  CurrentColor=
                  NewUI=on|off

                 Außerdem wird die Einstellung ColorSetX= aus [COLORS]
                 ausgewertet (X=<CurrentColor> aus 1..9).

                 FILELINK.CFG in %NWDOSCFG% (undokumentiert):

                 Enthält in der ersten Zeile die Hardware-Einstellungen wie

                  COMx:baudrate<ASCII-13> mit x       =1..2
                                              baudrate=115200, 57600, 38400,
                                                       19200, 9600, 4800,
                                                       2400, 1200, 600, 300,
                                                       150, 110.
                  LPTy<ASCII-13>              y       =1..3

                 Bemerkung:

                  Wenn man diese Konfigurationsdatei per Hand modifiziert,
                  sind auch andere Werte für COMx und LPTy möglich, etwa
                  COM6 oder LPT4. FILELINK scheint diese Werte dann auch
                  zu akzeptieren, bekommt aber evtl. Schwierigkeiten beim
                  Hardware-Zugriff. Deshalb muß man diese Einstellungen
                  auch überprüfen, wenn man vorher verwendete Schnitt-
                  stellen aus seinem Rechner entfernt hat.

                 Möchte man paßwortgeschützte Dateien übertragen, so
                 fragt FILELINK nach dem Paßwort. Am Ziel ist die Datei
                 nicht mehr paßwortgeschützt, hat aber nach wie vor das
                 Hidden-Attribut gesetzt. Das Kopieren von Dateien in
                 paßwortgeschützten Verzeichnissen ist auch möglich,
                 wenn man *vorher* in dieses Verzeichnis verzweigt (siehe
                 Kapitel II.4. bei PASSWORD und Kapitel II.9.).

                 Update 13 (FILELINK 3.01) enthält ein Bugfix für unmoti-
                 vierte Systemhänger und Verzeichnisse mit mehr als 1000
                 Einträgen.

   FIND.EXE      Kommt auch mit Dateien größer 63 KByte problemlos zurecht
                 (was für einige MS-DOS/PC-DOS Implementierungen ein
                 echtes Problem darstellt).

                 Normalerweise wird der Suchtext bei FIND in doppelte
                 Anführungszeichen eingerahmt, um ihn sicher von den rest-
                 lichen Parametern zu unterscheiden. Solange dadurch keine
                 Doppeldeutigkeiten auftreten, sind diese Anführungszeichen
                 jedoch optional, d.h. in erster Linie dann, wenn der Such-
                 text keine Leerfelder enthält und als erster Parameter
                 angegeben wird.

                 FIND durchsucht beliebige Dateien, allerdings wird die
                 Suche in Binärdateien bei einem ^Z (altes Dateiendezeichen)
                 in der Dateien abgebrochen.

                 Interessant ist auch, daß FIND es standardmäßig nicht
                 sehr genau mit der Umwandlung von Groß- und Kleinschreibung
                 nimmt. Der genaue Mechanismus dahinter ist noch nicht ganz
                 klar, aber ein Treffer kann auch dann erfolgen, wenn der
                 Suchtext nicht nur in Groß- oder Kleinschrift vom ge-
                 fundenen Text abweicht, sondern auch, wenn er 'nicht
                 näher zuzuordnende' Sonderzeichen enthält, d.h. im
                 Zweifelsfall findet FIND mehr Treffer, als eigentlich
                 vorhanden. Eine manchmal sicherlich praktische Eigenart.

                 Bezüglich der sicheren Verwendung in Batchjobs siehe
                 Kapitel IV.6.

                 Errorlevel (unvollständig):

                  (nur für Novell DOS 7 verifiziert):

                   0  normale Bearbeitung
                      bei MS-DOS 6.2: Muster mindestens einmal gefunden
                      bei Novell DOS auch: keine Dateien zu durchsuchen
                   1  nur MS-DOS: normale Bearbeitung, aber Muster nicht
                                  gefunden
                   2  nur MS-DOS: Falsche Parameter
                  31  Benutzerabbruch (<Ctrl>+<c> etc.), falsche Parameter
                      oder kein Suchtext (Novell DOS 7)

   FORMAT.COM    Der Parameter /F:format erlaubt die Formatangabe in vielen
                 Schreibweisen, die größtenteils nicht dokumentiert sind:

                                                                    5,25 3,5
                 2880KB, 2880K, 2880, 288, 2.88MB, 2.88M, 2.88        -   x
                 1440KB, 1440K, 1440, 144, 1.44MB, 1.44M, 1.44        -   x
                 1230KB, 1230K, 1230, 123, 1.23MB, 1.23M, 1.23 (1)    x   -
                 1220KB, 1220K, 1220, 122, 1.22MB, 1.22M, 1.22 (2)    x   -
                 1200KB, 1200K, 1200, 120, 1.2MB , 1.2M , 1.2  (3)    x   -
                  720KB,  720K,  720                                  -   x
                  640KB,  640K,  640                           (4)    x   -
                  360KB,  360K,  360                                  x   -
                  320KB,  320K,  320                                  x   -
                  180KB,  180K,  180                                  x   -
                  160KB,  160K,  160                                  x   -

                 (1) und (4) undokumentierte Formate für 5.25 Zoll
                             Diskettenlaufwerke, unterstützt von Novells
                             FORMAT
                 (2) und (3) andere Schreibweise führen zu leichten
                             Differenzen in der Kapazitäts*angabe*, nicht
                             jedoch in der Kapazität

                 Übrigens: Wenn Sie 'überformatierte' Disketten (FDFORMAT,
                 2M, VGACOPY, etc.) benutzen, müssen Sie normalerweise eine
                 'Lesehilfe' wie VGAREAD.EXE oder FDREAD während des Bootens
                 einbinden, um transparent auf diese Disketten zugreifen zu
                 können.
                 Offenbar kann Novell DOS zumindest einige dieser Sonder-
                 formate auch ohne diese zusätzlichen TSRs lesen und
                 schreiben. Am besten ist es, Sie probieren einfach
                 einmal aus was passiert, wenn Sie Ihren Treiber weglassen
                 (und berichten mir dann das Resultat...?). (Zumindest auf
                 1,77 MByte formatierte 1,44 MByte Floppies funktionierten
                 bei mir ohne zusätzliche Treiber, genaueres habe ich
                 allerdings noch nicht untersucht.
                 Novells FORMAT ist auch in der Lage, (einige) solche Über-
                 formate zu formatieren, wenn Sie die Parameter /N:sectors
                 und /T:tracks angeben. Eine Auflistung gängiger Sonder-
                 formate findet sich bei DRIVPARM= in Kapitel III.1.)

                 Neben den dokumentierten Parametern existiert bei
                 Novell DOS 7 noch ein undokumentierter Parameter /QUIET,
                 der alle Meldungen unterdrückt und FORMAT automatisch
                 ablaufen läßt. Offenbar war dieser Parameter u.a. für
                 Utilities wie BACKUP.COM gedacht, wird aber dort nicht
                 verwendet. /QUIET muß als letzter Parameter angegeben
                 werden, denn alle Parameter nach /QUIET werden ignoriert.
                 Den Parameter /C (Check Bad) von MS-DOS 6.22 FORMAT bietet
                 Novells FORMAT nicht, ebenso fehlen alle undokumentierten
                 MS-DOS 4.00+ Parameter: /AUTOTEST, /BACKUP, /SELECT (aber
                 genau für diese Zwecke läßt sich Novells Parameter /QUIET
                 gut verwenden, siehe auch MSDOSTIP.TXT). Um nur die Frage
                 nach dem Volume-Namen zu unterdrücken, geben Sie bei
                 Novell DOS einfach den Parameter /V ohne Wert an.

                 FORMAT kann nicht auf Netzlaufwerke und per ASSIGN, SUBST
                 oder JOIN umgeleitete Laufwerke angewendet werden.

                 Die Option /B ist bei Novell DOS 7 undokumentiert, da seit
                 langem (wohl ab DR DOS 3.41+, sicher aber DR DOS 5.0+)
                 überflüssig. Dennoch ist sie in vollem Umfang funktions-
                 fähig. Sie diente früher (und dient teilweise selbst noch
                 bei MS-DOS 6.22 und PC-DOS 7) dazu, Platz für die System-
                 dateien auf dem Medium zu reservieren (zum späteren
                 'SYS'en' alter DOS-Versionen). Da bei Novell DOS die
                 Systemdateien aber an beliebiger physikalischer Stelle
                 auf dem Medium liegen können, ist dies nicht mehr not-
                 wendig. Bei MS-DOS 6.0+ wurde die Beschränkung bei Floppies
                 aufgehoben, bei Festplatten gilt sie aber offenbar in
                 einigen Fällen immer noch, obwohl deren Dokumentation das
                 Gegenteil behauptet (die Dateien müssen zwar nicht mehr
                 direkt aufeinander folgen, aber einige Regionen in den
                 Systemdateien dürfen nicht fragmentiert auf dem Medium
                 gespeichert werden). Allerdings bewirkt diese Option auch,
                 daß die Floppy zwar mit 9 Sektoren formatiert wird, davon
                 aber nur 8 verwendet werden (nur bei 5,25" Laufwerken).

                 Aus Sicherheitsgründen (und weil diese Funktion bei DR DOS/
                 Novell DOS schon in FDISK enthalten ist), kann man Fest-
                 platten nur formatieren, wenn man zusätzlich /X angibt.
                 Wird daraufhin ein Schnell-Format angewendet, sollte man
                 die Formatierung - zumindest unmittelbar danach - mit
                 UNFORMAT.EXE wieder rückgängig machen können, sofern
                 genügend freier Platz auf dem Laufwerk vorhanden war, um
                 die Informationen abzulegen (wohl in einem Block namens
                 UNFORMATDR, der die Kennung JS10 enthält). Mal ehrlich,
                 wem ist es noch nicht passiert, versehentlich die falsche
                 Festplatte zu formatieren...? ;-)
                 Sollte UNFORMAT trotzdem nicht funktionieren, Ruhe
                 bewahren und bei UNFORMAT.EXE weiterlesen.

                 FORMAT /S überträgt die Systemdateien (IBMBIO.COM,
                 IBMDOS.COM und wohl auch STACKER.BIN) auf das formatierte
                 Medium, dabei wird allerdings MS-DOS DBLSPACE.BIN/
                 DRVSPACE.BIN nicht berücksichtigt, muß also ggf. nach-
                 träglich umkopiert werden. Zusätzlich wird wohl auch
                 DRMDOS.SYS für DR DOS Multiuser-Varianten unterstützt.
                 Boot-Sektoren können wohl vom Typ "NWDOS 7.0" oder
                 "OSLOADER" sein (könnte was mit Novells Multi-Boot-
                 Utility LOADER.ZIP zu tun haben???). FORMAT /S übernimmt
                 den Datumsstempel der Originalsystemdateien (bei DR DOS
                 wird - bis auf DR DOS 6.0 Updates nach 1992 - das aktuelle
                 Datum verwendet).

                 FORMAT /U wird zum Formatieren eines Mediums ohne Restau-
                 rationsmöglichkeit verwendet und ist damit auch besonders
                 für ATA-Cards (PCMCIA) und - in Verbindung mit den Optionen
                 /T:tracks /N:sectors - für SRAM-Cards (PCMCIA) verwendbar.

                 Eine Übersicht über die Hardware-Parameter für be-
                 stimmte Diskettenformate finden Sie in Kapitel III.1.
                 bei DRIVPARM=.

                 Update 13 (FORMAT 2.06) enthält eine verbesserte Version,
                 die nur noch dann formatiert, wenn dies unbedingt notwendig
                 ist.

                 Errorlevel (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
                 DR DOS 6.0)

                  0  normales Ende
                  3  Benutzerabbruch durch <Ctrl>+<c> etc.
                  4  Fataler Fehler (Datenträger, falscher Name)
                  5  Antwort 'Nein' auf Frage, ob Festplatte formatiert
                     werden soll

   GRAFTABL.COM  Entgegen vielen anderslautenden Meldungen in der Literatur
                 wird dieser Treiber nur für CGA-Karten und - mit ent-
                 sprechender zusätzlicher BIOS-Unterstützung durch einen
                 Spezialtreiber - für HGC-Karten benötigt, wenn auch im
                 Grafikmodus die ASCII-Zeichen 128 bis 255 dargestellt
                 werden sollen. (Oft wird behauptet, GRAFTABL wäre auch
                 für den Textmodus und/oder auf neueren Grafikkarten not-
                 wendig. Dies ist jedoch nicht der Fall, obwohl man GRAFTABL
                 in speziellen Fällen zweckentfremden könnte...)

                 Da die Bitmaps der Zeichen 128 bis 255 je nach gewünschter
                 Codeseite variieren, muß GRAFTABL mehrere Zeichensätze im
                 Format 8x8 enthalten (jeweils nur die obere Hälfte des
                 Zeichensatzes).

                 Auf den ersten Blick liegt mit GRAFTABL also etwas wie ein
                 "Codeseiten-Support des kleinen Mannes" vor, der leider
                 nur im Grafikmodus sichtbar werden kann. Daher dürfte
                 GRAFTABL auch nicht in die Umschaltung von Codeseiten
                 mittels MODE und CHCP einbezogen worden sein (nicht
                 überprüft), obwohl dies für den Grafikmodus durchaus
                 möglich wäre (interessanterweise testet zumindest Novells
                 DISPLAY.SYS aber auf GRAFTABL ab...).

                 Ein Standard-Font 8x8 (für die Hardware-Codeseite 437)
                 mit den ASCII-Zeichen 0 bis 127 befindet sich immer im
                 Haupt-BIOS des Rechners, das immer MDA (HGC) und CGA
                 unterstützt. Und im Textmodus werden die Bitmaps für die
                 einzelnen Zeichen bei MDA, HGC und CGA direkt aus einem
                 Zeichensatz-ROM geladen, der nicht etwa ein BIOS enthält.
                 Insofern kann man hier ohne Hardware-Manipulation sowieso
                 keine Zeichen umdefinieren. (CGA-Karten besitzen meist
                 einen Jumper, um zwischen zwei im ROM eingebrannten Fonts
                 für Codeseite 437 zu wechseln und bei neueren HGC-Karten
                 kann man häufig ein eigenes EPROM statt des mitgelieferten
                 oder bereits im Controller integrierten ROMs einsetzen.
                 HGC+ RAMFONT Karten erlauben zwar installierbare Zeichen-
                 sätze, werden aber von DOS nicht gesondert behandelt, weil
                 DOS sich dabei auf die Video-BIOS-Unterstützung (MCGA/EGA/
                 VGA) verläßt. Dies bietet eine HGC+ RAMFONT Karte nicht,
                 ließe sich bei Caldera OpenDOS relativ leicht mit einem
                 zusätzlichen Treiber nachrüsten...)
                 Bei Grafikkarten mit eigenem BIOS (MCGA/EGA/VGA) residieren
                 dort sowieso verschieden viele Fonts in voller Länge.
                 Außerdem erlauben diese Karten auch installierbare Text-
                 Fonts und damit den Einsatz von DISPLAY.SYS. Daher ist dort
                 GRAFTABL überflüssig. Selbst wenn Sie eine MDA-, HGC- oder
                 CGA-Karte neben einer MCGA-, EGA- oder VGA-Karte instal-
                 liert haben, brauchen Sie GRAFTABL nicht zu laden. Das
                 Video-BIOS der höherentwickelten Grafikkarte stellt den
                 höheren Anteil des 8x8-Fonts nämlich auch für die andere
                 Grafikkarte zur Verfügung.
                 Bei GRAFTABL sind die Zeichensatz-Daten im Treiber selbst
                 enthalten, können also nicht erweitert werden. (Notfalls
                 kann man aber auch den Treiber patchen, jeder der halben
                 Fonts ist exakt 1024 Zeichen lang, wobei der residente
                 Treiber ca. 1.5 KByte groß ist.)

                 Vielleicht werden Sie jetzt noch einwerfen, daß das Video-
                 BIOS höherer Grafikkarten aber nur Fonts für die Codeseite
                 437 enthält. Richtig, aber glücklicherweise können die
                 Fonts aus .CPI-Dateien sowohl im Text- als auch im Grafik-
                 modus verwendet werden, so daß auch in diesem Fall GRAFTABL
                 überflüssig bleibt.

                 Für die Angabe der Statusinformationen sind folgende
                 Optionen zulässig: /S und /STATUS, andere Formen dieser
                 Option sind ungültig (bei MS-DOS ist noch /STA möglich).

                 Interessanterweise werden die Namen der Codeseiten auch
                 in der deutschen Version in Englisch ausgegeben (437="USA",
                 850="Multilingual", 860=Portuguese, 863="Can French" und
                 865="Nordic") ausgewiesen (bei MS-DOS 6.2x heißt 850=
                 "Multi-lingual" und 863="Can. French", außerdem existiert
                 dort noch eine weitere Codeseite 852="Latin-2"), siehe
                 auch Kapitel II.16.

                 Glücklicherweise scheint MS-DOS GRAFTABL auch unter
                 Novell DOS zu laufen.

                 Errorlevel (dokumentiert für Novell DOS 7, gelten auch
                            für MS-DOS 4.0+ und OS/2 2.0+):

                  0  GRAFTABL erfolgreich geladen
                  1  GRAFTABL bereits geladen, Codeseite aktualisiert
                  2  Dateifehler
                  3  Parameterfehler, keine weitere Aktion
                  4  Falsche Version des Betriebssystems

   GRAPHICS.COM  Dieser Treiber ermöglicht Bildschirm-Hardcopies mit <Print>
                 auch im Grafikmodus. Ohne GRAPHICS (oder Fremdtreiber) sind
                 die Resultate im Grafikmodus unbrauchbar, lediglich der
                 Textmodus wird default-mäßig unterstützt. Der residente
                 Treiber kostet ca. 4,5 KByte Speicher.

                 Unterstützt - wie wenig bekannt - mit Option 'COLOR' auch
                 Farbdrucker (8 Farben mit CMY-Farbband für Cyan, Magenta,
                 Gelb und Schwarz). Neben den dokumentierten Parametern
                 erlaubt GRAPHICS noch einige Einstellungen mehr:
                 Neben 'COLOR' für Farbdrucker, kann man auch die bei MS-DOS
                 gewohnten Schlüsselworte 'COMPACT' für den IBM PC Compact
                 Printer oder 'GRAPHICS' für den IBM PC Graphics Printer
                 oder Kompatible angeben.
                 Die bei Novell DOS ebenfalls undokumentierte Option '/B'
                 (Background) sorgt dafür, daß auch der Hintergrund in der
                 gewünschten Farbe ausgedruckt wird (nur bei 'COLOR').

                 MS-DOS 6.22 GRAPHICS bietet allerdings noch erheblich
                 mehr Möglichkeiten, u.a. auch für Laser- und Tintenstrahl-
                 drucker, die in einer Datei GRAPHICS.PRO auch an eigene
                 Bedürfnisse angepaßt werden können.
                 Auch die alten Optionen für IBM AP PCs und Drucker
                 ('THERMAL' und '/LCD') werden von Novell DOS nicht
                 unterstützt.
                 Die Option 'COLOR' von Novell DOS entspricht übrigens der
                 Option 'COLOR8' bei MS-DOS ('COLOR4' für vier Farben mit
                 RGB-Farbbändern wird nicht unterstützt, 'COLOR1' für
                 Schwarz ist obsolet...). Siehe auch Kapitel II.16.

   JOIN.EXE      Novells JOIN erlaubt *auch* die Zuordnung eines Laufwerks
                 auf ein Unterverzeichnis des *gleichen* Laufwerks (getestet
                 bis Update 15 bei geladenem Netz-Client). Da das Laufwerk
                 aufgrund der JOIN-Zuordnung nun aber nicht mehr ansprechbar
                 ist, möchte ich bezweifeln, daß dies für irgendetwas nütz-
                 lich sein könnte (würde ja schließlich eine Rekursion
                 auslösen)... (Fällt Ihnen etwas ein?)

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                   0  MS-DOS 5.0+ : alles ok
                   1  MS-DOS 5.0+ : ungültiger Parameter
                      Novell DOS 7: Verzeichnis für JOIN nicht anlegbar
                   3  Novell DOS 7: Benutzerabbruch (<Ctrl>+<c> etc.)
                  32  Novell DOS 7: Ausgabe der JOIN-Zuordnungsliste
                  43  Novell DOS 7: Fehler
                 255  Novell DOS 7: erfolgreich Zuordnung hergestellt

   KEYB.COM      Novells KEYB benutzt - im Gegensatz zu KEYB von MS-DOS -
                 den BIOS-Treiber mit. Hierdurch, und durch die Möglichkeit,
                 sich in die HMA zu 'verdrücken', benötigt der Treiber ver-
                 gleichsweise wenig Speicherplatz (4 KByte statt 7,4 KByte
                 wie der Treiber von MS-DOS). Allerdings kann diese Ver-
                 fahrensweise auch nachteilig sein.

                 Die Tabellen für die Tastaturlayouts sind bei Novells
                 KEYB im Treiber selbst untergebracht (nicht wie bei MS-DOS
                 in einer externen Datei KEYBOARD.SYS). Es existieren der-
                 zeit noch drei Platzhalter für zusätzliche Layouts. Eine
                 Tabelle zum Patchen der jeweils gültigen Codeseiten ist
                 wegen der Zeichenkette "valid codepages (2 per country)-->"
                 leicht zu finden.

                 Ab dem Update 9 (KEYB 2.09) unterstützt dieser Treiber
                 (weitestgehend undokumentiert) auch Brasilien/Lateinamerika
                 (KEYB BR) und enthält einen Fix für <Ctrl>+<Tab>. Update 12
                 (KEYB 2.10) unterstützt sowohl <Shift>+<Tab>, als auch
                 <Ctrl>+<Tab>. <Alt> Belegungen 'schimmern' nun bei nicht
                 definierten <AltGr> Belegungen durch. KEYB 2.11 aus Update
                 13 löst Probleme mit Nortons NCACHE2, wenn beide in die
                 HMA geladen wurden. Update 14 enthält einen Fix für das
                 ungarische Layout (KEYB 2.12).
                 Leider unterstützt auch der Treiber aus Update 15 noch
                 nicht die neuen Windows95-Tasten (unter DOS) sowie Tasten
                 von 122-Tasten-Tastaturen (und auch nicht alle neuen
                 Tastatur-Layouts und IDs von MS-DOS 6.22 wie YU, YC, RO,
                 CZ, PL, IS, BG, SL). JP wird offenbar in Spezialversionen
                 unterstützt. (JA, KO, CH und TN werden von keiner euro-
                 päischen DOS-Version unterstützt, weder von MS-DOS noch
                 von Novell DOS). Statt TR gibt es die zwei neuen Optionen
                 TF und TQ. Bezüglich landesspezifischer Details siehe
                 Kapitel II.16.

                 Sollten Sie bestimmte Möglichkeiten von MS-DOS KEYB bei
                 Novell DOS 7 vermissen, können Sie auch den Treiber von
                 MS-DOS unter Novell DOS 7 verwenden. Dazu ist es aller-
                 dings notwendig die DOS-Version mit SETVER anzupassen
                 (z.B. SETVER KEYB.COM 6.22 für KEYB von MS-DOS 6.22).
                 Novells KEYB kann nicht unter MS-DOS gestartet werden.

                 Ganz allgemein eine bessere Alternative zu KEYB (von
                 jedem DOS) ist der stark erweiterte FreeWare-Tastatur-
                 treiber K3PLUS 6.50+ bzw. FreeKEYB, die trotz unzähliger
                 Erweiterungen auch nur ungefähr 8,5 KByte Speicher
                 benötigen (zu beziehen über mich).

   LABEL.COM     Dieses Kommando unterstützt (auch mit Update 15) im Gegen-
                 satz zum Pendant von MS-DOS 6.2x noch nicht die Ausgabe von
                 Medienseriennummern (obwohl der Novell DOS 7 Kernel im
                 Rahmen der Updates mittlerweile Seriennummern unterstützt).
                 Allerdings kann man für diesen Zweck auch LABEL.COM von
                 MS-DOS 6.22 ausleihen, das auch unter Novell DOS arbeitet.

                 Novells Implementation arbeitet allerdings im Gegensatz
                 zu MS-DOS' Realisierung auch auf Netz-, CD-ROM- und
                 Substitut-Laufwerken. In diesem Fall wird nur der Medien-
                 name des Laufwerks ausgegeben und es erscheint eine
                 Meldung, daß der Name nicht geändert werden kann.
                 Logischerweise unterbleibt dann auch die J/N-Frage nach
                 einem neuen Namen.

                 Obwohl LABEL auch direkt die Angabe des neuen Namens als
                 Parameter erlaubt, mag es in manchen Fällen sinnvoll sein,
                 den neuen Namen des Mediums aus einer Datei zu holen, etwa:

                  LABEL < newname.lbl

                 Auf gemeinsam benutzten Laufwerken, Floppies und RAM-Disks
                 kann dies jedoch mißlingen (auch bei MS-DOS/PC-DOS), wenn
                 der neue Name des Mediums einem bereits auf dem Medium
                 bestehenden Namen einer Datei im Hauptverzeichnis ent-
                 spricht. Denn der Name des Mediums wird dort im Prinzip
                 wie jede andere Datei gespeichert, nur mit (normalerweise
                 ausschließlich) gesetztem Volume-Attribut (aber andere
                 Attributkombinationen sind auch möglich). Daraus resul-
                 tiert auch die etwas seltsam anmutende maximale Länge von
                 11 Zeichen (8 + 3 Bytes). Auf physikalischen Festplatten-
                 laufwerken wird der Name an anderer Stelle gespeichert,
                 so daß dieses Problem hier nicht auftritt.

                 In sehr seltenen Fällen kann es vorkommen, daß Sie den
                 Namen einer Diskette unter MS-DOS/PC-DOS nicht mehr nach-
                 träglich ändern können: Falls die Diskette mit den Norton
                 Utilities formatiert oder nach einem Fehler restauriert
                 wurde, wird der Name des Mediums statt mit Leerfeldern
                 (ASCII-32) mit Null-Zeichen (ASCII-0) bis zur vollen Länge
                 aufgefüllt. Mit derartigen Namen kommen MS-DOS/PC-DOS
                 und einige andere Programme (z.B. ältere Versionen von
                 PKZIP) jedoch nicht zurecht.
                 Glücklicherweise ist es jedoch unter Novell DOS 7 über-
                 haupt kein Problem, den Namen derartiger Disketten zu
                 ändern!

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  erfolgreich
                  1  MS-DOS 5.0+: Laufwerk nicht vorhanden/ungültig
                  2  Novell DOS 7: Benutzerabbruch (<Ctrl>+<c> etc.)
                  4  Novell DOS 7: falscher Parameter, Laufwerk nicht
                                   vorhanden/ungültig

   LOCK.EXE      Achtung: Dieses Utility ist kein Schutz gegen unbeab-
                 sichtigtes Benutzen des Rechners! Schaltet ein skrupel-
                 loser Zeitgenosse den Rechner während der Abwesenheit
                 des Benutzers ab, ist der Schutz von LOCK aufgehoben
                 (und was schlimmer ist: Evtl. nicht gesicherte Daten
                 sind verloren - deshalb vorher möglichst Daten sichern).
                 Begrenzte Abhilfe ist durch Setzen eines Systempaßwortes
                 (mittels SETUP und SECURITY) möglich, das beim Booten
                 eingefordert wird. Siehe auch bei PASSWORD bezüglich
                 der Eingabe des globalen Paßwortes.

                 Unterstützt MDA-, HGC-, HGC+-, HGC-InColor-, CGA-, EGA-
                 und VGA-Grafikkarten. Speichert das Schirmbild in einer
                 temporären Datei in %Temp% namens SCREEN.SAV (bei Angabe
                 des Parameters /S). Besondere Grafikmodi und SuperVGAs
                 werden anscheinend nicht komplett unterstüzt, was aber
                 auch nicht verwunderlich wäre. (Ausweichempfehlung:
                 Den erweiterten Tastaturtreiber K3PLUS alias FreeKEYB
                 mit eingebautem Universal-Bildschirmschoner verwenden.
                 Aber: Falls dieser Treiber geladen ist, können Sie LOCK
                 mit dessen 'Break-to-DOS'-Funktion (<Ctrl>+<Alt>+<Break>,
                 sofern aktiviert) auch ohne Angabe des korrekten Paßwortes
                 beenden, wobei das System danach sofort neu gebootet
                 werden sollte. Daher sollten Sie sich nicht zu viel
                 von LOCK versprechen.)

                 LOCK entnimmt seine Einstellungen für die Bildschirm-
                 darstellung undokumentiert und entgegen den üblichen
                 Konventionen unter Novell DOS einer optionalen Datei
                 DOS.INI im Verzeichnis C:\NWDOS (oder evtl. im %Path%)
                 aus der Rubrik [COLORS]:

                  MaxColors=
                  CurrentColor=
                  ColorSetX=            (X=<CurrentColor> aus 1..9)

                 Die Einstellungen sind ansonsten völlig analog zu den
                 Einstellungen in der Datei NWDOS.INI, die hier allerdings
                 völlig ignoriert wird.

                 U.U. werden einige Einstellungen aus noch aus der Windows-
                 Datei CONTROL.INI geholt und evtl. spielt dabei LOCKBITMAP
                 eine Rolle.

                 Novell DOS 7 LOCK arbeitet weitestgehend anders als
                 noch DR DOS 6.0 LOCK, obwohl die nach außen sichtbare
                 Funktionalität ähnlich ist.
                 Ab Update 12 und später 14 (LOCK 2.01) werden Fassungen
                 ausgeliefert, die verschiedene Probleme fixen (nicht aber
                 das oben beschriebene Verhalten ändern).

                 LOCK.EXE kann auch unter Windows gestartet werden.

                 Achtung: LOCK.EXE hat absolut nichts mit den bei MS-DOS 7
                 (MS Windows95/Chicago) neuen internen Befehlen LOCK und
                 UNLOCK zu tun!!!

   MEM.EXE       Wie nur teilweise dokumentiert, kann man die folgenden
                 Optionen auch abkürzen:

                 /HELP     : /H /?   (der Parameter /HILFE existiert nicht,
                 /DEBUG    : /D       sondern ist lediglich das Resultat
                 /CLASSIFY : /C       eines übereifrigen Übersetzers...)

                 Die Option /PROGRAM läßt sich nicht mit /P abkürzen, da /P
                 für 'Page' zum Anhalten der Anzeige nach jeder Seite ver-
                 wendet wird (dies gilt nun übrigens auch für MS-DOS 7).

                 Die bei MS-DOS vorhandenen Optionen /FREE und
                 /MODULE=module bietet Novell DOS' MEM nicht.
                 In Kapitel IV.5. wird ein Batchjob beschrieben, der
                 diese Funktionen auch bei Novell DOS 7 nachrüstet und
                 dabei noch um zwei neue Parameter /REGION und /VECTORS
                 ergänzt.

                 Die bei MS-DOS undokumentierte Option /A zur Anzeige der
                 HMA-Information kollidiert mit der Anzeige der Gesamtinfo
                 (/A) unter Novell DOS. Für die Anzeige der HMA-Belegung
                 (d.h. des Segments FFFF) dient unter Novell DOS 7 die
                 Option /F.

                 Novells MEM.EXE funktioniert teilweise auch unter MS-DOS
                 und MS Windows95, allerdings führen die Parameter /D und
                 /F unter MS Windows95 zu einem Absturz (getestet mit der
                 ursprünglichen Original-Version von Novell DOS 7).

   MEMMAX.COM    Liefert Errorlevel 3 bei Benutzerabbruch durch <Ctrl>+<c>.
                 Weitere Hinweise siehe Kapitel V.6.

   MODE.COM      Dieses vielseitige Einstellungsprogramm bietet (ab DR DOS
                 5.0) im 'Japan-Modus' Möglichkeiten, japanische Drucker und
                 Grafikkarten (und Tastaturen) so anzusteuern, daß die
                 japanischen Schriftzeichen erscheinen. Wie dieser Modus
                 aktiviert wird, ist noch unklar (evtl. geht dies auch nur
                 mit speziellen Kernel-Versionen). Standardmäßig ist der
                 'Englisch-Modus' aktiv und die optionalen Werte werden
                 größtenteils zurückgewiesen.

                 Im folgenden werden nur die Hilfeschirme aufgelistet, die
                 in der Dokumentation unvollständig angegeben sind, die
                 restlichen Optionen erfahren Sie im DOSBOOK bzw. mit
                 MODE /?.

                 MODE LPT#:[n][,[m][,[P][,s]]]  Druckereinstellung
                         #=Nummer der Druckerschnittstelle
                         n=Zeichen pro Zeile (80, 132 oder J für Japan)
                         m=Zeilen pro Zoll (6 oder 8)
                         P=Ständige Wiederholung
                           Permanenten Teil von MODE zur Steuerung von
                           Wiederholungen installieren, kann mit
                           <Ctrl>+<Break> abgebrochen werden.
                           Die bei MS-DOS 4 - 6 möglichen Optionen
                           [R[ETRY=]]E|B|R|N|NONE|P für Error, Busy, Ready,
                           None, Permanent statt des einfachen P sind bei
                           Novell DOS 7 leider nicht möglich. Im Fehlerfall
                           erscheint eine DOS-Fehlermeldung Abbrechen (=N),
                           Wiederholen (=P), Ignorieren (=R), Fehler (=E).
                         s=Leerraum zwischen japanischen Zeichen
                           (12..50, C, D, E, P)
                 MODE COM#:b[,p][,d][,s][,P]  Serielle Schnittstelle
                         #=Nummer der seriellen Schnittstelle
                         b=Baudrate    - 110..19200
                         p=Parität     - Gerade (E), Keine (N), Ungerade (O)
                         d=Daten-Bits  - 7 oder 8
                         s=Stopp-Bits  - 1 oder 2
                         P=Ständige Wiederholung trotz Zeitschranken-
                           überschreitung.
                           Permanenten Teil von MODE zur Steuerung von
                           Wiederholungen installieren, kann mit
                           <Ctrl>+<Break> abgebrochen werden.
                           Die bei MS-DOS 4 - 6 möglichen Optionen
                           [R[ETRY=]]E|B|R|N|NONE|P für Error, Busy, Ready,
                           None, Permanent statt des einfachen P und die
                           anderen Syntax-Erweiterungen sind bei Novell DOS
                           und DR DOS leider nicht möglich.
                 MODE modus,zeilen   Anzeigemodus
                         modus=40 oder BW40: 40 Spalten; keine Farbe (CGA+)
                               80 oder BW80: 80 Spalten; keine Farbe (CGA+)
                                       CO40: 40 Spalten; in Farbe (CGA+)
                                       CO80: 80 Spalten; in Farbe (CGA+)
                                       MONO: 80 Spalten; monochrom (MDA/HGC)
                                       JT80: 80 Spalten (Japanischer Text)
                                       Auf Zweimonitorsystemen schalten
                                       BW40 und BW80 bzw. CO40 und CO80 auf
                                       den Farbadapter um, während MONO den
                                       Monochrom-Adapter zum aktiven Video-
                                       System macht. Das Bild des jeweils
                                       anderen Monitors wird dabei nicht
                                       gelöscht. Natürlich kann man mit BW40
                                       oder BW80 keine Graustufendarstellung
                                       auf einem Farbadapter erzwingen,
                                       solange eine MDA/HGC im System ist.
                                       Mit 40 oder 80 wird die aktive
                                       Video-Karte nicht umgeschaltet,
                                       sondern nur die andere Darstellungs-
                                       art gewählt (40 ist auf MDA/HGC un-
                                       möglich).
                         zeilen=Textzeilen : 25, 43 oder 50
                 MODE LPT#[:]=COM#|LPT# Umleitung eines Druckers
                         Im Gegensatz zur Dokumentation, die ausschließlich
                         die Umleitungsmöglichkeit eines parallelen Druckers
                         auf eine serielle Schnittstelle beschreibt, gibt
                         es eine äußerst interessante Möglichkeit, auch auf
                         einen *anderen* parallelen Drucker umzuleiten,
                         etwa: LPT1:=LPT2. Auch in diesem Fall wird ein
                         kleiner (ca. 500 Bytes) großer residenter Codeteil
                         geladen. Eine Möglichkeit zur Default-Einstellung
                         von PRN: und AUX: bietet sich damit allerdings
                         immer noch nicht. Allerdings könnte man hierfür
                         ein kleines Utility schreiben, daß die DEVICE-
                         Verkettung umpatcht (vielleicht gibt es soetwas
                         schon?). Diese Möglichkeit bestand auch schon
                         bei DR DOS.

                 (Bei DR DOS gab es offenbar noch zwei unbekannte Optionen
                 J80/40?? und A80/40??, die bei Novell DOS 7 weggefallen
                 sind.)

                 Es gibt eine größere Anzahl erlaubter Abkürzungen für
                 einige Schlüsselworte:

                 LINES    : LIN
                 COLS     : COL
                 DELAY    : DEL

                 CODEPAGE : CP, CODE         Diese Optionen werden
                 PREPARE  : PREP             auch in Verbindung mit
                 SELECT   : SEL              DISPLAY.SYS und PRINTER.SYS
                 REFRESH  : REF              in diesem Kapitel näher
                 /STATUS  : /STA             erläutert.
                                             Zusätzliche Hinweise finden
                                             sich weiter unten und in
                                             Kapitel III.16.

                 Bezüglich der Optionen für die Codeseiten-Unterstützung
                 seien noch einige (insb. für Novell DOS 7 verifizierte)
                 Anmerkungen angebracht, da diese Möglichkeiten die
                 meisten Benutzer hoffnungslos überfordern und allgemein
                 in der existierenden Literatur viel Unsinn bezüglich der
                 Codeseiten-Unterstützung von DOS verbreitet wurde...

                 Zum Prinzip:

                 Um Codeseiten-Support für MCGA-/EGA-/VGA-Anzeigen oder
                 Drucker einzurichten, muß man in CONFIG.SYS mittels
                 DISPLAY.SYS und PRINTER.SYS deklarieren, unter welchen
                 Codeseiten-Kennungen die Hardware-Codeseiten erreichbar
                 sein sollen und wieviele zusätzliche Codeseiten man
                 gleichzeitig unterstützen möchte. Mit dem Laden dieser
                 Treiber wird der hardware-abhängige residente Code der
                 Codeseiten-Unterstützung installiert und gleichzeitig
                 Platz für entsprechend große Tabellen und Datenbereiche
                 zur Aufnahme der Codeseiten- und Font-Informationen für
                 alle vorzubereitenden Codeseiten reserviert (welche
                 Codeseiten das einmal sein werden, steht zu diesem
                 Zeitpunkt noch in den Sternen). Die Codeseiten selbst
                 werden in diesem Fall noch nicht aktiviert; es gilt
                 weiterhin die Hardware-Codeseite. Später (z.B. in
                 AUTOEXEC.BAT) können die reservierten Slots mittels
                 MODE CODEPAGE PREPARE belegt werden, indem man in der
                 Parameterzeile die einzelnen Codeseiten-Slots (über die
                 Reihenfolge der Angabe der Codeseiten) mit Codeseiten-
                 Nummern aus dem Repertoire einer anzugebenen .CPI-Datei
                 verknüpft. Damit werden die jeweiligen Fonts in die von
                 den Treiber DISPLAY.SYS bzw. PRINTER.SYS dafür reservierten
                 Bereiche geladen, allerdings noch nicht an die jeweiligen
                 Geräte abgeschickt. MODE selbst bleibt hier daher nicht
                 resident im Speicher!
                 Nun kann man mittels MODE CODEPAGE SELECT oder (wegen
                 der zusätzlichen Verknüpfung mit den Landesdaten aus
                 COUNTRY.SYS nur bei zusätzlich geladenem NLSFUNC) auch
                 mit CHCP auf die so präparierten Codeseiten umschalten.
                 Die residenten Treiber DISPLAY.SYS bzw. PRINTER.SYS
                 schicken in diesem Fall in erster Linie die zugehörigen
                 Font-Daten aus ihren Datenbereichen an die jeweiligen
                 Geräte (Grafikkarte und Drucker).

                 Während die Größe der zu reservierenden Datenbereiche für
                 die Bildschirmfonts anhand deren Anzahl im voraus berechnet
                 werden kann, steht die Länge von Download-Zeichensätzen für
                 Drucker nicht unbedingt vorher fest. Dies ist auch der
                 Grund dafür, warum das einfache Ersetzen von Drucker-.CPI-
                 Dateien durch eigene .CPI-Dateien nur unter bestimmten
                 Voraussetzungen gelingt, denn der PRINTER.SYS Treiber
                 selbst enthält auch unveränderliche Teile der Sequenzen.

                 Da die Einrichtung von Codeseiten durchaus einigen
                 Speicher kostet, sollte man sich im Falle eines Falles
                 genau überlegen, ob es notwendig ist, mehr als eine
                 vorzubereitende Codeseite einzurichten, so daß man -
                 inklusive der Hardware-Codeseite - mit MODE CODEPAGE SELECT
                 oder CHCP zwischen drei und mehr Codeseiten wechseln
                 kann. Häufig benötigt man im ständigen Wechsel neben der
                 Hardware-Codeseite nur eine weitere Codeseite. Daher
                 reicht es auch aus, nur eine Codeseite vorzubereiten.
                 Sollte nun wirklich eine weitere Codeseite benötigt werden,
                 kann man auch zur Laufzeit den Slot für die vorbereitete
                 Codeseite mittels MODE CODEPAGE PREPARE durch die gewünsch-
                 te neue Codeseite ersetzen. Neu-Booten etc. ist dafür nicht
                 erforderlich. Konkret:

                 Sie arbeiten zwar meist mit der Hardware-Codeseite 437,
                 brauchen aber häufiger auch die Codeseiten 850 und 860,
                 letztere allerdings nie im schnellen Wechsel miteinander?
                 Dann sollten Sie statt zwei vorzubereitender Codeseiten

                  CONFIG.SYS:
                   DEVICE=c:\nwdos\display.sys con=(EGA,437,2)
                   DEVICE=c:\nwdos\printer.sys prn=(1050,437,2)

                  AUTOEXEC.BAT:
                   MODE con: CODEPAGE PREPARE=((850,860) c:\nwdos\ega.cpi)
                   MODE prn: CODEPAGE PREPARE=((850,860) c:\nwdos\1050.cpi)
                   NLSFUNC
                   CHCP 437
                   REM Sie können jetzt mit CHCP zwischen 437, 850 und 860
                   REM umschalten (sofern COUNTRY.SYS das unterstützt,
                   REM siehe Kapitel II.16.)...

                 nur eine Codeseite vorbereiten:

                  CONFIG.SYS:
                   DEVICE=c:\nwdos\display.sys con=(EGA,437,1)
                   DEVICE=c:\nwdos\printer.sys prn=(1050,437,1)

                  AUTOEXEC.BAT:
                   MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
                   MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
                   NLSFUNC
                   CHCP 437
                   REM Sie können jetzt mit CHCP nur noch zwischen 437 und
                   REM 850 umschalten, aber den Rest holen wir schnell
                   REM nach:

                  SWITCHCP.BAT:
                   MODE con: CODEPAGE PREPARE=((%1) c:\nwdos\ega.cpi)
                   MODE prn: CODEPAGE PREPARE=((%1) c:\nwdos\1050.cpi)
                   REM CHCP kann - abhängig vom Land - eine Fehlermeldung
                   REM ausgeben (siehe Kapitel II.16.)...
                   CHCP %1

                 In diesem rudimentären Beispiel können Sie jetzt -
                 obwohl nur eine Codeseite vorbereitet wurde - jederzeit
                 mit SWITCHCP zwischen 850, 860, etc. umschalten. Diese
                 Lösung braucht aber nur ca. halb soviel Speicherplatz
                 wie die erste Möglichkeit.

                 Auf die gleiche Weise, wie hier der Slot für die einzige
                 vorbereitete Codeseite bei Bedarf mit neuen Codeseiten
                 belegt wird, lassen sich auch einzelne Codeseiten ersetzen,
                 wenn man mehr als eine Codeseite vorbereitet hat. Im
                 DOSBOOK wird die dazu notwendige Syntax erläutert (man
                 gibt bei MODE CODEPAGE PREPARE einfach eine Liste der neu
                 zu belegenden Codeseiten in der Reihenfolge ihrer Slots an
                 und läßt dabei einfach die Slots aus, die nicht verändert
                 werden sollen).

                 Wenn Sie NLSFUNC (und CHCP) nicht sowieso benötigen,
                 können Sie auch auf das Laden von NLSFUNC verzichten
                 und die Codeseiten stattdessen mit MODE CODEPAGE SELECT
                 umschalten.

                 Zur Syntax:

                 Gibt man nur den Gerätenamen an (etwa: MODE CON: oder
                 MODE PRN: etc.), so erhält man eine Übersicht über die
                 aktuelle Konfiguration dieses Gerätes. In diesem Fall
                 sind die Parameter CODEPAGE, CP, CODE und /STATUS, /STA
                 optional. Möchte man /STATUS, /STA verwenden, muß man
                 allerdings auch CODEPAGE, CP oder CODE angeben.

                 Arbeitet sowohl mit DR DOS/Novell DOS als auch mit
                 MS-DOS/PC-DOS .CPI-Dateien, siehe auch Kapitel II.16.

   MORE.COM      Dieser Seiten-Filter wird bei Novell DOS nur noch für
                 die wenigsten DOS-Kommandos benötigt, da diese meist
                 selbst eine /P Option für seitenweise Ausgabe anbieten.

                 Andererseits liegt z.B. bei Verwendung von MORE in Ver-
                 bindung mit FOR schon ein signifikanter Unterschied
                 darin, ob man den Filter auf mehrere Ausgaben ver-
                 schiedener Kommandos gemeinsam anwendet, oder jeweils
                 die seitenweise Ausgabeoption der einzelnen Kommandos
                 selbst nutzt:

                  FOR %%x IN (config.sys autoexec.bat) DO TYPE %%x | MORE
                  FOR %%x IN (config.sys autoexec.bat) DO TYPE %%x /p

                 (Übrigens soll TYPE /p in älteren Versionen von
                 COMMAND.COM nicht sauber mit FOR zusammenarbeiten.
                 Mit Update 15 klappt's jedoch wunderbar...)

                 Kommt auch mit Dateien größer 64 KByte problemlos zurecht
                 (was für einige MS-DOS/PC-DOS Implementierungen ein Problem
                 darstellt). Auch bei Ausgabeumleitung wird die Meldung
                 "Bitte eine Taste drücken ..." auf dem Bildschirm angezeigt
                 (StdErrOut), und man muß auch tatsächlich jede Seite
                 bestätigen.
                 Bezüglich der sicheren Verwendung in Batchjobs siehe
                 Kapitel IV.6.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                    0  Hilfeschirm angezeigt
                    3  Benutzerabbruch (<Ctrl>+<c> etc.) während der
                       Eingabe (auch Eingabeumleitung).
                  255  Nach ordnungsgemäßem Ablauf, auch im Falle eines
                       Benutzerabbruchs (<Ctrl>+<c>) während der Ausgabe
                       (auch bei Ausgabeumleitung).

   MOVE.EXE      Das Kommando MOVE ist eine Mischung zwischen REN und COPY.

                 Wird eine Datei auf dem gleichen physikalischen Laufwerk
                 verschoben, so arbeitet MOVE intern genauso wie REN
                 (auch bezüglich des Handlings von Paßwörtern, nur mit dem
                 Fehler, daß aufgrund eines Bugs (getestet bis Update 15)
                 bereits in der Kommandozeile angegebene Paßwörter ignoriert
                 werden, d.h. MOVE fragt bei Bedarf explizit nach, siehe
                 Kapitel II.11.).
                 Dieses Umbenennen ist natürlich sehr viel schneller als das
                 normalerweise durchzuführende Kopieren mit anschließendem
                 Löschen des Originals, kann aber verständlicherweise nur
                 auf dem gleichen physikalischen Laufwerk angewendet werden.
                 Substitut-Laufwerke etc. werden dabei übrigens korrekt
                 berücksichtigt.
                 Da z.B. der Norton Commander beim Verschieben mit <F6>
                 keine Substitut-Laufwerke auf die physikalisch zugrunde-
                 liegenden Laufwerke zurückführt, dauert hier das Ver-
                 schieben zwischen unterschiedlichen Laufwerksbuchstaben
                 immer genausolange wie Kopieren plus anschließendes
                 Löschen. In solchen Fällen lohnt es sich also, den
                 Norton Commander zu verlassen.

                 Wird jedoch das effektive Kopieren notwendig, weil das
                 Ziel auf einem anderen Laufwerk liegt, so arbeitet MOVE
                 wie COPY + DEL. Sind die Dateien jedoch paßwortgeschützt,
                 so weicht das Verhalten davon ab: In diesem Fall wird die
                 Quelldatei nicht angetastet, dafür besitzt die Zieldatei
                 allerdings keinen Paßwortschutz mehr (im Gegensatz zu COPY
                 wird bei MOVE hier auch das Hidden-Attribut nicht gelöscht,
                 getestet bis Update 15. Es dürfte sich hier um ein oder
                 zwei kleine Bugs handeln).

                 Achtung: Unter 4DOS wird normalerweise der 4DOS-interne
                 MOVE Befehl verwendet. Hier unterscheidet sich das Ver-
                 halten nicht zwischen paßwortgeschützten Dateien und
                 normalen Dateien, und daher weicht das Verhalten bei
                 paßwortgeschützten Dateien stark von Novells externem
                 MOVE ab:
                 Solange die Datei nur umbenannt werden muß (d.h. nicht
                 über die Grenzen des physikalischen Laufwerks hinaus
                 verschoben wird) gleicht das Verhalten dem von Novell DOS.
                 Muß die Datei aber wirklich kopiert werden, so wird sie
                 im Gegensatz zu Novells MOVE an der Quelle gelöscht und
                 zum Ziel kopiert, wobei die Datei im Ziel zwar noch das
                 Hidden-Attribut besitzt, aber keinen Paßwortschutz mehr.
                 Leider berücksichtigt 4DOS dabei nicht, daß bei implizit
                 gleichen Laufwerke (wie z.B. bei Substitut-Laufwerken)
                 eventuell gar nicht kopiert, sondern nur umbenannt werden
                 muß (getestet mit 4DOS 5.5c).

                 Offensichtlich ist es nicht möglich, ein Paßwort über die
                 Laufwerksgrenzen hinweg zu übertragen. Entweder handelt es
                 sich dabei einfach um eine Nachlässigkeit bei der Implemen-
                 tierung, oder es könnte sich um eine Sicherheitsmaßnahme
                 im Kernel handeln, der es z.B. nur erlaubt, Paßwörter zu
                 setzen und abzutesten, aber nicht zu übertragen.
                 Dies wäre eine Erklärung dafür, warum Paßwörter nur dann
                 erhalten bleiben (sowohl bei Novell DOS Kommandos wie auch
                 bei 4DOS), wenn die Datei physikalisch gar nicht bewegt
                 werden muß.

                 Zu beachten ist also, daß man mit MOVE nur dann die
                 Plattenstruktur defragmentiert, wenn Dateien wirklich
                 über Laufwerksgrenzen hinweg bewegt werden müssen. D.h.,
                 wenn man Daten verschieben will, sollte man auch wirklich
                 MOVE oder REN und nicht eine Kombination aus COPY + DEL
                 verwenden.

                 Notwendige Paßwörter können - wie bei Novell DOS und
                 DR DOS üblich - durch ein Semikolon getrennt an die
                 Dateispezifikation angehängt werden:

                  d:filename.ext;password

                 (Näheres bezüglich Syntax und Fehlervermeidung in Kapitel
                 II.9., Näheres zum Dateimanagement bei PASSWORD.EXE.)

                 Wurden noch bei DR DOS beim Angabe der Option /S und einem
                 Pfad als Quelle die Verzeichnisse am Ziel nicht wieder-
                 hergestellt, so ist diese Situation unter Novell DOS ent-
                 schärft: die Verzeichnisse werden übernommen, das Quell-
                 verzeichnis bleibt erhalten. Zum Verschieben mit Löschen
                 verwendet man die Option /T.
                 Falls nicht klar ist, ob es sich bei der Zielangabe um
                 eine Datei oder ein Verzeichnis handelt, fragt der MOVE
                 Befehl explizit nach: <D> steht für Datei und <V> steht
                 für Verzeichnis (was bei anderssprachigen MOVE Dateien
                 Verwirrung stiftet). Handelt es sich bei der Quelle um
                 ein Verzeichnis, steht damit auch fest, daß auch das Ziel
                 ein Verzeichnis sein muß. Handelt es sich um eine Datei-
                 maske ist i. allg. auch klar, daß das Ziel ein Verzeichnis
                 sein muß. Handelt es sich jedoch um eine einzelne Datei,
                 kann normalerweise nicht erkannt werden, ob das Ziel eine
                 Datei oder ein Verzeichnis sein soll (es sei denn, daß
                 das Ziel bereits existiert). Gibt man jedoch im Ziel
                 einen '\' am Ende an, so ist auch klar, daß es sich um ein
                 Verzeichnis handeln muß. Der Fall, in dem MOVE nachfragt,
                 ist jedoch nicht trivial, denn die Angabe von <D> oder <V>
                 gilt natürlich nur für die deutsche Ausgabe dieses
                 Kommandos, d.h. ohne weitere Vorkehrungen ist es nicht
                 möglich, einen Batchjob zu schreiben, der in allen
                 Landesvarianten mit einer automatisierten Eingabeumleitung
                 arbeitet, aus der die Antwort auf diese Frage kommt. Da in
                 der englischen Version <F>=file und <D>=directory verwendet
                 werden, sollte man in die Datei für die Eingabeumleitung
                 die Antworten für 'Datei' in der Reihenfolge angeben, daß
                 keine Mißdeutung als 'Verzeichnis' erfolgen kann (Näheres
                 bezüglich internationaler Batchjobs siehe Kapitel II.16.).

                  REM (F und D sind gesichert, E und A nur Vermutungen!)
                  ECHO FEAD | MOVE oldfile newfile

                 Glücklicherweise akzeptiert Novells MOVE bei der besagten
                 Frage keine anderen Buchstaben als die beiden Buchstaben
                 für 'Datei' und 'Verzeichnis', so daß diese Methode wirk-
                 lich funktioniert.

                 Außerdem unterstützt MOVE über die undokumentierte Syntax
                 /U:name die Angabe eines zulässigen Benutzeranmelde- oder
                 Gruppennamens (maximal 12 Zeichen lang). Diese Option ist
                 nicht unter jedem Betriebssystem verfügbar und hat in
                 Novell/DR Multiuser-Varianten oder in Verbindung mit
                 lokalen Benutzerkonten und einmaliger Anmeldung eine
                 Bedeutung, sofern die Systemabsicherung aktiviert ist.

                 Die beiden mit MS-DOS 6.2 eingeführten Parameter /Y und
                 /-Y zur Bestätigung vor dem Überschreiben unterstützt
                 Novell DOS 7 (getestet bis Update 15) noch nicht, da es
                 viel früher eingeführt wurde.

   NLSFUNC.EXE   Dieser Treiber sollte in jedem Fall geladen werden, da er
                 vollen Zugriff auf die Länderunterstützung für alle in
                 COUNTRY.SYS enthaltenen Länder garantiert und auch für
                 CHCP benötigt wird, wenn man damit Codeseiten umschalten
                 will. Ein Großteil des residenten Codes für die Länder-
                 unterstützung ist sowieso im Kernel enthalten und wird
                 von NLSFUNC nur noch freigeschaltet, so daß das Laden des
                 Treiber auch nur sehr wenig Speicher benötigt, der auch
                 in der HMA liegen kann (ca. 900 Bytes statt ca. 2,8 KByte
                 wie bei MS-DOS). Der Treiber arbeitet auch unter DR DOS 6.0
                 "Business Update 1993" (wahrscheinlich aber nicht unter
                 früheren Versionen) und läßt sich nur unter Singleuser-
                 Varianten installieren, würde wahrscheinlich aber auch
                 in einer Multiuser-Umgebung funktionieren. Weitere Hinweise
                 in Kapitel II.16. Der Treiber akzeptiert auch COUNTRY.SYS
                 Dateien von DR DOS 5.0 und DR DOS 6.0 (diese besitzen wie
                 Novell DOS die Format-Revision R2.01), nicht aber die von
                 DR DOS 3.41 (R2.00), bei denen noch der mit DOS 4 einge-
                 führte DBCS-Support fehlte.

                 Wenn Sie NLSFUNC nicht laden, unterstützt das System
                 lediglich den Landesinformationen, die mit COUNTRY= in
                 CONFIG.SYS eingestellt wurden. Auch die Umschaltung des
                 Landes zur Laufzeit (etwa mit meinem FreeWare-Utility
                 COUNTRY.EXE aus dem Paket COUNTRY.ZIP) ist nur bei
                 geladenem NLSFUNC Treiber möglich. Die Umschaltung kann
                 je nach Codeseiteneinrichtung durchaus mehrere Sekunden
                 dauern.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  normales Ende
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)

   NWCACHE.EXE   Die Overlay-Dateien zu NWCACHE sind nicht ladbar, wenn
                 NWCACHE in CONFIG.SYS mittels INSTALL= geladen wird.
                 Entweder man ersetzt INSTALL= durch DEVICE= oder man
                 lädt NWCACHE erst in AUTOEXEC.BAT. NWCACHE.EXE/OV1/OV2
                 sind größtenteils identisch und unterscheiden sich
                 hauptsächlich in der Speichersorte, in der sie den
                 Cache-Puffer ablegen: NWCACHE.EXE dient als Wrapper
                 für alle Module, sowie speziell für den Cache im XMS,
                 NWCACHE.OV1 für EMS und NWCACHE.OV2 für den Cache im
                 konventionellen Speicher). Welches der drei Module
                 effektiv geladen wird, hängt von der gewünschten
                 Speicherverwendung (/E /L) ab. Alle drei Module sind
                 im Prinzip aber komplett eigenständig lauffähige
                 Programme (wenn man .OV? in .EXE umbenennt).
                 (Beim Vorgänger NLCACHE aus NetWare Lite waren die
                 Cache-Module von vornherein eigenständige Programme
                 NLCACHE?.EXE, z.B. siehe Update-Archiv NWL11G.EXE.)

                 Die Verwendung der verschiedenen Speichersorten für die
                 einzelnen Bestandteile ist durch die Vielfalt etwas ver-
                 wirrend, wenn auch sehr gut gelöst:

                 - Programmcode (Stub 5 KByte + Hauptteil variabel):
                             Mit DPMS ist der unterhalb des ersten MegaByte
                             verbleibende Hauptteil 5 KByte, mit EMS
                             ca. 8 KByte und mit XMS ab ca. 8 KByte mit
                             zunehmender Cache-Größe noch etwas weiter
                             steigend.
                    /ML      für beide Teile im unteren Speicher
                    /MU      für beide Teile im UMB-Speicher (im unteren
                             Speicher, falls keine UMBs verfügbar)
                    /MLX     für Stub im unteren Speicher und Hauptteil im
                             Extended Memory, angesprochen über DPMS. Falls
                             kein DPMS verfügbar ist, über XMS oder INT15h,
                             sonst auch im unteren Speicher.
                    /MUX     wie /MLX, nur - falls möglich - mit Stub in
                             UMBs.

                 - Hauptpuffer (max. 7 MByte):
                             normalerweise in XMS (via DPMS???)
                             Bemerkung: Angeblich soll Calderas NWCACHE 1.02
                             auch größere Cache-Puffer als 7 MByte akzep-
                             tieren, wenn man die Parameterzeile per Hand
                             modifiziert. Bisher kann ich dies jedoch noch
                             nicht bestätigen. Evtl. hängt dies aber auch
                             von der Cluster-Größe der gepufferten Parti-
                             tionen ab, und wäre daher nur auf sehr großen
                             Partitionen möglich (was ich aber ebenfalls
                             nicht nachvollziehen konnte)???
                    /X:adr   wahlweise Extended Memory über INT15h oder
                             direkt???
                    /E       im EMS
                    /L       im unteren Speicher

                 - Vorausschauender Puffer (4 - 16 KByte):
                    /BE:size im EMS-Speicher (nur möglich mit /E)
                    /BU:size im UMB-Speicher (evtl. nicht möglich mit /L)
                    /BL:size im unteren Speicher

                 NWCACHE besitzt zwei gesperrte undokumentierte Optionen
                 /HMA (vorgesehen, um die Cache-Tabellen in der HMA unter-
                 zubringen) und /NOXMS (für den Ausschluß der XMS-Nutzung).
                 Obwohl intern einige Vorbereitungen für diese Optionen
                 getroffen wurden, existieren leider in keinem der drei
                 Module weder Auswerteroutinen für diese Parameter, noch der
                 Code für die entsprechende Spezialbehandlung (/HMA wäre
                 das Tüpfelchen auf dem "i" ;-), /NOXMS ist eigentlich
                 obsolet, da die Verwendung des Speichers über die
                 vorhandenen Optionen ebenso gut eingestellt werden kann).
                 Dies gilt auch noch für Caldera OpenDOS 7.01 mit NWCACHE
                 v1.02. Die in der Sekundärliteratur teilweise zitierten
                 Optionen /MH und /MHX (ebenfalls für HMA) existieren in
                 den offiziell ausgelieferten Versionen von NWCACHE jeden-
                 falls nicht. (Im Tutorial NWCH_TUT.TXT, das offenbar auf
                 der Beta 12 von NWCACHE basierte, wurde übrigens behauptet,
                 mit der Option /B[x]=0 könnte man die vorausschauende
                 Pufferung abschalten und für den Betrieb unter MS Windows
                 wäre /DELAY=OFF zwingend notwendig. Beides kann ich nicht
                 bestätigen, und soweit ich weiß, schaltet NWCACHE
                 automatisch in den Durchschreibemodus, sobald MS Windows
                 gestartet wird.)

                 Der Vorgänger NLCACHE aus NetWare Lite konnte unter be-
                 stimmten Umständen die HMA verwenden. Obwohl die Codebasis
                 und das Grundprinzip der Aufteilung weitestgehend identisch
                 war, unterstützte er z.B. noch kein DPMS und einige andere
                 Funktionen fehlten ebenfalls. Zudem besaß er ein reichlich
                 verwirrendes Kommandozeilen-Interface, das sich nahezu
                 vollkommen von NWCACHEs Optionen unterscheidet. Aus diesem
                 Grund gab es sogar ein eigenes Konfigurationsprogramm für
                 NLCACHE. Einige Spezialbehandlungen, die sich bei NLCACHE
                 noch wählen ließen (etwa bei inkompatiblen Festplatten-
                 BIOSen mit großen Platten nur die ersten 256 MByte zu
                 cachen, und verschiedene Integritätskontrollen z.B. für
                 langsame EMS-Karten), kennt NWCACHE nicht mehr. Entweder
                 sind nur entsprechende Parameter weggefallen und der
                 Treiber erkennt diese Sonderfälle nun automatisch, oder
                 Sie sollten bei Schwierigkeiten mit NWCACHE auf ganz alten
                 Rechner einfach einmal NLCACHE ausprobieren (vorausgesetzt,
                 Sie sind Besitzer von NetWare Lite, dann ist das Update
                 NWL11G.EXE sicherlich für Sie interessant).

                 Das Modul NWCACHE.OV1 wertet darüber hinaus die Option /A20
                 nicht aus, das Modul NWCACHE.OV2 kennt neben /A20 auch
                 /LEND nicht. Die anderen Parameter werden nicht zurück-
                 gewiesen, aber für NWCACHE.OV2 ist z.B. /CHECK obsolet.

                 Achtung: Wenn Sie NWCACHE direkt als zu einer .EXE-Datei
                 umbenanntes .OV1/.OV2-Modul geladen haben und nun wieder
                 entladen wollen, müssen Sie dafür das gleiche Modul ver-
                 wenden, ansonsten wird eine Fehlermeldung ausgegeben.

                 Entgegen dem Hilfeschirm ist es mit NWCACHE 1.01(.1)
                 offenbar nur eingeschränkt möglich, den DELAY-Wert nach
                 der Erstinstallation zu ändern (ON|OFF ist möglich und
                 wird auch in der Statusmeldung bestätigt). Damit ein
                 geänderter Zeitwert für DELAY auch in der Meldung auf-
                 taucht, muß der Cache vorher entladen werden. Allerdings
                 ändert sich sehr wohl das Pufferungsverhalten von Floppies:
                 Bei sehr kleinen DELAY-Werten (auf einem 386sx18 ca.
                 50ms..58ms, auf einem 386sx16 gar nur 50ms..55ms) werden
                 diese Laufwerke im gepufferten Schreibmodus benutzt, sonst
                 nur im Durchschreibmodus (wie auch in der Statusmeldung
                 aufgeführt). Dies deutet darauf hin, daß die Änderung des
                 DELAY-Wertes auch zur Laufzeit durchaus möglich ist, nur
                 in der Zeitangabe der Statusmeldung nicht explizit geändert
                 wird.
                 Reicht der gültige Wertebereich von 50..5000ms nicht aus,
                 sollte es möglich sein, zumindest den Maximalwert (1388h)
                 zu patchen (drei Vorkommen pro Datei, das dritte Vorkommen
                 ist der Default-Wert; nicht ausprobiert!).

                 Für optimale Performance sollten Sie /FLUSH=OFF einstellen,
                 was aber auch nicht ganz ungefährlich ist, wenn Sie den
                 Rechner nach der Arbeit ohne Wartepause am Prompt (ca.
                 10 Sekunden) einfach ausschalten oder einen inkompatiblen
                 Tastaturtreiber einsetzen, der vor einem Boot-Vorgang via
                 <Ctrl>+<Alt>+<Del> die Cache-Puffer nicht ausschreiben
                 läßt (K3PLUS 6.18p5+ bzw. FreeKEYB unterstützen diese
                 Funktion in vollem Umfang). In Verbindung mit 4DOS/NDOS
                 sollten Sie die Einstellung SDFlush=Yes|No in der
                 4DOS.INI/NDOS.INI Datei entsprechend einstellen (siehe
                 Kapitel VII.3.).

                 Frühe NWCACHE Versionen gaben in der /S Übersicht teilweise
                 (mit VERIFY ON) ziemlichen Unsinn für gesparte Schreib-
                 zugriffe aus (astronomisch hohe Zahlen, aber 0%). Dies
                 wurde mit Update 13 korrigiert. Allerdings zeigt NWCACHE /S
                 immer noch keine gesparten Schreibzugriffe an, solange
                 VERIFY ON ist. Da es eigentlich auch mit VERIFY ON eine
                 (geringere) Anzahl einzusparender Schreibzugriffe geben
                 'könnte', ist dies nicht ganz einsichtig. Andererseits
                 weist Novell ausdrücklich darauf hin, daß VERIFY ON
                 jeglichen Cache-Bemühungen entgegenläuft und daher bei
                 Verwendung von NWCACHE oder NetWare-Anbindung ausgeschaltet
                 werden sollte (mehr zu diesem Thema in Kapitel II.14.).
                 Mit VERIFY OFF verbessert sich die NWCACHE Performance
                 jedenfalls drastisch, was sich insbesondere bei sehr
                 langsamen Laufwerken bemerkbar macht (s.u.).
                 Achtung: Die mit Caldera OpenDOS 7.01 ausgelieferte
                 Version NWCACHE v1.02 enthält diesen alten Bug nun wieder,
                 obwohl der bei Novell DOS mit NWCACHE v1.01 beseitigt
                 wurde (intern enthalten alle diese Ausgaben eine alte
                 Angabe VeRsIoN=1.01.1 von 1993).

                 Offiziell ist die maximale Laufwerks- (oder Partitions-
                 größe???), die NWCACHE bearbeiten kann, ein Gigabyte.
                 Darüber können angeblich nur noch Floppies gepuffert
                 werden, der Treiber sollte dann unmittelbar nach
                 HIMEM/EMM386/DMPS in CONFIG.SYS geladen werden. Vielleicht
                 wurde diese Schranke mit einem Update beseitigt, denn
                 ich konnte NWCACHE aus Update 15/2 auf einer 3.2 GByte
                 Festplatte mit einer (testweise installierten) 2 GByte
                 Partition erfolgreich und stabil einsetzen.

                 NWCACHE kann alle Laufwerke cachen, die via Blocktreiber
                 ins System eingebunden sind (d.h. aber keine CD-ROMs,
                 die via Umadressierer eingebunden sind, daher auch keine
                 entfernten Netzlaufwerke). Daran hat sich auch mit
                 NWCACHE v1.02 aus Caldera OpenDOS 7.01 noch nichts ge-
                 ändert. Eine Abhilfe bieten z.B. spezielle CD-ROM-Caches
                 von Drittanbietern, etwa CD-Quick (CDQ.EXE), die auch mit
                 meinem INSTCDEX.EXE Utility problemlos funktionieren,
                 allerdings bei Verwendung des DPMS-nutzenden NWCDEX statt
                 MSCDEX einen schmerzlichen Verlust von kostbarem DOS-
                 Speicher bewirken (aber mit SMARTDRV und/oder MSCDEX sind
                 Sie auch nicht besser bedient...).

                 Wenn Sie z.B. über einen Tape-Streamer verfügen, der sich
                 über Treiber als (extrem langsame) 'Harddisk' wahlfrei an-
                 sprechen läßt (z.B. 2x33 MByte HP9142 mit DC-600 Medien an
                 HP-IB/GP-IB/IEEE-488-Karte), so können damit schon nach
                 kurzer Betriebszeit die Wartezeiten (normalerweise bis zu
                 mehrere Minuten für einen Verzeichniswechsel!) drastisch
                 verkürzt werden. Bei derartig langsamen 'Laufwerken' ist
                 es übrigens zweckmäßig, den Schreib-Cache explizit zu
                 aktivieren (falls NWCACHE das während der Installation
                 noch nicht von selbst macht) und VERIFY OFF zu setzen.
                 (Bei obigem Streamer dauerte ein 30 MByte Backup mit dem
                 Norton Commander bzw. COPY ohne NWCACHE und mit VERIFY ON
                 etwa 3 Tage (BUFFERS=3, FASTOPEN=0), mit NWCACHE (mit
                 Schreib-Cache) und VERIFY ON etwa 2 Tage und als letzte
                 Alternative mit VERIFY OFF ca. 7 Stunden. ;-) )

                 Diese Ergebnisse lassen übrigens darauf schließen, daß
                 VERIFY ON|OFF bei Novell DOS 7 (und auch schon bei DR DOS)
                 wirklich einschneidende Überprüfungen vornimmt. Mehr dazu
                 in Kapitel II.14.

                 Übrigens ist NWCACHE in einigen Punkten kompatibel zu
                 SMARTDRV: Das SMARTDRV 4.0+ API wird größtenteils nach-
                 gebildet. Daher braucht NWCACHE auch nicht aus der Kon-
                 figuration entfernt werden, wenn etwa ein Defragmentierer
                 wie PC-Tools COMPRESS/OPTIMIZR warnt, alle Caches außer
                 SMARTDRV usw. (aber nicht NWCACHE) zu entfernen. Ich
                 hatte mit NWCACHE noch nie diesbezügliche Probleme mit
                 derartigen Pflegeprogrammen.

   NWCDEX.EXE    Speicheroptimierter (weil DPMS-nutzender) Ersatz für
                 Microsofts MSCDEX.EXE, siehe auch Kapitel II.3. und V.4.
                 Arbeitet auch mit DR DOS 5.0 und 6.0 (nicht aber mit 3.41).

                 Da NWCDEX im DOSBOOK nicht dokumentiert ist, müssen Sie
                 auf die eingebaute Hilfe ausweichen, die NWCDEX /? selbst
                 ausgibt. NWCDEX unterstützt - dokumentiert - alle Parameter
                 von MSCDEX.EXE sowie einige eigene Optionen. Der Parameter
                 /L:driveletter kann bei NWCDEX auch einen Doppelpunkt
                 enthalten (etwa /L:E:), da MSCDEX dies aber nicht akzep-
                 tiert, sollten Sie darauf verzichten.

                 Sogar die MSCDEX-Option /S (zum CD-ROM-Sharing in Ver-
                 bindung mit MS-NET oder MS Windows for Workgroups) wird -
                 undokumentiert - nicht zurückgewiesen (getestet mit Update
                 15), ändert bei NWCDEX aber absolut nichts am Speicher-
                 verbrauch, könnte also ein Dummy sein (MSCDEX benötigt
                 ca. 0,5 KByte mehr, wenn die /S Option angegeben wurde). Im
                 Zweifelsfall schadet die Angabe bestimmt nicht. NWCDEX.EXE
                 erlaubt in jedem Fall das Sharing des CD-ROM-Laufwerks in
                 Verbindung mit PNW (andere Netze noch nicht getestet,
                 Hinweise willkommen).
                 MSCDEX ändert mit /S die Unterstützung von TRUENAME:
                 Normalerweise werden CD-ROM-Laufwerke in einer speziellen
                 Variante der UNC-Notation angegeben (z.B. \\D.\A.), jeden-
                 falls wird das Laufwerk über diesen Pfad in der CDS
                 (Current Directory Structure) referenziert. Obwohl sich
                 daran auch mit /S nichts ändert, ergibt TRUENAME interes-
                 santerweise auch für das CD-ROM-Laufwerk einen normalen
                 Pfad (z.B. D:\). Obwohl MSCDEX unter MS-DOS problemlos
                 mit der Option /S aufgerufen werden kann, wird das Laden
                 des Treibers (meiner bisherigen Erfahrung nach) mit der
                 Option /S unter Novell DOS immer zurückgewiesen, auch bei
                 installiertem SHARE.

                 Sollen mehrere CD-ROMs ins System eingebunden werden,
                 kann man die Angabe /D:name mehrfach angeben. Möchte man
                 das gleiche Laufwerk unter mehreren Buchstaben ansprechen,
                 so ist sogar die mehrfache Ankopplung an den gleichen
                 Hardware-Treiber möglich.

                 NWCDEX/MSCDEX sollte vor den Netztreibern geladen werden,
                 zwingend notwendig ist dies aber nicht.

                 Es gibt einige Installationsprogramme von CD-ROM-Laufwerken
                 (z.B. 4fach-speed CD-ROM-Laufwerke von Mitsumi), die die
                 Konfigurationsdateien nach einem MSCDEX-Treiber durchsuchen
                 und nicht funktionieren, wenn Sie das Gegenstück NWCDEX von
                 Novell benutzen. In solchen Fällen sollten Sie NWCDEX.EXE
                 kurzfristig in MSCDEX.EXE umbenennen oder die Installation
                 manuell vornehmen. Das Problem ist lediglich in der Igno-
                 ranz solcher Installationsprogramme begründet und ist kein
                 Kompatibilitätsproblem: Die CD-ROM-Laufwerke funktionieren
                 natürlich genausogut mit NWCDEX wie mit MSCDEX!

                 Einzige Designschwäche: Während der Initialisierung be-
                 nötigt der Treiber enorm viel freien Speicher. Obwohl es
                 mit geladenem DPMS (oder CLOAKING, siehe Kapitel II.4. bei
                 DPMS) kein Problem ist, die unter DOS benötigte Größe des
                 residenten Codes von ca. 83 KByte auf 7 KByte schrumpfen
                 zu lassen (MSCDEX benötigt hier noch über das Doppelte
                 (16 KByte) und kann sich nicht ohne Weiteres auslagern),
                 ist es enorm schwierig, diese restlichen 7 KByte in den
                 UMBs zu verstauen.
                 Interessanterweise ist der insgesamt benötigte Speicher-
                 bedarf beider Treiber bis auf ca. ein KiloByte gleich, mit
                 dem Unterschied, daß man NWCDEX besser auslagern kann.
                 Trotzdem:
                 In den allermeisten Fällen wird sich der Treiber nicht
                 hochladen können und belegt dann diese 7 KByte im Basis-
                 speicher (wo er besonders stört). Offenbar kann der
                 Treiber nur dann hochgeladen werden, wenn zum Zeitpunkt
                 der Initialisierung der komplette Code in den UMBs unter-
                 gebracht werden kann, auch wenn er später nur besagte
                 7 KByte benötigt.
                 Vielleicht kann man hier mit QEMMs Squeeze-Technik etwas
                 ausrichten, unter EMM386 konnte ich jedoch noch keine DOS-
                 eigene Lösung für dieses Hochladeproblem finden.

                 Mit MEM direkt vor dem Aufruf des NWCDEX-Treibers können
                 Sie feststellen, wieviel UMB-Speicher ggf. fehlt, um NWCDEX
                 hochzuladen. Sollten auf Ihrem System nur 4 KByte oder
                 weniger fehlen, können Sie folgenden Trick versuchen:

                  PKLITE NWCDEX.EXE -x

                 entpackt den NWCDEX.EXE-Treiber auf Originalgröße und
                 streift den PKLITE-Selbstentpacker von der Datei NWCDEX.EXE
                 ab. Da nun dieser Selbstentpacker während der Ladephase
                 des Treibers nicht *auch* noch Speicher benötigt (maximal
                 4 KByte bei PKLITE 1.xx, jedoch bis zu 85 KByte bei PKLITE
                 2.xx), kann es sein, daß NWCDEX.EXE nun gerade doch noch
                 hochgeladen werden kann.

                 Wegen dieses Hochladeproblems ist es besonders ärgerlich,
                 daß NWCDEX (wie auch MSCDEX, von MS-DOS 7 abgesehen)
                 normalerweise nicht in CONFIG.SYS geladen werden kann, wo
                 i. allg. noch mehr als genug UMB-Speicher zur Verfügung
                 steht. Daß der Treiber in CONFIG.SYS nicht geladen werden
                 kann, liegt daran, daß oft nicht genügend Laufwerksbuch-
                 staben zur Verfügung stehen. Die CONFIG.SYS Einstellung
                 LASTDRIVE= wirkt erst *nach* der Abarbeitung der CONFIG.SYS
                 (mehr zu LASTDRIVE= in Kapitel III.1. und III.2.). So kommt
                 es, daß NWCDEX (als auch MSCDEX) oft die Meldung 'Kein
                 Laufwerksbuchstabe verfügbar' ausgibt, wenn Sie versuchen,
                 NWCDEX.EXE etc. per INSTALL=/INSTALLHIGH= etc. zu laden.
                 Das Laden per DEVICE=/DEVICEHIGH= etc. scheitert daran,
                 daß NWCDEX und MSCDEX keinen entsprechenden Treiberkopf
                 bereitstellt.

                 Um diesem Problem abzuhelfen und dadurch NWCDEX (oder
                 MSCDEX) doch komplett hochladen zu können, habe ich ein
                 kleines Utility namens INSTCDEX.EXE geschrieben, das alle
                 diese Probleme löst, indem es ermöglicht, einen bereits
                 benutzten Laufwerksbuchstaben wieder für ungültig zu er-
                 klären (was man natürlich nur mit Bedacht für Dummy-
                 Laufwerke anwenden sollte) oder selbst die Laufwerkstabelle
                 erweitert, um dadurch das Laden von Umadressierern wie
                 NWCDEX/MSCDEX bereits in CONFIG.SYS zu erlauben. Damit ist
                 das CD-ROM-Laufwerk in CONFIG.SYS bereits ansprechbar
                 (nachweisbar mit INSTALL=c:\nwdos\command.com). Auf diese
                 Weise können sogar in CONFIG.SYS Treiber direkt von CD-ROMs
                 geladen werden! Da beim endgültigen Laden des Kommando-
                 prozessors auf dem üblichen Weg (SHELL=) nach CONFIG.SYS
                 unter Novell DOS (nicht bei MS-DOS) die internen Laufwerks-
                 tabellen verschoben und erneut verändert werden, würde
                 das CD-ROM-Laufwerk aber in AUTOEXEC.BAT und später wieder
                 abgekoppelt sein. Auch mit diesem Problem wird INSTCDEX.EXE
                 fertig, indem es ermöglicht, den aktuellen Status des
                 Laufwerks in einer Datei C:\CDS_?.DAT zu speichern und
                 später wieder zu laden.

                 Beispiel zum Hochladen von NWCDEX.EXE in CONFIG.SYS:

                  CONFIG.SYS:

                   REM (EMM386.EXE/DPMS.EXE bereits geladen...)
                   DEVICEHIGH=c:\sys\cdrom\mscd001.sys /d:mscd001 ...
                   REM Laufwerksbuchstaben bereitstellen (hier H:=7)...
                   DEVICEHIGH=c:\nwdos\DRIVER.SYS /d:7 /f:7
                   DRIVPARM=/d:7 /c /f:8 /n
                   INSTALL=INSTCDEX.EXE /prepare /drive=h
                   REM Nun kann NWCDEX doch geladen werden, denn der bereit-
                   REM gestellte Laufwerksbuchstabe H: ist wieder verfügbar.
                   INSTALLHIGH=c:\nwdos\nwcdex.exe /d:mscd001 /m:32 /l:h ...
                   REM Nur bei Novell DOS notwendig:
                   INSTALL=INSTCDEX.EXE /cdrom /save /drive=h

                  AUTOEXEC.BAT:

                   REM CD-ROM-Laufwerk ist nicht mehr ansprechbar...
                   REM Nur bei Novell DOS notwendig:
                   INSTCDEX.EXE /restore /drive=h
                   REM Nun ist das CD-ROM-Laufwerk wieder ansprechbar...

                 Falls Sie auf diese Art und Weise mehr als ein CD-ROM-
                 Laufwerk einbinden wollen (/D: siehe oben), müssen Sie
                 entsprechend viele Laufwerke mit INSTCDEX.EXE präparieren.
                 Unter Novell DOS und Caldera OpenDOS gibt es sogar noch
                 eine (unsaubere) Methode, ganz auf den zusätzlichen
                 Treiber zu verzichten: Hierzu dient die INSTCDEX-Option
                 /LASTDRIVE. Näheres zu INSTCDEX findet sich in dem Archiv
                 INSTCDEX.ZIP.

                 NWCDEX (getestet bis Update 15) setzt im Gegensatz zu
                 MSCDEX in seinem CDS-Eintrag nicht das 'Local CD-ROM-Bit'.
                 Daher könnte theoretisch das Laufwerk fälschlicherweise
                 in Netzlaufwerksauflistungen auftauchen (allerdings für
                 PNW nicht notwendig), sicherheitshalber können Sie mit
                 Hilfe von INSTCDEX.EXE /CDROM dieses Bit nachträglich
                 setzen. Dieses Bit hat nichts mit der Option /S zu tun.

                 Zu guter Letzt noch eine Anmerkung am Rande (die Details,
                 die zu diesem Verhalten führen, sind noch nicht genauer
                 eingekreist): Wechselt man eine CD-ROM-Medium, während
                 man sich auf dem zugehörigen CD-ROM-Laufwerk in einem
                 Unterverzeichnis befindet, so synchronisiert der Kernel
                 erst dann auf die Verzeichnisstruktur des neuen Mediums
                 (d.h. dessen Wurzelverzeichnis), wenn man explizit darauf
                 wechselt (z.B. mit "CD\"). Alle anderen Dateioperationen
                 auf dem Laufwerk werden mit 'Ungültiger Pfad' zurückge-
                 wiesen; der Pfad bleibt auf der Einstellung für das vor-
                 herige Medium stehen und kann 'weiterverwendet' werden,
                 wenn man das zugehörige Medium wieder einlegt. Nicht ganz
                 unlogisch, aber auch nicht unbedingt ergonomisch in jeder
                 Situation.

                 Und noch ein interessanter Hinweis: Der CD-ROM-Umadres-
                 sierer IMSCDEX aus IMS REAL/32 (einem Nachfolger von
                 DR Multiuser DOS), ist nichts weiter als eine modifizierte
                 Fassung von Novells NWCDEX.EXE (1.00).

   PASSWORD.EXE  Einstellen und Löschen von Datei-, Pfad-, und globalen
                 Paßwörtern (wie auch bei DR DOS), aber zusätzlich auch
                 die Angabe eines Anmeldungspaßwortes (im Rahmen des
                 Features der 'einmaligen Anmeldung' unter Zuhilfenahme
                 der SECURITY-Datenbank).

                 Alle dateibezogenen Novell DOS Kommandos, die bei ihrer
                 Bearbeitung auf paßwortgeschützte Dateien/Pfade stoßen
                 könnten, erlauben nach der Angabe der Dateispezifikation
                 - getrennt durch ein Semikolon - die optionale Angabe
                 des jeweiligen Paßwortes (dies wird zwar im DOSBOOK
                 beschrieben, ist aber ansonsten fast undokumentiert).
                 Außerdem ist die gleiche Schreibweise auch innerhalb
                 der Eingabemasken von beliebigen Fremdprogrammen erlaubt,
                 falls diese nicht in Unkenntnis von Novells Feature das
                 Semikolon als ungültiges Zeichen zurückweisen. Diese
                 erweiterte Syntax war auch schon bei DR DOS vorhanden.
                 Das Ganze funktioniert auch in DOS-Boxen von Windows
                 und betrifft sogar die Windows-Anwendungen selbst, falls
                 diese unter Novell DOS oder DR DOS laufen.

                 Beispiele:

                  Für Novells COMMAND.COM und externe Kommandos:

                  DIR c:\autoexec.bat;password

                  Unter 4DOS ist die Angabe von DR DOS/Novell DOS-
                  Paßwörtern ebenfalls möglich, wegen der Kollision mit
                  deren Dateilisten (inclusion list) muß das Semikolon
                  allerdings bei (fast allen) 4DOS.COM internen Kommandos
                  verdoppelt werden:

                  DIR c:\autoexec.bat;;password

                  Tricks zur Vermeidung dieser Kompatibilitätsschwäche
                  in Kapitel II.9. (Achtung: Verwenden Sie nicht 4DOS 5.51/
                  5.52a TYPE mit paßwortgeschützte Dateien: Aufgrund eines
                  Bugs in 4DOS stürzt sonst der Rechner ab.)

                 Wie offiziell dokumentiert, werden Paßwörter mit PASSWORD
                 gesetzt, überprüft und gelöscht (wobei das Überprüfen etwa
                 mit PASSWORD *.* nicht mit geschützten Verzeichnissen
                 funktioniert). Die erweiterte Syntax mit Semikolon dient
                 hingegen dazu, das Paßwort beim Zugriff auf die Dateien und
                 Verzeichnisse angeben zu können (wenn sie nicht mit dem
                 globalen Paßwort übereinstimmen). Undokumentiert ist aller-
                 dings die Möglichkeit, mit dieser erweiterten Syntax auch
                 implizit Paßwörter zu *setzen*:

                 Beispiele:

                  ECHO Hello World!> c:\test.txt;password

                  setzt implizit das PASSWORD /R:password für die erzeugte
                  Datei c:\test.txt (Inhalt: "Hello World!")

                  COPY c:\test.txt;password c:\test2;newpassword

                  Genauso ist es möglich, mit COPY oder MOVE Befehlen auch
                  direkt ein neues Paßwort für die Zieldatei anzugeben, denn
                  wie noch gezeigt wird, wird der Schutz dabei normalerweise
                  aufgehoben.

                  MD c:\test;password

                  setzt implizit das PASSWORD /P:password für das erzeugte
                  Verzeichnis c:\test\

                 Obwohl dies im Großen und Ganzen auch unter 4DOS funktio-
                 niert, gibt es dort noch einige Schwierigkeiten, so daß
                 man bei gemischten Systemen auf diese implizite Angabe
                 von neuen Paßwörtern verzichten sollte: Teilweise akzep-
                 tiert 4DOS hier nur ein Semikolon und nicht die Verdop-
                 pelung (etwa bei CD), außerdem können Paßwörter bei 4DOS
                 nicht in Umleitungen verwendet werden. Der Befehl

                  ECHO Hello World!> c:\test.txt;;password

                 bewirkt bei 4DOS etwas völlig anderes als bei COMMAND.COM:
                 Die erzeugte Datei c:\test.txt enthält
                 "Hello World! ;;password" statt "Hello World!". Es dürfte
                 sich hier um einen Bug in 4DOS handeln (4DOS.COM 5.5c,
                 5.51, 5.52a), vgl. auch Kapitel II.11.

                 Ein echtes Problem entsteht unter 4DOS, wenn man auf
                 paßwortgeschützte Dateien zugreifen möchte, die in paß-
                 wortgeschützten Verzeichnissen liegen. Der Novell DOS
                 Kernel will hier (aufgrund der 4DOS-internen Behandlungs-
                 weise) grundsätzlich *beide* Paßwörter wissen (auch dann,
                 wenn man sich bereits im jeweiligen Verzeichnis befindet).
                 Unter Novells COMMAND.COM wird dies - von ausführbaren
                 Dateien abgesehen - normalerweise nicht benötigt, wenn
                 man sich bereits im entsprechenden Verzeichnis befindet.
                 Aber auch, wenn man von außen auf eine solche Datei zu-
                 greifen will, gibt es unter Novell DOS' und DR DOS'
                 COMMAND.COM eine zwar einleuchtende, aber undokumentierte
                 Eingabevariante:

                  c:\testdir            sei paßwortgeschützt mit
                                        Paßwort "hello" und
                  c:\testdir\dummy.txt  sei paßwortgeschützt mit
                                        Paßwort "world"

                  TYPE c:\testdir;hello\dummy.txt;world    funktioniert!!!

                 Diese Schreibweise (oder die Verwendung von später noch
                 vorzustellenden Master-Paßwörtern) ist *immer* notwendig,
                 wenn es darum geht, Programmdateien zu starten, die in
                 paßwortgeschützten Verzeichnissen liegen, selbst dann,
                 wenn man sich bereits in dem entsprechenden Verzeichnis
                 befindet.

                 Unter 4DOS wird diese besondere Form der Dateispezifikation
                 zurückgewiesen (auch mit verdoppeltem Semikolon).

                 Außerdem ist problematisch, daß Paßwörter unter MS-DOS und
                 PC-DOS generell als Eingabefehler zurückgewiesen werden.
                 Dieses Problem läßt sich für Batchjobs, die unter jedem DOS
                 funktionieren sollen, auf zwei Weisen aus dem Weg räumen:
                 Entweder man verzichtet auf diese Syntax und arbeitet mit
                 ständig anzupassenden globalen Paßwörtern (PASSWORD /G).
                 Die andere Möglichkeit besteht darin, die Paßwörter in
                 Umgebungsvariablen unterzubringen. Dies wird in Kapitel
                 II.9. ausführlicher beschrieben.

                 Da man mit den gespeicherten Einzelpaßwörtern keine Datei-
                 gruppen bearbeiten könnte, kann man mit PASSWORD auch ein
                 'globales' Paßwort definieren, das automatisch bei allen
                 Paßwortabfragen eingesetzt wird. Dieses Paßwort bleibt im
                 laufenden System (nicht auf der Festplatte) aktiv, bis es
                 wieder aufgehoben wird oder bis man den Rechner neu bootet.
                 Zwischenzeitlich kann man trotzdem mit expliziten anderen
                 Paßwörtern arbeiten.

                 Da unter Windows die wenigsten Programme in Dateieingabe-
                 masken die Angabe eines Semikolon akzeptieren, werden Sie
                 besonders hier auf die Angabe eines Master-Paßwortes
                 (PASSWORD /G) ausweichen müssen. Da im laufenden System
                 nur ein Master-Paßwort existiert (auch in unterschiedlichen
                 Tasks eines Multitaskers) können Sie zu diesem Zweck auch
                 problemlos eine DOS-Box öffnen und dort das Master-Paßwort
                 angeben, das sofort auf alle Windows- und DOS-Applikationen
                 wirkt.

                 Der Paßwortschutz kann (bei Novell DOS 7) 'offiziell' drei
                 verschiedene Hierarchieebenen umfaßen:

                 /R:password  Schutz vor allen Operationen (auch Lesen=Read)
                              (/P: für Verzeichnisse wirkt im Prinzip wie
                              /R: für Dateien)
                 /W:password  Schutz vor Schreiben und Modifizieren (Write)
                              Kann Gelesen und
                 /D:password  Schutz vor Löschen, Umbenennen und Verschieben

                 Da es hier auch in der Literatur immer wieder Verwechsel-
                 ungen gab: Es besteht ein signifikanter Unterschied darin,
                 ob alle Dateien eines Verzeichnisses mit einem Paßwort
                 geschützt werden, oder ob das Verzeichnis selbst paßwort-
                 geschützt wird!
                 Angenommen, C:\TESTDIR\ sei das Verzeichnis:

                 PASSWORD c:\testdir /R:test    schützt alle Dateien aus
                                                c:\testdir\*.* mit "---",
                 PASSWORD c:\testdir /P:test    läßt die Dateien in
                                                C:\TESTDIR völlig in Ruhe
                                                (können eigenen Paßwort-
                                                schutz besitzen oder auch
                                                nicht) und versieht das
                                                Verzeichnis C:\TESTDIR\
                                                selbst mit dem Paßwort-
                                                schutz "---"

                 Groß-/Kleinschreibung bei der Angabe von Paßwörtern wird
                 ignoriert. Bezüglich sinnvoller Namensvergabe für Paßwörter
                 siehe Kapitel VI.7.

                 Achtung: Der Umfang des Paßwortschutzes wird bei
                 Novell DOS 7 PASSWORD mit Masken wie "---", "RWD", usw.
                 angegeben. Hier besteht große Verwechselungsgefahr:
                 DR DOS 6.0 PASSWORD gab die Bits nämlich noch genau
                 invertiert an!
                 D.h. bei DR DOS wurde ein "-" angezeigt, wenn der Paßwort-
                 schutz für die jeweilige Operation NICHT gesetzt war
                 (irgendwie logisch), normale Dateien hatten also "---".
                 Bei Novell DOS 7 werden stattdessen die 'Rechte' an der
                 Datei ohne Angabe eines Paßwortes angegeben, d.h. normale
                 Dateien haben "RWD". Obwohl ich persönlich die alte Logik
                 bevorzuge (da sie der internen Realisierung in der API-
                 Funktion und der Verzeichnisstruktur entspricht, wohlge-
                 merkt bei DR DOS *und* Novell DOS), verwende ich in diesen
                 Dokumenten (außer in DRDOS6UN.TXT und DRDOSTIP.TXT) die
                 neue Schreibweise, wie von Novell DOS 7 verwendet.

                 Noch alles klar? ;-)

                 Möchte man ein Paßwort wieder aufheben, benutzt man
                 üblicherweise PASSWORD /N, das automatisch bei allen
                 paßwortgeschützten Dateien nach dem Paßwort fragt. Der
                 Parameter /N erlaubt jedoch keine direkte Angabe des
                 Paßwortes: Könnte man die Angabe jedoch auch über die
                 Dateispezifikation vornehmen (Wildcards, Listendateien
                 und Dateilisten sind erlaubt), so kann man die Angabe
                 auch vorweg vornehmen (etwa in Batchjobs), z.B.:

                  PASSWORD *.txt;password /N

                 Paßwörter können nicht über ein Netzlaufwerk vergeben/
                 verschickt werden (wäre ja auch unsicher, die in der
                 Dateispezifikation enthaltenen Paßwörter unverschlüsselt
                 über das Netz zu senden). Der Zugriff auf entfernte
                 Dateien, die paßwortgeschützt sind, ist - im Rahmen der
                 Zugriffsrechte des Benutzers - also nur in dem Maße
                 möglich, wie für die Operation kein Paßwort nötig ist.
                 Ungültige Operationen werden mit einem Gerätefehler
                 zurückgewiesen ("Schutz vor Recht").
                 Ob dieses Verhalten sich in Multiuser-Varianten ändert,
                 kann ich nicht sagen, auf diese Weise besteht aber eine
                 Möglichkeit, die Zugriffsrechte auch zwischen entfernten
                 Benutzern und lokalen Benutzern aufzuteilen und zusätzlich
                 zu den Dateiattributen und den jeweils geltenden Zugriffs-
                 rechten des jeweiligen Benutzer-Accounts auf dem Laufwerk
                 einzustellen.

                 Aus dem oben Beschriebenen kann man ein sinnvoll paßwort-
                 geschütztes System aufbauen, indem alle Dateien jedes
                 Benutzers mit jeweils einem anderen Paßwort versehen
                 werden. Ausgeschlossen davon bleiben andere wichtige
                 Dateien, die Paßwortgruppen wie 'System', 'ProjektX'
                 zugeordnet werden sollten. Gibt nun der jeweilige Benutzer
                 beim Systemstart *sein* globales Paßwort (im Rahmen der
                 lokalen Benutzerkonten) an, kann er nicht versehentlich
                 andere Dateien bearbeiten, die anderen Benutzern gehören
                 oder für die Systemfunktion notwendig sind. Dieses Paßwort
                 kann man über die Sicherheitsfunktion 'einmalige Anmeldung'
                 auch für den jeweiligen Account im PNW-Netz verwenden, so
                 daß sich jeder Benutzer nur einmal einloggen muß.

                 Paßwortgeschützte Dateien bekommen das Hidden-Attribut,
                 werden aber unter Novell DOS/DR DOS trotzdem ganz normal
                 angezeigt. Auch wenn man dieses Hidden-Attribut wieder
                 löscht, bleiben die Dateien natürlich paßwortgeschützt.
                 Unter 4DOS.COM werden normalerweise Dateien mit Hidden-
                 Attribut nicht angezeigt bzw. bearbeitet, solange man bei
                 dem entsprechenden Kommando nicht explizit diese Dateien
                 einschließt (so sagt es die 4DOS-Dokumentation).
                 Allerdings wurde auf meinem Testsystem (4DOS 5.5c) das
                 Verhalten von Novell DOS kopiert, indem paßwortgeschützte
                 Dateien (fast) ganz normal angezeigt bzw. bearbeitet
                 werden können, als wäre das Hidden-Attribut nicht gesetzt
                 (bis auf die optionale Attribut-Einfärbung bei DIR-Aus-
                 gaben, hier wird die den Attributen entsprechende Farbe
                 gewählt und das Hidden-Attribut nicht ignoriert). Wichtig
                 ist nur, daß man das Paßwort angibt.

                 Achtung: Die Paßwörter werden bei Kopieroperationen (z.B.
                 mit COPY oder XCOPY) nicht an neue Dateien vererbt. D.h.,
                 man muß zwar vor der Ausführung im Rahmen des gesetzten
                 Schutzes ein Paßwort angeben, aber eine kopierte Datei ist
                 dann nicht automatisch wieder paßwortgeschützt und muß bei
                 Bedarf wieder neu geschützt werden (entweder implizit über
                 die Angabe eines Paßwortes in erweiterter Syntax oder
                 explizit mit PASSWORD). Außerdem wird ein gesetztes Hidden-
                 Attribut gelöscht.

                 Bei Verwendung von Kommandos wie REN[AME] werden das Paß-
                 wort und die Attribute übernommen. Außerdem werden in
                 diesem Fall auch die restlichen Felder des reservierten
                 Bereichs der Verzeichnisstruktur übernommen, so daß auch
                 andere Daten, wie DR DOS 6.0 Owner-IDs und alles andere
                 gleich bleiben (mehr dazu etwas weiter unten). In diesem
                 Punkt ist die Unterstützung für Owner-IDs mit Novell DOS 7
                 also nicht weggefallen, d.h. alle Daten, die auf irgend-
                 eine Weise mit dem Verzeichniseintrag der Datei verknüpft
                 wurden, werden dann vom System solange mitgeschleppt, bis
                 die Datei gelöscht wird (auf welche Weise auch immer,
                 siehe folgende Bemerkungen bei MOVE).

                 Das Kommando MOVE ist eine Mischung aus REN[AME] und COPY,
                 daher ist auch das Verhalten davon abhängig, ob effektiv
                 ein REN oder ein COPY ausgeführt wird: Solange die Datei
                 effektiv nur umbenannt (d.h. innerhalb des gleichen Lauf-
                 werks verschoben) wird, verhält sich alles wie bei REN
                 (das bezieht sich übrigens auf die physikalischen Lauf-
                 werke, d.h. Substitut-Laufwerke etc. werden korrekt
                 berücksichtigt). Wird die Datei jedoch effektiv kopiert
                 (auf ein anderes physikalisches Laufwerk), so wird wie bei
                 COPY auch MOVE der Paßwortschutz bei der Zieldatei ent-
                 fernt, allerdings das Hidden-Attribut nicht gelöscht (das
                 dürfte ein Bug in der Implementation von MOVE sein).
                 Allerdings wird die Datei nicht wirklich verschoben,
                 sondern trotz MOVE nur kopiert. Das bedeutet, daß die
                 Quelldatei am Ursprung weiterhin vorhanden bleibt und
                 über die gleichen Attribute und Paßwortschutz wie bisher
                 verfügt.

                 Dieses Verhalten wird auch unter 4DOS nachgeahmt, außer
                 daß die Kommandos bei fehlender Paßwortangabe nicht
                 während der Bearbeitung des Kommandos automatisch das
                 Paßwort erfragen, d.h. das Paßwort muß immer beim Aufruf
                 angegeben werden und damit kann es Schwierigkeiten geben,
                 wenn während der Abarbeitung mehrere unterschiedliche Paß-
                 wörter angegeben werden müssen und man nicht mit einem
                 Master-Paßwort arbeitet.

                 Unter anderen Betriebssystemen (wie MS-DOS oder PC-DOS),
                 die diese Paßwortfunktionen nicht kennen, sind die paßwort-
                 geschützten Dateien stattdessen versteckt, aber nach Ent-
                 fernen des Hidden-Attributs ohne Paßwort zugänglich!
                 Damit besteht also auch eine Möglichkeit, an Dateien
                 heranzukommen, deren Paßwort vergessen wurde. Diese müssen
                 unter MS-DOS oder PC-DOS nur 'effektiv' in eine neue Datei
                 kopiert werden (also nicht nur REN), danach kann man auch
                 unter Novell DOS/DR DOS wieder an diese Dateien heran-
                 kommen. Entscheidend dafür, ob der Paßwortschutz aktiv ist
                 oder nicht, ist die Kernel-Implementation, nicht die des
                 Kommandoprozessors.
                 Problematisch ist lediglich, daß auch paßwortgeschützte
                 Verzeichnisse das Hidden-Attribut besitzen und dieses
                 Attribut mit dem normalen ATTRIB-Kommando bei Verzeich-
                 nissen nicht zurückgesetzt werden kann. Hier muß man
                 entweder auf Fremd-Utilities oder Disk-Editore ausweichen,
                 die diese Kombination nicht zurückweisen (gibt es noch aus
                 der Zeit, wo DOS selbst noch kein ATTRIB kannte), oder z.B.
                 den Norton Commander zuhilfe nehmen (die Option 'Show
                 Hidden-Files' muß aktiviert werden). Im NC kann man dann
                 ganz normal in diesem versteckten Verzeichnis arbeiten.
                 Will man den Schutz aufheben, sollte man den Verzeichnis-
                 inhalt zwischenspeichern, das geschützte Verzeichnis
                 löschen, und danach wieder alles zurückkopieren.
                 Alternativ dazu ist es im Norton Commander auch möglich,
                 das Hidden-Attribut von Verzeichnissen zu löschen. Danach
                 kann man dann auch wieder DOS-Befehle auf das Verzeichnis
                 anwenden.

                 Eine verwandter Trick, um ein Hidden-Attribut eines Ver-
                 zeichnisses zu löschen, ist es, mit PASSWORD ein Dummy-
                 Paßwort für das Verzeichnis zu setzen und direkt danach
                 wieder zu löschen. Dabei wird dann auch das Hidden-Attribut
                 gelöscht.

                 Übrigens: Ein Paßwort bleibt (zumindest mit DELWATCH) auch
                 erhalten, wenn eine Datei gelöscht und danach wieder ent-
                 löscht wird.

                 Etwas zur Physik der Verzeichniseinträge:

                 Die Paßwörter werden bei Novell DOS und DR DOS uni-
                 direktional verschlüsselt in bei MS-DOS reservierten Be-
                 reichen innerhalb der 32 Byte großen Verzeichniseinträge
                 gespeichert: Das unidirektional verschlüsselte Paßwort
                 liegt als Prüfsumme bei Offset +0Eh (WORD) (von Windows95
                 für das Erzeugungszeitpunkt einer Datei benutzt), die
                 Zugriffssperren WRED (Write/Read/Execute/Delete) jeweils
                 für "World", "Group" und "Owner" im leider auch von OS/2
                 benutzten Feld "EA-Handle" bei Offset +14h (Word), und
                 zwar in der Bit-Logik, wie bei DR DOS angegeben (d.h.
                 invers zu der Ausgabe von PASSWORD bei Novell DOS 7).
                 Normalerweise haben diese drei Bit-Gruppen unter
                 'Singleuser' DR DOS/Novell DOS immer den gleichen Wert
                 (0000h, 0111h, 0555h, 0DDDh). Man erkennt, daß die mit
                 PASSWORD einstellbaren drei Kombinationen von Zugriffs-
                 rechten nur einen Bruchteil der möglichen Kombinationen
                 abdecken. Der Schutz für Verzeichnisse entspricht
                 übrigens auch 0DDDh, auch wenn die API-Funktionen selbst
                 etwas anders angesprochen werden müssen.
                 PASSWORD setzt (zumindest unter dem üblichen 'Singleuser'
                 Novell DOS 7) die Access-Rights gleichzeitig für alle
                 drei internen Benutzerklassen "World", "Group" und "Owner",
                 und kennt jeweils auch nur "RWD" (nichts, bzw. /N), "RW-"
                 (/D), "R--" (/W) und "---" (/R), da diesbezüglich nur bei
                 Multiuser-Varianten unterschieden wird (bei DR DOS ist die
                 Funktionsweise zwar gleich, aber die Bits werden genau in
                 umgekehrter Logik angezeigt, s.o.). Auch haben die drei
                 Execute-Lock-Bits (nicht angezeigt) unter DR DOS/Novell DOS
                 keine Bewandtnis (und wurden wohl nur von FlexOS benutzt).
                 Sollte Execute-Lock doch gesetzt sein, wird es als Read-
                 Only-Recht (nicht Attribut!!!) behandelt, allerdings nur,
                 wenn zusätzlich auch andere Bits gesetzt sind. Die Execute-
                 Lock-Bits und die restlichen 4 unbenutzten Bits werden bei
                 Änderungen in den Zugriffsrechten nicht angetastet.
                 Beim Testen der Zugriffsrechte wertet 'Singleuser' DR DOS/
                 Novell DOS offenbar alle drei Gruppen nach einem noch unbe-
                 kannten Schema aus und bildet daraus 'ungefähr' die Access-
                 Rights, die am meisten restriktiv sind.
                 Außerdem wird im Attribut-Byte (Offset +0Bh) das Hidden-
                 Attribut gesetzt, aber davon hängt der Paßwortschutz nicht
                 ab. Die Zugriffsrechte haben nichts mit den üblichen Datei-
                 attributen zu tun, obwohl sie auch so etwas wie 'Attribute'
                 darstellen!!! Weil es ein Read-Only-Dateiattribut, einen
                 Read-Only-Paßwortschutz und im Netz noch Read-Only-
                 Zugriffsrechte in Abhängigkeit vom Laufwerk und Benutzer
                 gibt, und im speziellen auch noch SHARE-Modi für die
                 erlaubten Zugriffsvarianten auf eine Datei verantwortlich
                 sind, kommen viele Benutzer hier immer wieder durcheinander
                 (ist zugegebenermaßen auch nicht einfach).

                 Wie weiter oben beschrieben wurde, werden diese
                 Einträge in der Verzeichisstruktur normalerweise vom
                 System über die gesamte 'echte' Lebensdauer dieser
                 Datei mitgeschleppt; die bei Novell DOS 7 weggefallene
                 Unterstützung für DR DOS 6.0 Owner-IDs ließe sich also
                 relativ leicht wieder mit einem kleinen Treiber re-
                 implementieren (siehe auch bei DELWATCH.EXE und in
                 Ralf Browns Interrupt-Liste INTER53+).

                 Einige ältere Plattenpflegeprogramme meckern die ver-
                 änderten Einträge auch als Fehler in der Plattenstruktur
                 an, was aber natürlich nicht stimmt. Läßt man sie von
                 solchen Programmen korrigieren, ist das Schlimmste, was
                 passieren kann, ein aufgehobener Paßwortschutz.
                 Die Paßwörter sollten keinerlei Probleme mit Long-
                 Filename-Support (wie bei MS-DOS 7 aus MS Windows95
                 aktivierbar) bereiten. Auch das bei MS-DOS 7 neue Last-
                 Access-Datum bei Offset +12h (Word) ist unkritisch
                 (ACCDATE=). Allerdings kollidieren die Paßwörter mit
                 OS/2 Extended Attributes und MS Windows95 Datei-Erzeugungs-
                 zeitpunkt, sollten in diesem Fall also nicht verwendet
                 werden. Eine Belegungsübersicht gibt Kapitel II.21.

                 Fest steht, daß bei geeigneter Rücksichtnahme in der
                 Implementation alle anderen Funktionen (Microsofts Long-
                 Filenames & ACCDATE= sowie Novells DELWATCH und Paßwörter)
                 kollisionsfrei nebeneinander existieren könnten. Einzige
                 Ausnahme scheint das Datei-Erzeugungsdatum von MS Windows95
                 zu sein, das daraus resultierende Verhalten habe ich aber
                 noch nicht untersucht (selbst das könnte bedingt sogar
                 klappen). (Siehe auch DELWATCH.EXE und in Kapitel II.21.).

   PNUNPACK.EXE  Undokumentiertes Entpackprogramm von Novell DOS, PNW und
                 NetWare Lite.

                  PNUNPACK [/?] [@]source [target] [/O]

                   @       bei Angabe einer Listendatei
                   source  Quelldatei (kann Laufwerk und Pfad enthalten)
                   target  Zieldatei/pfad
                   /O      Überschreiben existierender Dateien erlauben

                 Dieses Programm akzeptiert auch Wildcards, solange alle
                 damit spezifizierten Dateien gepackt sind. Innerhalb einer
                 gepackten Datei können auch mehrere Dateien gepackt sein.
                 Normalerweise unterscheidet sich die Dateiendung der
                 gepackten Dateien durch ein '_' als letztes Zeichen,
                 dies ist aber keine notwendige Voraussetzung. Da bei
                 Novell DOS und PNW die ursprünglichen Dateinamen intern
                 abgelegt sind, können die alten Namen auch dann wieder
                 hergestellt werden, wenn die Datei umbenannt wurde. Vor
                 den gepackten Daten befindet sich ein Header "Packed File
                 xxxxxxxx.xxx"+1Ah+02h, wobei xxxxxxxx.xxx der wirkliche
                 Dateiname ist.

                 In Verbindung mit Wildcards ist an PNUNPACK problematisch,
                 daß es bei einem Fehler die Operation nicht nur für die
                 jeweilige Datei, sondern komplett abbricht. Dem kann man
                 mit folgendem Batchjob abhelfen:

                  FOR %%x IN (%1) DO PNUNPACK %%x %2 %3 %4 %5 %6 %7 %8 %9

                 Im Client Kit (VLMKT1.EXE bis VLMKT6.EXE bzw. dem neueren
                 VLM121_1.EXE bis VLM121_6.EXE) wird ein sehr ähnliches
                 Programm NWUNPACK.EXE mitgeliefert, das offenbar weitest-
                 gehend kompatibel ist.

                 Sollten Sie z.B. mit bestimmten Dateien von NetWare Lite
                 (mit Dateiendung .??@) Probleme mit der Benutzung von
                 PNUNPACK haben, indem PNUNPACK einen ungültigen Dateinamen
                 als Ziel angibt und dann abbricht, läßt sich das Problem
                 leicht aus dem Weg räumen, indem Sie den Header der
                 gepackten Datei mit einem Hex-Editor (oder DEBUG)
                 patchen: Höchstwahrscheinlich ist lediglich der Eintrag
                 xxxxxxxx.xxx, der oben erwähnt wurde, ungültig. Schreiben
                 Sie hier einfach einen gültigen Dateinamen hin (es reicht,
                 die Zeichen bis zur folgenden Null mit einem beliebigen
                 Buchstaben zu überschreiben). Die so geänderte Datei
                 sollte von PNUNPACK problemlos auf den gepatchten
                 Dateinamen hin entpackt werden können.

   PRINT.COM     Die Angabe des Gerätes für die Ausgabe läßt leider nur
                 die vom System vordefinierten Geräte PRN, AUX, CON, LPT1-3
                 und COM1-4 zu, auch wenn man durch entsprechende Geräte-
                 treiber weitere Devices eingebunden hat. (Dies ist aller-
                 dings bei MS-DOS genauso.)

                 Da dies vielen Benutzern nicht klar ist: Der Drucker-
                 puffer, den PRINT einrichtet, muß nicht etwa groß genug
                 sein, um alle gewünschten Dateien gleichzeitig aufnehmen
                 zu können (dann würde PRINT viel zu viel Speicherplatz
                 kosten, als daß es etwas nutzen könnte), sondern es
                 handelt sich dabei lediglich um einen Zwischenpuffer,
                 der die Daten enthält, die unmittelbar vor der Ausgabe
                 an den Drucker stehen. Normalerweise ist daher die
                 Default-Einstellung, die mit 512 mehrere Zeilen eines
                 Textes fassen kann, schon reichlich bemessen.

                 Neben diesem Zwischenpuffer benötigt der residente Teil
                 von PRINT auch noch Platz für die Liste von Dateinamen,
                 die in der Warteschlange zum Ausdruck stehen. Pro Datei-
                 spezifikation sind ca. 70 Bytes zu veranschlagen, die
                 Default-Einstellung 10 Dateien schlägt als mindestens
                 ebenso zu Buche, wie der Puffer selbst. Defaultmäßig
                 werden vom gesamten residenten Treiber ca. 6 KByte Speicher
                 benötigt.

   PRINTER.SYS   Gehört bei MS-DOS 7 und PC-DOS 7 nicht mehr zum Liefer-
                 umfang, ist bei Novell DOS 7 aber noch vertreten:

                  DEVICE = PRINTER.SYS dev=(typ [,hwcp] [,n]) ...
                  dev  Druckerschnittstellen: PRN, LPT1, LPT2 oder LPT3
                       PRN und LPT1 identisch; die Einstellung eines Gerätes
                       konfiguriert automatisch auch innerhalb des Treibers
                       das jeweils andere Gerät mit.
                       (PRN ist evtl. bei MS-DOS nicht möglich.)
                  typ  Druckertypen: 1050, 4201, 4208 oder 5202
                  hwcp Hardware-Codetabelle: 0..32767 (z.B. 437)
                       (auch 32768..65535, mit Überlauf in der Anzeige
                       von MODE als negative Zahlen)
                  n    Anzahl vorzubereitender Codetabellen (1..12),
                       für die Speicher reserviert werden muß (werden
                       später mit MODE CODEPAGE PREPARE belegt)

                 Andere Typen werden leider nicht zur Verfügung gestellt
                 und durch die Festverdrahtung ist es anscheinend auch
                 nicht ohne weiteres möglich, eigene Typen zu generieren
                 und einzubinden (höchstens unter einem falschen Namen
                 durch das Ersetzen eines vorhandenen Druckertyps):
                 Die Sequenzen zur Steuerung des Druckers stammen -
                 zumindest für die Hardware-Codeseite - offensichtlich
                 nicht aus einer später mit MODE zugeordneten .CPI-Datei,
                 sondern sind direkt in PRINTER.SYS kodiert. Zum Teil
                 gilt das offenbar auch noch für andere Druckertypen,
                 zumindest für alle Treiber vom Typ 2 (Codeseiten-Um-
                 schaltung statt Download-Daten). Gute Erfahrungen habe
                 ich bisher nur mit dem Ersetzen der 1050.CPI Datei (eine
                 Datei mit Download-Daten) durch eigene .CPI-Dateien
                 gemacht. Siehe auch Kapitel II.16.

                 Achtung: Die bei PRINTER.SYS notwendige Angabe der Code-
                 seite bezieht sich auf die hardware-mäßig installierte
                 Codeseite des Druckers (da DOS dies nicht überprüfen kann,
                 muß diese Angabe überhaupt erst vorgenommen werden). Auch
                 wenn Sie später mit Codeseite 850 etc. arbeiten wollen,
                 müssen Sie hier in den allermeisten Fällen noch die Code-
                 seite 437 angeben. In Druckerhandbüchern wird diese Ein-
                 stellung oft als IBM Zeichensatz 2, World Trade Character
                 Set oder PC-8 Zeichensatz bezeichnet. Die Zuordnung zu
                 Codeseite 437 erhalten Sie bei den meisten Druckern üb-
                 licherweise dann, wenn der Drucker den obigen Zeichensatz
                 aktiviert hat, und für die Zeichen 128..255 die IBM-Grafik-
                 zeichen statt der Epson-Schrägschrift (Italics) benutzt.
                 Wenn Sie hier eine andere Codeseite als die wirklich unter-
                 stützte Hardware-Codeseite angeben, kann die Codeseiten-
                 Unterstützung von DOS später nicht sauber arbeiten, da sie
                 von falschen Voraussetzungen ausgeht. Eine Ausnahme davon
                 ist die Angabe einer Dummy-Kennung für die Hardware-Code-
                 seite (meine Empfehlung: 999), z.B. wenn Sie eine fremde
                 .CPI-Datei verwenden und sicherstellen wollen, daß wirklich
                 alle Steuerinformationen für diesen Drucker aus der .CPI-
                 Datei und nicht aus dem PRINTER.SYS-Treiber kommen.
                 In diesem Fall müssen Sie aber bei PRINTER.SYS *jede*
                 später genutzte Codeseite vorbereiten (also üblicherweise
                 eine mehr, da die Nutzung der Hardware-Codeseite (meist
                 437) dann flachfällt).

                 Beachten Sie bitte, daß PRINTER.SYS in Abhängigkeit vom
                 verwendeten Drucker und Anzahl der vorzubereitenden
                 Codeseiten (n) unterschiedlich viel Platz beansprucht:

                  Drucker:  Typ:    Basis-Code:  +  Code/Daten je Codeseite:

                   4201  1 (DL-Fonts)  ca. 1616 Bytes + n *  ca. 7000 Bytes
                   4208  2 (Page-Switch)   1616 Bytes + n *       496 Bytes
                   5202  2 (Page-Switch)   1120 Bytes + n *       496 Bytes
                   1050  1 (DL-Fonts)      1600 Bytes + n *      2304 Bytes

                 Die Länge der Datenbereiche repräsentieren also gleich-
                 zeitig Obergrenzen für die Länge der Sequenzen, die zum
                 Drucker geschickt werden können (wobei der Platz nicht
                 nur für die Sequenz selbst, sondern auch für jeweils
                 zusätzlichen Code benötigt wird).
                 Für jedes Gerät (PRN/LPT1, LPT2, LPT3) wird bei Bedarf ein
                 kompletter eigener PRINTER.SYS Treiber installiert.

                 Die Details bezüglich der Unterscheidung von Hardware-
                 und vorzubereitenden Codeseiten sind sehr ausführlich
                 bei DISPLAY.SYS in diesem Kapitel beschrieben, hier nur
                 zwei Beispiele:

                   Einrichtung des "1050"-Treibers für alle
                    Epson FX850/1050-kompatiblen Drucker
                    (in dessen Grundeinstellung für USA):

                    CONFIG.SYS:

                      DEVICE=c:\nwdos\printer.sys prn=(1050,437,1)

                    AUTOEXEC.BAT:

                      MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
                      CHCP 437

                   Ersetzung des "1050"-Treibers durch eine eigene
                    .CPI-Datei, hier für die NEC Pinwriter Serie:

                    CONFIG.SYS:

                      DEVICE=c:\nwdos\printer.sys prn=(1050,999,2)

                    AUTOEXEC.BAT:

                      REM (NECPINW.CPI kann über mich bezogen werden.)
                      MODE prn: CODEPAGE PREPARE=((437,850) ...\necpinw.cpi)
                      CHCP 437

                 Weitere Hinweise finden sich auch bei MODE.COM in
                 diesem Kapitel.

                 Hinweis: In vielen Betriebsanleitungen von Matrix- und
                 Tintenstrahldruckern finden Sie einen Hinweis, daß der
                 Drucker im deutschen Sprachraum auf deutsche Landesein-
                 stellungen umgestellt werden sollte (per Software-Setup
                 oder DIP-Schalter). Viele Anwender setzen daraufhin die
                 Hardware-Konfiguration auf 'Deutsch' und wundern sich dann,
                 warum sie unter DOS manche Zeichen (z.B. den Backslash)
                 nicht richtig ausdrucken können. Nun, das Problem liegt
                 ganz einfach darin begründet, daß auch die PCs in ihrer
                 Grundkonfiguration nicht 'deutschsprachig' sind, sondern
                 für US-amerikanische Verhältnisse konstruiert sind, d.h.
                 Codetabelle 437 des von IBM erweiterten ASCII-Zeichensatzes
                 mit 256 Zeichen verwenden. Daher sollte auch der Drucker
                 in der US-amerikanischen Einstellung verbleiben (ist meist
                 die Werkseinstellung), so daß PC, Drucker und DOS zunächst
                 einmal mit dem gleichen zugrundeliegenden Zeichensatz (437)
                 arbeiten. Für die Druckereinstellung 'Deutsch' gibt es
                 keine Entsprechung in den Codetabellen von DOS; in
                 Wahrheit handelt es sich hierbei auch nur um ein Relikt
                 aus längst vergessenen Tagen, wo unter ASCII noch aus-
                 schließlich ein 7Bit-Zeichensatz (mit 128 Zeichen) ver-
                 standen wurde und damalige Typenraddrucker (Diabolo) und
                 frühe Matrixdrucker (hauptsächlich von Epson) in einem be-
                 stimmten Codefenster (sog. Substitut-Codeseiten) je nach
                 Landesvariante wichtige nationale Buchstaben zugeordnet
                 hatten, wodurch es damals im deutschen Sprachraum überhaupt
                 erst die Möglichkeit zur Verwendung von Umlauten und 'ß'
                 gab (diese entsprechen ISO 646 in deutscher Anpassung, bzw.
                 ISO 21). In der Codetabelle 437 liegen diese Buchstaben
                 jedoch im Bereich von 128..255, daher stört heutzutage ein
                 auf 'deutsche Konventionen' eingestellter Drucker nur den
                 reibungslosen Ablauf (es sei denn, Sie arbeiten mit Uralt-
                 Textverarbeitungen aus CP/M-Zeiten...).

   RECOVER.COM   Liefert Errorlevel 3 bei Benutzerabbruch durch <Ctrl>+<c>
                 (verifiziert für Novell DOS 7).

   RESTORE.COM   RESTORE ist mit allen BACKUP Versionen von DR DOS
                 und MS-DOS/PC-DOS kompatibel.
                 Weitere Hinweise siehe BACKUP.COM.

                 RESTORE sollte nicht auf Laufwerke angewendet werden, auf
                 die ASSIGN, JOIN oder SUBST wirkt (Vorsichtsmaßnahme).

                 Das Format der Datums-/Zeitangaben hängt von der jeweiligen
                 COUNTRY-Einstellung ab.

                 Parameterübersicht (alles von DR DOS bekannt):

                  /A:tt.mm.jj   Nachladen von Dateien, die an oder nach dem
                                angegebenen Datum geändert wurden.
                  /B:tt.mm.jj   Nachladen von Dateien, die an oder vor einem
                                dem Datum geändert wurden.
                  /E:hh:mm:ss   Nachladen von Dateien, die an oder vor dem
                                angegebenen Zeitpunkt geändert wurden.
                  /L:hh:mm:ss   Nachladen von Dateien, die an oder nach dem
                                angegebenen Zeitpunkt geändert wurden.
                  /M            Nachladen von Dateien, die seit dem letzten
                                Sichern geändert oder gelöscht wurden.
                  /N            Nachladen von Dateien, die im Zielbereich
                                nicht mehr existieren.
                  /P            Fragen vor dem Nachladen von seit der
                                letzten Sicherung geänderten Dateien
                                (bei DR DOS auch schreibgeschützte Dateien).
                  /R            Angabe der Dateien, die nachgeladen WÜRDEN
                                ohne diese jedoch wirklich nachzuladen.
                                Testet auch die Unversehrtheit der
                                Disketten.
                  /S            Nachladen auch von Dateien in Unterver-
                                zeichnissen. Unterverzeichnisse werden
                                automatisch erstellt, allerdings nicht, wenn
                                man gleichzeitig die Option /R angibt (bei
                                DR DOS 6.0 Updates vor 1992 war dies noch
                                anders).

                 MS-DOS 6.0+ RESTORE bietet eine 'neue' Option /D an, die
                 von Novells RESTORE nicht unterstützt wird. Genau diese
                 Funktion wird aber bei Novell DOS mit der Option /R er-
                 füllt, die bei DR DOS 6.0 noch nicht vorhanden war.

                 Errorlevel (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 4.0+, Novell DOS 7,
                 Caldera OpenDOS 7.01, DR DOS 6.0 und CCI Multiuser DOS 7.22
                 Gold)

                  0  normales Ende
                  1  keine Dateien zur Wiederherstellung gefunden
                  2  einige Dateien wegen Zugriffskonflikt nicht wieder-
                     hergestellt
                  3  Ende der Wiederherstellung mit <Ctrl>+<Break>
                  4  Abbruch der Wiederherstellung durch Fehler oder
                     ungültiger Parameter angegeben

   SCREATE.COM   (auch SFORMAT)

   SDRES.EXE     Der Viren-Scanner Search & Destroy 33.01 liegt für DOS und
   SDSCAN.EXE    MS Windows jeweils als residentes Programm und als normale
   WSDRES.EXE    Applikation vor (die deutsche Übersetzung von SDRES ist
   WSDSCAN.EXE   allerdings katastrophal).

                 Es ist keine Schande, irgendwann einmal eine virenver-
                 seuchte Diskette/CD zu bekommen, aber es ist sehr wohl
                 eine Schande, es im Falle eines Falles an der nötigen
                 Sorgfalt in der Vor- und Nachsorge fehlen zu lassen!!!
                 Dazu gehört es u.a.

                 - den Verursacher ausfindig zu machen und umgehend zu
                   benachrichtigen,
                 - alle Rechner, an denen man zuletzt gearbeitet hat,
                   zu untersuchen und alle anderen Benutzer von ver-
                   seuchten Rechnern zu warnen,
                 - alle verwendeten Diskettenbestände mit aktuellen
                   Viren-Scannern zu überprüfen,
                 - entdeckte Viren zu vernichten (durch Desinfizieren
                   oder Löschen der betreffenden Dateien, Formatieren
                   der Diskette oder notfalls physikalisches Zerstören
                   des Mediums, siehe auch in Kapitel II.4. bei FDISK,
                   FORMAT und SYS). Sollten infizierte Disketten aus
                   besonderen Gründen aufbewahrt werden, müssen diese
                   auffällig als mit einem Virus verseucht gekennzeichnet
                   werden,
                 - sich angewöhnen, den Schreibschutz von Disketten
                   wirklich nur dann zu entfernen, wenn man bewußt auf
                   eine Diskette schreiben möchte (m.E. die häufigste
                   und schlimmste Nachlässigkeit vieler Benutzer),
                 - Fremd-Disketten vor der Benutzung zu scannen.

                 Wenn Sie häufig Disketten an 'ungesicherten Orten' (z.B.
                 Firma oder Institut) beschreiben, kann ich nur dringend
                 empfehlen, *immer* einen residenten Viren-Scanner im
                 Hintergrund laufen zu haben (und zwar zu einem Zeitpunkt
                 installiert, wo Ihr eigenes System mit Sicherheit noch
                 unverseucht war). Die Optionen, jede neu eingelegte
                 Diskette und jede ausführbare Datei automatisch zu scannen,
                 sollte unbedingt aktiviert sein (schließlich kostet das
                 nur Sekundenbruchteile).

                 Ich habe persönlich mit einem resident installierten
                 SDRES (ins EMS ausgelagert) wesentlich bessere Erfahrungen
                 gemacht, als etwa mit McAfees residentem Viren-Scanner
                 VSHIELD: Bei einem nicht repräsentativen Testlauf mit
                 einigen im Laufe der Zeit 'gesammelten' virenverseuchten
                 Disketten zeigte sich SDRES (sämtliche Scanner-Optionen
                 aktiviert) als sehr viel zuverlässiger als z.B. VSHIELD
                 (eine Version von Herbst 1996!). Alle verseuchten Disketten
                 wurden erkannt. SDRES hat durch seine Alarmmeldungen schon
                 manches Mal eine Virenverseuchung *meiner* Rechner ver-
                 hindert!!!
                 Und bei Versuchen mit einem virenverseuchten Rechner
                 (nicht meiner ;-) ) konnten SDRES/SDSCAN sogar Viren
                 zuverlässig erkennen *und* beseitigen, obwohl der Virus
                 aktiv im Speicher war. Zu diesem Zweck wurde der Virus
                 'totgepatcht'. McAfees SCAN und VSHIELD sind in dieser
                 Situation zu keinem von beiden geeignet.

                 Die Aufruf-Syntax von SDRES.EXE und SDSCAN.EXE akzeptiert
                 sowohl '/' als auch '-' als Parametereinleitungszeichen.
                 Auf meinem System wurden vom SETUP-Programm für SDRES.EXE
                 die Optionen "-uc:\nwdos\sdscan.exe -m 640" gewählt. Diese
                 Einstellung ist jedoch nicht effektiv, vor allem muß die
                 Angabe für den Scanner mit -s eingeleitet werden. Auf
                 meinem System arbeitet "-sc:\nwdos\scscan.exe 640" zu-
                 friedenstellend, allerdings konnte sich SDRES.EXE auf
                 meinem System entweder nur in UMBs laden oder zum großen
                 Teil in EMS auslagern. Im letzten Fall wurden auf meinem
                 System lediglich 1,9 KByte vom Basisspeicher abgezwackt,
                 die sich nicht hochladen ließen. Dies kann man aber fast
                 immer verschmerzen.
                 Die Angabe 640 steht für die übliche Größe des Basis-
                 speichers. In einigen Fällen (besonders auf Rechnern
                 neuerer Generation mit SCSI- und PCI-Bussen) wird aber
                 von diesem Speicher schon standardmäßig ein ca. 1 - 5
                 KByte großer Bereich für interne Zwecke abgezweigt, in
                 solchen Fällen (und nur dann) sollten Sie die Angabe 640
                 entsprechend reduzieren, um eine prompte Warnung von SDRES
                 zu verhindern.

                 Im Zusammenhang mit der Speicherkonfiguration von SDRES
                 noch ein Hinweis für 4DOS-Benutzer:
                 Sofern SDRES sich in EMS auslagern soll, d.h. einen
                 1,9 KByte großen Stummel im konventionellen Speicher
                 hinterläßt, sollten Sie unbedingt die Hinweise in Kapitel
                 V.8. beachten.

                 Über die Tastenkombination <Ctrl>+<Alt>+<u> kann man das
                 Konfigurationsmenü von SDRES aufrufen und zur Laufzeit auf
                 drei Seiten (<PageUp>, <PageDown>) die Scanner-Optionen
                 einstellen. Das Fenster kann sich nur in üblichen Textmodi
                 einblenden, und auch nur dann, wenn eine Applikation keinen
                 eigenen Tastaturtreiber mitbringt, ansonsten poppt das
                 SDRES-Fenster erst auf, nachdem man die Anwendung verlassen
                 hat. Leider habe ich in SDRES selbst keine Möglichkeit
                 entdecken können, diese Einstellungen auch direkt abzu-
                 speichern, so daß sie auch nach dem nächsten Booten noch
                 verfügbar wären. Auch die Kommandozeile bietet nur minimale
                 Einstellungsmöglichkeiten und in SDSCAN.EXE lassen sich
                 ebenfalls keine Einstellungen für SDRES.EXE/WSDRES.EXE
                 vornehmen. So erscheint es zunächst notwendig, die Scanner-
                 Optionen bei jedem Booten neu einzustellen oder mit der
                 Standard-Einstellung (die bei Weitem nicht alle Möglich-
                 keiten aktiviert) vorlieb zu nehmen. Glücklicherweise ist
                 dem nicht so:

                 Als Workaround kann man nämlich MS Windows starten und
                 dort WSDRES.EXE aufrufen (das in die AUTOSTART-Gruppe auf-
                 genommen werden sollte). Das Programm verkleinert sich
                 sofort auf Symbolgröße. Wenn man auf das Symbol klickt
                 und 'Wiederherstellen' wählt, kann man jedoch alle Ein-
                 stellungen von SDRES.EXE und WSDRES.EXE ändern und auch
                 abspeichern. Diese Einstellungen werden sofort von einer
                 evtl. in DOS laufenden SDRES.EXE Version übernommen und
                 sind dann auch nach dem nächsten Booten wieder aktiv!

                 Die Bedienung der normalen Scanner SDSCAN.EXE und
                 WSDSCAN.EXE dürfte keine Probleme bereiten. Es sei
                 lediglich darauf verwiesen, daß die Version für MS Windows
                 (WSDSCAN.EXE) auch die Optionseinstellungen für die
                 residenten Programme SDRES.EXE und WSDRES.EXE zuläßt
                 (dabei sind sogar zwei zusätzliche Optionsseiten verfügbar,
                 die in den residenten Programmen selbst nicht angeboten
                 werden: 'Ressourcen' und 'Messages'. Dazu gehören die
                 Einstellung der Hochlademöglichkeiten, die Angabe der
                 Speichergröße, die Angabe des im Notfall zu startenden
                 Viren-Scanners und der zu verwendenden Datenbank, die
                 Möglichkeit zur Laufzeitkonfiguration, die Auswahl-
                 möglichkeiten bei Virenalarm u.a. Anscheinend werden
                 aber nicht alle dieser Einstellungen sofort von einer
                 bereits gestarteten Version von SDRES/WSDRES übernommen.
                 Wenn man WSDSCAN erst nachträglich per Hand in ein
                 bestehendes MS Windows System einfügt, kam es auf meinen
                 Testsystemen (MS-DOS 6.22) manchmal dazu, daß sich der
                 Scanner in der Startphase aufhing. Vermutlich muß man
                 noch eine Einstellung in der Windows-Konfiguration ändern,
                 denn auf Systemen, wo das Novell DOS SETUP-Programm
                 Search & Destroy eingerichtet hat, traten diese Probleme
                 nicht auf.

                 Die Konfigurationsdaten für alle 4 Programme werden in der
                 'Untouchable'-Datenbank UT.CDB gespeichert. Außerdem werden
                 noch UI.CDB, VIR-INFO.VRB und WSDSCAN.HLP benötigt. Die
                 Dateien BWCC.DLL und DEFAULT.INI (mit angepaßten Pfaden)
                 werden von den Scannern ebenfalls genutzt, aber können
                 häufig auch entfallen.
                 Da die Virendatenbank aus dem Jahre 1994 ist und im Rahmen
                 der Novell DOS 7 Updates noch kein Update für diese
                 Datenbank ausgeliefert wurde, muß man sich dieses entweder
                 von Fifth Generation besorgen (unklar) oder sollte auf
                 andere Viren-Scanner wie F-PROT oder McAfees SCAN nicht
                 verzichten.
                 Trotzdem bieten die mit Novell DOS 7 ausgelieferten Scanner
                 auch jetzt noch (11/1996) einen gewissen Schutz, da die
                 residenten Programme nicht nur nach bestimmten Viren
                 suchen, sondern auch heuristisch bestimmte nicht an einen
                 bestimmten Virus geknüpfte Aktivitäten aufdecken können.

                 Die deutsche Übersetzung von SDRES ist äußerst holprig und
                 fehlerbehaftet. Leider hat der Fehlerteufel auch nicht
                 vor dem Alarm-PopUp-Fenster halt gemacht. Die Frage
                 'Abbruch', 'Weiter' kann man z.B. nicht mit <w> für
                 'Weiter' quittieren, sondern muß stattdessen <c> für
                 'Continue' drücken (in einem Buch habe ich einen Hinweis
                 auf <f> für 'Fortfahren' gefunden, es könnte sich hier
                 noch um eine Beta-Version gehandelt haben). Glücklicher-
                 weise gilt dies nicht auch noch für <a> = Abbruch = Abort.

                 Die SDRES-Option 'Überprüfen auf einen Begleit-Virus'
                 kollidiert mit der Erzeugung von .COM-Dateien mittels
                 EXE2BIN, weil genau dieses Verhalten (von einer geöffneten
                 .EXE-Datei wird eine gleichnamige .COM-Datei erstellt) von
                 vielen Viren verwendet wird. Wenn Sie EXE2BIN anwenden,
                 sollten Sie die entsprechende SDRES-Option also vorher
                 abschalten. Dies ist aber besonders bei automatisierten
                 Abläufen störend, hier hilft das folgende Workaround
                 (auch für ATTRIB):

                  REN program.exe program.ex_
                  EXE2BIN program.ex_ program.com
                  REM REN program.ex_ program.exe  oder  DEL program.ex_

                 Bei SDRES in Verbindung mit NWCACHE sollte man entweder
                 die 'Überprüfung der DOS Fehlerbehandlung' deaktivieren,
                 SDRES erst nach NWCACHE laden oder mit den SDRES-Optionen
                 -M und -R experimentieren. NWCACHE verbiegt die DOS-
                 Fehlerbehandlung während der Installation und falls zu
                 diesem Zeitpunkt SDRES geladen ist, wird sofort falscher
                 Alarm geschlagen, falls diese Option aktiviert ist (denn
                 mit Option -M biegt SDRES sofort den INT21h Vektor wieder
                 auf sich zurück, mit -R geschieht dies nur 'manuell').
                 Das gleiche Problem tritt auch auf, wenn man den TASKMGR
                 als Prozeßumschalter startet (zumindest bei TASKMGR.INI
                 [Shell] Exec=True, siehe auch in den Kapiteln VII.2.,
                 VII.3, VII.4.). Das Starten des Multitaskers ist hingegen
                 unkritisch.
                 Auch der Aufruf von PC-Tools 9.0 MIRROR.COM führt zu einem
                 unbegründeten Viren-Alarm bezüglich eines verbogenen
                 'Critical Error-Handlers'.

                 Ähnliche Probleme sind mit Dienstprogrammen wie FDISK,
                 FORMAT, SYS etc. zu erwarten, wenn in SDRES die ent-
                 sprechenden Optionen scharf gemacht wurden. Natürlich
                 handelt es sich hier nicht um eine Virenverseuchung.

                 Wenn man die Option 'Boot-Diskette vor Booten durchsuchen'
                 aktiviert hat, kann ein kleines Problem auftreten, wenn
                 Sie als Laufwerk A: noch ein 5.25" Laufwerk installiert
                 haben. Ist in diesem Laufwerk eine Diskette eingelegt und
                 die Verriegelung nicht geschlossen, so versucht SDRES bei
                 den meisten Laufwerksmodellen unendlich lange, die
                 Diskette zu lesen (Disketten-LED leuchtet, nichts pas-
                 siert). In diesem Fall hilft es nur, die Verriegelung zu
                 schließen oder *vorher* die Diskette aus dem Schacht zu
                 entfernen.

                 Die Option 'Dateien vor der Ausführung durchsuchen' kann
                 im Netzwerk nicht mit veralteten Netz-Shells arbeiten (bis
                 ca. 1992-1993, ist also für PNW überhaupt kein Problem,
                 wohl aber in vielen lange nicht gewarteten Firmennetzen
                 auf der Basis von NetWare 3.xx). Wird eine alte Version
                 der Netztreiber installiert, gibt SDRES eine Warnung aus,
                 daß man diesen Treiber aktualisieren muß und deaktiviert
                 automatisch die obige Scan-Option. Da diese Fähigkeit aber
                 gerade eine der wichtigsten Möglichkeiten von SDRES dar-
                 stellt, sollte man die Netztreiber unbedingt auch wirklich
                 updaten!

                 SDRES kann während des Starts einen 'Köder' auslegen, um
                 zu testen, ob bereits residente Viren darauf anspringen.
                 Dieses Verfahren hinterläßt bei bereits installiertem
                 DELWATCH eine entlöschbare ?????.IMM Datei. Um zu ver-
                 hindern, daß DELWATCH hiermit unnötigerweise belastet
                 wird, empfiehlt es sich, im Bootverlauf SDRES erst nach
                 DELWATCH zu laden oder derartige Dateien mit DELWATCH
                 /E:IMM von der Löschverfolgung auszuschließen.

                 Wenn ein Virenalarm ertönt, sollte man unbedingt mit jedem
                 Tastendruck warten, bis der Jingle verklungen ist. Wenn
                 dies nicht beachtet wird, kommen die Tastatur-LEDs durch-
                 einander: SDRES mißbraucht auf ATs im Alarmfall die
                 Tastatur-LEDs von AT- und MF2-Tastaturen als 'Lauflicht'
                 und offenbar gibt es hier einen kleinen Bug in der An-
                 steuerung der Tastatur...

                 SDRES gibt mit -? einen Hilfeschirm über die möglichen
                 Optionen aus, bietet allerdings noch zwei weitere, un-
                 dokumentierte Optionen:

                  -V  Unbekannt (V=Virus??)

                  -X  Durchsucht den Speicher nach Viren und 'reaktiviert'
                      den residenten Scanner. Was dies aber genau bedeutet
                      ist noch nicht geklärt.

                 SDSCAN bietet ebenfalls noch zwei undokumentierte Optionen:

                  -M  Durch Angabe dieser Option wird das automatische
                      Verlassen des Scanners bei einem batch-gesteuerten
                      Aufruf unterdrückt, d.h. nach dem Scandurchlauf bleibt
                      die Bearbeitung auf der Übersichtsseite stehen und muß
                      per Hand abgebrochen werden.

                  -N  Ruft man "SDSCAN -N" ohne weitere Optionen auf, so
                      wird nur der Speicher und keine Datei durchsucht (auch
                      in PNW-Netzen nicht), danach wird der Scanner wieder
                      verlassen, so daß man diese Möglichkeit gut für den
                      Batch-Betrieb benutzen kann.

                 Bei SDRES und SDSCAN müssen die Optionen nicht unbedingt
                 alle extra mit einem Optionseinleitungszeichen ("-" oder
                 "/") beginnen, es sind auch Kombinationen wie -AB statt
                 -A -B möglich.

   SECURITY.OVL  Wird die Datei SECURITY.OVL in NWLOGIN.EXE umgenannt, kann
   (NWLOGIN.EXE) darin enthaltene Programm NWLOGIN direkt aufgerufen werden.

                 Die Angabe eines Systempaßwortes ist kein 100% Schutz gegen
                 böswillige Eindringlinge (wenn auch wesentlich sicherer als
                 noch bei DR DOS, wo man den Schutz durch Booten mit MS-DOS
                 umgehen konnte), da er mit etwas Trickserei mit Programmen
                 wie NDD (Norton Utilities) - evtl. unter partiellem Daten-
                 verlust - entschärft werden kann. Die Systemabsicherung
                 verschlüsselt nämlich nicht etwa die Daten auf der Fest-
                 platte, sondern unterbindet den Zugriff auf ein Laufwerk
                 lediglich durch Veränderungen in der Partitionstabelle.

                 Im Rahmen der 'einmaligen Anmeldung' soll es möglich sein,
                 sich mit der einmaligen Angabe des Benutzernamens und Paß-
                 wortes sowohl lokal, als auch im Netz anzumelden (dazu
                 müssen neben den Netz-Accounts auch lokale Benutzerkonten
                 eingerichtet sein, was möglich ist, sobald die System-
                 absicherung per SETUP aktiviert wurde).
                 Die Angabe des Masterpaßwortes gibt den lokalen Rechner
                 frei (für Notwartungsarbeiten), arbeitet aber nicht mit
                 der einmaligen Anmeldung zusammen.

                 Das Kommando UNSECURE auf der 1. Installationsdiskette
                 von Novell DOS 7 erlaubt es nach der Angabe des Master-
                 paßwortes, einen lokalen Rechner wieder von seinem
                 Security-Schutz zu befreien.

                 SECURITY.OVL alias NWLOGIN.EXE entnimmt seine Konfiguration
                 der Datei %NWDOSCFG%\NWDOS.INI und wertet dort die folgen-
                 den Abschnitte aus, wobei Eintragungen aus [SECURITY] die
                 von [COLORS] übersteuern:

                  [SECURITY]
                   CurrentColor=

                  [COLORS]
                   ColorSetX=    (X=<CurrentColor> aus 1..9)
                   NewUI=on|off

                 Außerdem werden in irgendeiner Form die Dateien
                 C:\NWCNTL\SECURITY und C:\@FDS.SAV verwendet.

   SERNO.EXE     Im DOSBOOK undokumentiert. Gibt die Seriennummer der
                 Betriebssystem- oder PNW-Installation aus. Die Seriennummer
                 wird in der Datei SETUP.INI in %NWDOSCFG% in der Gruppe
                 [Registration] SerialNumber=abcd-1234-123456 (entsprechend
                 dem Diskettenaufkleber auf der Installationsdiskette 1)
                 gespeichert.
                 Theoretisch ist auch das Ändern der Seriennummer von
                 Novell DOS und PNW über die Option /S möglich (es kann
                 jeweils eine entsprechende Frage erscheinen, wobei ich
                 bisher nur die Frage nach der Seriennummer von DOS er-
                 zeugen konnte, selbst wenn PNW geladen war), allerdings
                 akzeptiert das Kommando nur acht- bzw. 4-4-6-stellige
                 Zahlenkombinationen, nicht aber die vierstellige Buch-
                 stabenkombination in der Seriennummer, die Novell zu-
                 mindest für die deutschen Seriennummern verwendet. (U.U.
                 wird auch die Datei SERVER.EXE über %Path% untersucht.)

                 Die Meldungen von SERNO sind (gewollt?) etwas irreführend:
                 Die Seriennummer wird keineswegs 'direkt auf der Platte',
                 sondern - wie oben beschrieben - in einer speziellen Datei
                 gespeichert. D.h. die Medienseriennummer, die nun auch
                 Novell DOS 7 (spätestens ab Update 14) unterstützt, wird
                 nicht beeinflußt, genausowenig werden die vorbereiteten
                 Felder für Seriennummern in den Systemdateien wie
                 COMMAND.COM (bei Caldera OpenDOS 7.01 übrigens mit
                 SeRiAlNuMbEr=xxxx-xxxx-xxxxxx gekennzeichnet, siehe auch
                 bei VERSION.EXE), noch werden im Boot-Sektor Einträge
                 verändert.

   SETFIFO.EXE   Dieses externe Kommando ist erst mit einem Update dazuge-
                 kommen, wohl auch, um Performance-Probleme mit seriellen
                 Schnittstellen zu mildern (auch unter dem Multitasker
                 TASKMGR). Es erlaubt den FIFO von neueren UART-Chips 16550
                 mit FIFO einzustellen. Das Kommando kann mit zwei Para-
                 metern gefüttert werden oder fragt interaktiv nach den
                 notwendigen Einstellungen. Leider scheint dieser
                 'Quick-Hack' keine (anderen) Kommandozeilenparameter
                 auszuwerten und kann obendrein nur mit COM1 und COM2
                 arbeiten. Als wesentlich besseren Ersatz kann das
                 FreeWare-Utility ACOM.COM herhalten, das nebenbei
                 auch so ziemlich alle anderen Einstellungsarbeiten
                 an seriellen Schnittstellen bewältigen kann (zu beziehen
                 über mich - Adresse siehe oben).

   SETUP.EXE     (enthält INSTALL.EXE)
                 SETUP /A[DVISE] schaltet in den 'Anleitungsmodus', der das
                                 System analysiert und ein Ergebnisprotokoll
                                 ausgibt. Achtung: Wenn diese Datei
                                 INSTALL.EXE heißt, bewirkt /A etwas völlig
                                 anderes!!!
                      /COLORS    Farbunterstützung (zumindest für PNW-Setup)
                      /STACKER   Für STACKER-Setup
                      /FIRST     Für PNW-Setup

                 Weitere ungeklärte Optionen:
                 /RESULTS /DONE_SCAN /QA /QUIET

                 Dieses Programm akzeptiert andere Parameter, wenn es zu
                 INSTALL.EXE umbenannt wird. INSTALL /? gibt diese Möglich-
                 keiten aus.

                 Durch entsprechende Änderungen der Setup-Dateien läßt sich
                 die Setup-Prozedur in weiten Bereichen einstellen/ändern.

                 Offenbar kann man den integrierten DOS-Extender??? (RTLink/
                 Plus) bei Bedarf mit folgenden Umgebungsvariablen für
                 die Verwendung bestimmter Speichersorten konfigurieren
                 (vgl. NET.EXE in Kapitel VI.9.) (0=deaktivieren):

                 VM-Manager:      RTVMEXT, RTVMEXP, RTVMEXPLOW, RTVCONV
                 Overlay-Manager: RTOVEXP, RTOVEXT, RTOVCONV

                 Achtung: Falls Ihre CONFIG.SYS eine Dateigröße von mehr als
                 7462 Bytes oder die AUTOEXEC.BAT größer als 9500 Bytes ist,
                 besteht akute Gefahr, daß SETUP.EXE Ihre Konfigurations-
                 dateien ab dieser Größe abschneidet. Sichern Sie die beiden
                 Konfigurationsdateien unbedingt vor dem Aufruf von SETUP
                 und kopieren Sie die alten Dateien zurück, bevor Sie den
                 Rechner neu starten. Mittels SETUP vorgenommene Einträge
                 können mit FC relativ schnell gefunden werden und in Ihre
                 eigenen Konfigurationsdateien übernommen werden.

   SETVER.EXE    Die Versionstabellen werden in der SETVER.EXE Datei selbst
                 gespeichert. Dabei sind optional auch Pfadangaben zu den
                 einzelnen Dateien erlaubt, um Doppeldeutigkeiten bei
                 gleichnamigen Dateien vorzubeugen (seltsamerweise funktio-
                 niert dies aber bei mir nicht..., im Zweifelsfall geben
                 Sie keine Pfade angeben). Die ausgelieferte Version
                 enthält bereits eine Reihe Voreinstellungen für bekannte
                 Programme, die eigentlich nur unter einer bestimmten
                 DOS-Versionsnummer laufen wollen, aber unter Novell DOS 7
                 auch funktionieren.

                 Da jeder Eintrag zur Laufzeit Speicherplatz kostet (jeweils
                 der vollständige Dateiname plus 3 Bytes), sollten Sie zu-
                 nächst alle nicht wirklich benötigten Einträge aus der
                 Tabelle löschen (Option /D).

                 Wegen der Veränderungen an der Datei sollten Sie ein
                 Original von der Installationsdiskette (unter einem
                 anderen Namen) aufbewahren.

                 Gibt man eine ungültige DOS-Version für eine Datei an, so
                 wird Errorlevel 1 zurückgeliefert. Erlaubte Versionsnummern
                 sind x.y (Hauptversion.Unterversion) jeweils im Bereich
                 0..255, wobei der 255 als Unterversionsnummer eine un-
                 dokumentierte Sonderfunktion zukommt (s.u.).

                 Die vorgetäuschten Versionsnummern beziehen sich auf den
                 'offiziellen' DOS-API Call (INT21h/30h) für Versionscheck,
                 nicht auf die API-Funktion zur Ermittlung der 'wahren'
                 DOS-Version (INT21h/3306h, Novell DOS 7 liefert hier
                 übrigens selbst mit Update 15 immer noch Revision 00) und
                 auch nicht auf DR DOS/Novell DOS ureigene Versions-APIs
                 (INT21h/4451h und INT21h/4452h).

                 Ausnahme: Wurde eine Unterversion 255 angegeben (also
                 x.255), so liefert zwar INT21h/30h ebenfalls diese
                 Versionsnummer zurück, aber zusätzlich wird die Novell DOS-
                 eigene Versionsabfrage INT21h/4452h mit Fehlercode AX=0001h
                 beantwortet. Sollte es ein Programm geben, das bewußt auf
                 DR DOS/Novell DOS abtestet, um dann unter diesem Betriebs-
                 system die Arbeit zu verweigern, so kann man hiermit die
                 entsprechende Interrupt-Funktion für dieses Programm
                 einfach verschwinden lassen und das Programm kann nicht
                 mehr erkennen, daß es unter DR DOS/Novell DOS gestartet
                 wird... Testet ein Programm hingegen 'echte Funktionalität'
                 von DR DOS/Novell DOS ab, so läßt sich dies natürlich nicht
                 mit diesem kleinen Schwindel überlisten...

                 Neben den dokumentierten Parametern kennt Novells SETVER
                 noch zwei undokumentierte Parameter:

                  /G version     Ändert die globale Versionsnummer, die für
                                 alle Programme gemeldet wird, die nicht
                                 extra aufgelistet werden.
                                 (Standard ist 6.00, da Novell DOS 7 das
                                 API von IBM PC-DOS 6.1 nachbildet, das den
                                 API-Level 6.00 hat und mit MS-DOS 6.00
                                 übereinstimmen dürfte.)
                                 Wenn Sie wollen, können Sie hier mit
                                 /G 7.00 Novell DOS 7 zu seiner wahren
                                 Versionsnummer verhelfen, dies könnte
                                 aber eine Reihe Kompatibilitätsprobleme
                                 mit Anwendungen verursachen... ;-)
                                 Die oben beschriebene Ausnahme gilt auch
                                 für die globale Versionsnummer.
                                 Ist DEVICEHIGH=SETVER.EXE nicht geladen,
                                 gibt sich Novell DOS 7 immer als PC-DOS 6.1
                                 (d.h. API-Level 6.00) aus (zumindest alle
                                 Versionen von Update 3 bis Update 15). Es
                                 ist möglich, daß sich ganz frühe Versionen
                                 von Novell DOS 7 wirklich als "Novell DOS
                                 6.00, API-Level 6.00" ausgegeben haben.
                  /P             "Page" hält die Ausgabe nach jeder Seite
                                 an.

                 Sollten Ihnen die Möglichkeiten von SETVER für einen
                 speziellen Anwendungsfall nicht ausreichen, können Sie von
                 mir das FreeWare-Tool FREEVER.COM anfordern, das ähnlich
                 wie SETVER.EXE Versionsnummern türken kann, sich dabei aber
                 nicht auf INT21h/30h beschränkt, sondern auch die wahre
                 Versionsnummer INT21h/3306h und die DR DOS/Concurrent DOS/
                 DR Multiuser DOS/Novell DOS Versionsabfragen bei
                 INT21h/4412h, 4451h und 4452h detailgetreu nachbildet.
                 Außerdem emuliert das AMIS-konforme Tool das SETDRVER.COM-
                 API und MS-DOS 4 INT2Fh/122Fh. Natürlich ist die Anwendung
                 nicht ungefährlich und erfolgt ausschließlich auf Ihr
                 Risko!

   SHARE.EXE     Dieses TSR sollte bei Novell DOS 7 unbedingt geladen
                 werden. Im Gegensatz zu (zumindest älteren) MS-DOS Ausgaben
                 besitzt der Novell DOS 7 Kernel keine (oder nur sehr
                 eingeschränkte) SHARE-Funktionalität (bei alten DR DOS
                 Ausgaben war SHARE dahingegen wohl hauptsächlich bereits
                 Bestandteil des Kernels und intern völlig anders
                 realisiert). Um also ein mit MS-DOS gleichwertiges
                 System zu erhalten, muß SHARE geladen werden (besonders
                 für Multitasker und MS Windows). Die ursprüngliche Version
                 war auf maximal 1024 Dateisperrungen beschränkt, mit
                 Update 13 (SHARE 2.03) wurde jedoch eine Version ausge-
                 liefert, die bis zu /F:60000 oder /L:4900 erlaubt, wobei
                 der Speicher (12 Bytes pro Sperrung) im Gegensatz zu früher
                 dynamisch alloziert wird, so daß der Speicher nur dann
                 belegt wird, wenn er auch wirklich benötigt wird. Mit
                 Update 13 wurde SHARE 2.04 ausgeliefert.
                 Siehe auch Kapitel V.4.

                 Bezüglich FILES= und FCBS= sei auf Kapitel III.1. ver-
                 wiesen. Insgesamt können vom System maximal 255 Handles
                 zur Verfügung gestellt werden, natürlich gibt es innerhalb
                 von Applikationen und in Netzen die Möglichkeit, diese
                 Schranke in Eigenregie zu umgehen (daher macht es auch
                 Sinn, daß SHARE mehr Dateien verwalten kann).

                 DR DOS 3.41-6.0 bot noch eine Option /X zum Deakti-
                 vieren von SHARE nach dem Laden. Diese Option wird von
                 Novell DOS 7 nicht mehr unterstützt, weil die neue MS-DOS-
                 konforme Implementation dies nicht mehr erlauben würde.

   SORT.EXE      Im Gegensatz zu MS-DOS 6.2x SORT.EXE kann Novells SORT
                 auch problemlos Dateien/Umleitungsdaten mit mehr als
                 64 KByte bearbeiten! Da SORT i. allg. in Verbindung mit
                 Umleitungen angewendet wird, sollte jedoch genug Platz
                 auf dem Temporärlaufwerk frei sein.

                 SORT verwendet nach Möglichkeit die landesspezifischen
                 Einstellungen zur Bestimmung der Sortierreihenfolge (in
                 einigen Büchern wird das Gegenteil behauptet, vermutlich
                 war auf den Testsystemen die Landesunterstützung falsch
                 konfiguriert).
                 Möchten Sie eine Datei nach den Konventionen eines anderen
                 Landes sortieren, müssen Sie vorher mit einem kleinen
                 Utility wie COUNTRY.EXE das 'aktuelle Land' umstellen
                 (siehe auch Ralf Browns Interrupt-Liste) oder CONFIG.SYS
                 COUNTRY= ändern und neu booten).

                 Für den Parameter /+n mit n=Offset der Spalte, ab der
                 sortiert werden soll, sind Werte von 0..65535 zulässig,
                 d.h. SORT kommt auch mit exotischen Textdateien zurecht.
                 Anscheinend wirkt /+0 dabei genauso wie /+1, was auch dem
                 Default-Wert entspricht, wenn man nichts angibt (jedenfalls
                 konnte ich bisher keinen Unterschied feststellen).

                  Beispiel (Sortieren eines Verzeichnisses nach Dateigröße):

                   DIR *.* | SORT /+14 | MORE

                 Bezüglich der sicheren Verwendung in Batchjobs siehe
                 Kapitel IV.6.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  normale Bearbeitung
                  1  offenbar bei MS-DOS/PC-DOS: Datei zu groß (größer
                     64 KByte). Bei Novell DOS wahrscheinlich nicht belegt,
                     da Novell DOS auch mit größeren Dateien zurecht kommt.
                  2  Benutzerabbruch (<Ctrl>+<c>)
                  4  falscher Parameter

   STACHIGH.SYS  Verwendet %Path%, %DirCMD%, SDIR/DIR.COM??, STACKER.INI
                 und bietet anscheinend besondere Unterstützung für DIR,
                 CHKDSK, DEFRAG und DBLSPACE. SDIR.COM ist ein Tool, das
                 zu den einzeln erhältlichen Versionen von STACKER mitge-
                 liefert wird, bei Novell DOS 7 ist es nicht enthalten,
                 weil DIR entsprechend erweitert wurde (SDIR bietet übrigens
                 auch undokumentierte Parameter...).

   SUBST.EXE     Obwohl dieses Kommando rein äußerlich genau die gleichen
                 Funktionen wie bei MS-DOS bereitstellt, ist es doch intern
                 besser realisiert: Z.B. können Sie auch implizite Lauf-
                 werksangaben machen, wie etwa:

                  SUBST i: c:\nwdos
                  SUBST j: i:\cfg   (wenn c:\nwdos\cfg existieren würde)
                  SUBST k: c:\nwdos
                  SUBST l: k:.

                 Ein Detail ist aber noch nicht ganz zu Ende gedacht (ist
                 aber eine Frage der Kernel-Implementation, nicht der von
                 SUBST): Wenn Sie einen Verzeichnisnamen ändern, der gleich-
                 zeitig in der Wurzel eines substituierten Laufwerks liegt,
                 so wird diese Laufwerkszuordnung aufgehoben und auf das
                 Wurzelverzeichnis gesetzt und nicht  - wie es sinnvoller
                 wäre - dem neuen Laufwerksnamen zugeordnet. Etwa:

                 Eingabe:                   Ausgabe:

                 SUBST m: c:\test1
                 RENDIR c:\test1 c:\test2
                 SUBST                      "m: c:\" statt "m: c:\test2"

                 Ein Fehler ist das allerdings nicht, versuchen Sie dies
                 'mal bei MS-DOS...

                 Interessante Optimierungsmöglichkeiten des Speicherbedarfs
                 residenter TSRs in Verbindung mit SUBST finden sich bei
                 LH in Kapitel II.11. (gelten auch für INSTALLHIGH=).

                 Novells SUBST kennt die von CCI Multiuser DOS 7.22 her
                 bekannte Option /B für eine batch-konforme Ausgabe in
                 Verbindung mit Umleitungen leider nicht.

                 Errorlevel (nur für Novell DOS 7 verifiziert):

                  0     ok
                  1     ungültiger Parameter, zuwenig Parameter
                  3..67 nur Novell DOS: Entspricht der Länge des
                        TRUENAMEs eines geänderten SUBST-Laufwerks
                        (bei diesen Errorleveln könnte es sich um ein
                        äußerst praktisches Zufallsresultat handeln).

                 Um eine Vorstellung von der sinnvollen Verwendung der
                 Errorlevel von Novells SUBST zu geben, hier ein
                 praktisches Beispiel. Der folgende Batchjob erlaubt
                 (in meiner Konfiguration) das komfortable, aber sicher-
                 lich noch verbesserungswürdige Umsetzen des Temporär-
                 laufwerks, das hier unter dem Buchstaben T:\ verfügbar
                 sein soll:

                  SETTMP.BAT:

                   @ ECHO off > \dev\nul
                     REM 1995-11-25 -mp
                     IF NOT ""=="%1" GOTO start
                     ECHO SETTMP: Changes temporary drive/dir setting.
                     ECHO Syntax: SETTMP ['reset'] [path\]
                     :start
                     IF ""=="%1" GOTO end
                     IF "reset"=="%1" GOTO reset
                     SET old_tmp=%tmp%> \dev\nul
                     SET old_temp=%Temp%> \dev\nul
                     SET tmp=%1> \dev\nul
                     SET Temp=%tmp%> \dev\nul
                     GOTO perform
                     :reset
                     IF NOT ""=="%old_tmp%"  SET tmp=%old_tmp%> \dev\nul
                     IF NOT ""=="%old_temp%" SET Temp=%old_temp%> \dev\nul
                     SET old_tmp=> \dev\nul
                     SET old_temp=> \dev\nul
                     :perform
                     c:
                     CD \
                   @ SUBST t: /d > nul
                   @ SUBST t: %tmp%
                     IF NOT "NWDOS"=="%Os%" IF NOT "OPENDOS"=="%Os%" ...
                                                                ... GOTO end
                     IF NOT ERRORLEVEL 4 ECHO Warning: Root dir specified!
                     IF NOT ERRORLEVEL 4 IF EXIST t:\*.* DIR t:\*.*
                     :end

   SYS.COM       Beim 'SYS'en' eines Boot-Mediums wird der Boot-Sektor des
                 jeweiligen Laufwerks überschrieben und es werden die beiden
                 zum Booten notwendigen 'BIOS'- und 'DOS'-Dateien (bei
                 Novell DOS: IBMBIO.COM und IBMDOS.COM) von einem boot-
                 fähigen Medium überspielt. Außerdem wird der Kommando-
                 prozessor (ohne den keine Eingaben am Prompt möglich wären)
                 kopiert. Dafür wird die Variable %ComSpec% ausgewertet,
                 vgl. Kapitel IV.7.
                 Achtung: Die Datei, auf die %ComSpec% zeigt, wird als
                 Kommandoprozessor notwendigerweise - da die Existenz einer
                 CONFIG.SYS Datei mit einem Eintrag SHELL= nicht vorausge-
                 setzt werden darf - unter dem Namen COMMAMD.COM auf das
                 Boot-Medium kopiert. Dies geschieht auch dann, wenn man
                 nicht mit COMMAND.COM, sondern etwa mit 4DOS.COM arbeitet.
                 Das System kann problemlos von einem solchen Medium booten;
                 der 'falsche' Name COMMAND.COM und das abweichende Ver-
                 halten könnte aber einen arglosen Benutzer etwas ver-
                 wundern. Wenn Sie das stört, und Sie in jeder Situation
                 sicherstellen wollen, daß COMMAND.COM auf das Bootmedium
                 übertragen wird, können Sie folgendes probieren:

                  SYS.BAT:

                   @COMMAND /C SYS.COM %1 %2 %3 %4 %5 %6 %7 %8 %9

                 Dabei ist es wichtig, daß SYS.BAT in einem Batch-
                 Verzeichnis liegt, das in %Path% vor dem C:\NWDOS\
                 Verzeichnis durchsucht wird. Außerdem müssen Sie
                 beachten, daß Sie die Dateiendung von SYS.COM angeben
                 müssen, damit keine Rekursion entsteht (auch bei MS-DOS
                 hat das SYS-Programm die Endung .COM).

                 Die bei SYS unter MS-DOS ebenfalls übertragenen Dateien
                 DBLSPACE.BIN/DRVSPACE.BIN werden nicht berücksichtigt,
                 müssen also ggf. nachträglich umkopiert werden.

                 Bei DR DOS 5.0+/Novell DOS können die Systemdateien offen-
                 bar an beliebiger physikalischer Stelle auf dem Laufwerk
                 liegen, bei MS-DOS 6.0+ gilt dies in dieser Allgemeinheit
                 nur für Floppies (früher noch nicht einmal das, man denke
                 an FORMAT /B), wodurch mit MS-DOS manchmal Probleme auf-
                 tauchen, wenn mehr als eine DOS/Windows-Betriebssystem-
                 version auf der gleichen Partition installiert ist.

                 Ein spezielles Problem tritt in Multi-Boot-Konfigurationen
                 auf (etwa mit Novells LOADER-Tool, das z.B. zum Liefer-
                 umfang von CCI Multiuser DOS 7.22 Gold gehört und problem-
                 los auch mit Novell DOS, OpenDOS, MS Windows95 mit Dual-
                 Boot und/oder dem OS/2-Bootmanager zusammenarbeitet): Sind
                 die Namen der Systemdateien in der meisten Fällen unter-
                 schiedlich (IO.SYS und MSDOS.SYS bei MS-DOS, BOOT.SYS bei
                 CCI Multiuser DOS, oder IBMBIO.COM/IBMDOS.COM bei PC-DOS),
                 so tritt in Verbindung mit DR DOS 5.0+, Novell DOS 7 oder
                 Caldera OpenDOS das Problem auf, daß diese Systeme die
                 gleichen Dateinamen verwenden. Viele Boot-Manager sind
                 mit dieser Konstellation überfordert und können PC-DOS
                 nicht parallel zu einem System der DR-Familie installiert
                 haben, selbst leistungsfähige Boot-Manager haben oft
                 Schwierigkeiten, mehrere Versionen des gleichen Systems
                 (etwa DR DOS 5.0, DR DOS 6.0, Novell DOS 7 oder OpenDOS)
                 nebeneinander bootfähig installiert zu haben. Hier hilft
                 eine SYS-Option weiter, der ab DR DOS 6.0 existiert:

                 Mit dem undokumentierten Parameter "SYS /DR:ext" kann man
                 SYS.COM veranlassen, beim Schreiben des Boot-Sektors und
                 der IBMBIO.COM-Datei die Dateiendungen interner Referenzen
                 auf die Standardnamen (d.h. im Bootsektor auf IBMBIO.COM
                 und in IBMBIO.COM auf IBMDOS.COM und [D]CONFIG.SYS) auf
                 den Wert von "ext" zu patchen: Bei DR DOS 6.0 sollte man
                 üblicherweise "SYS /DR:DR6" angeben, bei Novell DOS 7
                 entsprechend "SYS /DR:NW7". Auf diese Art und Weise
                 ist es sogar möglich, die Kernel-Dateien mehrerer
                 Novell DOS 7 Updates nebeneinander bootfähig zu halten
                 (etwa /DR:D01, /DR:D02, usw.). Ein Beispiel:

                  SYS /DR:NW7 a:

                 schreibt einen Bootsektor, der die Datei IBMBIO.NW7
                 statt der Datei IBMBIO.COM lädt. Diese Datei IBMBIO.NW7
                 entspricht dem Original bis auf einen Patch, der seiner-
                 seits auf die Dateien IBMDOS.NW7 statt IBMDOS.COM, und
                 auf [D]CONFIG.NW7 statt auf [D]CONFIG.SYS verweist.
                 Innerhalb dieser Datei kann man mit einer modifizierten
                 SHELL= Anweisung auf einen anderen Kommandoprozessor und
                 eine andere AUTOEXEC.BAT Datei verweisen, sonst wird -
                 wie üblich - COMMAND.COM und AUTOEXEC.BAT gewählt. Auf
                 diese Weise ist eine saubere Trennung der einzelnen
                 Kernel-Dateien möglich. Die Syntax für SHELL= lautet z.B.:

                  SHELL=c:\nwdos\command.com c:\nwdos /P:autoexec.nw7

                 Hat man bereits ein Multi-Boot-System mit LOADER und
                 Konsorten eingerichtet, ist die Anwendung von SYS auf
                 die so präparierte Partition immer mit dem Risiko ver-
                 bunden, daß dabei der Boot-Manager durch das Neuschreiben
                 des Boot-Sektors oder gar des MBRs wieder abgekoppelt
                 wird. Aus diesem Grunde empfehle ich in solchen Situa-
                 tionen, von Diskette das betreffende Betriebssystem aus
                 der DR-Familie zu booten und dann unter Zuhilfenahme der
                 /DR:ext Option eine andere Diskette bootfähig zu machen.
                 Von dieser Diskette kann man dann die entsprechend
                 modifizierten Dateien IBMBIO.??? und IBMDOS.??? in das
                 Hauptverzeichnis des ersten Festplattenlaufwerks kopieren
                 und die LOADER.INI Datei mit einem normalen Text-Editor
                 manuell um die Einträge für das neue System zu erweitern.

                 Übrigens kann man durch das Ändern der Dateiendung auf
                 eine nicht ausführbare Endung auch einem anderen Fehler
                 vorbeugen, nämlich der Möglichkeit, versehentlich (etwa
                 im NC) eine der Dateien IBMBIO.COM oder IBMDOS.COM zu
                 starten (z.B. .SYS oder .BIN). Dies führt sonst un-
                 weigerlich zum Absturz des Systems. Nicht ohne Grund
                 sind diese beiden Dateien mit Hidden- und System-
                 Attributen versehen.

                 Bemerkung: Für ein zukünftiges Update für Calderas
                 OpenDOS 7.01 habe ich den Startcode von IBMBIO.COM so
                 modifiziert, daß er - falls fälschlicherweise als normales
                 Programm gestartet - ohne Absturz zur Kommandozeile
                 zurückkehrt. Wann diese Sicherheitsfunktion in die
                 offizielle Version Einzug halten wird, ist jedoch noch
                 nicht abzusehen.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok
                  3  Benutzerabbruch (<Ctrl>+<c> etc.), oder
                     kann Boot-Sektor nicht schreiben
                  4  Syntax-Fehler

                 In manchen Fällen mag es notwendig sein, direkten Zugriff
                 auf den Boot-Sektor eines Laufwerks zu bekommen (z.B. um
                 den Boot-Sektor zu retten oder um einen eigenen modifi-
                 zierten Boot-Sektor aufzuspielen). Dies kann man mit Hilfe
                 von DEBUG bewerkstelligen. Beachten Sie, daß der Boot-
                 Sektor eines Laufwerks nichts mit dem Master-Boot-Sektor
                 (MBR) zu tun hat, den man mit FDISK bearbeiten kann (siehe
                 bei FDISK in Kapitel II.4.). In beiden folgenden Beispielen
                 steht ??? für die nullbasierte Laufwerksnummer (A:=0, B:=1,
                 C:=2), d.h. üblicherweise wird man hier 2 als Boot-Laufwerk
                 einsetzen!

                  Speichern des Boot-Sektors des jeweiligen Laufwerks in
                  einer Datei \BOOTSECT.BIN:

                   DEBUG
                    -L 100 ??? 0 1
                    -Rcx=200
                    -N \bootsect.bin
                    -W
                    -Q

                  Aufspielen eines neuen (präparierten) Boot-Sektors auf
                  ein Laufwerk aus einer Datei \BOOTSECT.BIN:

                   DEBUG \bootsect.bin
                    -W 100 ??? 0 1
                    -Q

                 SYS.COM kann man auch prima zum Entfernen von Boot-Viren
                 (etwa der weitverbreitete "PARITY B"-Virus) benutzen,
                 solange das laufende System selbst noch nicht verseucht
                 ist: Einfach das Medium neu 'SYS'en', wodurch der in-
                 fizierte Boot-Sektor überschrieben wird. Danach kann man
                 die drei System-Dateien auch wieder löschen, vgl. Kapitel
                 II.4. bei SDRES.

   TOUCH.EXE     Es gibt neben den dokumentierten Parametervarianten noch
   TREE.COM      eine speziell selektive undokumentierte Syntax, die die
   XDEL.EXE      Angabe eines Benutzeranmelde- oder Gruppennamens erlaubt
   XDIR.EXE      (Syntax: /U:name; der Name darf normalerweise maximal
                 12 Zeichen lang sein). Diese Option ist nicht in jeder
                 Betriebssystemkonfiguration verfügbar und hat eine
                 besondere Bedeutung in Novell/DR Multiuser-Varianten oder
                 bei lokalen Benutzerkonten und bei einmaliger Anmeldung,
                 sofern die Systemabsicherung aktiviert ist.

                 Haben Sie schon mal das Problem gehabt, daß Sie den Inhalt
                 eines kompletten Laufwerks mit XDIR.EXE /S ausgeben lassen
                 wollten und XDIR.EXE dann nach einiger Zeit mit einer
                 Fehlermeldung abbricht, es hätte nicht genug Speicherplatz
                 einige 10.000 Dateien zu Sortieren?
                 Wenn Sie lediglich eine Übersicht über alle Dateien haben
                 wollten, können Sie in diesem Fall auf XDIR.EXE /S /N
                 oder das Kommando TREE.COM /F ausweichen, wobei die Dateien
                 dann nicht sortiert werden.

                 Für Hinweise zu TOUCH.EXE siehe auch bei ATTRIB.EXE.

                 Errorlevel für Novell DOS 7 TOUCH (unvollständig):

                   0  ok, Hilfe
                  31  kein Dateiname, Syntax-Fehler, TOUCH für einige
                      Dateien fehlgeschlagen

                 Errorlevel für Novell DOS 7 TREE (unvollständig):

                   0  ok
                   1  Syntax-Fehler, Laufwerks(zugriffs-)fehler
                   3  Benutzerabbruch (<Ctrl>+<c> etc.)
                   4  Lesefehler (Diskette fehlt)

   XCOPY.EXE     Es gibt neben den dokumentierten Parametervarianten noch
                 eine speziell selektive undokumentierte Syntax, die die
                 Angabe eines Benutzeranmelde- oder Gruppennamens erlaubt
                 (Syntax: /U:name; der Name darf normalerweise maximal
                 12 Zeichen lang sein). Diese Option ist nicht in jeder
                 Betriebssystemkonfiguration verfügbar und hat eine
                 besondere Bedeutung in Novell/DR Multiuser-Varianten
                 oder bei lokalen Benutzerkonten und bei einmaliger
                 Anmeldung, sofern die Systemabsicherung aktiviert ist.

                 Außerdem wird die DR DOS Option /C auch noch bei
                 Novell DOS 7 unterstützt, ist aber undokumentiert.
                 Sie wirkt genauso wie die neue Option /P.

                 Die beiden mit MS-DOS 6.2 eingeführten Parameter /Y und
                 /-Y zur Bestätigung vor dem Überschreiben unterstützt
                 Novell DOS 7 (getestet bis Update 15) noch nicht, da es
                 viel früher eingeführt wurde.

                 Errorlevel (unvollständig):

                 (verifiziert für MS-DOS/PC-DOS 4.0+, Novell DOS 7,
                  wahrscheinlich auch DR DOS 6.0)

                  0  normales Ende
                  1  Keine Dateien zu kopieren
                  2  Benutzerabbruch durch <Ctrl>+<Break> etc.
                  4  Initialisierungsfehler, zuwenig Speicher, ungültige
                     Optionen, Diskette voll, Datei/Pfad nicht gefunden
                  5  INT24h-Fehler beim Lesen/Schreiben der Daten

   UNDELETE.EXE  UNDELETE stellt das Gegenstück zu Kommandos wie DEL,
                 ERASE, ERA, XDEL dar und kann - je nach installiertem
                 Löschschutz - unterschiedlich komfortabel und sicher
                 bereits gelöschte Dateien zurückholen.

                 Viele Benutzer haben gewisse Anschauungsprobleme, deshalb
                 folgendes Bild:
                 Wird Novells UNDELETE auf in der DELWATCH-Löschverfolgung
                 befindliche Dateien angewendet (die gewissermaßen in einem
                 'unsichtbaren' Bereich des Laufwerk liegen), so kann man
                 UNDELETE auch im Kontext von Novells DELPURGE betrachten:
                 UNDELETE holt die gelöschten Dateien aus dem unsichtbaren
                 Bereich zurück in die Sichtbarkeit, wohingegen DELPURGE
                 sie zwar auch aus dieser Pufferzone entfernt, aber dafür
                 'in entgegengesetzter Richtung', indem es sie dem freien
                 Speicherbereich des Laufwerks zuschlägt.

                 Wie schon angesprochen, unterstützt Novells UNDELETE
                 neben der DOS-Methode auch DISKMAP und DELWATCH, aller-
                 dings keine Fremdkonzepte wie etwa das von MS-DOS/PC-Tools
                 UNDELETE.
                 PC-Tools 9.0 UNDEL.EXE kommt hingegen sowohl mit MS-DOS
                 UNDELETE /LOAD als auch mit DR DOS/Novell DOS DELWATCH
                 zurecht. Dies ist interessant zu wissen, wenn Sie statt
                 DELWATCH evtl. Microsofts 6.2x UNDELETE /LOAD verwenden,
                 um die Probleme, die DELWATCH mit verschiedenen Disk-Tools
                 bereitet, zu lösen (siehe bei DELWATCH/DELPURGE).
                 UNDEL.EXE findet auch dann noch gelöschte Dateien, wenn
                 sie mit DELPURGE aus der Löschverfolgung entfernt wurden.
                 Diese Dateien sind offenbar mit Novells UNDELETE nicht
                 mehr zu restaurieren (siehe DELPURGE und DELWATCH). Mehr
                 Hintergrund-Informationen zur Physik der Verzeichnis-
                 einträge gibt Kapitel II.21.


                 Unterstützt, wie Novells DELPURGE.EXE, neben den dokumen-
                 tierten Parametern noch eine Reihe weiterer neuer Parameter
                 (wie auch MS-DOS/PC-Tools UNDELETE.EXE):

                  /ALL      identisch mit /A
                  /LIST     identisch mit /L
                  /DT       nur "Delete-Tracking-Methoden" verwenden, d.h.
                            nur die Unterstützung durch DISKMAP und DELWATCH
                            wählen. Wollen Sie zwischen DISKMAP und DELWATCH
                            unterscheiden, müssen Sie stattdessen /R:DISKMAP
                            oder /R:DELWATCH angeben.
                  /DOS      nur "DOS-Löschmethoden" verwenden, d.h. wie
                            /R:UNAIDED. Dies bezieht sich gleichzeitig
                            sowohl auf die 'alte' DOS-Methode (wie auch
                            bei MS-DOS/PC-DOS), bei der der erste Buchstabe
                            des Dateinamens verloren geht und vor der
                            Restaurierung erfragt werden muß, als auch
                            auf die 'neue' Methode unter Novell DOS,
                            wenigstens diesen Buchstaben an anderer Stelle
                            im reservierten Bereich der Verzeichnisstruktur
                            zwischenzuspeichern, wodurch die lästige und
                            fehlerträchtige Fragerei unterbleiben kann.
                            Werden /DOS und /DT gleichzeitig angegeben,
                            hat /DT offenbar den Vorrang.
                  *.*       Alles

                 Die undokumentierte Syntax /U:name erlaubt die Angabe eines
                 zulässigen Benutzeranmelde- oder Gruppennamens (maximal 12
                 Zeichen lang). Diese Option ist nicht unter jedem Betriebs-
                 system verfügbar und hat in Novell/DR Multiuser-Varianten
                 oder in Verbindung mit lokalen Benutzerkonten und
                 einmaliger Anmeldung eine Bedeutung, sofern die System-
                 absicherung aktiviert ist.

                 Der MS-DOS 6 UNDELETE /T Parameter hat eine gänzlich
                 andere Funktion als Novells /T: Parameter!

                 Die Parameter /D: bzw. /T: (in landesspezifischem Format)
                 erlauben bei Novell DOS UNDELETE die zeitliche Ein-
                 schränkung des Suchbereichs für Dateien, wobei das
                 exakte Verhalten nicht so pauschal (und damit größtenteils
                 falsch) beschrieben werden kann, wie dies in der Novell-
                 und Fremd-Dokumentation geschieht (zwar bietet auch
                 DELPURGE gleichnamige Parameter mit gewissermaßen
                 'umgekehrtem Vorzeichen' an, dort sind sie allerdings
                 exakt beschrieben und beziehen sich ausschließlich auf
                 den Bereich *vor* dem angegebenen *Lösch*zeitpunkt):

                 Die Parameter /D:dd.mm.yy (absolut) bzw. /D:-nnn (relativ
                 bezogen auf das aktuelle Datum) bewirken eine doppelte
                 Suchmaske, die einerseits als Angabe des Zeitraum *seit*
                 der letzten *Änderung* (vor dem Löschen) der zu suchenden
                 Dateien gilt und andererseits gleichzeitig bei Dateien,
                 die in der DELWATCH-Löschverfolgung hängen, zusätzlich auf
                 das *exakte* *Lösch*datum paßt.
                 Dieses etwas gewöhnungsbedürftige Konzept erlaubt gewisser-
                 maßen eine Doppelnutzung der Parameter und liefert in den
                 meisten Fällen genau die richtigen gewünschten Dateien
                 (im Zweifel wenige Dateien mehr), denn der Unterschied
                 wird erst dann sehr offensichtlich, wenn das letzte
                 Änderungsdatum einer Datei sich stark vom Löschdatum
                 unterscheidet und weit zurückliegt.

                  Beispiele:

                  /D:-0   für Dateien, die heute gelöscht wurden (plus die,
                          die - mit falschem Datumsstempel - in der Zukunft
                          geändert und gelöscht 'wurden'... ;-) )
                  /D:-1   für bereits gelöschte Dateien, die noch gestern
                          oder heute geändert wurden, plus alle in der
                          Löschverfolgung stehenden Dateien, die gestern
                          gelöscht wurden.
                  /D:-7   für bereits gelöschte Dateien, die noch innerhalb
                          der letzten Woche geändert wurden, plus alle in
                          der Löschverfolgung stehenden Dateien, die vor
                          exakt 7 Tagen gelöscht wurden.

                 Zum sukzessiven rückwärtigen Durchsuchen *aller* in der
                 letzten Woche gelöschten Dateien muß man also der Reihe
                 nach die Optionen /D:-0 .. /D:-7 durchprobieren (die
                 Dokumentation beschreibt dies falsch)! Gleiches gilt
                 natürlich auch bei absoluter Angabe eines Datum mit
                 /D:dd.mm.yy.

                 Der Parameter /T:hh:mm[:ss] bezieht sich immer auf den
                 Löschzeitpunkt und spezifiziert den Zeitraum *seitdem*.
                 Ohne die Angabe eines genaueren Datums mit /D: (bzw.
                 des Löschdatums einer durch die /D: Maske in Frage
                 kommenden Datei) bezieht sich /T: auf das aktuelle Datum.

                 Sollten Sie bei in der DELWATCH-Löschverfolgung befind-
                 lichen Dateien neben dem Original-Datums-/Zeitstempel auch
                 noch den Zeitpunkt des Löschens erfahren wollen, können
                 Sie dafür das Kommando DELPURGE /L verwenden, denn UNDELETE
                 verwendet zwar intern auch das Löschdatum für seine /D: und
                 /T: Parameter, zeigt diese Informationen aber nicht an.

                 Novell DOS 7 UNDELETE dürfte zwar unter DR DOS 6.0 ge-
                 löschte Dateien problemlos entlöschen können, da aber
                 DR DOS 6.0 und Novell DOS 7 DELWATCH sich bezüglich der
                 Speicherung des Löschdatums unterscheiden, könnte es sein,
                 daß Novells UNDELETE alte, unter DR DOS 6.0 gelöschte
                 Dateien mit falschem Datum anzeigt, das Originaldatum
                 mit dem Löschdatum verwechselt und die Dateien nach
                 dem Restaurieren ein völlig falsches Datum haben
                 (1980-01-01???). Schwerwiegendere Probleme sind
                 allerdings nicht zu erwarten. (Nicht getestet.)

                 Nur, wenn UNDELETE ganz ohne Parameter aufgerufen wird,
                 erscheint die integrierte Menüoberfläche, ansonsten ar-
                 beitet das Programm konsolenorientiert. Lediglich die
                 Parameter /B (für Schwarz/Weiß-Darstellung) und/oder /N
                 (für EGA/VGA-Zeichensatz) sind auch in diesem Fall erlaubt
                 (und können entgegen der Dokumentation auch gleichzeitig
                 angegeben werden). Standardmäßig wirkt UNDELETE dann für
                 das aktuelle Laufwerk, dies kann aber innerhalb der Ober-
                 fläche auch geändert werden.
                 Möchten Sie hingegen von vornherein den Konsolenmodus
                 aktivieren, reicht es aus, einfach eine Laufwerksspezifi-
                 kation (und sei es auch nur die des aktuellen Laufwerks)
                 anzugeben.

                 UNDELETE wertet in der Datei %NWDOSCFG%\NWDOS.INI die
                 Gruppen [UNDELETE] CurrentColorX= (x=1..9) und [COLORS]
                 ColorSetX und NewUI=on|off aus (wie oben schon erwähnt).
                 Evtl. wird auch noch eine Variable %ADDSTOR% (SuperStor)
                 untersucht.

                 Wird UNDELETE auf JOIN-Laufwerke angewendet, werden keine
                 zu entlöschenden Dateien angezeigt, auch wenn in Wirklich-
                 keit Dateien vorhanden sind. In diesem Fall muß die Zu-
                 ordnung aufgehoben werden und mit dem Original-Laufwerks-
                 buchstaben gearbeitet werden (vgl. auch DELWATCH, das
                 nur mit physikalischen Laufwerken arbeitet).

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok???
                  2  ???
                 31  Allgemeiner Fehler (Fehlercode: xx),
                     z.B. Fehlercode 3 hervorgerufen durch ungültige
                                       Zahlenwerte im Zeitformat des
                                       /T: Parameters.

   UNFORMAT.EXE  Die meisten Anwender würden dieses Kommando am liebsten
                 verkennen, ging seinem Einsatz doch in der Regel ein
                 essentieller und peinlicher Fehler in der Benutzung der
                 DOS-Kommandozeile voraus... ;-)
                 Trotzdem, wenn Sie versehentlich FORMAT /X auf eine Fest-
                 platte angewendet haben, sollten Sie normalerweise alle
                 Daten dieser Platte wiederherstellen können (besonders,
                 wenn Sie DISKMAP, MS-DOS/PC-Tools MIRROR oder Norton
                 Utilities IMAGE verwendet haben).
                 Ich hatte bisher erst einmal Kontakt mit diesem Kommando,
                 und prompt funktionierte das gerade beschriebene Procedere
                 NICHT! UNFORMAT weigerte sich, auf die Platte auch nur
                 zuzugreifen und auch CHKDSK oder PC-Tools DISKFIX ließen
                 sich nicht dazu überreden. Nortons NDD fand nur Bad-
                 Sectors. Kein gutes Zeichen. Des Rätsels Lösung:
                 Während des FORMAT /X war offenbar ein Fehler aufgetreten,
                 und die DOS-internen Datenstrukturen wiesen diese Platte
                 nun als nicht ansprechbar ('nicht formatiert') aus. Also
                 hieß es, sicherheitshalber alle DISKMAP, MIRROR, IMAGE etc.
                 Tools temporär aus der AUTOEXEC.BAT entfernen (damit diese
                 weiterhin den alten Zustand dokumentierten) und den Rechner
                 neu booten. Und prompt war die Platte wieder ansprechbar,
                 als wäre nichts gewesen...

                 MS-DOS 6.2 UNFORMAT /TEST bietet Novell DOS 7, welches
                 vor MS-DOS 6.2 auf den Markt kam, verständlicherweise
                 noch nicht. Sollten die Möglichkeiten von Novells UNFORMAT
                 einmal nicht ausreichen, können Sie auch das bis auf die
                 Unterstützung für Novells FORMAT leistungsfähigere
                 UNFORMAT.COM von MS-DOS 6.2 verwenden (da dieses Programm
                 eigentlich von Central Point PC-Tools stammt, arbeitet es
                 auch mit Novell DOS).

                 UNFORMAT kann nur funktionieren, wenn zum Zeitpunkt des
                 FORMATs auf dem Laufwerk genügend freier Speicherplatz
                 vorhanden war, um die UNFORMAT-Informationen zu sichern
                 (bei 1,2 MByte-Floppy ca. 4 KByte) und das Format nicht
                 geändert wurde. Außerdem dürften die neu auf das Medium
                 kopierten Dateien noch nicht die UNFORMAT-Informationen
                 überschrieben haben, wie dies geschieht, wenn das Medium
                 voller wird.

                 Errorlevel:
                 (unvollständig, nur für Novell DOS 7 verifiziert)

                  0  ok
                  1  unzulässiges Laufwerk
                  3  Benutzerabbruch (<Ctrl>+<c> etc.)
                  4  Kann Laufwerk nicht lesen (keine Diskette)

   VERSION.EXE   Diese kleine Novell-Utility (in C:\NWCLIENT\) ermöglicht
                 die Berechnung von (extrem langen) Dateiprüfsummen und
                 die Ausgabe der in vielen Novell-Dateien intern gespeicher-
                 ten Versionsangaben.

                 Die Syntax ist VERSION [filespec] [/N], wobei auch Wild-
                 cards erlaubt sind.

                 Das Programm durchsucht die Datei nach bestimmten
                 standardisierten Zeichenketten, hinter denen die gesuchten
                 Informationen entsprechend Novells Konventionen bei der
                 Erzeugung eingetragen wurden. Die wichtigsten Zeichenketten
                 sind "VeRsIoN=", "VeRsIoN#", "CoPyRiGhT=" und für die
                 Option /N noch "NaMe SeRvIcE=" (und "NeTwArE="???).

                 Natürlich kann man diese Methode auch praktisch für eigene
                 Programme übernehmen, wenn man das richtige Format einhält,
                 z.B.

                  DB "NaMe SeRvIcE=Dies ist ein Dummy!", NUL, CR, LF
                  DB "VeRsIoN=1.00 REV A (970130)", NUL, CR, LF
                  DB "CoPyRiGhT=(C) Copyright 1997 by ??", NUL, CR, LF

                 Dabei sollte das Datum unabhängig von der eigenen Landes-
                 einstellung immer im japanischen Datumsformat und ohne
                 Separatoren angegeben werden. Zumindest die letzten
                 beiden Zeichenketten müssen mit NUL (ASCII-0) abgeschlossen
                 werden; das CR (ASCII-13), LF (ASCII-10) ist optional,
                 aber sinnvoll. Die Versionsangabe sollte nicht mit einem
                 Satzzeichen enden, da VERSION.EXE hier automatisch einen
                 Punkt setzt. Es müssen nicht alle Zeichenketten angegeben
                 werden.

                 Bei "VeRsIoN#" kann die Angabe einer Versionsnummer
                 (optional mit Revisionscode) direkt binär erfolgen
                 (für Seriennummern). Dafür werden offenbar die unmittelbar
                 auf das '#'-Zeichen folgenden 3 DWORDs als Version, Unter-
                 version und Revision ausgewertet.

                 Ein Problem ergibt sich, wenn Dateien, die solche Infor-
                 mationen enthalten, mit einem Online-Kompressor wie PKLITE
                 bearbeitet werden. VERSION.EXE kann dann die Informationen
                 nicht mehr finden. Allerdings kann man die Informationen
                 normalerweise auch an das Ende der komprimierten Datei an-
                 hängen (etwa mit einem speziellen Batchjob). Um optimale
                 Konsistenz zu erhalten, ist folgende Vorgehensweise sinn-
                 voll:

                  - Ausführbare Datei erzeugen (mit internen Informationen
                    für VERSION.EXE)
                  - Die internen Versionsinformationen mit einem Utility
                    auslesen und zwischenspeichern
                  - Ausführbare Datei komprimieren (z.B. mit PKLITE)
                  - Die zwischengespeicherten Informationen wieder in das
                    richtige Format bringen und zusätzlich an die ausführ-
                    bare Datei anhängen.
                  - Virenscanner, Prüfsummenschutz, etc. laufen lassen

                 Dieses auf den ersten Blick recht komplizierte Unterfangen
                 kann sogar mit einem trickreichen Batchjob gelöst werden
                 (wer's braucht, kann XVERSION.BTM bei mir anfordern).

                 Noch eine Bemerkung zum Schluß: Bei einer Komprimierung
                 mit PKLITE werden die Token wie VeRsIoN=, CoPyRiGhT= usw.
                 oft nur teilweise komprimiert und bleiben auch von 'außer-
                 halb' sichtbar. Dies kann VERSION.EXE verwirren, wenn es
                 diese Fragmente vor den neu angehängten Einträgen in der
                 Datei findet. Ein kleiner Trick hilft hier: Wenn Sie im
                 Code unmittelbar vor dem Auftauchen der Zeichenketten
                 einen Teil des Musters vorweg angeben, kann PKLITE den
                 eigentlichen Eintrag besser komprimieren und es bleiben
                 keine verwirrenden Fragmente mehr übrig, z.B. funktioniert:

                  DB "VeCoP"
                  ... <hier die eigentlichen Einträge vornehmen>

                 Zwar wertet VERSION.EXE den folgenden Eintrag nicht
                 aus, aber bei Caldera OpenDOS 7.01 wird der Eintrag der
                 Seriennummer in COMMAND.COM erstmals speziell mit
                 "SeRiAlNuMbEr=" gekennzeichnet.

   VDISK.SYS     Novells VDISK unterstützt neben normalem DOS und DR DOS
                 auch Concurrent DOS/XM 6.0+, Concurrent DOS/386 2.0+,
                 DR Multiuser DOS 5.1+ und Concurrent DOS 5.1+. Die ausge-
                 lieferte Version unterstützt kein DPMS; in dem DPMS-SDK
                 gibt es aber einen Beispiel-VDISK-RAM-Disk-Treiber, der
                 DPMS nutzt und damit nur 400 Bytes im Real Mode-Adreßraum
                 beläßt. Trotzdem:

                 Im FreeWare-Bereich existieren zwei sehr viel flexiblere
                 (Größe zur Laufzeit einstellbar) und kleinere RAM-Disk-
                 Treiber, die obendrein noch etwas schneller sind:
                 TurboDSK (TDSK, selbsthochladender Gerätetreiber/TSR,
                 ebenfalls nur ganze ca. 400 Bytes groß (!!!), Nutzung
                 aller Speichersorten) bzw. BitDisk, der wohl kleinste
                 RAM-Disk-Treiber der Welt (ebenfalls ein Selbsthochlader,
                 lediglich ca. 256 Bytes groß, Nutzung von XMS), beide
                 geschrieben von Ciriaco García de Celis. Beide sind auch
                 mit deutscher Dokumentation erhältlich, z.B. über meine
                 Web-Page.

                                                                             
  ---------------------------------------------------------------------------

  II.5. Undokumentierte Möglichkeiten von DEBUG: [96-07-15]
  =========================================================

   Stichworte: DEBUG, Bugs, Kompatibilität, OpCodes, 286er, Pentium, /X,
               Breakpoints, Symbole, Selbstdokumentierung, Makros,
               Berechnung von Werten, Remote-Debugging

   Das Kommando DEBUG von Novell DOS ist nahezu 100% kompatibel mit dem
   Gegenstück von MS-DOS und arbeitet mit jedem DOS 2.11+ zusammen. Es
   gibt nur ganz wenige Unterschiede, aber - leider zum größten Teil un-
   dokumentiert - sehr viele praktische Erweiterungen, die zum Teil noch
   vom Vorgänger SID (DR DOS 6.0) abstammen (SID wiederum hat seine Vor-
   fahren in SID86 von DR DOS 3.41 - der übrigens spezielle Befehle zum
   Debuggen unter GEM (und VIEWMAX) besaß - und der wiederum basierte auf
   Debuggern für CP/M, wie etwa DDT). Leider sind im Detail nicht alle
   Fähigkeiten von SID übernommen worden (z.B. die angesprochenen GEM-
   Features), das allermeiste ist allerdings wiederzufinden.

   Novell DOS DEBUG stellt sich wahrlich als Fundgrube undokumentierter
   Eigenschaften dar und dürfte damit das am meisten verkannte Utility von
   Novell DOS sein (Beim Vergleich mit der Konkurrenz drängt sich einem
   unweigerlich der ungerechte Vergleich von Porsche und Käfer auf...).

   Im DOSBOOK findet sich (allerdings etwas versteckt ganz am Ende) eine
   recht ausführliche Dokumentation über alle offengelegten Kommandos und
   Funktionen dieses äußerst mächtigen und wichtigen Werkzeugs, das trotz
   diverser Hochsprachen-Debugger und wesentlich flexiblerer Tools wie
   Borlands Turbo-Debugger manchmal unumgänglich ist, um bestimmte Dinge
   auszuführen.


   i. Inkompatibilitäten zu MS-DOS DEBUG:
   --------------------------------------

   - Im Assemble-Modus (-A) muß man bei Novell DOS 7 gewünschte Zeichen-
     ketten in doppelte Anführungszeichen (DB "Teststring") setzen, bei
     MS-DOS tun's auch die einfachen Anführungszeichen. Dies kann manchmal
     Änderungen in Debug-Skripten für MS-DOS DEBUG erfordern. Die Debug-
     Skripte heißen bei Novell DOS übrigens meistens .SCR, bei MS-DOS
     meist .DEB, die Namenswahl ist allerdings in keiner Weise einge-
     schränkt, sondern lediglich eine Konvention in den Dokumentationen.

   - Die derzeitige Implementation (getestet bis 1.42, Update 15) hat einen
     kleinen, aber schwerwiegenden Bug: Versuchen Sie niemals Ausdrücke
     wie die folgenden einzugeben:

      A
      DB 0A, 0D, "$"

     oder

      A
      DW 3FF, 2000, "Teststring"

     Sobald eine Zeichenkette und eine normale Angabe in dieser Reihenfolge
     zusammen in einer Zeile definiert werden, kann es zu einem tiefen
     Absturz kommen. Dies läßt sich vermeiden, wenn diese Angaben in
     getrennten Zeilen erfolgen. Eine Zeichenkette vor einer Zahl wird
     hingegen akzeptiert.

   - Mit der ursprünglich ausgelieferten Version 1.40 kann man nicht in
     Interrupts tracen (-T) (es wurde stattdessen Proceed (-P) ausgeführt),
     dies ist aber wohl mit der Version 1.41 von Update 12 möglich
     (prinzipielle Ausnahmen siehe unten). (Mit Update 13-15 (diverse
     Unterversionen von 1.42) habe ich dies nochmals überprüft, und es
     klappt seltsamerweise nicht mehr. Ob der Fix versehentlich wieder
     entfernt wurde oder ob mir ein Fehler unterlaufen ist? Leider habe
     ich die Version 1.41 nicht mehr zur Verfügung...)

   - Die EMS-Funktionen von MS-DOS DEBUG (-XA, -XD, -XM und -XS) werden
     nicht unterstützt, werden aber auch so gut wie nie benötigt. Dafür
     bietet Novells DEBUG eine Unzahl anderer Erweiterungen.
     Natürlich kann man die fehlenden Funktionen nachbilden, in dem man
     sich im Assemble-Modus 'online' ein paar Interrupt-Aufrufe für die
     EMS-Funktionen schreibt.

   - Während des Assembler-Modus (-A) sind keine Kommentare erlaubt
     (dies ist bei MS-DOS DEBUG möglich, wenn auch undokumentiert).
     Kommen solche Kommentare allerdings in Debug-Skripten vor, stört
     das deren Abarbeitung nicht. Novells DEBUG gibt lediglich eine
     Fehlermeldung aus, arbeitet aber normal weiter. Zusätzlich sind
     bei Novell jedoch Kommentare direkt am Prompt erlaubt (was aller-
     dings bei MS-DOS zurückgewiesen wird).

   - Die Syntax der Mnemos ist bei Novells DEBUG gegenüber MS-DOS
     in einigen Punkten leicht eingeschränkt (dafür werden aber viele
     andere Erweiterungen geboten). So sind z.B. keine Ausdrücke wie

      MOVAX,1

     oder

      D,1,1

     erlaubt, aber diese Einschränkungen sich eigentlich nur konsequent,
     anderenfalls könnte es mit zukünftigen neuen Assemblerbefehlen
     Doppeldeutigkeiten in Debug-Skripten geben. Da all dies MS-DOS DEBUG
     sowieso fremd ist, konnte man dort auch auf solche Vorsorgemaßnahmen
     verzichten.


   ii. Grundsätzliche Verbesserungen:
   ----------------------------------

   - Im allgemeinen stabiler (mit MS-DOS DEBUG habe ich schon die
     seltsamsten Phänomene erlebt, etwa Abstürze an Segmentgrenzen
     etc., so etwas ist Novells Implementation fremd)...

   - Umschalten auf Benutzerschirm (Kommando 'Video' -V), d.h. die
     Debug-Sitzung überschreibt nicht die Ausgabe des getesteten
     Programms und umgekehrt. Dieser Parameter ist nur in der ein-
     gebauten Hilfe von DEBUG dokumentiert.

   - Im Gegensatz zu MS-DOS 6.22 DEBUG wird der komplette (!!!) Befehlssatz
     vom Intel 8088 bis zum Intel Pentium sowie alle Befehle der Intel
     Coprozessoren voll unterstützt. Die zusätzlchen Opcodes der V20/V30
     (und damit auch 8080) Opcodes und Erweiterungen der Cyrix- und IIT-
     Prozessoren und Coprozessoren werden allerdings nicht erkannt. Einige
     undokumentierte Opcodes werden nicht für alle Prozessoren unterstützt,
     aber eine ganze Reihe undokumentierter Opcodes (und Aliase) werden
     wenigstens richtig decodiert.

   - Der Debugger bietet einen erweiterten /X-Modus an, in dem die Kommando-
     zeilen-Syntax mancher Befehle mächtiger wird und in dem man von der
     Default-Vorgabe BYTE abweichen kann. Neben einigen Bemerkungen im
     weiteren Verlauf mehr dazu im DOSBOOK. Für die Bearbeitung von Debug-
     Skripten von MS-DOS DEBUG sollte man den /X-Modus nicht verwenden, da
     es hier durch die Erweiterungen zu Fehlinterpretationen kommen kann.

   - Der Debugger erlaubt symbolisches Debuggen durch spezielle Symbol-
     dateien und Makros. Neben Erkennungsmechanismen für verschiedene CPUs
     sind auch eine große Anzahl symbolischer Namen der gängigen DOS-,
     NetWare- und BIOS-APIs direkt intern kodiert.

   - Novell DOS DEBUG erlaubt die Verwendung von bedingungsabhängigen
     Breakpoints.

   - Es gibt Möglichkeiten zum Remote-Debuggen.


   iii. Undokumentierte Kommandos und Optionen:
   --------------------------------------------

   (Sowie einige spezielle Anmerkungen zu teilweise dokumentierten
    Funktionen.)

    -A [address]       'Assemble' ist im DOSBOOK dokumentiert.
                       Während dieses Kommandos beziehen sich Register-
                       ausdrücke aus verständlichen Gründen auf die Namen,
                       nicht auf die gerade darin enthaltenen Werte (wie
                       ansonsten bei Novells DEBUG und SID üblich).
                       Im Gegensatz zu MS-DOS DEBUG sind keine einge-
                       betteten Kommentare erlaubt, allerdings werden
                       entsprechende Debug-Skripte auch nicht zurück-
                       gewiesen, da durch die auftretende Fehlermeldung
                       weder der Assemble-Modus beendet, noch die je-
                       weilige Codezeile verlassen wird, d.h. das Er-
                       gebnis ist das Gleiche.
                       Weitere Hinweise siehe oben.


    -B [breakpoint[, count[, condition]]

                       'Breakpoint' - Dieser undokumentierte Parameter
                       erlaubt das flexible Setzen von permanenten
                       Ansprungpunkten (im Gegensatz zu den bis zu 3
                       temporären Haltepunkten, die man bei G 'Go'
                       optional angeben kann). Im Gegensatz zu Halte-
                       punkten ist bei Ansprungpunkten die Anweisung an
                       der spezifizierten Stelle noch nicht ausgeführt.

                       -B

                       Gibt Liste der derzeit definierten Ansprungpunkte
                       und der Haltebedingungen an. Es können maximal
                       4 Ansprungpunkte angegeben werden.

                       -Bbreakpoint[, count[, condition]

                       Definiert einen Ansprungpunkt. Ohne Angabe von
                       count und condition ist dies ein unbedingter
                       Ansprungpunkt, der beim (nach dem?) ersten Mal
                       aktiv wird (d.h. count=1 und condition=always
                       wird implizit angenommen). Gibt man count an,
                       so wird der Ansprungpunkt erst beim Durchlauf
                       count durch diesen Haltepunkt aktiv (der Zähler
                       wird mit jedem Durchlauf um eins erniedrigt, bis
                       er 1 erreicht. Bei 1 bleibt er dann stehen).
                       Dabei sind für count beliebige Werte von 0 bis
                       xxxx möglich. Die zusätzliche Angabe von condition
                       erlaubt es, auch noch ein CPU-Register auf einen
                       bestimmten Wert hin zu überprüfen. Nur in diesem
                       Fall wird der Ansprungpunkt aktiv (und der Zähler
                       zählt).

                       Beispiel:

                       B100, 2, AX=05

                       setzt einen Haltepunkt an Offset 100h, der nach zwei
                       Durchläufen mit Bedingung AX=05 aktiv wird. Für die
                       Registerangabe sind alle möglichen 8- und 16-bittige
                       Register und jeweils gültige Werte erlaubt.
                       Die Angabe einer condition ist nur gleichzeitig mit
                       den anderen Angaben möglich. Es ist zu beachten, daß
                       beim zweiten Parameter durch die Angabe eines Textes
                       wie AX noch der aktuelle Inhalt dieses Registers
                       (für den Durchlaufzähler) verwendet wird, wohingegen
                       im dritten Parameter der Eintrag vor dem Gleichheits-
                       zeichen die symbolische Bedeutung für Register XY
                       hat, nach dem Gleichheitszeichen jedoch auch der Wert
                       des evtl. angegebenen Register gemeint ist.

                       B100, 0, BL=CH

                       setzt also die Bedingung BL=03 falls CH=3 ist.

                       Wofür die Einstellung count=0 gut ist, ist noch nicht
                       klar, man kann aber vermuten, daß dieser Ansprung-
                       punkt dann immer gilt und nicht erst nach einer
                       gewissen Anzahl von Durchläufen aktiv wird.

                       (SID erlaubte in einer sehr ähnlichen Funktion bis
                       zu 16 Ansprungpunkte auf der Basis von eingefügten
                       INT03h-Anweisungen, d.h. es konnte kein ROM-Code
                       debuggt werden und die Angabe von Bedingungen war
                       nicht möglich. Novells DEBUG arbeitet hier aber
                       wahrscheinlich auf der Basis der Debug-Features des
                       386er (und höher) (deshalb auch nur 4 Breakpoints).
                       Allerdings ist diese Funktion auch auf 286ern,
                       wahrscheinlich sogar auf 8088-Systemen verfügbar.
                       Vielleicht wird das Verhalten intern umgeschaltet -
                       nicht überprüft...)

                       Die obigen Funktionen sind auch im /S-Modus ver-
                       fügbar, die folgenden Optionen werden im /X-Modus
                       zusätzlich freigeschaltet:

                       --B                     löscht alle Ansprungpunkte
                       --Bbreakpoint           löscht nur den spezifizierten
                                               Breakpoint.


    -C range address   'Compare' ist im DOSBOOK dokumentiert.


    -CLS               Dieser undokumentierte Befehl löscht den Bildschirm
                       der Debug-Sitzung (nicht den 'Benutzerschirm').
                       Dabei wird im Gegensatz zur Novell DOS' und DR DOS'
                       Kommandozeile die eventuell in der Umgebungsvariable
                       %$Cls% definierte Sequenz ignoriert (siehe auch
                       Kapitel II.11., III.1. und IV.7.).


    -CPU               Dieser undokumentierte Befehl gibt die vorhandene
                       CPU und ihren aktuellen Betriebsmodus aus.
                       Erkannt werden alle Intel CPU-Generationen (bis
                       zum Pentium) sowie die NEC V20/V30 Prozessoren.
                       An Prozessormodi werden Real Mode und V86-Modus
                       angegeben (DOS läuft nicht im Protected Mode).


    -D [range]         'Dump' - Im /X-Modus gibt es die erweiterten Modi
                       (jeweils mit einem Leerfeld abgeschlossen!), die
                       jeweils entsprechende Größen oder Objekte zur Anzeige
                       bringen.

                       -DB [range]             Dump BYTE
                       -DW [range]             Dump WORD (von SID bekannt)
                       -DD [range]             Dump DWORD (auch auf 286ern)
                       -DP [range]             Dump POINTER
                       -DI [range]             Dump INTERRUPTS

                       Die Angabe von -DP und -DI gibt Pointer-Strukturen
                       (Segment:Offset) aus. Die einfache Angabe von -D
                       benutzt den zuletzt eingestellten Modus weiter.
                       Hinter diesen Spezialbefehlen können auch die
                       üblichen Parameter angegeben werden. Bei -DI werden
                       diese nicht als Adreßangaben interpretiert, sondern
                       als Interrupt-Nummern im Bereich von 0 bis FF. Trotz-
                       dem ist sowohl die Angabe des Start- und Endwertes
                       als "-DP start end", als auch die Angabe der Anzahl
                       mit "-DP start L count" möglich.

                       Ebenfalls nur im /X-Modus kann auch die Default-
                       Länge für die Dump-Ausgaben angezeigt und umge-
                       ändert werden:

                       --D [count]             stellt Format nicht um
                                               (diese Funktion ist von
                                               SID bekannt)
                       --DB [count]            identisch, stellt aber
                                               gleichzeitig das Format
                                               auf BYTE zurück.

                       Eine veränderte Standardlänge arbeitet auch in
                       Verbindung mit späterem -DI, hier wird die Standard-
                       länge durch 4 dividiert und daraufhin werden ent-
                       sprechend viele Interrupt-Vektoren aufgelistet.
                       Es erscheint eine Meldung, die die aktuelle Ein-
                       stellung für die Standardlänge und das -format
                       (BYTE, WORD, DWORD, POINTERS, INTERRUPTS) des
                       Dump-Kommandos ausgibt. Gibt man count an, so wird
                       die Einstellung der Standardlänge entsprechend
                       umgeändert. Ein anderes Standardformat (außer BYTE)
                       kann man jedoch nur über die oben aufgeführten
                       Einzelkommandos ändern:

                       -DB
                       -DW
                       -DD                     (auch auf 286ern!!!)
                       -DP
                       -DI

                       Die Einstellung für die Standardlänge bleibt auch
                       nach dem Zurückschalten in den /S-Modus erhalten,
                       das Format wird dabei allerdings auf BYTE zurück-
                       gestellt.

                       Eine veränderte Standardlänge wie z.B. --DB 017F
                       oder --D 17F führt dazu, daß beim nächsten -D
                       Kommando ein kompletter Bildschirm vollgeschrieben
                       wird.
                       Besonders praktisch ist die Veränderung der Standard-
                       länge, wenn man eine bestimmte Struktur (etwa ein
                       Feld mit Tabellenwerten) untersuchen will. Hier
                       gibt man mit --D die Länge eines Feldelements an,
                       und kann damit eine automatisch richtig formatierte
                       Ausgabe der einzelnen Elemente bekommen. Bei MS-DOS
                       würde ohne explizite Längenangabe jedesmal der halbe
                       Bildschirm mit Daten vollgeschrieben, die meist gar
                       nicht interessieren und nur dazu führen, daß die
                       relevanten Daten viel zu früh vom Bildschirm ge-
                       scrollt werden.
                       In diesem Zusammenhang bleibt zu erwähnen, daß
                       Novells DEBUG seine Auflistung immer an der
                       angegebenen Position beginnt und nicht - wie bei
                       MS-DOS - die Ausgabe auf die vorherige Paragraphen-
                       grenze ausrichtet.
                       Auch dies führt normalerweise zu übersichtlicheren
                       Ausgaben, denn man wird freiwillig nur dann von
                       den üblicherweise verwendeten Paragraphengrenzen
                       (letzte Ziffer 0) abweichen, wenn man dadurch eine
                       Struktur besser betrachten kann. Bei MS-DOS wird
                       diese Ausgabe dann trotzdem unvorteilhaft ausgegeben.
                       Einen Vorteil hat MS-DOS Methode: Die Offsets +0..+F
                       in einer Dump-Zeile entsprechen immer der letzten
                       Ziffer des Gesamt-Offsets, bei dem man mit dem Dump
                       begonnen hat. Bei Novells DEBUG kann sich dies
                       verschieben. Möchte man eine Ausgabe im Stil von
                       MS-DOS, sollte man also darauf achten, daß die
                       Adreßangabe eine 0 in der letzten Stelle hat.


    -E [address [data]]

                       'Enter' - Im /X-Modus existieren die folgenden
                       erweiterten Modi (für die normale Bedeutung von
                       -EB ohne /X muß man B nach einem Leerfeld angeben,
                       für -EA, -EC..-EF ist dies nicht notwendig.):

                       -EB [address [data]]    Enter BYTE
                       -EW [address [data]]    Enter WORD
                       -ED [address [data]]    Enter DWORD

                       Außerdem kann man (wie bei MS-DOS DEBUG) im Enter-
                       Eingabemodus mit der Minustaste jeweils einen
                       Eintrag zurückgehen.

                       SID gab eine Fehlermeldung aus, wenn z.B. wegen
                       fehlerhaftem RAM die Daten nicht korrekt geschrieben
                       werden konnten. Dies ist im Gegensatz zu MS-DOS DEBUG
                       mit Novells DEBUG nicht mehr der Fall.


    -F range data      'Fill' ist im DOSBOOK dokumentiert.
                       Im /X-Modus gibt es allerdings noch eine weitere
                       undokumentierte Syntax, die analog arbeitet, jedoch
                       16 Bit breit ist:

                       -FW range data

                       Dieser Befehl war auch schon bei SID vorhanden.
                       Eine interessante Eigenschaft von SID bietet
                       Novells DEBUG nicht mehr: SID gab eine Fehler-
                       meldung aus, wenn die geschriebenen Daten nicht
                       wieder gelesen werden konnten, z.B. weil sich
                       kein RAM an der Zieladresse befand.


    -G [=address] [breakpoint]

                       'Go' ist im DOSBOOK dokumentiert.
                       Nach der Ausführung eines Programms wird angezeigt,
                       auf welche Art und Weise das Programm beendet wurde,
                       z.B. normaler Abbruch oder als TSR. Außerdem wird
                       der Fehlercode angegeben (siehe Kapitel II.11.).
                       Bei MS-DOS DEBUG lassen sich 10 Breakpoints angeben,
                       hier sind es maximal 3 Stück.
                       Diese Breakpoints werden mit INT03h-Opcodes gesetzt.
                       Wenn eine solche Stelle erreicht wird, wird der
                       Original-Opcode wieder eingesetzt. Wenn das Programm
                       aber beendet wird, ohne die Breakpoints erreicht zu
                       haben, sind die Breakpoints immer noch vorhanden.
                       Daher sollte die Datei nicht abgespeichert werden
                       und ggf. neu geladen werden. Diese Verhalten
                       unterscheidet sich allerdings nicht von MS-DOS
                       DEBUG. Auf dem Anwenderstack werden übrigens 6 Bytes
                       belegt, da die Ausführung des Go-Befehls mit einer
                       IRET-Anweisung arbeitet.
                       'Go' arbeitet mit der nächsten Anweisung nach
                       einem Haltepunkt weiter, wenn er erreicht wurde.
                       'Go' stoppt nicht nur bei den temporären Halte-
                       punkten, sondern auch bei Haltepunkten, die per-
                       manent im Code vorhanden sind (d.h. eingebaute
                       INT03h-Opcodes). Hier wird natürlich kein Opcode
                       ersetzt.


    -H value1 [value2]

                       'Hex' ist teilweise im DOSBOOK dokumentiert.
                       Diese Funktion stellt praktische Rechenoperationen
                       im Hex-System zur Verfügung. Die zwei angegebenen
                       Argumente werden der Einfachheit halber in allen
                       vier Grundrechenarten miteinander verknüpft und
                       das Ergebnis aller vier Berechnungen in einer Zeile
                       angezeigt (jeweils eingeleitet von der zugehörigen
                       Operation).
                       Bei der Division wird auch der Rest angegeben.
                       (Bei MS-DOS DEBUG wird nur Addition und Subtraktion
                       ausgeführt).

                       Neben dieser offiziellen Variante gibt es noch eine
                       weitere Funktion. Gibt man nur einen Parameter an,
                       so ist verständlicherweise eine Verknüpfung mit
                       einem anderen Wert nicht möglich. Stattdessen wird
                       der angegebene Wert im Hexadezimalsystem, im Dezimal-
                       system und - falls darstellbar - als ASCII-Zeichen
                       ausgegeben. (Diese Funktion war bereits bei SID in
                       voller Blüte vorhanden.)

                       Besonders flexibel ist dieses Kommando, wenn man
                       weiß, daß man nahezu beliebige Ausdrücke für value1
                       und value2 verwenden kann, z.B. Rechenoperationen
                       oder Buchstaben, mehr dazu siehe unten.


    -I port            'Input' ist teilweise im DOSBOOK dokumentiert.

                       Ab Update 13 (DEBUG 1.42) arbeiten die folgenden
                       Erweiterungen nun korrekt. Es werden jetzt auch
                       Ports oberhalb 400h unterstützt, da neuere Systeme
                       auch diese Adressen nutzen.

                       Im /X-Modus gibt es außerdem noch die Kommandos

                       -IB port                Input BYTE
                       -IW port                Input WORD
                       -ID port                Input DWORD (ab 386ern,
                                               ergibt auf 286ern eine
                                               Syntax-Fehler)

                       Das Kommando -I bleibt dabei aber immer in der BYTE
                       Einstellung, egal was man vorher für Kommandos ver-
                       wendet hat.

                       Die syntaktischen Varianten

                       --I port
                       --IB port
                       --IW port
                       --ID port               (ab 386ern, ergibt auf
                                               286ern einen Syntax-Fehler)

                       bewirken augenscheinlich das Gleiche wie ohne die
                       Angabe eines führenden Bindestrichs.

                       Achtung: -IB im /S-Modus liest den Port 0Bh als
                       Byte ein. Ein Leerfeld ist nicht notwendig.
                       -IB erfordert im /X-Modus einen weiteren Parameter,
                       dieser wird dann byte-weise eingelesen.


    -L [address]
    -L address drive start count

                       'Load' ist im DOSBOOK dokumentiert. Soll angeblich
                       auch .HEX-Hexadezimal-Dateien direkt laden können
                       (mit dem dafür üblichen Intel-Hex-Format konnte
                       ich das jedoch bisher nicht nachvollziehen). Beim
                       Laden einer .EXE-Datei wird der Dateikopf direkt
                       ausgewertet und ist nicht mehr verfügbar. Wenn man
                       den .EXE-Header anschauen möchte, muß man die Datei
                       vor dem Laden umbenennen, so daß sie als Binärdatei
                       geladen wird (siehe -N). Andere Dateien werden als
                       binäre Dateien geladen.
                       Die optionale Angabe -L address lädt die (binäre)
                       Datei an die entsprechende Adresse, wodurch speziell
                       auf bestimmte Adreßlagen zugeschnittener Code
                       ausführbar wird. Außerdem ist es möglich, auf diese
                       Weise mehrere Programme gleichzeitig in den
                       Speicher zu laden (wenn man als Startpunkt des
                       jeweils nächsten Programms das Ende des vorherigen
                       angibt - den Registern zu entnehmen) und diese dann
                       gemeinsam in einer Datei abzuspeichern.

                       Bei SID war für Sektor start auch die Angabe eines
                       32Bit-Wertes möglich. Es ist wahrscheinlich, daß
                       dies auch für Novells DEBUG gilt. Die Syntax für
                       Sektor wäre dann nnnn:nnnn, d.h. 0003:FFFF für
                       Sektor 3FFFF.

                       Falls mit -N spezifiziert, lädt dieser Befehl auch
                       die Symbolinformationen aus einer Datei .SYM.


    -M range address   'Move' ist im DOSBOOK dokumentiert.
                       Im Gegensatz zu SID versucht DEBUG, daß die Speicher-
                       bereiche nicht überschrieben werden, auch wenn sie
                       sich überlappen.


    -N [drive:][path]file

                       'Name' ist teilweise im DOSBOOK dokumentiert. Benennt
                       einen Dateinamen für die Dateioperationen 'Load' und
                       'Write' (-L und -W).
                       Undokumentiert ist dabei die spezielle Syntax

                       -N?

                       die Informationen über den eingestellten Namen der
                       Programm- und/oder Symboldatei sowie - falls
                       bereits geladen - über den Dateityp (binär/.EXE)
                       ausgibt. Außerdem werden evtl. angegebene Parameter
                       für das Programm angezeigt.

                       DEBUG unterscheidet den Dateityp nicht allein
                       anhand der Dateiendung, sondern auch anhand des
                       Headers. So kommt es, daß eine .EXE-Datei, die
                       die Dateiendung .COM hat, trotzdem als .EXE
                       interpretiert wird und dementsprechend später
                       auch nicht wieder mit -W zurückgeschrieben werden
                       kann. Möchte man also eine .EXE-Datei - etwa nach
                       einem Patch - wieder zurückschreiben, muß man
                       vorher die Dateiendung auf eine nicht ausführbare
                       Endung ändern (REN TEST.EXE TEST.BIN). Solche
                       Dateien werden dann trotz .EXE-Headers nicht als
                       .EXE-Dateien interpretiert sondern ab Offset 0000h
                       geladen. Dateien vom .COM-Typ werden wie üblich an
                       Offset 0100h geladen (dabei ist - wie gesagt -
                       die Dateiendung .COM nicht allein ausschlaggebend).

                       Außerdem kann man nach dem Dateinamen auch noch die
                       zu dem Programm gehörigen Aufrufparameter angeben,
                       etwa:

                       -N TEST.COM /parameter

                       Nachdem eine ausführbare Datei mit -L geladen
                       wurde, kann man mit diesem Befehl ohne Angabe des
                       Programmnamens neue Programmparameter angeben:

                       -N /parameter

                       Dabei werden alle Zeichenketten akzeptiert; insofern
                       kann es Probleme bereiten, wenn Sie einen neuen
                       Programmnamen spezifizieren wollen. Im Zweifelsfall
                       sollten Sie DEBUG einfach kurz beenden und neu
                       starten.

                       Es gibt noch eine weitere Syntax für die Angabe
                       einer Symboldatei .SYM (die runden Klammern sind
                       hier syntaktisches Merkmal):

                       -N prgfile (symfile) parameter

                       Die Angabe von Parametern ist optional.
                       Eine Programmdatei kann weiterhin angegeben werden,
                       Parameter sind allerdings anscheinend nicht möglich.

                       -N()

                       Löscht den Namen der Symboldatei.

                       Im /X-Modus löscht das folgende Kommando
                       alle Einträge:

                       --N


    -O port, value     'Output' ist teilweise im DOSBOOK dokumentiert.

                       Ab Update 13 (DEBUG 1.42) arbeiten die folgenden
                       Erweiterungen nun korrekt. Es werden jetzt auch
                       Ports oberhalb 400h unterstützt, da neuere Systeme
                       auch diese Adressen nutzen.

                       Im /X-Modus gibt es außerdem noch die Kommandos

                       -OB port, value         Output BYTE
                       -OW port, value         Output WORD
                       -OD port, value         Output DWORD (ab 386ern)

                       Das Kommando -O bleibt dabei aber immer in der BYTE
                       Einstellung, egal was man vorher für Kommandos ver-
                       wendet hat.

                       Die Varianten

                       --O port, value
                       --OB port, value
                       --OW port, value
                       --OD port, value (ab 386ern)

                       arbeiten anscheinend genauso wie ohne voran-
                       gestellten Bindestrich.

                       Achtung: -OB schreibt im /S-Modus den Port 0Bh als
                       Byte (Ein Leerfeld ist nicht notwendig). -OB im /X
                       Modus erfordert einen weiteren Parameter (also ins-
                       gesamt zwei), dieser wird dann byteweise geschrieben.


    -P [=address] [count]

                       'Proceed' ist teilweise im DOSBOOK dokumentiert.
                       Neben der normalen Funktion gibt es noch eine un-
                       dokumentierte Variante.

                       -PU
                       -PU [=address] [count]

                       Hierbei wird die Ausgabe der Registerwerte und
                       Ansprungpunkte mit Zählern größer als 1 unter-
                       drückt (vgl. -TU). Läßt man die Parameter weg,
                       wird ein einzelnes 'Proceed' ohne Ausgabe aus-
                       geführt.
                       'Proceed' arbeitet sehr ähnlich wie 'Trace',
                       allerdings werden auch CALLs, INTs und REP, REPcond
                       als einzelne Anweisungen behandelt und nicht in
                       sie hinein getract (Ist man mit 'Trace' innerhalb
                       einer REP oder REPcond Anweisung, kann man mit
                       'Proceed' sofort bis zu ihrem Ende weiterarbeiten).
                       Wenn eine einzelne Anweisung getract wird, werden
                       für die Ablaufdauer die Interrupts gesperrt, damit
                       man nicht versehentlich in einen auftretenden
                       Interrupt hineintract.
                       Ein echter INT03h im Code kann derzeit (Update 15)
                       weder mit 'Proceed' noch mit 'Trace' übersprungen
                       werden und muß manuell durch Patchen des Codes
                       (Option -E) mit NOP (Opcode 90h) überschrieben
                       werden, damit man weitertracen kann.

                       Im /X-Modus wird auch die Syntax mit vorangestelltem
                       Bindestrich akzeptiert.

                       --P  [=address] [count]
                       --PU [=address] [count]

                       Ob sich dabei allerdings etwas gegenüber der
                       normalen Ausführung ändert ist noch unbekannt.


    -Q                 'Quit' ist im DOSBOOK dokumentiert.


    -R [regname]       'Register' ist zu einem geringen Teil im DOSBOOK
                       dokumentiert. Anzeige und Eingabe von Register-
                       werten. Zeigt auch die Registerwerte bei den Halte-
                       punkten an. Im /X-Modus ändert sich die Anzeige der
                       Register.

                       -RF   die Flags werden ausgegeben (die Angabe unter-
                             scheidet sich im /S-Modus von der im /X-Modus).

                       -R=16 schaltet die Registerausgabe in den 16Bit-
                             Modus. (--R=16 bewirkt das Gleiche)

                       -R=32 schaltet die Registerausgabe in den 32Bit-
                             Modus. (--R=32 bewirkt das Gleiche)
                             (erst ab 386ern)

                       -R=   zeigt den jeweils eingestellten Modus
                             (16 Bit/32 Bit) an (--R= bewirkt das Gleiche).

                       Folgende Registerbezeichnungen sind zulässig (je nach
                       Prozessortyp sind nicht alle Bezeichnungen gültig):

                       AL    AH     AX     EAX         CR0?  TR3?
                       BL    BH     BX     EBX         CR1?  TR4?
                       CL    CH     CX     ECX         CR2?  TR5?
                       DL    DH     DX     EDX         CR3?  TR6?
                                    SI     ESI         CR4?  TR7?
                                    DI     EDI
                                    ES                 DR0?
                                    DS                 DR1?
                                    SS                 DR2?
                                    CS                 DR3?
                                    FS
                                    GS                 DR6?
                                    SP     ESP         DR7?
                                    BP     EBP
                                    IP (=PC)
                                    F

                       (PC als Alias für IP wird nur von MS-DOS DEBUG,
                       nicht jedoch von Novells DEBUG akzeptiert. Die
                       Bezeichnungen CRx, DRx und TRx sind intern codiert,
                       ich konnte sie allerdings bisher noch nicht mit
                       DEBUG auslesen.)

                       Folgende Flag-Bezeichnungen sind erlaubt:

                                        Set:   Clear:

                       Overflow          OV      NV
                       Direction         DN      UP
                       Interrupt         EI      DI
                       Sign              NG      PL
                       Zero              ZR      NZ
                       Auxillary Carry   AC      NA
                       Parity            PE      PO
                       Carry             CY      NC

                       Bezüglich der Syntax zur Eingabe von Registerwerten
                       und Flags siehe DOSBOOK (auch erweiterte 386er-
                       Register können direkt angegeben und verändert
                       werden, natürlich nur, wenn sie auch vorhanden sind).


    -S range data      'Search' ist im DOSBOOK dokumentiert.


    -T [=address] [count]

                       'Trace' ist teilweise im DOSBOOK dokumentiert.
                       Neben den üblichen Möglichkeiten zum Tracen wird
                       das Kommando hier sogar symbolisch behandelt, d.h.
                       es werden nicht nur die jeweiligen Register ange-
                       zeigt, sondern auch, ob Sprünge, Schleifen etc.
                       erfüllte Bedingungen haben oder Flaggen effektiv
                       gesetzt wurden (JUMP, NO JUMP, LOOP, NO LOOP, INT,
                       NO INT, SET 0, SET 1) und die Inhalte der effektiv
                       adressierten Speicherstellen werden auch ausgegeben
                       (so daß man sich ein Speicher-Dump meist sparen
                       kann). Diese in Klammern angegebenen Angaben sind
                       das Ergebnis des Calls und Erleichtern das Ver-
                       ständnis dessen, was beim Weiter-Tracen als Nächstes
                       passieren wird. Die Ausgabe von Speicherinhalten
                       bezieht sich auf den Inhalt der Speicherstelle
                       *vor* der Ausführung der gerade angegebenen An-
                       weisung (die diesen Wert ja verändern kann).
                       Auch symbolische Bezüge zu den meisten DOS, NetWare,
                       GEM APIs und BIOS Interrupts, einigen FarCalls sowie
                       auf PC-Hardware (IO-Bereich) werden aufgelöst und in
                       ihrer Bedeutung angezeigt (Bsp: DOS: Get Int Vector).
                       Dadurch bekommt man einen sehr guten Überblick über
                       den Ablauf eines Programms, auch ohne, daß man jede
                       einzelne Interrupt-Funktion in der Literatur nach-
                       schauen muß. 'Trace' kann auch ROM-Code tracen.

                       Trace arbeitet normalerweise als Single-Step,
                       allerdings gibt es einige wenige Ausnahmen:
                       DOS Interrupts werden nicht getract, sondern wie mit
                       Proceed übersprungen (dies muß so sein, da DOS nicht
                       reenterant ist).
                       DEBUG von MS-DOS fängt diese Gefahrenquelle aller-
                       dings nicht ab und 'erlaubt' damit auch das Tracen
                       in DOS-Interrupts hinein (was manchmal ganz inter-
                       essant sein kann), auf die Gefahr hin, daß man eine
                       nicht reenterante Funktion tract, was meist zum
                       Absturz führt. Sollten Sie diese Trace-Möglichkeit
                       wirklich benötigen, können Sie auch MS-DOS' DEBUG
                       unter Novell DOS laufen lassen, eine korrekt 'ge-
                       türkte' DOS-Version mittels SETVER vorausgesetzt.

                       Bestimmte Assembleranweisungen sperren die Interrupts
                       (einschließlich des Single-Step-Interrupts) direkt
                       nachdem mit MOV oder POP Segmentregister geladen
                       wurden. Eine solche Anweisungsfolge wird (und muß)
                       als ein Programmschritt behandelt werden.

                       Der folgende Hinweis beziehen sich auf MS-DOS DEBUG,
                       dürften aber für Novells Gegenstück genauso gelten:
                       Das Programm sollte die Interrupt-Maske des
                       Interrupt-Controllers nicht verändern, da beim
                       Tracen vor der Ausführung eines Befehls alle
                       Hardware-Interrupts gesperrt werden. Wird dies
                       nicht befolgt, kann es zu unvorhergesehenem
                       Verhalten kommen. Wird ein INT03h im Code verwendet,
                       so wird dieser durch einen Breakpoint ersetzt.

                       Möchte man den Code begutachten, der als nächstes
                       ausgeführt wird, genügt es, während des 'Trace' oder
                       'Proceed' -U ('Unassemble') einzugeben, das so vor-
                       eingestellt ist, daß der richtige Code disassembliert
                       wird.

                       Neben der offiziellen Syntax gibt es noch eine
                       undokumentierte Variante, die die sonst übliche
                       Ausgabe nach jedem Schritt unterdrückt:

                       -TU
                       -TU [=address] [count]

                       Vermutlich gilt dies (analog zu SID) auch für
                       Ansprungpunkte, deren Durchlaufzähler noch größer
                       als 1 ist. Diese werden erst angezeigt, wenn der
                       Zähler 1 erreicht.

                       Im /X-Modus wird auch die Syntax mit

                       --T [=address] [count]
                       --TU [=address] [count]

                       akzeptiert, ob sich hierbei aber etwas gegenüber dem
                       normalen Ablauf ändert, ist noch nicht klar.


    -U [range]         'Unassemble' ist im DOSBOOK weitestgehend dokumen-
                       tiert. Allerdings gibt es eine spezielle Syntax,
                       mit der man die Standardlänge von Disassemblier-
                       ausgaben ohne explizite Angaben voreinstellen kann.

                       --U [count]

                       Ohne Angabe von count wird die aktuelle Einstellung
                       (standardmäßig 12 Befehle) ausgegeben; die Angabe
                       von count verändert diese Einstellung auf die ge-
                       wünschte Anzahl (dies ist vom Prinzip her noch von
                       SID bekannt). Beim Zurückschalten in den /S-Modus
                       bleibt eine evtl. geänderte Standardlänge erhalten.


    -W [address]
    -W address drive start count

                       'Write' ist im DOSBOOK dokumentiert. Dieser Befehl
                       kann nur binäre Dateien speichern (also .COM-Typ).
                       .EXE- oder .HEX-Dateien lassen sich nicht wieder
                       zurückschreiben (dies gilt auch für MS-DOS DEBUG).

                       Bei SID war für Sektor auch die Angabe eines 32Bit-
                       Wertes möglich. Es ist wahrscheinlich, daß dies auch
                       für DEBUG gilt. Die Syntax für Sektor wäre dann
                       nnnn:nnnn, d.h. 0003:FFFF für Sektor 3FFFF.


    -=                 Definieren und Abfragen von Makros:
    -:
                       -=

                       Gibt eine Liste der derzeit definierten Makros aus.
                       Auf diese Art und Weise lassen sich die Makros über
                       Ein/Ausgabenumleitungen wohl auch speichern.
                       Zwei Makros sind immer vordefiniert:
                       DRDOS: und DEVICE:
                       Genaueres kann man der Auflistung selbst entnehmen.

                       -=macroname

                       Führt ein definiertes Makro aus. Ob dabei noch
                       Parameter übergeben werden können, ist noch unklar,
                       scheint aber wahrscheinlich zu sein.

                       -:macroname

                       Makro definieren, ändern oder löschen. Der Prompt
                       wechselt zu :. Jetzt kann man das Makro eingeben.
                       Alle üblichen DEBUG-Befehle sind erlaubt, ein-
                       schließlich Makrokommandos, die allerdings nicht
                       sinnvoll einsetzbar sind. Die Abarbeitung von
                       verschachtelten Makros ist nicht möglich.
                       Makronamen können auch syntaktische Zeichen und
                       Leerfelder enthalten und werden als Ganzes textuell
                       ausgewertet. Nachdem man alle Zeilen des Makros
                       eingegeben hat, kann man mit dem Gleichheitszeichen
                       ('=') am Prompt ':' die Makroaufzeichnung beenden
                       (das ist auch der Grund, warum verschachtelte Makros
                       nicht möglich sind). Der Prompt wechselt wieder zu
                       '-'. Nun kann man mit -= das Makro in der Auflistung
                       ansehen.
                       Möchte man ein Makro löschen, so reicht es, die
                       Makroaufzeichnung direkt mit '=' wieder zu beenden.

                       Im /X-Modus kann man die Makros auch wieder löschen:

                       --:
                       --:macroname

                       Löscht alle Makros (einschließlich der intern
                       definierten) oder nur das Makro mit dem Namen
                       macroname.
                       Die Syntax --:macroname wird auch unterstützt,
                       arbeitet allerdings genauso wie -:macroname.

                       Die Angabe von symbolischen Parametern ist noch
                       unklar, immerhin werden weitere Parameter aber nicht
                       zurückgewiesen.


    -; comment         Kommentar, wenn in der ersten Spalte geschrieben
                       (ist allerdings im DOSBOOK dokumentiert). Diese
                       Funktion war auch schon bei SID vorhanden.


    -?                 Gibt Hilfeseite aus. (Im /X-Modus --? ebenso.)


    -/X                Schaltet in den erweitertem Modus (/X) oder wieder
    -/S                zurück zur Default-Einstellung (/S).

    Drückt man einfach nur <Return> so wird praktischerweise das letzte
    Kommando (mit Folgewerte) wiederholt (unter MS-DOS DEBUG ist das nicht
    möglich, oder zumindest nicht bei allen Kommandos).


   iv. Weitere Hinweise und spezielle Möglichkeiten:
   -------------------------------------------------

   Schlüsselwörter:

    Sollte es Doppeldeutigkeiten bei der Angabe von Mnemos geben, kann man
    mit folgenden Schlüsselwörtern für Klarheit sorgen:

    BYTE WORD DWORD QWORD PWORD FWORD TBYTE NEAR FAR PTR INT

    Die meisten dieser Schlüsselwörter dürfen mit den ersten beiden
    Buchstaben abgekürzt werden:

    BY WO DW QW PW FW TB NE

    Statt 'BYTE PTR' kann man also 'BY', statt 'WORD PTR' 'WO' schreiben.
    Einige Versionen (1.40 und 1.41) von DEBUG haben allerdings wohl
    Probleme mit den Langformen.


   Präfixe:

    Die drei möglichen Präfixe (LOCK, REP, REPcond und Segment-Overrides)
    eines Ausdrucks müssen während des Assemblierens nicht in der gleichen
    Zeile stehen, sondern können auf mehrere Zeilen aufgeteilt werden.
    (Das LOCK Präfix kann anscheinend nicht mit einem anderen Präfix
    zusammen in einer Zeile angegeben werden).


   Zahlenangaben:

    Im DOSBOOK gibt es eine wage Beschreibung dessen, welche Ausdrücke
    bei Zahlenangaben erlaubt sind. Es entsteht der Eindruck, daß man an
    manchen Stellen im Assembler symbolische Registerwerte verwenden kann
    und daß die Kommandozeilen-Syntax sonst recht lax ist (Kommata zwischen
    den Werten sind optional).

    In Wirklichkeit bestehen jedoch sehr viel weiterreichende Möglichkeiten:

    Sämtliche Zahlenangaben erfolgen default-mäßig auf der Basis des
    Hexadezimalsystems. Trotzdem kann man z.B. auch Zahlen im Dezimal-
    system angeben, wenn man ein '#' voranstellt oder auch Buchstaben
    verwenden, wenn diese in Hochkommata eingeschlossen werden. Diese
    werden entsprechend dem ASCII-Code automatisch umgewandelt in die
    zugehörigen Hexzahlen.

    Es ist jederzeit erlaubt, die Grundrechenarten '+', '-', '*' und '/'
    zu verwenden (bei SID waren nur '+' und '-' erlaubt), z.B. statt 18
    kann man auch schreiben 10+8 oder 1A-2 oder statt 200 auch 100*2 usw.
    Dies gilt ganz allgemein an jeder Stelle, auch mehrfach in einem
    Ausdruck. Dabei werden in begrenztem Umfang sogar die Prioritäten
    von Punkt- vor Strichrechnung beachtet. Allerdings sollte man vor-
    sichtig sein, wenn man mehrere Punktrechnungen aufeinander folgen
    läßt: In diesem Fall wird nur die erste Rechnung ausgeführt und
    alles weitere ignoriert.

    Abhelfen kann man dem durch Angabe von Klammerpärchen '(', ')'. Die
    Klammerpaare '[' und ']' haben dagegen eine besondere Bedeutung:
    Sie spezifizieren nicht den Wert, sondern den Inhalt dessen, was durch
    den angegebenen Wert adressiert wird. Jederzeit sind statt direkter
    Zahlenwerte auch Registerbezeichnungen erlaubt (nur 16 Bit breite
    Register), wobei alle Kombinationen unterstützt werden:

    Hier ein paar Beispiele für das -D Kommando:

    -D (10+5)*2 L 10
    -D SI:DX
    -D [100]
    -D [ES:AX], [ES:AX]+10
    -D SI:100 L 5+3
    -D 5+4:SI L AX
    -D 'A', 'Z'-1
    -D 'A' L 10
    -D #10 L #15

    Leerfelder sind innerhalb eines Ausdrucks i. allg. nicht erlaubt.

    Die Angabe von Bereichen kann auf zweierlei Art und Weise erfolgen:
    Entweder man gibt den Startpunkt und Endpunkt an, oder man gibt den
    Startpunkt und nach dem Buchstaben 'L' die Anzahl an. Gibt man keine
    Anzahl an, wird die Default-Anzahl verwendet. Gibt man überhaupt nichts
    an, so wird die Bearbeitung mit der letzten Einstellung fortgesetzt.


   Es muß definitiv Möglichkeiten geben, Makro- und Symboldateien zu laden:

    Die Aufruf-Syntax

     DEBUG =macrofile

    scheint eine Makrodatei als Eingabe zu erwarten.

    Wahrscheinlich gibt es auch eine Möglichkeit Symbole innerhalb des
    Debuggers zu definieren und wieder abzuspeichern (evtl. mit '(', ')').
    Leider habe ich bisher noch nicht genau herausfinden können, wie dies
    vonstatten gehen könnte.
    Insbesondere das Datenformat der Symboldateien ist noch völlig unklar,
    es scheint aber Hexzahlen zu enthalten, außerdem die Schlüsselworte
    LABELS, VARIABLES, NUMBERS, evtl. noch VECTORS (bei SID auch noch CODE,
    DATA, EXTRA, STACK, X1, X2, X3, X4).

    Es gibt zwei sinnvolle Möglichkeiten:

    - Das Format könnte auf dem Format von alten CP/M-Assemblern basieren,
      die .SYM-Dateien erzeugt haben:
      Allerdings haben Versuche mit einigen alten Original-CP/M .SYM-
      Dateien bisher weder mit SID noch mit Novells DEBUG zum Erfolg
      geführt: SID hat jedoch nach dem Laden (und einer Fehlermeldung)
      versucht, die Symbole während des Disassemblierens und in der -H
      Auflistung (ohne Parameter) anzuzeigen; DEBUG hat sein Verhalten
      in keiner Weise geändert, was aber auch daran liegen kann, daß
      eben das Format fehlerhaft war, und SID dies nur nicht abfing.

    - Die andere Möglichkeit besteht darin, daß das Format von Microsofts
      SYMDEB übernommen wurde. Diese Dateien konnte man aus den .MAP-Dateien
      des Linkers mit Hilfe des Utility MAPSYM (bei Microsoft) oder TMAPSYM
      (bei Borland) in .SYM-Dateien konvertieren. Es sieht aber nach einigen
      Tests wohl so aus, als wenn zumindest Borlands .SYM-Format von SID und
      Novells DEBUG nichts akzeptiert wird. (Der Nachfolger von SYMDEB,
      CodeView CV, scheint einen anderen Weg zu gehen: Hier werden mit der
      Option MASM /ZD und LINK /CO Symbolinformationen direkt in die .OBJ-
      und .EXE-Dateien eingebunden.

    DEBUG versucht Begriffe als Symbole zu interpretieren, wenn diese u.a.
    mit einem Punkt oder einem @ beginnen (z.B. -D.P, wobei das -D hier für
    den Dump-Befehl steht). Näheres ist noch unklar, dies deutet aber auf
    eine Verwandtschaft mit dem ZAP-Patch-Utility von Multiuser DOS hin.

    Vielleicht kennt ja jemand anders des Rätsels Lösung und kann mir dies
    mitteilen (schließlich wäre doch gerade das symbolische Debuggen eigener
    Programme äußerst interessant)...


   Remote-Debugging:

    Außerdem enthält Novells DEBUG eindeutig Unterstützung zum Remote-
    Debuggen über eine der seriellen Schnittstellen COM1: bis COM4:, d.h.
    die Steuereingaben des Debuggers kommen nicht von der lokalen Tastatur,
    sondern von einem Terminalprogramm auf einem entfernten Rechner, der
    über eine serielle Schnittstelle an den Debug-Rechner angeschlossen
    ist (9600 Baud, 8 Daten-Bit, 1 Stopp-Bit, keine Parität). Dabei wird in
    irgendeiner Weise eine Syntax wie ':x' mit x=1..4 ausgewertet, und im
    Zweifelsfall die Schnittstelle bei 3F8h gewählt. Leider ist es mir
    bisher noch nicht gelungen, herauszufinden, wie dieser Modus aktiviert
    wird...

                                                                             
  ---------------------------------------------------------------------------

  II.6. STACKER beim Booten nicht laden:
  ======================================

   Stichworte: STACKER, Booten, <Ctrl>+<Alt>

   Um zu verhindern, daß trotz eingerichteten STACKER-Laufwerken beim Booten
   die entsprechenden Treiber geladen werden, muß man am Anfang des Bootens
   die Tasten <Ctrl>+<Alt> gedrückt halten, bis DOS bootet.

   Höchstwahrscheinlich kann man auch <Ctrl>+<F5> und <Ctrl>+<F8> benutzen,
   um das Laden von STACKER zu übergehen, jedenfalls besitzt IBMBIO.COM
   die entsprechende Funktionalität, siehe Kapitel II.2.

                                                                             
  ---------------------------------------------------------------------------

  II.7. STACKER auf Version 4 updaten: [97-02-28]
  ===============================================

   Stichworte: STACKER Update, CHKDSK, INSTALL/SETUP

   Novell DOS 7 liegt eine angepaßte STACKER-Version 3.12 bei (die nicht
   unter anderen Betriebssystemen verwendet werden sollte). Zu den beson-
   deren Fähigkeiten gehört die Unterstützung von DPMS und in Verbindung
   mit NetWare- oder PNW-Servern, die ebenfalls STACKER-komprimierte Lauf-
   werke haben, sogar der Austausch der komprimierten Daten über das Netz.
   Dadurch entfällt weitestgehend das zeitaufwendige Entpacken der Daten
   auf dem einen und Neupacken der Daten auf dem anderen Rechner und
   zusätzlich wird die effektive Netzbelastung durch die kleineren Pakete
   reduziert. STACKER unterstützt auch MS Windows' permanente Auslagerungs-
   dateien, allerdings ist dies verständlicherweise in den meisten Fällen
   mit starken Performance-Einbrüchen verbunden (ausgenommen sehr langsame
   Festplatten auf relativ schnellen Rechnern).

   Wer (trotzdem) auf das eigenständige Produkt STACKER Version 4 updaten
   will (etwa weil er MS Windows95 installieren will), muß sich - sofern
   er auch weiterhin Novell DOS 7 benutzen will - unbedingt ein aktuelles
   Update zu Novell DOS 7 besorgen, da u.a. CHKDSK überarbeitet wurde, um
   mit STACKER 4 zurechtzukommen (indem die STACKER-Überprüfung mit einer
   neuen Option umgangen werden kann). Auch die Installationsprogramme
   INSTALL/SETUP (nur bei Update 11) sind überarbeitet und sollen daher
   mit bereits installiertem STACKER 4 zurechtkommen. Inwieweit die
   speziellen Novell DOS Anpassungen auch in STACKER 4 wiederzufinden
   sind, bzw. umgekehrt, inwieweit es wirklich gefährlich ist, Novells
   STACKER-Version unter anderen Betriebssystemen zu verwenden, ist mir
   leider unbekannt (gerüchteweise soll es - zumindest partiell -
   funktionieren). Zumindest DPMS wird auch von STACKER 4 unterstützt.

   Um Doppeldeutigkeiten und seltsames Systemverhalten zu vermeiden, sollte
   man alle zu STACKER 3.12 gehörenden Dateien aus dem c:\nwdos\ Verzeichnis
   entfernen:

    DCONVERT.COM, DCONVRT2.EXE, SCONVERT.EXE, SCREATE.SYS, SDEFRAG.COM,
    SDEFRAG2.EXE, SCREXEC.EXE, STACFM.DLL, STACFM.HLP, STACHIGH.SYS,
    STACKER.COM, STACKER.EXE, STACLOAD.BIN, UNSTACK.COM, UNSTACK2.EXE,
    WINSWAP2.EXE.

   Noch ein Hinweis am Rande:
   Derzeit (Update 15) unterstützt der Kernel von Novell DOS 7 bezüglich der
   Preload-Schnittstelle wohl nur STACKER.BIN bzw. DBLSPACE.BIN und nicht
   das mit MS-DOS 6.22 eingeführte DRVSPACE.BIN. Da sich DRVSPACE und das
   vorherige DBLSPACE aber so gut wie gar nicht unterscheiden (die größten
   Unterschiede bestehen in den Meldungen...), sollte Novell DOS 7 auch
   problemlos mit DRVSPACE zurechtkommen, nachdem man den Novell DOS Kernel
   so gepatcht hat, daß er nach DRVSPACE.BIN statt nach DBLSPACE.BIN sucht.

                                                                             
  ---------------------------------------------------------------------------

  II.8. Rechnerkopplung über Punkt-zu-Punkt-Verbindungen: [97-02-04]
  ==================================================================

   Stichworte: MS-DOS, INTERLNK, INTERSRV, Datenverluste, FILELINK, Remote,
               TASKMGR, CTTY, FASTLYNX, LAPLINK, NC, IPX, PNW, SERVER,
               virtuelle Maschine, DOS-Box

   Zunächst ein kurzer Überblick über die möglichen Transfer-Arten der
   bekanntesten Programme, die eine Rechnerkopplung über Punkt-zu-Punkt-
   Verbindungen erlauben:

                               Seriell    Parallel           IPX

    Novell DOS FILELINK          ja          ja              nein
    MS-DOS INTERSRV/INTERLNK     ja          ja              nein
    Norton Commander 3.0  [NC]   ja          nein           (nein)
    Norton Commander 4.0+ [NC]   ja          ja             (nein)
    LAPLINK 3.xx [LL]            ja          nein           (nein)
    LAPLINK PRO 4.0 [LLPRO]      ja          ja             (nein)
    FASTLYNX 1.xx [FX]           ja, auto    ja, auto       (nein)
    FASTLYNX 2.0+ [FX]           ja, auto    ja, auto      ja, auto

   Für serielle Verbindungen werden übliche 3-, 5- oder 7-adrige Nullmodem-
   kabel oder eine Modemverbindung benötigt, mit jeweils unterschiedlicher
   Datensicherheit und maximaler Geschwindigkeit (Maximum ist 110 kBd).

   Für Verbindungen über die parallele Schnittstelle wird glücklicherweise
   vom Norton Commander, LAPLINK, FASTLYNX, FILELINK und INTERSRV/INTERLNK
   das gleiche Parallel-Nibble-Transfer-Kabel (oft als 'Laplink'-Kabel
   bezeichnet) benötigt, das mittlerweile auch in PC-Läden zu kaufen ist
   und nicht mehr nach der Programmdokumentation selbstgebastelt werden
   muß (siehe z.B. im DOSBOOK bei FILELINK).
   Die Übertragungsrate hängt von der Rechnergeschwindigkeit und der Aus-
   legung des Ports ab, ist normalerweise aber mindestens einer seriellen
   Verbindung mit 110 kBd ebenbürtig, mit starker Tendenz nach oben (bis
   ca. 1 MByte/s). Eventuell wird mit Druckerports von uralten Original-PCs
   (1. Serie) sowie mit modernen ECP/EPP-Ports auch ein bidirektionaler
   Transfer ermöglicht, wofür aber ein anderes Kabel notwendig wäre (mangels
   zweier solcher Schnittstellen habe ich das noch nicht überprüfen können).

   Interessant ist, daß FASTLYNX 2.0+ sogar Verbindungen durch ein auf
   den zugehörigen Rechnern geladenes IPX tunneln kann (wie heutige, hier
   nicht verzeichnete Versionen von LAPLINK auch). Dafür müssen lediglich
   die Netztreiber der IPX-Schicht (bei Personal NetWare also der Hardware-
   Treiber wie NE2000.COM sowie LSL.COM und IPXODI.COM) geladen sein,
   SERVER.EXE oder VLM.EXE sind nicht notwendig! Manchmal reichen die
   Möglichkeiten einer Punkt-zu-Punkt-Verbindung ja durchaus aus und die
   komplette Netzankopplung eines Rechners wird gar nicht benötigt. In
   diesem Fall kann man sich so das Laden der restlichen Client- (VLM.EXE
   oder NETX.EXE) oder Server-Software (SERVER.EXE) sparen und so wertvollen
   Speicherplatz gewinnen.
   Diese Methode hat auch den Vorteil, daß zwischen den beiden Rechnern
   keine 1:1-Verkabelung bestehen muß; ein installiertes Ethernet tut's
   auch. FASTLYNX fragt in diesem Fall nach, welchen Rechner es als
   Gegenstelle annehmen soll. Da VLM.EXE (und SERVER.EXE) nicht geladen
   werden muß, funktioniert eine solche Verbindung (bei geeigneter Ein-
   stellung) sogar dann, wenn man die IPX-Treiber unter dem multitaskenden
   TASKMGR nur innerhalb eines Tasks lädt! In den anderen Tasks hat man
   dann zwar keine IPX-Verbindung, dafür aber mehr Speicherplatz zur
   Verfügung...

    Ein interessanter Einschub für PNW:

     Ja, das geht wirklich! - Würde man für eine vollständige Netzankopplung
     hingegen auch VLM.EXE (und SERVER.EXE) laden wollen, so müßte dies vor
     dem Start des TASKMGR geschehen, oder - mit Einschränkungen - in einer
     DOS-Box einer unter Novell DOS 7 laufenden Windows 3.1x Session im
     Erweiterten 386er-Modus. Im ersteren Fall hätten dann später alle Tasks
     entsprechend viel Speicher weniger, im zweiten Fall stehen nicht alle
     Möglichkeiten (NMR.VLM, FIO.VLM) zur Verfügung und SERVER.EXE kann DPMS
     nicht nutzen (Verlust ca. 28 KByte), wodurch zumindest dieser Task nur
     noch sehr wenig freien Speicher übrig ließe. Umgekehrt könnte man
     natürlich in unterschiedlichen Tasks auch unabhängig voneinander für
     unterschiedliche Netzadapterkarten gleichzeitig IPX-Stacks aufbauen.
     Aber bitte nicht in mehreren Tasks die Treiber für die gleiche Netz-
     adapterkarte laden oder Benutzerdaten ändern, denn aufgrund mangelnder
     Kommunikation zwischen den virtuellen Maschinen würde das zum Daten-
     chaos führen (Windows fängt das aber üblicherweise auch ab)...
     (unbedingt: siehe Kapitel VI.2.)

   Üblicherweise sind über die Netzverbindung noch größere Transferraten
   erzielbar als über parallele Verbindungen, d.h. theoretisch bis hin zu
   maximal 10MBit/s.

   Das Programm INTERSRV von MS-DOS soll völlig inkompatibel zu Novell DOS 7
   sein und schwere Datenverluste auf der Festplatte verursachen (nicht
   überprüft ;-) ). Das Gegenstück INTERLNK kann aber problemlos unter
   Novell DOS 7 ausgeführt werden, so daß man trotzdem die Verbindung zu
   einem MS-DOS System aufnehmen kann.

   Stabilen Ersatz liefert Novell selbst in Form des recht komfortablen
   Programms FILELINK mit (das in weniger leistungsfähiger Version auch
   schon bei DR DOS 6.0 beilag).

   Für viele ist jedoch die in den Norton Commander (NC) integrierte
   Link-Funktion die einfachste Alternative zu letzten beiden Programmen,
   weil man sich nicht an eine andere Umgebung gewöhnen muß und (fast)
   alles genauso funktioniert, als wenn man zwischen zwei Verzeichnissen
   des gleichen Rechners Dateien hin und her kopiert.

   Lediglich die bei MS-DOS INTERSRV/INTERLNK gegebene Möglichkeit
   der Ausführung von Kommandos auf dem Fremdrechner bietet FILELINK
   nicht, aber dafür gibt es sowieso wesentlich bessere Alternativen
   wie etwa obiges FASTLYNX (FX). (Die mir bekannten, älteren und
   ehemals standardsetzenden Versionen von LAPLINK können weder von
   der Funktionalität, noch von der Flexibilität mit FASTLYNX oder
   auch nur dem NC konkurrieren.)

   Wenn auch etwas bodenständiger, dafür aber auch flexibler, braucht
   man auch unter ausschließlicher Verwendung von Novell DOS 7 Bord-
   mitteln nicht auf eine Möglichkeit zur Fernsteuerung verzichten:

   Die diesbezüglich Alternative ist eine Terminal-Emulation (etwa
   CTTY COM1:), die bei Novell DOS 7 natürlich besonders in Verbindung
   mit dem TASKMGR Sinn ergibt. Dieselbe serielle Verbindung kann auf
   beiden Rechnern jedoch nicht gleichzeitig von mehreren Programmen
   benutzt werden. Multitasking-Betrieb mit Zugriff auf die gleiche
   Schnittstelle ist daher nicht angebracht. Stehen mehrere serielle
   Kanäle zur Verfügung, ist das Ganze jedoch kein Problem. Näheres
   hierzu in Kapitel VII.5.

                                                                             
  ---------------------------------------------------------------------------

  II.9. Erweiterte Kommandozeilen-Syntax am Prompt: [97-03-23]
  ============================================================

   Stichworte: Kommandozeile, Prompt, Syntax, COMMAND.COM, 4DOS, Paßwörter,
               Listendateien, Dateilisten, Gruppen, UNC

   Obwohl es auch für Novells COMMAND.COM noch besseren Ersatz gibt (4DOS),
   ist die Syntax der Kommandozeile (auch bei den externen Kommandos) in
   einigen interessanten Punkten erweitert (dies ist zwar teilweise seit
   DR DOS 3.41 dokumentiert, da aber immer noch MS-DOS als 'Standard' gilt,
   weitestgehend unbekannt), siehe auch Kapitel II.11. Auch die meisten
   externen Novell Kommandos erlauben diese Erweiterungen.


   - Paßwörter:   Nach der Dateispezifikation kann ein Datei-/Pfadpaßwort
                  mittels Semikolon angehängt werden (ab DR DOS 3.41):

                   DIR file;password

                  (Achtung: Unter 4DOS muß das Semikolon i. allg. verdoppelt
                  werden! Allerdings kann man dies leider nicht auf alle
                  Befehlen übertragen: Befehle, die keine 4DOS-Include-
                  Listen erlauben (wie MD, CD) und deshalb auch ein ein-
                  faches Semikolon nicht mißverstehen würden, akzeptieren
                  leider auch kein verdoppeltes Semikolon, und das, obwohl
                  ein Semikolon kein gültiges Zeichen für ein Paßwort ist,
                  und daher eigentlich beides zugelassen werden könnte,
                  siehe auch Kapitel II.20.)

                  Mit dieser Syntax werden nicht nur bereits mit PASSWORD
                  gesetzte Paßwörter angegeben, sondern es können implizit
                  auch neue Paßwörter gesetzt werden. Problematisch daran
                  ist, daß die Angabe eines Paßwortes unter MS-DOS und
                  PC-DOS nicht erlaubt ist. Näheres zu diesem Themenkomplex
                  in Kapitel II.4. unter PASSWORD.

                  Die Angabe eines Paßwortes (auch unter 4DOS nur mit einem
                  Semikolon getrennt) ist auch innerhalb der Eingabemasken
                  beliebiger Fremdprogramme möglich und notwendig, falls die
                  jeweiligen Programme mit diesen Dateien trotz gesetzter
                  Paßwörter arbeiten sollen). Voraussetzung dafür ist aller-
                  dings, daß das Programm das Semikolon und eine mehr als
                  8 Zeichen lange Eingabe in Unkenntnis dieses Novell DOS/
                  DR DOS Features nicht als ungültig zurückweist (wie leider
                  häufig der Fall). Dies funktioniert deshalb, weil die
                  Paßwortunterstützung von DR DOS/Novell DOS direkt im
                  Betriebssystem-Kernel untergebracht und nicht etwa
                  - wie oft vermutet - eine Eigenschaft der jeweiligen
                  Kommandos ist! (Dies bedeutet übrigens auch, daß auch auf
                  API-Ebene in Dateispezifikationen mit Semikolon getrennte
                  Paßwörter angegeben werden können.) Natürlich besitzen
                  unabhängig von diesem Sachverhalt die meisten Novell/
                  DR DOS Programme *zusätzliche* Sonderbehandlungen für
                  Paßwörter, die den Komfort noch steigern; der grund-
                  sätzliche Mechanismus ist jedoch Bestandteil des Kernels
                  und kann daher prinzipiell aus jeder Anwendung heraus
                  verwendet werden (auch wenn diese nicht das geringste
                  von Paßwörtern ahnt).

                  Und was machen Sie, wenn sowohl übergeordnete Ver-
                  zeichnisse, als auch die Dateien selbst mit einem
                  (unterschiedlichen) Paßwort versehen sind?

                  Wenn Sie sich schon im paßwortgeschützten Verzeichnis
                  befinden, brauchen Sie normalerweise nur das Paßwort der
                  Datei angeben, da Sie über einen relativen Pfad (den Sie
                  sich bereits 'freigeschaltet' haben) auf die Datei zu-
                  greifen. In Ausnahmefällen (z.B. beim Aufruf von Programm-
                  dateien in solchen Verzeichnissen) wird jedoch intern über
                  den vollen Pfad auf die Datei zugegriffen: In solchen
                  Fällen müßte man eigentlich *beide* Paßwörter angeben,
                  so als ob Sie sich noch außerhalb des paßwortgeschützten
                  Verzeichnisses befänden. Dies scheint auf den ersten Blick
                  unmöglich, d.h. man müßte immer erst in das jeweilige
                  Verzeichnis wechseln.
                  Es gibt aber eine völlig undokumentierte Möglichkeit, die
                  leider derzeit nur mit Novells COMMAND.COM funktioniert:

                   c:\testdir            sei paßwortgeschützt mit
                                         Paßwort "hello" und
                   c:\testdir\dummy.txt  sei paßwortgeschützt mit
                                         Paßwort "world"

                   TYPE c:\testdir;hello\dummy.txt;world    funktioniert!!!

                  Das Prinzip läßt sich bei weiter verschachtelten Unter-
                  verzeichnissen auch auf mehr als zwei Paßwörter verallge-
                  meinern. Die Angabe mehrerer Paßwörter in einer Datei-
                  spezifikation wird von 4DOS 5.51/5.52a (und früher) leider
                  als Fehler zurückgewiesen.
                  Paßwortgeschützte Verzeichnisse stellen unter 4DOS sowieso
                  ein gewisses Problem dar, denn der Novell DOS Kernel will
                  natürlich in einem Fall wie dem obigen beide Paßwörter
                  wissen, und da 4DOS intern offenbar immer über absolute
                  Pfade auf Dateien zugreift, auch dann, wenn man sich
                  bereits im Verzeichnis C:\TESTDIR befindet, trifft diese
                  Situation hier ständig auf...

                  Um aber wenigstens bezüglich der anderen Unterschiede
                  in der Paßwortbehandlung Kompatibilität unter 4DOS und
                  Novell DOS bzw. DR DOS COMMAND.COM zu erreichen, sollte
                  man in Batchjobs generell folgenden Trick anwenden:

                   DIR file%;%;password

                  wobei die Umgebungsvariable %;% unter Novell DOS' und
                  DR DOS' COMMAND nicht definiert ist (und mit SET aufgrund
                  ungültiger Syntax auch nicht definiert werden kann; es sei
                  denn auf Seitenwegen über direkte Manipulation der System-
                  Umgebung), unter 4DOS jedoch ganz normal belegt werden
                  kann. Irgendwo vorher (z.B. in AUTOEXEC.BAT) fügt man dann
                  folgende Zeile in die Batch-Bearbeitung ein:

                   IF "4"=="%@Eval[2 + 2]%" SET ;=;

                  In obigem Beispiel wird nun unter 4DOS die Variable %;%
                  durch ';' ersetzt und das Paßwort wird von zwei Semikolon
                  eingeleitet. Unter COMMAND.COM ist die Variable %;% nicht
                  definiert und wird durch eine Null-Zeichenkette ersetzt.
                  Dadurch erscheint nur ein Semikolon in der Kommandozeile.
                  Es ist übrigens wichtig, daß das erste Semikolon durch %;%
                  ersetzt wird, denn ansonsten müßte man vor dem Paßwort
                  noch ein für die Dateibearbeitung nicht akzeptiertes
                  Leerfeld angeben. Dieser Trick kann auch unter der
                  4DOS-Kommandozeile angewendet werden, nicht aber in der
                  COMMAND.COM-Kommandozeile, da hier keine Ersetzung von
                  Umgebungsvariablen stattfindet. Innerhalb von Datei-
                  eingabemasken von Programmen ist diese Angabe ebenfalls
                  nur in den seltensten Fällen erlaubt, da auch hier so
                  gut wie nie Ersetzungen von mit % eingerahmten Variablen
                  stattfinden (Ausnahmen sind aber vorhanden und sollten
                  für eigene Programme berücksichtigt werden).

                  Ein Problem besteht allerdings immer noch:

                  Batchjobs, in denen entsprechend dieser erweiterten Syntax
                  explizit Paßwörter angegeben werden, arbeiten unter
                  Novell DOS/DR DOS als auch unter 4DOS/NDOS, nicht aber
                  unter MS-DOS/PC-DOS.
                  Normalerweise werden hier auch keine Paßwörter gesetzt
                  sein, aber es besteht ja die Möglichkeit, daß unter
                  Novell DOS Paßwörter gesetzt wurden und danach der Rechner
                  unter MS-DOS gebootet wird. Noch komplizierter wird es,
                  da bei aktiviertem Long-Filename-Support mit MS-DOS 7
                  unter MS Windows95 sogar das Semikolon zum gültigen
                  Zeichen einer Dateispezifikation avanchiert.
                  Wenn man Batchjobs schreiben möchte, die auch unter
                  diesen Voraussetzungen noch sauber arbeiten, muß man
                  einen weiteren Trick anwenden, indem man auch die
                  Paßwörter nicht direkt, sondern über Umgebungsvariablen
                  angibt: Diese Umgebungsvariablen dürfen dann nur belegt
                  werden, wenn unter Novell DOS/DR DOS gebootet wurde
                  (siehe Kapitel IV.7.).

                  Das folgende Beispiel verdeutlicht dies:

                   ...
                   SET envpassword=
                   IF NOT "NWDOS"=="%Os%" IF NOT "DRDOS"=="%Os%" ...
                                      ... IF NOT "OPENDOS"=="%Os%" GOTO skip
                   IF "4"=="%@Eval[2 + 2]%" SET ;=;
                   SET envpassword=password
                   :skip
                   DIR file%;%;%envpassword%
                   SET envpassword=
                   ...

                  Diese Syntax muß genau eingehalten werden, damit sie unter
                  allen Versionen von COMMAND.COM sowie 4DOS/NDOS arbeitet.
                  Dabei
                  wird die Angabe des Paßwortes unter den einzelnen
                  Betriebssystemen recht unterschiedlich ausgewertet,
                  das Resultat ist jedoch immer, daß die Funktion bereit-
                  gestellt wird, die jeweils notwendig ist:
                  Unter anderen Systemen als DR DOS und Novell DOS werden
                  die Variablen %envpassword% und %;% nicht belegt, daher
                  wird nur "DIR file" ausgeführt. Unter DR DOS/Novell DOS
                  COMMAND.COM wird %envpassword% belegt und damit
                  "DIR file;password" ausgeführt. Läuft 4DOS/NDOS unter
                  DR DOS/Novell DOS, so werden beide Variablen belegt, das
                  Ergebnis ist "DIR file;;password".
                  Voraussetzung für die Funktion dieses Beispiels ist es,
                  daß die Variable %Os% auch unter 4DOS/NDOS gesetzt wird,
                  was üblicherweise *nicht* der Fall ist (muß z.B. in
                  AUTOEXEC.BAT manuell geschehen, wenn ein DR DOS/Novell DOS
                  Kernel erkannt wurde, siehe Kapitel IV.7.). Wie dies
                  sicher bewerkstelligt werden kann, wird an anderer Stelle
                  in dieser Datei beschrieben.


   - Listendatei: Bei vielen Kommandos kann statt einer direkten Datei-
                  auflistung mit direkt vorangestelltem @ eine Datei
                  angegeben werden, die eine Liste von zu bearbeitenden
                  Dateien enthält (ab DR DOS 5.0).
                  (Hinweis: Ich unterscheide in diesem Dokument zwischen
                  Listendateien, d.h. Dateien, die eine Liste von Dateien
                  enthalten, und letzten Dateilisten, die eine Liste
                  mehrerer Dateispezifikationen enthalten, siehe unten.)

                  Die Dateien innerhalb der Listendatei können selbst auch
                  wieder Wildcards enthalten, wohingegen als Datei-
                  spezifikation für eine @Listendatei keine Wildcards und
                  damit mehrere Dateien angegeben werden dürfen. Außerdem
                  darf eine Listendatei keine Verweise auf weitere Listen-
                  dateien enthalten (sicher, um Rekursionen zu vermeiden);
                  auf diese Weise sind also auch Dateien mit einem '@'
                  als ersten Buchstaben (z.B. alte Backup-Dateien) innerhalb
                  der Listendatei problemlos ansprechbar.
                  Wegen der möglichen Fehlinterpretation als Listendatei ist
                  es sonst notwendig, ein paar Tricks anzuwenden, um eine
                  Datei, die tatsächlich mit dem Zeichen '@' beginnt,
                  anzusprechen (siehe auch Kapitel II.20.):

                  - über relative Pfadangaben, d.h. voranstellen von '.\'
                    oder 'd:' (mit d: als dem aktuellen Laufwerk), z.B.
                    statt "@backup.dat" nun ".\@backup.dat"
                  - über Wildcards, die nicht mit '@' beginnen (z.B. ist
                    "@*.*" nicht möglich)
                  - (temporäres) Umbenennen der Datei (mit REN)
                  - Verwendung eines Ersatz-Kommandos, das keine Listen-
                    dateien unterstützt (z.B. interne Kommandos)

                  Eine Listendatei kann z.B. mit XDIR /B erzeugt werden:

                   XDIR *.txt /B > filelist.lst

                  um dann wie folgt verwendet zu werden:

                   XDIR @filelist.lst

                  In der Digital Research Literatur wird für Listendateien
                  häufig die Dateiendung .FL (File-List) verwendet (wie
                  gesagt, bitte im Deutschen nicht mit Dateilisten ver-
                  wechseln, die in diesem Dokument meist als mehrfache
                  Dateispezifikationen, manchmal auch als Einschlußliste
                  und bei 4DOS auch als 'inclusion list' bezeichnet werden).

                  Normalerweise muß jede Dateispezifikation einer Listen-
                  datei in einer neuen Zeile anfangen. Allerdings ist dies
                  - undokumentiert - nicht notwendigerweise so: Einzelne
                  Dateien können auch mit Leerfelder, Tab oder Komma
                  voneinander getrennt werden. Möchten Sie Paßwörter in
                  einer solchen Listendatei angeben, so müssen Sie diese
                  wie gewohnt mit Semikolon von der jeweiligen Datei-
                  spezifikation trennen, dazwischen werden keine Leerfelder
                  akzeptiert.

                  Liste der Kommandos, die Listendateien akzeptieren
                  (noch unvollständig):

                   ATTRIB, FC, FILELINK, FIND, MOVE, PASSWORD, PNUNPACK,
                   REPLACE, STACKER, TOUCH, XCOPY, XDEL, XDIR.

                  (Bei CCI Multiuser DOS 7.22 COMP statt FC, außerdem
                   noch XATTRIB.)

                  Es gibt auch eine Reihe Fremdprogramme, die Listendateien
                  unterstützen, etwa alle Programme von PKWare (PKPAK,
                  PKUNPAK, PKZIP, PKUNZIP, usw.). Einige dieser Fremd-
                  programme erlauben jedoch auch Kommentare in Listen-
                  dateien, die meist einfach mit Semikolon eingeleitet
                  werden (nicht unbedingt am Anfang der Zeile). Hier gibt
                  es u.U. Probleme, wenn DR DOS oder Novell DOS solche
                  Kommentare als Paßwörter zu interpretieren versucht.
                  Wenn Sie das Semikolon nur jeweils unmittelbar hinter
                  einer normalen Dateispezifikation verwenden, gibt es
                  zwar keine Syntaxfehler und solange Sie die Listendatei
                  nicht zum Erzeugen oder Verändern von Dateien verwenden
                  auch keine Probleme: Der Kernel interpretiert zwar die
                  Kommentare als Paßwörter, was aber solange ohne Folgen
                  bleibt, wie die Datien keinen Paßwortschutz besitzen
                  und nicht schreibend auf sie zugegriffen wird (mit
                  XDIR und bedingt XDEL klappt's also prima). Mit XCOPY
                  erhalten die neuen Dateien aber die Kommentare als
                  Paßwörter, sicherlich nicht das, was gewünscht wurde...


   - Mehrere Dateispezifikationen in einer Zeile (Dateilisten):

                  Ähnlich wie bei 4DOS können in vielen Fällen (meist bei
                  externen Kommandos, wo die Syntax dabei eindeutig bleibt)
                  direkt mehrere Dateispezifikationen in einer Zeile an-
                  gegeben werden (ab DR DOS 5.0); diese können sogar Wild-
                  cards enthalten. Darauf wird in den Hilfeübersichten (/?)
                  der entsprechenden Kommandos hingewiesen:

                   XDIR *.TXT *.DOC

                  Anstelle der Dateispezifikationen können Sie natürlich
                  auch hier Listendateien angeben, auch mehrere gleich-
                  zeitig. Die einzelnen Spezifikationen müssen bei DR DOS
                  und Novell DOS mit Leerfeldern oder Tabs voneinander
                  getrennt werden, Kommata werden zurückgewiesen, Semikoli
                  als Einleitung für Paßwörter interpetiert. Dies ist
                  wichtig zu wissen, da die unter 4DOS/NDOS üblichen
                  Dateilisten (inclusion lists) hier meist ein Komma er-
                  warten (oft reicht aber auch hier ein Leerfeld oder Tab).

                  Die einzelnen Dateien oder Masken werden zusammengefaßt
                  und gemeinsam bearbeitet (also nicht der Reihe nach ge-
                  trennt bearbeitet). Auf diese Weise wird sichergestellt,
                  daß jede Datei auch wirklich nur einmal bearbeitet wird,
                  obwohl sie vielleicht auf mehrere Masken paßt. (Achtung:
                  Einige Nach-Implementationen dieser Funktion, etwa in
                  meiner CUI_LIB, bearbeiten die einzelnen Masken der
                  Reihe nach, so daß eine Datei u.U. auch mehrfach benutzt
                  wird.)

                  Kommandoübersicht, die dies unterstützen
                  (noch unvollständig):

                   ATTRIB, FIND, PASSWORD, TOUCH, XDEL, XDIR.

                  Die Dateispezifikation bei XDIR darf auch mit doppelten
                  Anführungszeichen (") eingerahmt werden (sinnvoll für
                  Spezialfälle, vgl. FIND).


   - Gruppen:     Diese undokumentierte Möglichkeit vieler Kommandos
                  erlaubt die Angabe von Benutzeranmelde (also Account-Name)
                  oder Gruppennamen in der Syntax /U:name (auch schon bei
                  einigen Kommandos von DR DOS 6.0).
                  Bekommt in Verbindung mit Novell DOS/DR DOS Multiuser-
                  Varianten, von denen Novell DOS genauso abstammt wie von
                  DR DOS 6.0, eine Bedeutung, sofern die Systemabsicherung
                  aktiviert ist (die bei DR Multiuser DOS beiliegenden
                  zusätzlichen Kommandos kennen jedenfalls auch die Option
                  /U, etwa SHOW oder XATTRIB). Ob die Option auch in Ver-
                  bindung mit NetWare, lokaler Absicherung etc. eine
                  Bedeutung hat, ist eher fraglich, auch wenn es dort auch
                  Gruppen- und Benutzernamen gibt.
                  Die entsprechenden Programme prüfen auf Multiuser-Eigen-
                  schaften des Betriebssystems, nicht auf Netzanbindung,
                  siehe auch Kapitel VII.5.

                  Kommandoübersicht, die /U:name unterstützen:

                  - Novell DOS 7, OpenDOS, CCI Multiuser DOS 7.22 Gold:

                    ATTRIB, BACKUP, MOVE, TOUCH, TREE, XCOPY, XDEL, XDIR

                  - DR DOS 6.0+, Novell DOS 7, OpenDOS:

                    DELPURGE, UNDELETE

                  - nur Multiuser-Varianten wie CCI Multiuser DOS 7:

                    XATTRIB, SHOW???

                  Falls jemand ein Concurrent DOS oder DR Multiuser DOS
                  besitzt, wäre es nett, wenn er mir entsprechende
                  Informationen übermitteln könnte. Denn mit einem
                  kleinen selbstgeschriebenen Treiber ließe sich auch
                  für ein 'normales' Novell DOS eine sinnvolle Funktion
                  für dieses Feature nachkonstruieren.


   - Optionskombinationen:

                  Statt der üblichen Variante, jeden Parameter einzeln
                  mit einem SwitChar einzuleiten, kann man bei den meisten
                  externen (und allen internen) Kommandos Parameter auch
                  zusammenfassen:

                   XDIR *.* /C /L /P /S      ->  XDIR /CLPS

                  Getestet (noch nicht vollständig): XDIR, XCOPY, XDEL, MOVE

                  Das Kommando ATTRIB erlaubt dies auch für die '+'/'-'-
                  Optionen.


   - Hilfeparameter:

                  Normalerweise muß ein Hilfeparameter (/? oder /H) der
                  erste Parameter eines Kommandos sein, damit er generell
                  akzeptiert wird (so zum Beispiel bei allen internen
                  Kommandos). Bei den externen Kommandos gilt dies im
                  Prinzip auch, weil es z.B. bei XDIR und XCOPY mit dem
                  /H Parameter zu Doppeldeutigkeiten kommen könnte. Ein
                  hinten angegebenes /H bedeutet dann also nicht /HELP,
                  sondern steht für die entsprechend zugeordnete Funktion.
                  Nichtsdestotrotz funktioniert /? (meist) auch am Ende
                  einer Befehlszeile, und auch in Optionskombinationen.

                  Ist der SwitChar (siehe Kapitel II.1.) auf '-' statt des
                  üblichen '/' verstellt, so bekommen Sie Probleme mit
                  Programmen, die die Angabe von ausschließenden Datei-
                  attributen über die Syntax -H erlauben (XDIR), da diese
                  dann als Aufforderung zur Hilfe mißverstanden werden.
                  Abhilfe ist nur möglich, indem Sie den SwitChar -
                  zumindest vorübergehend - auf ein anderes Zeichen als
                  '-' (bzw. '+' bei Einschlußlisten) einstellen.

                  Achtung: ? ist gleichzeitig auch ein DOS-Wildcard.
                  Achten Sie darauf, daß Sie den /? Parameter nicht dort
                  verwenden, wo er als Dateimaske fehlinterpretiert werden
                  könnte (wie dies manchmal am Ende von Optionskombinationen
                  möglich ist).

                  Vielleicht ist es für Sie bei der automatischen Auswertung
                  von Hilfsschirmen (etwa innerhalb von Batchjobs) von Be-
                  deutung zu wissen, daß die Hilfeschirme von DR DOS und
                  Novell DOS 7 ein bestimmtes Format haben:

                  Zunächst folgt eine Zeile mit dem Namen des Kommandos,
                  bei externen Kommandos der Versionsnummer und einer Kurz-
                  beschreibung seiner Funktion, danach folgt bei den ex-
                  ternen Kommandos eine Zeile mit dem Copyright-Hinweis.
                  Nach einer Leerzeile folgt ein Syntax-Überblick, eine
                  weitere Leerzeile und danach die Erklärung der einzelnen
                  Parameter. Optional folgt (oder ist vor der Parameter-
                  erklärung eingefügt) eine weitere Leerzeile und zusätz-
                  liche Benutzungshinweise und Beispiele.

   Außerdem ist es bei Novell DOS möglich, Pfad- und Dateispezifikationen
   in der normalen 'DOS-Syntax', und auf Netzlaufwerken auch in der
   NetWare-Syntax und UNC-Notation anzugeben, siehe Kapitel VI.10.

   Weitere Hinweise zu COMMAND.COM Interna in der Datei NWDOS7UN.TXT.

                                                                             
  ---------------------------------------------------------------------------

  II.10. Gemischte DOS-Systeme:
  =============================

   Stichworte: DR DOS, MS-DOS, PC-DOS, NWDOS

   Im Gegensatz zur verkrampften Situation bei MS-DOS ist es bei
   Novell DOS (wie schon bei DR DOS) meist möglich, die externen
   Kommandos auch unter anderen DOS-Versionen auszuführen. (Bei MS-DOS
   sind noch nicht einmal die Kommandos von 6.21 unter 6.22
   einsetzbar, von ganz wenigen Ausnahmen, wohl eher Versehen,
   abgesehen.)

   Die Novell DOS Kommandos melden nur dann 'Falsche DOS-Version' oder
   'Falsche Version des Betriebssystems', wenn sie wirklich irgendeine
   interne Funktionalität des Systems benötigen, die eben nicht
   unterstützt wird. Meist erlauben sie einfach nicht den Zugriff auf
   Optionen, die das jeweilige System nicht unterstützt. Diese
   Austauschmöglichkeiten macht sogar vor den Speichermanagern nicht
   halt, die (unter bestimmten Umständen) miteinander vermischt werden
   können. Programme wie TASKMAX bzw. TASKMGR können natürlich nicht
   unter anderen Betriebssystemen arbeiten. Daß Microsoft hier eine völlig
   andere Taktik verfolgt, sieht man allein schon daran, daß man die meisten
   (aber nicht alle) dieser MS-DOS Programme mit SETVER doch zum einwand-
   freien Lauf überreden kann.

   Dadurch ist das Mischen verschiedener DR DOS und Novell DOS
   Versionen (in beiden Richtungen), als auch die Vermischung mit MS-DOS
   und PC-DOS Systemen zu großen Teilen möglich (praktisch in Netzen).
   Da die Novell DOS Kommandos i. allg. mehr Optionen anbieten, stellen sie
   oft einen besseren Ersatz für MS-DOS Systeme dar. Insofern können auch
   MS-DOS Benutzer (aus welchen Gründen auch immer) von einigen der
   Verbesserungen durch Novell profitieren.
   Lediglich bei speziellen Programmen wie Gerätetreibern ist der Betrieb
   unter fremden DOS'en nicht möglich. Dies liegt daran, daß diese Treiber
   von vornherein für Novell DOS 7 optimiert wurden und nur bei 'intimer'
   Ausnutzung der Novell DOS Interna ihre besonderen Fähigkeiten entfalten
   können.

   Besonders interessant ist die Möglichkeit, DPMS unter MS-DOS oder
   PC-DOS zu nutzen und so mit den entsprechenden Fremdprogrammen seine
   DOS-Konfiguration zu optimieren. Mit PC-DOS 7 wird sogar ein eigener
   DPMS-Treiber mitgeliefert, der allerdings durch eine aktuellere
   Version von Novell (aus einem Update) ersetzt werden sollte.

   Einige Hinweise zur Kombination wurden 1995 in c't dargestellt,
   speziell zu IBM PC-DOS 7 und NWDOS 7 sei auf c't 09/1995 S. 210
   verwiesen.

                                                                             
  ---------------------------------------------------------------------------

  II.11. Interne Kommandos und Optionen von COMMAND.COM: [97-04-23]
  =================================================================

   Stichworte: COMMAND.COM, NWDOS7UN.TXT, DIR, %DirCMD%, COPY, EXIT, ., ..,
               CLS, PROMPT, Region-Support

   i. Aufrufoptionen:
   ------------------

   Spätestens mit Update 15 wurden auch die noch fehlenden, zum Teil auch
   bei MS-DOS noch undokumentierten Aufrufoptionen für COMMAND.COM
   implementiert:

   c:\nwdos              Dokumentiert
                         Angabe des Home-Verzeichnisses für Novell DOS
                         Programme. Diese Angabe sollte man nicht
                         vergessen, da sie die grundlegende %Path% Ein-
                         stellung bewirkt, so daß die Novell DOS Programme
                         immer gefunden werden können.

   device                Teilweise dokumentiert.
                         Angabe eines Gerätes für Ein- und Ausgabe (z.B.
                         AUX), wie Kommando CTTY.
                         Manchmal ist es wichtig, sicherzustellen, daß
                         die Boot-Bearbeitung von AUTOEXEC.BAT nicht
                         unterbrochen wird (ist ja in Grenzen auch mit
                         BREAK off möglich). Oder die Bildschirmausgaben
                         von AUTOEXEC.BAT sollen unterdrückt/umgeleitet
                         werden. Man könnte dann hier z.B. NUL angeben,
                         was die Konsole an das Null-Device koppeln würde.
                         Gegen Ende der AUTOEXEC.BAT muß dann aber mit
                         CTTY CON: wieder auf die Standard-Ein-/Ausgabe
                         umgeschaltet werden, sonst läßt sich der Rechner
                         nicht mehr bedienen. Halten Sie eine Boot-Diskette
                         in Reichweite!!!

   /? und /H             Dokumentiert
                         Ausgabe der Hilfeseite (unvollständig)

   /C command            Dokumentiert
   /Ccommand             Startet temporäre Kopie und führt dort das bel.
   /C=command            Kommando command aus (auch Batchjobs), vgl. /K
                         und EXIT weiter unten in diesem Kapitel.
                         Das Leerfeld zwischen der Option /C und dem
                         Kommando ist optional und kann auch durch ein
                         Gleichheitszeichen '=' ersetzt werden. Ein Doppel-
                         punkt ':' ist hingegen leider nicht erlaubt.

   /D                    Undokumentiert bei Novell DOS
                         Unterdrückt die Abarbeitung von AUTOEXEC.BAT und
                         der Frage nach Datum und Uhrzeit (wie bei MS-DOS/
                         PC-DOS 5.0+)

   /E:nnnnn              Dokumentiert
                         Stellt die Größe des Master-Environment ein, d.h.
                         die Umgebung des primären Kommandoprozessors.
                         Der gültige Wertebereich ist 129..32751, wird dies
                         über- oder unterschritten, so wird der Default-Wert
                         256 angenommen (anscheinend ist der effektiv mini-
                         male Wert jedoch 160 und die Angaben werden in
                         Paragraphen aufgerundet). Gibt man /E:value bei
                         sekundären Kopien an, so wird entweder diese
                         Größe bereitgestellt oder die Größe der bereits
                         existierenden Umgebung (je nachdem, welcher Wert
                         größer ist).

                         Wie kommt diese ungerade Zahl 32751 für die maxi-
                         male Umgebungsgröße zustande? Nun, dies ist genau
                         16 Bytes weniger als ein halbes 64 KByte-Segment,
                         und diese 16 Bytes werden für den MCB-Header be-
                         nötigt, mit dem alle allozierten Speicherblöcke
                         beginnen.
                         Übrigens muß hinter der eigentlichen mit SET und
                         %% sichtbaren Umgebung auch noch Platz für mögliche
                         zusätzliche Zeichenketten (wie den Pfadnamen der
                         ausgeführten Programmdatei, zu der diese Umgebung
                         gehört) sein.

                         Diese Größe der Umgebung wird auch bei sekundären
                         Kopien des Kommandoprozessors bereitgestellt
                         (nicht bei DR DOS, von DR DOS 6.0 Updates ab 1992
                         abgesehen).

   /K command            Undokumentiert bei Novell DOS.
   /Kcommand             Ähnlich wie /C, allerdings erscheint danach der
   /K=command            Prompt. Sinnvoll z.B. zur Aufnahme in DOSPRMPT.PIF
                         von MS Windows (analog zu 4DOS' 4START.BAT
                         Dateien). Die gestartete Shell kann mit EXIT
                         verlassen werden.

                         Der Unterschied zu /C besteht insbesondere darin,
                         daß mit /K 'im Prinzip' eine permanente Kopie
                         von COMMAND.COM geladen wird (wie mit /P), aller-
                         dings trotzdem die Möglichkeit zum EXIT besteht,
                         vgl. Beschreibung zu EXIT weiter unten in diesem
                         Kapitel.

                         Möchte man sich mit der CONFIG.SYS SHELL= Direktive
                         die Möglichkeit für EXIT nicht verbauen, kann man
                         statt der üblichen Option /P auf die Option /K aus-
                         weichen (siehe auch bei EXIT etwas weiter unten in
                         diesem Kapitel sowie bei SHELL= in Kapitel III.1.),
                         etwa:

                  SHELL=c:\nwdos\command.com c:\nwdos /E:512 /P:autoexec.bat

                         ersetzen durch:

                  SHELL=c:\nwdos\command.com c:\nwdos /E:512 /K autoexec.bat

                         Jetzt kann man auch die erste (also 'primäre')
                         Kopie von COMMAND.COM beenden! Das darunterliegende
                         IBMBIO.COM weiß sich dann nicht anders zu helfen,
                         als nach Pfad und Namen eines gültigen Kommando-
                         prozessors zu fragen, der dann wieder geladen wird.
                         (Leider ist dabei die Angabe neuer Parametern nicht
                         möglich, so daß die ehemalige SHELL= Zeile erneut
                         ausgeführt wird, i. allg. also wieder AUTOEXEC.BAT
                         geladen wird, obwohl alle bereits geladenen Treiber
                         und TSRs aus CONFIG.SYS und AUTOEXEC.BAT ja bereits
                         komplett zur Verfügung stehen.)
                         Für den einen oder anderen mag es dennoch sinnvoll
                         sein, ohne Booten den Kommandoprozessor zu wechseln
                         (das Überladen kostet ja zusätzlichen Speicher).
                         Interessant ist das bei der Betriebssystem- und
                         Treiberentwicklung, beim Laden unterschiedlicher
                         COMMAND.COM Versionen (i. allg. des gleichen Her-
                         stellers). Wichtig ist ja erst einmal zu wissen,
                         daß es diese Möglichkeit überhaupt gibt.

   /Mx                   als /ML /MU /MH, dokumentiert, (nur Novell DOS und
                         DR DOS)

                         Angabe der Lage von COMMAND.COM im Speicher.
                         Üblicherweise wird /MH zum Laden in die HMA
                         empfohlen.
                         Hieraus ist auch ersichtlich, daß es es hierbei um
                         eine Option von COMMAND.COM, und nicht - wie oft
                         vermutet - von CONFIG.SYS SHELL= handelt und daß
                         man damit keine Fremd-Kommandoprozessoren hoch-
                         laden kann (die diese Möglichkeit aber u.U. auch
                         bieten).

   /MSG                  (Nur MS-DOS und PC-DOS, obsolet bei Novell DOS)

   /P[:autoexec.bat]     Dokumentiert
                         Macht zu startende Kopie permanent (EXIT wird de-
                         aktiviert) und bearbeitet normalerweise automatisch
                         die Datei AUTOEXEC.BAT. Erlaubt optional die Angabe
                         einer anderen Datei als AUTOEXEC.BAT. Siehe auch /K
                         bezüglich nicht offensichtlicher Möglichkeiten.

                         Übrigens: Haben Sie sich schon einmal Gedanken
                         darüber gemacht, welche Werte die Batch-Variablen
                         %0 bis %9 innerhalb von AUTOEXEC.BAT während des
                         Bootens haben?
                         Leider ist hier eine schöne Kommunikationsmöglich-
                         keit zwischen CONFIG.SYS und AUTOEXEC.BAT bisher
                         nicht ausgenutzt worden: Bei Novells COMMAND.COM
                         sind %1 bis %9 in diesem Fall immer unbelegt, und
                         %0 enthält mit /P den Wert "autoexec.bat", bzw.
                         mit Angabe eines Dateinamens den Namen dieser Kon-
                         figurationsdatei, allerdings umgewandelt in Groß-
                         schrift. An den Dateiparameter /P:[autoexec.bat]
                         angehängte Paßwörter erfüllen zwar die gewünschte
                         Funktion, erscheinen aber ebenfalls nicht im Para-
                         meter %0.
                         Bei 4DOS waren %1 bis %9 ebenfalls leer, und %0
                         enthielt den Wert der 4START.BAT-Datei.

   /T                    Undokumentiert (ab Novell DOS 7, sowie bei
                         Concurrent DOS), und bedeutet 'TSR' und wird
                         evtl. vom TASKMGR verwendet.

                         Dieser Parameter ist ein gewisses Kuriosum, ist
                         doch auf den ersten Blick kein Unterschied zum
                         normalen Verhalten auszumachen.
                         Bisher wurde nur das Verhalten in Verbindung mit
                         der Option /C untersucht, es könnte also sein,
                         daß dieser Parameter mit anderen Parametern noch
                         weitere Auswirkungen hat. Wichtig: Verwenden Sie
                         /T nur, wenn der gerade aktive Kommandoprozessor
                         COMMAND.COM ist, da der Rechner sonst in einer
                         Endlosschleife hängenbleibt!

                         Bei Verwendung der Option /C wird eine neue
                         Kopie von COMMAND.COM geladen, der dann die
                         Ausführung des Parameters "/C cmd" überlassen,
                         d.h. 'vererbt' wird. Nach der Ausführung wird
                         COMMAND.COM wieder beendet.
                         Gibt man nun zusätzlich die Option /T an (vor der
                         Option /C, die als letzte Option stehen sollte,
                         da sie weitere Parameter erwarten kann), so wird
                         zwar ebenfalls eine neue Kopie von COMMAND.COM
                         geladen, die Bearbeitung der Kommandos jedoch
                         umgedreht: Die neue Kopie übernimmt nun die Ein-
                         gaben vom Prompt entgegen (und arbeitet z.B. den
                         Batchjob weiter ab, der von der darunterliegenden
                         Kopie noch nicht beendet wurde). Die darunter-
                         liegende Kopie bekommt jedoch die Aufgabe, das
                         mit "/C cmd" angegebene Kommando auszuführen, was
                         sich natürlich verzögert, bis die temporäre Kopie
                         wieder beendet wird. Auf diese Weise kann innerhalb
                         von Batchjobs ein regelrechter Kommandostapel
                         aufgebaut werden, der dann *nach* Beendigung des
                         Batchjobs, der die oberste Kopie des Kommando-
                         prozessors beendet, in umgekehrter Reihenfolge
                         abgearbeitet wird!
                         (Mit diesem Wissen kann man auch verstehen, warum
                         die Option /T zum Hängen des Rechners führt, wenn
                         die alte Kopie des Kommandoprozessors nicht
                         COMMAND.COM ist. Offensichtlich geschieht dieser
                         Aufgabenwechsel über eine undokumentierte Schnitt-
                         stelle, die z.B. 4DOS nicht unterstützt, auch nicht
                         mit der 4DOS.INI Direktive FullInt2E=Yes. Mit Hilfe
                         von K3PLUS'/FreeKEYBs Break-To-DOS-Funktion können
                         Sie derart hängende COMMAND.COM Kopien aber ab-
                         brechen, ohne das System neu starten zu müssen.)
                         Verwendet man die Option /T ohne auch die Option
                         "/C cmd" zu benutzen, so wird ebenfalls ein neuer
                         Kommandoprozessor geladen, ganz als hätten Sie die
                         Option nicht angegeben. Allerdings ist die Vorein-
                         stellung des Prompts dann "ECHO off", d.h. es ist
                         kein Prompt zu sehen (kann natürlich durch Eingabe
                         von "ECHO on" geändert werden).
                         Achtung: Bei der Verwendung dieser Option sollten
                         Sie sehr vorsichtig mit den Batch-Parametern %1 %2
                         %3 %4 %5 %6 %7 %8 und %9 sein und diese nur bei
                         der ersten Instanz verwenden. Durch die umgekehrte
                         Reihenfolge bei der Bearbeitung ist es möglich,
                         daß diese Variablen in anderen Instanzen nur
                         undefinierten Datenmüll enthalten. Ein Beispiel:

                         test.bat:

                          @ ECHO off> \dev\nul
                            REM Nur von COMMAND.COM aus starten!!!
                            ECHO Start!
                          @ COMMAND.COM /T /CECHO Marke 1!
                          @ COMMAND.COM /T /CECHO Marke 2!
                          @ COMMAND.COM /T /CECHO Marke 3!
                          @ COMMAND.COM /T /CECHO Marke 4!
                          @ COMMAND.COM /T /CECHO Marke 5!
                            ECHO Ende!

                         Die Ausgabe dieses Batchjobs ist nicht, wie sie
                         vielleicht erwarten würden, chronologisch, sondern:

                          Start!       Hier wird der Batchjob abgearbeitet,
                          Ende!        die weitere Ausführung des Batchjobs
                                       aber an die temporäre Kopie vererbt,
                                       das "/C cmd" jedoch aufbewahrt, um
                                       bei Beendigung der darüberliegenden
                                       Kopie ausgeführt zu werden, also ein
                                       Art Ende-Prozess, den man auch zum
                                       Aufräumen oder Reinitialisieren des
                                       Systems verwenden könnte.
                          Marke 5!     Nach der Bearbeitung des Batchjobs
                          Marke 4!     wird eine nach der anderen Kopie des
                          Marke 3!     Kommandoprozessors wieder verlassen,
                          Marke 2!     die dann jeweils ihren Ende-Prozess
                          Marke 1!     ausführen, und danach die Kontrolle
                                       an den darunterliegenden Kommando-
                                       prozessor zurückgeben.

   /Y                    Undokumentiert bei Novell DOS (neu mit Update 15)
                         (wie bei MS-DOS/PC-DOS 5.0+). Wird von Caldera
                         OpenDOS 7.01 noch nicht unterstützt.

                         Der angegebene Batchjob wird im Einzelschritt-
                         betrieb durchgesteppt (mit jeweiligen Fragen
                         "(J/N) ?"), vgl. <F8>-Einzelschrittbetrieb in
                         Kapitel II.2. Leider wird die YESCHAR= Einstellung
                         nicht übernommen (getestet bis Update 15).

   /N                    Diese undokumentierte Option ist bei Caldera
                         OpenDOS 7.01 Beta 4 (mit der Source-Pre-Release
                         vom 1997-04-21) hinzugekommen und unterdrückt die
                         Einbindung einer Behandlungsroutine für kritische
                         Fehler (INT24h).


   ii. Hinweise für Kommando-Syntax interner Kommandos:
   ----------------------------------------------------

   Wie in CONFIG.SYS, so akzeptiert Novell DOS COMMAND.COM bei (fast) allen
   internen Kommandos (nicht COPY, CD, ...) auch an der Kommandozeile und
   in Batchjobs direkt nach dem Befehl ein optionales Gleichheitszeichen.
   Bei Kommandos, wo dies nicht mehrdeutig wird (wie z.B. bei ECHO) wird
   das Gleichheitszeichen auch akzeptiert, wenn es nicht direkt nach dem
   Befehl folgt, sondern nur das erste sichtbare Zeichen ist.

   Beispiel:

    ...
    ECHO=Dieses Gleichheitszeichen wird nicht mit ausgegeben!!!
    ECHO = Dieses Gleichheitzeichen wird mit ausgegeben!!!
    ECHO==Hier wird das erste Gleichheitszeichen unterdrückt!!!
    REM Bei GOTO muß das Gleichheitszeichen nicht *direkt* folgen:
    GOTO=label1
    ECHO Test1
    :label1
    GOTO = label2
    ECHO Test2
    :label2
    ...

   Achtung:

   4DOS/NDOS weist dieses Gleichheitszeichen als ungültig zurück (MS-DOS
   COMMAND.COM wurde diesbezüglich noch nicht getestet). Weitere Hinweise
   in Kapitel III.1.

   Teilweise ist direkt nach dem internen Kommando auch noch ein Zeichen
   aus ';', '.', '+', '=' erlaubt, aber häufig wird ein solches Zeichen
   auch als ungültig zurückgewiesen oder hat gar eine Spezialbedeutung.
   Von der unachtsamen Verwendung sei abgeraten.

   Außerdem wird von COMMAND.COM vor allen Befehlen eine beliebige Anzahl
   Leerfelder sowie vor allen internen Befehlen ein Zeichen aus '.', ';',
   '+', '=' akzeptiert (4DOS (5.52a) akzeptiert hier nur ';' und '='.)
   Steht eines dieser Sonderzeichen unmittelbar vor dem Kommando, so wird
   es ignoriert, ansonsten versucht COMMAND.COM offenbar, das Zeichen als
   Argument für das *dahinterstehende* Kommando zu verstehen, was normaler-
   weise zurückgewiesen wird. Der Sinn sei dahingestellt, wird aber durch
   ein weiteres Feature, das in Kapitel IV.6. erläutert wird, wenigstens
   etwas erhellt...
   Je nachdem, ob das Kommando (plus optionales Zeichen) zu Beginn der Zeile
   steht oder weiter eingerückt wurde, ändert sich die Behandlung, falls ein
   gleichnamiges Makro mit DOSKEY definiert wurde. Eingerückte Kommandos
   werden i. allg. nicht als Makros, sondern als Originale interpretiert.
   Eine Ausnahme stellt in der derzeitigen DOSKEY-Implementation (Update 15)
   die Ersetzung interner Kommandos direkt am Prompt dar, denn hier werden
   auch bei Einrückung die Makros gewählt. Dem kann man wiederum durch
   Voranstellen eines der obigen Zeichen begegnen (es sei denn, ein
   gleichnamiges Makro existiert inklusive dieses Zeichens)... Näheres
   hierzu in Kapitel II.4.
   Ein einem Kommando vorangestelltes '@'-Zeichen muß immer in der ersten
   Spalte stehenbleiben!

   Wie aufgrund mangelnder Dokumentation nahezu unbekannt, haben auch
   doppelte Anführungszeichen (") eine besondere Bedeutung für COMMAND.COM
   (auch MS-DOS und 4DOS/NDOS). Passagen, die in doppelte Anführungszeichen
   eingeschlossen werden, werden bezüglich der Auswertung von Umleitungen
   ('>', '<' und '|') übergangen (die Ersetzung von Umgebungsvariablen
   findet allerdings statt). Die Anführungszeichen selbst werden nicht
   unterdrückt, so daß die Nutzung recht eingeschränkt ist, da Anführungs-
   zeichen nur bei ECHO, PAUSE etc. oder bei FIND sinnvoll verwendet werden
   können. Die Anführungszeichen haben (zumindest bei COMMAND.COM) keine
   anderweitig klammernde Wirkung, d.h. es ist damit nicht möglich,
   Parameter, die Leerfelder enthalten, zusammenzuziehen. Stattdessen muß
   man sich die Funktion wie ein Toggle vorstellen:

    @ECHO "Hallo! Bitte <ESC> drücken!" >dummy.lst "Ende der Durchsage..."
    TYPE dummy.lst

   DUMMY.LST enthält jetzt (4DOS fügt ein Leerfeld mehr ein):

    "Hallo! Bitte <ESC> drücken!" "Ende der Durchsage..."

   Bei MS-DOS/PC-DOS COMMAND.COM (mit MS-DOS 6.2 und PC-DOS 7 getestet)
   gibt es eine Möglichkeit, mit <Ctrl>+<t> (ASCII-20 "Pi", vgl. auch
   Kapitel lI.4. bei DOSKEY) mehrere Kommandos in einer Zeile anzugeben
   (bei 4DOS funktioniert ^ alias %+), mit Novells COMMAND.COM (getestet
   bis Update 15) funktioniert dies nicht. Definitiv auch unter Novells
   COMMAND.COM und unter 4DOS können Sie aus der Sicht vieler Betrachter
   oder Editore mehrere Kommandos 'in einer Zeile' aber auch mit einem
   einzelnen ASCII-10 (LF ^M) oder ASCII-13 (CR ^J) trennen. Das liegt
   einfach daran, daß diese Zeichen als Pärchen sowieso einen Zeilen-
   umbruch markieren und aufgrund unterschiedlicher Konventionen unter
   DOS und Unix sicherheitshalber alle möglichen Kombinationen dieser
   Zeichen vom Kommandointerpreter als Zeilenumbruch verstanden werden
   (siehe auch Kapitel II.4. bei DOSKEY). Sofern die Umleitung nicht
   stört, kann man auch das Pipe-Symbol für solche Zwecke verwenden, etwa:

    XDIR *.* | IF ERRORLEVEL 1 ECHO Fehler beim Dateizugriff!

   In diesem Fall sollte man aber die Hinweise in Kapitel IV.6. beachten.

   Eine andere Erleichterung ist, daß man nicht jede Option mit einem
   eigenen SwitChar einleiten muß, sondern sie kombinieren kann.

    DIR *.* /S /W           -> DIR /SW

   Wichtig ist, daß ein Hilfeparameter (/H oder /?) generell nur dann
   akzeptiert wird, wenn er als erster Parameter steht. Bei den externen
   Kommandos würde es sonst teilweise Doppeldeutigkeiten geben können.
   Dies gilt übrigens auch bei 4DOS/NDOS und bei Novell DOS für die meisten
   externen Kommandos (XDIR, XCOPY, XDEL, MOVE).

   Novells COMMAND.COM akzeptiert - wie allgemein üblich - eine maximale
   Zeilenlänge von 128 Zeichen (obwohl intern noch etwas längere Zeichen-
   ketten unterstützt werden), dieses Limit gilt auch für interne Kommandos
   und während der Evaluierung von Umgebungsvariablen (4DOS stellt hier
   eine absolute Besonderheit dar, indem es wesentlich längere Zeilen
   akzeptiert). Zum Vergleich: Die Zeilenlänge in CONFIG.SYS kann bei
   Novell DOS 255 Zeichen betragen, bei MS-DOS sind/waren nur 31 - 128
   Zeichen erlaubt.


   iii. Hinweise zu internen Kommandos:
   ------------------------------------

   Eine Übersicht über die dokumentierten und undokumentierten
   Möglichkeiten der COMMAND.COM internen Kommandos von Novell DOS 7
   findet sich in der Extradatei NWDOS7UN.TXT.

   Seit Update 15 unterstützt nun auch Novell DOS 7 in den Ausgaben von
   DIR etc. die Tausenderseparatoren.

   Im folgenden sollen lediglich relativ zusammenhangslos noch einige
   zusätzliche Hinweise zu einzelnen Funktionen verschiedener Kommandos
   gegeben werden, soweit nicht offensichtlich:

   /? /H         Funktioniert nicht nur als Hilfeoption zu anderen Kommandos
                 sondern auch direkt am Prompt (d.h. ohne, daß ein Befehl
                 angegeben werden müßte). Liefert dann eine Übersicht über
                 alle möglichen Befehle, die in COMMAND.COM implementiert
                 sind. (4DOS/NDOS bietet die gleiche Funktion, allerdings
                 mit einem einzelnen Fragezeichen: ?) Kann z.B. in gene-
                 rellen DR DOS/Novell DOS Batchjobs verwendet werden, um
                 herauszufinden, ob ein gewünschter Befehl unterstützt wird:

                  /? | FIND "befehl" > %tmp%\tempfile.$$$
                  REM Nun die erzeugte Datei auf Länge Null überprüfen...

                 Kann nicht als "COMMAND /C /?" angegeben werden, da dies
                 als Hilfe *über* COMMAND.COM und nicht als Wunsch nach der
                 Ausführung des internen Kommandos /? interpretiert würde.
                 Alle bei /? aufgelisteten Kommandos besitzen eigene Hilfe-
                 seiten mit "befehl /?" (bis auf das spätestens mit Update 8
                 hinzugefügte TRUENAME und /? selbst...)

   ?             als Frage, ob der folgende Befehl ausgeführt werden soll,
   ?"fragetext"  darf - im Gegensatz zu CONFIG.SYS - nicht nach dem Befehl,
                 sondern muß vor dem Befehl stehen (Was natürlich nicht aus-
                 schließt, daß ein weiteres Fragezeichen die optionale
                 Meldung abschließen darf). Dies gilt auch für 4DOS/NDOS
                 und MS-DOS COMMAND.COM. In beiden Fällen wird ein
                 optionales Gleichheitszeichen auch nach der Frage
                 akzeptiert (nicht bei 4DOS/NDOS und MS-DOS).
                 Klappt auch als einfaches Fragezeichen in Batchjobs,
                 daraufhin erscheint eine Dummy-Frage "(J/N)?", bei Druck
                 auf <J> aber keine Fehlermeldung. Ist bei Novells
                 COMMAND.COM direkt am Prompt nicht erlaubt.
                 Ein Meldungstext muß in doppelte Anführungszeichen ('"')
                 eingerahmt werden muß. In diesem Fall unterdrückt
                 COMMAND.COM auch die Ausgabe der eigentlichen Aufrufzeile.
                 (In der Sekundärliteratur konnte ich einen Hinweis finden,
                 daß Novell DOS einen Meldungstext auch ohne Anführungs-
                 zeichen akzeptiert, wenn man die Frage mit einem Frage-
                 zeichen abschließt. Mit Update 15/2 konnte ich diese
                 Behauptung nicht bestätigen, weder in CONFIG.SYS noch
                 in Batchjobs.)

                 Kommt sowohl ein '?' als auch ein '@' als Präfix vor, so
                 muß bei Novells COMMAND.COM (getestet bis Update 15) das
                 '?' vor dem '@' stehen, dummerweise ist es bei 4DOS genau
                 umgekehrt. Hier wird es hoffentlich in Zukunft einen Fix
                 in beiden Produkten geben, so daß beide Varianten akzep-
                 tiert werden.

   @             Ein einem Befehl vorangestellter Klammeraffe (oder "at")
                 unterdrückt für diese Zeile das ECHO. Bei 4DOS/NDOS wird
                 außerdem die Belegung der Umgebungsvariable %CmdLine%
                 unterdrückt, was Speicherplatz sparen kann. Wichtig ist,
                 daß das '@' bei Novells COMMAND.COM (getestet mit Update
                 15) immer in der ersten Spalte stehen muß, auch wenn der
                 Rest des Befehls eingerückt ist. Einzige Ausnahme ist ein
                 '?', das noch vor dem '@' stehen muß.
                 Direkt am Prompt ist ein vorangestelltes '@'-Zeichen nicht
                 erlaubt.

   BREAK         Bei jeder Rückkehr zum Prompt (mal von BREAK selbst abge-
                 sehen) und nach dem EXIT Kommando restauriert Novells
                 COMMAND.COM die letzte Einstellung von BREAK. Einstel-
                 lungen, die innerhalb einer Applikation vorgenommen
                 wurden, bleiben also nur für die Laufzeit dieser
                 Applikation erhalten. Da dieses Verhalten bei anderen
                 DOS'en nicht vorkommt, sei hier extra darauf hingewiesen.
                 Bezüglich der CONFIG.SYS Direktive BREAK= siehe auch
                 Kapitel III.1. Zumindest während der Bearbeitung von
                 Batchjobs sollte man nach der Testphase BREAK off setzen,
                 denn die Ausführungsgeschwindigkeit erhöht sich damit
                 dramatisch. Ansonsten ist der Geschwindigkeitsunterschied
                 nur recht gering:

                 Beispiel für den Anfang eines Batchjobs:

                  @ECHO off > \dev\nul
                  ECHO off > \dev\nul
                  IF NOT ""=="%batdbg%" ECHO %batdbg%
                  IF NOT "off"=="%batdbg%" IF NOT "on"=="%batdbg%" GOTO skip
                  BREAK %batdbg% > \dev\nul
                  :skip
                  ...

                 Auch in Warteschleifen beim Semaphoren-Austausch
                 mehrerer Batchjobs unter Multitaskern sollten Sie,
                 um einen Benutzerabbruch zu verhindern, BREAK off
                 setzen.

                 Ohne Angabe von Parametern gibt BREAK, wie auch ECHO und
                 VERIFY den aktuellen Status in einer bestimmten Syntax
                 aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
                 speichern des Status verwenden kann:

                  BREAK = on
                  BREAK = off

                 Dies entspricht nämlich genau der Eingabe, die man machen
                 muß, um diesen Zustand nach einer Veränderung wieder zu
                 restaurieren (das Gleichheitszeichen ist optional).

                  @ECHO> %tmp%\echo_.bat
                  @ECHO off> \dev\nul
                  BREAK> %tmp%\break_.bat
                  VERIFY> %tmp%\verify_.bat
                  REM Nun die geforderten Einstellungen für diesen Batchjob
                  REM ändern, z.B.:
                  BREAK off> \dev\nul
                  VERIFY on> \dev\nul

                  REM Hier die gewünschte Aktion ausführen:
                  ...

                  REM Am Ende des Batchjobs alte Einstellungen restaurieren:
                  @%tmp%\break_.bat > \dev\nul
                  @%tmp%\verify_.bat> \dev\nul
                  DEL %tmp%\break_.bat > \dev\nul
                  DEL %tmp%\verify_.bat > \dev\nul
                  @%tmp%\echo_.bat  > \dev\nul
                  DEL %tmp%\echo_.bat > \dev\nul

                 Eine verwandte Möglichkeit bietet sich durch Speichern
                 des aktuellen Wertes in einer Umgebungsvariablen an, dazu
                 benötigt man allerdings eine Datei, die die Zeichenkette
                 "SET " (ohne die Anführungszeichen und) ohne den ab-
                 schließenden Zeilenvorschub enthält. Damit sind Konstrukte
                 wie

                  Anweisungen:                 Inhalt von settmp.bat:

                  COPY setfile.dat settmp.bat  "SET "
                  BREAK>>settmp.bat            "SET BREAK = on"
                  ...

                 Leider gilt dies nicht für die anderen ON|OFF-Schalter
                 (hier wird in der deutschen Ausgabe "ist" statt "=" und
                 teilweise "eingeschaltet/ausgeschaltet" statt "ON|OFF"
                 gesetzt) und auch nicht für andere Kommandoprozessoren
                 anderer DOS-Hersteller.

   CD/CHDIR      Schlecht dokumentiert ist die folgende Möglichkeit dieses
                 Kommandos:
                 Die Angabe eines Laufwerksbuchstabens gefolgt von einem
                 Doppelpunkt zeigt die aktuelle Pfadeinstellung für dieses
                 Laufwerk an. Wird kein Laufwerk angegeben, so wird das
                 aktuelle Verzeichnis verwendet.

                 Eine interessante Eigenschaft des CD/CHDIR Befehls (nur
                 bei Novell DOS 7 COMMAND.COM) erlaubt die automatische
                 Erkennung (aus Batchjobs heraus), ob der SwitChar verändert
                 wurde:

                 Bei verstelltem SwitChar (anders als '/') wird der erste
                 '\' in der Pfadangabe des CD Befehls durch ein '/' ersetzt.

                  CD | FIND "/" > %tmp%\tempfile.$$$
                  REM Nun die erzeugte Datei auf Länge Null überprüfen.
                  REM Falls sie größer Null ist, dann wurde der SwitChar
                  REM verändert und dürfte in den meisten Fällen gleich
                  REM '-' sein.

                 Näheres hierzu in Kapitel II.1.

                 Eine abschließende Bemerkung zu Verzeichnissen:

                 Bei allen Versionen von DR DOS 3.4-6.0, die keine CDS im
                 Stil von MS-DOS hatten (also bis DR DOS 6.0 Update 11/1992)
                 konnten Pfadangaben beliebig lang sein. Eine Beschränkung
                 auf 67 Zeichen, wie bei MS-DOS/PC-DOS und nun auch bei
                 Novell DOS 7 gab es damals nicht!
                 Dabei wurden die Pfadangaben lediglich vorne am jeweils
                 möglichen Backslash so abgeschnitten, daß Ausgaben auf
                 67 Zeichen formatiert wurden. Leider kamen die wenigsten
                 Applikationen mit dieser sehr viel flexibleren Methode
                 zurecht (es waren dadurch noch allerhand andere Dinge
                 möglich, wie eine History der zuletzt durchlaufenen
                 Verzeichnisse, wurden allerdings meines Wissens nie
                 ausgenutzt). In eigenen Programmen sollten Sie aber nicht
                 davon ausgehen, daß eine Pfadangabe nur 67 Zeichen lang
                 sein kann (d.h. *nicht* die Routinen verwenden, die die
                 meisten Hochsprachen-Compiler mitbringen). Existieren
                 Verzeichnisse mit solchen Überlängen, so können sie unter
                 Novell DOS 7, MS-DOS und PC-DOS nicht darauf zugreifen,
                 und um die Pfade zu kürzen, müssen Sie unter DR DOS booten.

   CD /A         Außerdem bietet CD/CHDIR seit DR DOS 3.41 noch eine Option
                 /A an, die allerdings seit DR DOS 6.0 komplett undokumen-
                 tiert ist. Durch Angabe von /A wird eine Liste der aktuel-
                 len Pfadeinstellungen aller Laufwerke ausgegeben
                 (leider unterstützt selbst 4DOS 5.52a diese Möglichkeit
                 noch nicht).

                 Die Option CD /B, die der Ausgabe ein CHDIR voranstellt
                 und damit für den Betrieb in Batchjobs mit Umleitung
                 prädestiniert ist, sowie die zum SUBST äquivalente
                 Möglichkeit für CD, etwa "CD d:=c:\path" an Stelle von
                 "SUBST d:=c:\path" bietet bisher leider nur Multiuser DOS
                 (getestet CCI Multiuser DOS 7.22 Gold), nicht aber
                 Novell DOS 7 oder Caldera OpenDOS 7.01, was man in Zukunft
                 leicht ändern könnte.

   COPY          Ein Paßwortschutz wird bei COPY (und XCOPY) nicht auf die
                 Zieldatei übertragen (im Gegensatz zu REN). Die neue Datei
                 hat keinen Schutz und das Hidden-Attribut wurde gelöscht.
                 Das externe Kommando MOVE arbeitet demgegenüber anders,
                 siehe Kapitel II.4.
                 Die MS-DOS 6 Variable %CopyCMD% wird nicht unterstützt und
                 es gibt auch keine hundertprozentige Methode, dieses Ver-
                 halten zu simulieren.
                 COPY /C und /Z werden von 4DOS 5.52a noch nicht unterstützt
                 und COPY /S hat bei 4DOS eine völlig andere Bedeutung. /C
                 kann bei 4DOS mit /P, und /S mit /A: nachgebildet werden.
                 Die beiden mit MS-DOS 6.2 eingeführten Parameter /Y und /-Y
                 zur Bestätigung vor dem Überschreiben unterstützt
                 Novell DOS 7 COMMAND.COM (getestet bis Update 15) noch
                 nicht, da es viel früher eingeführt wurde.
                 Novells COPY kopiert keine Dateien mit der Länge Null
                 (wie bei MS-DOS/PC-DOS), DR DOS kopierte jedoch auch diese
                 (ausgenommen DR DOS 6.0 Updates nach 1992).

                 Bei dieser Gelegenheit ein kleines praktisches Beispiel
                 für Novells COPY /Z:

                  IS7BIT.BAT:

                   @ ECHO off > \dev\nul
                     REM Reports "Files are equal" if file is in 7Bit-ASCII
                     REM Runs with Novell DOS 7 COMMAND.COM, only!!!
                     IF NOT EXIST %1 GOTO end
                   @ CALL swc.bat
                   @ c:\nwdos\COMMAND.COM %switch%C COPY %switch%Z ...
                                          ... %1 %tmp%\is7bit.$$$ > \dev\nul
                   @ CALL FC %1 %tmp%\is7bit.$$$
                     DEL %tmp%\is7bit.$$$ > \dev\nul
                     :end

   COPY A:.      Wie allgemein bekannt, kann man '.' und '..' nicht nur für
   COPY A:       den CD/CHDIR Befehl verwenden, sondern auch sonst.
   u.a.
                  .  steht für 'aktuelles Verzeichnis'
                  .. steht für das dem aktuellen Verzeichnis übergeordnete
                     Verzeichnis

                 Dabei kann man häufig eine Dateispezifikation "*.*" auch
                 mit '.' abkürzen, da dies ja ebenfalls 'gesamtes aktuelles
                 Verzeichnis' ausdrückt

                  DIR *.*          bewirken also das Gleiche
                  DIR .            (übrigens auch bei MS-DOS)
                  DIR

                 Das funktioniert z.B. auch beim COPY Befehl COPY A:. , der
                 den Inhalt von A:*.* ins aktuelle Verzeichnis kopiert.
                 COPY A: ist nun bei Novell DOS eine weitere mögliche
                 Abkürzung für die Abkürzung, bezieht sich also ebenfalls
                 auf das jeweils aktuelle Verzeichnis und nicht auch das
                 gesamte Laufwerk.

   COPY ...+...  Interessant und besonders in Batchjobs praktisch ist
                 auch, daß der COPY-Befehl auch mehr als zwei Dateien in
                 eine Zieldatei kopieren kann, selbst wenn einige der
                 aufgezählten Dateien nicht existieren:

                  COPY src1+src2+src3+src4 target

                 kopiert die Dateien src1 bis src4 in target. Sollte z.B.
                 src2 nicht existieren, wird diese Datei dabei einfach
                 übersprungen. Dabei sind auch in dieser Syntax-Variante
                 Wildcards erlaubt, etwa:

                  COPY *.lst+*.prn *.res

                 Im Gegensatz zu MS-DOS COMMAND.COM ist es bei Novell DOS
                 auch möglich, ohne temporäre Zwischendatei mehrere Dateien
                 zu einer Datei zusammenzuführen, die genauso heißt, wie
                 die erste der Quelldateien, etwa:

                  COPY src1+src2 src1

                 Bei MS-DOS geht dabei der Inhalt der Datei src1 verloren!

   COPY file+,,  Diese undokumentierte Syntax-Variante stellt eine
                 Besonderheit von Novells COMMAND.COM dar, die gut mit
                 dem externen TOUCH-Befehl verglichen werden kann:

                  COPY file+,,

                 *simuliert* das Kopieren die Datei file auf sich selbst
                 und aktualisiert damit den Datums- und Zeitstempel auf das
                 aktuelle Datum. Die Datei file wird nicht verändert, egal
                 ob es sich um eine ASCII- oder um eine Binärdatei handelt.
                 Im Gegensatz dazu arbeitet die Variante

                  COPY file+,

                 mit wirklichem Kopieren der Datei auf sich selbst und ist
                 entsprechend langsamer. Daher wird hier nicht nur der
                 Datums- und Zeitstempel aktualisiert, sondern es erfolgt
                 auch die übliche Behandlung von ASCII- oder Binärdateien
                 (die nicht vom Dateinamen abhängt). Einer vornehmlichen
                 ASCII-Datei wird u.U. ein zusätzliches ^Z (CP/M-Dateiende-
                 Zeichen) angehängt, wodurch die Datei ggf. ein Byte länger
                 wird. Binärdateien bleiben bis auf das aktualisierte
                 Datum unverändert.

   CLS           Dieses Kommando löscht normalerweise den Bildschirm durch
                 direkten Aufruf der entsprechenden Funktion. Ist ein ANSI-
                 Treiber installiert, wird jedoch stattdessen die ANSI-
                 ED-Sequenz "Esc [2J" ausgegeben, die den Bildschirm
                 löscht. Mit der undokumentierten Umgebungsvariable %$Cls%
                 kann man die Sequenz übersteuern, die an die Konsole CON:
                 geschickt wird. Ist diese Variable nicht belegt, tritt
                 das oben beschriebene Verhalten in Kraft.
                 Sinnvollerweise wird diese Variable bei Bedarf mit der
                 Steuersequenz zum Löschen des Bildschirms belegt, wie
                 von den gängigen Terminaltreibern angeboten. Für die
                 Benutzung von ANSI kann man die passende Sequenz im DOSBOOK
                 bei der Beschreibung der ANSI-Sequenzen finden (ANSI kommt
                 aber i. allg. auch ohne diese Speziallösung aus).
                 Sinnvoll wird diese Möglichkeit dann, wenn man mit speziel-
                 len Bildschirmtreibern oder völlig abweichender Grafik-
                 Hardware arbeitet oder Terminalsessions fährt. Außerdem
                 ist es auf diese Weise auch möglich, den Bildschirm einer
                 "remote console" zu löschen, etwa wenn mittels CTTY die
                 Konsole an eine serielle Schnittstelle gekoppelt wurde.
                 Dies eröffnet wiederum neue Möglichkeiten für TASKMGR...
                 Auch Farbeinstellungen sind auf diese Weise möglich.

                 Da die Eingabe von beliebigen Zeichencodes nicht in
                 jedem Editor möglich ist und es zu Problemen bei der
                 Bearbeitung von Batchjobs kommen könnte, ist optional
                 die folgende Syntax erlaubt, die die Angabe eines
                 dreistelligen Oktalwertes für den Zeichencode erlaubt:
                 Da etwa die ASCII-CRT-Terminals die übliche Escape-
                 Sequenz nicht verstehen, kann man stattdessen auch

                  SET $Cls=\033+

                 für "Esc +" eingeben (die von dem bei Novell DOS mitge-
                 lieferten ANSI.SYS-Treiber nicht verstanden wird). Die
                 Folge \033 erzeugt das Zeichen 33o=1Bh=27d.

                 Eine andere Anwendung besteht darin, neben der Funktion
                 zum Löschen des Bildschirms auch andere Einstellungen oder
                 Bildschirmanzeigen über CLS auszulösen oder durch Belegen
                 von %$Cls% mit einer Dummysequenz die Funktion von CLS
                 sogar zu unterbinden. 4DOS 5.52a und MS-DOS COMMAND.COM
                 kennen die Sonderbehandlung der Variablen %$Cls% nicht.

                 Ist diese Variable nicht belegt (was i. allg. der Fall
                 ist) oder kein ANSI-Treiber installiert, wird der Bild-
                 schirm - wie bei MS-DOS - auf dem üblichen direkten Weg
                 (über BIOS-Funktionen) gelöscht, oder - falls ein ANSI-
                 Treiber vorhanden ist - durch Ausgabe der ANSI ED-Sequenz
                 "Esc [2J". Weitere Infos bei TYPE und in Kapitel IV.7.

   CTTY          Eine selten bekannte Möglichkeit dieses Kommandos ist es,
                 eine dauerhafte 'Umleitung' der Ein-/Ausgabe für Batchjobs
                 zu programmieren. Achtung: Halten Sie eine Boot-Diskette
                 bereit, da Sie bei falscher Verwendung die Eingabe von der
                 Tastatur abkoppeln! Siehe auch weiter vorne in diesem
                 Kapitel.

   DATE          In Verbindung mit Umleitungen siehe auch Kapitel IV.6.,
                 sowie Kapitel IV.1.

                 Die zusätzlichen Optionen von CCI Multiuser DOS 7.22 Gold
                 /B (für Betrieb in Batchjobs) und /E (zum Setzen der Um-
                 gebungsvariablen %DATE%, %DOW%, %DOM% und %DOY%) bieten
                 Novell DOS 7 und Caldera OpenDOS 7.01 COMMAND.COM noch
                 nicht, dies ließe sich aber leicht implementieren.

   DEL *.*       In Verbindung mit Umleitungen siehe auch Kapitel IV.6.
                 DEL *.* unterscheidet sich insofern von anderen DEL Auf-
                 rufen, als daß der Kommandoprozessor bei dieser speziellen
                 Maske nachfragt "Sind Sie sicher (J/N)". Ansonsten wird,
                 ohne Angabe spezieller Optionen ohne Rückfrage gelöscht.

   DEL, ERASE,   DEL und die älteren CP/M-Kommandos ERASE und ERA sind
   ERA           identisch. (Die Kurzform ERA, die seit CP/M existiert,
                 wird selbst von 4DOS 5.52a noch nicht unterstützt. Statt
                 der Option /C, die übrigens (wie DELQ und ERAQ) vor *jeder*
                 zu löschenden Datei nachfragt, müssen Sie unter 4DOS die
                 gleichwertige Option /P verwenden, die glücklicherweise
                 auch unter Novells COMMAND.COM funktioniert.)

   DELQ, ERAQ    DELQ und ERAQ sind identisch (ERAQ existiert seit CP/M).
                 (Da selbst 4DOS 5.52a diese Kommandos nicht nachbildet,
                 müssen Sie ggf. auf dessen Option DEL /P ausweichen.)

   DIR           Paßwortgeschützte Dateien werden trotz i. allg. gesetztem
                 Hidden-Attribut angezeigt (wie auch bei XDIR).

                 (4DOS und MS-DOS 6.20+ bietet bei DIR dermaßen viele Er-
                 weiterungen, daß alle Erweiterungen von Novell DOS/DR DOS
                 gegenüber dem alten Standard von MS-DOS hier mit den Er-
                 weiterungen von 4DOS/MS-DOS kollidieren. Die einzigen
                 Optionen von Novells DIR, die Sie ohne 'Übersetzung' auch
                 bei 4DOS verwenden können, sind die alten Parameter /2 und
                 /W. Alle Möglichkeiten lassen sich unter 4DOS aber mehr als
                 gut nachbilden.)

   DIR /C        Zum Speichern der (anderen) angegebenen Parameter als
   DIR /R        zukünftige Default-Einstellung. Damit kann man MS-DOS'
                 Verhalten mit der Umgebungsvariable %DirCMD% in etwa
                 nachbilden. Nach einem Booten ist die neue Default-
                 Einstellung wieder gelöscht, d.h. es empfiehlt sich die
                 Aufnahme einer entsprechenden Zeile in AUTOEXEC.BAT.

                 Aus diesem Grund gibt es auch zwei verschiedene Optionen:

                 Mit /C wird die aktuell angegebene Einstellung nur für
                 die weitere Verwendung abgespeichert, ohne das Kommando
                 auch auszuführen (praktisch für AUTOEXEC.BAT und andere
                 Batchjobs), mit /R wird zusätzlich das Kommando auch
                 direkt ausgeführt (praktisch für die Kommandozeile).

                 Beide Varianten existieren übrigens schon seit DR DOS
                 3.41+, waren allerdings bis vor DR DOS 6.0+ undokumentiert.

   DIR *.        Zeigt (zumeist) die Unterverzeichnisse des aktuellen
                 Verzeichnisses an.
                 Voraussetzung dafür ist allerdings, daß alle Unterver-
                 zeichnisnamen keine Erweiterung haben (was durchaus erlaubt
                 ist und in letzter Zeit immer häufiger z.B. für Versions-
                 nummern von Software-Paketen etc. verwendet wird) und daß
                 umgekehrt alle 'normalen' Dateien eine Erweiterung haben
                 (das muß auch nicht so sein).
                 Andere Möglichkeiten, Unterverzeichnisse abzutesten, werden
                 in Kapitel IV.6. und IV.3 vorgestellt.

   ECHO [on|off] Die üblichen Funktionen von ECHO als Kommando (nicht
                 CONFIG.SYS) dürften hinreichend bekannt sein und machen
                 normalerweise nur in Batchjobs Sinn. Beachten Sie, daß
                 unter Verwendung von doppelten Anführungszeichen auch die
                 Zeichen '>', '<' und '|' ausgegeben werden können.

                 Bei DR DOS 3.41+ und Novell DOS 7 COMMAND.COM kann man
                 jedoch durch Eingabe von "ECHO on" oder "ECHO off" am
                 DOS-Prompt die Ausgabe des DOS-Prompts ein- oder aus-
                 schalten. Mit "ECHO off" erscheint einfach kein Prompt
                 mehr, unabhängig von "PROMPT $-". Natürlich lassen sich
                 Eingabe wie bisher vornehmen. COMMAND.COM von MS-DOS 7
                 reagiert genauso (das Verhalten von früheren MS-DOS
                 Versionen wurde noch nicht untersucht).
                 4DOS reagiert in diesem Fall anders, denn es wird nur die
                 zukünftige Einstellung von ECHO für Batchjobs verändert.

                 Ohne Angabe von Parametern gibt ECHO, wie auch BREAK und
                 VERIFY den aktuellen Status in einer bestimmten Syntax
                 aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
                 speichern des Status verwenden kann.
                 Näheres hierzu bei BREAK.

   EXIT [errorlevel]  Mit EXIT beendet man normalerweise eine temporäre
                 Kopie eines Kommandoprozessors (z.B. COMMAND.COM). Aller-
                 dings ist EXIT auch ein Spezialbefehl innerhalb von Batch-
                 jobs, der die Ausführung des Batchjobs beendet. Normaler-
                 weise erscheint danach wieder der DOS-Prompt für weitere
                 Eingaben. Arbeitet man aber in einer temporären Kopie des
                 Kommandoprozessors (z.B. unter dem TASKMGR bei bestimmten
                 Einstellungen oder in Windows DOS-Boxen (siehe SYSTEM.INI
                 [386Enh] DOSPromptExitInstr=Yes/No)), so wird dabei der
                 gesamte Task geschlossen, sofern der aktuelle Kommando-
                 prozessor der unterste innerhalb des jeweiligen Fensters/
                 Tasks ist. Beim TASKMGR und z.B. mit 4DOS hängt das exakte
                 Verhalten davon ab, ob für die Bearbeitung des Batchjobs
                 eine neue Kopie des Kommandoprozessors gestartet wurde
                 (sog. 'Shellen') oder über eine interne Software-
                 Schnittstelle die alte Kopie mitbenutzt wird. In
                 TASKMGR.INI ist diesbezüglich die Einstellung [Shell]
                 Exec=True/False interessant, in 4DOS.INI sollte man auf
                 die Einstellung von FullInt2E=Yes/No und die 4START.BAT
                 Dateien achten. Leider ist es aus Kompatibilitätsgründen
                 nicht immer möglich, einfach diese Einstellung zu ver-
                 ändern (siehe z.B. Kapitel VII.3.), deshalb sollte man
                 EXIT in Batchjobs nur im Notfall verwenden (Es gibt
                 schließlich auch Ersatz mit "GOTO end" und einer Marke
                 :end am Ende des Batchjobs).
                 Weitere Hinweise zu EXIT siehe etwas weiter oben bei /K
                 und in Kapitel III.1. bei SHELL=.

                 Undokumentiert ist die Möglichkeit, bei EXIT einen
                 Errorlevel im Bereich 0..255 anzugeben, der von dem
                 Programm ausgewertet werden kann, in das nach EXIT
                 zurückgekehrt wird. Dies ist besonders für verschachtelte
                 Batchjobs interessant. Leider funktioniert dies nicht für
                 "COMMAND.COM /C EXIT errorcode" (liefert immer
                 Errorlevel 0, getestet mit Update 15), sondern nur für
                 Batchjobs wie "COMMAND /C batchjob.bat" (in diesem
                 Fall wird der letzte Errorlevel des Batchjobs zurück-
                 geliefert, der entweder aus dem Programmlauf oder
                 durch explizites Beenden via EXIT resultiert) oder
                 "COMMAND.COM /K batchjob.bat" (der Batchjob muß in
                 diesem Fall mit EXIT beendet werden). Gibt man direkt
                 am Prompt EXIT mit einem Errorlevel an, so wird dieser
                 Wert ebenfalls an die darunterliegende Kopie des
                 Kommandoprozessors zurückgeliefert (diese Möglichkeiten
                 sind wahrscheinlich auch schon in DR DOS 6.0 Updates ab
                 1992 vorhanden, definitiv aber auch in CCI Multiuser DOS
                 7.22). Achtung: Werden neben dem Errorlevel noch andere
                 Parameter angegeben, so muß der Zahlenwert als letzter
                 Parameter stehen. Es dürfen auch nicht mehr als eine
                 Zahl als Parameter angegeben werden.
                 Die unter CCI Multiuser DOS 7.22 verfügbare EXIT-Option
                 /T zum Löschen aller nach der Shell geladenen Programme
                 bietet Novells COMMAND.COM nicht, zurückgewiesen wird sie
                 aber auch nicht.

                 Auf diesem Weg gibt es also eine Möglichkeit, auch ohne
                 bestimmte Zusatzprogramme den Errorlevel auf einen be-
                 stimmten Wert zu setzen (leider etwas komplizierter, als
                 wenn EXIT auch direkt bei "COMMAND.COM /C EXIT code"
                 funktionieren würde):

                  SETERROR.BAT:

                   @ECHO off
                   REM Dieser Batchjob funktioniert nur wie gewünscht,
                   REM wenn Novells COMMAND.COM verwendet wird...
                   REM Allerdings kann der Batchjob sehr wohl auch von
                   REM 4DOS/NDOS aus gestartet werden, wenn Novells
                   REM COMMAND.COM im Zugriff liegt...
                   IF "%1"=="_SETERRLVL_" GOTO errlvl
                   ...
                   REM Nun soll ein bestimmter Errorlevel (hier 13) gesetzt
                   REM werden...
                   COMMAND.COM /C %0 _SETERRLVL_ 13
                   REM Nun gilt Errorlevel 13...
                   IF ERRORLEVEL 13 IF NOT ERRORLEVEL 14 ECHO Ok!
                   GOTO end
                   :errlvl
                   EXIT %2
                   :end

                 Eine spezielle Anwendung dafür besteht in der Möglichkeit,
                 während der Abarbeitung der CONFIG.SYS Datei Batchjobs als
                 Makros oder Unterroutinen für Problemlösungen zu benutzen,
                 die innerhalb der CONFIG.SYS-Sprache nicht lösbar wären!
                 Dazu lädt man

                  CONFIG.SYS:

                   ...
                   INSTALL=c:\nwdos\command.com /C batchjob.bat
                   REM Errorlevel-Auswertung, hier als Demo:
                   ONERROR = 0 ECHO Kein Fehler!
                   ONERROR = 1 ECHO Bedingung 1 ist eingetreten...
                   ONERROR = 2 ECHO Bedingung 2 ist eingetreten...
                   ...

                 wobei batchjob.bat beliebige Befehlsfolgen ausführen kann
                 und am Ende mit "EXIT errorlevel" einen Code an CONFIG.SYS
                 zurückliefert, der dort die weitere Bearbeitung beeinflus-
                 sen kann (siehe Kapitel III.1. und III.5.)! Leider ist der
                 Aufruf von COMMAND.COM nicht ganz rückwirkungsfrei, z.B.
                 wird damit die CONFIG.SYS Vorab-Umgebung vor der weiteren
                 Verwendung geschlossen.

   FOR %%x IN (list) DO cmd params

                 Entgegen der Beschreibung im DOSBOOK sind in der Liste list
                 nicht nur Dateispezifikationen erlaubt, sondern beliebige
                 Texte, die der Reihe nach für die Schleifenvariable einge-
                 setzt werden. Achtung: Die Zeichen '?' und '*' nehmen die
                 übliche Sonderstellung für Datei-Wildcards ein, d.h. werden
                 auf alle in Frage kommenden Dateien expandiert und der
                 Reihe nach für %%x eingesetzt (aus *.* wird also ein Aufruf
                 des Anwendungsblocks mit *jeder* einzelnen Datei, die auf
                 die Maske *.* paßt, und nicht *ein* Aufruf mit '*.*'). Alle
                 anderen Zeichenketten werden nicht besonders ausgewertet
                 und werden ohne Überprüfung, ob es sich um einen gültigen
                 Dateinamen handelt, in die Schleifenvariable eingesetzt).
                 Eine praktische Beispielanwendung für die Verwendung von
                 FOR abseits seiner üblichen Funktion zur Dateiexpandierung-
                 und -auflistung findet sich in MEM.BAT in Kapitel IV.5.
                 In der Dokumentation zu CCI Multiuser DOS 7.22 Gold heißt
                 es, daß in der Liste keine Dateien mit Pfadangaben erlaubt
                 sind, zumindest auf Novell DOS 7 COMMAND.COM kann man diese
                 Aussage nicht übertragen.

                 Manchmal kann man FOR auch verwenden, um mehrere Kommandos
                 in einer Zeile unterzubringen, was die Bearbeitung eines
                 Batchjobs beschleunigt:

                  FOR %%x (DIR TYPE) DO %%x test.txt

                 Übrigens: Die Verwendung des FOR-Befehls ist auch direkt
                 an der Kommandozeile erlaubt, wenn man die verdoppelten
                 %% Zeichen durch einfache % ersetzt. Umgebungsvariablen
                 werden bei COMMAND.COM nicht ersetzt, 4DOS/NDOS erlaubt
                 auch dies (siehe auch BATTIPS.TXT).

   GOSUB label [comments]
                 Erlaubt maximal vier Verschachtelungsstufen (getestet
                 mit DR DOS 6.0, Novell DOS 7 und CCI Multiuser DOS 7.22
                 Gold).

   GOTO label [comments]
                 Interessant ist, daß hinter der Angabe des Sprungziels
                 label noch weitere 'Parameter' erlaubt sind, die allerdings
                 ignoriert werden. Wird GOTO direkt am Prompt von Novells
                 COMMAND.COM angegeben, so wird das Kommando ignoriert
                 (wie auch bei GOSUB, RETURN, SWITCH).

   HILOAD | LH | LOADHIGH
                 [/L:region[,minsize[;region2[,minsize[;...]]]]][/S]
                 cmd params

                 Aus Kompatibilitätsgründen unterstützten diese Kommandos
                 bei Novell DOS schon immer undokumentiert die MS-DOS
                 MEMMAKER Optionen /L: und /S, allerdings waren diese
                 funktionslos, da Novell DOS 7 keinen Region-Support besaß.
                 Mit Update 14 (sicher jedoch Update 15) hat sich dies ge-
                 ändert: Novell DOS 7 unterstützt jetzt in vollem Umfang
                 UMB-Memory-Regions. Eine genaue Beschreibung dieser Para-
                 meter findet sich bei DEVICEHIGH= in Kapitel III.4. (und
                 Kapitel III.1., V.7.).
                 Zu beachten ist lediglich, daß bei HILOAD/LH/LOADHIGH,
                 die im übrigen untereinander identisch sind, kein Gleich-
                 heitszeichen vor dem eigentlichen Kommando gegeben werden
                 darf.

                  Ein Beispiel:

                  LH /l:2 DOSKEY /insert

                 Achtung: 4DOS 5.5c bis 5.52a gehen offenbar davon aus, daß
                 Novell DOS 7 keinen Region-Support bietet, insofern wird
                 eine Fehlermeldung ausgegeben: "No UMB-regions defined.
                 Switches ignored."
                 Dies wird wohl in einem zukünftigen Update gefixt. Auf die
                 gleichwertigen Parameter während der CONFIG.SYS-Bearbeitung
                 hat dieses Problem natürlich keinen Einfluß. Für das Laden
                 in UMBs (nur hierfür, da sonst die temporäre Kopie von
                 COMMAND den Speicher fragmentieren würde) bietet sich - in
                 obigem Beispiel - folgendes Workaround an:

                  COMMAND /c LH /l:2 DOSKEY /insert

                 Noch ein Hinweis: Jedes Programm, das installiert wird,
                 bekommt vom System eine Umgebung zugewiesen. Die meisten
                 residenten Programme benötigen diese Umgebung jedoch
                 nach der Installation überhaupt nicht mehr. Daher geben
                 umsichtig programmierte TSRs den Umgebungsblock auch
                 wieder frei (viele TSRs machen aber noch nicht einmal das).
                 Das Ganze hat trotzdem den Nachteil, daß der Speicher durch
                 kleine ungenutzte Speicherbereiche fragmentiert wird.

                 Daher sollte man beim Laden aller TSR-Programme, die nicht
                 in der Lage sind, Programmcode in ihren Umgebungsbereich
                 zu relozieren (das können leider nur sehr wenige) die
                 folgenden Tricks zur Optimierung des Speicherverbrauchs
                 beherzigen (dies ist natürlich nicht nur an LH etc. ge-
                 bunden):

                   Die Umgebung möglichst klein halten, solange
                    residente Programme geladen werden. D.h. die SET
                    Anweisungen möglichst erst am Schluß der AUTOEXEC.BAT
                    einsetzen (ist leider nicht für alle Umgebungsvariablen
                    praktikabel). 4DOS/NDOS bieten mit dem SETLOCAL und
                    UNSET * Kommando eine Möglichkeit, die Umgebung temporär
                    zu löschen (siehe 4DOSTIP.TXT). Für CONFIG.SYS gibt es
                    mit SETENV.COM eine äquivalente Möglichkeit, siehe
                    INSTALL= etc. in Kapitel III.1 und im Archiv SETENV.ZIP.
                    In seltenen Einzelfällen mag auch das Gegenteil sinnvoll
                    sein: Eine sehr groß 'aufgeblasene' Dummy-Umgebung,
                    die vom TSR wieder freigegeben wird, erzeugt auch ein
                    'großes Loch' im Speicher, in das u.U. wieder ein neues
                    TSR hineinpaßt. Diese Optimierung erfordert allerdings
                    großen Aufwand (und einige Berechnungen anhand der MEM-
                    Ausgaben) und lohnt sich nur, wenn ein TSR ganz knapp
                    nicht mehr hochgeladen werden kann, und mehrere kleine
                    freie Bereiche ehemaliger Umgebungen anderer TSRs
                    existieren, die mindestens diese Größe aufwiegen.

                   Die Aufrufpfade von TSR-Programmen sollten möglichst
                    kurz sein, da an die übergebene Umgebung ab DOS 3.1+
                    auch der Aufrufpfad des Programms angehängt wird. Da
                    diese Funktion innerhalb des Kernels ausgeführt wird,
                    kann man von außen wenig ausrichten (man müßte schon die
                    Exec-Funktion INT21h/4B00h ersetzen oder ändern). Die
                    temporäre Aktivierung von SUBST-Laufwerken (um den
                    Aufrufpfad zu verkürzen) ist eine mögliche Lösung,
                    dabei kann man bei Novell DOS 7 (mit LASTDRIVE=32,
                    siehe Kapitel III.1. und III.2) auch die Laufwerke [:
                    bis `: verwenden, um die Belegung der anderen Laufwerke
                    nicht zu stören.

                     Beispiel für "c:\dir1\dir2\dir3\dir4\dir5\tsr.com":

                      SUBST z: c:\dir1\dir2\dir3\dir4\dir5
                      LH z:tsr.com ...
                      SUBST z: /D

                    In diesem Beispiel würde der Aufruf 26 Bytes (für
                    "\dir1\dir2\dir3\dir4\dir5\" gegenüber dem direkten
                    Aufruf einsparen. Übrigens: Die auf den ersten Blick
                    offensichtliche Alternative, einfach nur den Pfad des
                    aktuellen Laufwerks auf das Verzeichnis, in dem das
                    TSR liegt, zu wechseln und es dann als "c:tsr.com"
                    aufzurufen, nützt leider nichts, da der Pfad intern
                    normalisiert wird und wieder die volle Länge bekommt.
                    Das Weglassen der Dateiendung bringt keine zusätzliche
                    Ersparnis, denn diese wird immer angehängt.

                    Dieser Trick läßt sich natürlich auch auf CONFIG.SYS
                    und INSTALLHIGH= etc. anwenden:

                     Beispiel für "c:\dir1\dir2\dir3\dir4\dir5\tsr.com":

                      INSTALL=c:\nwdos\subst.exe b: ...
                                             ... c:\dir1\dir2\dir3\dir4\dir5
                      INSTALLHIGH=b:tsr.com ...
                      INSTALL=c:\nwdos\subst.exe b: /D

                    In diesem Fall kann man natürlich nicht auf Laufwerke
                    ausweichen, die mit LASTDRIVE= definiert werden.
                    SUBST arbeitet jedoch auch mit bereits belegten Lauf-
                    werken, so daß sich hier Laufwerk B: anbietet (da Lauf-
                    werk A: und C: sowie andere Laufwerke oberhalb von C:
                    in der Boot-Phase zum Laden von Programmen referenziert
                    werden könnten).

   IF            Dieser Befehl ist inklusive vieler seiner Erweiterungen
                 im DOSBOOK beschrieben. Hinzuzufügen ist, daß man die
                 Konstruktionen mit AND durch IF und die Konstruktionen
                 mit OR durch eine andere Logik im Batchjob ersetzen
                 sollte, damit Batchjobs auch unter MS-DOS und 4DOS/NDOS
                 laufen (Genausowenig sollte man 4DOS .AND. und .OR.
                 anwenden, die ansonsten mit AND, OR identisch ist).

                 Neben den im DOSBOOK beschriebenen Vergleichsoperationen
                 "=", "==" (für 'gleich'), "<>" und "!=" (für 'ungleich')
                 kann man allerdings auch noch die nur in der COMMAND.COM
                 internen Hilfe (IF /?) aufgelisteten Vergleichsoperationen
                 ">" ('größer'), "<" ('kleiner'), ">=" ('größer-gleich')
                 und "<=" ('kleiner-gleich') verwenden! Um möglichst hohe
                 Kompatibilität zu anderen Kommandoprozessoren herzustellen,
                 sollte man jedoch stattdessen in der Praxis die Ungleich-
                 heit durch ein vorangestelltes NOT ausdrücken und entweder
                 auf alle Vergleichsoperationen, die '>' oder '<' enthalten,
                 verzichten oder wenigstens vorher sicherstellen, daß
                 diese nur unter Novell DOS 7 COMMAND.COM ausgeführt
                 werden. Andere Kommandozeileninterpreter werten diese
                 Zeichen als Umleitung und dies kann zu schweren Fehlern
                 bis hin zum Datenverlust durch überschriebene Dateien
                 führen. Eine partielle Abhilfe (bei veränderter Funktion)
                 ist aber evtl. durch geschickte Verwendung von doppelten
                 Anführungszeichen möglich (nicht ausprobiert).

                 Die gleichwertigen Vergleichsoperationen EQ, NE, LT, GT,
                 LE und GE, die CCI Multiuser DOS und 4DOS/NDOS bieten,
                 unterstützt Novell DOS 7 nicht. Ebenfalls fehlen die von
                 CCI Multiuser DOS bekannten Erweiterungen wie

                  IF KEY ["message"] == char

                 oder gar die Kurzschreibweise für IF ERRORLEVEL mittels
                 ON in der Form "ON [ERRORLEVEL] code [GOTO] label".
                 Multiuser DOS bietet hier noch einige weitere Ergänzungen,
                 die hier nicht näher aufgelistet werden.

                 Die Syntax zum Vergleich zweier Zahlenwerten beginnt
                 auf beiden Seiten des Vergleichs mit einem Doppelkreuz
                 '#'. Interessant daran ist, daß die hier behandelten
                 Werte offenbar immer erst auf ganze Zahlen gerundet
                 werden, d.h. #7,1 oder #7.1 wird wie #7 behandelt.
                 Nachkommastellen fallen einfach unter den Tisch.

                 Die obigen Vergleichsoperationen (auch die Relationen)
                 können nicht nur auf derartige Werte, sondern auch auf
                 Zeichenketten angewendet werden! In diesem Fall werden
                 die beiden Zeichenketten entsprechend der landes-
                 spezifischen Sortierreihenfolge miteinander verglichen.

                 Ein paar Beispiele:                 Ausgabe:

                  IF #7   >= #7.1 ECHO Achtung!!!    Achtung!!!
                  IF #7,1 = #7.1  ECHO Richtig!!!    Richtig!!!
                  IF "A"  >= "B"  ECHO Falsch!!!     --
                  IF "BA" >= "BB" ECHO Falsch!!!     --
                  IF "A"  >= "AB" ECHO Falsch!!!     --

                 Achtung: Normalerweise ist die Auswertung der Argumente
                 case-sensitiv, d.h. Groß- und Kleinschreibung werden
                 unterschieden. Dies ist wichtig zu wissen, da der IF-
                 Befehl gerade oft zur Auswertung von Umgebungsvariablen
                 herangezogen wird (hierzu siehe SET= in Kapitel III.1.).
                 Bei CCI Multiuser DOS gibt es ein internes Kommando
                 namens CASE [<ON>|OFF], mit dem man wählen kann, ob die
                 Auswertung keine Fallunterscheidung machen soll.

                 Zu IF ERRORLEVEL ist anzumerken, daß durch die Abfrage des
                 Errorlevels der Errorlevel *nicht* auf Null zurückgesetzt
                 wird, wie dies häufig vermutet wird. Diese Annahme liegt
                 deshalb nahe, weil die betriebssysteminterne Variable des
                 Exitcodes INT21h/4Dh (und damit auch dessen Realisierung
                 in Programmiersprachen) sehr wohl mit der Abfrage zurück-
                 gesetzt wird. COMMAND.COM (als auch 4DOS) speichern diesen
                 Wert jedoch vorher in eine eigene Variable um, daher ist
                 IF ERRORLEVEL nicht betroffen.

                 Bei Novells (und DR DOS 6.0) COMMAND.COM kann - wie nur
                 teilweise dokumentiert - eine beliebige Anzahl von Gleich-
                 heitszeichen auch bei

                  IF ERRORLEVEL [=|==] errlvl
                  IF EXIST [=|==] filespec
                  IF DIREXIST [=|==] dirspec

                 verwendet werden. Zumindest unter einigen MS-DOS/PC-DOS
                 und DR DOS COMMAND.COM Versionen ist dies ebenfalls möglich
                 (DIREXIST nur bei Novell DOS und DR DOS 6.0). "IF EXIST"
                 arbeitet bei Novell DOS (wie auch MS-DOS/PC-DOS) auch mit
                 versteckten Dateien, hingegen wurden bei DR DOS (ausge-
                 nommen die DR DOS 6.0 Updates ab 1992) versteckte Dateien
                 ignoriert. Trotzdem wird auch bei "IF ERRORLEVEL ==" auf
                 ">=" ('größer-gleich') getestet! Dieser Unterschied in der
                 Semantik ist meistens nicht tragisch, sollte aber trotzdem
                 bei der Programmierung von Batchjobs berücksichtigt werden
                 (denn 4DOS/NDOS unterscheidet hier sehr wohl...).
                 IF ERRORLEVEL 0 ist eine immer erfüllte Bedingung.

                 Novells COMMAND.COM akzeptiert auch negative Zahlen-
                 angaben, dabei entspricht

                  -1=255, -2=254, -3=253 ... -255=1.

                 Und Errorlevel-Angaben oberhalb 255 werden modulo 256 auf
                 den Bereich von 0..255 zurückgefaltet, so daß die Angabe
                 999 als 231 interpretiert wird.

                 Und wie bekommt man die Errorlevel heraus?

                   Siehe BATTIPS.TXT und ERRORLVL.BAT

                   Das Programm unter Kontrolle von DEBUG aufrufen:

                     DEBUG program parameter

                    und dann am Prompt das Kommando -G absetzen, damit
                    DEBUG das Programm wie normal abarbeitet. Bei der
                    Beendigung wird der Errorlevel angezeigt. Bezüglich
                    DEBUG siehe auch Kapitel II.5.

                 Übrigens: Novells COMMAND.COM erlaubt, wie 4DOS/NDOS, die
                 Verwendung des IF Befehls auch direkt am Prompt. Normaler-
                 weise ist dieser Befehl nur in Batchjobs verfügbar und wird
                 z.B. am Prompt von MS-DOS als ungültig zurückgewiesen.

   MD/MKDIR      Nicht offensichtlich sind zwei Eigenschaften dieses
                 Befehls:

                 - Der Befehl kann nur ein Verzeichnis auf einmal er-
                   zeugen, d.h. wenn man einen längeren Pfad zu einem zu
                   erstellenden Verzeichnis angibt, muß der gesamte Ast
                   bis dahin bereits existieren. (Dies ließe sich bei
                   OpenDOS noch verbessern.)

                 - Da der Befehl - im Gegensatz zu 4DOS/NDOS - bei
                   COMMAND.COM nur einen Parameter erwartet, eröffnet
                   sich die Möglichkeit, auch mehrere angegebene Parameter
                   als einen Parameter zu interpretieren und auf diese
                   Weise sogar Verzeichnisse erzeugen zu können, die
                   Leerfelder enthalten. Unter MS-DOS können solche
                   Verzeichnisse auf legale Weise nicht erstellt werden,
                   deshalb sollten Sie auch hier auf diese Möglichkeit
                   verzichten. Beispiel:

                    MD c:\a b c

                   erzeugt ein Verzeichnis namens "c:\a b c", d.h. mit
                   zwei Leerfeldern! Derartige Verzeichnisse lassen sich
                   zwar mit RD/RMDIR wieder löschen und sind im Prinzip
                   ganz normal ansprechbar, das Problem ist nur, das die
                   anderen Kommandos Leerfelder als Trenner zwischen
                   Parametern auffassen und Sie große Schwierigkeiten
                   bekommen werden, von außen auf dieses Verzeichnis oder
                   seinen Inhalt zuzugreifen (was man natürlich in Einzel-
                   fällen als Feature auffassen könnte). Mit dem Norton
                   Commander (NC) können Sie dieses Problem jedoch über-
                   brücken und danach innerhalb des Verzeichnisses mit
                   relativen Pfadangaben ganz normal operieren.

   PATH          Die Verwendung des Befehls PATH dürfte bekannt sein (siehe
                 DOSBOOK). Benötigen Sie längere %Path%-Angaben, als über
                 die Kommandozeile möglich sind, können Sie die Umgebungs-
                 variable %Path% auch (direkt) an PATH vorbei mit einer
                 Suchliste belegen. Dazu müssen Sie lediglich ein kleines
                 Programm schreiben, das den Eintrag des *Master*-Environ-
                 ment verändert. Aber Vorsicht: Es gibt (glücklicherweise
                 nur wenige) Programme, die mit PATH-Angaben über 128
                 Zeichen nicht zurechtkommen (etwa Windows 3.0 oder
                 Checkit). Ab einer gewissen Länge sollten Sie aus
                 Performance-Gründen die Suche über %Path% um Substitut-
                 Laufwerke und Programmaufrufe über Batchjobs in einem
                 Batch-Verzeichnis (C:\BAT etc.) erweitern (welches
                 natürlich in %Path% vorkommt, am besten sogar noch vor
                 dem DOS-Verzeichnis).
                 Mit Paßwörtern geschützte Verzeichnisse können nicht in der
                 Pfadauflistung vorkommen, da die Angabe eines Paßwortes
                 mit Semikolon bei PATH anders interpretiert würde.

   PROMPT        Der Befehl PROMPT, der auch über die Variable %Prompt%
                 eingestellt werden kann, ist bei Novell DOS teilweise
                 undokumentiert erweitert. Hier folgt die fehlende Be-
                 schreibung:

                 $x  Wenig bekannt ist, daß durch die Angabe von $x im
                     Prompt vor jeder Rückkehr von *externen* Kommandos
                     und Programmen zum Prompt ein Kommando abgearbeitet
                     wird, daß in der Variable %PExec% definiert ist (in
                     der Online-Hilfe wird fälschlicherweise %Exec% ange-
                     geben und es wird behauptet, daß der Befehl jedesmal
                     vor der Anzeige des Prompts ausgeführt wird, z.B.
                     DISKMAP wie in Kapitel II.4. beschrieben).
                     Für dieses Kommando kann natürlich auch ein Batchjob
                     verwendet werden. (Leider bietet selbst 4DOS 5.52a
                     diese Möglichkeit noch nicht; ein partielles Work-
                     around ist mit der %@Exec[]% Funktion von 4DOS möglich.
                     $x und $X haben dort eine andere Funktion.)

                 $-  Teilweise undokumentiert sind die beiden Token $- und
                     $_: Gibt man nur PROMPT (ohne Parameter) an, so er-
                     scheint der Default-Prompt wie mit $n$g, d.h. es ist
                     nicht möglich, den Prompt ganz verschwinden zu lassen.
                     Gibt man nun als ersten und einzigen Parameter PROMPT
                     $- an, so wird der Prompt ganz abgeschaltet (siehe
                     auch bei ECHO in diesem Kapitel).
                     Ist $- einer von mehreren Parametern, so wird er
                     ignoriert, d.h. durch eine leere Zeichenkette ersetzt.
                     (Mit 4DOS 5.52a wurde diese Möglichkeit offenbar ein-
                     gebaut, wenn sie auch noch nicht dokumentiert ist.)

                 $_  Die Angabe von $_ bewirkt hingegen, daß in eine neue
                     Zeile gesprungen wird (CR/LF). Dies ist besonders hilf-
                     reich, wenn es als erster Token für PROMPT angegeben
                     wird, hat allerdings auch den Nachteil, daß die oberste
                     Zeile von Bildschirmausgaben, die genau auf eine Seite
                     formatiert sind, weggescrollt wird.

                 $u  Ausschließlich in der Hilfe von SETUP ist der Parameter
                     $u dokumentiert, der den Benutzeranmeldenamen ausgibt.
                     Wie dies dann allerdings vonstatten gehen soll, findet
                     der geneigte Leser nirgendwo - außer hier:
                     Der Inhalt der reservierten und undokumentierten Umge-
                     bungsvariable %LoginName% wird online an Stelle des
                     $u eingebaut, d.h. wenn sich dieser Wert während einer
                     Session ändert, paßt sich auch der PROMPT bei der
                     nächsten Zeile sofort daran an. Da man diese Möglich-
                     keit nicht hat, wenn man Umgebungsvariablen bei der
                     Definition des PROMPT-Befehls benutzt (der PROMPT
                     bleibt dann fix auf die zu diesem Zeitpunkt gültigen
                     Werte eingestellt), bietet sich hier - auch für ganz
                     andere Zwecke - eine interessante Option. (4DOS erlaubt
                     ganz regulär, Umgebungsvariablen im Prompt zu ver-
                     wenden, aber unter Novells COMMAND geht es über die
                     Definition von %LoginName% nun auch.)
                     %LoginName% darf keinesfalls mit der verwandten Pseudo-
                     Umgebungsvariable %Login_Name% verwechselt werden!
                     Wenn man sich ins Netz einloggt, wird %Login_Name%
                     im Rahmen der Möglichkeiten darauf eingestellt,
                     %LoginName% bleibt jedoch davon völlig unbeeinflußt.
                     (4DOS 5.52a bietet diese spezielle Möglichkeit noch
                     nicht.) Siehe auch Kapitel IV.7.

                 $g  Wie in Kapitel II.1. ausführlich erläutert, ändert
                     PROMPT den ersten '\' in der Verzeichnisausgabe in
                     ein '/', wenn der SwitChar nicht auf '/' eingestellt
                     ist. Siehe auch bei CD/CHDIR.

                 $h  (Unter 4DOS (getestet mit 5.52a) gibt es eine Ein-
                     schränkung, die bei Novells COMMAND.COM nicht zum
                     Tragen kommt, da Variablen während des PROMPTs sowieso
                     nicht ergänzt werden. Bei 4DOS kann $h nur bis zur
                     nächstrückwärtigen Grenze einer expandierten Variable
                     oder Funktion rückwärts gehen.)

                 $m  (Multiuser DOS verwendet dies in Verbindung mit der
                     Variable %MAIL% für die Anzeige von Post.)

   REM           Der REM-Befehl funktioniert, wie auch der Doppelpunkt,
   :             direkt am Prompt und wird einfach ignoriert. (Das Semi-
                 kolon hat in diesem Zusammenhang eine *andere* Funktion
                 und ist hier kein Alias für REM. Siehe oben.)
                 Enthält eine Pseudo-Kommentarzeile mit Doppelpunkt eine
                 Umleitung, so wird diese ignoriert, d.h. es gibt nicht
                 die üblicherweise damit auftretenden Probleme (auch nicht
                 unter MS-DOS), für solche Zwecke hat sich ein verdoppeltes
                 :: eingebürgert, ist aber nicht vorgeschrieben.
                 Achtung: Da der Kommandoprozessor überlange Zeilen mit
                 mehr als 123 Zeichen abschneidet und den Rest als neue
                 Zeile betrachtet, müssen Sie bei überlangen Kommentaren
                 entweder ein weiteres REM oder einen Doppelpunkt einfügen
                 oder von vornherein den Kommentartext auf mehrere Zeilen
                 aufteilen. Dieses Verhalten ist ein dokumentiertes Ver-
                 halten von CCI Multiuser DOS 7, also kein Fehler. Angeblich
                 muß ein Doppelpunkt, der eine Marke einleitet, immer in
                 der ersten Spalte stehen (laut CCI Multiuser DOS Dokumenta-
                 tion), die Praxis zeigt aber, daß dies nicht zwingend
                 notwendig ist.
                 Übrigens gibt es einen weiteren Unterschied zwischen REM
                 und dem Doppelpunkt. Da der Doppelpunkt eigentlich für
                 Marken gedacht ist, werden solche Zeilen auch mit "ECHO on"
                 oder im Einzelschrittbetrieb nicht ausgegeben, REM-Zeilen
                 jedoch sehr wohl.
                 (MS-DOS 2.xx und 3.xx erlaubten (angeblich) die Verwendung
                 eines Punktes als Alias für REM, dies funktioniert unter
                 Novells COMMAND.COM und unter 4DOS/NDOS jedenfalls nicht.)

                 Es gibt noch eine Besonderheit zu beachten: Aus Kompatibi-
                 lität zu MS-DOS wertet auch Novells COMMAND.COM Umleitungen
                 (mit '>', '>>', '<' oder '|') auch in REM-Zeilen aus, etwa:

                  REM | DIR *.*

                 wird also nicht etwa ignoriert, sondern führt DIR *.*
                 aus (siehe auch Kapitel IV.6.), was mit 4DOS/NDOS nicht
                 funktioniert.

   RD/RMDIR      Nicht offensichtlich sind zwei Eigenschaften dieses
                 Befehls:

                 - Der Befehl kann nur ein Verzeichnis auf einmal löschen,
                   d.h. wenn man einen längeren Pfad zu einem leeren
                   Verzeichnis angibt, so wird nur der letzte Ast des
                   Baums gekappt und nicht der gesammte angegebene Pfad,
                   selbst wenn dieser leer sein sollte und keine weiteren
                   Verzeichnisse einhält. Dieses Verhalten ist auch
                   wünschenswert, da die gewünschte Aktion sonst nicht
                   eindeutig anhand des Parameters festgelegt werden
                   könnte.

                 - Da der Befehl - im Gegensatz zu 4DOS/NDOS - bei
                   COMMAND.COM nur einen Parameter erwartet, eröffnet
                   sich die Möglichkeit, mehrere angegebene Parameter
                   als einen Parameter zu interpretieren und auf diese
                   Weise auch Verzeichnisse löschen zu können, die
                   Leerfelder enthalten. Unter MS-DOS können solche
                   Verzeichnisse auf legale Weise gar nicht erst erstellt
                   werden, unter DR DOS und Novell DOS ist dies jedoch
                   mit dem Befehl MD/MKDIR durchaus erlaubt, wenn auch
                   undokumentiert:

                    RD c:\a b c

                   würde z.B. das Verzeichnis namens "c:\a b c" löschen,
                   das oben (bei MD/MKDIR) erstellt wurde.

   REN/RENAME    Der Rename-Befehl kann auch über die Verzeichnisgrenzen
                 hinweg ausgeführt werden, solange es sich bei Quelle und
                 Ziel physikalisch um dasselbe Laufwerk handelt (d.h. auch
                 Substitut-Laufwerke etc. werden korrekt berücksichtigt).
                 In diesem Fall muß nur eine Änderung der Verzeichnis-
                 struktur bewerkstelligt werden, die Datei selbst bleibt
                 aber an der gleichen physikalischen Stelle auf der Fest-
                 platte. Dadurch ist dieses Kommando sehr schnell.

                 Ein gesetzter Paßwortschutz wird wie die Attribute auf die
                 neue Datei übertragen (auch bei 4DOS).

                 Im Vergleich dazu wirkt der externe MOVE Befehl anders,
                 siehe Kapitel II.4.

                 REN/RENAME bietet noch eine undokumentierte Option /C
                 'Confirm', die von CCI Multiuser DOS her bekannt ist.
                 Gibt man sie an (im Zweifelsfall nach den beiden Datei-
                 spezifikationen), so fragt der Befehl vor dem Ausführen
                 jeweils nach, ob dies auch wirklich gewünscht ist.

   SWITCH        Leider ist COMMAND.COMs SWITCH nicht genauso erweitert,
                 wie die Realisierung in CONFIG.SYS. Es gibt keine Zeit-
                 schranke, dementsprechend auch keinen Default-Wert, und
                 es werden wirklich nur maximal 9 Sprungziele akzeptiert.

                 Achtung: Mit 4DOS 5.95/6.00 wurde ein neues Kommando
                 namens SWITCH eingeführt, das leider nicht das geringste
                 mit dem seit DR DOS bekannten SWITCH Befehl zu tun hat!

   TIME          In Verbindung mit Umleitungen siehe auch Kapitel IV.6. und
                 Kapitel IV.1.
                 Die zusätzlichen Optionen von CCI Multiuser DOS 7.22 Gold
                 /B (für Betrieb in Batchjobs), /E (zum Setzen der Umge-
                 bungsvariablen %TIME% und %ELAPSED%) und /G (für sekünd-
                 liche Piepser in Verbindung mit /C) bieten Novell DOS 7
                 und Caldera OpenDOS 7.01 COMMAND.COM noch nicht, dies
                 ließe sich aber leicht implementieren.

   TRUENAME      Undokumentiert (das Kommando fehlte in den ursprünglichen
                 Ausgaben von DR DOS 6.0 und Novell DOS 7; wurde aber sowohl
                 bei DR DOS, als auch spätestens mit Novell DOS Update 8
                 nachträglich eingebaut). Entspricht direkt dem Ergebnis der
                 zugehörigen API-Funktion, die auch schon in frühen Ausgaben
                 von Novell DOS 7 implementiert war, die den TRUENAME-Befehl
                 selbst noch nicht kannten.
                 Gibt den komplett expandierten, physikalischen Pfad zu
                 einer Datei an, um damit Doppeldeutigkeiten aufzulösen
                 (etwa bei SUBST, JOIN, ASSIGN, MAP). Dateimasken werden auf
                 "?"-Masken expandiert.
                 Siehe auch MSDOSTIP.TXT. Das TRUENAME-Verhalten hat sich
                 im Laufe der Zeit (im Zuge von Updates) leicht verändert,
                 siehe HISTORY.TXT.
                 Netzlaufwerke werden normalerweise in UNC-Notation (siehe
                 Kapitel VI.10.) ausgegeben und CD-ROM-Laufwerke entweder
                 als "\\X.\A.\filename" (wobei der zugeordnete Laufwerks-
                 buchstabe hier durch X und die Nummer des CD-ROM-Laufwerks
                 mit A dargestellt wird, bei MSCDEX und neueren Versionen
                 von NWCDEX) oder "Cdex. X:\filename" bei älteren Ausgabe
                 von NWCDEX. Lädt man MSCDEX mit der Option /S, so ändert
                 sich zwar in der CDS (Current Directory Structure) nichts
                 an diesem Eintrag, bei TRUENAME wird aber jetzt eine
                 normale Pfadangabe zurückgeliefert "X:\filename".

   TYPE          Bei vielen Kommandoprozessoren erlaubt der TYPE-Befehl
                 nicht die Angabe von Wildcards, stattdessen muß man auf
                 COPY ausweichen, z.B.:

                  COPY *.bat CON
                  COPY *.txt CON | MORE

                 Entgegen der Dokumentation und manchen Fremdpublikationen
                 akzeptiert COMMAND.COM von DR DOS 6.0 und Novell DOS 7
                 auch bei TYPE Wildcards:

                  TYPE *.bat
                  TYPE *.txt /P

                 Gibt man Wildcards an, so wird vor der Ausgabe jeder
                 Datei der entsprechende Dateiname ausgegeben. In diesem
                 Zusammenhang gibt es eine interessante Besonderheit:

                 Unter Singleuser-Varianten ist standardmäßig zunächst
                 nichts besonderes zu erkennen, unter Multiuser-Varianten
                 werden die angegebenen Dateinamen jedoch invertiert an-
                 gezeigt. Und zwar existieren unter Multiuser DOS zwei
                 Variablen namens %$On% (RevOn) und %$Off% (RevOff), die
                 üblicherweise mit den Werten "Esc p" und "Esc q" belegt
                 sind. (Diese beiden Sequenzen werden von dem stark
                 erweiterten ANSI-Treiber ausgewertet, der unter
                 Multiuser DOS ein fester Bestandteil des Systems ist.
                 Der bei Novell DOS mitgelieferte ANSI.SYS-Treiber versteht
                 diese Sequenzen nicht!) Der Wert von %$On% wird unmittelbar
                 vor jedem Dateinamen auf der Konsole ausgegeben, der Wert
                 von %$Off% unmittelbar danach. Auf diese Weise ist eine
                 Steuerung der Farbe und der Attribute möglich.

                 Hat man jedoch in der Singleuser-Variante ebenfalls einen
                 ANSI-Treiber geladen, so kann man diese beiden Variablen
                 manuell mit passenden Steuersequenzen belegen (%$On% und
                 %$Off% existieren seit DR DOS 3.41 COMMAND.COM). Da die
                 Eingabe von beliebigen Zeichencodes nicht in jedem Editor
                 möglich ist und es zu Problemen bei der Bearbeitung von
                 Batchjobs kommen könnte, die Codes außerhalb des
                 Repertoires für normale Wörter enthalten, gibt es eine
                 optionale Syntax, die die Angabe eines dreistelligen
                 Oktalwertes für den Zeichencode erlaubt:

                  SET $On=\033[1m
                  SET $Off=\033[0m
                  TYPE *.*

                 Dieses Beispiel sorgt dafür, daß die Dateinamen hervor-
                 gehoben dargestellt werden. Natürlich können Sie diese
                 Variable auch verwenden, um einen Banner auszugeben oder
                 einen Seitenvorschub auszulösen... Dies funktioniert
                 auch dann noch, wenn Sie die Ausgabe des TYPE-Befehls
                 in eine Datei oder auf ein Gerät umleiten! Siehe auch
                 bei CLS und in Kapitel IV.7.

   VER           Der Befehl VER von Novell DOS 7 (und DR DOS) gibt die
                 Novell DOS/DR DOS Versionsnummer aus. Dabei hängt das
                 Ergebnis vom Inhalt der Umgebungsvariable %Ver% ab.
                 Dieser Wert wird bei Start von COMMAND.COM auf "7" (bei
                 Novell DOS) gesetzt (7.01 bei Caldera OpenDOS 7.01 trotz
                 %Ver%=7; das .01 wird festverdrahtet angehängt). Ändert
                 man diesen Wert, so wird eine entsprechend andere Angabe
                 angezeigt. Ist %Ver% nicht definiert (wie z.B., wenn man
                 COMMAND.COM durch 4DOS.COM ersetzt - also nicht nur
                 überlädt), so gibt VER (von COMMAND.COM) gar nur
                 "Novell DOS" aus. Weitere Hinweise zur Belegung der
                 Variable %Ver% unter den einzelnen Versionen finden sich
                 in Kapitel IV.7.
                 Die Pseudo-Umgebungsvariable %OS_Version% übernimmt
                 übrigens ebenfalls den Wert von %Ver% (falls definiert),
                 wenn auch nicht umgekehrt, siehe Kapitel IV.7.

   VERIFY        Ohne Angabe von Parametern gibt VERIFY, wie auch BREAK
                 und ECHO den aktuellen Status in einer bestimmten Syntax
                 aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
                 speichern des Status verwenden kann.
                 Näheres hierzu bei BREAK.

                                                                             
  ---------------------------------------------------------------------------

  II.12. Hinweise zu Editieren am COMMAND.COM Prompt: [97-02-21]
  ==============================================================

   Stichworte: COMMAND.COM, HISTORY=, PROMPT, überlange Eingabezeile

   Besonders mit längeren Anzeigen des Prompts (über PROMPT), etwa bei
   tief verschachtelten Unterverzeichnissen kommt es öfters vor, daß man
   die Zeilenlänge von z.B. 80 Zeichen überschreitet und die Eingabe in der
   nächsten Zeile fortsetzen muß. Dies ist im Prinzip kein Problem, aller-
   dings kann man den Cursor unter COMMAND.COM selbst in Verbindung mit
   HISTORY= nur soweit wieder zurück bewegen, bis man den Anfang der
   aktuellen Zeile erreicht. Damit ist es nicht möglich, Tippfehler in
   dem Teil der Eingabe zu korrigieren, die noch in der vorherigen Zeile
   stehen. Abhilfe schafft die Betätigung von <Up> gefolgt von <Down>:
   Danach steht die komplette aktuelle Eingabezeile (sofern nicht länger
   als 80 Zeichen) in der aktuellen Zeile und kann wieder komplett editiert
   werden.

   Falls Sie die CONFIG.SYS Direktive HISTORY=ON gesetzt haben, wirkt
   sowohl am COMMAND.COM Prompt, als auch im Eingabe-Interface von
   kommandozeilenorientierten Applikationen (z.B. DEBUG) eine HISTORY-
   Funktion.
   Diese normalerweise recht praktische Funktion kann allerdings manchmal
   auch störend sein, wenn man die automatische Suchfunktion aktiviert hat
   (ebenfalls über HISTORY=... oder mittels <Ctrl>+<_> bei Novell DOS bzw.
   <F8> bei DR DOS): Da diese Funktion, falls aktiviert, auch innerhalb
   von Eingabeleitungen funktioniert, führt dies oft zur Verfälschung
   des Eingabestroms aus der Umleitung. Begrenzt kann man dem entgegen-
   wirken, indem man an das Ende jeder Zeile eine große Anzahl Leerfelder
   (oder anderer syntaktisch korrekter Zeilen ohne Funktion) setzt (sofern
   der Editor das erlaubt), aber es ist besser, die Suchfunktion vor
   Eingabeumleitungen abzuschalten (bei DEBUG innerhalb des -E Kommandos
   ein zusätzliches Komma am Schluß, z.B. "-Exxxx:yyyy,zz,").

   Weitere Hinweise zur Editierung auch bei HISTORY= (Kapitel III.1.)
   und DOSKEY (Kapitel II.4.).

   Unter 4DOS/NDOS ergibt sich dieses Problem erst gar nicht, da man
   problemlos die gesamte Zeile editieren kann.

   Weitere Hinweise zur Kommandozeilen-Syntax siehe Kapitel II.11.

                                                                             
  ---------------------------------------------------------------------------

  II.13. Patchen der US-Version auf deutsche Ja/Nein-Abfragen: [96-05-30]
  =======================================================================

   Stichworte: IBMBIO.COM, IBMDOS.COM, YESCHAR=, J/N, Y/N, O/N, S/N, DEBUG

   Häufig stellt sich das Problem, daß nach einem US-Update die deutsche
   Grundversion nach Y/N statt nach J/N fragt. Innerhalb von CONFIG.SYS
   kann man dem mit der undokumentierten Direktive YESCHAR= abhelfen, deren
   Einstellung aber leider nicht in das System übernommen wird (könnte sich
   in Zukunft evtl. ändern).

   Stattdessen gibt es die Möglichkeit, die Kerneldateien direkt umzu-
   patchen, dazu ist eigentlich nur eine Änderung nötig, aber in dem
   folgenden Beispiel werden direkt Nägel mit Köpfen gemacht und zwei (von
   drei) Vorkommnisse von 'Yy' zu 'Jj' umgepatcht. Dieser Patch sollte mit
   jedem US-Update für Novell DOS 7 funktionieren.

   Leider werten die Novell DOS eigenen Kommandos (etwa DEL *.*, DEL /C,
   ERASE /C, ERA/C, DELQ, ERAQ, COPY /C, <Del> im TASKMGR und viele andere
   ) die zugehörige DOS-Funktion überhaupt nicht aus, so daß hier weiterhin
   Y/N erscheint...
   Könnte sich ebenfalls in Zukunft ändern (bezüglich externer Kommandos
   sei auch Kapitel II.16. verwiesen).
   Falls nicht, müßten COMMAND.COM und die betreffenden externen Programme
   auch gepatcht werden (wozu sie meistens mit "PKLITE filespec -x" ent-
   packt werden müssen, dann mit DEBUG an den passenden Stellen geändert
   und danach mit "PKLITE filespec" wieder gepackt werden müßten).
   Im folgenden wird der Patchvorgang nur für IBMBIO.COM und IBMDOS.COM
   geschildert:

   Achtung: Diesen Patch nicht auf die Originale, sondern auf Kopien
            anwenden. Vorher müssen die Dateiattribute HRS gelöscht werden.

    >DEBUG                   Eingaben (außer '-' Prompt-Eingaben)
    -Nibmbio.com             <RET>
    -L                       <RET>
    -Scs:100 cx+100 59 79    <RET>
    ????:<xxxx>
    -E<xxxx>                 <RET> (xxxx übernehmen)
    ????:<xxxx>   59.        4A <SPACE>
    ????:<xxxx>+1 79.        6A <RET>
    -W
    -Nibmbio.com             <RET>
    -L
    -Scs:100 cx+100 59 79    <RET>
    ????:<yyyy>
    ????:<zzzz>
    ; Achtung! Das erste Vorkommnis in dieser Datei nicht verwenden. Führt
    ; aus ungeklärten Ursachen zu Problemen beim Booten.
    -E<zzzz>                 <RET>
    ????:<zzzz>   59.        4A <SPACE> (zzzz übernehmen)
    ????:<zzzz>+1 79.        6A <RET>
    -W
    -Q


   Nun können - nach einer Überprüfung und mit einer Boot-Diskette in
   Reichweite - die Originaldateien überschrieben werden und die Attribute
   HRS wieder gesetzt werden. YESCHAR= ist nun auch nicht mehr notwendig.

                                                                             
  ---------------------------------------------------------------------------

  II.14. Hinweise zu VERIFY: [96-04-01]
  =====================================

   Stichworte: VERIFY, NWCACHE

   Es gibt verschiedentlich Hinweise, daß die Einstellung VERIFY ON|OFF
   bei MS-DOS für den DOS-Kernel selbst keinen Einfluß hat, sondern optional
   nur durch externe Gerätetreiber verwendet wird. Da die Daten zumindest
   auf Festplatten sowieso durch Prüfsummen gesichert werden, wird häufig
   empfohlen, VERIFY OFF zu setzen (Ich arbeite persönlich allerdings lieber
   mit VERIFY ON).
   Bei MS-DOS sind (ohne Platten-Cache) mit VERIFY ON|OFF gewisse Unter-
   schiede in der Performance festzustellen, die bei Novell DOS nicht so
   stark ausfallen, aber dort generell eher langsam sind (also wie mit
   VERIFY ON). Über den im Vergleich zu MS-DOS relativ zögerlichen Fest-
   platten- und Floppy-Zugriff unter DR DOS und Novell DOS hat es schon
   viel Murren und eine Reihe Spekulationen gegeben. Häufig wird ins Feld
   geführt, daß DR DOS/Novell DOS offensichtlich auch bei VERIFY OFF
   gewisse Überprüfungen vornimmt, die zusätzliche Zeit beanspruchen.
   Ich kann in dieser Diskussion bezüglich VERIFY weder in der einen noch
   in der anderen Richtung etwas beisteuern (über die Interna müßte sich
   mal ein Novellaner äußern...), sicher ist jedoch, daß NWCACHE offenbar
   mit VERIFY ON nicht in der Lage ist, Schreibzugriffe zu cachen, auch
   wenn diese Option enabled ist (jedenfalls gibt die Statistikübersicht
   immer 0% gesparte Zugriffe aus - siehe Kapitel II.3. und II.4.). Daher
   empfiehlt Novell VERIFY OFF bei Verwendung von NWCACHE oder NetWare-
   Anbindung.

   Ich empfehle das konservative VERIFY ON (Sicherheit über Geschwindigkeit)
   zu setzen, solange nicht spezielle Gründe dagegen sprechen, wie etwa der
   Zugriff auf manche Netze oder extrem langsame Geräte wie Tape-Streamer.
   NWCACHE ist durchaus in der Lage, auch mit VERIFY ON zu cachen, aller-
   dings bei stark reduzierter Performance. VERIFY OFF kann dazu führen, daß
   Diskettenwechsel nicht richtig erkannt werden, solange man das Laufwerk
   nicht explizit neu betritt (was sich in seltenen Fällen z.B. im NC
   unschön bemerkbar machen kann, in jüngsten Updates ist dieses Verhalten
   aber offenbar verbessert worden).

   Hinweise zu anderen performance-fressenden Einstellungen wie Doppel-
   pufferung und Disk-Deblocking siehe Kapitel II.17.

                                                                             
  ---------------------------------------------------------------------------

  II.15. Unter Novell DOS 7 lauffähige MS-DOS 6.22 Kommandos:
  ===========================================================

   Stichworte: MS-DOS 6.22, Kompatibilität, Versionsabhängigkeiten

   Die folgenden externen Kommandos von MS-DOS 6.22 laufen auch
   unter Novell DOS 7. Leider sind das nur relativ wenige, was an der
   übertrieben pingeligen Versionsabfrage in MS-DOS Kommandos liegt.
   Die meisten Kommandos sind unter Novell DOS 7 sowieso unnütz, da
   die eigenen namensgleichen oder -verwandten Kommandos meist mehr
   Möglichkeiten bieten und - wie meine Erfahrung immer wieder zeigt -
   umsichtiger programmiert wurden.

   ADOS (AddOn), CHOICE, COMP, EDIT (QBASIC), DEFRAG (Zukauf),
   DELTREE, DOSSHELL, EXPAND (allg.), FAKEMOUS (AddOn), FASTHELP (unnütz),
   GRAFTABL, LABEL, LOADFIX (besser MEMMAX -L), MIRROR (Zukauf: Central
   Point PC-Tools), MOVE, MSAV (Zukauf), MSCDEX (allg.), MSD (allg.),
   MSHERC (allg.), POWER (allg.), PRINTFIX, QBASIC (EDIT), SCANDISK
   (Zukauf), SETNAME (Netz), SETVER (wohl sinnvoll), SMARTDRV (allg.),
   UNDELETE (Zukauf: Central Point PC-Tools), UNFORMAT (Zukauf), VSAFE
   (Zukauf), evtl. noch ein paar mehr.

                                                                             
  ---------------------------------------------------------------------------

  II.16. Landessprachliche Unterstützung: [97-03-25]
  ==================================================

   Stichworte: COUNTRY=, DISPLAY.SYS, MODE, KEYB, Codeseiten, Landescodes,
               Keyboardcodes, Keyboard-IDs, .CPI-Dateien, FONT, DRFONT

   i. Einrichtung von Codeseiten:
   ------------------------------

     Im folgenden Beispiel wird neben der immer verfügbaren Hardware-
     Codeseite (entspricht i. allg. zumindest bezüglich der Zeichenzuordnung
     für jedes Gerät der Codeseite 437) eine Software-Codeseite (hier 850)
     eingerichtet.
     Auch wenn in der Dokumentation immer nur von zwei Codeseiten pro Land
     die Rede ist (dies bezieht sich auf die Angaben in COUNTRY.SYS),
     können jeweils bis zu 12 Codeseiten (bei MS-DOS nur 6) vorbereitet
     werden. Bezüglich der Details bei der Einrichtung von DISPLAY.SYS und
     PRINTER.SYS sei auf Kapitel II.4. verwiesen. Noch einmal: Die Angaben
     der Codeseiten bei den CONFIG.SYS-Treiber DISPLAY.SYS und PRINTER.SYS
     beziehen sich auf die jeweilige Hardware-Codeseiten (wie üblicherweise
     auch bei COUNTRY=, siehe Kapitel III.1.).
     Erst die Codeseiten-Angaben bei MODE PREPARE (in AUTOEXEC.BAT) gelten
     für die vorzubereitenden Codeseiten, d.h. die Codeseiten, mit denen man
     über die Hardware-Codeseiten hinaus arbeiten möchte.
     Das Vorbereiten *einer* Codeseite erlaubt bereits das Arbeiten mit
     *zwei* Codeseiten:
     Mit der Hardware-Codeseite und mit der vorbereiteten Codeseite,
     zwischen denen man mit CHCP oder MODE SELECT wechseln kann (deshalb
     ist auch die korrekte Angabe der Hardware-Codeseite so wichtig).
     Analoges gilt für mehr als eine vorbereitete Codeseite.
     Natürlich ist es möglich, auch die Codeseite, die bereits von der
     Hardware-Codeseite benutzt wird, mit einer erst vorzubereitenden
     Codeseite zu überladen. In diesem Fall stammen die Informationen zum
     Umschalten auf diese Codeseite (Fonts, Escape-Sequenzen) nicht mehr
     aus dem Grafikkarten-BIOS (Hardware) oder - bei Druckern - aus dem
     Treiber PRINTER.SYS, sondern aus der mit MODE zugeordneten .CPI-Datei.
     Dies ist besonders dann wichtig zu wissen, wenn Sie eine spezielle
     .CPI-Datei besitzen, die z.B. einen artfremden Drucker ansteuern oder
     in allen Codeseiten eine andere Bildschirm-Schriftart erzeugen soll.
     In diesem Fall dürfen Sie nicht vergessen, auch die Codeseite 437
     mittels MODE CODEPAGE PREPARE vorzubereiten und bei DISPLAY.SYS und
     PRINTER.SYS eine Codeseite mehr zu reservieren. Näheres zu diesem
     Themenkomplex findet sich in Kapitel II.4. bei DISPLAY.SYS und
     PRINTER.SYS.

     Für Details bei der Einrichtung von mehr als einer zusätzlichen
     Codeseite oder der Auswahl der Anzahl der unterstützten Fonts sei
     auf das Handbuch und das DOSBOOK verwiesen!

     Hier soll nur einmal anschaulich dargestellt werden, was man in der
     üblichen Praxis alles für Codeseitenunterstützung benötigt (häufig
     drücken sich die Dokumentatoren gerade um dieses aberwitzig kompli-
     zierte Thema ;-) ):

      CONFIG.SYS:

       ...
       YESCHAR=J
       REM -----------------------------------------------------------------
       REM Hier Codeseite 437 angeben, auch wenn Sie später mit einer
       REM anderen Codeseite arbeiten wollen, siehe Kapitel III.1. ...
       COUNTRY=49,437,c:\nwdos\country.sys
       REM -----------------------------------------------------------------
       REM Für EGA-/MCGA-/VGA-Systeme: Wenn Sie ein Zweimonitorsystem be-
       REM sitzen (also zusätzlich noch MDA oder HGC), dürfen Sie hier keine
       REM Codeseite angeben! Dann wird implizit die Hardware-Codeseite 437
       REM übernommen. Andernfalls erscheint hier eine Fehlermeldung, weil
       REM MDA-/HGC-Karten keine Codeseitenunterstützung bieten...
       DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,(1,3))
       REM oder einfacher: DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,1)
       REM Statt CON kann man (undokumentiert) auch CON: schreiben.
       REM An die DISPLAY.SYS Zeile kann man (undokumentiert) einen mit
       REM Semikolon abgetrennten Kommentar anhängen.
       REM -----------------------------------------------------------------
       REM Falls Sie (noch) einen Matrixdrucker angeschlossen haben, wird
       REM meist die Epson-FX850/1050 Emulation auch mit Ihrem Drucker
       REM funktionieren (wohingegen die anderen angebotenen Drucker der-
       REM maßen selten sind, daß man sie getrost hätte weglassen können).
       REM Glück für Novell DOS Benutzer, denn bei MS-DOS gibt es überhaupt
       REM keine Unterstützung für Epson-Drucker (bei PC-DOS 6.1 wurde dies
       REM nachgeholt, um dann mit MS-DOS 7 und PC-DOS 7 den Treiber
       REM PRINTER.SYS ganz wegfallen zu lassen...). Auch hier:
       REM Codeseite 437 wählen, wenn Ihr Drucker auf die üblichen US-
       REM amerikanischen Einstellungen konfiguriert ist. Folgendes Beispiel
       REM für einen Epson-kompatiblen Farbdrucker:
       DEVICEHIGH=c:\nwdos\printer.sys prn=(1050,437,1)
       INSTALLHIGH=c:\nwdos\graphics.com color
       ...

      AUTOEXEC.BAT:

       ...
       REM Hier nun die Codeseiten wählen, mit denen man (optional) arbeiten
       REM möchte (hier 850)... (Bei mehr als einer vorzubereitenden Code-
       REM seite wird die Syntax etwas komplizierter...)
       @MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
       @MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
       REM NLSFUNC lädt sich selbst hoch, sogar in die HMA!
       @NLSFUNC c:\nwdos\country.sys
       REM Wird nur für echte CGA-Karten benötigt (nicht bei Emulationen
       REM durch EGA-/VGA-Karten). Ist nicht (direkt) für HGC-Grafiken
       REM geeignet, dafür gibt es allerdings andere Treiber auf dem Markt.
       REM @LH GRAFTABL
       REM Auf Standard-Codeseite umschalten...
       CHCP 437
       REM Tastaturtreiber laden (lagert sich normalerweise in HMA aus):
       REM (Eine Alternative zu KEYB ist K3PLUS/FreeKEYB, zu beziehen über
       REM mich.)
       @KEYB GR+
       ...


   ii. Tips zum 'Nachrüsten' fehlender Geräte oder Codeseiten:
   -----------------------------------------------------------

      Der Treiberdatei PRINTER.SYS scheint noch Einträge für 3 zusätzliche
       Drucker ("anyother") zu besitzt. Durch Vergleich der Dateien aus
       DR DOS 3.40 bis Novell DOS 7 kann man feststellen, daß die Unter-
       schiede nur minimal sind. Mit etwas Übung sollte es möglich sein,
       den Treiber so zu patchen, daß er auch andere Namen als "1050",
       "4201", "4208" oder "5201" akzeptiert.
       Danach könnte man sich eigene .CPI-Dateien für ganz persönliche
       Drucker erstellen.
       Eine Sache steht dem allerdings (zumindest für einige Kombinations-
       möglichkeiten) entgegen: In einigen Fällen (wohl in erster Linie
       für die Hardware-Codeseite) werden die Escape-Sequenzen für den
       Drucker direkt aus dem Treiber PRINTER.SYS und nicht aus einer
       .CPI-Datei entnommen. Hier hilft es nur, auch die Hardware-Codeseite
       zu überladen. Aber auch dann, werden - zumindest bei Novell DOS und
       abhängig von gewählten Druckertyp - offenbar immer noch Teile der
       Sequenzen aus den treiberinternen Tabellen entnommen.
       Gute Erfahrungen mit Novell DOS 7 habe ich mit dem Erstellen von
       .CPI-Dateien gemacht, die den Druckertyp 1050 ersetzen. Das Format
       der .CPI-Datei ist für diesen Typ zwar nicht ganz so übersichtlich
       wie für die anderen drei Typen (jeweils noch mit Untertypen), aber
       ist hier definitiv eine 100%ige Ersetzung aller Escape-Sequenzen
       durch Sequenzen aus der .CPI-Datei möglich, eine Grundvoraussetzung
       für eigene Experimente, wenn die .CPI-Datei nicht nur mit einer
       DOS-Version funktionieren soll. Nachteilig am Typ "1050" ist es,
       daß MS-DOS/PC-DOS diesen Typ evtl. nicht kennt. Dort müßte man auf
       "4201" ausweichen, was aber unter Novell DOS 7 zu Problemen führt.
       Wer eine .CPI-Datei für die NEC Pinwriter Serie (P6plus (P5200),
       P7plus (P5300), P20/P30, P60/P70, P90, P22Q/P32Q, P62/P72, P42/P52,
       P42Q/P52Q und andere) sucht, kann eine solche Datei von mir anfordern
       (NECPINW.ZIP).

      Bei meinen Untersuchungen habe ich herausgefunden, daß das .CPI-
       Format von Novell DOS im Großen und Ganzen eine Erweiterung des
       .CPI-Formates von MS-DOS darstellt: Das Format der Druckerdateien
       ist quasi identisch. Die Display-Fonts ab DR DOS 6.0 sind in einem
       neuen Format abgelegt, das zwar äußerlich dem bisherigen Format
       ähnelt, aber durch Kompression wesentlich effizienter ist. Bis
       DR DOS 5.0 war das Datenformat sowohl der Drucker- als auch der
       Display-Fonts fast identisch zum MS-DOS "FONT" Format (außer einer
       'falschen' Typkennung in den Drucker-Fonts). Die neuen komprimierten
       Display-Fonts ("DRFONT") von DR DOS 6.0 und Novell DOS 7 sind so
       angelegt, daß die .CPI-Dateien nur etwa halb so groß wie die ent-
       sprechenden Dateien von MS-DOS sind, obwohl im Gegensatz zu
       MS-DOS/PC-DOS statt fünf oder sechs Codeseiten mit jeweils drei
       Fonts (8x8, 14x8 und 16x8) neun (!) Codeseiten mit jeweils vier (!)
       Fonts (6x8, 8x8, 14x8 und 16x8) unterstützt werden! Der Font 6x8
       ist undokumentiert und läßt sich offenbar auch nicht ohne Patchen
       von DISPLAY.SYS freischalten, obwohl er innerhalb der .CPI-Dateien
       in vollem Umfang definiert wird. Jedenfalls führen Versuche wie

        DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,(1,4))
                                                     ^----!!!

       zu einer Fehlermeldung. Der Font 6x8 wäre - entsprechende Unter-
       stützung durch das Grafikkarten-BIOS vorausgesetzt - für Textdar-
       stellung in Grafikmodi und für Textmodi mit mehr als 43 Zeilen auf
       Super-EGAs, mehr als 60 Zeilen auf Super-VGAs oder auch - mit Blick
       auf DR PalmDOS - für spezielle reduzierte LCD-Anzeigen von PalmTops
       interessant.

       Trotzdem akzeptiert Novell DOS auch alte DR DOS .CPI-Dateien, und
       - als Cloú - sogar .CPI-Dateien von MS-DOS oder PC-DOS (LCD.CPI
       nur nach einem Patch, s.u.)! (Umgekehrt dürfte dies generell nicht
       möglich sein.)
       Da MS-DOS/PC-DOS in einigen Punkten mehr oder andere Codeseiten
       unterstützt, sollte es möglich sein, bei Bedarf die Codeseitendatei
       von MS-DOS/PC-DOS auszuleihen. Allerdings:
       Wird eine Codeseite bei Novell DOS (und DR DOS) bis auf wenige Aus-
       nahmen für alle möglichen Geräte unterstützt, sieht die Situation bei
       MS-DOS/PC-DOS wesentlich schlechter aus. Hier beschränkt sich der
       Support mancher seltener Codeseiten teilweise auf nur ein Gerät
       (was die Frage nach dem Sinn des ganzen Aufwands aufkommen läßt, den
       Microsoft in diesem Bereich getrieben hat, wenn man es dann doch nur
       halb nutzen kann...). Abgesehen davon enthalten die .CPI-Dateien
       von MS-DOS/PC-DOS (speziell die für Drucker) etliche Unstimmigkeiten,
       die u.U. sogar zum Hängen des Rechners führen könnten, wenn nicht
       explizit darauf eingegangen wird. Wenn nicht alle Geräte auf die
       gleiche Codeseite umgeschaltet werden können (eben z.B. weil eine
       Codeseite nicht für alle Geräte verfügbar ist), kann man statt

        CHCP codepage

       (das für seine Hauptfunktion, Codeseiten umzuschalten, auch noch
       NLSFUNC benötigt) den Befehl

        MODE device CODEPAGE SELECT=codepage
        (mit device=con:, prn:, lpt1:, lpt2:, lpt3:)

       verwenden, der die Codeseite nur selektiv für das jeweilige Gerät
       umschaltet. Das klappt auch dann, wenn bei CHCP nur Fehlermeldungen
       erscheinen, weil NLSFUNC nicht geladen ist oder die Codeseite über-
       haupt nicht für das eingestellte Land gedacht ist (das hängt von
       COUNTRY.SYS ab). Ansonsten (z.B. bei MS-DOS) muß man entweder jedes-
       mal die CONFIG.SYS COUNTRY= Einstellung ändern und neu booten oder
       mit meinem FreeWare-Utility COUNTRY.EXE (über die entsprechende
       API-Funktion) die Landeseinstellung ändern. Obwohl nach dem Laden
       von NLSFUNC für Programme Zugriff auf die landesspezifischen Daten
       aller in COUNTRY.SYS unterstützten Länder gewährleistet ist, können
       Sie bei eingerichtetem Codeseitensupport nicht wahlfrei auf ein
       anderes Land umschalten, wenn Sie eine Codeseite aktivieren, die
       für das gewünschte Land nicht gedacht ist (d.h. nicht alle Geräte
       mit aktivierter Codeseitenunterstützung dieses Land unterstützen).
       Dies führt manchmal zu recht paradoxen Situationen, in denen zwar
       voller Support (inkl. Codeseitenunterstützung) für ein bestimmtes
       Land vorhanden ist, Sie aber trotzdem zur Laufzeit nicht umschalten
       können, weil eine 'fremde' Codeseite aktiviert ist. In diesen
       Fällen gelingt die Umschaltung über eine Zwischenstufe, indem Sie
       mit CHCP auf Codeseite 850 (manchmal 437) zurückschalten, danach
       mit COUNTRY.EXE z.B. auf 1 (USA) wechseln, dort die gewünschte
       neue Codeseite mit CHCP wählen und dann mit COUNTRY.EXE auf das
       neue Land umschalten. Dies ist aber kein Fehler, sondern nur eine
       Nachahmung des 'ganz normalen Verhaltens', das MS-DOS in diesen
       Situationen auch zeigt. Mit COUNTRY.EXE können Sie auch heraus-
       finden, welche Länder für jeweils welche Codeseiten in Ihrer
       Systemkonfiguration unterstützt werden.

      Ohne, daß ich dies auch unter MS-DOS ausprobiert habe, möchte
       ich darauf hinweisen, daß die Codeseitenumschaltung auch in
       hohen Textmodi funktioniert (sofern die Fonts 8x8, 14x8 und 16x8
       installiert sind): Mit meiner ET4000-Karte arbeiten die Textmodi
       40x25, 80x25/43/50/60 und 132x25/28/60 als auch die Grafikmodi.
       Bei den Modi 80x43/50 wurde allerdings jeweils auf 80x25 zurück-
       geschaltet, was man nachträglich wieder ändern kann (um dies zu
       verhindern, müßte man einige Ergänzungen im residenten Code von
       DISPLAY.SYS implementieren). Die Textmodi 100x40 und 132x44 führten
       allerdings aus noch ungeklärter Ursache zu EMM386-Schutzfehlern.
       Reduziert man die Anzahl der installierten Fonts, kommt es auch
       beim Umschalten von Codeseiten in anderen höheren Textmodi zu
       Schutzfehlern. Offenbar gibt es hier einen Bug in DISPLAY.SYS.

      Möchten Sie die einzelnen Zeichensätze simultan miteinander ver-
       gleichen, können Sie z.B. einen Grafikmodus aktivieren und sich
       danach mit einem kleinen Public-Domain-Utility (wie ASCII.COM) alle
       ASCII-Zeichen ausgeben lassen. Danach schalten Sie mit CHCP auf eine
       andere Codeseite um, und wiederholen die Anzeige aller Zeichen. Da
       im Grafikmodus die Zeichen als Pixel abgelegt werden, werden Sie
       nicht mit jedem Codeseitenwechsel umgeschaltet, so daß die Simultan-
       darstellung möglich wird.

      Leider unterstützt Novells DISPLAY.SYS als Gerätetyp nur "EGA",
       nicht aber "LCD" (die anderen von MS-DOS unterstützten Typen "MONO",
       "CGA", "EGA 8", "EGA 14", "EGA 14M" sind nur Dummies bzw. einiger-
       maßen obsolet. Die MS-DOS-Datei ISO.CPI enthält einen "EGA" Typ,
       der von Novell DOS problemlos akzeptiert wird). Das Laden von MS-DOS
       LCD.CPI unter Novell DOS scheitert am Typ "LCD". Trotzdem kann man
       sich nach einer kleinen Modifikation auch die LCD.CPI Datei von
       MS-DOS ausleihen:

        COPY LCD.CPI NW7LCD.CPI
        DEBUG
         -Nnw7lcd.cpi
         -L
         -S0 cx+0100 "LCD"
          cs:<aaaa>             (Üblicherweise 5 Vorkommen, wobei man die
          cs:<bbbb>              letzte Angabe normalerweise nicht patchen
          cs:<cccc>              muß, da sie sich in einem Kommentarfeld
          cs:<dddd>              befindet!)
          cs:<eeee>
          cs:<ffff>
         -E<aaaa> "EGA"
         -E<bbbb> "EGA"
         -E<cccc> "EGA"
         -E<dddd> "EGA"
         -E<eeee> "EGA"
         -W
         -Q

       Nun kann die Datei NWLCD.CPI ganz normal wie EGA.CPI geladen werden,
       mit dem Unterschied, daß sie nur den Font 8x8 unterstützt.
       Vergessen Sie nicht, auch die Hardware-Codeseite (meist 437) mit
       einer vorzubereitenden Codeseite 437 zu überladen, sonst ändert
       sich die Darstellung nur in allen anderen Codeseiten (vgl.
       DISPLAY.SYS in Kapitel II.4.).

      Möchten Sie MS-DOS/PC-DOS ISO.CPI Datei verwenden, sollten Sie
       zusätzlich zu den normalerweise einzurichtenden Codeseiten noch 437
       einrichten, denn der Hardware-Font 437 unterscheidet sich eklatant
       vom Font 437 aus ISO.CPI (dies gilt für jedes DOS).
       Auch hier gilt das bei LCD.CPI bezüglich der Codeseite 437 Gesagte.

      Sollten Sie für die Erstellung neuer Codeseiten/Fonts das "DRFONT"
       oder "FONT" .CPI-Dateiformat benötigen oder .CPI-Dateien analysieren
       und auseinandernehmen wollen, können Sie über mich das Programm
       CPI.EXE, meinen FreeWare-Analyser und -Decompiler für Codeseiten-
       Dateien (im Archiv CPI???.ZIP) anfordern (z.B. auf meiner Web-Seite).
       Im Groben ist das Dateiformat auch in Ralf Browns Interrupt-Liste
       INTER50+ dokumentiert.
       Bei der Erstellung eigener .CPI-Dateien dürften EGA-/VGA-Font-Editore
       (wie bei nahezu allen SuperVGA-Karten mitgeliefert) eine praktische
       Hilfe sein. Die dort mitgelieferten .FNT-Dateien haben i. allg. das
       gleiche Format (als Zeichen-Bitmaps) wie die internen Font-Daten
       innerhalb der .CPI-Dateien, so daß Konvertierprogramme relativ
       einfach zu schreiben sind (teilweise ist noch ein kurzer Info-Header
       vorangestellt).
       Sollten Sie spezielle FreeWare oder Public-Domain .CPI-, .CP- oder
       .FNT-Dateien besitzen oder erstellen, wäre es nett, wenn Sie sie
       auch mir zuschicken könnten: Ich möchte in Zukunft ein kostenloses
       Sammelpaket für neue und erweiterte .CPI-Dateien einrichten, so daß
       für jedes DOS zusätzliche Geräte, Codeseiten und Fonts zur Verfügung
       stehen.


   iii. Landescodes und Keyboard-Kürzel:
   -------------------------------------

     Die folgende Tabelle enthält die wichtigsten Ländercodes, die von DOS
     unterstützt werden. Grundsätzlich ist zu sagen, daß Keyboard-IDs nur
     von MS-DOS/PC-DOS 4.0+ unterstützt werden, Novell DOS 7 und DR DOS 6.0
     verwenden teilweise andere Keyboard-Layout-Kürzel um das Gleiche zu er-
     reichen. Novell DOS 7 unterstützt auch nicht alle Layout-Kürzel (siehe
     Kapitel II.4. bei KEYB). Ein Plus ('+') hinter dem Kürzel bedeutet, daß
     seit MS-DOS 6.2? mehr als eine Einstellung unter dem gleichen Namen
     existiert. Diese erweiterten Möglichkeiten sind Novell DOS 7 fremd.
     Normalerweise ist Novell DOS' KEYB besser als das Gegenstück von
     MS-DOS, da der Treiber sich selbständig in die HMA auslagert und den
     darunterliegenden BIOS-Treiber teilweise mitbenutzt. Ein Stern ('*')
     bedeutet, daß PNW 1.0 (und NetWare 3.xx) entsprechende Unterstützung
     besitzt. Zwei Sterne ('**') bedeuten, daß mittlerweile Unterstützung
     für jede NetWare (mit ODI/VLM) vorliegt, die z.B. in Novells Client-
     Kit zu finden ist. Sollten Sie jedoch Fähigkeiten vermissen, die bei
     MS-DOS 6.2? KEYB neu hinzugekommen sind, können Sie mittels SETVER
     auch diesen Treiber verwenden oder auf den erweiterten Tastaturtreiber
     K3PLUS 6.50+ bzw. FreeKEYB (zu beziehen über mich) ausweichen.
     Novell DOS' Direktive COUNTRY= akzeptiert leider auch nicht die
     COUNTRY.SYS Datei von MS-DOS, so daß die Möglichkeit des 'Ausleihens'
     in diesem Fall ausscheidet (was besonders ärgerlich ist, da dadurch
     auch das Ausleihen von MS-DOS .CPI-Dateien für exotische Länder
     schwieriger wird). Ältere COUNTRY.SYS Dateien von DR DOS 5.0 und 6.0
     als auch die von Caldera OpenDOS können aber verwendet werden (wichtig
     zu wissen, falls Sie eine fremdsprachige DR DOS COUNTRY.SYS Datei
     besitzen, die Einstellungen unterstützt, die Novell DOS 7 in der
     deutschen Distribution fremd sind (würde mich übrigens sehr interes-
     sieren)). Das Format der COUNTRY.SYS Datei von DR DOS/Novell DOS
     findet sich ebenfalls in Ralf Browns Interrupt-Liste. Das Format
     von MS-DOS/PC-DOS/OS/2 COUNTRY.SYS wird wahrscheinlich ab INTER54+
     ebenfalls dort dokumentiert sein und ist auch in meinem Archiv
     COUNTRY.ZIP zu finden.

     Die deutsche Ausgabe von Novell DOS 7 enthält in der COUNTRY.SYS Datei
     zusätzlich zu den in der Dokumentation erwähnten Ländern Support für
     die ehem. Tschechoslowakei (Tschechien und teilweise Slowakei) (42),
     Österreich (43), Japan (81), Korea (82), Saudi Arabien (785) und Israel
     (972), obwohl für Fern-Ost wohl eine andere .CPI-Datei benötigt wird,
     da die deutschen .CPI-Dateien keine Unterstützung für die Codeseite
     932 etc. bietet. Vermutlich liegen auch allen anderen Ausgaben von
     Novell DOS 7 (außer der Japan-Version, falls diese wirklich existiert)
     die gleichen COUNTRY.SYS und .CPI-Dateien bei.
     Das ehem. Jugoslawien (38) sowie die Nachfolgestaaten und Brasilien
     (55) werden von COUNTRY.SYS nicht unterstützt, wohl aber vom Keyboard-
     Treiber ('~'). Achtung: Versuchen Sie niemals unter Novell DOS 7 das
     Land 0 zu *setzen* (welches sowieso nicht definiert ist), in diesem
     Fall wird der Rechner abstürzen (getestet mit Update 15).

     Übrigens: Wie schon angedeutet, hängen die beiden Größen Country-Codes
     und Codeseiten über ein recht verwirrendes Regelwerk zusammen und die
     landesspezifischen Daten eines Landes können sich - einmal vor den
     offensichtlichen Änderungen in der Repräsentation der Daten - auch
     beim Ändern der Codeseite ändern! Z.B. ändert sich jeweils zwischen
     den beiden von Rußland und Spanien unterstützten Codeseiten die
     Darstellung von Währungen, zwischen den beiden von Italien und
     Deutschland unterstützten Codeseiten die Darstellung des Zeitformates:
     "hh:mm" bei 437 und "hh.mm" bei 850, allerdings nur bei Novell DOS 7
     und DR DOS, nicht bei MS-DOS/PC-DOS. Dies ist allerdings zumindest
     für Deutschland kein Fehler (mehr), da hier seit kurzem (Mai 1996)
     neue Normen für Geschäftsbriefe eingeführt wurden und Daten jetzt
     "yy-mm-dd" und Zeiten "hh:mm" geschrieben werden.

      Einschub: Das 'japanische' Datumsformat hat zwei Vorteile gegenüber
                den beiden anderen Formaten:

                1. Es kann wegen der führenden Jahreszahl nicht mit den
                   beiden anderen Formaten verwechselt werden (zumindest
                   nicht bis zum Jahr 2001).
                   Beispiel:
                   Ist "10.11.96" der Zehnte des Monats November oder
                   der Elfte des Monats Oktober? Ohne Zusatzinformation
                   läßt sich dies nicht immer eindeutig entschlüsseln,
                   denn das verwendete Separator-Zeichen ist international
                   gesehen kein generelles Unterscheidungsmerkmal.

                2. Wegen der absteigenden Priorität der Größen Jahr,
                   Monat, Tag entsteht im Datum ohne zusätzliche Maßnahmen
                   von selbst eine eindeutige Sortierreihenfolge.
                   Beispiel:
                   Benennt man Dateien, die Briefe (EMails) enthalten, nach
                   dem Erstellungsdatum, so werden diese bei alphabetisch
                   sortierten Inhaltsverzeichnisausgaben automatisch
                   chronologisch angeordnet, auch wenn man die Briefe über
                   mehrere Jahre hinweg in einem Verzeichnis ablegt. Dies
                   ist bei den beiden anderen Datumsformaten nicht der Fall.

     Entgegen der Dokumentation bereitet bei Novell DOS die Aktivierung
     der Codeseite 437 für Kanada (engl.) (2) und der Codeseite 850 für
     Australien (Internationales Englisch) (61) Probleme (evtl. liegen
     hier Fehler in der COUNTRY.SYS Datei vor; näheres ist noch nicht
     untersucht). Speziell auf Deutschland bezogen gibt es auch Unterschiede
     in den landesspezifischen Daten, die von Novell DOS bzw. MS-DOS
     geliefert werden (z.B. im Währungs- und Zeitformat).

     Sollte Sie dies stören, können Sie die COUNTRY.SYS Datei von Novell DOS
     auch so patchen, daß die gleichen Daten wie bei MS-DOS zurückgeliefert
     werden. Beispielhaft wird dies für die deutschen Landeseinstellungen in
     der COUNTRY.SYS Datei, die bei der deutschen Novell DOS 7 Ausgabe bei-
     liegt (13312 Bytes) erläutert. Das Byte an Offset +08E9h ausschlag-
     gebend. Hier steht normalerweise ein 2Eh '.', das in ein 3Ah ':' ge-
     ändert werden kann (nach der Norm bis Anfang 1996 war dies jedoch
     eigentlich bei MS-DOS falsch). Der Vorgang mit DEBUG:

      COPY COUNTRY.SYS COUNTRY1.SYS
      DEBUG
       -Ncountry1.sys
       -L                     Der Wert für CX (die Dateilänge) sollte hier
                              3400h betragen! Sonst nicht fortfahren!
                              Für Codeseite 850:
       -Ecs:09E9 2E. 3Ah      Falls dort ein Zeitseparator 2Eh '.' steht,
                              diesen durch 3Ah ':' <RET> ersetzen.
                              Ansonsten nur <RET> drücken, denn Sie haben
       -W                     wahrscheinlich etwas falsch gemacht, oder die
       -Q                     Datei ist bereits angepaßt.

     Möchten Sie die deutschen Landeseinstellungen von Novell DOS 7 hingegen
     *komplett* an die neue Norm für Geschäftsbriefe anpassen, können Sie
     COUNTRY.SYS stattdessen folgendermaßen patchen (in diesem Beispiel
     werden die Einstellungen für Codeseiten 437 und 850 geändert):

      COPY COUNTRY.SYS COUNTRY2.SYS
      DEBUG
       -Ncountry2.sys
       -L                     Der Wert für CX (die Dateilänge) sollte hier
                              3400h betragen! Sonst nicht fortfahren!
                              Für Codeseite 437:
       -Ecs:09C0 01. 02h      Falls dort 01h steht, dies mit 02h <RET>
                              für 'Japanisches' Datumsformat überschreiben.
                              Ansonsten nur <RET> drücken.
       -Ecs:09CB 2E. 2Dh      Falls dort ein Datumsseparator 2Eh '.' steht,
                              diesen mit 2Dh '-' <RET> überschreiben.
                              Für Codeseite 850:
       -Ecs:09DC 01. 02h      Falls dort 01h steht, dies mit 02h <RET>
                              für 'Japanisches' Datumsformat überschreiben.
                              Ansonsten nur <RET> drücken.
       -Ecs:09E7 2E. 2Dh      Falls dort ein Datumsseparator 2Eh '.' steht,
                              diesen mit 2Dh '-' <RET> überschreiben.
       -Ecs:09E9 2E. 3Ah      Falls dort ein Zeitseparator 2Eh '.' steht,
                              diesen mit 3Ah ':' <RET> überschreiben.
                              Ansonsten nur <RET> drücken.
       -W
       -Q

     (Für dieses Unterfangen steht auf meiner Web-Seite und auf einigen
     FTP-Servern unter dem Namen JPDATE49.ZIP auch ein automatisierter
     Patch zur Verfügung.)

     Die allermeisten Länder unterstützen wenigstens Codeseite 850 (und
     über die Hardware 437, allerdings nicht unbedingt auf der Ebene von
     COUNTRY.SYS), dies wird aber nur kritisch, wenn Sie Codeseitenunter-
     stützung eingerichtet haben.


      Land Name                Codeseiten Keyboard  MS-DOS/ Caldera OpenDOS/
                                          Layout    PC-DOS      Novell DOS
                                 (3.3+)   (3.0+)                  DR DOS

      000  undefiniert           7Bit-ASCII --         --           --!   **
      001  Vereinigte Staaten    437,850  US (103)     2.00+        3.40+ *
                                          DV (Dvorak)  6.20+        --
                                          RH (Rechts)  6.20+        --
                                          LH (Links)   6.20+        --
      002  Kanada (Französisch)  850,863  CF + (058)   2.00+        3.40+ *
             ""   (Englisch)     850,863  CF +         --           3.40+ *
      003  Lateinamerika         850,437  LA (171)     2.00+        3.40+ *
      004  Kanada (Englisch)     850,863  CF +         6.2?+        --
      007  Rußland   866,855,852,850,437  RU 441,443,341 6.2?+      6.0+  **
      027  Südafrika             437,850  US           6.2?+        --
      030  Griechenland      869,737,850  GK 319       6.2?+        --
      031  Niederlande           850,437  NL (143)     2.00+        3.40+ *
      032  Belgien               850,437  BE (120)     2.00+        3.40+ *
      033  Frankreich            850,437  FR 120,189   2.00+        3.40+ *
      034  Spanien               850,437  SP (172)     2.00+        3.40+ *
      035  undokumentiert??? (offenbar wie Bulgarien)  6.22/95      --
      036  Ungarn                852,850  HU 208       2.00+/5.0+   6.0+  **
      038  ehem. Jugoslawien     852,850  YU 234       2.00+/5.0+   ~6.0-7
             "" (Kyrillisch)     855,850  YC 118       6.2?+        --
      039  Italien               850,437  IT 141,142   2.00+        3.40+ *
      040  Rumänien              852,850  RO 333,446   6.2?+        --
      041  Schweiz (Deutsch)     850,437  SF (Franz., 150)  2.00+   3.40+ *
                                          SG (Deutsch, 000) 2.00+   3.40+ *
      042  ehem. Tschechoslowakei                                         **
                 "" (Tschechien) 852,850  CZ 243       5.0+         6.0+
                 "" (Slowakei)   852,850  SL           5.0
      043  Österreich            850,437  GR +         6.2?+        5.0+
      044  Großbritannien        850,437  UK 166,168   2.00+        3.40+ *
      045  Dänemark              850,865  DK (159)     2.00+        3.40+ *
      046  Schweden              850,437  SV (153)     2.00+        3.40+ *
      047  Norwegen              850,865  NO (155)     2.00+        3.40+ *
      048  Polen                 852,850  PL (214)     5.0+         6.0+  **
                     (zusätzlich 667 und 668 bei PTS/DOS 6.51 und S/DOS 1.x)
      049  Deutschland           850,437  GR + (129,453) 2.00+      3.40+ *
      052  Mexiko                850,437  LA           6.2?+        --
      054  Argentinien           850,437  LA           6.2?+        --
      055  Brasilien             850,437  BR 274,275   5.0+         ~6.0+
      056  Chilé                 850,437  LA           6.2?+        --
      057  Kolumbien             850,437  LA           6.2?+        --
      058  Venezuela             850,437  LA           6.2?+        --
      060  Malaysia              437,???  --           6.2?+        --
      061  Internat. Englisch    437,850  --           2.00+              *
                   Australien    437,850  US           6.2?+        3.41+ *
      064  Neuseeland            437,850  US           6.2?+        --
      065  Singapur              437,???  --           6.2?+        --
      066  Tailand               874                   --           --
      081  Japan                 437,932  JP (194)     ~5.0+        3.40+ *
                                          JA           4.0          --
      082  Korea                 437,934  (KO)         ~4.0/~6.2?   5.0+
      086  VR China              437,936  (CH)         ~4.0/~5+
      088  Taiwan (China trad.)  437,938  (TN)         ~4.0/~5+
      090  Türkei                857,850  TR 440,179   5.0?+        --    **
                                          TF (FDDIOD)  --           6.0+
                                          TQ (QWERTY)  --           6.0+
      091  Indien                437,???  --           6.2?+        --
      099  Asien (Englisch)               --           --           --
      351  Portugal              850,860  PO (163)     2.00+        3.40+ *
      353  Irland                850,437  UK           6.2?+        --
      354  Island                850,861  IS 161,197   6.0+         --
      355  Albanien              852,850  AL (452)     6.2?+        --
      358  Finnland              850,437  SU (153)     2.00+        3.40+ *
      359  Bulgarien             855,850  BG 442,(241) 6.2?+        --
      370  Litauen               (1257)                --           --
      371  Lettland              (1257)                --           --
      372  Estland               (1257)                --           --
      381  Serbien/Montenegro 855,850,915 YC 118,450   6.2?+        --
      384  Kroatien              852,850  YU 234       6.2?+        --
      385  Kroatien              852,912  HR 234       PC 7.0       --
      386  Slowenien          852,850,912 YU,SI 234    6.2?+        --
      387  Boznien/Herzegowina   852,850  YU 234       6.2?+        --
      388  Boznien/Herzegowina   855,915  BC 450,118   PC 7.0       --
      389  Mazedonien            855,850  YC 118       6.2?+        --
      421  Slowakei              852,850  SL 245       6.2?+        --
           Tschechien            852,912  CZ 243       PC 7.0       --
      422  Slowakei              852,912  SK 245       PC 7.0       --
      593  Äquador               850,437  LA           6.2?+        --
      711  undokumentiert??? (Währung ist EA$)         6.22/95      --
      785  Mittlerer Osten/
           Saudi Arabien         850,864  --           ~2.00+/5.0+  3.40+ **
      852  Hongkong              437,???  --           6.22+
      886  Taiwan                                      6.22+
      972  Israel (Hebräisch)    850,862  --           ~2.00+/5.0+  3.40+ **

     Normalerweise kann man die Einstellung des aktuellen Landes nur über
     die COUNTRY= Direktive beim Booten des Rechners ändern (siehe Kapitel
     III.1.). Gibt man keine COUNTRY= Direktive an, so werden üblicherweise
     die US-amerikanischen Landeseinstellung angenommen (manchmal auch die
     Einstellung der Landesanpassung, allerdings nicht bei allen mir be-
     kannten Ausgaben von DR DOS und Novell DOS). Mit entsprechenden
     Utilities kann man die Landeseinstellungen jedoch auch zur Laufzeit
     ändern, siehe z.B. mein FreeWare-Utility COUNTRY.EXE (aus COUNTRY.ZIP).
     Übrigens werden sie dabei gleichzeitig für alle Tasks des evtl.
     laufenden Multitaskers wie TASKMGR oder Windows geändert, was manchmal
     wünschenswert, manchmal aber auch unpassend ist. Solange man bei
     COUNTRY= nicht den Namen zur Datei COUNTRY.SYS angegeben hat, kann
     man offenbar in einigen DOS-Versionen nur zwischen den US- und den
     bei COUNTRY= gewählten Einstellungen wechseln (da diese immer im
     Speicher liegen), sonst (zumindest bei installiertem NLSFUNC) zwischen
     allen Ländern, die von COUNTRY.SYS unterstützt werden.


   iv. Codeseiten:
   ---------------

     Die folgende Tabelle enthält eine kurze Zusammenfassung der Codeseiten-
     Unterstützung in den verschiedenen DOS-Versionen. Anhand dieser Tabelle
     können Sie schnell feststellen, ob die benötigte Codeseite von
     Novell DOS 7 unterstützt wird oder ggf. von einer DR DOS, MS-DOS
     oder PC-DOS Version entliehen werden kann (wobei bei Letzteren bei
     weniger üblichen Codeseiten zumindest in den westeuropäischen und
     amerikanischen Versionen i. allg. nicht alle Geräte unterstützt
     werden). Es ist möglich, daß die aufgeführten Codeseiten nicht in
     allen landessprachlichen Versionen unterstützt werden (falls mir dies
     bekannt ist, habe ich den entsprechenden Eintrag mit '~' versehen).
     Im Zweifelsfall wenden Sie sich am besten an Novell bzw. Caldera.
     Soweit eindeutig bekannt, habe ich DBCS-Codeseiten (double byte
     character sets) extra erwähnt, jedoch sind auch noch einige der
     restlichen Codeseiten DBCS-Codeseiten. (Ein '*' bedeutet, daß die
     Codeseite von PNW 1.0 und NetWare 3.xx unterstützt wird, '**' bedeutet,
     daß sie standardmäßig nur von NetWare 3.xx unterstützt wird, nicht
     von PNW 1.0. Natürlich ist es möglich, sich die entsprechenden
     Dateien des \NLS\ Verzeichnisses von einer großen NetWare auszuleihen.
     Ein '!' bedeutet, daß diese Codeseitennummer von Novell NetWare für
     einen reduzierten 7Bit-ASCII Zeichensatz reserviert ist, um für Länder,
     für die noch keine Codeseitenunterstützung existiert, überhaupt ein
     Arbeiten zu ermöglichen. Diese 'Codeseite' unterstützt nur die Zeichen
     ASCII-32 bis ASCII-127 mit Ausnahme von ASCII-92.)

     (Die zusätzlichen Angaben zu OS/2 und MS Windows95 haben nur
     informativen Charakter, da die interne Organisation anders realisiert
     ist; ein Austausch dürfte nicht möglich sein. Für den MS-DOS 7 Anteil
     von MS Windows95 und PC-DOS 7 hat sich nicht sonderlich viel getan,
     außer daß die beiden bisher undokumentierten Printer-Codeseiten durch
     generellen Verzicht auf Printer-Codeseiten-Dateien flachgefallen sind
     und, daß - bei MS-DOS 7 - die Display-Codeseiten aufgrund des neu
     eingeführten Long-Filename-Supports nun nur noch zum Installations-
     zeitpunkt umgeschaltet werden können (Ausnahme CHANGECP). Benutzt man
     CHCP in einer DOS-Box, so täuscht es das Umschalten der Codeseite vor,
     ohne die Umschaltung wirklich vorzunehmen. Allerdings hatte auch schon
     unter MS Windows 3.xx die Umschaltung der Codeseite für DOS-Boxen im
     Fenster keine sichtbare Wirkung, solange nicht entsprechende Fonts
     installiert waren. All diese Gründe sprechen dafür, auch heute noch
     die Codeseite 437 als Standard unter Windows zu wählen, d.h. Windows95
     sofort nach der Installation mit CHANGECP auf diese Codeseite zurück-
     zuschalten.)

      Codeseite      Name                          MS-DOS/  Novell DOS/
                                                   PC-DOS    DR DOS

        0  Reduziertes 7Bit-ASCII                   --        --!
       37  EBCDIC: Englisch (US/Kanada) (CECP)      --        --
       38  EBCDIC: International (alt)              --        --
      111  Griechisch   [AST Premium Exec DOS 5.0]  --        --
      112  Türkisch     [AST Premium Exec DOS 5.0]  --        --
      113  Jugoslawisch [AST Premium Exec DOS 5.0]  --        --
      161  Arabisch [Linux]                         --        --
      162  Arabisch [Linux]                         --        --
      163  Arabisch [Linux]                         --        --
      164  Arabisch [Linux]                         --        --
      165  Arabisch [Linux]                         --        --
      237  EBCDIC: Deutschland (CECP)               --        --
      273  EBCDIC: unbekannt (CECP)                 --        --
      274  EBCDIC: Belgien                          --        --
      275  EBCDIC: Brasilien                        --        --
      277  EBCDIC: Dänemark, Norwegen (CECP)        --        --
      278  EBCDIC: Finnland, Schweden (CECP)        --        --
      280  EBCDIC: Italien (CECP)                   --        --
      281  EBCDIC: Japan (E)                        --        --
      284  EBCDIC: Latein-Amerika/Spanien (CECP)    --        --
      285  EBCDIC: Englisch (UK) (CECP)             --        --
      290  EBCDIC: Japan (Kana)                     --        --
      297  EBCDIC: Französisch (CECP)               --        --
      367  US-ASCII (ISO 646-US 7Bit)               --        --
      420  EBCDIC: Arabisch 1                       --        --
      423  EBCDIC: Griechisch                       --        --
      424  EBCDIC: Hebräisch                        --        --
      437  Englisch/West-Europa (World Trade)       3.30+     3.40+    *
      500  EBCDIC: Belgien, Schweiz (International) (CECP) -- --
      646  (reserviert für ISO 646 7Bit-Codeseiten) --        --
      667  Ost-Europa (Polnisch) [PTS/DOS u. S/DOS] --        --
      668  Ost-Europa (Slawisch) [PTS/DOS u. S/DOS] --        --
      708  Arabien/Mittlerer Osten                  ~95       --
      737  Griechenland (2)                         6.2?+     --
      775  Baltische Staaten (BaltRim)              ~95       --
      819  Latein 1 (ISO 8859-1)                    --        --
      850  International/Multilingual (Latein 1)    3.30+     3.40+    *
      851  Griechenland (undok., siehe 8510) [AST, WP] 4.00-6.22 --
      852  Slawisch/Ost-Europa (Latein 2)           5.0+      6.0+
      853  Türkisch (Latein 2) (undok.) [AST]       4.00-6.22 6.0+
      854  Spanisch (obsolet)???                    --        --
      855  Kyrillisch (1)                           4.00+     --
      857  Türkisch                                 6.1+      6.0+
      860  Portugal (siehe 8600)                    3.30+     3.40+    **
      861  Island                                   6.0+      --
      862  Israel (Hebräisch)                       4.00+/~95 3.40-5.0/~6.0
      863  Kanada (Französisch)                     3.30+     3.40+    **
      864  Arabien/Mittlerer Osten                  4.00+     3.40+
      865  Nordisch (Norwegen/Dänemark)             3.30+     3.40+    **
      866  Rußland (Kyrillisch 2)                   6.1/6.22+ 6.0+
      867  Tschechisch [NEC Pinwriter P20/P30/P60/P70/P90] -- --
      868  Arabisch                                 --        --
      869  Griechenland (1)                         6.1+      --
      870  EBCDIC: Jugoslawien (Roece)              --        --
      871  EBCDIC: Isländisch                       --        --
      874  Thailand                                 ~95       --
      875  EBCDIC: Griechenland                     --        --
      880  Rußland (Kyrillisch GOST und EBCDIC)     --        --
      881  Latein 1 [AST Premium Exec DOS 5.0]      --        --
      882  Latein 2 [AST Premium Exec DOS 5.0]      --        --
      883  Latein 3 [AST Premium Exec DOS 5.0]      --        --
      884  Latein 4 [AST Premium Exec DOS 5.0]      --        --
      885  Latein 5 [AST Premium Exec DOS 5.0]      --        --
      891  unbekannt                                --        --
      895  Tschechisch (Kamenicky) [WP]             --        --
      897  Japan etc. (Shift-JIS)                   --        --       **
      899  Kyrillisch [WP] (siehe 8990)             --        --
      903  unbekannt                                --        --
      904  unbekannt                                --        --
      905  EBCDIC: Türkisch                         --        --
      912  Lateinisch 2 (ISO 8859-2)                PC 7.0    --
      915  Latein/Kyrillisch (ISO 8859-5)           PC 7.0    --
      918  EBCDIC: Arabisch 2                       --        --
      928  reserviert für Griechenland (ELOT 928, ISO 8859-7)
      932  DBCS: Japan (Shift-JIS)                  ~4.00+    ~6.0+    **
      934  DBCS: Korea                              ~4.00+    ~6.0+
      936  DBCS: VR-China (vereinfacht, erw. GB)    ~4.00+    --
      938  DBCS: Taiwan (trad. China)               ~4.00+    --
      942  DBCS: Japan SAA                          (~OS/2)   --
      944  DBCS: Korea SAA                          (~OS/2)   --
      948  DBCS: VR-China SAA                       (~OS/2)   --
      949  Korea (Unified Hangul, erw. Wansung)     ~95       --
      950  China trad., Taiwan, Hong Kong (Big5)    ~95       --
      966  Saudi Arabien                            ~95       --
      972  Hebräisch (Israelisches VT100 Terminal)  --        --
      999  reserviert                               --    5.0+ KEYB
     1002  unbekannt [NT4]                          --        --
     1004  Desktop Publishing           (OS/2, DAPIE, Open32) --
     1026  EBCDIC: Türkei (Latein 5)                --        --
     1047  EBCDIC: Internat. (US, defacto EBCDIC) (CECP) --   --
     1250  WIN: Ost-Europa (Latein 2)               (95)      --       **
     1251  WIN: Kyrillisch                          (95)      --       **
     1252  WIN: Englisch/West-Europa (Latein 1)     (3.xx,95) (PNW 1.0) *
     1253  WIN: Griechenland (GRC)                  (95)      --
     1254  WIN: Türkei                              (95)      --
     1255  WIN: Israel/Hebräisch                    (95)      --
     1256  WIN: Arabien                             (95)      --       **
     1257  WIN: Baltische Staaten                   (95)      --
     1258  WIN: Vietnam                             --        --
     1361  ANSI???: Korea (Johab)                   (95)      --
     8510  Griechenland (Alternativ zu 851) [WP]    --        --
     8600  Portugal (Brasilianisch) [WP]            --        --
     8990  Kyrillisch (Akzentuierte russische Vokale) [WP] -- --
    10000  MAC: International/Standard              --        --
    10001  MAC: unbekannt                           --        --
    10006  MAC: Griechenland                        --        --
    10007  MAC: Kyrillisch                          --        --
    10010  MAC: unbekannt                           --        --
    10017  MAC: unbekannt                           --        --
    10029  MAC: Latein 2                            --        --
    10079  MAC: Island                              --        --
    10081  MAC: Türkei                              --        --
    10082  MAC: unbekannt                           --        --
    10646  (reserviert für ISO 10646 32Bit-Codeseite) --      --
    20261  unbekannt [NT4]                          --        --
    20866  unbekannt [NT4]                          --        --
    28592  unbekannt [NT4]                          --        --
    65400  erste 256 Glyphen des aktuellen Fonts    (OS/2 3+) --
    65534  intern reserviert für DR DOS             --        --
    65535  intern von DOS und DR DOS reserviert     --        --


     Die meisten Taschencomputer (z.B. von SHARP) und einige andere Computer
     benutzen üblicherweise ebenfalls die Hardware-Codeseite 437 (auch wenn
     sie dort meist nicht so heißt), lediglich neuere sog. PDAs (persönliche
     digitale Assistenten) folgen zunehmend dem Trend hin zu Codeseite 850.
     Eine Reihe anderer Computer (Amiga, Acorn) verwenden eine der Codeseite
     1252 (ab Windows 3.0+) entsprechende Zuordnung, die an die ANSI-Code-
     seite nach ISO-8859-1 angelehnt ist, ihr aber nicht zu 100% Prozent
     entspricht. Von DOS selbst wird diese Seite nicht angeboten.
     Aus Gründen der besseren Austauschbarkeit von Dateien empfehle ich -
     wenn nicht spezielle Gründe dagegen sprechen - weiterhin die Codeseite
     437 als Standard zu verwenden und die Codeseite 850 lediglich für alle
     Fälle vorzubereiten, aber nicht als permanente Einstellung zu benutzen
     (auch wenn in den letzten Jahren die meisten Microsoft SETUP-Programme
     die Codeseite 850 eigenmächtig als Standard aktivieren). (Benutzer von
     MS Windows95 müssen sich direkt nach der Installation für eine Code-
     seite entscheiden, d.h. ggf. sofort mit CHANGECP auf 437 umkonfigu-
     rieren. Eine spätere Änderung kann zu nicht mehr über ihren Namen
     erreichbaren Dateien führen, da die neuen Long-Filenames in Unicode
     abgelegt werden und die Zuordnung zwischen Unicode und den jeweiligen
     Zeichensätzen natürlich nicht beliebig umkehrbar ist.)


   v. Internationale Batchjobs:
   ----------------------------

     Beim Schreiben von Batchjobs, die in jedem Land funktionieren sollen,
     muß man besonders aufpassen, wenn innerhalb der Batchjobs Situationen
     auftreten können, die eine Benutzerinteraktion erfordern. In solchen
     Fällen möchte man die notwendigen Eingaben häufig aus einer Eingabe-
     umleitung holen, oder umgekehrt, die Ausgabe bestimmter Kommandos mit
     Filtern wie FIND oder SORT auswerten, um dann im weiteren Verlauf des
     Batchjobs entsprechend zu reagieren.

     Ein häufiges Problem ist z.B. die Ja/Nein-Abfrage, die viele Kommandos
     stellen können. Verwendet man die deutsche Kernel-Version, wird man
     nach (J/N) gefragt (außer in CONFIG.SYS, wo man YESCHAR= einsetzen
     kann); mit der englischen Version lautet die Frage jedoch (Y/N), usw.
     Das Problem liegt nun darin, daß eine Befehlszeile wie

      ECHO J | DEL *.*

     nur mit der deutschen Kernelversion funktioniert. Solange wenigstens
     der Buchstabe für 'Nein' bei allen Kernel-Versionen gleich bleibt,
     d.h. auch nicht mit dem Buchstaben für 'Ja' irgendeiner Kernel-
     Version übereinstimmt, hilft manchmal folgender Trick, der die 'Ja'-
     Buchstaben aller Versionen hintereinander ausgibt (siehe bei FDISK
     in Kapitel II.4.). (Leider ist das global gesehen keine Lösung, denn
     z.B. in Rußland ist der Buchstabe für Ja ein 'L' und für Nein ein 'Y',
     was obendrein noch mit 'Yes' kollidiert. Allerdings gibt es keine
     speziell russische Version von Novell DOS.)

      ECHO YOSJ | DEL *.* > \nul\dev

     (was aber leider so pauschal nur bei 4DOS funktioniert, da hier
     explizit auf 'Ja' oder 'Nein' gewartet wird und nicht alles, was
     nicht 'Ja' ist, als 'Nein' interpretiert wird. Diese Methode kann
     man auch bei Novells MOVE sowie mit FDISK aus Update 15 anwenden,
     siehe Kapitel II.4.).

      ECHO FEAD | MOVE c:\source.tmp c:\dest.tmp

     Für Kommandos, wo diese glückliche Fügung nicht zutrifft (oder in
     anderen DOS-Versionen anders implementiert ist), bietet sich die
     folgende, recht holprige, aber auch mit Novells COMMAND.COM lauf-
     fähige Alternative an (Achtung: Keine Bedingung voranstellen, siehe
     Kapitel IV.6.):

      FOR %%x IN (Y O S J) DO ECHO %%x | DEL *.* > \dev\nul

     oder - bei Verwendung einer Variable %yeschar%, die z.B. in
     AUTOEXEC.BAT belegt wird - auch eine Lösung wie folgt:

      ECHO %yeschar% | DEL *.*

     Damit man in Batchjobs vorsorgen kann, im folgenden eine Übersicht
     über externe Kommandos, die in bestimmten Situationen interaktive
     Bestätigungen erwarten (noch sehr unvollständig, bezieht sich auf
     deutsche Version, für interne Kommandos sei auf Kapitel II.13.
     verwiesen):

                 Ja/Nein  Datei/Verzeichnis  Frage nach Paßwort

      COMP       J/N           -
      MOVE       J/N          D/V
      LABEL      J/N?          -
      UNDELETE   J/N           -
      DELTREE (MS-DOS)        J/N                    -


     Sonderzeichenübersicht:

      Bedeutung:          Zeichen in Novell DOS 7 Kernel-Version:

                          U        F         S          I         G        J

      Ja-Zeichen          <Y>      <O>       <S>        <S>       <J>      ?
      Nein-Zeichen        <N>      <N>       <N>        <N>       <N>      ?
      Datei-Zeichen       <F>      <F>       <A>        <F>       <D>      ?
      Verzeichnis-Zeichen <D>      <R>       <D>        <D>       <V>      ?
      Abbruch             <A>      <A>       <A>        <A>       <A>      ?
      Wiederholen         <R>      <R>       <R>        <R>       <W>      ?
      Ignorieren          <I>      <I>       <I>        <I>       <I>      ?
      Fehler              <F>      <T>       <F>        <F>       <F>      ?

      "nicht"             not       ?        no         non       nicht    ?
      "Frei"             Free     Libre     Libre      Libera     Frei     ?
      "aktiviert"     enabled    activée   activada   attivata   aktiviert ?
      "deaktiviert"  disabled désactivée desactivada disattivata inaktiviert
      %NWLanguage%    ENGLISH  FRANCAIS    ESPANOL    ITALIANO   DEUTSCH \ ?
                                                                 \ NIHON[GO]

      (außer Konkurrenz: %NWLanguage% PORTUGUE[SE])

     Wie findet man die passenden Schlüsselworte heraus? Einfach die
     landessprachlichen Updates besorgen (siehe Kapitel I.2.) und die
     Dateien (insb. COMMAND.COM) unter sprachlichen Gesichtspunkten
     miteinander vergleichen. Dabei kann ein Batchjob wie im folgenden
     Beispiel nützlich sein:

      GETD70.BAT:

       @ECHO off
       ECHO GETD70 V1.01 - Get file from all Novell DOS 7 localized updates
       ECHO Syntax: GETD70 file_from_all_updates
       ECHO         Each floppy may only contain one update release!
       REM 96-04-03 -mp
       IF ""=="%1" GOTO end
       PAUSE Insert US update in floppy drive A:
       FOR %%x IN (A:D70U*.*) DO %%x -x -s %1
       REN %1 U%1
       PAUSE Insert German update in floppy drive A:
       FOR %%x IN (A:D70G*.*) DO %%x -x -s %1
       REN %1 G%1
       PAUSE Insert French update in floppy drive A:
       FOR %%x IN (A:D70F*.*) DO %%x -x -s %1
       REN %1 F%1
       PAUSE Insert Italian update in floppy drive A:
       FOR %%x IN (A:D70I*.*) DO %%x -x -s %1
       REN %1 I%1
       PAUSE Insert Spanish update in floppy drive A:
       FOR %%x IN (A:D70S*.*) DO %%x -x -s %1
       REN %1 S%1
       :end

     Bezüglich der Realisierung von Batchjobs, die bestimmte Schlüsselworte
     in Bildschirmmeldungen erkennen müssen und trotzdem auf landessprach-
     liche Besonderheiten eingehen, sei auf MEM.BAT aus Kapitel IV.5. ver-
     wiesen.

     Unglücklicherweise gibt es bei den landessprachlich unterschiedlichen
     Buchstaben einige Überschneidungen, wie etwa bei der Unterscheidung
     zwischen Datei oder Verzeichnis (Im Deutschen steht D für <D>atei, im
     Englischen für Verzeichnis=<D>irectory). U.U. ist es möglich, die
     Reihenfolge der umgeleiteten Sequenzen so anzuordnen, daß trotzdem
     immer der richtige Buchstabe akzeptiert wird (siehe bei MOVE.EXE in
     Kapitel II.4.), aber manchmal hilft nur die explizite Unterscheidung
     der Kernel-Version. Achtung: Der Alternativ-Kommandoprozessor 4DOS.COM
     existiert meines Wissens nur in einer englischen Version und verwendet
     demnach ausschließlich die Buchstaben der US-Version, die Lizenz-
     version NDOS.COM von den Norton Utilities ist jedoch der jeweiligen
     Sprache angepaßt (d.h. die deutsche Version verwendet die gleichen
     Buchstaben, wie die deutsche COMMAND.COM Version)!

     Dafür verwendet man am besten einen Batchjob, der für jedes in Frage
     kommende Zeichen eine entsprechende Umgebungsvariable mit dem
     passenden Buchstaben belegt. Weiterhin darf man in allen Batchjobs nur
     mit diesen Variablen statt der konkreten Werte arbeiten. In Anlehnung
     an Novell DOS YESCHAR= Direktive schlage ich dafür die folgenden
     Namen vor (je mehr sich daran halten, desto eher kann etwas wie ein
     globaler Standard etabliert werden):

      %yeschar%, %nochar%, %filechar%, %dirchar%, %abortchar%, %retrychar%,
      %ignorechar%, %failchar%, %switchar% (siehe SWC.BAT und MEM.BAT).

     Das Problem besteht nun noch darin, die installierte Kernel-Version
     herauszufinden. Das folgende Beispiel zeigt die einfachste Lösung, die
     nur mit Mitteln der Batch-Sprache auskommt, siehe auch Kapitel IV.7.
     Erweiterungen dieser Methode können in einem Praxisbeispiel in Kapitel
     IV.5. beim Batchjob MEM.BAT studiert werden.
     Die in den einzelnen Kernel-Versionen möglichen Werte für die Pseudo-
     Umgebungsvariablen (Systeminformationskonstanten) %Greeting_Time%,
     %Month_Name% und %Day_Of_Week% sind in Kapitel IV.7. zu finden.
     Achtung:
     Falls Sie 4DOS/NDOS.COM verwenden, müssen Sie dieses Beispiel noch
     passend erweitern, denn einerseits muß dann bezüglich der Sprache
     zwischen internen und externen Kommandos unterschieden werden und
     andererseits existieren von 4DOS.COM nur englische, von NDOS.COM aber
     landessprachlich angepaßte Varianten.
     U.U. können Sie - wie in MEM.BAT - den Hilfsschirm eines externen
     Kommandos per FIND nach bestimmten Wörtern durchsuchen lassen, um die
     Sprache der externen DOS-Utilities festzustellen. Die Sprache der
     COMMAND.COM internen Befehle kann auf die gleiche Weise z.B. mit
     COMMAND /? ermittelt werden, bezüglich der Sprachbestimmung von
     4DOS/NDOS.COM sei auf 4DOSTIP.TXT verwiesen.

     Ein unvollständiges Beispiel:

      ...
      REM Check for Novell DOS 7 kernel localization (not with 4DOS/NDOS)...
      FOR %%x IN (morning afternoon evening) DO IF ...
                                          ..."%%x"=="%Greeting_Time%" GOTO U
      FOR %%x IN (Bonjour Bonsoir) DO IF "%%x"=="%Greeting_Time%" GOTO F
      FOR %%x IN (mańana tarde noche) DO IF "%%x"=="%Greeting_Time%" GOTO S
      FOR %%x IN (giorno pomeriggio sera) DO ...
                                      ... IF "%%x"=="%Greeting_Time%" GOTO I
      FOR %%x IN (Morgen Tag Abend) DO IF "%%x"=="%Greeting_Time%" GOTO G
      REM FOR %%x IN (xxxx xxxx xxxx) DO IF "%%x"=="%Greeting_Time%" GOTO J
      REM [insert other decisions here]
      IF "4"=="%@Eval[2 + 2]%" IF NOT ""=="%_4Ver%" GOTO U
      REM IF "4"=="%@Eval[2 + 2]%" IF NOT ""=="%_NVer%" GOTO ...
      ...
      :U
      SET yeschar=Y
      SET nochar=N
      SET filechar=F
      SET dirchar=D
      GOTO continue
      :F
      ...
      GOTO continue
      :S
      ...
      GOTO continue
      :I
      ...
      GOTO continue
      :G
      SET yeschar=J
      SET nochar=N
      SET filechar=D
      SET dirchar=V
      GOTO continue
      REM :J ...
      :continue
      ...

     Weitere Probleme in internationalen Batchjobs können deshalb auf-
     treten, weil sich bei Novell DOS natürlich die Datums- und Zeit-
     formate aller DOS-Kommandos (DATE, TIME, UNDELETE, DELPURGE, um nur
     einige Beispiele zu nennen) an das per COUNTRY= eingestellte Land
     anpassen, wobei hier zwar die Separatoren in Grenzen wahlfrei bleiben,
     das Datumsformat (Reihenfolge von Tag, Monat und Jahr) aber jeweils
     korrekt angegeben werden muß. Ähnliches gilt für die Sortierreihen-
     folge von Zeichen, etwa bei SORT.

                                                                             
  ---------------------------------------------------------------------------

  II.17. Zögerlicher Platten-/Diskettenzugriff unter Novell DOS/DR DOS:
  ========================================================[97-04-06]===

   Stichworte: Disk-Deblocking, DEBLOCK=, SCSI, Busmaster-DMA, DBLBUF.SYS,
               Floppy-Zugriff, PROMPT.

   Warum Novell DOS/DR DOS beim Festplattenzugriff (ohne Cache-Programme
   wie NWCACHE und ohne große BUFFERS= Einstellungen) zögerlicher als MS-DOS
   erscheint, kann verschiedene Gründe haben.

   Für DR DOS 6.0 galt (laut einem Infopaper 1205.TXT) jedenfalls, daß
   jeder Laufwerkszugriff, der von einem hochgeladenen Programm stammte,
   über einen Zwischenpuffer im konventionellen Speicher gepuffert wurde.
   Diese zusätzliche Kopiermaßnahme kostete natürlich Zeit, allerdings gab
   es dafür auch keine Probleme mit Busmaster-DMA-Zugriffen (etwa bei den
   meisten PS/2) und einigen älteren SCSI-Festplatten (die noch kein VDS -
   Virtual DMA Specification unterstützten). Für Novell DOS 7 gilt diese
   Tatsache ebenfalls. Allerdings wurden verschiedene Möglichkeiten
   geschaffen, diesen vermeintlichen Geschwindigkeitsnachteil auszubügeln:

   Einerseits kann jetzt offenbar mit der undokumentierten CONFIG.SYS
   Direktive DEBLOCK= ein Grenzwert für das direkte oder gepufferte
   Schreiben eingestellt werden (der früher bei A000h, in aktuellen
   Novell DOS Versionen aber bei FFFFh liegt, d.h. 'außer Kraft' gesetzt
   ist), oder zumindest die Art und Weise dieses Zugriffs beeinflußt werden.
   Niedrigere Werte gehen zu Lasten der Performance. Näheres zu dieser
   Direktive in Kapitel III.1.

   Andererseits gibt es für problematische Kombinationen von Mainboard/Bus/
   BIOS/Festplatte/Online-Festplattenkompressor einen speziellen Doppel-
   pufferungstreiber DBLBUF.SYS, der bei Bedarf explizit geladen werden
   kann (dieser Treiber existierte auch schon bei DR DOS 6.0). Dies geht
   natürlich zu Lasten der Performance. DBLBUF.SYS muß in CONFIG.SYS nach
   jedem in Frage kommenden Laufwerk geladen werden, darf natürlich nicht
   hochgeladen werden und belegt ca. 2 KByte. (Allerdings ist mir ein Fall
   bekannt, wo NWCACHE auf einem 286 mit lediglich 640KByte mit STACKER
   trotz gefordertem und installiertem DBLBUF.SYS nicht aktiviert werden
   konnte.)

   Um den Floppy-Zugriff - besonders auf langsamen Rechnern - zu beschleu-
   nigen, sollten Sie den Wert für Look-ahead-Buffer (der undokumentierte
   zweite Parameter ss der CONFIG.SYS Direktiven BUFFERS=nn,ss bzw.
   HIBUFFERS=nn,ss) erhöhen, siehe Kapitel III.1.

   Auch ist der Floppy-Zugriff bei Novell DOS/DR DOS nur scheinbar
   langsamer, da im Gegensatz zu MS-DOS beim ersten Zugriff auf das
   Medium diverse Daten (Verzeichnis und FAT) direkt eingelesen werden,
   die den späteren Zugriff dann schneller machen (diesen Unterschied
   zwischen MS-DOS und Novell DOS/DR DOS wird der eine oder andere
   sicherlich schon an den Prompt-Ausgaben bemerkt haben, wenn er mit
   einem PROMPT $p$g Pfad auf Floppies gearbeitet hat).

   In Verbindung mit alten Rechnern/BIOSen kann auch der Lesezugriff auf ein
   oder mehrere Laufwerke sehr langsam sein. Dies liegt dann daran, daß das
   BIOS veraltet ist und nicht alle heute üblichen Funktionen unterstützt.
   In diesem Fall hilft es (sowohl bei Novell DOS 7, als auch bei DR DOS,
   vielleicht auch bei MS-DOS) für das jeweilige Laufwerk in CONFIG.SYS den
   BIOS-Treiber mit

    DEVICE[HIGH]=DRIVER.SYS parameter

   zu überladen (bzw. zu ergänzen, evtl. reicht dafür auch schon DRIVPARM=).
   Da das alte Laufwerk <old_drive> mit neuen Parametern nun aber über
   einen neuen Laufwerksbuchstaben <new_drive> bereitgestellt wird (nicht
   bei DRIVPARAM=), kann man die Zuordnung danach mit

    ASSIGN old_drive=new_drive

   wieder auf den alten Laufwerksbuchstaben zurückbiegen.
   Statt DRIVER.SYS kann evtl. auch ein anderer Fremdtreiber wie Ciriaco
   Garía de Celis' 2M-XBIOS.EXE, 2M-ABIOS.EXE oder Ontracks Drive-Rocket
   oder Disk-Manager ausreichen, die ebenfalls das System-BIOS ergänzen
   oder ersetzen können.

   Bzgl. weiterer Hinweise in Verbindung mit der ebenfalls (stark)
   performance-fressenden VERIFY ON Einstellung siehe Kapitel II.14.
   Hinweise zu Performance-Problemen bei CD-ROMs siehe Kapitel II.3.

                                                                             
  ---------------------------------------------------------------------------

  II.18. Mit STACKER Hauptspeicher 'virtuell' verdoppeln... [96-04-14]
  ====================================================================

   Stichworte: STACKER, NWCACHE, VDISK, RAM-Disk

   Im letzten Jahr (1995-1996) ist viel über sog. RAM-Verdoppler-Software
   geschrieben worden. Dabei wurde deutlich, daß nichts über wirklich
   vorhandenen Hauptspeicher geht und daß 'RAM-Verdopplung' durch Online-
   Kompression immer nur eine Notlösung bleiben wird (die unter MS Windows
   3.xx manchmal etwas bringt, meist aber nicht effizient ist). Besonders
   hervorgehoben sei der unglaubliche weltweite Skandal um das inzwischen
   wohl wieder vom Markt verschwundene 'Produkt' SoftRAM, das - nach c't und
   anderen Informationsquellen - in erster Linie ein teurer Dummy ist/war.

   In Einzelfällen kann sich der Einsatz eines RAM-Verdopplers trotzdem
   lohnen, besonders wenn die folgenden Voraussetzungen gelten:

   - Die Software muß man nicht mehr extra bezahlen ;-)
   - Für die Einrichtung wird kein (oder nur minimal mehr) Speicher
     im ersten MegaByte benötigt.
   - Es geht nicht um Ausführungsgeschwindigkeit, sondern um:
     "Trotz akuter Speichernot an allen Ecken und Enden überhaupt noch
      einigermaßen arbeiten können".

   Wenn Sie Novell DOS 7 einsetzen, STACKER bereits installiert haben,
   eine RAM-Disk (wie z.B. VDISK) oder einen STACKER-kompatiblen Cache wie
   NWCACHE eingerichtet haben, könnten sich die folgenden Überlegungen
   lohnen. Wenn Sie STACKER nur zu diesem Zweck installieren, lohnt sich
   das Ganze mit Sicherheit nicht...

   STACKER komprimiert Laufwerke durchschnittlich auf 1:2, d.h. im Mittel
   passen doppelt soviele Daten auf ein STACKER-Volume, wie auf ein
   normales unkomprimiertes Laufwerk. Dadurch wird 'virtuell' auch der auf
   ein komprimiertes Volume verwendete Cache (mit NWCACHE ist das möglich)
   verdoppelt (nicht der für das Host-Laufwerk).

   Da RAM-Disks wie VDISK, RAMDRIVE oder TDSK ebenfalls von STACKER
   komprimiert werden können, kann auf diese Weise auch die theoretische
   Größe von RAM-Disks verdoppelt werden (oder mit anderen Worten: Es
   wird nur halb soviel XMS-Speicher für die RAM-Disk benötigt, wie an Daten
   drauf paßt). Natürlich lohnt sich die ganze Sache erst, wenn dies den
   Verlust, STACKER nun auch noch im Speicher unterbringen zu müssen, auf-
   wiegt. Bei Computern ist es jedoch häufig möglich, mit viel Fleiß und
   durch Opfern einiger kleiner Heiligtümer an anderer Stelle enorm viel
   herauszukitzeln.
   Da RAM-Disks per sé extrem schnell sind, macht sich der Geschwindigkeits-
   verlust für die Kompression zwar stark bemerkbar, die Gesamtzeit ist aber
   generell noch kurz; bei langsamen (Harddisk-)Laufwerken kann auf recht
   schnellen Rechnern sogar ein Geschwindigkeitszuwachs entstehen, wenn die
   Kompressionszeit kürzer ist als die Zeit, die für die Speicherung der
   Mehrdaten benötigt würde.

                                                                             
  ---------------------------------------------------------------------------

  II.19. Einstellungen in Novell DOS 7 .INI-Dateien [97-02-24]
  ============================================================

   Stichworte: NWDOS.INI, [COLORS]

   In Zukunft wird diese Rubrik die Einstellungsmöglichkeiten der
   einzelnen .INI- und .CFG-Konfigurationsdateien von Novell DOS 7 be-
   handeln. Dabei wird in erster Linie nur auf Besonderheiten eingegangen,
   die nicht offensichtlich sind oder nicht dokumentiert wurden.

   Derzeit ist hier nur die [COLORS] Rubrik beschrieben, wie sie in
   %NWDOSCFG%\NWDOS.INI vorkommen kann. Die gleichen Einstellungen sind
   auch in den undokumentierten Konfigurationsdateien %NWDOSCFG%\COLORS.INI
   (bei PNW NET.EXE, falls %NWDOSCFG%\NWDOS.INI nicht existiert) oder
   C:\NWDOS\DOS.INI (für LOCK.EXE) möglich. Siehe auch Kapitel II.4.

   %NWDOSCFG%\NWDOS.INI:

    [COLORS]

    # Enthält globale Einstellungen, soweit nicht von anderen Gruppen
    # übersteuert.
    # Die hier definierten Farben sind Werte von IBM PC Video-Attributen.
    # Auf EGA oder VGA im Farbmodus können alle Farben (0-F) für den
    # Hintergrund verwendet werden. Mit anderen Video-Karten können nur 0-7
    # verwendet werden.
    #
    # 0 = Schwarz             8 = Dunkelgrau
    # 1 = Blau                9 = Hellblau
    # 2 = Grün               10 = Hellgrün
    # 3 = Zyan (Türkis)      11 = Hellzyan (Helltürkis)
    # 4 = Rot                12 = Hellrot
    # 5 = Magenta (Lila)     13 = Hellmagenta (Rosa)
    # 6 = Braun              14 = Gelb
    # 7 = Weiß (Hellgrau)    15 = Intensives Weiß
    #
    # Es können maximal 10 Farbpaletten definiert werden (ColorSet0= bis
    # ColorSet9=). Die Default-Farbpalette kann mit CurrentColor= angegeben
    # werden. [COLORS] CurrentColor= kann (bei fast allen Programmen mit
    # eigenen Gruppen) durch eine lokale CurrentColor= Einstellung über-
    # steuert werden.
    #
    # Die Definition der Farbpaletten unterscheidet sich erheblich zwischen
    # den einzelnen .INI-Dateien (TASKMGR.INI, TASKMAX.INI und VIEWMAX.INI
    # verwenden eine völlig andere Syntax innerhalb der ColorSetX=
    # Direktiven, das Prinzip bleibt jedoch gleich). Hier, in NWDOS.INI,
    # werden die Paletten jeweils mit einer Definition des Namens (in
    # Anführungszeichen) plus 13 jeweils geklammerten Sets mit (Vordergrund-
    # farbe, Hintergrundfarbe) definiert.
    # Dabei sind offenbar nur Dezimalzahlen erlaubt. Bei Syntax-Fehlern wird
    # entweder der Rest der Zeile ignoriert oder es wird die interne
    # Default-Palette gewählt (die der "Standard"-Definition entspricht).
    # Werden nicht alle Sets angegeben, wird für die restlichen offenbar
    # die interne Default-Einstellung (entspr. "Standard" belassen).
    # Kommanta und Leerfelder zwischen den Sets sind optional, sollten aber
    # bis auf die Kommata in den Sets weggelassen werden, da es sein kann,
    # daß das SETUP-Programm sonst nicht damit zurecht kommt.
    #
    # Die Sets im Einzelnen:
    #
    # SetNr: Bedeutung:
    #    1 = Farbe des Haupttextes, auch in eingeblendeten Fenstern
    #    2 = Titelleiste des aktiven Fensters
    #    3 = Titelleiste eines nicht aktiven Fensters
    #    4 = Farbe der Menütexte und Statuszeile und des seitlichen
    #        Scroll-Balkens, Warnungen
    #    5 = Vordergrund=Farbe des Button-Randes und Schatten,
    #        Hintergrund=Farbe des Button-Umrandungsfeld
    #    6 = Eingaben in Menüs, Farbe der Angaben in Auswahlmasken,
    #        Verbatim-Texte in Hilfe (Beispiele)
    #    7 = Gewählter, hervorgehobener Menüpunkt
    #    8 = Nicht aktives Menü im Hintergrund
    #    9 = Hotkey-Buchstaben in den Menüs (für <Alt>+Buchstabe)
    #   10 = Links im Hilfetext (Querverweise)
    #   11 = PopUps im Hilfetext (für Kurzerläuterungen)
    #   12 = Highlights im Hilfetext (ohne sonstige Funktion)
    #   13 = DOSBOOK Kommando

    NewUI=On                        # Pseudographische Oberfläche (ON|OFF)
                                    # Default ist On, solange die Dar-
                                    # stellung möglich ist (EGA, VGA, kein
                                    # MEMMAX +V).
                                    # Falls dies nicht möglich ist, wird Off
                                    # gewählt, auch wenn hier On angegeben
                                    # wurde.
                                    # Einige Cirrus-VGA-Adapter haben
                                    # Probleme mit der pseudographischen
                                    # Darstellung. In diesem Fall sollten
                                    # Sie global NewUI=Off wählen.

    MaxColors       = 10            # Anzahl definierter Farbsets
    CurrentColor    = 0             # Aktuelle Palettennummer aus ColorSetX
                                    # Falls nicht definiert, wird die
                                    # applikationsinterne Einstellung ge-
                                    # wählt, die "Standard" entspricht.
    ColorSet0       = "Standard"   (0,15)(15,1)(15,8)(15,4)(0,15)(0,7) ...
                               ... (15,3)(3,7)(4,7)(12,15)(3,15)(9,15)(2,15)
    ColorSet1       = "Monochrom" ...
    ColorSet2       = "LCD"       ...
    ColorSet3       = "Meer"      ...
    ColorSet4       = "Wiese"     ...
    ColorSet5       = "Sonnig"    ...
    ColorSet6       = "Rosa"      ...
    ColorSet7       = "Kohle"     ...
    #ColorSet8      = "Plasma"    ...
    # Zwei selbstdefinierte ergonomische, da flimmerfreie Farbpaletten
    # (nicht geeignet für Graustufenmonitore):
    # "EditMP" empfindet die Einstellungen der Borland IDE-Editore nach
    #          und ist damit z.B. für die EDIT-Gruppe [EDITOR] gut geeignet.
    # "HelpMP" empfindet die Farben des 4DOS/NDOS-Hilfemenüs nach
    #          und ist eine sehr angenehme Einstellung für [DOSBOOK]
    ColorSet8       = "EditMP"     (14,1)(15,8)(15,1)(15,4)(0,1)(0,7) ...
                                ... (15,3)(3,7)(4,7)(15,1)(10,1)(12,1)(2,15)
    ColorSet9       = "HelpMP"     (0,2)(15,7)(15,8)(15,4)(0,2)(0,7) ...
                                 ... (15,0)(8,7)(4,7)(14,2)(6,2)(15,2)(2,15)

    # Nun folgen Einstellungen, die nur für die einzelnen Anwendungen
    # gelten. Meist heißt die Gruppe genauso wie das jeweilige Programm,
    # es gibt aber Ausnahmen. Innerhalb der Rubriken ist fast immer
    # CurrentColor= und NewUI= möglich (undokumentiert). Siehe Kapitel II.4.
    ...

                                                                             
  ---------------------------------------------------------------------------

  II.20. Nicht erlaubte Zeichen in Dateinamen: [97-05-13]
  =======================================================

   Stichworte: Semikolon, Klammeraffe, Ausrufezeichen, Bindestrich, Umlaute

   Wie Sie sicherlich wissen, sind nicht alle Zeichen in Dateinamen
   erlaubt. Die jeweils erlaubten Zeichen hängen auch von der DOS-Version
   ab. Hier soll - zunächst noch unvollständig - auf einige Besonderheiten
   eingegangen werden:

   Zeichen:   Name:              Bemerkung:

   ;          Semikolon          Dieses Zeichen ist grundsätzlich in
                                 keiner DOS-Version innerhalb von Datei-
                                 namen erlaubt (im FAT-Dateisystem). Bei
                                 den Betriebssystemen der DR-Familie wird
                                 es von jeher zur Einleitung von Paßwörtern,
                                 bei 4DOS/NDOS für Einschlußlisten ver-
                                 wendet, siehe Kapitel II.9.

   @          Klammeraffe, 'at'  Dieses Zeichen ist zwar auch innerhalb
                                 von Dateinamen gültig, die Benutzung
                                 sollte aber vermieden werden, weil es
                                 sonst zu unnötigen Schwierigkeiten mit
                                 Kommandos kommen könnte, die Listendateien
                                 unterstützen, siehe Kapitel II.9.

   !          Ausrufezeichen     Dieses Zeichen ist üblicherweise als
                                 gültiges Zeichen in Dateinamen erlaubt,
                                 sollte aber trotzdem vermieden werden,
                                 weil es unter CCI Multiuser DOS nicht
                                 erlaubt ist. Dort dient es dem Kommando-
                                 zeileninterpreter als Trenner zwischen
                                 mehreren Kommandos in einer Zeile, wie
                                 dies intern auch bei Novells COMMAND.COM
                                 realisiert ist, siehe Kapitel II.4. bei
                                 DOSKEY.EXE.

   -          Bindestrich        Der Bindestrich '-' ist zwar auch ein
                                 gültiges und recht häufig verwendetes
                                 Zeichen, sollte aber möglichst nicht
                                 verwendet werden, da er mit dem ISO-9660
                                 Standard (von CD-ROMs) kollidiert, weshalb
                                 er von CD-Writer-Software oft durch einen
                                 Unterstrich '_' ersetzt wird.

   ÄÖÜäöüß    Umlaute und 'sz'   Viele Sonderzeichen und Umlaute sind zwar
                                 gültige Zeichen für Dateinamen, sollten
                                 aber aus verschiedenen Gründen vermieden
                                 werden, weil es beim Betrieb im Netz,
                                 bei der Umstellung auf lange Dateinamen
                                 (VFAT) oder bei falschen Landeseinstel-
                                 lungen Probleme mit dem Zugriff auf be-
                                 stimmte Zeichen geben kann, die z.B. in
                                 anderen Ländern nicht direkt über die
                                 Tastatur erreichbar sind, die in anderen
                                 Zeichensätzen durch völlig kryptische
                                 Zeichen ersetzt werden, usw. Siehe auch in
                                 Kapitel VI.7.

   ' '        Leerfeld           Zwar waren Leerfelder (auch schon lange vor
                                 Einführung von MS Windows95 Long-Filenames)
                                 auf API-Ebene durchaus gültige Zeichen in
                                 Dateinamen (wie Novells COMMAND.COM mit MD
                                 und RD beweist, siehe Kapitel II.11.), sie
                                 sollten aber trotzdem nicht verwendet
                                 werden, da die meisten Anwendungsprogramme
                                 und auch der Kommandointerpreter in der
                                 Regel nicht damit klar kommen.

                                                                             
  ---------------------------------------------------------------------------

  II.21. Physik der Verzeichniseinträge unter Novell DOS: [97-04-29]
  ==================================================================

   Stichworte: DELWATCH, UNDELETE, PASSWORD, DR DOS 6.0 Owner-IDs,
               IBM OS/2 EA-Handles, MS Chicago, MS Windows95 LFN-Support

   Entgegen landläufiger Meinung ist Microsofts LFN-Support keineswegs
   so ganz kompatibel in das bisherige FAT-Konzept integriert worden,
   wie dies in der Literatur gerne beschrieben wird. Nicht zuletzt solche
   Punkte aus meiner Sicht unfairer Machenschaften haben im Endeffekt
   zur Einstellung der Weiterentwicklung von Novell DOS 7 geführt.
   Glücklicherweise sinnt man bei Caldera schon über Lösungen für
   diese Probleme.

   Zum Beispiel existieren seit MS Windows95 einige Inkompatibilitäten
   mit speziellen, in das FAT-System integrierten Fähigkeiten, die die
   ehemalige Konkurrenz "DR DOS" spätestens seit Version 3.40 (von 1987)
   bot, und die jetzt zu unnötigen Schwierigkeiten bei der Weiterentwicklung
   von Calderas OpenDOS führen. Wie man unschwer aus der unten aufgeführten
   Abbildung ableiten kann, hätte Microsoft durchaus - und das ohne
   Performance-Einbußen - mit einem etwas besseren Design bei der
   Verwendung dieser bereits anderweitig belegten Bereiche eine Koexistenz
   der Funktionen der "DR DOS"-Familie mit denen von MS Windows95 erreichen
   können. Zur eindeutigen Unterscheidung der unterschiedlichen Belegungs-
   varianten hätte man z.B. eine andere Bit-Belegung der LFN-Sequenznummer
   in Verbindung mit dem Typ-Info-Byte benutzen können, schließlich mußten
   ja für Windows95 die Festplatten-Utilities sowieso angepaßt werden;
   stattdessen muß jetzt ein alternatives Betriebssystem geändert werden,
   um weiterhin kompatibel zu FAT zu bleiben. Oder man hätte die neuen
   Informationen auch ganz in den ja sowieso zusätzlich benötigten Ver-
   zeichniseinträgen für LFNs unterbringen können.

   Um Programmierer, die Microsofts LFN-Features ausnutzen wollen und
   trotzdem - soweit wie dies jetzt überhaupt noch möglich ist -
   Kompatibilität zur DR DOS Familie wahren wollen, von der wirklichen
   Belegung dieser Strukturen in Kenntnis zu setzen, hier eine Übersicht
   der Belegung der Verzeichniseinträge. Weitere Detailinformationen
   zur Löschverfolgung (DELWATCH.EXE, UNDELETE.EXE) sowie zum Paßwort-
   schutz (PASSWORD.EXE) finden sich in den jeweiligen Abschnitten in
   Kapitel II.4.

   Ernsthaft kollidierende Doppelbelegungen sind mit '!!!' bei dem
   jeweils zuletzt veröffentlichten Betriebssystem gekennzeichnet.


    +-------------------------------+-----------+---+---+---+-------+
    |                               |           |   |   |Del|       |
    |                               |           |   |   |Chr|Paßwort|
    |             Name              |Erweiterung|Att|Typ| / |   /   |
    |         (8 Zeichen)           |(3 Zeichen)|   |   |Mil|Create-|
    |                               |           |   |   |Sek| Zeit  |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh

      |                                           |   |   |     |
      |    In der DELWATCH-Löschverfolgung      --+   |   |     |
      |    stehende Dateien haben zusätzlich      |   |   |     |
      |    das Volume-Attribut gesetzt, was mit   |   |   |     |
      |    Windows95 LFN-Einträgen kollidiert.    |   |   |     |
      |                                           |   |   |     |
      |    Paßwortgeschützte Dateien oder Ver-  --+   |   |     |
      |    zeichnisse haben ein gesetztes Hidden- |   |   |     |
      |    Attribut, werden aber ganz normal an-  |   |   |     |
      |    gezeigt. Natürlich hat das Hidden-     |   |   |     |
      |    Attribut keinen Einfluß auf den        |   |   |     |
      |    Paßwortschutz.                         |   |   |     |
      |                                           |   |   |     |
      |    !!! MS Windows95: Die Attribut-      --+   |   |     |
      |    Kombination 0Fh (Read-Only + Hidden +      |   |     |
      |    System + Volume) von nun auch zur          |   |     |
      |    Kennzeichnung von LFN-Einträgen benutzt.   |   |     |
      |                                               |   |     |
      |    MS Windows95: Reserviert zur Kennzeichung -+   |     |
      |    des Typs von LFN-Einträgen, für Chicago    |   |     |
      |    waren zwei Typen definiert: LONG_NAME_COMP |   |     |
      |    (00h) und LONG_CLASS (??h). Im letzten     |   |     |
      |    Fall enthält der LFN-Eintrag Klassen-      |   |     |
      |    informationen in einem anderen Format      |   |     |
      |    (16 Bytes), ob er aber auch von Windows95  |   |     |
      |    benutzt wird, ist nicht geklärt. Üblich    |   |     |
      |    ist jedenfalls 00h.                        |   |     |
      |                                               |   |     |
      |    !!! Dieses Byte wird wahrscheinlich in    -+   |     |
      |    Zukunft von OpenDOS benutzt werden werden,     |     |
      |    um trotz der jetzt bestehenden Konfusion       |     |
      |    in Zukunft wieder Kompatibilität inklusive     |     |
      |    eigenem LFN-Support (und mehr) zu integrieren. |     |
      |    Default ist 00h.                               |     |
      |                                                   |     |
      |    Normalerweise 00h. Ab Novell DOS 7 enthält   --+     |
      |    dieses Feld den ersten Buchstaben eines Datei- |     |
      |    namens nach dem Löschen, der so von UNDELETE   |     |
      |    automatisch wiederhergestellt werden kann.     |     |
      |    Wurde eine Datei mit DELPURGE aus der          |     |
      |    Löschverfolgung entfernt, so steht hier der    |     |
      |    Wert E5h, der UNDELETE daran hindert, die      |     |
      |    Datei auf herkömmliche Art wieder zu ent-      |     |
      |    löschen. Setzt man dies manuell auf 00h zurück,|     |
      |    ist die konventionelle Entlöschmethode möglich.|     |
      |                                                   |     |
      |    !!! MS Windows95: Millisekunden der Datei-   --+     |
      |    erzeugung (10 Millisekunden-Raster). Bei             |
      |    LFN-Einträgen enthält dieses Feld die Prüf-          |
      |    summe für den Eintrag des alten Dateinamens.         |
      |                                                         |
      |    Bei DR DOS, Multiuser DOS, Novell DOS und Caldera  --+
      |    OpenDOS steht hier 0000h für ungeschützte Einträge   |
      |    bzw. ein unidirektional verschlüsseltes Datei- bzw.  |
      |    Verzeichnispaßwort.                                  |
      |                                                         |
      |    !!! MS Windows95: Zeit der Dateierzeugung          --+
      |
      +--- Erstes Zeichen einer gelöschten Datei, normalerweise E5h,
      |    bei DELWATCH von DR DOS 6.0, Novell DOS 7 und Caldera
      |    OpenDOS 7.01 jedoch 05h, solange die Datei in der Lösch-
      |    verfolgung steht.
      |
      +--- !!! MS Windows95: Enthält bei LFN-Einträgen die
           Sequenz-Nummer des Verzeichniseintrags in Bits 0-4 (Eins-basiert)
           und im letzten Eintrag ist Bit 6 als Endmarke gesetzt.
           Damit ergeben sich die Kombinationen 01h..1Fh und 41h..5Fh,
           die sich leider nicht eindeutig von den anderen bisher
           verwendeten Werten unterscheiden lassen.

    +-------+-------+-------+-------+-------+-------+---------------+
    |Org-Del|OwnerID|Paßwort| Std-  | Std-  |       |               |
    | Zeit  |Org-Del|Rechte | Zeit  | Datum |Start- |   Dateilänge  |
    |RecSiz/|Datum /|  /    |  o.   |   o.  |Cluster|   in Bytes    |
    |Create-|Zugriff|  EA-  | Del-  | Del-  |       |               |
    | Datum | Datum |Handle | Zeit  | Datum |       |               |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh

        |       |       |       |       |       |
        |       |       |       +-------+       +-- MS Windows95:
        |       |       |       |               Bei LFN-Einträgen 0000h.
        |       |       |       |
        |       |       |       +-- Befindet sich eine Datei in der
        |       |       |           DELWATCH Löschverfolgung von Novell DOS
        |       |       |           oder Caldera OpenDOS 7.01 (nicht jedoch
        |       |       |           DR DOS 6.0), so steht hier das Datum
        |       |       |           und die Zeit des Löschzeitpunktes,
        |       |       |           nicht der Stempel der letzten Änderung.
        |       |       |
        |       |       +-- DR DOS, CP/M, Multiuser DOS, Novell DOS, Caldera
        |       |       |   OpenDOS: Zugriffssperren für paßwortgeschützte
        |       |       |   Dateien oder Verzeichnisse. In drei Klassen
        |       |       |   'World', 'Group' und 'Owner' gibt es jeweils
        |       |       |   vier Zugriffssperren 'Read' (01h), 'Write'
        |       |       |   (02h), 'Delete' (04h) und 'Execute' (08h).
        |       |       |   'Execute' wird derzeit nur von FlexOS verwendet
        |       |       |   und sonst wie 'Read' behandelt. Singleuser-
        |       |       |   Varianten dieser Betriebssysteme benutzen alle
        |       |       |   drei Klassen simultan (d.h. hier sind 0000h,
        |       |       |   0111h, 0555h, und 0DDDh üblich), Multiuser-
        |       |       |   Varianten je nach Ebene.
        |       |       |
        |       |       +-- CP/M: Zusätzlich werden noch die Attribute
        |       |       |   F1 'Modify default open rules' (80h),
        |       |       |   F2 'Partial close default' (40h),
        |       |       |   F3 'Ignore Close Checksum Error' (20h) und
        |       |       |   F4 'Disable Checksums' (10h) benutzt
        |       |       |
        |       |       +-- !!! (MS)/IBM OS/2: Extended-Attribut Handle
        |       |       |
        |       |       +-- ??? MS Windows95b FAT32-Partitionen: High-Word
        |       |           des Start-Clusters (reine Spekulation!!!)
        |       |
        |       +-- DR DOS 6.0, FlexOS (und Multiuser DOS???): Owner-IDs;
        |       |   dabei in 12h den Wert der User-ID, und in 13h den
        |       |   Wert der Group-ID.
        |       |
        |       +-- Novell DOS 7, Caldera OpenDOS 7.01 DELWATCH: Zwischen-
        |       |   gespeichertes Datum der letzten Änderung bei gelöschten,
        |       |   aber in der Löschverfolgung stehenden Dateien oder
        |       |   Verzeichnissen.
        |       |
        |       +-- MS Windows95: Mit ACCDATE= Last-Access-Datum
        |           Datum des letzten Zugriffs
        |
        +-- FlexOS: Record-Größe
        |
        +-- Novell DOS 7, Caldera OpenDOS 7.01 DELWATCH:  Zwischen-
        |   gespeicherte Zeit der letzten Änderung bei gelöschten, aber
        |   in der Löschverfolgung stehenden Dateien/Verzeichnissen.
        |
        +-- !!! MS Windows95: Datum der Dateierzeugung


   MS Chicago/Windows95 LFN-Einträge mit langen Dateinamen in Unicode
   (Typ LONG_NAME_COMP=00h)

    +---+---------------------------------------+---+---+---+-------+
    |   |                                       |   |   |   |       |
    |   |                                       |   |   |   | Langer|
    |LFN|    Langer Dateiname (1/3)             |Att|Typ|CRC| Datei-|
    |SNo|                                       |0Fh|00h|   | name  |
    |   |       |       |       |       |       |   |   |   | (2/3) |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh

    +---------------------------------------+-------+---------------+
    |                                       |       |               |
    |                                       |       | Langer        |
    |  Langer Dateiname (Fortsetzung 2/3)   | 0000h | Dateiname     |
    |                                       |       | (3/3)         |
    |       |       |       |       |       |       |       |       |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh


   MS Chicago LFN-Einträge mit Klasseninformationen (Typ LONG_CLASS=??h)
   (ob diese auch von MS Windows95 verwendet werden, ist nicht geklärt)

    +---+---------------------------------------+---+---+---+-------+
    |   |                                       |   |   |   |       |
    |   |                                       |   |   |   |Klassen|
    |LFN|       Klasseninformation (1/2)        |Att|Typ|CRC| info  |
    |SNo|                                       |0Fh|??h|   | (2/2) |
    |   |                                       |   |   |   |       |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh

    +---------------+-----------------------+-------+---------------+
    |               |                       |       |               |
    | Klasseninfo   |                       |       |               |
    | (Forts. 2/2)  |      Reserviert       | 0000h |  Reserviert   |
    |               |                       |       |               |
    |               |                       |       |               |
    |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |   |
    +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
    +10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh


   Einige Beta-Versionen von MS-DOS 4 benutzten ein (unbekanntes) Wort
   innerhalb dieser Strukturen, um die gewünschte Codeseite zur Anzeige
   der jeweiligen Datei unterzubringen (im Prinzip keine schlechte Idee,
   siehe INT21h/3303h, INT21h/3304h, INT21h/5703h und INT21h/5704h). In
   Release-Versionen wurde dieses Feld jedoch nie zu diesem Zweck genutzt.

   Die für den Paßwortschutz verwendeten Bereiche werden wahrscheinlich
   auch noch von heutigen Multiuser DOS-Betriebssystemen, etwa von
   CCI Multiuser DOS 7.22 oder von IMS Multiuser DOS und IMS REAL/32
   verwendet. Überprüft habe ich dies jedoch noch nicht.

   Achtung: Die inkompatibilen FAT32-Partitionen von MS Windows95b ver-
   wenden zumindest noch zwei weitere Bytes für das High-Word des Start-
   Clusters. Leider ist mir noch unbekannt, welche Bytes das sind...

                                                                             
  ###########################################################################
  ###########################################################################

  III. CONFIG.SYS:
  ================

  ---------------------------------------------------------------------------

  III.1. Undokumentierte Direktiven und Eigenschaften: [97-05-21]
  ===============================================================

   Stichworte: CONFIG.SYS, Reihenfolge, maximale Zeilenlänge, alle
               dokumentierten und undokumentierten Direktiven, besonders:
               SWITCHES=/N, NUMLOCK, YESCHAR, [COMMON], TIMEOUT, GETKEY,
               ERROR, ONERROR, BBB.

   DR DOS 6.0, Novell DOS und Caldera OpenDOS suchen vor einer evtl.
   auszuwertenden CONFIG.SYS Datei nach einer Datei namens DCONFIG.SYS
   (der Name stammt von 'Laufwerk D:', da diese Funktion in erster Linie
   für Online-Festplattenkompressoren wie STACKER etc. gedacht ist, wo
   die ursprüngliche CONFIG.SYS Datei auf Laufwerk D: statt auf Laufwerk
   C: zu finden ist). Wird eine solche Datei gefunden, so wird eine
   evtl. ebenfalls vorhandene CONFIG.SYS Datei ignoriert. (Andere
   Möglichkeiten, die Konfiguration aus einer alternativen Datei zu laden,
   finden sich bei CHAIN= oder in Kapitel II.4. bei SYS /DR:ext.)
   Bezüglich der Namenswahl ist übrigens interessant, daß Multiuser DOS
   statt CONFIG.SYS generell verwandte Datei CCONFIG.INI auswertet.

   Im Gegensatz zu MS-DOS ist bei Novell DOS die Reihenfolge der Anweisun-
   gen in der Datei CONFIG.SYS sehr wichtig. Der Parser arbeitet die Datei
   (bis auf wenige Ausnahmen wie etwa SWITCHES=) streng nach dem vorgege-
   benen Verlauf durch, d.h. beginnt in der ersten Zeile und verzweigt
   entsprechend evtl. GOSUB=, SWITCH=, CHAIN= etc. Anweisungen. (Bei MS-DOS
   gilt das im Prinzip zwar auch, aber es gibt sehr viele undokumentierte
   Ausnahmen von dieser Regel, so daß manchmal sehr seltsame Dinge pas-
   sieren, z.B. werden dort DEVICE= Befehle immer vor INSTALL= Befehlen
   ausgeführt, vgl. Kapitel III.7. und V.7.).
   Natürlich gibt es viele Direktiven, die nicht sofort wirksam werden,
   sondern erst in dem Moment, wenn der Kommandoprozessor geladen wird
   (teilweise aber auch schon bei INSTALL[HIGH]=).
   Um den generellen Unterschied zusammengefaßt zu erklären, läßt sich
   sagen, daß DR DOS und Novell DOS zur Auswertung der CONFIG.SYS einen
   echten Interpreter verwenden, MS-DOS und PC-DOS hingegen eine Art
   Pre-Compiler, wobei beides Vor- und Nachteile hat.

   Die CONFIG.SYS Datei, die auch größer als 64 KByte lang sein kann, wird
   übrigens nicht komplett auf einmal in den Speicher geladen und dort
   abgearbeitet, sondern nach und nach in einen internen 8 KByte großen
   Zwischenpuffer geladen, aus dem dann Zeile für Zeile herausgelesen wird
   (nach GOTO= und GOSUB= wird die Datei offenbar neu eingeladen). Da die
   Behandlung aber als Ganzes nicht streng zeilenweise funktioniert, ist
   trotzdem eine Art Online-Editierung (etwa INSTALL=c:\nwdos\edit.com
   c:\config.sys) ausgeschlossen. (Bei MS-DOS/PC-DOS wird die CONFIG.SYS
   Datei komplett in den Speicher geladen, andernfalls wären MS-DOS-konforme
   Boot-Menüs trotz obiger Besonderheiten in der Bearbeitungsreihenfolge
   nicht realisierbar, vgl. Kapitel III.7. und V.7.)

   Übrigens gibt es von Bert Schönwälder eine interessante Ergänzung zu
   Novells eigenen Boot-Menüs: 'Bert's Boot Box' (BBB v1.0 von 1995-1996)
   erlaubt eine übergreifende Menüauswahl mit Check-Boxen, Radiobuttons,
   etc. sowie das Auswerten von Bedingungen und das Setzen von Vorab-
   Umgebungsvariablen. Dieses Utility arbeitet als eine Art Pre-Prozessor
   für die von Novell DOS in den Speicher geladene CONFIG.SYS Datei und
   wertet zur Gestaltung seiner Menüs u.a. eine Meta-Sprache (versteckt
   in CONFIG.SYS Kommentaren) aus. Trotz der trickreichen Einbettung ins
   System ist die Benutzung leider nicht ganz frei von Einschränkungen und
   Inkompatibilitäten, z.B. darf die CONFIG.SYS nicht größer als 8 KByte
   sein, und Sprungziele dürfen nur Vorwärtsreferenzen enthalten.

   Die maximale Zeilenlänge für CONFIG.SYS Anweisungen beträgt bei
   Novell DOS 255 Zeichen, statt der sonst meist üblichen 128 oder noch
   weniger Zeichen (ältere MS-DOS Ausgaben akzeptierten nur 31 Zeichen).
   Ob alle Ihre Treiber (per DEVICE= etc.) allerdings mit solchen Über-
   längen zurecht kommen, ist fraglich. Bei der Übergabe an Treiber durch
   diese Begrenzung abgeschnittene Parameter werden ignoriert, genauso wie
   auch generell eventuell überstehende Reste von Zeilen, die selbst die
   Maximallänge von 255 Zeichen noch überschreiten.
   Natürlich werden per INSTALL= etc. geladenen Treibern nach wie vor
   maximal 127 Zeichen als Kommandozeile übergeben, ansonsten würde ja
   der Programmkopf solcher Treiber überschrieben.
   Gegenüber der Vorgängerversion (als auch gegenüber der Konkurrenz MS-DOS)
   gibt es eine Vielzahl von Verbesserungen, die unverständlicherweise zum
   größten Teil nicht oder nur sehr oberflächlich dokumentiert sind. Diese
   Erweiterungen erlauben eine äußerst flexible Handhabung von Mehrfach-
   konfigurationen und ein effektives Fehlermanagement. Auf den ersten Blick
   erscheint die Methode, mit der bei DR DOS und Novell DOS Boot-Menüs
   behandelt werden, etwas schwerfällig. Allerdings kann man schon mit den
   offiziellen Direktiven - bei entsprechender Strukturierung - mehr als nur
   alle Möglichkeiten von MS-DOS so nachbilden, daß eine AUTOEXEC.BAT für
   beide Systeme identisch aussehen könnte (besonders bezüglich der Variable
   %CONFIG%). Trotzdem hat man bei Novell DOS noch wesentlich mehr
   Flexibilität (das Sprachniveau kann man fast mit BASIC gleichsetzen
   und geht teilweise über die Möglichkeiten der Batch-Sprache hinaus!).

   Die folgenden Abschnitte werden nun alle CONFIG.SYS Direktiven be-
   leuchten, wobei allerdings nur dann ausführlich auf Besonderheiten
   eingegangen wird, wenn die Dokumentation mißverständlich, unvollständig
   oder schlichtweg nicht vorhanden ist. Ansonsten wird nur kurz die
   vollständige Syntax dargestellt.
   Frühere Versionen von DR DOS unterstützten auch noch verschiedene
   andere undokumentierte Direktiven. Mehr hierzu siehe DRDOS6UN.TXT.

   Traditionell werden CONFIG.SYS Direktiven mit einem Gleichheitszeichen
   von ihrem Wert getrennt. Mittlerweile sind aber viele Direktiven hinzu-
   gekommen, die eine bestimmte Funktion ausführen, anstatt eine Einstellung
   vorzunehmen. Das Gleichheitszeichen ist hier nicht besonders intuitiv
   und kann in Ausnahmefällen sogar kleinere Probleme bereiten (etwa bei
   ECHO[=] (Kapitel III.3.) oder YESCHAR[=]). Deshalb ist die Angabe des
   Gleichheitszeichen bei Novell DOS zwar überall möglich, aber optional.
   Dies gilt übrigens auch für die Kommandozeile und Batchjobs mit Novells
   COMMAND.COM, siehe Kapitel II.11.

   Die einzelnen Werte dürfen mit Leerfeldern, TABs oder Komma getrennt
   werden. Vor einem Wert, der ein bestimmtes ASCII-Zeichen spezifizieren
   soll, dürfen nach einem Komma keine Leerfelder folgen, sonst werden
   diese Leerfelder als das anzugebende ASCII-Zeichen interpretiert (z.B.
   bei TIMEOUT=).
   Bei Parametern, die Zeichenketten (z.B. Dateinamen oder Marken) als
   Argument erwarten, ist zusätzlich noch '/' als Trennzeichen zwischen
   den Parametern erlaubt. Normale Werte zu Parametern müssen mit ':'
   zwischen Parameter und Wert getrennt werden (etwa bei DRIVPARM=).
   Außerdem haben die Zeichen '>', '<', '|' und andere in CONFIG.SYS noch
   keine Bedeutung für Umleitungen, und können daher problemlos z.B. für
   die Gestaltung von Menüs mittels ECHO= herangezogen werden. Das gilt
   auch für die meisten anderen Zeichen. Ungültige Zeichen werden jedenfalls
   einfach ignoriert.

   Muß auf Dateien zugegriffen werden, die mit Paßwörtern geschützt sind,
   muß auch hier das Paßwort mit Semikolon getrennt angegeben werden.

   Sofern es nicht zu Mißdeutung kommen kann, sind am Ende jeder Zeile
   jeweils beliebige Kommentare erlaubt, solange sie wie normale Parameter
   von den echten Argumenten getrennt werden.


   i. Allgemeine Einstellungen:
   ----------------------------

    Direktiven, die Werte erwarten, die aber nicht angegeben werden, melden
    sich mit einer Fehlermeldung. Läßt man die Direktive jedoch komplett
    weg, arbeitet Novell DOS mit internen Default-Einstellungen. Liegt ein
    Wert außerhalb des zulässigen Wertebereichs, so wird der Wert normaler-
    weise stillschweigend auf- oder abgerundet. Nur in Einzelfällen kommt
    es zu einer Fehlermeldung. Nicht erkannte Direktiven führen ebenfalls
    zu einer Fehlermeldung. Im Verlauf der CONFIG.SYS Bearbeitung dürfen
    Direktiven durchaus auch mehrfach vorkommen, die jeweils letzte Ein-
    stellung gilt dann. Wurden dabei bei Direktiven, die die Angabe mehrerer
    Parameter erlauben, zunächst zusätzliche Parameter angegeben, bei
    späteren Vorkommen der Direktive jedoch weggelassen, bleiben die
    hierfür bereits eingestellten Werte erhalten und werden nicht wieder
    auf Default-Einstellungen zurückgesetzt.

    BREAK [=] [ON|OFF]                                                  <ON>

                   BREAK=ON macht das System geringfügig langsamer (wirklich
                   minimal, außer bei Batchjobs), ist aber trotzdem zu
                   empfehlen, damit man Programme im Fehlerfall mit
                   <Ctrl>+<c> abbrechen. Das klappt aber nicht bei allen
                   Programmen und hat noch den Nachteil, daß das Programm
                   dafür sorgen muß, daß das System wieder aufgeräumt wird.
                   Geschieht dies nicht und drückt man im falschen Moment
                   <Ctrl>+<c>, so kann es zu Abstürzen und Datenverlust
                   kommen (z.B. AUTOCAD R11). (Viele Editore etc. unter-
                   stützen die alte WordStar-Belegung aus CP/M Zeiten, dort
                   ist <Ctrl>+<c> mit <PageDown> belegt.)
                   Wenn Sie den erweiterten Tastaturtreiber K3PLUS bzw.
                   FreeKEYB (zu beziehen über mich) einsetzen, können Sie
                   problemlos "BREAK off" verwenden, denn K3PLUS bietet
                   eine Möglichkeit (sog. verschärftes <Ctrl>+<Break>),
                   diese Einstellung bei Bedarf über eine spezielle Tasten-
                   kombination umzuschalten.

                   Bezüglich des COMMAND.COM Kommandos BREAK und einer
                   Beispiellösung für Batchjobs siehe auch Kapitel II.11.

    BUFFERS [=] nn[,ss] [comments]                  nn=3..99, <3, 5 oder 15>
    HIBUFFERS [=] nn[,ss] [comments]                ss=1..99, <0>

                   Die Dokumentation erwähnt nur die Möglichkeit, Puffer nn
                   mit BUFFERS= einzurichten. Trotzdem ist es auch bei
                   Novell DOS möglich, zusätzlich noch 'Look-Ahead-Buffer',
                   d.h. die Anzahl der Sektoren ss pro Schreib/Lesean-
                   forderung anzugeben (wie von MS-DOS gewohnt). Dies wird
                   nicht nur syntaktisch akzeptiert, sondern ist auch mit
                   der entsprechenden Funktionalität versehen. Diese Angabe
                   ist optional. Standardmäßig werden werden keine 'Look-
                   Ahead-Buffer' eingerichtet, was der Einstellung ss=0
                   entsprechen würde, die allerdings syntaktisch nicht
                   akzeptiert wird. Auf langsamen Rechnern können Sie durch
                   Angabe eines Wertes für ss eine starke Beschleunigung
                   insbesondere der Floppies erreichen, auf schnelleren
                   Rechnern ist ein echter Cache wie NWCHACHE allemal
                   effektiver. Andere als die erlaubten Werte werden zurück-
                   gewiesen. (Evtl. spielt die ss Angabe auch im Zusammen-
                   hang mit DBLBUF.SYS eine Rolle???)
                   Die Default-Angabe hängt auch vom verfügbaren Speicher-
                   platz ab: Sollte Ihr System weniger als 128 KByte RAM
                   besitzen, werden nur drei Puffer eingerichtet, sonst
                   fünf, für große Platten offenbar auch 15. Puffer werden
                   nach Möglichkeit automatisch in die HMA oder den oberen
                   Speicher verlagert (DOS=HIGH,UMB), die Verwendung der
                   alten DR DOS Direktive HIBUFFERS= ist daher auf den
                   ersten Blick obsolet. Trotzdem wird diese mit gleicher
                   Syntax weiterhin unterstützt (ist allerdings nun
                   undokumentiert); die interne Bearbeitung weicht leicht
                   von BUFFERS= ab, weil hier nur 'Hi'-Puffer eingerichtet
                   werden (nach Möglichkeit in der HMA, sonst in UMBs bei
                   DOS=HIGH,UMB bzw. HIDOS=ON).

                   Ein Puffer belegt 528 Bytes (plus einige Bytes für die
                   Verwaltungsstrukturen) und kann darin 512 Bytes Daten
                   speichern. Während der CONFIG.SYS sind die vordefinierten
                   Puffer alle einzeln allokiert. Bei Änderung der Sektor-
                   zahl kann sich der Speicherbedarf jedoch vervielfachen.
                   Daher sollte man diese Angabe stark reduzieren (etwa 3
                   oder 4), sobald man mit einem Platten-Cache wie NWCACHE
                   arbeitet. Ein Cache ist nicht nur effektiver, sondern
                   die Performance wird durch zu hohe BUFFERS= Werte sogar
                   wieder gedrosselt, da erstens weniger freier Arbeits-
                   speicher verfügbar ist und zweitens eine doppelte
                   Pufferung stattfindet. Ohne Cache sind meist Werte
                   zwischen 20 und 30 angebracht.

                   Es mag einige wenige, unsauber programmierte Programme
                   geben, die die Puffer direkt ansprechen. Liegen die
                   Puffer dann in der HMA, so führt dies höchstwahrschein-
                   lich zum Absturz des Rechners, wenn die Adreßleitung A20
                   abgeschaltet sein sollte (was allerdings sehr unwahr-
                   scheinlich ist). Manche Harddisk-Controller erfordern
                   ebenfalls einen Puffer im nicht gemappten, konventio-
                   nellen Speicher, siehe auch bei DEBLOCK=. Normalerweise
                   sind keine Probleme zu erwarten.

                   Ab DR DOS 6.0 werden bei BUFFERS= zwei Parameter ausge-
                   wertet, bei DR DOS 3.4x und 5.0 wurde nur ein Parameter
                   verwendet.

                   Die mit HIBUFFERS= vergleichbare bei MS-DOS 7
                   (MS Windows95/Chicago) eingeführte Direktive BUFFERSHIGH=
                   wird von Novell DOS 7 (Update 15) nicht unterstützt, ist
                   aber - wie ersichtlich - auch überflüssig.

    COUNTRY [=] phonecode, codepage, [d:\[path]]\COUNTRY.SYS

                   Die Default-Einstellung ohne diese Angabe ist vom je-
                   weiligen Rechner und DOS abhängig, i. allg. werden
                   dann jedoch amerikanische Einstellungen gewählt
                   (was COUNTRY=1,437,C:\COUNTRY.SYS entspräche).

                   Für Deutschland sollte man deshalb

                    COUNTRY=049,437,c:\nwdos\country.sys

                   nicht vergessen. Die Angabe der beiden Codes sollte
                   dreistellig erfolgen (obwohl das bei Novell DOS nicht
                   notwendig ist). Mehr zum Thema landessprachliche
                   Unterstützung in Kapitel II.16.

                   Achtung:

                   Die Angabe der Codeseite ist im Rahmen der Auswahl der
                   in COUNTRY.SYS für das jeweilige Land zugeordneten
                   Codeseiten (üblicherweise zwei) zwar wahlfrei, sollte
                   aber die tatsächlichen Gegebenheiten zum Zeitpunkt der
                   Bearbeitung von COUNTRY= wiederspiegeln.
                   Da dies üblicherweise der Hardware-Codeseite für Anzeige
                   (Main-BIOS und Grafikkarten-BIOS) und Drucker entspricht
                   (die DOS beide nicht überprüfen kann), muß diese Angabe
                   überhaupt erst vorgenommen werden und sollte - in den
                   allermeisten Fällen (USA, West-Europa) - Codeseite 437
                   entsprechen. Sollten sich die Codeseiten von Bildschirm
                   und Drucker unterscheiden, müssen Sie sich für das be-
                   vorzugte Medium (i. allg. die Anzeige) entscheiden.
                   DOS wählt auf der Grundlage dieser Einstellung die
                   landesspezifischen Informationen aus der COUNTRY.SYS
                   Datei aus.
                   Wenn Sie später keine Codeseitenunterstützung einrichten
                   oder verwenden wollen (DISPLAY.SYS, PRINTER.SYS, MODE),
                   kann DOS für diese Geräte auch keine andere Codeseite
                   forcieren, und nimmt die mit COUNTRY= eingestellte
                   Codeseite einfach global an (z.B. auch bei CHCP), auch
                   wenn dies nicht den wirklichen Tatsachen entspricht!

                   Wenn Sie hier eine andere Codeseite als die tatsächlich
                   aktive Codeseite angeben, wird eine Synchronisation mit
                   den wirklichen Verhältnissen erst dadurch erreicht, daß
                   Sie bei aktivierter Codeseitenunterstützung mit CHCP auf
                   eine *andere* Codeseite umschalten, denn dabei werden
                   die aktivierten Geräte mit den neuen und nun stimmigen
                   Font- und Zeichensatz-Informationen versorgt.
                   Bis dahin zeigt z.B. auch MODE CODEPAGE /STATUS an,
                   daß noch keine Codeseite für das jeweilige Gerät geladen
                   wurde.
                   Die Angaben für die Hardware- und vorbereiteten Code-
                   seiten basieren hingegen auf den Einstellungen bei der
                   Installation von DISPLAY.SYS, PRINTER.SYS, MODE CODEPAGE
                   PREPARE oder werden zu 437 angenommen.

                   Dieser Sachverhalt wird in vielen Büchern falsch
                   geschildert und auch einige modernere Setup-Programme
                   (von Microsoft) installieren hier immer wieder die
                   Codeseite 850, was üblicherweise nicht korrekt oder
                   zumindest unsauber ist!
                   Viele Applikationen gestalten Ihre Ausgaben in Ab-
                   hängigkeit von der vom System zurückgelieferten
                   Codeseite, mit der Folge von unschönen Ergebnissen,
                   wenn diese Information nicht mit den Tatsachen über-
                   einstimmt.
                   Daher sollten Sie - von speziellen bewußten Täuschungs-
                   maßnahmen abgesehen - hier unbedingt die korrekte
                   Einstellung überprüfen und ggf. auf 437 umändern
                   (wenn dies der Hardware-Codeseite entspricht), auch
                   wenn Sie später mit Codeseite 850 arbeiten wollen!
                   Es gibt eigentlich keinen Grund, hier Codeseite 850
                   vorzugeben, nur weil Sie später - nach Einrichtung
                   der Codeseitenunterstützung - mit dieser Codeseite
                   arbeiten wollen. Das System bekommt diese Änderung
                   schließlich sowieso in dem Moment mit, wo Sie mit
                   CHCP auf diese Codeseite umschalten; also genau zu
                   dem Zeitpunkt, ab dem eine falsche Einstellung durch
                   Neusynchronisation korrigiert würde. Ohne aktivierte
                   Codeseitenunterstützung würde diese Diskrepanz bestehen
                   bleiben.
                   (Lediglich für den Long-Filename-Support von MS-DOS 7
                   mag es - rein theoretisch - annehmbar sein, bis zu
                   diesem Zeitpunkt quasi unter falscher Flagge zu laufen,
                   dafür aber schon während der CONFIG.SYS korrekte
                   Zuordnungstabellen zu UniCode eingestellt zu haben
                   (ob dies überhaupt daran gekoppelt ist, ist nicht
                   gesichert). Da dort aber die Codeseitenunterstützung
                   (unter dem GUI) sowieso funktionslos ist, wäre dies
                   aber auch wieder nur ein Grund mehr, bei diesem Betriebs-
                   system sofort mit CHANGECP auf die Codeseite 437 umzu-
                   konfigurieren. Für Novell DOS 7 ist diese Überlegung
                   jedenfalls ohne Belang. Bei KEYB können Sie ebenfalls
                   explizit eine Codeseite angeben.)

                   Die Angabe dieser Direktive kostet keinen zusätzlichen
                   Speicherplatz, da das System die Landesinformationen
                   sowieso bereitstellt (nur möglicherweise für das falsche
                   Land).

    FCBS [=] [mm [, nn]] [comments]  mm=0..255 <1 oder 4>,
                                     0<=nn=<=mm <0??? oder 1>

                   Diese Direktive erlaubt es, die Anzahl der System-
                   Dateisteuerblöcke (System FCBs) anzugeben, die das
                   System zur Wahrung der Kompatibilität mit Applikationen,
                   die FCBs (File Control Blocks) benutzen, reserviert.

                   FCBs werden in erster Linie für alte Programme benötigt,
                   die noch die CP/M-Dateioperationen verwenden. Trotzdem
                   sind auch heute FCBs keineswegs überflüssig und werden
                   von mehr Programmen verwendet, als man glaubt...

                   Früher stand durch die Benutzung von FCBs, die ja
                   bekanntermaßen innerhalb der sie benutzenden Anwendung
                   selbst alloziert werden, eine Möglichkeit offen, beliebig
                   viele Dateien gleichzeitig zu öffnen (genug Speicherplatz
                   vorausgesetzt). Allerdings waren bei diesem Konzept die
                   Verwaltungsstrukturen von DOS den Applikationen zu-
                   gänglich, was spätere Erweiterungen aus Kompatibilitäts-
                   gründen schwer bis unmöglich machte. Aus diesem Grunde
                   wurde mit DOS 2.0 eine Dateiverwaltung auf der Basis von
                   Handles eingeführt, die die Behandlung über FCBs ablöste.
                   Die internen Verwaltungsstrukturen sind damit vor den
                   Applikationen, die nur noch die Handles zu Gesicht
                   bekommen, gekapselt, was Raum für Erweiterungen schafft.
                   Nachteilig an der neuen Methode ist, daß das Betriebs-
                   system von vornherein Speicherplatz für diese Ver-
                   waltungsstrukturen (SFT-Einträge) reservieren muß
                   (siehe FILES=), was die maximale Anzahl gleichzeitig
                   offener Dateien einschränkt. Um trotzdem die Kompatibi-
                   lität mit FCBs-nutzenden Programmen zu wahren, die
                   natürlich von den nötigen Erweiterungen der Verwaltungs-
                   strukturen auf der Basis von Handles nichts wissen
                   können und FCBs daher immer noch wie anno-dazumal
                   benutzen, war die Einführung sog. System-FCBs nötig (eben
                   vom System reserviert mit FCBS=), die der Kernel bei
                   CP/M-Dateioperationen jedesmal mit den wirklichen FCBs
                   synchronisiert, die die alte Applikation zu verwenden
                   glaubt. Das System arbeitet hingegen intern mit nur mit
                   diesen System-FCBs, die im Prinzip genauso aussehen, wie
                   die internen Verwaltungsstrukturen, die auch für Datei-
                   operationen via Handles benutzt werden. Um den Synchron-
                   isationsaufwand soweit wie möglich zu reduzieren, war
                   bei FCBS= auch die Angabe geschützter System-FCBs
                   (Protected FCBs) möglich, die das System zwischen-
                   puffert (s.u.).

                   Die Angabe des Wertes 0 ist zwar möglich, sollte aber
                   vermieden werden. Laut meiner Erfahrung ist die Default-
                   Einstellung <1,0> (Update 15), laut Dokumentation jedoch
                   <4,4>, wobei jeder Steuerblock 50 Bytes im konventio-
                   nellen Speicher benötigt (die auch mit DOS=HIGH,UMB nicht
                   ins Upper Memory verlagert werden können). Während der
                   CONFIG.SYS gilt - unabhängig von der gewählten FCBS=
                   Einstellung, die zunächst nur aufgezeichnet wird, um
                   erst nach Beendigung der CONFIG.SYS aktiv zu werden -
                   eine Einstellung, die effektiv FCBS=1,0 entspricht.

                   Bei Novell DOS ist FCBS= allerdings nur dann wirklich
                   effektiv, wenn SHARE.EXE oder eine Netzwerk-Software ge-
                   laden wird. Obwohl die Angabe nn für die geschützten FCBs
                   (Protected FCBs) optional ist, wird sie - entgegen der
                   Dokumentation - zumindest bis zur derzeitigen IBMBIO.COM
                   Version (Update 15 und Caldera OpenDOS 7.01) definitiv
                   nicht ausgewertet (und wahrscheinlich deshalb auch nicht
                   von SHARE etc.), es gibt aber in der Literatur immer
                   wieder Hinweise, daß die zweite Angabe bei DR DOS im
                   Netzbetrieb eine Auswirkung hatte (allerdings enthält
                   auch der Kernel von DR DOS 3.41-6.0 nur Code zur Aus-
                   wertung des ersten Parameters, so daß mir dies recht
                   unwahrscheinlich erscheint).
                   Die geschützten FCBs sind auch bei MS-DOS 5.0+ wegge-
                   fallen, so daß die fehlende Auswertung bei Novell DOS 7
                   nur kompatibel wäre...

                   Geschützte FCBs kosten (vermutlich) jeweils 16 Bytes
                   Speicherplatz.

                   Da die Verwaltungsstrukturen für System-FCBs und FILES=
                   intern sowieso gleich sind (s.o.), benutzen DR DOS und
                   Novell DOS FCBS= und FILES= konsequenterweise auch gleich
                   als 'Handles' und verwalten sie aus einem gemeinsamen
                   Pool, was eine effektivere Speicherauslastung zur Folge
                   hat (siehe auch MEM /A). FILES= und FCBS= können zusammen
                   maximal 255 ergeben. Diese Beschränkung ist systemgegeben
                   für DOS, kann allerdings mit einigen Tricks von NetWare-
                   Shells wie NETX, VLM umgangen werden, wenn auch nur für
                   Dateien im Netz.
                   Wegen der Zusammenfassung von FCBS= und FILES= geben
                   einige Analyseprogramme (wie etwa Quarterdecks MFT)
                   mehr FILES an, als eingestellt, dafür aber nur einen FCB.

                   Im Zusammenhang mit dem FCB-Management wurden im Laufe
                   der Zeit eine Menge Anpassungen vorgenommen, so daß sich
                   die Verwendung eines aktuellen Updates empfiehlt, falls
                   Ihre Programme FCBs benutzen. (Leider gibt es selbst mit
                   Update 15/2 noch ein paar Einschränkungen, etwa unter-
                   stützt INT21h/13h erweiterten FCBs nicht für alle
                   möglichen Attribute, so daß "PKZIP -&w" unter Novell DOS
                   und OpenDOS fehlschlägt, da PKZIP bis 2.04g ärgerlicher-
                   weise diese obsolete Methode verwendet, um ein Medium zu
                   entleeren - was auf diese Weise sowieso nur zum Teil
                   gelingen kann...).

                   Die mit MS-DOS 7 (MS Windows95/Chicago) später einge-
                   führte Direktive FCBSHIGH= wird von Novell DOS 7 (Update
                   15) nicht unterstützt. Bei Novell DOS 7 bleiben die FCBs
                   auch bei DOS=HIGH,UMB im konventionellen Speicher, was
                   bei üblichen Konfigurationen für FCBS= und FILES= ge-
                   meinsam einen 'Verlust' von 0,5 - 3,5 KByte konventio-
                   nellen Speicher bedeutet, der durch die anderen Hochlade-
                   möglichkeiten aber mehr als wett gemacht wird.
                   Andererseits besteht die Möglichkeit, sich die Utilities
                   FILES.COM und FCBS.COM von QEMM 7.50+ 'auszuleihen'
                   (funktionieren problemlos mit Novells Speichermanagern,
                   getestet mit Update 15), und damit die Datenstrukturen
                   wenigstens in UMBs abzulegen... Dafür sollten Sie einen
                   sehr kleinen FCBS= und FILES= Wert in CONFIG.SYS ein-
                   stellen (z.B. die effektive Minimaleinstellung FCBS=1,0
                   und FILES=5) und per INSTALLHIGH= oder LH diese beiden
                   Utilities mit den entsprechenden Parametern aufrufen,
                   die Sie sonst bei FILES= und FCBS= angeben würden.

                   Beispiel:

                    CONFIG.SYS:

                     DEVICE=EMM386 ...
                     DOS=HIGH,UMB
                     ...
                     REM Statt wie vorher 60 Handles im konventionellen
                     REM Speicher, nun dort nur noch 5 Handles (Minimum),
                     REM dafür aber 55 Handles in UMBs. Spart ca. 3,5KB
                     REM konventionellen Speicher ein! Also:
                     REM Statt FILES=60 nun:
                     FILES=5
                     INSTALLHIGH=c:\sys\qemm\files.com 60
                     REM Statt FCBS=4,4 nun:
                     FCBS=1,0
                     INSTALLHIGH=c:\sys\qemm\fcbs.com 4,4

                   Manche Programme arbeiten allerdings nicht sauber, wenn
                   die Einträge in UMBs verlagert wurden. In diesem Fall
                   sollten Sie eine etwas größere Anzahl im konventionellen
                   Speicher belassen.
                   Zum Beispiel erwartet MS Windows 3.xx mindestens acht
                   Handles im konventionellen Speicher, sonst bricht Windows
                   sofort mit der Meldung 'MS-DOS Version nicht unterstützt'
                   ab. Da aber unter Novell DOS während der CONFIG.SYS immer
                   die internen Einstellungen von FILES= und FCBS= gelten
                   (und die sind kleiner, als Windows es später erwartet)
                   und Utilities wie FILES.COM, FCBS.COM Puffer in Abhängig-
                   keit von diesen Werten nur die darüber hinausgehenden
                   Handles neu einrichten, muß man hier etwas tricksen:
                   Die CONFIG.SYS Einstellung wird auf das Minimum ver-
                   ringert, das MS Windows zuläßt und erst in AUTOEXEC.BAT
                   werden die restlichen Handles mit FILES.COM und FCBS.COM
                   eingerichtet:

                   Beispiel:

                    CONFIG.SYS:

                     DEVICE=EMM386 ...
                     DOS=HIGH,UMB
                     ...
                     REM Minimaleinstellung, die im konventionellen Speicher
                     REM bleiben muß, damit MS Windows noch startet:
                     FILES=8
                     FCBS=0,0

                    AUTOEXEC.BAT:

                     REM Nun *gilt* die in CONFIG.SYS gewählte Einstellung,
                     REM wir können den gewünschten Rest in UMBs anlegen:
                     LH c:\sys\qemm\files.com 60
                     LH c:\sys\qemm\fcbs.com 4,4
                     REM Nun können Programme folgen, die die höhere Ein-
                     REM stellung für Handles benötigen, daher sollten
                     REM obige Aufrufe möglichst am Anfang der AUTOEXEC.BAT
                     REM stehen, sonst werden einige Programme und DOS-
                     REM Dienstprogramme nicht ordnungsgemäß funktionieren.

                   Der Grund für MS Windows' Verhalten ist übrigens sehr
                   kurios und zugleich ein Beispiel dafür, wie man es
                   *nicht* machen sollte: MS Windows' DOSMGR benötigt für
                   seine Arbeit nicht nur einen Zeiger auf die SFT-Kette,
                   sondern auch die Größe ihrer Einträge, die sich leider
                   im Laufe der DOS-Versionen verändert hat. Statt nun die
                   jeweile Größe entsprechend der DOS-Version aus einer
                   Tabelle zu holen, öffnet DOSMGR fünfmal hintereinander
                   das Gerät CON:, sucht dann die ersten 512 KByte des
                   Hauptspeichers nach Zeichenketten wie "CON" ab und
                   ermittelt die Größe der SFT-Einträge durch Abstands-
                   berechnungen zwischen diesen Fundstellen. Natürlich ist
                   dieses Verfahren im wahrsten Sinne des Wortes lebens-
                   gefährlich, denn findet DOSMGR fälschlicherweise andere
                   "CON"-Zeichenketten als die, die wirklich zu den SFT-
                   Einträgen gehören, ist das Chaos auf Ihrer Festplatte
                   vorprogrammiert...
                   Damit DOSMGR diese Zeichenketten überhaupt finden kann,
                   dürfen sie halt nicht hochgeladen werden. (Es gibt
                   allerdings die - gefährliche - Möglichkeit, trotzdem
                   alle SFTs hochzuladen und vor dem Start von MS Windows
                   die seit DOS 4.0 geltende SFT-Größe von 3Bh Bytes
                   dadurch vorzutäuschen, daß man einen nicht allozierten
                   Bereich des Hauptspeichers unterhalb von 512 KByte mit
                   "CON"-Zeichenketten im richtigen Abstand beschreibt,
                   so daß DOSMGR überlistet wird. Dieses Verfahren könnte
                   man natürlich auch direkt in einen Speichermanager wie
                   EMM386 einbauen...)

    FILES [=] nnn [comments]                         nnn=8..255 <12 oder 20>

                   Entgegen den Angaben im Handbuch sind hier auch Werte
                   kleiner 20 möglich. Sinnvolle Einstellung hängen von
                   den verwendeten Anwendungen ab. Normalerweise ist der
                   Default-Wert FILES=20 ausreichend. Für Netz- und Multi-
                   tasking-Betrieb sollte man den Wert jedoch mindestens
                   auf 40 erhöhen. Mit FILES=60 bis FILES=80 liegen Sie
                   fast immer auf der sicheren Seite, allerdings kostet
                   die Bereitstellung von File-Handles pro Datei 64 Bytes
                   Arbeitsspeicher (laut Dokumentation 52 Bytes), die immer
                   im konventionellen Speicher liegen. Zu hohe Werte für
                   FILES= (etwa FILES=250) können auch wieder Probleme
                   bereiten, wenn etwa eine Shell wie NETX darauf angewiesen
                   ist, mehr als 255 Files zu öffnen (in diesem Fall werden
                   nämlich negative Werte, d.h. die freien Werte von oben
                   nach unten benutzt).
                   Zu beachten ist außerdem, daß DOS einige File-Handles
                   für die Standard-Geräte immer in Benutzung hat (die
                   Anzahl liegt bei 4 bis 6 und hängt auch von Ihrer
                   Hardware ab). Sie sollten keine Angaben kleiner 8
                   machen (laut Doku sind minimal 5 möglich, frühere
                   DOS-Versionen hatten auch diese Default-Einstellung),
                   weil diese Werte offenbar nicht korrekt ausgewertet
                   werden!!!
                   Während der CONFIG.SYS gilt - unabhängig von der FILES=
                   Einstellung, die zunächst nur aufgezeichnet wird, um
                   erst nach Beendigung der CONFIG.SYS aktiviert zu werden -
                   eine Einstellung, die effektiv FILES=5 entspricht.
                   FILES= und FCBS= zusammen dürfen maximal 255 betragen,
                   ansonsten wird intern abgerundet (siehe FCBS=).
                   Durch die sinnvolle Zusammenfassung von FCBS= und FILES=
                   (hierzu siehe bei FCBS=) geben einige Analyseprogramme
                   (wie etwa Quarterdecks MFT) mehr FILES an, als einge-
                   stellt, dafür aber nur einen FCB.

                   GEOWORKS ENSEMBLE 1.2+ und GEO PRO benötigten mindestens
                   FILES=120, um unter DR DOS 6.0 und Novell DOS 7 laufen
                   zu können.
                   Microsofts WIN32S-Spiel FREECELL benötigt, bezogen auf
                   seine Funktion, ebenfalls eine sehr hohe Anzahl FILES,
                   so daß FILES=60 hier nur knapp hinkommt.

                   Die mit MS-DOS 7 (MS Windows95/Chicago) später einge-
                   führte Direktive FILESHIGH= wird von Novell DOS 7
                   (Update 15) nicht unterstützt. Soweit mir bekannt,
                   bleiben die Dateieinträge bei Novell DOS 7 auch bei
                   DOS=HIGH,UMB im konventionellen Speicher, was bei
                   üblichen Konfigurationen für FCBS= und FILES= gemeinsam
                   einen 'Verlust' von 0,5 - 3,5 KByte konventionellen
                   Speicher bedeutet, der durch die anderen Hochlade-
                   möglichkeiten aber mehr als wett gemacht wird.

                   Andererseits besteht die Möglichkeit, sich die Utilities
                   FILES.COM und FCBS.COM von QEMM 7.50+ 'auszuleihen'
                   (funktionieren problemlos mit Novells Speichermanagern,
                   getestet mit Update 15), und damit die Datenstrukturen
                   wenigstens in UMBs abzulegen... Dafür sollten Sie einen
                   sehr kleinen FCBS= und FILES= Wert in CONFIG.SYS ein-
                   stellen (z.B. die effektive Minimaleinstellung FCBS=1,0
                   und FILES=5) und per INSTALLHIGH= oder LH diese beiden
                   Utilities mit den entsprechenden Parametern aufrufen, die
                   Sie sonst bei FILES= und FCBS= angeben würden.
                   (Zwei Beispiele, die auch auf disbezügliche Absonder-
                   heiten von MS Windows eingehen, finden Sie etwas weiter
                   oben bei FCBS=...)

                   Manche Programme arbeiten allerdings nicht sauber, wenn
                   die Einträge in UMBs verlagert wurden. In diesem Fall
                   sollten Sie eine etwas größere Anzahl im konventionellen
                   Speicher belassen (z.B. FILES=8 für 4DOS.COM oder
                   MS Windows).

    FASTOPEN [=] hashbufsize [comments]    hashbufsize=0..32768
                                           <0, 512 oder 4096>

                   FASTOPEN merkt sich in einer Verweistabelle Einsprung-
                   zeiger zu bereits einmal geöffneten Dateien, und kann
                   bei Programmen, die häufig Dateien öffnen und wieder
                   schließen (Datenbanken, manche Compiler) einen starken
                   Performance-Gewinn bringen. Allerdings ist FASTOPEN nicht
                   ungefährlich, wenn Sie Festplattenpflegeprogramme
                   einsetzen (COMPRESS, OPTIMIZR, DEFRAG, DISKOPT, SPEEDISK,
                   etc.), die an FASTOPEN vorbei die Position der Dateien
                   neu anordnen. Wird dann über DOS wieder auf eine solche
                   Datei zugegriffen, ist ein Datenchaos vorprogrammiert,
                   wenn der Rechner nicht neu gestartet wird. Die Tabelle
                   von FASTOPEN kann nicht in der HMA liegen.

                   Die interne Realisierungen unterscheidet sich grundlegend
                   zwischen MS-DOS/PC-DOS und DR DOS/Novell DOS, was sich
                   einerseits in den möglichen Parametern niederschlägt,
                   andererseits auch im Speicherbedarf. Bei MS-DOS/PC-DOS
                   werden *pro* Dateieintrag 48 Bytes belegt, bei
                   DR DOS/Novell DOS durch eine effiziente Hash-Tabelle nur
                   2 Bytes. Dadurch, daß bei MS-DOS/PC-DOS die Anzahl und
                   bei DR DOS/Novell DOS die Größe angegeben werden muß,
                   sind die Zahlenwerte bei Novell DOS etwa doppelt so groß
                   wie bei MS-DOS, nur daß Novell DOS hier offenbar mit
                   1/24 des Speicherbedarfs auskommt, was sich bei üblichen
                   Werten wie FASTOPEN=512 schon in über 11 KByte Speicher-
                   platzersparnis niederschlägt... Nicht ohne Grund ist
                   deshalb die Default-Einstellung bei MS-DOS sehr viel
                   niedriger (unter 50).

                   Im Gegensatz zur Dokumentation sind bei Novells FASTOPEN
                   auch Angaben unterhalb von 128 möglich (und zwar offen-
                   sichtlich stufenlos bis herab zu Null). Angaben für
                   spezifische Laufwerke (wie bei MS-DOS) sind nicht
                   möglich. In Verbindung mit NWCACHE wird FASTOPEN = 0
                   empfohlen, da FASTOPEN durch den höheren Verwaltungs-
                   aufwand sonst nur die Performance des NWCACHE bremst.
                   Mit Update 13 wurde die Default-Einstellung auf 0 ge-
                   setzt. Auch wegen der oben genannten Problematik mit
                   der Datenkonsistenz und einem auf heutigen Rechnern nur
                   geringen Geschwindigkeitszuwachs (nur sofern kein Cache
                   installiert ist), empfehle ich dringend FASTOPEN = 0
                   einzusetzen, wenn nichts gegen die Verwendung eines
                   Cache-Programms spricht.

                   Die erweitere Syntax mancher MS-DOS Versionen (Laufwerks-
                   angaben, Zahl zusammenhängender Bereiche, EMS mit /X)
                   wird nicht unterstützt (aber auch nicht zurückgewiesen).
                   Angesichts der bereits optimalen Speicherbilanz wäre
                   derartiger Aufwand auch kontraproduktiv.

                   Das *Kommando* FASTOPEN.EXE (bei DR DOS 6.0) bzw.
                   FASTOPEN.COM (bei Novell DOS 7) ist hingegen ein
                   funktionsloses Kompatibilitäts-Dummy, da die FASTOPEN-
                   Funktionalität bei Novell DOS 7/DR DOS 6.0 schon
                   intern realisiert ist (bei manchen MS-DOS Ausgaben
                   wurde FASTOPEN via

                    INSTALL=FASTOPEN.EXE

                   (oder gar erst in AUTOEXEC.BAT) geladen, daher mußte auch
                   bei Novell DOS eine gleichnamige Dummy-Datei existieren).

                   Manchmal benötigt man ein Dummy-Befehl, der einfach nur
                   als Platzhalter aufgerufen wird und keinen Schaden an-
                   richtet. Mit FASTOPEN.COM liegt Novell DOS 7 ein solches
                   'Programm' bei; es tut wirklich nichts anderes, als eine
                   entsprechende Meldung auszugeben und mit Errorcode 0
                   zu DOS zurückzukehren. Das gleiche gilt auch für
                   FASTOPEN.EXE von DR DOS 6.0, außer daß Novells
                   FASTOPEN.COM in der Meldung zusätzlich auf CONFIG.SYS
                   verweist, wenn es vom Prompt aus aufgerufen wird.
                   (Ältere Ausgaben von FASTOPEN.EXE von DR DOS 5.0 besaßen
                   wahrscheinlich noch eigene Funktionalität und kehrten bei
                   falschen Parametern mit Errorcode 1 zurück. Dies gilt
                   mit Sicherheit für FASTOPEN von MS-DOS/PC-DOS 4.0+.)

    DOS [=] [LOW|HIGH] [, [UMB|NOUMB]]
    HIDOS [=] [ON|OFF]

                   Wie von MS-DOS bekannt (Naja, eigentlich gab es die
                   Hochlademöglichkeit *zuerst* bei DR DOS 5.0, allerdings
                   noch mit der alten Direktive HIDOS=).
                   Novell DOS akzeptiert die möglichen Parameter in
                   beliebiger Reihenfolge. Auch der Token NOUMB ist vor-
                   handen, in der Doku wird er allerdings nicht erwähnt.
                   Die DR DOS Direktive HIDOS= ist auch bei Novell DOS noch
                   vorhanden und wird - undokumentiert - voll unterstützt.
                   Dabei entspricht HIDOS=ON dem DOS=HIGH. Bei DR DOS 6.0
                   war es noch genau umgekehrt: Die Direktive DOS=HIGH
                   (nicht aber die anderen Token) existierte auch dort
                   schon, war allerdings noch undokumentiert.
                   Default-Wert für DOS= ist LOW,NOUMB.
                   Mit DOS=HIGH,UMB werden nach Möglichkeit auch die DOS-
                   Datenbereiche verschoben (außer FILES und FCBS).

                   MS-DOS 7 (MS Windows95/Chicago) unterstützt einige
                   zusätzliche Optionen (AUTO, NOAUTO und bei Chicago
                   ENHANCED), die Novell DOS 7 (Update 15) fremd sind,
                   aber auch nicht vermißt werden, da sie lediglich die
                   Handhabung unter MS Windows95 etwas vereinfachen
                   (Default ist AUTO), indem bestimmte notwendige Treiber
                   nicht explizit angegeben werden müssen, sondern auto-
                   matisch geladen werden. Außerdem bewirkt diese Ein-
                   stellung, daß die Direktiven BUFFERS, FILES, FCBS,
                   STACKS und LASTDRIVE automatisch in ihrer neuen -HIGH-
                   Variante verwendet werden. Bei Novell DOS werden bei
                   entsprechender Einstellung von DOS=HIGH,UMB die Puffer
                   automatisch in die HMA verlegt und die LASTDRIVE-
                   Tabelle in den oberen Speicher.

    DEBLOCK [=] hexvalue                          hexvalue=0000..FFFF <FFFF>

                   Diese undokumentierte Direktive von Novell DOS 7 erlaubt
                   die explizite Einstellung der Adresse, ab der IBMBIO.COM
                   beim 'Disk-Deblocking' nur noch einzelne Sektoren benutzt
                   (im Prinzip gibt es das seit CP/M).
                   In ganz frühen Novell DOS 7 Versionen (und bei DR DOS)
                   war die Default-Einstellung A000, was der 640 KByte-
                   Grenze entsprach. Darüber wurde auf den Single-Sektor-
                   Betrieb ausgewichen. Diese Einstellung war sicherer als
                   die heutige Einstellung, aber auch langsamer.
                   Um die Kompatibilität mit MS-DOS zu verbessern und
                   die Performance für in UMBs geladene Programme (wie
                   STACKER.EXE oder SERVER.EXE) zu erhöhen, wurde die
                   Default-Einstellung auf FFFF verändert (was effektiv
                   auch bei MS-DOS gilt, obwohl es dort diese Direktive
                   überhaupt nicht gibt, denn MS-DOS 5.0+ MULTITRACK=ON|OFF
                   ist hierzu fast identisch: DEBLOCK=FFFF entspricht wohl
                   weitestgehend MULTITRACK=ON und DEBLOCK=0000 demnach
                   MULTITRACK=OFF. Wie man sieht, sind Novells Einstellungs-
                   möglichkeiten hier flexibler. Die Einstellung FFFF ist
                   schneller, aber auch gefährlicher. Über die DEBLOCK=
                   Direktive hat der Anwender die Möglichkeit, die
                   Einstellung bei Bedarf zu verändern. Probleme könnten
                   wohl in Verbindung mit (hochgeladenem) NWCACHE,
                   DBLBUF.SYS oder bei Floppy- oder Harddisk-DMA (ohne
                   VDS) auftreten.
                   Solange es keine Probleme gibt, sollte man DEBLOCK=
                   nicht angeben, um die automatische Hardware-Erkennung
                   und Konfiguration je nach System zu aktivieren. In diesem
                   Fall entscheidet nach der Beendigung von CONFIG.SYS ein
                   dynamischer Test darüber, ob die Default-Einstellung
                   FFFF bestehen bleibt, oder ob die Einstellung sicher-
                   heitshalber auf A000 zurückgesetzt wird (der Test be-
                   steht darin, den ersten Sektor sowohl in den konventio-
                   nellen Speicher als auch in UMBs zu laden und dann mit-
                   einander zu vergleichen). Ist man sicher, daß es keine
                   Probleme gibt, kann man die Einstellung auch explizit
                   auf einen Wert, hier also DEBLOCK=FFFF setzen und damit
                   die automatische Konfiguration übersteuern.
                   Näheres kann dem FaxBack-Infopaper 14926.TXT aus
                   ND7TID.EXE entnommen werden. Näheres siehe auch in
                   Kapitel II.17.

    DRIVPARM [=] /D:n [/C] [/F:n] [/H:nn] [/I] [/N] [/S:nn] [/T:nn]

                   /D:driveno     driveno=0..31 (d.h. auch LASTDRIVE=32
                                  wird voll unterstützt)
                   /F:drivetype   drivetype=0..255 <0..9>
                   /S:sectors     sectors=1..99 <hängt von drivetype ab>
                   /T:cylinder    cylinder=1..999 <"">

                   Der in der Dokumentation erwähnte Parameter /I wird
                   wahrscheinlich nicht unterstützt (da obsolet).

                   Wird der Parameter /C für die Change-Disk-Detection
                   nicht angegeben, so versucht Novell DOS zwar trotzdem,
                   diese Statusanzeige auszuwerten, im Fall des Scheiterns
                   wird jedoch nach einer Wartezeit von 3 Sekunden still-
                   schweigend ein Medienwechsel angenommen.

                   Bei /F:n kann eine beliebige Zahl angegeben werden,
                   es sind jedoch nur 0..9 vordefiniert. Die Default-
                   Einstellungen der restlichen Parameter hängen davon
                   ab, welche anderen Parameter in welchen Kombinationen
                   angegeben wurden. Sollte die DRIVPARM= Direktive mehr-
                   fach pro Laufwerk angegeben werden, so werden (bis
                   auf Ausnahmen) nur die Werte neu belegt, die auch neu
                   definiert wurden.

                   Übliche Zuordnungen für /F: sind:

                    0 = 320/360 KByte, double density [DD] (5,25")
                    1 = 1,2 MByte, high density [HD]   (5,25")
                    2 = 720 KByte, double density [DD] (3,5")
                    3 = ??? KByte, single density [SD] (8")
                        (wird wie 360 KByte Floppy eingebunden)
                    4 = ??? KByte, double density [DD] (8")
                        (wird wie 360 KByte Floppy eingebunden)
                    5 = (Festplatte, sonst wie 360 KB Floppy eingebunden)
                    6 = (Bandlaufwerk, sonst wie 360 KB Floppy eingebunden)
                    7 = 1,44 MByte, high density [HD]  (3,5")
                    8 = (optisches Laufwerk, z.B. CD-ROM, CD-WO, CD-RW,
                         wird allerdings wie 1,44 MByte Floppy eingebunden)
                    9 = 2,88 MByte, extra density [ED] (3,5")

                   Einige übliche Diskettenformate:

                     Größe        8"------+
                                  5,25"-+ |  Typ  Seiten  Sektoren   Spuren
                                  3,5"+ | |  /F:    /H:      /S:       /T:

                     160 KByte, SS/SD - x -   0      1        8        40
                     180 KByte, SS/SD - x -   0      1        9        40
                     243 KByte, SS/SD - - x   0      1       26        77
                     320 KByte, DS/DD - x -   0      2        8        40
                     320 KByte, SS/HD x - -   ?      1        8        80
                     360 KByte, DS/DD - x -   0      2        9        40
                     600 KByte, DS/DD - x -   ?      2       15        40
                    1,20 MByte, DS/HD x x -   1      2       15        80
                     720 KByte, DS/DD x x -   2      2        9        80
                    1,44 MByte, DS/HD x x -   7      2       18        80
                    2,88 MByte, DS/ED x - -   9      2       36        80

                   Einige weniger übliche Diskettenformate:

                     200 KByte, SS/SD - x    ??      1       10        40
                     205 KByte, SS/SD - x    ??      1       10        41
                     210 KByte, SS/SD - x    ??      1       10        42
                     361 KByte, SS/DD - x    ??      1        9        80
                     389 KByte, DS/DD   x -  2 (0)   2        9        43
                     400 KByte, DS/DD   x -  ??      2       10        40
                     410 KByte, DS/DD   x -  ??      2       10        41
                     420 KByte, DS/DD   x -  ??      2       10        42
                     640 KByte, DS/DD x x -  1       2        8        80
                     719 KByte, DS/DD x x -  ??      2        9        80
                     785 KByte, DS/DD x   -  2       2        9        86
                     800 KByte, DS/DD x   -  ??      2       10        80
                     810 KByte, DS/DD x   -  ??      2       10        81
                     820 KByte, DS/DD x   -  ??      2       10        82
                     830 KByte, DS/DD x   -  ??      2       10        83
                     880 KByte, DS/DD   x -  ??      2       11        80
                    1,04 MByte, DS/DD x   -  ??      2       13        80
                    1,12 MByte, DS/DD x   -  ??      2       14        80
                    1,23 MByte, DS/HD x x -  1       2       15        82
                    1,31 MByte, DS/HD x x -  ??      2       16        82
                    1,48 MByte, DS/HD x x -  7       2       18        82
                    1,49 MByte, DS/HD   x -  ??      2       18        83
                    1,60 MByte, DS/HD x x -  ?? (7)  2       20        80
                    1,64 MByte, DS/HD x   -  ?? (7)  2       20        82
                    1,68 MByte, DS/HD x   -  ??      2       21        80
                    1,71?MByte, DS/HD x   -  ?? (7)  2       21        82
                    1,73?MByte, DS/HD x   -  ?? (7)  2       21        83
                    1,79 MByte, DS/HD x   -  ?? (7)  2       21        85
                    1,76 MByte, DS/HD x   -  ??      2       22        80
                    1,84 MByte, DS/HD x   -  ??      2       23        80
                    1,92 MByte, DS/HD x   -  ??      2       24        80
                    3,20 MByte, DS/ED x - -  ??      2       40        80
                    3,52 MByte, DS/ED x - -  ??      2       44        80
                    3,84 MByte, DS/ED x - -  ??      2       48        80

                   Mit einem der letzten Updates (11-15) zu Novell DOS
                   gab es verschiedene Bugfixes, DRIVPARM= betreffend:

                   Einerseits konnten 2,88 MByte Laufwerke bisher nicht
                   entsprechend der Dokumentation angemeldet werden, und
                   andererseits werden sie jetzt auch korrekt erkannt, wenn
                   das BIOS sie falsch meldet (in der Einführungsphase
                   dieser Laufwerke - dauert die nicht eigentlich immer
                   noch an? ;-) - gab es hier noch keinen sauberen Standard,
                   und einige BIOSe melden solche Laufwerke als Typ 3 oder
                   4 statt 5 oder 6). 1,44 MByte Floppies können jetzt
                   auch korrekt formatiert werden, wenn sie über DRIVPARM=
                   eingebunden worden sind.

                   Nachbemerkung: Angeblich unterstützt DR DOS 6.0
                   DRIVER.SYS /D:0..127. Diese dürfte auch für Novells
                   DRIVER.SYS zutreffen, aber ob Laufwerke oberhalb 31
                   vom System unterstützt werden, ist nicht geklärt
                   (MS-DOS 2.xx unterstützte 64 Laufwerke).
                   Sollten Sie die obige Tabelle verwenden wollen, um
                   Diskettensonderformate einzustellen, sollten Sie hierzu
                   am besten mit DRIVER.SYS statt DRIVPARM= arbeiten, weil
                   Sie dann unter dem alten Laufwerksbuchstaben weiterhin
                   problemlos auf Normalformatdisketten zugreifen können.
                   Wichtig: Ich habe die meisten der obigen Sonderformate
                   nicht selbst ausprobiert! Die Angaben bezüglich des
                   Laufwerkstyps beziehen sich auf Laufwerke entsprechender
                   Kapazität. Nicht alle Laufwerke unterstützen mehr als
                   40/80 Spuren und die Anzahl der zuverlässig ansprech-
                   baren Sonderspuren variiert von Fabrikat zu Fabrikat
                   und kann sogar gewissen Exemplarstreuungen unterliegen.
                   Auch bei Disketten gibt es Unterschiede. Nicht jedes
                   Diskettenfabrikat eines Typs ist in der Lage, Überformate
                   (zuverlässig) zu verkraften, dies gilt besonders für
                   Formate außerhalb der vorgesehenen Dichte. Unter Um-
                   ständen benötigen Sie auch zusätzliche Treiber, um diese
                   Formate zu unterstützen. Obwohl einige der Überformate
                   auch über lange Zeiträume sehr zuverlässig verwendet
                   werden können (siehe Ciriaco Garía de Celis' 2M-Paket
                   und andere) empfehle ich dringend ausführliche Tests,
                   ehe Sie wichtige Daten auf solchen Disketten ablegen!
                   Ich übernehme selbstredend keine Gewähr!!!

    HISTORY [=] OFF|[ON [, bufsize][[, ON|OFF][, ON|OFF[, ON|OFF]]]]]

                   bufsize=128..4096 <512>

                   In der während des Bootens ausgegebenen Hilfe sind nicht
                   alle möglichen Parameter angegeben; das DOSBOOK gibt aber
                   erschöpfende Hinweise. Das erste ON in Verbindung mit dem
                   optionalen Wert value (128..4096, Default ist <512>)
                   gibt die Größe des Puffers an, die weiteren optionalen
                   ON|OFF-Parameter stehen jeweils für Einfügemodus ein/aus
                   (<Ins>), Kommandozeilensuchmodus ein/aus (<Ctrl>+<r>),
                   erweiterte Kommandozeilensuche ein/aus (<Ctrl>+<_>) und
                   werden nur ausgewertet, wenn der erste Parameter ON ist
                   (siehe auch Kapitel II.12.). Jeder Puffereintrag kostet
                   zwei Bytes, die immer im konventionellen Speicher
                   bleiben, bei 512 Puffern also 1 KByte.

                   Wird diese Direktive innerhalb der CONFIG.SYS mehrfach
                   wiederholt, so werden dabei nur die jeweils zuletzt
                   angegebenen Werte aktualisiert.

                   Offenbar wird erst mit dem Laden von COMMAND.COM Speicher
                   für den HISTORY-Puffer reserviert, jedenfalls konnte ich
                   bei beliebigen Einstellungen von HISTORY= keinerlei
                   Unterschiede im statischen Speicherverbrauch feststellen,
                   wenn mit SHELL=4DOS gearbeitet wurde. Trotzdem ist die
                   History-Funktion innerhalb von COMMAND.COM wohl
                   funktionsfähig, was mir noch Rätsel aufgibt... ???

                   Meine Empfehlung, wenn Sie (zumindest zeitweise) mit
                   COMMAND.COM arbeiten:

                    HISTORY=ON,512,ON,OFF,OFF

                   Meine Empfehlung, wenn Sie ausschließlich mit einem
                   Alternativ-Kommandoprozessor wie 4DOS/NDOS arbeiten:

                    HISTORY=OFF

                   Bei HISTORY=OFF sollten Sie nicht mit DOSKEY /H arbeiten
                   (offenbar gibt es hier einen kleinen Bug, der dazu führt,
                   daß bei Verwendung von 4DOS der History-Puffer zerstört
                   wird, getestet bis Update 15).

                   Das mit MS-DOS/PC-DOS 5 eingeführte DOSKEY besitzt
                   recht ähnliche Funktionalität, die meisten Tasten sind
                   identisch belegt, aber leider nicht alle. Unterschiede:

                    Taste  DR DOS  Novell DOS 7       MS-DOS/PC-DOS 5.0

                    <F7>   ^Z      ^@                 listet Makros
                    <F8>   ^@                         durchsucht History
                    <F9>   ??      löscht akt. Zeile  aktiviert Makro Nr.
                    <F10>  ??      löscht akt. Zeile

                    <Alt>+<F7>
                    <Alt>+<F10>

                   Novell DOS 7 DOSKEY stellt zwar die gleichen Optionen
                   wie das Original bereit (auch die Funktionen, die sich
                   auf die History-Funktion beziehen), dennoch ist die
                   History-Funktionalität bei Novell DOS weiterhin via
                   HISTORY= realisiert und nur die zusätzlichen Makro-
                   funktionen sind Bestandteil des residenten DOSKEY
                   (siehe auch Kapitel II.4.). Dadurch können beide
                   Funktionen unabhängig voneinander aktiviert werden.
                   Im Vergleich zu MS-DOS DOSKEY, das bei 512 Bytes
                   Puffergröße 4 KByte Speicher für den residenten
                   Code benötigt, schlägt Novells DOSKEY nur mit ca.
                   1,5 KByte zu Buche, plus ca. 1,5 KByte für HISTORY=
                   mit 512 Bytes Puffer.

                   HISTORY= akzeptierte bei DR DOS 3.41 und 5.0 drei
                   Parameter, bei DR DOS 6.0 bereits vier, und nun noch
                   einen fünften. Offenbar hinkte die Dokumentations-
                   abteilung immer eine DOS-Release hinterher, denn es
                   wurde in jeder DR DOS Ausgabe vergessen, die jeweils
                   letzte Option komplett zu dokumentieren.

    LASTDRIVE [=] [A..Z]|[1..32] [comments]                      <F oder G>

                   Hinter dem Laufwerksbuchstaben sind weitere Zeichen
                   möglich, d.h. eine Angabe wie LASTDRIVE=Z: wird also
                   auch akzeptiert. Jedes eingerichtete Laufwerk kostet 88
                   Bytes Speicherplatz. Die Default-Einstellung hängt offen-
                   bar von der Festplatteneinrichtung des Rechners ab: Mit
                   zwei Festplatten mit jeweils zwei Partitionen ist die
                   Einstellung offensichtlich G:, obwohl es laut Handbuch in
                   dieser Konfiguration F: sein müßte (bei MS-DOS ist die
                   Normaleinstellung E:). Eine andere Erklärung würde darin
                   bestehen, daß die Laufwerksbuchstaben, die von echten
                   Gerätetreibern (DEVICE=) benötigt werden, erst nach der
                   Abarbeitung der CONFIG.SYS wirklich eingebunden werden
                   (dies ist aber zumindest bei Novell DOS 7 definitiv nicht
                   der Fall).

                   Erweiterte undokumentierte Syntax zur Unterstützung von
                   bis zu 32 Laufwerken (wird nun auch von MS-DOS 7 aus
                   Windows95 unterstützt). Näheres siehe Abschnitt III.2.

                   Die mit LASTDRIVE= vorgenommene Einstellung wird bei
                   Novell DOS und MS-DOS/PC-DOS (abgesehen von MS-DOS 7)
                   erst beim Laden des Kommandoprozessors wirksam. Inner-
                   halb der CONFIG.SYS gilt weiterhin die interne LastDrive-
                   Einstellung, die vor der Bearbeitung der CONFIG.SYS
                   ermittelt wurde (s.o.), d.h. es ist zwar möglich,
                   Blockgerätetreiber zu laden (ist nicht abhängig von
                   LASTDRIVE=), aber es ist nicht möglich, die Lastdrive-
                   Einstellung zu erhöhen, wenn das Laden von Laufwerks-
                   treibern per INSTALL= aufgrund fehlender freier Lauf-
                   werksbuchstaben fehlschlägt, weil diese als Umadressierer
                   implementiert sind (NWCDEX, MSCDEX, Netztreiber wie VLM),
                   siehe auch Kapitel II.4. bei NWCDEX.
                   Intern wird bei Novell DOS 7 im Gegensatz zu MS-DOS/
                   PC-DOS bis 6.2x jedoch bereits eine auf 26 Laufwerke
                   erweiterte Vorab-CDS verwendet, dadurch kann mein Utility
                   INSTCDEX mittels der speziellen /LASTDRIVE Option auch
                   dazu verwendet werden, die LASTDRIVE= Einstellung des
                   Systems während der CONFIG.SYS zu verändern (mehr dazu
                   bei NWCDEX). Diese Vorab-CDS wird nach der Bearbeitung
                   der CONFIG.SYS auf die wirklich geforderte Größe gestutzt
                   (oder mit LASTDRIVE=27..32 vergrößert) und dabei nach
                   Möglichkeit auch in den UMBs angeordnet. Bei MS-DOS bis
                   einschließlich 6.22 ist das Handling wesentlich un-
                   flexibler: Die CDS, die immer im Basisspeicher bleibt,
                   enthält nur soviele Einträge, wie Laufwerke vor der
                   Bearbeitung der CONFIG.SYS Datei erkannt wurden plus die
                   Einträge von geladenen Blockgerätetreibern. Bei MS-DOS 7
                   haben die Entwickler einen weiteren langen Blick über den
                   Zaun geworfen, denn bei MS-DOS 7

                   - kann die LASTDRIVE=/LASTDRIVEHIGH= Angabe nun auch über
                     eine Zahl erfolgen,
                   - es werden auch bis zu 32 Laufwerke unterstützt,
                     (wobei sinnvollerweise wie bei späten Ausgaben von
                     Novell DOS auch Zahlenwerte von 1..32 und nicht - wie
                     bei frühen Ausgaben von Novell DOS 7 - nur von 27..32
                     erlaubt sind. Die externen Utilities von MS-DOS 7
                     arbeiten im Gegensatz zu den Programmen von
                     Novell DOS 7 allerdings nicht mit diesen neuen
                     Buchstaben),
                   - die Vorab-CDS enthält ebenfalls 26 komplett initiali-
                     sierte Laufwerkseinträge (die sinnvollerweise auch
                     nach außen dokumentiert werden, und nicht - wie bei
                     Novell DOS 7 - nur intern vorbereitet sind, wodurch
                     INSTCDEX unter Novell DOS 7 trotzdem benötigt wird,
                     bei MS-DOS 7 hingegen nicht mehr).
                   - und die CDS kann (automatisch) hochgeladen werden.

                   (Zusätzlich wirkt bei MS-DOS 7 die LASTDRIVE= Direktive
                   nun schon während der CONFIG.SYS und auch das Verschieben
                   der CDS findet vorher statt, so daß die Probleme, zu
                   deren Umgehung ich für ältere DOS-Versionen INSTCDEX.EXE
                   geschrieben habe, unter MS-DOS 7 nicht mehr auftreten.)

                   Übrigens kann man mit dem Wissen dieses Verhaltens auch
                   verstehen, warum man für PNW und NetWare VLMs (üblicher-
                   weise nicht in CONFIG.SYS geladen) LASTDRIVE=Z setzen
                   sollte/muß, wohingegen man bei der alten NetWare Shell
                   (NETX) den LASTDRIVE= Wert nur leicht erhöhen mußte,
                   siehe auch Kapitel III.2. (VLM.EXE kann übrigens auch
                   unter Zuhilfenahme von INSTCDEX nicht in CONFIG.SYS
                   geladen werden.)

                   Die mit MS-DOS 7 (MS Windows95/Chicago) später einge-
                   führte Direktive LASTDRIVEHIGH= wird von Novell DOS 7
                   (Update 15) nicht unterstützt. Wie bekannt, kann man
                   das Gleiche auch mit DOS=HIGH,UMB und 'normalem'
                   LASTDRIVE= erreichen.

    NUMLOCK [=] [ON|OFF]

                   Diese undokumentierte Direktive schaltet NumLock ein oder
                   aus; allerdings wird die Einstellung normalerweise erst
                   übernommen, wenn eine Taste gedrückt wird. Auf XTs bzw.
                   PC-Tastaturen kann es dazu kommen, daß die NumLock-LED
                   durch die Umstellung ab sofort genau umgekehrt reagiert.
                   Dieses systembedingte Verhalten ist kein Fehler und läßt
                   sich korrigieren, wenn zu einem spätereren Zeitpunkt mit
                   einem Utility der NumLock-Zustand erneut verändert wird.
                   (Bei DR DOS 6.0 gab es diese Direktive noch nicht.)

    SET [=] preenvvar = [value]

                   Die während CONFIG.SYS aufgezeichneten Umgebungsvariablen
                   werden später in COMMAND.COMs Systemumgebung übernommen.
                   Standardmäßig ist diese Vorab-Umgebung leer, wird jedoch
                   beim Starten von COMMAND.COM um die Variable %ComSpec%
                   erweitert. COMMAMD.COM seinerseits fügt noch %Ver% und
                   %Os% ein, siehe Kapitel IV.7. (Weitere Variablen würden
                   dann in AUTOEXEC.BAT belegt.) Maximal kann die Vorab-
                   Umgebung ca. 5760 Zeichen aufnehmen.

                   Wenn man Programme mit INSTALL[HIGH]= bzw. HIINSTALL=
                   lädt, wird ihnen die bis zum jeweiligen Zeitpunkt aufge-
                   baute Vorab-Umgebung (unbearbeitet) übergeben, daher
                   sollte man gerade in CONFIG.SYS mit dem SET= Befehl
                   umsichtig umgehen. An diesen eigentlichen Umgebungsblock
                   wird - wie üblich - noch eine Zeichenkette angehängt,
                   die Pfad und Namen der ausgeführten Programmdatei
                   spezifiziert. Kurze Aufrufpfade führen also auch zu
                   eingespartem Speicherplatz (siehe Kapitel II.11.)!

                   Gegenüber dem üblichen Verhalten von SET arbeitet die
                   CONFIG.SYS Direktive SET= etwas unterschiedlich: In
                   der Vorab-Umgebung werden *alle* mit SET= definierten
                   Variablen abgelegt (auch Leerdefinitionen wie SET=
                   ohne Wert nach dem =). Wenn man Variablen innerhalb
                   der CONFIG.SYS mit neuen Werten überschreibt, so wird
                   der alte Eintrag *nicht* gelöscht, sondern die neue
                   Belegung an das Ende der Liste angehängt. Außerdem ist
                   zu beachten, daß bei den Variablen der Vorab-Umgebung
                   Groß- und Kleinbuchstaben unterschieden werden, wohin-
                   gegen bei COMMAND.COM (und 4DOS.COM) die Variablen der
                   späteren Umgebung als Großbuchstaben abgelegt sind
                   (wobei der SET-Befehl und die %var%-Ersetzung des
                   Kommandoprozessors nur auf die Variablen mit Großbuch-
                   staben zugreifen, obwohl die Referenzen in Batchjobs
                   durchaus auch klein geschrieben werden können; wie dies
                   der besseren Übersicht auch in dieser Datei in ge-
                   mischter Groß-/Kleinschreibung angewendet wird). Auf
                   diese Art und Weise können innerhalb der CONFIG.SYS
                   mehrere Definitionen *gleichzeitig* unter demselben
                   Namen existieren. Möchten Sie auf Nummer sicher gehen,
                   sollten Sie die Variablennamen für CONFIG.SYS SET=
                   generell in Großbuchstaben schreiben.
                   Da diese Vorab-Umgebung allen per INSTALL[HIGH] ge-
                   ladenen Programmen übergeben wird, ist dieses Detail
                   durchaus wichtig, denn von deren internen Auswerte-
                   routinen für die Umgebung hängt es ab, wie solche
                   Vorab-Umgebungen bearbeitet werden (viele GETENV()-
                   Routinen aus den Laufzeitbibliotheken Hochsprachen-
                   Compilern erkennen nur die Variablen, die in Block-
                   schrift geschrieben wurden, weil sie einfach davon
                   ausgehen, daß die Variablennamen in der Umgebung in
                   Großschrift repräsentiert werden). Sofern man auf
                   diese Besonderheiten eingeht, eröffnen sich durchaus
                   sinnvolle Möglichkeiten, z.B. kann man eine Art
                   History-Funktion der CONFIG.SYS Abarbeitung ermöglichen,
                   wenn man an allen relevanten Stellen eine spezielle
                   Variable (z.B. %hit_me%) mit dem Namen/Marke der
                   Position belegt. Die Reihenfolge der %hit_me%= Werte in
                   der Vorab-Umgebung entspricht dann der Reihenfolge, in
                   der die CONFIG.SYS bearbeitet wurde.

                   Ein Beispiel:

                    CONFIG.SYS:

                    SET test=wert1
                    SET test=wert2
                    SET test=
                    SET test=wert3
                    REM Die Vorab-Umgebung sieht jetzt folgendermaßen aus
                    REM (von anderen Variablen abgesehen):
                    REM "test=wert1 test=wert2 test= test=wert3"
                    INSTALL=c:\nwdos\command.com /C SET
                    REM Die Umgebungsauflistung von COMMAND.COM (neben
                    REM anderen Variablen wie %ComSpec%):
                    REM "test=wert1 test=wert2 test= test=wert3 TEST=wert3"
                    REM Gleichzeitig schließt der Aufruf von COMMAND.COM
                    REM aber auch Vorab-Umgebung (Update 15).

                   Dieses Beispiel zeigt ein weiteres Detail: Der Kommando-
                   prozessor COMMAND.COM (hier für Testzwecke auf unüblichem
                   Wege geladen), enthält neben der Vorab-Umgebung auch
                   die 'richtige' Umgebung "TEST=wert3". Diese spezielle
                   Ausnahme liegt an der internen Behandlung während der
                   Installation von COMMAND.COM; andere per INSTALL[HIGH]=
                   geladene Programme besitzen nur die Vorab-Umgebung!
                   Zu beachten ist, daß man dieses Phänomen nur zu Gesicht
                   bekommt, wenn man COMMAND.COM über INSTALL= lädt. Bei der
                   normalen Ladeprozedur am Ende der CONFIG.SYS (und unter
                   Verwendung von SHELL=), wertet COMMAND.COM die Vorab-
                   Umgebung aus und baut das Master-Environment mit den
                   daraus resultierenden Belegungen auf. Dabei wird die
                   jeweils letzte Definition einer Variablen übernommen.
                   Leerdefinitionen werden allerdings ignoriert, so daß
                   eine Vorab-Umgebung "test=wert1 test=" in "TEST=wert1"
                   umgewandelt wird.
                   Variablennamen werden in Großbuchstaben abgelegt (bei
                   4DOS.COM bleibt die Groß-/Kleinschreibung erhalten),
                   siehe Kapitel III.6. und 4DOSTIP.TXT.

                   Je weniger Variablen man belegt (und desto weniger häufig
                   man gleichnamige Variablen umdefiniert), desto weniger
                   Speicher wird für *jedes* per INSTALL[HIGH]= zu ladende
                   Programm benötigt. Die jeweils letzten Belegungen werden
                   beim regulären Laden des Kommandoprozessors (am Ende der
                   CONFIG.SYS Bearbeitung) übernommen und werden von da an
                   jedem geladenen Programm übergeben. Braucht man den SET=
                   Befehl exzessiv, so sollte man aus Gründen der Speicher-
                   platzersparnis - soweit möglich - die Variablen erst
                   *nach* dem Laden der Programme definieren (dies gilt also
                   sowohl für CONFIG.SYS, als auch AUTOEXEC.BAT).

                   Leider kann der Anwender nicht schon innerhalb der
                   CONFIG.SYS auf die Variablen zugreifen (außer über
                   interne Datenstukturen INT21h/4458h). Dabei ist aber
                   unbedingt darauf zu achten, daß ein Wert ungleich 0 bei
                   Offset +12h nicht unbedingt bedeutet, daß der Pointer
                   auf die Vorab-Umgebung auch wirklich gültig ist (unter
                   4DOS wird dieser Pointer nämlich nicht zurückgesetzt).
                   Ein Workaround findet sich in Kapitel III.6. und
                   4DOSTIP.TXT.

                   Um die Vorab-Umgebung benutzen zu können, ohne gleich-
                   zeitig mit jedem geladenen TSR (die diese Variablen meist
                   gar nicht benötigen) einen gewissen Speicherverlust in
                   Kauf zu nehmen, habe ich für DR DOS 6.0/Novell DOS 7 ein
                   kleines Utility namens SETENV.COM geschrieben, das die
                   Vorab-Umgebung temporär versteckt. Dadurch kann bei
                   mit INSTALL=/INSTALLHIGH=/HIINSTALL= geladenen Programmen
                   etwas Speicher eingespart werden und einer unnötigen
                   Fragmentierung vorgebeugt werden.
                   (Obwohl der Sachverhalt genauso auch für MS-DOS/PC-DOS
                   6.0+ Vorab-Umgebung gilt, besteht diese praktische
                   Möglichkeit für MS-DOS/PC-DOS Benutzer leider nicht.
                   Eine ähnliche Möglichkeit gibt es auch bei PTS/DOS und
                   S/DOS mit dem INSTALL= Parameter /E.)
                   Dazu muß man jedes zu ladende TSR, dem nur eine Dummy-
                   Umgebung übergeben werden soll, mit Aufrufen von
                   SETENV.COM einrahmen:

                    SET test=wert
                    REM Versteckt die Vorab-Umgebung
                    INSTALL=SETENV.COM
                    INSTALL=TSR ...
                    REM Restauriert die Vorab-Umgebung
                    INSTALL=SETENV.COM

                   Derzeit hat SETENV.COM noch einen sehr rudimentären
                   Status und toggelt bei jedem Aufruf den Zustand der
                   Vorab-Umgebung. Ist die Umgebung versteckt und verwendet
                   man zwischenzeitlich den SET= Befehl, so baut dieser
                   eine neue Umgebung auf, gleichzeitig wird diese wieder
                   sichtbar. Auf diese Weise ist es auch möglich, eine
                   bereits aufgebaute Umgebung wieder komplett zu löschen:

                    SET test=wert
                    REM Versteckt die Vorab-Umgebung
                    INSTALL=SETENV.COM
                    SET test2=wert2
                    REM SET löscht die bisherige Vorab-Umgebung und
                    REM überschreibt sie mit dem neuen Wert! Auf diese
                    REM Weise kann man den einzelnen TSRs auch völlig
                    REM unterschiedliche Umgebungen übergeben...
                    INSTALL=SETENV.COM
                    REM Da die alte Vorab-Umgebung nicht mehr existiert
                    REM und eine neue sichtbar ist, versteckt SETENV die
                    REM neue Umgebung, statt - wie in obigem Beispiel -
                    REM die alte wieder sichtbar zu machen...

                   Damit SETENV.COM (und SET=) arbeiten kann, darf aller-
                   dings im vorherigen Boot-Verlauf niemals COMMAND.COM
                   aufgerufen worden sein, auch nicht temporär etwa als:

                    INSTALL=c:\nwdos\command.com /C DIR *.*

                   Denn durch den Aufruf von COMMAND.COM wird die Vorab-
                   Umgebung geschlossen und weitere Variablen können
                   nicht mehr definiert werden. Außerdem sind alle bis-
                   herigen Variablen auch für den später per SHELL= ge-
                   ladenen Kommandoprozessor nicht mehr verfügbar!

    SHELL [=] [d:[\path]]\COMMAND.COM d:\path /P[:autoexecfile] [/E:n] [/Mx]

                   Angabe des Kommandoprozessors (i. allg. COMMAND.COM).
                   Näheres zu dokumentierten COMMAND.COM Aufrufoptionen
                   siehe COMMAND.COM /? und zusätzlich auch undokumentierten
                   Optionen siehe in Kapitel II.11!
                   Der Aufrufpfad für den Kommandoprozessor wird bei allen
                   üblichen Kommando-Interpretern (wie COMMAND.COM, 4DOS,
                   NDOS) auch für die Variable %ComSpec% benutzt, siehe
                   Kapitel IV.7.
                   Gibt man hier (für COMMAND.COM) die Option /P nicht
                   an, so wird keine AUTOEXEC.BAT Datei abgearbeitet,
                   nachdem COMMAND.COM geladen ist. Außerdem ist dessen
                   EXIT Kommando in diesem Fall nicht gesperrt, d.h. man
                   kann die Primärversion des Kommandoprozessors verlassen
                   ohne zu Booten! Das darunterliegende IBMBIO.COM weiß
                   sich daraufhin nicht anders zu helfen, als die Eingabe-
                   behandlung selbst in die Hand zu nehmen, beschränkt sich
                   aber darauf, nach dem Pfad und Namen eines gültigen
                   Kommandoprozessors zu fragen. Leider kann man in diesem
                   Fall dem Kommandoprozessor keine Optionen (eben z.B. /P)
                   angeben. Alle während der CONFIG.SYS und AUTOEXEC.BAT
                   geladenen Treiber stehen übrigens in diesem Moment schon
                   zur Verfügung.
                   Achtung: Die Angabe des Pfades zu den Systemdateien
                   (C:\NWDOS\) sollte nicht vergessen werden: Sie sorgt
                   auch ohne spätere Verwendung des PATH-Kommandos oder der
                   %Path% Variable dafür, daß %Path% wenigstens das System-
                   verzeichnis einschließt, damit man auf einem jung-
                   fräulichen System überhaupt erst mal loslegen kann.

                   Diese Direktive wird erst beim Verlassen der CONFIG.SYS
                   wirksam, wenn der Kommandoprozessor (COMMAND.COM) geladen
                   werden soll. Lädt man den Kommandoprozessor COMMAND.COM
                   schon vorher per INSTALL= (dauerhaft oder temporär), so
                   hat SHELL= keinen Einfluß darauf.
                   Achtung: Wurde COMMAND.COM einmal geladen (auch, falls
                   nur temporär), ist die Größe der Umgebung damit festge-
                   legt und gilt auch für den Kommandoprozessor, der beim
                   Verlassen der CONFIG.SYS geladen wird (was in den aller-
                   meisten Fällen dazu führt, daß bei späteren SET-Befehlen
                   Überlauffehler auftreten.)

    STACKS [=] n [, s] [comments]             n=<0> | 8..64,
                                              s=<0> | 32..512 <128>

                   Für Original IBM-PC und PC/XT reicht 0,0, ansonsten
                   sollte man z.B. 9,128 angeben (häufig funktioniert aber
                   auch 0,0). In Verbindung mit MS Windows wird häufig 9,256
                   empfohlen, womit man in jedem Fall genug Sicherheits-
                   reserven hat.

                   Obwohl DR DOS 6.0 ebenfalls eine STACKS= Direktive (und
                   DR DOS 3.41 und 5.0 eine vergleichbare STACK= Direktive)
                   kannte, waren diese (zumindest bis zur Originalausgabe
                   von DR DOS 6.0 von 1991) nur ein Kompatibilitäts-Dummy
                   und wurden exakt wie REM= behandelt. Der Grund lag
                   einfach darin begründet, daß DR DOS zu großen Teilen
                   reenterant programmiert ist. Bei einigen Programmen
                   (z.B. Ventura Publisher), die mit dieser Möglichkeit
                   nicht rechneten und in inkompatibler Weise Stacks in
                   Eigenregie einrichteten, konnte aber diese eigentlich
                   so positive Eigenschaft Probleme bereiten. Diese Probleme
                   sind ist jedenfalls mit Novell DOS 7 durch explizite
                   Angabe von STACKS= weggefallen.

                   Die mit MS-DOS 7 (MS Windows95/Chicago) später einge-
                   führte Direktive STACKSHIGH= wird von Novell DOS 7
                   (Update 15) nicht unterstützt. Wie bekannt, kann man
                   das Gleiche auch mit DOS=HIGH,UMB und 'normalem'
                   STACKS= erreichen.

    SWITCHES [=] [/N] ([/F] [/K])

               /N  Dieser bei Novell DOS undokumentierte Parameter unter-
                   bindet die <F5>- und <F8>-Möglichkeit während des
                   Bootens. Diese Tasten werden während der Startmeldung
                   'Starten von DOS' abgefragt und zur späteren Verwendung
                   aufgezeichnet.
                   Da innerhalb von IBMBIO.COM <Ctrl>+<F5> bzw. <Shift> wie
                   <F5> und <Ctrl>+<F8> wie <F8> behandelt werden, gilt für
                   diese Tasten in diesem Zusammenhang das Gleiche. Aller-
                   dings ist es über die sog. Preload-Schnittstelle möglich,
                   daß bereits vor der Bearbeitung der CONFIG.SYS weitere
                   Spezialtreiber wie DBLSPACE, DRVSPACE oder STACKER ge-
                   laden werden. Zumindest für DBLSPACE und DRVSPACE ist
                   gesichert, daß diese Online-Kompressoren die Tasten-
                   kombination (mit <Ctrl>) für sich als Hinweis auswerten,
                   sich nicht zu installieren (wahrscheinlich gilt das auch
                   für STACKER). Näheres in Kapitel II.2.
                   Die Einstellung der SWITCHES= Direktive wird in dem
                   Moment wirksam, in dem sie vom Parser bearbeitet wird.
                   Wurde also bereits vorher eine der obigen Tasten aufge-
                   zeichnet, so wird diese Aufzeichnung ab sofort für
                   ungültig erklärt.

                   Dieses Verhalten hat seine Vor- und Nachteile, in jedem
                   Fall ist es flexibler als das von MS-DOS:
                   Dieser Schalter stellt z.B. eine Ausnahme von der obigen
                   Regel dar, daß die CONFIG.SYS Datei entsprechend der
                   logischen Abfolge bearbeitet wird: Novell DOS sucht
                   zuerst einmal (unbeachtet von Verzweigungen) die gesamte
                   Datei nach dieser Direktive ab.
                   Wenn Sie SWITCHES= /N in die erste Zeile setzen,
                   passiert das Gleiche wie bei MS-DOS, weil dann eine
                   evtl. gedrückte Funktionstaste sofort wieder gelöscht
                   wird. Auf den ersten Blick gibt es hier eine Sicher-
                   heitslücke, daß bei <F8> auch eine Frage der Art
                   "SWITCHES=/N (J/N)?" erscheint, allerdings wird dies
                   intern abgefangen, solange die SWITCHES= Direktive
                   nicht ?SWITCHES=/N heißt.

                   Steht diese Anweisung aber nicht in der ersten Zeile,
                   weicht das Verhalten signifikant ab:

                   Solange weder <F5> noch <F8> gedrückt werden, bleibt das
                   Verhalten logischerweise ganz normal. Wurde jedoch eine
                   der beiden Funktionstasten gedrückt, spielt nun die beim
                   Vorab-Scan der Datei gefundene Position der Direktive
                   SWITCHES=/N eine große Rolle.
                   Wurde <F5> oder <F8> gedrückt, wird die CONFIG.SYS Datei
                   trotz /N bis zum Vorkommen der SWITCHES=/N Direktive ent-
                   sprechend <F5> oder <F8> übersprungen oder im Einzel-
                   schrittbetrieb durchlaufen. Erst nachdem die SWITCHES=/N
                   Zeile passiert wurde (was im <F8>-Betrieb nicht unbedingt
                   mehr der Fall sein muß), wird <F5> oder <F8> ignoriert
                   und die restliche Datei ganz normal bearbeitet.

                   Höchstwahrscheinlich handelt es sich bei diesem Verhalten
                   um einen Bug (getestet bis Update 14) und weniger um ein
                   verstecktes Feature, daher sollte man sich nicht darauf
                   verlassen, daß dieses Verhalten auch in Zukunft so
                   bleibt.
                   Bei trickreicher Verwendung kann das seltsame Verhalten
                   aber auch ein echtes Feature sein, indem man einen
                   Sonderfall anspringen läßt (nämlich dann, wenn Sie die
                   SWITCHES= Anweisung an einer Stelle platzieren, die durch
                   den normalen Ablauf nie erreicht würde. Sie können dann
                   in der Zeile nach der SWITCHES= Anweisung einen Sprung-
                   befehl schreiben, der in den Sonderfall verzweigt).
                   Leider kann das auch Verwirrung stiften, indem nun alle
                   Fallunterscheidungen durchgearbeitet werden, da
                   Novell DOS von der Existenz eines Boot-Menüs nichts
                   mitbekommen hat.
                   Achtung: Wegen der fehlenden Überbrückungsmöglichkeit
                   besteht mit SWITCHES=/N die Gefahr, daß der Rechner in
                   einer Endlosschleife hängenbleibt, falls die GOTO=,
                   GOSUB=, SWITCH= oder RETURN= Anweisungen so verknüpft
                   werden, daß die Bearbeitung immer wiederholt wird.
                   Hier wäre ein CONFIG.SYS Pre-Compiler wie bei MS-DOS
                   sinnvoller, denn damit könnte eine derartige Situation
                   verhindert werden.

             (/F)  Unterdrückt bei MS-DOS die 2 Sekunden Pause während der
                   Anzeige der Meldung 'Starten von DOS...'. Novell DOS 7
                   wartet immer 2 Sekunden, falls nicht schon vorher eine
                   Taste gedrückt wurde. Hat bei Novell DOS (zumindest bis
                   Update 15) keine Funktion, könnte sich aber in Zukunft
                   ändern, denn intern sind alle Voraussetzungen dafür
                   bereits vorbereitet und könnten mit einem minimalen
                   Patch realisiert werden.

             (/K)  Dieser MS-DOS Schalter zum Unterdrücken erweiterter
                   Tastaturen wird bei Novell DOS ebenfalls nicht unter-
                   stützt. Novell DOS 7 entscheidet bei Laden von
                   IBMBIO.COM anhand der BIOS-Flagge 'erweiterte Tastatur',
                   ob erweiterte INT16h Calls verwendet werden oder nicht.
                   Sollte es Ihnen gelingen, diese Flagge vorher zu löschen,
                   arbeitet Novell DOS nur mit den Calls für Standard-
                   tastaturen. (Bei DR DOS 6.0 war SWITCHES= noch nicht
                   vorhanden.) Auch dieser Schalter wäre mit einem minimalen
                   Patch bei Novell DOS 7 (Update 15) implementierbar, da
                   alle Voraussetzungen dafür bereits erfüllt sind.

                   MS-DOS 7 (MS Windows95/Chicago) unterstützt einen neuen
                   /E:value Schalter, den Novell DOS 7 (Update 15) nicht
                   unterstützt, der dort aber auch überflüssig ist.

    YESCHAR [=] x [comments]   x=<J|Y|O|S> je nach 'Land der Kernelfassung'>

                   Diese undokumentierte Direktive stellt das Zeichen x als
                   Bestätigung für 'Ja' in den [J/N] Abfragen bei IBMBIO.COM
                   ein. Wenn Sie mit amerikanischen Updates arbeiten, er-
                   scheint sonst [Y/N].
                   Dies kann mit YESCHAR=J für deutsche Rechner kompensiert
                   werden. (Wird leider derzeit nur innerhalb von CONFIG.SYS
                   ausgewertet. War bei DR DOS noch nicht vorhanden.)
                   Die Groß- und Kleinschreibung von Buchstaben ist uner-
                   heblich. Das optionale Gleichheitszeichen erfordert hier
                   meistens, daß das Zeichen verdoppelt wird, wenn man ein
                   Gleichheitszeichen als 'Ja' angeben wollte.
                   Abhilfe für das Gesamtsystem ist nur durch Patchen des
                   Kernels möglich, siehe Kapitel II.13.
                   Die impliziten Auswirkungen dieser Direktive werden be-
                   sonders im Zusammenhang mit den undokumentierten Möglich-
                   keiten von ?= und TIMEOUT= deutlich. Bei entsprechender
                   Konfiguration ist es quasi möglich, das Verhalten aus der
                   Sicht des Anwenders zu invertieren.


    ii. Laden von Gerätetreibern und TSR-Programmen:
    ------------------------------------------------

    Kann ein Treiber nicht geladen werden, tritt während des Ladens ein
    Fehler auf (erweiterter Errorcode). Ansonsten setzt das geladene
    Programm einen Exitcode (meist wird '0' für 'Alles ok' verwendet).
    Diese Codes kann man innerhalb der CONFIG.SYS Datei verarbeiten.
    Novell DOS (und teilweise auch schon DR DOS 6) stellt eine Reihe
    undokumentierter Direktiven (etwa ONERROR=, ERROR=) zur Verfügung,
    mit denen man damit flexibel auf solche Zustände reagieren kann.

    Sowohl bei den DEVICE...= als auch bei den INSTALL...= Direktiven muß
    der komplette Pfad inkl. der Dateiendung angegeben werden, ansonsten
    wird das Programm nicht geladen (ohne, daß eine Fehlermeldung angezeigt
    würde). Dies gilt auch, wenn die angegebene Datei nicht existiert (in
    diesem Fall gibt MS-DOS meines Wissens eine Fehlermeldung aus). Dieses
    Verhalten kann von Vorteil sein, wenn man eine Datei laden möchte, die
    nicht immer vorhanden/erreichbar ist. In den "Aus"-Phasen wird dann
    keine störende Meldung ausgegeben. Dies funktioniert praktischerweise
    auch bei Zugriffen auf die Floppy-Laufwerke, auch wenn keine Diskette
    eingelegt ist. Mit einem Trick (Verwendung von INSTCDEX.EXE) können
    Sie sogar Treiber direkt von CD-ROMs laden, was normalerweise nicht
    möglich ist, da ein CD-ROM-Umadressierer (wie NWCDEX) sonst erst in
    AUTOEXEC.BAT geladen werden kann.

    Die Dateiendung spielt bei den DEVICE...= Direktiven keine Rolle (Sie
    können also auch ausführbare Dateien laden, wenn diese z.B. die Endung
    .BIN, .OVL, .EXE, .COM haben), entscheidend ist der Aufbau der Datei.
    Üblicherweise haben Gerätetreiber aber die Dateiendung .SYS (aber es
    gibt auch andere Dateien, die - obwohl sie keinen Binär-Code enthalten -
    die Endung .SYS haben, etwa CONFIG.SYS, COUNTRY.SYS, usw.)
    Wenn Sie Treiber mit anderen Endungen als .SYS per DEVICE= laden
    wollen, sollten Sie dies nur tun, wenn die Dokumentation dies aus-
    drücklich erlaubt. Wenn z.B. eine .EXE- oder .COM-Datei nicht einen
    speziellen Dateikopf, wie er für Gerätetreiber üblich ist, integriert
    hat, wird der Rechner abstürzen. Es gibt aber (wenige) Treiber und
    Programme, die einen dualen Dateikopf haben und in beiden Fällen
    geladen werden können. Manchmal unterscheidet sich sogar das Verhalten
    des Treibers zwischen beiden Ladevarianten (z.B. EMM386.EXE).

    Bei Novell DOS/DR DOS werden die Treiber in der Reihenfolge geladen,
    in der sie im Rahmen ihrer CONFIG.SYS Abarbeitung vorkommen (MS-DOS/
    PC-DOS arbeitet hier anders und lädt Treiber per DEVICE= etc. vor
    denen, die per INSTALL= geladen werden.) Dies ist wichtig, da dadurch
    die Reihenfolge der geladenen Programme total differieren kann.
    Allerdings lassen sich mit Novells Lösung einige Tricks bewerk-
    stelligen, die unter MS-DOS/PC-DOS völlig unmöglich sind.

    DEVICE[=] driver [params]
    HIDEVICE[=] [SIZE=hexsize] [=] driver [params]
    DEVICEHIGH[=] [SIZE=hexsize] [=] driver [params]
    DEVICEHIGH[=] [/L:reg[,minsize][;reg[,minsize][;...]]] [/S]] ...
                                                      ... [=]driver [params]

                   Die alte DR DOS Direktive HIDEVICE= wird weiterhin un-
                   dokumentiert unterstützt und identisch zu DEVICEHIGH=
                   behandelt. Für die optionale Angabe hexsize (in Bytes)
                   sind Werte von 00000..FFFFF erlaubt, intern wird dies
                   jedoch auf Paragraphen (á 16 Bytes) aufgerundet.
                   Näheres zu DEVICE= und DEVICEHIGH= in Kapitel III.4.

                   Kann ein Gerätetreiber nicht geladen werden, so wird die
                   interne Fehlervariable (siehe ONERROR=) auf den Fehler-
                   code der Funktionen INT21h/3D00h, INT21h/4202h bzw.
                   INT21h/3Eh gesetzt. Diese Fehlercodes entsprechen in
                   ihrer Nummerierung den sog. erweiterten Fehlercodes,
                   die man auch über INT21h/59h erhalten könnte.
                   Tritt ein Fehler *während* der Initialisierung des
                   Treibers (d.h. unter der Kontrolle des bereits geladenen
                   Treibers) auf, so bekommt die Fehlervariable einen Wert
                   mit gesetztem Bit15 und dem Inhalt der Bits7-0 des
                   Statuswortes (Offset +03h im Device Request Header),
                   das der Gerätetreiber zurückliefert, zugewiesen. Das
                   bedeutet, daß die Treiber-Returncodes 0..255 auf
                   32768..33023 umgemappt werden. Da diese Fehlercodes
                   üblicherweise als erweiterte DOS-Fehlercodes nicht
                   belegt sind, kann man bei ONERROR= zwischen Fehlern
                   vor oder während der Treiberinitialisierung unter-
                   scheiden.

                   Beispiele für erweiterte Fehlercodes (vor der Init):
                    (im Bereich 0..65535, jedoch üblicherweise kleiner 256,
                     weitere Codes wie bei INT21h/59h.)

                     0 = kein Fehler
                     1 = Ungültige Funktion
                     2 = Datei nicht gefunden
                     3 = Pfad nicht gefunden
                     4 = Zu viele offene Dateien (keine Handles frei)
                     5 = Zugriff verweigert
                     6 = Ungültiges Handle
                    12 = Ungültige Zugriffsrechte
                    86 = Ungültiges Paßwort

                   Beispiele für Returncodes des Treibers nach der Init
                    (Codes 0..255 umgemappt auf 32768..33023):

                    32768  (0) = Medium schreibgeschützt
                    32769  (1) = Gerätenummer unbekannt
                    32770  (2) = Gerät nicht bereit
                    32771  (3) = Funktion ist nicht definiert
                    32772  (4) = CRC-Fehler
                    32773  (5) = ungültiger Parameterblock
                    32774  (6) = Spur nicht gefunden
                    32775  (7) = unbekanntes Speichermedium
                    32775  (7) = Sektor nicht gefunden
                    32776  (8) = kein Papier im Drucker
                    32777  (9) = Schreibfehler
                    32778 (10) = Lesefehler
                    32779 (11) = allgemeiner Fehler
                    32780 (12) = reserviert
                    32781 (13) = reserviert
                    32782 (14) = unerlaubter Diskettenwechsel

                   Da die Fehlervariable, die innerhalb von CONFIG.SYS ver-
                   wendet wird, zweier Herren Diener ist, kann man Doppel-
                   deutigkeiten nicht ganz ausschließen; trotzdem kann
                   aufgrund einer glücklichen Fügung üblicherweise doch sehr
                   einfach zwischen den Fehlercodes (aus der Sicht von
                   IBMBIO.COM) unterhalb 32768 und den Fehlerrückgabewerten
                   (aus der Sicht des Treibers) von 32768..33023 unter-
                   schieden werden. Eine dritte Möglichkeit wäre zwar theo-
                   retisch möglich, nämlich die Rückgabe eines von Null ver-
                   schiedenen Codes bei fehlerfreier Initialisierung des
                   Treibers, aber da dies in den DOS-Standards undefiniert
                   ist, wird es folgerichtig auch nicht angeboten (es würde
                   in den meisten Fällen nur Zufallsresultate liefern). Zu
                   beachten ist, daß Fehlercodes, die in der Dokumentation
                   eines Treibers angegeben werden (üblicherweise 0..255),
                   in *dieser* Übersicht als Returncodes des Treibers zu
                   verstehen sind. Diese Codes finden Sie daher innerhalb
                   der CONFIG.SYS an den Codes 32768..33023 (+32768) wieder.

    INSTALL[=] program [params]
    HIINSTALL[=] program [params]
    INSTALLHIGH[=] program [params]

                   INSTALL= wurde ursprünglich nur vorgesehen, um bestimmte
                   Programme des Betriebssystems früher als sonst möglich
                   zu laden. An eine praktische Möglichkeit zur generellen
                   Verwendung für Fremdtreiber hatten die Entwickler offen-
                   bar zunächst nicht gedacht. Dies ist auch nicht ver-
                   wunderlich, denn in frühen DOS-Versionen war das System
                   während der Bearbeitung der CONFIG.SYS Datei noch
                   so minimal funktionsfähig, daß viele der Interrupt-
                   Funktionen, die TSRs und andere Programme normalerweise
                   aufrufen, offiziell noch nicht definiert waren (vgl.
                   Spezifikation für Programmierung von Gerätetreibern).
                   In der Praxis waren (insbesondere bei DR DOS gegenüber
                   MS-DOS) viele der kritischen Funktionsausrufe auch schon
                   innerhalb von CONFIG.SYS problemlos möglich, so daß im
                   Endeffekt fast alle Programme schon in CONFIG.SYS geladen
                   werden konnten. Es gibt wirklich nur sehr wenige Pro-
                   gramme, die aus verschiedenen Gründen noch *nicht* in
                   CONFIG.SYS geladen werden können.
                   Außerdem werden die per INSTALL= etc. geladenen Treiber
                   bei MS-DOS/PC-DOS sowieso nach den per DEVICE= etc.
                   geladenen Treibern geladen, so daß der Vorteil von
                   INSTALL= sich darauf reduziert, Programme vor der Shell
                   (COMMAND.COM) zu laden, was - für sich genommen - nur
                   selten wirklich notwendig ist. Bei DR DOS und Novell DOS
                   sieht die Sache allerdings völlig anders aus: Dadurch,
                   daß Sie hier - aus Sicht des Betriebssystems - völlige
                   Wahlfreiheit in der Ladereihenfolge haben, können Sie
                   INSTALL= auch für viele andere Dinge 'mißbrauchen':

                   Näheres zu INSTALL= in Kapitel III.5 (z.B., daß man nicht
                   unbedingt residente Software laden muß, sogar die Ab-
                   arbeitung von Batchjobs als Unterroutinen von CONFIG.SYS
                   ist problemlos möglich. INSTALL= taugt auch prima zum
                   Debuggen von erst später per DEVICE= zu ladenden Geräte-
                   treibern.).
                   Bezüglich der Umgebung und Möglichkeiten, Speicherplatz
                   zu sparen, siehe auch bei SET=, insbesondere bezüglich
                   des Utilities SETENV.COM, auch bei LH in Kapitel II.11.

                   Die alte DR DOS Direktive HIINSTALL= wird weiterhin un-
                   dokumentiert unterstützt und dabei seltsamerweise nicht
                   wie INSTALLHIGH=, sondern wie INSTALL= behandelt
                   (getestet bis Novell DOS 7 Update 14, spätestens bei
                   Caldera OpenDOS 7.01 wurde dies jedoch korrigiert).
                   INSTALL= und HIINSTALL= werden auch von CCI Multiuser DOS
                   7.22 unterstützt, dort kann man angeblich bei HIINSTALL=
                   auch die von HIDEVICE= bekannte Option SIZE=hhhh angeben,
                   die DR DOS und Novell DOS *hier* nicht kennen.

                   INSTALLHIGH= wird nun auch von MS-DOS 7 (MS Windows95/
                   Chicago) unterstützt. MS-DOS 6.22 bot diese Möglichkeit
                   noch nicht.

                   Nach der Ausführung der INSTALL= etc. Direktive ermittelt
                   IBMBIO.COM im Falle eines signalisierten Fehlers (aus der
                   Sicht von IBMBIO.COM) über INT21h/59h den "erweiterten
                   Fehlercode" (0..65535), oder andernfalls über INT21h/4Dh
                   den "erweiterten" Returncode des Treibers, dessen Low-
                   Byte exakt dem Code entspricht, den auch ERRORLEVEL
                   zurückliefern würde. Dieser Wert wird in beiden Fällen
                   16-bittig in die CONFIG.SYS Fehlervariable eingetragen,
                   die mittels ONERROR= in CONFIG.SYS abgefragt werden kann.
                   Für den üblichen Fall, nämlich, daß in CONFIG.SYS per
                   INSTALL= etc. nur residente Treiber geladen werden,
                   ergibt sich hier - ähnlich wie bei DEVICE= - trotz
                   Doppelnutzung einer Variablen eine gute Unterscheidungs-
                   möglichkeit, nur nicht mit einer Grenze bei 32768
                   (Bit15 gesetzt), sondern mit einer 'fließenden' Grenze,
                   die bei 256 (Bit8 gesetzt) beginnt. Für den Fall, daß
                   man mit INSTALL= Programme aufruft, die nicht resident
                   bleiben, ergibt sich allerdings das Problem, daß dann
                   beide Kategorien von Fehlercodes bei 0 beginnen und
                   nicht mehr voneinander unterschieden werden können.
                   In diesem Fall empfehle ich, die Auswertung in erster
                   Linie auf die Returncodes des Treibers auszurichten,
                   da diese sehr viel wahrscheinlicher andere Werte als 0
                   liefern und sinnvoller verwendbar ist, als die meist
                   nur sporadisch auftretenden erweiterten Fehlercodes des
                   Betriebssystems. Die ERRORLEVEL Werte finden Sie
                   (manchmal) in der Dokumentation des jeweiligen Pro-
                   gramms; einige Werte werden auch in dieser Datei bei
                   der Beschreibung des jeweiligen Kommandos aufgelistet.
                   Andererseits hat diese Methode auch den Vorteil, daß
                   Sie die Returncodes im Fall ordnungsgemäßer Ausführung
                   exakt so für die Auswertung per ONERROR= übernehmen
                   können, wie sie in der Dokumentation des jeweiligen
                   Treibers (üblicherweise für den COMMAND.COM Prompt)
                   angegeben wurden.

                   Beispiele für erweiterte Fehlercodes:

                    (im Bereich 0..65535, jedoch üblicherweise kleiner 256,
                     weitere Codes wie bei INT21h/59h.)

                     0     = kein Fehler
                     sonst = (siehe weiter oben bei DEVICE=)

                   Beispiele für Returncodes des Treibers (High-Byte):

                     0      = normale Ausführung       (->   0 .. 255)
                     1      = Abbruch durch <Ctrl>+<c> (-> 256 .. 511)
                     2      = Kritischer Abbruch       (-> 512 .. 767)
                     3      = Resident installiert     (-> 768 ..1023)

                   Beispiele für Returncodes des Treibers (Low-Byte):

                     Wie ERRORLEVEL im Bereich 0..255, werden bei Fehler-
                     zuständen oder (üblicher) residenter Installation je-
                     doch auf 256..511, 511..767 oder 768..1023 umgemappt.


    iii. Kommentare, Meldungen, Bildschirmsteuerung:
    ------------------------------------------------

    :label [=] [comments]

                   Labels (Sprungmarken) müssen mit einem Doppelpunkt in der
                   ersten Spalte eingeleitet werden. Nach der Angabe des
                   Label-Namens (maximal 8 Zeichen werden unterschieden, bis
                   zum ersten Leerfeld), können dann noch weitere Kommentare
                   folgen, die bei der Bearbeitung einfach ignoriert werden.
                   Damit kann eine Marke im Prinzip genauso aussehen wie ein
                   Kommentar, und in der Tat: Frühere DOS-Versionen kannten
                   noch keine REM[=] etc. Direktive. Hier konnte man sich
                   dadurch behelfen, daß man die Kommentare in Marken-Zeilen
                   geschrieben hat, deren Namen niemals als Sprungziele
                   benutzt wurden.

    ; [=] [comments]
    REM [=] [comments]
    [COMMON] [=] [comments]

                   Kommentare können, wie gewohnt, mit REM[=] oder ;[=] an-
                   gegeben werden. Bezüglich [COMMON] (mit eckigen Klammern)
                   siehe auch den folgenden Abschnitt. Die von MS-DOS 6.0+
                   undokumentiert unterstützte Direktive COMMENT=, die
                   identisch mit REM ist, wird von Novell DOS 7 nicht unter-
                   stützt.
                   Hinweis: Das Semikolon ';' wird von "Bert's Boot Box"
                   (s.o.) als Einleitung für Meta-Befehle zur Gestaltung
                   seiner Boot-Menüs verwendet, wodurch sich die Benutzung
                   für normale Kommentare ausschließt.

    ECHO [=] [message]

                   Diese Direktive dient der Ausgabe von Meldungen (via
                   BIOS-Funktionen) und zur Gestaltung von Konfigurations-
                   menüs. "ECHO ON|OFF" und "ECHO." arbeiten nicht in
                   CONFIG.SYS.
                   Leerzeilen erzeugt man einfach dadurch, daß man keinen
                   Meldungstext angibt. Es sind beliebige Zeichen erlaubt,
                   '>', '<' und '|' haben noch nicht ihre spätere Bedeutung.
                   Näheres siehe in Kapitel III.3.

    CLS [=] [comments]

                   Diese Direktive löscht den Bildschirm, indem sie den
                   aktuellen Bildschirmmodus holt und sofort wieder setzt
                   (dabei wird bei Modi unterhalb 128 der Bildschirm ge-
                   löscht). Das Verhalten unterscheidet sich insofern vom
                   *Befehl* CLS (der von COMMAND.COM zur Verfügung gestellt
                   wird), als daß in der CONFIG.SYS noch keine andere
                   Möglichkeit zum Bildschirmlöschen besteht. Die er-
                   weiterten Möglichkeiten des COMMAND.COM Befehls CLS
                   (z.B. mit %$Cls%) sind in Kapitel II.11., IV.7. und
                   in DRDOS6UN.TXT beschrieben. Außerdem wird alles nach
                   dem CLS= Befehl ignoriert, kann also für Kommentarzwecke
                   verwendet werden.

    CPOS [=] [line[, column]]           line=0, <1>..255, column=0, <1>..255

                   Die Direktive setzt ohne Angabe von Parametern den
                   Cursor auf die Position (1,1) (obere linke Ecke).
                   Es gibt jedoch die Möglichkeit, zusätzlich noch ein oder
                   zwei Parameter für die gewünschten Koordinaten der neuen
                   Cursor-Position anzugeben. Wird ein Wert nicht angegeben,
                   wird jeweils 1 angenommen.
                   Entgegen der Anleitung sind Werteangaben von 1..255
                   möglich.
                   Die jeweiligen Maximalwerte hängen vom eingestellten
                   Textmodus ab und sollten nicht überschritten werden
                   (je nach BIOS kann der Cursor sonst an einer völlig
                   falschen Position erscheinen).
                   Gibt man den Wert 0 für einen Parameter an, so wird der
                   Cursor außerhalb des sichtbaren Bereichs an die
                   'Position 256' gesetzt. Mit (0,0) kann man den Cursor
                   meist ganz verschwinden lassen. Das exakte Verhalten
                   hängt jedoch auch vom BIOS ab, das den Wert außerhalb
                   des gültigen Bereichs u.U. auf den Maximalwert reduziert
                   (damit wäre (0,0) dann die rechte untere Ecke).


    iv. Benutzereingaben, Zeitsteuerung, Default-Verhalten:
    -------------------------------------------------------

    TIMEOUT [=] seconds [,query_answer [,switch_answer [comments]]]

                   seconds=<0>, 1..65535
                   query_answer=ASCII-char  <'N'> (außer 0Ah und 0Dh)
                   switch_answer=ASCII-char <'1'> (außer 0Ah und 0Dh)

                   Diese Direktive zur Einstellung der Zeitschranke für
                   ?=, SWITCH= und GETKEY= Direktiven bietet offiziell nur
                   die Möglichkeit, die Wartezeit seconds anzugeben. Wird
                   eine Zeitschranke von 0 angegeben, so wird die Zeit-
                   schrankenautomatik deaktiviert, d.h. es wird effektiv
                   auf einen Tastendruck gewartet.

                   Undokumentiert ist jedoch, daß TIMEOUT= darüber hinaus
                   noch zwei weitere Angaben zuläßt:

                   Die erste Angabe query_answer spezifiziert die anzu-
                   nehmende Default-Antwort auf die Ja/Nein-Fragen bei ?=
                   oder während des <F8>-Einzelschrittmodus. Als Default
                   gilt hier 'N', d.h. nach Ablauf der Zeitschranke wird
                   eine ?= Frage automatisch mit 'N' beantwortet, d.h.
                   die entsprechende Direktive ignoriert. Dies entspricht
                   i. allg. dem gewünschten Verhalten. (Hierzu siehe auch
                   Kapitel II.2.)
                   Grundsätzlich kann hier aber jeder beliebige andere Wert
                   angegeben werden. Möchte man, daß nach Ablauf des Time-
                   outs eine ?= Frage automatisch mit 'Ja' beantwortet wird,
                   so muß man hier als Default-Wert ein 'J', bzw. den ent-
                   sprechenden YESCHAR= Wert angeben (in der Ausgabe der
                   entsprechenden Ja/Nein-Frage wird allerdings nur das 'J'
                   durch das per YESCHAR= gesetzte Zeichen ersetzt, das 'N'
                   bleibt hingegen auch erhalten, wenn man query_answer
                   ändert).
                   Der dritte Parameter switch_answer erlaubt - analog zum
                   zweiten Parameter - die Vorgabe einer Default-Antwort für
                   SWITCH= Eingaben. Normalerweise wird hier '1' angenommen,
                   was bewirkt, daß nach Ablauf der Zeitschranke automatisch
                   zur ersten Marke von SWITCH= gesprungen wird (und damit
                   z.B. den ersten Menüpunkt wählt). Als grundsätzlich
                   gültige Eingaben werden bei SWITCH= nur '0'..'9' akzep-
                   tiert, trotzdem kann man *hier* durchaus auch andere
                   Werte angeben.
                   Durch Übersteuern des Default-Wertes läßt sich etwa
                   das von MS-DOS her bekannte Verhalten MENUDEFAULT=
                   simulieren, indem nach Ablauf der Zeitschranke standard-
                   mäßig ein anderer Menüpunkt gewählt wird. Aber die
                   Implikationen, die eine veränderte Einstellung mit
                   sich bringt, werden besonders deutlich, wenn man sich
                   das genaue Verhalten von SWITCH= näher betrachtet.
                   Es ist möglich, die Zeitschrankenfunktion für SWITCH=
                   zu unterbinden (gleichzeitig aber für ?= aktiv zu
                   lassen), indem ein für die jeweilige SWITCH= Zeile
                   ungültiger Wert als Default-Antwort gewählt wird
                   (z.B. 'X'). Ist diese Verhalten nicht gewünscht,
                   sollte man darauf achten, daß die Zahl, die der
                   SWITCH= Eingabe entspricht, auch wirklich mit einem
                   existierenden Sprungmarke verknüpft ist.

                   Um die Möglichkeiten von TIMEOUT= auszunutzen, muß
                   diese Direktive u.U. relativ häufig dicht hintereinander
                   aufgerufen werden. Dabei ist zu beachten, daß nur die
                   Werte mit den neuen Einstellungen belegt werden, die in
                   der TIMEOUT= Zeile auch angegeben werden. Auf diese
                   Weise kann man z.B. den Default-Wert für ?= Fragen
                   oder die Verzögerung der Zeitschranke ändern, ohne den
                   Default-Wert für SWITCH= angeben zu müssen. In manchen
                   Fällen ist es wichtig, daß man eben diese Angaben nicht
                   jedesmal wiederholen muß.
                   Gibt man TIMEOUT= ohne Parameter an, so wird die Warte-
                   zeit wieder auf unendlich zurückgestellt.

                   Achtung: Das trennende Komma zwischen den einzelnen
                   Werten von TIMEOUT= ist optional, wird es aber angegeben,
                   so darf nach dem Komma kein weiteres Leerzeichen folgen,
                   sonst wird dieses Leerzeichen fälschlicherweise als das
                   gewünschte ASCII-Zeichen für die Default-Antworten
                   interpretiert.

    ? [=] ["message"] directive [params]

                   Diese Frage - bei DR DOS und Novell DOS 7 steht das
                   Fragezeichen üblicherweise vor dem Befehl, bei MS-DOS/
                   PC-DOS wird dies zurückgewiesen - erlaubt es, die Aus-
                   führung der angegebenen beliebigen Direktive abhängig
                   von der Antwort auf eine Frage zu machen. Typischerweise
                   handelt es sich dabei um eine Ja/Nein-Frage ohne Zeit-
                   beschränkung (abhängig von TIMEOUT=). Wird die Frage
                   mit der Taste für 'Ja' (YESCHAR=) beantwortet, so wird
                   die angegebene Direktive ausgeführt, andernfalls wird
                   die Zeile übersprungen (es ist also nicht notwendig,
                   explizit mit 'Nein' zu antworten). Sobald aber mit
                   TIMEOUT= eine Zeitschranke definiert wurde, wird nach
                   deren Ablauf automatisch die dort angegebene Default-
                   Antwort (query_answer) gewählt (normalerweise 'N').

                   Praktisch an der ?= Direktive ist, daß sie automatisch
                   die zugehörige Zeile mit "(J/N) ?"-Frage anzeigt, wenn
                   man nicht explizit ein Meldung angegeben hat. Interessant
                   ist diese Variante deshalb, weil sie automatisch die
                   richtigen Zeichen für (J/N) darstellt (abhängig von
                   der Landesversion von IBMBIO.COM). Der 'Ja'-Buchstabe
                   kann mit der Direktive YESCHAR= übersteuert werden.
                   Zwar wird man meist die Einstellung YESCHAR=J wählen,
                   aber in Einzelfällen lassen sich über Änderungen von
                   YESCHAR= auch ganz andere Fragen verwirklichen.
                   Es muß nämlich nicht so sein, daß man in einer Situation
                   eine typische Ja/Nein-Entscheidung möchte. Da aber der
                   'Nein'-Wert nicht verstellt werden kann, stört in diesem
                   Fall die automatisch generierte Frage. Sobald man aber
                   selbst einen Meldungstext definiert ("message" in Gänse-
                   füßchen), erscheint dieser Text anstelle der Frage.
                   Natürlich kann man hier auch wieder eine Frage formu-
                   lieren, aber es wäre z.B. auch eine Simulation einer
                   'PAUSE'-Funktion mit Abbruch durch Druck auf 'C' denkbar,
                   etwa:

                    TIMEOUT=10,N
                    YESCHAR=C
                    ? "Bitte warten... (Abbruch mit '<C>ontinue')."
                    YESCHAR=J

                   Wird ein Text angegeben, kann man trotzdem die automa-
                   tische Meldung "(J/N) ?" an diese Meldung anhängen,
                   indem man nach der Meldung ein Fragezeichen schreibt
                   (würde hier "(C/N) ?" ergeben).
                   Da man bei TIMEOUT= auch den Default-Wert für den
                   Timeout-Fall einstellen kann, ist es 'fast' möglich,
                   auch den 'Nein'-Fall umzudefinieren und zumindest aus
                   der Sicht des Anwenders die Bedingung logisch umzudrehen.
                   Nur, um Mal ein Beispiel dafür zu geben:

                    TIMEOUT=10,J
                    YESCHAR=N
                    ? "Heute <n>icht den Viren-Scanner starten?" GOTO skip
                    INSTALL=virusscan...
                    :skip
                    TIMEOUT=10,N
                    YESCHAR=J

                   Das 'Nein' in der Ja/Nein-Frage wird allerdings nicht
                   zum bei TIMEOUT= angegebenen Wert umgeändert (die automa-
                   tisch generierte Frage würde also "(N/N)? " fragen, wenn
                   keine "message" angegeben würde...).

                   Sollte man beim Booten <F8> für Singlestepping gedrückt
                   haben (falls nicht mit SWITCHES=/N deaktiviert), so
                   werden bei den damit implizierten Fragen (d.h. auch ohne
                   explizites ?=) alle Kommentare (REM=, ;=, :=) und
                   SWITCHES= übersprungen. Seltsamerweise gilt dies nicht
                   für [COMMON], das doch bei Novell DOS ebenfalls keine
                   Funktion hat (Update 14). Enthält eine Zeile bereits
                   eine ?= Direktive, so wird auch mit zusätzlichem <F8>
                   nur einmal gefragt.

                   Eine syntaktische Alternative (wie bei MS-DOS/PC-DOS
                   6.xx) besteht darin, das Fragezeichen erst nach einem
                   Befehl (aber noch vor evtl. weiteren Schaltern wie z.B.
                   bei DEVICEHIGH=/HIDEVICE= möglich (/L: und /S) und
                   ebenso vor dem optionalen Gleichheitszeichen) zu setzen.
                   Ein paar Beispiele:

                    ?ECHO Soll dies angezeigt werden (nur DR DOS/Novell DOS)
                    ECHO? Soll dies angezeigt werden (auch MS-DOS/PC-DOS)
                    ?DEVICEHIGH=driver parameter (nur DR DOS/Novell DOS)
                    DEVICEHIGH?=driver parameter (auch MS-DOS/PC-DOS)
                    DEVICEHIGH?/L:2=driver parameter

                   Wie kann man sich dies merken? Einfach so: Denken Sie
                   sich, ?= wäre eine eigenständige und verschachtelbare
                   Direktive wie ONERROR= (s.u.) und nicht einfach eine
                   spezielle Option der normalen Direktiven. Das Gleich-
                   heitszeichen ist auch hier optional.

                   Achtung: Auch später unter COMMAND.COM haben Sie eine
                   Möglichkeit, die Befehlsausführung mit ? variabel zu
                   gestalten. Die Syntax weicht aber in einigen Details
                   leicht ab, siehe Kapitel II.11.

    SWITCH [=] [label1[[,] label2[[,] label3[[,] label4[[,] label5
               [[,] label6[[,] label7[[,] label8[[,] label9[[,] label10
               [[,] label11 [[,] comments]]]]]]]]]]]]

                   SWITCH= ist eine Mischung zwischen GOSUB=, ?= und
                   GETKEY=. Nur ein kleiner Teil der Möglichkeiten dieses
                   Kommandos ist dokumentiert.
                   Normalerweise wird bei SWITCH= kein Errorlevel gesetzt
                   (dies geschieht erst mit dem RETURN=), aber falls eine
                   Marke nicht existiert (und deshalb die Bearbeitung mit
                   der nächsten Zeile fortgesetzt wird), wird ein
                   Errorlevel 0 gesetzt.

                   SWITCH= erlaubt auf den ersten Blick normalerweise die
                   Eingabe einer Zahl, die zwischen <1> und der Anzahl der
                   angegebenen Sprungziele liegt (offiziell nicht mehr als
                   neun: label1..label9). Die möglichen Tastendrücke müssen
                   vorher durch entsprechende ECHO= Ausgaben dem Benutzer
                   mitgeteilt werden. Wird die entsprechende Taste gedrückt,
                   verzweigt SWITCH= per 'GOSUB=' zu der entsprechenden
                   Marke und führt das Unterprogramm aus. Normalerweise
                   wird dies irgendwann einmal mit RETURN= abgeschlossen
                   und es wird in die Zeile nach der SWITCH= Anweisung
                   zurückgesprungen. Dabei ist es - wie wir noch sehen
                   werden - mit RETURN= möglich, einen 'Resultat' zurück-
                   zuliefern, das dann im weiteren Verlauf entsprechend
                   ausgewertet werden kann. Man kann aber auch auf den
                   Rücksprung aus den Unterprogrammen verzichten, wenn man
                   darauf achtet, daß evtl. an anderer Stelle benötigte
                   RETURN= Direktiven nicht versehentlich bearbeitet
                   werden.
                   Wird eine falsche Taste gedrückt, wird diese auf den
                   ersten Blick nicht akzeptiert, d.h. man darf die Eingabe
                   solange wiederholen, bis eine gültige Taste gedrückt ist.
                   Ist mittels TIMEOUT= eine Zeitschranke vereinbart, so
                   ändert sich das Verhalten insofern, als daß diese
                   Schranke mit jedem falschen Tastendruck wieder zurück-
                   gesetzt wird. Wenn aber der Timeout abgelaufen ist,
                   wird als Default-Antwort switch_answer gewählt (das
                   ist normalerweise <1> und daher wird die erste Marke
                   angesprungen).

                   Nun wird es kompliziert:

                   Angenommen, switch_answer ist per TIMEOUT= umdefiniert
                   worden: Liegt nach Ablauf des Timeouts die Default-
                   Antwort im Rahmen der gültigen Zahlen (aus '0'..'9'),
                   so wird die der Zahl entsprechende Marke angesprungen
                   (womit man MS-DOS MENUDEFAULT= simulieren kann).
                   Entspricht die Default-Antwort nicht den gültigen
                   Werten, so wird die Default-Antwort genauso zurück-
                   gewiesen, wie echte Tastendrücke (weil die entsprechenden
                   Marken nicht angegeben wurden). Der Effekt ist, daß man
                   trotz Timeout gezwungen ist, die richtige Taste zur
                   Fortsetzung zu drücken.

                   Hat man bei der SWITCH= Anweisung überhaupt keine Marken
                   angegeben, so kommt man nur weiter, indem man <1> drückt
                   (oder eine <1> als switch_answer nach einem abgelaufenen
                   Timeout simuliert wird). Nun wird dieses nicht existente
                   'Label1' angesprungen, im Endeffekt wird die SWITCH=
                   Zeile übersprungen. Dies gilt auch für andere Sprung-
                   ziele, die zwar bei SWITCH= definiert sind, aber in der
                   Datei nicht existieren (auf diese Weise kann man z.B.
                   Dummy-Sprungziele einfügen, die wir später noch benötigen
                   werden).
                   Drückt man einfach <RET>, so wird automatisch die
                   switch_answer gewählt, also z.B. der per TIMEOUT=
                   definierte Default-Menüpunkt angesprungen.

                   Damit sind auf den ersten und zweiten Blick alle
                   Möglichkeiten sinnvoll ausgeschöpft...

                   Es kommt aber noch besser:

                   SWITCH= akzeptiert nämlich eigentlich grundsätzlich als
                   Eingaben die Zahlen <0> bis <9>. Drückt man <0>, so wird
                   dies derzeit intern zu 11 umgesetzt, da aber diese Marke
                   normalerweise nicht angegeben wird, wird dieser Wert
                   zurückgewiesen. Genauso mit den anderen Tasten.
                   Würden jedoch bis zu elf Marken angegeben werden, so
                   würden diese auch tatsächlich angesprungen werden (und
                   wenn die Marke dann innerhalb der Datei nicht existieren
                   würde, würde die Bearbeitung stattdessen mit der Zeile
                   nach SWITCH= fortgesetzt). Bei diesem Verhalten, daß <0>
                   zu Label 11, statt zu Label 10 verzweigt, handelt es sich
                   mit Sicherheit um einen Bug (getestet bis Update 15), der
                   vielleicht in zukünftigen Versionen behoben ist, so daß
                   die Eingabe von <0> dann die zehnte Marke anspringt.
                   Aus diesem Grund sollte man sicherheitshalber die zehnte
                   und elfte Marke immer mit dem gleichen Sprungziel be-
                   legen.

                   Marken dürfen auch mit '/' als Trennzeichen eingeleitet
                   werden.

                   Möchte man die Zählung der Menüpunkte bei 0 statt bei
                   1 beginnen lassen, benötigt aber weniger als 10 Sprung-
                   ziele, so ergibt sich das Problem, was mit den da-
                   zwischenliegenden Marken zu tun ist, so daß die Eingaben
                   oberhalb des gewünschten Maximums wie gewohnt zurück-
                   gewiesen werden. Hierzu gibt es verschiedene Möglich-
                   keiten, die jedoch alle nicht besonders sauber sind.
                   Schließlich bedeutet dies in jedem Fall, daß man 11
                   Marken angeben muß. Dadurch werden aber <0> sowie
                   <1>..<9> als Eingaben akzeptiert.

                    ECHO Menü: Drücken Sie <0>..<2>!
                    :start
                    SWITCH= l1, l2, d3, d4, d5, d6, d7, d8, d9, l0, l0
                    GOTO start

                    :l0
                    ...
                    EXIT
                    :l1
                    ...
                    EXIT
                    :l2
                    ...
                    EXIT


    GETKEY [=] [comments]

                   Diese undokumentierte Direktive wartet auf einen Tasten-
                   druck und setzt daraufhin den Errorlevel auf den Wert
                   des zugehörigen ASCII-Code der Taste (0..255). Um z.B.
                   den Errorlevel auf 1 zu setzen, muß man nicht etwa <1>
                   drücken (hat Scan-/ASCII-Code 0231h und damit 31h = 49),
                   sondern eine <Alt>-NumPad Eingabe vornehmen, hier z.B.
                   <Alt>=<Alt>+<NumPad1>.
                   Über diese Möglichkeit ist es möglich, auf jede beliebige
                   Taste (für die der Tastaturtreiber ein Zeichen generiert)
                   unterschiedlich zu reagieren (d.h. die Ebenen mit <Shift>
                   und <AltGr> werden i. allg. unterstützt).
                   Sofern keine Zeitschranke mittels TIMEOUT= gesetzt wurde
                   (0), wird effektiv auf den nächsten Tastendruck gewartet.
                   Bei laufendem Countdown wird jedoch die Verzögerung nach
                   Ablauf der Zeitschranke abgebrochen und stattdessen als
                   Default-Errorlevel der Wert 0400h = 1024 gesetzt und
                   nicht etwa eine der mit TIMEOUT= spezifizierten Default-
                   Antworten. (Ab DR DOS 6.0).


    v. Konfigurationsmenüs, Verzweigungen, Blockbildung:
    ----------------------------------------------------

    GOTO [=] [label] [comments]

                   Gibt man hier ein enicht existierende Marke an, so
                   springt GOTO= an das Dateiende der CONFIG.SYS, d.h.
                   die Bearbeitung wird umgehend abgebrochen und ggf.
                   AUTOEXEC.BAT bearbeitet. Fehlt die Angabe einer Marke
                   komplett, springt GOTO= zur letzten Marke, die innerhalb
                   der CONFIG.SYS gefunden werden kann, bzw. falls überhaupt
                   keine Marke existiert, wird die Bearbeitung einfach mit
                   dem nächsten Befehl fortgesetzt. Es besteht die Gefahr
                   von Endlosschleifen, die nicht abgebrochen werden können,
                   außer im Single-Stepping <F8> (falls SWITCHES=/N nicht
                   gesetzt wurde).

    GOSUB [=] [label] [comments]

                   Normalerweise wird bei GOSUB= kein Errorlevel gesetzt,
                   aber falls keine Marke angegeben wurde oder die ange-
                   gebene Marke nicht existiert, wird ein Errorlevel 0
                   gesetzt. In diesem Fall wird die Bearbeitung mit der
                   nächsten Anweisung fortgesetzt. GOSUB=/RETURN= wirkt
                   nicht bis in die Verzweigung in andere Dateien (CHAIN=)
                   hinein.

    RETURN [=] [errorlevel] [comments]                 errorlevel=<0>..65535

                   Nimmt die Bearbeitung mit der Zeile nach dem letzten
                   GOSUB= bzw. SWITCH= wieder auf (kann auch verschachtelt
                   werden).
                   Allerdings bietet die Direktive noch einige undokumen-
                   tierte Spezialitäten, die neue Möglichkeiten eröffnen:
                   Es ist möglich, einen optionalen Errorlevel anzugeben,
                   der als Rückgabewert des Unterprogrammblocks angesehen
                   werden kann.
                   Gibt man keinen Wert an, so wird der Errorlevel auf 0
                   zurückgesetzt. Dadurch ist eine unbeabsichtigte Beein-
                   flussung von auf Errorlevel basierenden Verzweigungen
                   über die Grenzen eines Unterprogrammblocks hinaus ausge-
                   schlossen. Wenn man aber genau diese Funktion benötigt,
                   hat man dafür die Möglichkeit, explizit einen Wert an-
                   zugeben. Durch diese Methode werden auch die vielen
                   möglichen Errorlevel, die innerhalb eines Unterprogramms
                   auftreten können, auf einen Wert, der dann nach außen
                   zurückgeliefert wird, reduziert. Nur durch diese Re-
                   duktion ist es auf der nächsthöheren Ebene möglich, daß
                   Doppelbelegungen bewußt eingeplant oder ausgeschlossen
                   werden.
                   Fehlt zu einem RETURN= das vorherige GOSUB= bzw. SWITCH=,
                   so wird RETURN einfach ignoriert.

    CHAIN [=] filespec [comments]

                   Falls die angegebene Datei existiert, wird die Bear-
                   beitung der aktuellen 'CONFIG.SYS'-Datei beendet und
                   in die neue Datei verzweigt. Die diesbezüglichen
                   Möglichkeiten sind besonders gut für schreibgeschützte
                   oder ROM- oder CD-ROM-Laufwerke geeignet (zur Ein-
                   bindung von CD-ROM-Treibern in CONFIG.SYS siehe auch
                   Kapitel II.4. bei NWCDEX). Bei Wechsellaufwerken oder
                   -medien muß man besonders auf Pfadangaben in DEVICE...=
                   und INSTALL...= Direktiven achten. Existiert die Datei
                   nicht, wird die Bearbeitung in der nächsten Zeile
                   fortgesetzt.
                   Mit der Verzweigung in die neue Datei werden alle noch
                   ausstehenden RETURN= Rücksprungadressen von GOSUB= oder
                   SWITCH= zurückgesetzt.

    EXIT [=] [comments]

                   Die Bearbeitung der aktuellen CONFIG.SYS wird beendet
                   (auch bei noch ausstehenden RETURN= Anweisungen) und
                   der via SHELL= spezifizierte Kommandoprozessor mit
                   dort definierten Parametern geladen. Ein evtl. ange-
                   gebener Kommentar wird ignoriert; die Angabe eines
                   Errorlevel ist hier nicht möglich (vgl. Kommando EXIT
                   in Kapitel II.11.).

    [COMMON] [=] [comments]

                   Die Gruppenüberschrift [COMMON] für allgemeine
                   CONFIG.SYS Einträge entsprechend MS-DOS Boot-Menüs
                   (die von Novell DOS nicht akzeptiert werden). Man
                   sollte diese Überschrift an das Ende seiner CONFIG.SYS
                   Datei plazieren, damit Installationsprogramme hier ihre
                   notwendigen Einstellungen eintragen, die man dann leicht
                   an die entsprechenden Stellen in den Novell DOS Boot-
                   Menüs platzieren kann. Novell DOS behandelt diese
                   Direktive exakt wie einen Kommentar.


    vi. Fehlermanagement:
    ---------------------

    ERROR [=] [errorlevel] [comments]       errorlevel=0..65535

                   Diese undokumentierte Direktive setzt - sofern ange-
                   geben - den Errorlevel auf den angegebenen Wert. Damit
                   ist die bewußte Beeinflußung nachfolgender ONERROR= etc.
                   Befehle möglich (ab DR DOS 6.0) und in Kombination mit
                   ONERROR= ist es ebenfalls möglich, die vielen unter-
                   schiedlichen möglichen Codes durch gezielte Fallunter-
                   scheidungen auf wenige Codes zu reduzieren.
                   (In Batchjobs kann man mit einer undokumentierten
                   Option des EXIT-Kommandos ebenfalls explizit Errorlevel
                   setzen, allerdings nur im Bereich von 0..255, vgl.
                   Kapitel II.11.)

    ONERROR [=|>|<|<>|>=|<=|=>|=<|==] value directive [params]

                   relation= <=>
                   value   = 0..65535 <no default>

                   Diese leistungsfähige undokumentierte Direktive erlaubt
                   das Ausführen beliebiger Direktiven in Abhängigkeit vom
                   aktuell eingestellten Errorlevel (analog zu ?=).
                   Dabei sind beliebige Relationen (mit den Zeichen = > <)
                   zwischen dem Errorlevel und dem angegebenen Wert value
                   auswertbar. Wenn die Bedingung erfüllt ist, wird die
                   angegebene Direktive ausgeführt (dies könnte z.B. eine
                   weitere ONERROR= Anweisung (die Bedingungen werden dann
                   mit einem 'logischen AND' verknüpft), ein GOTO= oder
                   eine beliebige andere Anweisung sein), sonst wird die
                   Bearbeitung in der nächsten Zeile fortgesetzt.

                   Ist keine Relation angegeben, so wird '=' angenommen,
                   ist kein Wert angegeben, so wird die Bearbeitung mit
                   der nächsten Anweisung fortgesetzt. Ist die auszu-
                   führende Direktive nicht definiert, wird die Bearbeitung
                   ebenfalls in der nächsten Zeile fortgesetzt (bzw. eine
                   Fehlermeldung ausgegeben).

                   Auf diese Weise sind z.B. Abfragen der folgenden Form
                   möglich:

                    YESCHAR=J
                    TIMEOUT=10,N
                    :start
                    INSTALL=myprog.exe
                    ONERROR=0 GOTO skip
                    ONERROR>10 ONERROR<>17 ONERROR<=30 GOTO skip
                    ECHO Fehler aus 1..10, 17, 31..65535 ist aufgetreten!
                    ? "Nochmal versuchen?" GOTO start
                    :skip

                   Wie die Fehlercodes bei den einzelnen CONFIG.SYS Direk-
                   tiven im Detail gesetzt werden, ist in diesem Kapitel
                   bei den jeweiligen Direktiven beschrieben.

                   (In Batchjobs sind ähnliche, wenn auch lange nicht so
                   flexible Abfragen von Errorleveln über das altherge-
                   brachte IF ERRORLEVEL möglich, vgl. Kapitel II.11.)

                                                                             
  ---------------------------------------------------------------------------

  III.2. Undokumentierte Möglichkeiten von LASTDRIVE= : [97-05-01]
  ================================================================

   Stichworte: CONFIG.SYS, LASTDRIVE=, DR DOS, 27-32 Laufwerke, MAP,
               IPX/NETX, ODI, NCP, UNC, SUBST, 4DOS

   Wahrscheinlich schon länger (definitiv aber mit dem Update 11 von
   Novell DOS 7, definitiv noch nicht mit der Originalausgabe von DR DOS
   6.0 von 1991) ist es möglich, mehr als 26 Laufwerke entsprechend den
   Buchstaben A: bis Z: zu definieren. Dies wurde vor allem deshalb
   implementiert, um den Engpaß bei der Verwendung zusätzlicher Netz-
   laufwerke (MAP) zu mildern.

   Eine derartige Möglichkeit war schon immer (undokumentiert) gegeben,
   wenn die Novell Netz-Client-Software IPX/NETX geladen wurde. Die Netz-
   Shell NETX legte sich dabei wie eine Schale um den DOS-Kern (insbe-
   sondere INT21h). Da so alle Calls erst durch diese Shell gefiltert
   wurden (Front-End-Hooks), war es möglich, für Netzlaufwerke auf die
   'Buchstaben' [ bis ` auszuweichen (und dort - weil nicht alle Programme
   derartige Eingaben überhaupt unterstützen - wenigstens die Search-
   Mappings zu verstauen).
   Seit einiger Zeit versucht Novell massiv als Ersatz für die völlig
   veraltete IPX/NETX Kombination ODI-Treiber mit einem auf der VLM-Technik
   (von NetWare 4.0 und PNW 1.0) basierenden Net-Requester durchzusetzen.
   Dadurch wird nun der Umadressierer (INT2Fh/AH=11h) bedient (und die Shell
   und das proprietäre Interface via INT21h (NCP - Novell Core Protocol)
   wird überflüssig) und muß ggf. nur noch aus Kompatibilitätsgründen für
   alte Programme mittels NETX.VLM geladen werden. (Der Umadressierer, auch
   Redirektor genannt, ist ein Back-End-Device.)
   Hierfür wird normalerweise eine Einstellung LASTDRIVE=Z in der
   CONFIG.SYS erforderlich, siehe Kapitel III.1 und II.4. bei NWCDEX.
   Soweit die Theorie.

   In der Praxis bedeutet dies, daß - wenn man diese zusätzlichen Lauf-
   werke vorher genutzt hat - man nach der Umstellung mit weniger Lauf-
   werken auskommen muß. Dies kann bei großen Netzen mit vielen Mappings
   oder komplexen Konfigurationen mit vielen Substitut-Laufwerken etc.
   zu Engpässen führen, da nicht genug Buchstaben bereitstehen.

   Aus diesem Grund hat Novell die Syntax der Direktive LASTDRIVE so er-
   weitert, daß dort für noch größere Laufwerksbuchstaben als Z auch Zahlen
   angegeben werden können. (Und mit MS-DOS 7 hat auch Microsoft diese und
   alle weiteren pfiffigen Ergänzungen im CDS-Support von Novell DOS 7
   übernommen, allerdings auch dort undokumentiert.)

   Die vollständige Syntax lautet:

    LASTDRIVE [=] A..Z | 1..32
    (auch bei MS-DOS 7; bei frühen Ausgaben von Novell DOS 7  - irgendwo
    vor Update 14 - war hingegen als Zahlenangabe nur 27..32 erlaubt!)

   Beispiele:         ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`

    LASTDRIVE=Z     -> 26 Laufwerke  A: ... Z:
    LASTDRIVE=32    -> 32    ""      A: ... `:

   Interessanterweise ist die Verwendung dieser Laufwerke nicht auf
   NetWare-Anwendungen beschränkt, man kann auch ganz normal unter DOS
   damit arbeiten, und zwar auch ohne, daß dafür die Netzwerk-Software
   geladen werden müßte!

   (Hinter der Angabe es Laufwerksbuchstabens können weitere Zeichen folgen,
   so daß auch eine Angabe A: erlaubt ist.)

   Ein funktionierendes Beispiel (unter COMMAND.COM):

    SUBST [: c:\dos
    [:
    DIR

   In der Auflistung mit SUBST erscheinen diese Laufwerke allerdings nicht,
   ähnliche Beschränkungen dürften auch einige andere Tools und Programme
   haben, die solche Buchstaben als 'Fehler' abfangen.

   Leider gibt es bei 4DOS Probleme mit diesen Laufwerken (besonders
   ^: und `:), da die Buchstaben '^' und '`' hier besondere Bedeutung haben.
   Zwar kann man dies bei 4DOS mit SUBST %=`: c:\dos umgehen, aber diese
   Schreibweise ist nicht mit der Syntax von COMMAND.COM kompatibel.
   Egal wie man auch versucht, die Beschränkung zu umgehen, es ist mit 4DOS
   nicht möglich, auf diese Laufwerke zu wechseln. Hierzu muß man - wenn
   auch nur temporär - Novells COMMAND.COM verwenden. Auch intern kommt
   4DOS nicht mit dem Laufwerk `: zurecht (getestet mit 4DOS 5.5c).

   Offenbar hat sich das Verhalten von Novells COMMAND.COM bezüglich der
   Laufwerke oberhalb von 26 mit Update 15 (Januar 1996) leicht verändert:
   Wurden diese Laufwerke vorher exakt wie die anderen Laufwerke behandelt,
   d.h. ohne eine Belegung mit SUBST oder MAP wurden sie in jedem Fall mit
   "Ungültiger Laufwerksbuchstabe" zurückgewiesen, so sieht die Situation
   jetzt etwas anders aus:
   Nicht 'belegte' Laufwerke oberhalb von Z: werden zwar normalerweise
   immer noch zurückgewiesen (etwa bei DIR [:), das 'Wechseln' auf ein
   solches Laufwerk ist hingegen möglich. In diesem Fall erscheint dann
   statt der Pfadangabe eines $p Prompts die Zeichenkette "Aktuelles
   Laufwerk ist nicht mehr gültig", und das ehemals aktuelle Laufwerk
   'schimmert' sozusagen durch (DIR, CD auch mit Unterverzeichnissen,
   aber ohne die Angabe eines Wurzellaufwerks etc.), d.h. alle Pfad-
   veränderungen etc. beziehen sich auf das zuletzt gültige aktuelle
   Laufwerk, obwohl der Laufwerksbuchstabe selbst nicht mehr aktuell ist.
   Bei einigen Befehlen springt der Laufwerksbuchstabe aber auch wieder
   auf das alte aktuelle Laufwerk um.

   Es gibt aber - nur nebenbei erwähnt - auch noch zwei Möglichkeiten,
   Netzlaufwerke direkt anzusprechen: Die NetWare-Ressourcen-Syntax und
   die Universal Naming Convention (UNC), die in Kapitel VI.10. erläutert
   werden.

                                                                             
  ---------------------------------------------------------------------------

  III.3. Verhalten von ECHO= :
  ============================

   Stichworte: CONFIG.SYS, ECHO=, Boot-Menüs, Direktiven

   Der Befehl ECHO kann - wie schon lange bei DR DOS gewohnt - auch in
   CONFIG.SYS verwendet werden. Allerdings funktioniert er hier etwas
   anders, siehe auch Kapitel III.1. (und IV.1.).

   a) Normalerweise schreibt die Syntax für CONFIG.SYS Direktiven ein
      Gleichheitszeichen vor: Direktive=Wert.
      Dieses Gleichheitzeichen kann allerdings häufig weggelassen werden,
      solange ein Leerfeld für eine Abgrenzung sorgt. Daraus entsteht aber
      eine kleine Einschränkung. Die Direktive 'ECHO' erwartet nämlich
      (entgegen der Gewohnheit) optional auch ein Gleichheitszeichen,
      d.h. soll die Ausgabezeichenkette mit einem Gleichheitszeichen
      beginnen, so wird dieses als syntaktisches Element interpretiert
      und weggelassen, d.h. man muß dieses Zeichen verdoppeln:

      Statt                                   Ausgabe:

       ECHO Hallo Benutzer!                    Hallo Benutzer!
       ECHO ===============                    ==============

      muß man also schreiben:                 um zu erhalten:

       ECHO Hallo Benutzer!                    Hallo Benutzer!
       ECHO ================                   ===============

      weil die Zeile eigentlich so interpretiert wird:

       ECHO [=] Hallo Benutzer!
       ECHO [=] ==============

      Dies muß man insbesondere bei der Gestaltung von Boot-Menüs beachten.


   b) 'ECHO.' zur Ausgabe einer Leerzeile funktioniert nicht.
      Stattdessen kann man einfach 'ECHO' oder (s.o.) 'ECHO=' schreiben.

                                                                             
  ---------------------------------------------------------------------------

  III.4. Hinweise zu DEVICE=/DEVICEHIGH= : [96-06-11]
  ===================================================

   Stichworte: CONFIG.SYS, DEVICE, .SYS/.COM/.EXE, INSTALL, Region-Support

   Die CONFIG.SYS-Befehle DEVICE=/DEVICEHIGH= sind eigentlich dafür vorge-
   sehen, .SYS-Treiber zu laden. Da sich das Format aber nur gering von
   .COM/.EXE-Programmen (die als TSR ebenfalls Treiber sein können) unter-
   scheidet, lassen sich auch solche Programme ohne Rückfrage hochladen.
   Dies sollte man jedoch nur dann mit DEVICE=/DEVICEHIGH= durchführen,
   wenn dies ausdrücklich vom Treiberhersteller erlaubt wird (der Treiber
   muß einen 'dualen' Header haben), ansonsten wird das System abstürzen.

   Ausweichmöglichkeit:

    - .SYS-Version des Treibers verwenden, oder falls nicht vorhanden:
    - Mit INSTALL=/INSTALLHIGH= hochladen!!!

   Besonders zu beachten ist, daß Novell DOS DEVICE[HIGH]=/INSTALL[HIGH]=
   Direktiven in der Reihenfolge abarbeitet, in der sie in der CONFIG.SYS
   vorkommen. Dies ist äußerst praktisch, da man so auch TSR-Treiber (per
   INSTALL[HIGH]=) vor Gerätetreibern (per DEVICE[HIGH]=) laden kann. Bei
   MS-DOS werden zuerst die DEVICE[HIGH]= und erst danach die INSTALL=
   Direktiven abgearbeitet, was häufiger zu ziemlichen Schwierigkeiten
   bei der Bestimmung der optimalen Ladereihenfolge mit sich bringt.

   Die Direktive DEVICEHIGH= unterstützt (undokumentiert) noch zusätzliche
   Parameter, die das Hochladen steuern.

   SIZE=size  Teilweise undokumentierte Option für DEVICEHIGH= analog zu
              der Option von MS-DOS 5.0, die auch bei MS-DOS 6.x (dort
              allerdings wieder undokumentiert) noch vorhanden ist.
              Diese Option erlaubt die Angabe einer Größe size (hexa-
              dezimal), die minimal in UMBs vorhanden sein muß, damit
              DOS den Treiber hochlädt. Ist soviel Speicher in den UMBs
              nicht (mehr) vorhanden, wird der Treiber automatisch in den
              Basisspeicher geladen. Diese Option ist dann wichtig, wenn
              ein Treiber während seiner Initialisierung mehr Speicher
              benötigt, als die Dateigröße oder die Headerinformationen
              vermuten lassen (Gerätetreiber können nicht ohne Weiteres
              nachträglich mehr Speicher allozieren). Ist der Treiber dann
              nämlich bereits in die UMBs geladen und steht der zusätzliche
              Speicher nicht zur Verfügung, kann die Initialisierung des
              Treibers eventuell ganz versagen.
              Achtung: Die Angabe der Größe ist willkürlich (00000..FFFFF
              in Bytes), d.h. muß nicht der tatsächlich vom Treiber be-
              nötigten Menge entsprechen (sinnvolle Anwendung setzt aller-
              dings voraus, daß man hier den wirklichen Bedarf angibt).
              Wird vom Treiberhersteller keine Angabe gemacht, kann man
              meistens mit DEVICE= und anschließendem MEM den nötigen
              Speicherbedarf für DEVICEHIGH= ermitteln. Der angegebene
              Wert wird intern auf Paragraphen aufgerundet (1 Paragraph =
              16 Bytes). Die Syntax lautet:

              DEVICEHIGH [SIZE=xxxx] =driver [driverparameter]

   /L:region[,minsize][;[...]]
   /S
              Diese MS-DOS MEMMAKER-Optionen werden aus Kompatibilitäts-
              gründen akzeptiert und ausgewertet, hatten aber bei Novell DOS
              7 bis vor Update 14 keine Funktion, da Novell DOS keinen
              Region-Support bot. Mit Update 14 (sicher jedoch Update 15)
              wurde diese Funktionalität nachgerüstet und arbeitet genauso
              wie bei MS-DOS (siehe Kapitel V.7.).
              Besonders tragisch ist die vorher fehlende Unterstützung
              nicht, da die Speicherverwaltung auch ohne MEMMAKER, SIZER
              und CHKSTATE erheblich komfortabler (mit SETUP, MEM und
              MEMMAX) arbeitete und unabhängig von Region-Support schon
              gleiche oder bessere Bilanzen brachte.

              Ist der UMB-Speicher in mehrere getrennte Blöcke fragmentiert
              (z.B. bei Verwendung des Video-Speichers als UMB-Bereich), so
              wird ein Programm normalerweise in den Block mit dem größten
              verfügbaren Speicher geladen, um dem Programm möglichst viel
              Speicher zur Verfügung zu stellen und einer Fragmentierung der
              einzelnen Blöcke vorzubeugen. In Einzelfällen ist dies aber
              nicht die optimale Wahl. In solche Fällen ist es möglich, über
              die Angabe der Option /L: mit einer Bereichsnummer x als
              Parameter genau einen UMB-Bereich zu definieren (/L:x), in den
              das Programm geladen werden soll. Kann das Programm mehrere
              getrennte Blöcke (y,z) verwenden, ist auch die Angabe weiterer
              Bereiche möglich, die dann für das Programm freigeschaltet
              werden (/L:x;y;z). Fehlt die Angabe zusätzlicher Bereiche,
              kann das Programm nur den angegebenen Bereich verwenden.
              Sich selbst hochladende Programme können diese Sperrung von
              UMB-Bereichen allerdings umgehen (getestet mit Update 15).
              Die Nummerierung der UMB-Bereiche (sog. Regions) beginnt von
              unten nach oben. Die Zählung beginnt bei 1. Jeder Bereich
              endet immer dort, wo ein Bereich ausgeschlossen wird
              (/EXCLUDE) oder aus anderen Gründen nicht zur Verfügung
              steht (etwa BIOS-ROM). Der konventionelle Speicher und die
              HMA werden nicht mitgezählt. Die Bereichsnamen und Größen
              kann man mit MEM /A herausfinden, allerdings werden sie dort
              nicht explizit angegeben, siehe auch bei MEM.BAT /FREE in
              Kapitel IV.5.

              Ist der UMB-Speicher nicht fragmentiert (d.h. existiert nur
              ein zusammenhängender erlaubter Bereich unabhängig von evtl.
              fragmentierten freien Bereichen innerhalb dieses Bereichs),
              so hat dieser logischerweise die Nummer 1.
              Gibt man eine Zahl an, die größer als die tatsächliche Anzahl
              der UMB-Regions ist, so wird das Programm trotz DEVICEHIGH=
              in den konventionellen Speicher geladen.
              Der Bereich 0 entspricht dem konventionellen Speicher. Bis vor
              Update 14 wurde ein Programm bei Angabe der Option /L:0 trotz
              DEVICEHIGH= auch tatsächlich in den konventionellen Speicher
              geladen, ab Update 14 wird die Angabe /L:0 offenbar ignoriert,
              so daß der Treiber so in UMBs geladen wird, als hätte man die
              Option nicht angegeben (bei DEVICEHIGH=, nicht aber bei LH).

              Optional kann für jeden der Bereiche auch eine minimal
              freie Größe angegeben werden, die verfügbar sein muß, um
              diesen Bereich auch tatsächlich zu verwenden. Die Angabe
              der Größe minsize muß dabei dezimal erfolgen (im Gegensatz
              zu SIZE=size).

              Möchte man ausschließen, daß ein Treiber mehr als eine
              minimale Größe an Speicher verwendet, kann man zusätzlich
              die Option /S benutzen, die OHNE Leerfeld an die /L:...
              Anweisung angehängt werden muß (sonst wird die Zeile von
              Novell DOS nicht akzeptiert). Dadurch wird der erste der
              angegebenen Bereiche für die Dauer des Ladevorgangs des
              Treibers auf die Größe minsize verkleinert, so daß der
              Treiber keine Chance bekommt, mehr Speicher zu verwenden.
              (In gewisser Weise arbeiten /S und SIZE= also gegenläufig.)

              Syntax:

              DEVICEHIGH= [/L:region[,minsize][;region[,minsize][;...]]]
                          [/S]] =driver [driverparameter]

   Die Optionen /L: und /S stehen auch beim Kommando HILOAD/LH/LOADHIGH,
   (nicht aber bei INSTALLHIGH) zur Verfügung. Im Gegensatz zu DEVICEHIGH=
   kann man hier auch Memory-Region 0 angeben, die entspricht dem kon-
   ventionellen Speicher. Das Gleichheitszeichen nach dem Hochladekommando
   und vor dem Programmnamen ist nicht zulässig.

                                                                             
  ---------------------------------------------------------------------------

  III.5. Möglichkeiten von INSTALL= : [96-12-23]
  ==============================================

   Stichworte: CONFIG.SYS, TSR, Temporäres Laden nicht residenter Programme

   Neben der üblichen Funktion zum Laden von TSR-Programmen bereits inner-
   halb der CONFIG.SYS kann man dieses Kommando auch benutzen, um nicht-
   residente Programme zu laden (sofern diese mit dem noch nicht komplett
   hochgezogenen System bereits zurechtkommen). Damit ist es möglich, über
   solche Programme bereits sehr früh bestimmte Systemeinstellungen vor-
   zunehmen, die andere residente Treiber/Programme in CONFIG.SYS schon
   brauchen. (Außerdem läßt sich so - natürlich nur im Notfall - mancher
   Installations- oder Kopierschutz von widerspenstigen Programmen aus-
   hebeln. Die Realisierung bleibt der eigenen Phantasie überlassen... ;-) )

   Das Besondere an dieser Möglichkeit ist, daß ein mit INSTALL= geladenes,
   nicht residentes Programm danach den belegten Speicher wieder zur Ver-
   fügung stellt. Daß dies der Fall ist, ist leider kaum bekannt, so daß
   viele Leute vor scheinbar unvermeidlichen Problemen stehen (oder ver-
   suchen, alle Programme erst in AUTOEXEC.BAT zu laden, was mit einer
   Reihe von Nachteilen verbunden sein kann).

   Zu beachten ist lediglich, daß zum dem Zeitpunkt, wo CONFIG.SYS abge-
   arbeitet wird, das System noch nicht komplett steht. Das bedeutet,
   daß bestimmte Programme nicht auf diese Art und Weise geladen oder
   ausgeführt werden können (etwa NWCDEX, sofern Sie nicht das Utility
   INSTCDEX.EXE einsetzen, siehe Kapitel II.4.). Bei DR DOS und Novell DOS
   ist das System aber (im Gegensatz zu früheren Versionen von MS-DOS)
   bereits sehr weit hochgezogen und die meisten internen Schnittstellen
   stehen Programmen schon zur Verfügung.

   Zur Verdeutlichung ein triviales Beispiel:

   CONFIG.SYS:

    REM Der folgende Befehl wird während der Abarbeitung von CONFIG.SYS
    REM ausgeführt (d.h. bevor mittels SHELL= ein Kommandoprozessor wie
    REM COMMAND.COM geladen wurde), ohne daß der hier temporär geladene
    REM COMMAND.COM resident bleibt!
    INSTALL=c:\nwdos\command.com /c dir c:\*.*
    REM Auch der Aufruf von Batchjobs etc. ist möglich, so daß alle Ein-
    REM schränkungen der CONFIG.SYS Sprache umgangen werden können.
    INSTALL=c:\nwdos\command.com /c machwas.bat
    ONERROR = 1 GOTO routine1
    ONERROR = 2 GOTO routine2


   Über undokumentierte CONFIG.SYS Direktiven (siehe z.B. ONERROR= in
   Kapitel III.1.) ist auch die Abfrage des erweiterten Fehlercodes oder
   Exitcodes nach der Beendigung möglich, womit flexibel auf Sonderzustände
   eingegangen werden kann. Und da COMMAND.COM beim Befehl EXIT die Angabe
   von Errorleveln erlaubt (siehe Kapitel II.11.), eröffnen sich ungeahnte
   Möglichkeiten.

   Es sind sogar Aufrufe wie

    INSTALL=c:\nwdos\mem.exe [parameter]
    INSTALL=c:\nwdos\debug.exe [parameter]
    INSTALL=c:\nwdos\command.com [parameter]

   möglich. Im letzteren Fall wird ein Kommandoprozessor geladen, mit
   dem man ganz normal arbeiten kann. Z.B. ist es hierdurch bedingt
   möglich, das System während der CONFIG.SYS zu untersuchen. Beendet
   man den Kommandoprozessor mit EXIT, wird die CONFIG.SYS Datei weiter-
   bearbeitet. Allerdings ist zu beachten, daß das Ganze bei COMMAND.COM
   nicht rückwirkungsfrei funktioniert (wohl aber mit 4DOS). CONFIG.SYS
   Einstellungen wie SHELL= oder SET= werden offenbar durch COMMAND.COM
   modifiziert, siehe Kapitel III.1.

   Da per INSTALL= etc. geladene Programme von der Definition her keine
   Gerätetreiber sind (auch wenn sie vielleicht gleichwertige Funktionen
   zur Verfügung stellen), bekommen die bis dahin definierte Vorab-Umgebung
   als Umgebung. Wie man hier Speicher sparen kann, ist bei SET= in
   Kapitel III.1. beschrieben.

   Dadurch, daß bei DR DOS und Novell DOS die Reihenfolge von INSTALL= etc.
   und DEVICE= etc. Direktiven völlig wahlfrei ist, können Sie z.B. auch
   bestimmte Programme *vor* Gerätetreibern laden, was unter MS-DOS/PC-DOS
   - zumindest mit Bordmitteln des Betriebssystems - schlichtweg unmöglich
   ist. Eine prima Lösung zum Debuggen von Gerätetreibern ist es daher,
   im Gerätetreiber INT 3 Anweisungen einzustreuen, und vor der DEVICE=
   Zeile einen Debugger wie z.B. Borlands Turbo-Debugger TD.EXE per
   INSTALL= zu laden. Sie können dann 'online' durch den Gerätetreiber
   tracen, sogar während dessen Installationsprozedur...

                                                                             
  ---------------------------------------------------------------------------

  III.6. Hinweise zur Vorab-Umgebung in Verbindung mit 4DOS: [96-06-14]
  =====================================================================

   Stichworte: SET=, COMMAND.COM, 4DOS.COM, SET

   Novell DOS 7 (und DR DOS 6.0) wandeln Vorab-Umgebungsvariablen, die
   innerhalb der CONFIG.SYS mit SET= belegt wurden, nicht in Großbuchstaben
   um, d.h. sie werden so in der Vorab-Umgebung repräsentiert, wie sie
   geschrieben wurden. Außerdem werden sämtliche Zeichenketten, die per SET=
   definiert werden, an das Ende der Vorab-Umgebung aufgenommen, auch
   wenn diese keinen Wert enthalten oder bereits belegte Variablen ersetzen
   würden.

   Wird am Ende der CONFIG.SYS Behandlung COMMAND.COM geladen, so wertet
   der Kommandointerpreter die Vorab-Umgebung aus und baut dabei sein
   Master-Environment auf (siehe Kapitel III.1.). Dabei werden die
   Variablennamen auch in Großbuchstaben umgewandelt. Letzteres geschieht
   bei 4DOS (zumindest bis 5.52a) nicht.

   Normalerweise ist das unkritisch, weil 4DOS bei Variablenexpansionen
   sowohl die Variablennamen in der Umgebung, als auch in der Referenz
   in Großbuchstaben umwandelt, d.h. innerhalb von Batchjobs erkennt man
   keinen Unterschied (die Auflistung per SET zeigt aber sehr wohl den
   Unterschied in der Schreibweise).

   Wenn Programme aber direkt auf die Umgebung zugreifen und dabei nicht
   auch beide Seiten des Vergleichs in Großbuchstaben umwandeln, kann es
   sein, daß in CONFIG.SYS definierte Variablen auf DR DOS/Novell DOS-
   Systemen, auf denen 4DOS.COM ohne COMMAND.COM läuft, nicht gefunden
   werden.

   Es gibt noch einen weiteren Unterschied: 4DOS (getestet bis 5.52a)
   tastet bezüglich der Vorab-Umgebung die DR DOS/Novell DOS internen
   Datenstrukturen nicht an. Sobald COMMAND.COM geladen wird, wird nach
   der Auswertung und Übernahme in das Master-Environment die Vorab-
   Umgebung in INT21h/4458h, Offset +12h durch den Wert 0 für ungültig
   erklärt. 4DOS läßt hier den alten Wert stehen, der aber nun ins Leere
   zeigt! Wenn Utilities einen Wert ungleich 0 als Erkennung für einen
   gültigen Pointer auf eine Vorab-Umgebung auswerten, so wird dies
   meistens zum Absturz des Rechners führen, wenn 4DOS geladen wurde.
   Solange 4DOS für dieses Problem noch keinen Fix implementiert hat,
   hilft folgendes Workaround:

   Nachdem 4DOS (ohne zusätzliches COMMAND.COM) geladen wurde, sollten Sie
   an den Anfang der AUTOEXEC.BAT folgende Zeile aufnehmen (siehe auch
   Kapitel VII.3.):

    @C:\NWDOS\COMMAND.COM /C EXIT> \dev\nul

   Dadurch wird kurzzeitig COMMAND.COM geladen und patcht einige interne
   Datenstrukturen so, wie dies unter DR DOS/Novell DOS gültig wäre. Danach
   gehören diese Probleme unter 4DOS der Vergangenheit an. Mir ist dies
   bisher nur in Verbindung mit der Vorab-Umgebung aufgefallen, es könnte
   aber gut sein, daß ein solcher unkritischer Aufruf von COMMAND.COM auch
   einige andere Dinge geraderücken kann, die 4DOS aufgrund der Unkenntnis
   der internen Datenstrukturen von Novell DOS/DR DOS nicht korrekt anpaßt.

                                                                             
  ---------------------------------------------------------------------------

  III.7. Novell DOS Boot-Menüs aus der Sicht von MS-DOS: [96-05-31]
  =================================================================

   Stichworte: MENUITEM=, MENUDEFAULT=, INCLUDE=, SUBMENU=, MENUCOLOR=,
               [MENU], [COMMON], DEVICE=, INSTALL=, SWITCH=

   In Kapitel III.1 wurden die bei Novell DOS (und DR DOS 6) möglichen
   CONFIG.SYS Direktiven zur Konstruktion von Boot-Menüs bereits ausführlich
   beschrieben. (Leider unterstützt Novell DOS 7 selbst mit Update 15 noch
   nicht optional die Boot-Menüs im Stil von MS-DOS 6.)

   Zwar sind die Möglichkeiten, die sich über Novells Boot-Menüs bieten, um
   Größenordnungen flexibler als die Möglichkeiten, die MS-DOS hier bietet,
   aber leider ergibt sich auch ein Problem mit vielen Setup-Programmen von
   Anwendungsprogrammen, die diese Boot-Menüs ignorieren. Im einfachsten
   Fall wird die CONFIG.SYS einfach nur falsch ausgewertet oder unpassend
   modifiziert, im schlimmsten Fall stürzen solche Setup-Programme ab (z.B.
   das Setup-Programm von GMOUSE 10.20...).

   Die sicherste Methode für solche Fälle ist es, eine temporär zu verwen-
   dende CONFIG.SYS Version ohne Boot-Menüs bereitzuhalten. Sofern CHAIN=
   mit Ihren Setup-Programmen keine Probleme bereitet, können Sie die
   eigentliche Bearbeitung inkl. der Boot-Menüs auch auf eine andere
   'CONFIG.SYS' Datei auslagern. Häufig hilft es auch, die [COMMON] Gruppe
   an geeigneter Stelle in der CONFIG.SYS unterzubringen. Im allgemeinen
   halte ich [COMMON] am Ende der CONFIG.SYS für die beste Wahl.

   Um einen Rechner multibootfähig zu machen, sollte man aber die Struktur
   der Boot-Menüs von Novell DOS und MS-DOS möglichst stark angleichen, um
   eine einfache Wartung der beiden 'parallelen' CONFIG.SYS Dateien zu er-
   möglichen. (Dies wird gerade im Zeitalter von MS Windows95 noch wichti-
   ger, damit Novell DOS über Boot-Manager wie die von OS/2 oder Linux
   (LILO) weiterhin als Alternative neben dem MS-DOS 7 und einem evtl.
   anderen MS-DOS ab 5 bestehen bleiben kann.)
   Dabei geht natürlich ein Großteil der Flexibilität unter Novell DOS/
   DR DOS verloren, aber häufig ist dies nicht besonders tragisch.

   Zunächst ist anzumerken, daß bei MS-DOS/PC-DOS einzelne Abschnitte in
   CONFIG.SYS mit [name] getrennt werden. Findet MS-DOS beim Start keine
   Gruppe mit dem reservierten Namen [MENU] (als Einstiegspunkt), so werden
   die übrigen [name] Direktiven ignoriert. Bei Novell DOS ist nur [COMMON]
   vorhanden, andere Gruppennamen mit [name] sind nicht erlaubt.
   Kann man für Ihre Anwendungsfälle alle Menüabfragen von Novell DOS an
   den Anfang der CONFIG.SYS-Bearbeitung verschieben (nur dies ist bei
   MS-DOS/PC-DOS möglich), so kann man eine echte Parallelkonstruktion
   vornehmen. Außerdem ist zu beachten, daß bei MS-DOS/PC-DOS die Treiber
   per DEVICE= etc. vor denen per INSTALL= etc. geladen werden, auch wenn
   sie in anderer Reihenfolge in CONFIG.SYS stehen (inkl. aller Ver-
   schachtelungsebenen in den einzelnen Gruppen). Wollen Sie hier völlige
   Übereinstimmung herstellen, sollten Sie bei Novell DOS zuerst alle
   DEVICE= etc. und dann erst die INSTALL= etc. Direktiven aufführen.
   (Dies ist allerdings eine ziemliche Einschränkung und bei komplexen
   Konfigurationen sehr unübersichtlich und meistens nicht nötig.)

   Im folgenden werden die Novell DOS Möglichkeiten aus der Sicht von
   MS-DOS/PC-DOS Boot-Menüs beleuchtet:


   i. [MENU], [COMMON], MENUITEM=, MENUDEFAULT= :
   ----------------------------------------------

   Ein MS-DOS 6 CONFIG.SYS Boot-Menü wie

    [MENU]
    MENUITEM=def, Basiskonfiguration
    MENUITEM=std, Standardkonfiguration
    MENUITEM=min, Minimalkonfiguration
    MENUDEFAULT=def, 10

    [def]
    ...

    [std]
    ...

    [min]
    ...

    [COMMON]

   kann man unter Novell DOS fast 1:1 umsetzen (sollte in beiden Fällen
   direkt am Anfang der CONFIG.SYS stehen, wenn man wirklich die gleichen
   Implikationen nachbilden will, abgesehen von SWITCHES=):

    :[MENU] ist hier nur ein Kommentar...
    CLS
    TIMEOUT=10,N,1
    ECHO = Novell DOS 7 Boot-Konfiguration:
    ECHO = ================================
    ECHO
    ECHO 1 - Default-Konfiguration
    ECHO 2 - Standardkonfiguration
    ECHO 3 - Minimalkonfiguration
    ECHO
    ECHO Bitte drücken Sie die entsprechende Taste (Default-Timeout ...
                                                              ... 10sec) ...
    SWITCH [def], [std], [min]
    GOTO common

    :[def]
    SET CONFIG=DEF
    ...
    RETURN

    :[std]
    SET CONFIG=STD
    ...
    RETURN

    :[min]
    SET CONFIG=MIN
    ...
    RETURN

    [COMMON]

   Wie man sieht, wird MENUDEFAULT= mit TIMEOUT= und SWITCH= nachgebildet,
   MENUITEM= entspricht einer Mischung aus ECHO= und SWITCH=. Eine
   Gruppe [name] kann man prinzipiell durch eine Kombination aus RETURN mit
   einer anschließenden Marke :name oder - je nach Geschmack - :[name]
   nachbilden.

   Die %CONFIG% Variable kann man bei Novell DOS explizit setzen.
   Marken bzw. Gruppennamen sollten übrigens nicht länger als 8 Zeichen
   lang sein, um hier Fehlinterpretationen auszuschließen.

   Die Gruppe [COMMON] sollte aus verschiedenen Gründen leer bleiben
   und ganz am Ende stehen. Dadurch werden eine Reihe Probleme abgewendet,
   die manche Setup-Programme haben, wenn sie keine Novell DOS Boot-Menüs
   verstehen. Für gemeinsam genutzte Einstellungen bietet sich mit
   INCLUDE= alias GOSUB= eine andere Möglichkeit an, nur sollte die
   Gruppe [COMMON] hierfür nicht verwendet werden (in folgendem Beispiel
   z.B. [basic]).


   ii. INCLUDE= :
   --------------

   Ein INCLUDE= Block bei MS-DOS entspricht im wesentlichen einem GOSUB zu
   einem Abschnitt; bei MS-DOS:

    [name]
    ...
    INCLUDE=basic
    INCLUDE=extra
    ...

    [extra]
    ...

    [basic]
    ...

    [COMMON]

   wird bei Novell DOS zu:

    :[name]
    ...
    GOSUB [basic]
    GOSUB [extra]
    ...
    RETURN

    :[extra]
    ...
    RETURN

    :[basic]
    ...
    RETURN

    [COMMON]

   Ich empfehle, die diesbezüglichen Blöcke erst *nach* den Blöcken anzu-
   ordnen, die sich mit der Verzweigung der Boot-Menüs befassen (s.u.), und
   dabei Blöcke wie Speichermanager, Festplattenkonfiguration, serielle
   Schnittstellen, Video-Konfiguration zu unterscheiden.


   iii. SUBMENU= :
   ---------------

   Die Nachkonstruktion von SUBMENU= geschieht wie bei MENUITEM= durch ECHO=
   und SWITCH=, nur daß der angesprungene Block selbst wieder ein neues Menü
   mit CLS=, ECHO= und SWITCH= aufbaut. Dabei sollte dieses Menü unmittelbar
   am Anfang dieses Blocks stehen, damit die Logik identisch zu MS-DOS ist.
   Angenommen, in obigem Beispiel würde die Standardkonfiguration durch
   ein Untermenü ersetzt werden, so würde dies bei MS-DOS wie folgt aus-
   sehen:

    [MENU]
    MENUITEM=def, Basiskonfiguration
    SUBMENU =std, Standardkonfigurationen
    MENUITEM=min, Minimalkonfiguration
    MENUDEFAULT=def, 10

    [def]
    ...

    [std]
    MENUITEM=cfg1, Konfiguration 1
    MENUITEM=cfg2, Konfiguration 2

    [cfg1]
    ...

    [cfg2]
    ...

    [min]
    ...

    [COMMON]

   Bei Novell DOS würde daraus ein Menü wie folgt:

    :[MENU] ist hier nur ein Kommentar...
    CLS
    TIMEOUT=10,N,1
    ECHO = Novell DOS 7 Boot-Konfiguration:
    ECHO = ================================
    ECHO
    ECHO 1 - Default-Konfiguration
    ECHO 2 - Standardkonfigurationen
    ECHO 3 - Minimalkonfiguration
    ECHO
    ECHO Bitte drücken Sie die entsprechende Taste (Default-Timeout ...
                                                              ... 10sec) ...
    SWITCH [def], [std], [min]
    GOTO common

    :[def]
    SET CONFIG=DEF
    ...
    RETURN

    :[std]
    CLS
    ECHO = Novell DOS 7 Standard-Konfigurationen:
    ECHO = ======================================
    ECHO
    ECHO 1 - Konfiguration 1
    ECHO 2 - Konfiguration 2
    ECHO
    ECHO Bitte drücken Sie die entsprechende Taste (Default-Timeout ...
                                                              ... 10sec) ...
    SWITCH [cfg1], [cfg2]
    RETURN

    :[cfg1]
    SET CONFIG=CFG1
    ...
    RETURN

    :[cfg2]
    SET CONFIG=CFG2
    ...
    RETURN

    :[min]
    SET CONFIG=MIN
    ...
    RETURN

    [COMMON]


   iv. MENUCOLOR= :
   ----------------

   MS-DOS/PC-DOS MENUCOLOR=x[,y] kann man nicht ohne weiteres nachbilden
   (vielleicht mit einem per INSTALL= geladenen Utility, das die Farbe
   umstellt), aber dies ist auch wirklich reiner Schnickschnack.

                                                                             
  ###########################################################################
  ###########################################################################

  IV. AUTOEXEC.BAT UND BATCHJOBS:
  ===============================

  ---------------------------------------------------------------------------

  IV.1. Bug in ECHO. (Bug behoben - getestet 11/1994):
  ====================================================

   Stichworte: ECHO., Linefeed, Wagenrücklauf, MS-DOS, DATE, Updates

   Bei der Programmierung von Batchjobs ist bei frühen Versionen von
   Novell DOS folgendes Problem aufgetaucht.
   Der ECHO-Befehl erzeugt in der Spezial-Syntax 'ECHO.' eine Leerzeile.
   Leider weicht das exakte Verhalten bei Novell DOS 7 in diesem Fall
   geringfügig vom Standard ab, was aber große Auswirkungen haben kann:

   Statt der Zeichenfolge $0A $0D (für Linefeed/Wagenrücklauf), die bei
   MS-DOS üblich ist (oder $0D $0A wie bei NDOS der Norton Utilities),
   wird hier die Zeichenfolge $20 $0D $0A (d.h. ein zusätzliches Leerfeld)
   abgeschickt. (Nachbemerkung: Auf einem MS-DOS 6.22 System wurde ebenfalls
   ein $20 vorangestellt - trotzdem ist dies wohl nicht repräsentativ und
   sollte nicht vorausgesetzt werden. Näheres wurde nicht untersucht.)

   Dies führt bei manchen Batchjobs, die 'ECHO.' als Eingabeumleitung in ein
   Programm verwenden, zu Fehlverhalten oder sogar zum Hängen des Prozesses:

   Ein Beispiel für MS-DOS und NDOS (nicht NWDOS!):

    ...
    ECHO. | DATE > protokol.dat
    ...

   Der DATE-Befehl bekommt das gewünschte RETURN und die Bearbeitung wird
   ordnungsgemäß fortgesetzt. In PROTOKOL.DAT steht das aktuelle Datum.

   Bei NWDOS führt das obige Beispiel zum Aufhängen des Rechners, und kann
   auf normale Weise auch nicht beendet werden: Der DATE-Befehl wertet das
   zusätzliche Leerzeichen als eine Fehleingabe und erwartet nun aus der
   Umleitung (d.h. nicht von der Tastatur) ein gültiges Datum. Der DATE-
   Befehl kommt übriges gleichermaßen mit der Zeichenfolge $0D $0A wie
   auch $0A $0D zurecht, nur nicht mit dem zusätzlichen $20. Bei NDOS
   ergibt sich allerdings ein ähnliches Problem nicht, da hier der DATE-/
   TIME-Befehl intern definiert ist und damit den internen Befehl eines
   evtl. darunter geladenen COMMAND.COM ersetzt.

   Abhilfe für NWDOS:

   a) Eine Datei ECHO_.INP erzeugen, die NUR die Zeichenfolge $0A $0D
      (also LineFeed/Carriage Return) enthält.
      DATE < echo_.inp > protokoll.dat

   b) Ein kleines Utility schreiben, das nur die Zeichenfolge $0A $0D
      ausgibt und dieses statt ECHO. verwenden (z.B. ECHO_.EXE).

   Ein Test mit dem Update 8 zu Novell DOS zeigte, daß dieser Bug mittler-
   weile behoben wurde, Novell DOS verhält sich jetzt konform und liefert
   nur noch die Folge $0D $0A. Ab welcher Update-Release dieser Bug behoben
   wurde, wurde im nachhinein nicht mehr überprüft.

                                                                             
  ---------------------------------------------------------------------------

  IV.2. Fehler bei Abfrage von Variablen, die mehrere Parameter enthalten:
  ========================================================================
                                          (Bug behoben - getestet 02/1995)

   Stichworte: MS-DOS, Batchjobs, Updates, Parameterübergabe

   Bei MS-DOS sind in Batchjobs Abfragen der folgenden Form möglich:

    SET test=param1 param2 param3
    IF NOT ""=="%test%" ECHO Test ist definiert!

   Bei frühen Versionen von Novell DOS führt diese Anweisung meistens zu
   einem Syntax-Fehler:

   Solange TEST nur einen Parameter (d.h. keine Leerfelder) enthält,
   funktioniert alles wie gewohnt. Wenn der Wert aber aus mehreren Wörtern
   besteht, erscheint der Syntax-Fehler oder die Meldung 'Kommando- oder
   Dateiname nicht erkannt'. Novell DOS interpretiert diese Zeile anders
   und wertet einen Teil des Wertes bereits als Anweisung aus.
   Ein ähnliches Verhalten ist teilweise übrigens auch beim Batch-Prozessor
   von MS-DOS 6.0/6.2 erkennbar, trotzdem ergibt sich dadurch keine sinn-
   volle Anwendung (siehe MSDOSTIP.TXT).
   Wenn paramX aus Zahlen besteht, so wird dies u.U. von Novell DOS
   akzeptiert, wenn es auch zu einer falschen Funktion führt.

   Die einfachste Abhilfe ergibt sich durch Umstellen der Bedingung, so
   daß kein NOT mehr vorkommt. Außerdem muß die Bedingung u.U. so gedreht
   werden, daß '""==' vorne steht:

    SET test=param1 param2 param3
    IF ""=="%test%" GOTO skip
    ECHO Test ist definiert!
    :skip

   Mit dem Update 11 zu Novell DOS (das alle bisherigen Fixes vereint)
   wurde das Verhalten erneut untersucht. Mittlerweile hat sich die Aus-
   wertung des SET-Kommandos diesbezüglich geändert (siehe HISTORY.TXT
   im Update), so daß die Probleme nun nicht mehr auftauchen.

                                                                             
  ---------------------------------------------------------------------------

  IV.3. Abfrage von geladenen Gerätetreibern aus Batchjobs: [96-10-30]
  ====================================================================

   Stichworte: Batchjobs, Gerätetreiber, Zeichentreiber, Blocktreiber,
               IF EXIST, IF DIREXIST, AVAILDEV, \DEV\, Unix

   Häufig steht man in Batchjobs vor dem Problem, daß man bestimmte Geräte-
   treiber als Voraussetzung für eine Anwendung benötigt, z.B. Maustreiber,
   Speichermanager oder Treiber für spezielle serielle Karten.

   Bisher mußte man dann einfach alle Treiber aufrufen, was verschiedene
   Nachteile hat:
   - evtl. werden bereits eingestellte Optionen wieder zurückgesetzt
   - evtl. wird ein Treiber mehrfach geladen, wenn kein Schutzmechanismus
     eingebaut ist
   - es kann zu Treiberkonflikten aufgrund der Reihenfolge des Ladens kommen
   - kostet Bearbeitungszeit
   usw.

   Zumindest bei Novell DOS 7 gibt es eine Möglichkeit, in einem Batchjob
   die Existenz eines geladenen Gerätetreibers abzufragen und davon abhängig
   Entscheidungen zu treffen: Damit kann man die oben angedeuteten Probleme
   komfortabel umgehen.

   Man muß zwei Sorten von Gerätetreibern unterscheiden: Zeichentreiber und
   Blocktreiber. Systemtreiber sind zwar keine Zeichentreiber, haben aber
   ebenfalls ihr Format.

   Zeichengerätetreiber (ob für vordefinierte Geräte wie CON, PRN, LPT1,
   LPT2, LPT3, AUX, COM1, COM2, COM3, COM4) oder für spezielle Geräte wie
   Mäuse (PC$MOUSE) etc. und Blocktreiber (für zusätzliche Laufwerke) werden
   ähnlich wie Programme im Speicher verankert und von DOS verwaltet.
   Allgemein bekannt ist auch, daß sich auf DOS-Kommandoebene logische
   Geräte vom Typ Zeichentreiber fast wie Dateien verwenden lassen, etwa
   COPY a:\text.txt PRN: etc.

   Aus diesen Gründen ist es auch naheliegend, solche Geräte ähnlich wie
   Dateien abzufragen.

   Für Dateien gilt:

    IF EXIST path\filename ECHO Datei 'path\file' vorhanden!

   Für logische Geräte vom Typ Zeichentreiber gilt:

    IF EXIST device ECHO Gerätetreiber für 'device' vorhanden!

    wobei 'device' das zu überprüfende Gerät angibt (dies funktioniert
    auch unter 4DOS (zumindest auf einem Novell DOS 7 System), trotzdem
    sollte man noch eine Sonderbehandlung einbauen, s.u.).

   Das können z.B. folgende sein (\dev\ kann immer vorangestellt werden):

    NUL       Null-Device (liefert als Eingabe immer EOF und als Ausgabe
              schluckt es alle Informationen auf Nimmerwiedersehen).
              Im Gegensatz zu den anderen Geräten in IBMDOS.COM definiert.
    CON       Konsole (Ein- und Ausgabe, siehe CTTY Kommando in Kapitel
              II.11.), in IBMBIO.COM definiert.
    PRN       Standarddrucker (i. allg. = LPT1), in IBMBIO.COM definiert.
    LPT1      Drucker 1 (Gerät an erstem parallelem Port).
              Üblicherweise in der sortierten Reihenfolge 3BCh, 378h und
              278h, in IBMBIO.COM definiert.
    LPT2      Drucker 2 (Gerät an zweitem parallelen Port),
              in IBMBIO.COM definiert.
    LPT3      Drucker 3 (Gerät an drittem parallelen Port),
              in IBMBIO.COM definiert.
    AUX       Standard-Kommunikationsgerät (i. allg. = COM1),
              in IBMBIO.COM definiert.
    COM1      Serielle Schnittstelle 1 (üblich ist 3F8h),
              in IBMBIO.COM definiert.
    COM2      Serielle Schnittstelle 2 (üblich ist 2F8h)
              in IBMBIO.COM definiert.
    COM3      Serielle Schnittstelle 3 (üblich ist 3E8h),
              in IBMBIO.COM definiert.
    COM4      Serielle Schnittstelle 4 (üblich ist 2E8h),
              in IBMBIO.COM definiert.

   Aber es gibt noch viele andere logische Geräte, die man abtesten kann.
   Hier kommen insbesondere per DEVICE geladene Programme in Frage und vor
   allem Systemtreiber, die sich i. allg. als Zeichentreiber ausgeben,
   obwohl sie keine sind (auf sie kann nicht geschrieben, von ihnen nicht
   gelesen werden, d.h. die DOS-Umleitung auf solche Geräte funktioniert
   nicht).

   Ein paar relativ weitverbreitete Beispiele:

    CLOCK$    Interne Uhr
    IDLE$     Dynamische Wartezeiterkennung von TASKMGR (Novell DOS 7),
              war auch schon bei DR DOS 5.0+ vorbereitet, wurde aber von
              deren Speichermanagern und DR DOS 6.0 TASKMAX nicht
              aktiviert. Wenn der TASKMGR als Multitasker läuft, kann
              die Idle-Erkennung mit dem COMMAND.COM internen Kommando
              IDLE ON|OFF ein- oder ausgeschaltet werden.
    $SECURE$  SECURITY.SYS bei Novell DOS 7
    RPL       Remote-Program-Loader für das Booten von einem NetWare-Server
              (auch PNW), ohne daß der Client-Rechner mit eigenen Laufwerken
              ausgestatten sein müßte. Die Netzadapterkarte benötigt dafür
              ein spezielles Boot-PROM.
    LPT4      vierter Drucker, unterstützt von CCI Multiuser DOS 7.22 Gold
    AUX?      serielle Ports, unterstützt von CCI Multiuser DOS 7.22 Gold

    XMSXXXX0  Extended Memory Manager (XMS) (HIMEM)
    EMMXXXX0  Expanded Memory Manager (EMS/EMM) (EMM386/EMMXMA)
    EMM$$$$$  ""
    QMMXXXX0  Quarterdeck Memory Manager
    QEXTXXX0  Quarterdeck Extended Memory Manager
    QEMM386$  Quarterdeck 386 Memory Manager
    $MMXXXX0  MM-Speichermanager
    386MAX$$  386Max-Speichermanager
    EMMQXXX0  Expanded Memory Manager (EMS/EMM), nicht aktiv
    EMMXXXQ0  Expanded Memory Manager (EMS/EMM), nicht aktiv
    EXTXXX@   manchmal: 'rohes' Extended Memory über INT15h??? (NWCACHE)
    VCPIXXX0  VCPI-Manager (EMM386/HIMEM/THREADS.SYS)
    DPMIXXX0  DPMI-Server (EMM386/HIMEM/DPMI.SYS)
    QDPMI$$$  DPMI-Server (QEMM 386)
    DPMSXXX0  DPMS-Server, falls per DEVICE= geladen (Novell EMM386, DPMS)
              (nicht, wenn durch CLOAKING.EXE bereitgestellt)
    CLOAK$$$  Helix CLOAKING-Server (CLOAKING.EXE)
    HMALDSYS  Helix HMA-Lader
    $SIZER$   Helix Treiber zur Ermittlung der Programmgröße
    VMXXXXX0  VM-Manager (MS Windows/TASKMGR ?)
    HOOKROM$  Quarterdeck QEMM HOOKROM-Treiber
    KSP$UMM   Key Softwares Memory Manager
    LA$TBYTE  Key Softwares "The Last Byte"

    SETVERX0
    SETVERXX  durch SETVER.EXE

    PC$MOUSE  Mouse Systems Maustreiber ("PC", 3-Tasten-Maus, etc.)
    MS$MOUSE  Microsoft Maustreiber (manchmal jedoch auch PC$MOUSE)
    TC$MOUSE  Logitech Maustreiber (meist jedoch auch PC$MOUSE)
    gmouse    Genius Maustreiber (meist jedoch auch PC$MOUSE)

    IFS$HLP$  Installable File System Hilfstreiber (auch WfW)
              (MS Windows95/MS-DOS 7 Long-Filename-Support: IFSHLP.SYS)
    NET$HLP$  Diverse Netztreiber (TCP/IP, WfW, usw.)
    @!NETW!@  Novell NetWare Treiber
    PROTMAN$  Microsoft LAN Manager

    MSCD001   Default-Name für erstes CD-ROM-Laufwerk
    OEMCD001  Default-Name für einige CD-ROM-Treiber
    CDROM     Sony CD-ROM Erweiterungen

    SMARTAAR  SMARTDrive Disk-Cache
    _doubleB  SMARTDrive Double Buffer Treiber
    CACHCMPQ  Compaq Disk Disk-Cache
    CACHE$$$  HyperDisk Disk-Cache
    $$$CACHE  IBM Disk-Cache
    _Cache__  PC Chips Hard Disk-Cache
    CACHE__Q  Datamorphics Disk-Cache
    @CACHE-X  Norton Cache
    @CACHE-F  Norton Cache (Schnell)
    @CACHE-S  Norton Cache (Klein)

    $ADDSTOR  SuperStor Disk-Kompressor
    DBLSSYS$  DoubleSpace Disk-Kompressor
    DBLSYSH$  MS-DOS Doublespace/Drivespace Hilfstreiber

    SCSITAPE  Seagate ST-01 Treiber (Brian Antoine)
    rocket    Ontrack IDE-Festplattenbeschleuniger
    VGA-Read  Public-Domain-Treiber VGAREAD.EXE (falls per DEVICE=/
              DEVICEHIGH= geladen) zum Lesen höherer Diskettenformate
              (VGACOPY)

    EGA$      Microsofts EGA.SYS Treiber
    MONODISP  CON-Bildschirmtreiber für MDA-/HGC-Monitor
              (Zweimonitorsysteme)
    MONO      (MONO.SYS/DUALMON.SYS)
    CO80DISP  CON-Bildschirmtreiber für Farbmonitor (Zweimonitorsysteme)
    COLOR     (COLOR.SYS/DUALMON.SYS)

    KBD$BUF$  K3PLUS.SYS/.COM bzw. FreeKEYB-Tastaturtreiber mit erweitertem
              Tastaturpuffer sowie MS-DOS Dummy: KBDBUF.SYS
    K3PLUS$   Ältere K3PLUS.SYS Versionen
    CPQKEYB   Compaq Tastaturtreiber
    4DOSSTAK  4DOS erweiterter Tastaturpuffer
    NDOSSTAK  NDOS erweiterter Tastaturpuffer

    TDHDEBUG  Borland Turbo Debugger
    SOFTICE   Debugger
    NU-MEGA   NuMega CodeView Magic
    SYSLOAD   Periscope Debugger

   Um an die Gerätenamen zu kommen (die von den Dateinamen der Geräte-
   treiber abweichen können), kann man z.B. MEM /I aufrufen.

   Blocktreiber (z.B. RAMDRIVE, TurboDSK, MSCDEX, NWCDEX etc.) haben
   i. allg. keinen Namen, ihnen wird stattdessen ein Laufwerk zugeordnet.

   Zwei Beispiele für Zeichentreiber:

    a) NWCDEX nur laden, wenn in CONFIG.SYS auch ein Hardware-Treiber für
       CD-ROM eingebunden wurde.

    REM Das \dev\ ist unter heutigen DOS-Versionen optional:
    IF "%@Eval[2 + 2]%"=="4" IF "%@Device[\dev\MSCD001]%"=="0" GOTO no_cd
    IF NOT EXIST \dev\MSCD001 GOTO no_cd
    @LH NWCDEX /d:MSCD001 /m:32 /l:h
    :no_cd

    b) Eine Warnung ausgeben, wenn ein für eine Anwendung nötiger Speicher-
       manager nicht geladen ist (Pseudo-Zeichentreiber).

    REM Das \dev\ ist unter heutigen DOS-Versionen optional:
    IF "%@Eval[2 + 2]%"=="4" IF "%@Device[\dev\EMMXXXX0]%"=="0" GOTO error
    IF NOT EXIST \dev\EMMXXXX0 GOTO error
    REM Anwendung starten (Anwendung benötigt EMS-Speicher)
    anwendung
    GOTO end
    :error
    ECHO Leider kein EMM-Speichermanager geladen, daher kein EMS-Speicher
    ECHO verfügbar.
    ECHO Verwenden Sie z.B. DEVICE=EMM386.EXE in CONFIG.SYS, um passenden
    ECHO Treiber zu laden.
    :end

   Solange es um logische Laufwerke (Blocktreiber) geht, wird man die
   Existenz häufig mit z.B.

    IF DIREXIST f:\ ECHO Laufwerk vorhanden! (nur bei Novell DOS und
                                             4DOS 5.5+) auch Netzlaufwerke!
    IF EXIST f:\nul ECHO Laufwerk vorhanden! (auch bei MS/PC-DOS, sowie
                                             nach meinen Erfahrungen auch
                                             bei Novell DOS 7, jedoch nicht
                                             bei späten Versionen von
                                             DR DOS 6.0)

   abtesten, sollten jedoch unformatierte (aber vorhandene) Laufwerke auf
   diese Art und Weise angesprochen nicht werden (z.B. TurboDSK mit
   Laufwerksgröße 0 oder Treiber, deren Spezialgeräte noch nicht initia-
   lisiert sind), würde eine Fehlermeldung erscheinen. Leider scheint es
   in diesem Fall keine Ausweichmöglichkeit zu geben, außer wenn man für
   jeden solchen Blocktreiber zusätzlich noch einen Zeichentreiber mit
   einem entsprechenden Namen laden würde. Unter 4DOS kann man auch
   IF ISDIR f:\ ... verwenden. Eine andere Methode, die Existenz von
   Verzeichnissen abzutesten, wird in Kapitel IV.6. angedeutet.

   In früheren DOS-Versionen gab es eine Möglichkeit, zwischen der
   obigen laxen Form und einer schärferen Methode zu unterscheiden
   (INT21h/3702h und INT21h/3703h 'AVAILDEV'). Heutzutage wird i. allg.
   nur noch die laxe Form unterstützt, d.h. Geräte liegen 'virtuell'
   in jedem Verzeichnis. Ansonsten müssen Sie dem Gerätenamen noch
   \DEV\ (analog zu Unix) voranstellen, um darauf umzuleiten oder um
   dessen Existenz zu überprüfen.

                                                                             
  ---------------------------------------------------------------------------

  IV.4. Novell DOS Kompatibilität unter 4DOS erhöhen: [97-02-22]
  ==============================================================

   Stichworte: Batchjobs, 4DOS, NDOS, Kompatibilität

   Dieses Kapitel beschreibt verschiedene Tips und Tricks, die angebracht
   sind, wenn man Batchjobs nicht nur für ein Betriebssystem schreiben
   will, aber trotzdem nach Möglichkeit auch erweiterte Fähigkeiten etwa
   von Novell DOS oder 4DOS nutzen möchte.

   Ähnliche Hinweise sind an den entsprechenden Stellen über das ganze
   Dokument verstreut zu finden und werden dort im jeweiligen Zusammenhang
   motiviert und diskutiert. Hier wird eine Zusammenfassung dieser Möglich-
   keiten gegeben. Wird der folgende Beispiel-Batchjob (der an eigene Be-
   dürfnisse angepaßt werden muß) in die Behandlung von AUTOEXEC.BAT ein-
   gebunden, werden einige Umgebungsvariablen und Aliase gesetzt, die unter
   4DOS fehlende Kommandos von Novells COMMAND.COM ersetzen, übersetzen
   oder zugänglich machen. Gleichzeitig wird auch noch DR DOS und MS-DOS
   supportet (%Ver% muß manuell gesetzt werden, vgl. Kapitel IV.7.).

   Beispiel:

   4DOSCOMP.BAT:

    @ ECHO off > \dev\nul
      ECHO off > \dev\nul
      IF NOT ""=="%batdbg%" ECHO %batdbg%
      IF NOT "4"=="%@Eval[2 + 2]%" GOTO end
      LOADBTM on

      REM DR DOS compatibility: --------------------------------------------
      IF "DRMDOS"=="%Os%" GOTO drmdos
      IF "MDOS"=="%Os%" GOTO drmdos
      IF NOT "DRDOS"=="%Os%" GOTO nwdos7
      REM This check does not work, if %Ver% is not set manually!!
      IF NOT "3.41"=="%Ver%" IF NOT "5.0"=="%Ver%" GOTO drdos6

      ALIAS ASSIGN `c:\drdos\COMMAND.COM /C ASSIGN %&`
      ALIAS JOIN `c:\drdos\COMMAND.COM /C JOIN %&`
      ALIAS MORE `c:\drdos\COMMAND.COM /C MORE %&`
      ALIAS SUBST `c:\drdos\COMMAND.COM /C SUBST %&`
      ALIAS DRHELP `c:\drdos\DOSBOOK.EXE %&`
      GOTO drdos

      :drdos6
      ALIAS DRHELP `c:\drdos\DOSBOOK.EXE %&`
      GOTO drdos

      :drmdos
      REM Dummy for DR Multiuser DOS 5.1 (%Ver%=5.1, %Os%=DRMDOS) or
      REM CCI Multiuser DOS 7 (%Ver%=7.xx, %Os%=MDOS), just to
      REM show how to handle this...

      :drdos
      ALIAS DBG `c:\drdos\COMMAND.COM /C DBG %&`
      ALIAS IDLE `c:\drdos\COMMAND.COM /C IDLE %&`
      ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
            ... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
      ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`

      :nwdos7
      REM Novell DOS compatibility: ----------------------------------------
      IF NOT "NWDOS"=="%Os%" GOTO opendos

      ALIAS NWHELP `c:\nwdos\DOSBOOK.EXE %&`
      ALIAS TM `TASKMGR /F /C %ComSpec% /C %&`
      ALIAS IDLE `c:\nwdos\command.com /C IDLE %&`
      ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
            ... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
      IF NOT "%_4Ver%"=="5.51" IF NOT "%_4Ver%"=="5,51" GOTO no4dos551
      REM Avoiding a bug with 4DOS 5.51 (not with 4DOS 5.5a/b/c nor ...
                                                            ... 4DOS 5.52a):
      REM Won't always work :-(
      ALIAS MEMMAX `c:\nwdos\COMMAND.COM /C c:\nwdos\MEMMAX %&`
      :no4dos551
      ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`

      :opendos
      REM Caldera OpenDOS compatibility: -----------------------------------
      IF NOT "OPENDOS"=="%Os%" GOTO msdos

      ALIAS CAHELP `c:\nwdos\DOSBOOK.EXE %&`
      ALIAS TM `TASKMGR /F /C %ComSpec% /C %&`
      ALIAS IDLE `c:\opendos\command.com /C IDLE %&`
      ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
            ... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
      IF NOT "%_4Ver%"=="5.51" IF NOT "%_4Ver%"=="5,51" GOTO no4dos551
      REM Avoiding a bug with 4DOS 5.51 (not with 4DOS 5.5a/b/c nor ...
                                                            ... 4DOS 5.52a):
      REM Won't always work :-(
      ALIAS MEMMAX `c:\opendos\COMMAND.COM /C c:\opendos\MEMMAX %&`
      :no4dos551
      ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`

      :msdos
      REM MS-DOS compatibility aliases: ------------------------------------
      IF "DRDOS"=="%Os%" GOTO all
      IF "NWDOS"=="%Os%" GOTO all
      IF "OPENDOS"=="%Os%" GOTO all

      ALIAS MSHELP `c:\dos\help.com %&`
      ALIAS SEL `c:\dos\select.exe %&`
      ALIAS APP `c:\dos\command /C APPEND`
      REM Simulate DR DOS/Novell DOS RENDIR
      ALIAS RENDIR `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ ECHOS ...
              ... "REN /S %&" %+ *REN /? %& %+ ELSE %+ *REN /S %& %+ ENDIFF`

      :all
      REM For better access to help systems: -------------------------------
      ALIAS 4DHELP *HELP
      ALIAS NDHELP *HELP

      REM For 1DIR+ compatibility: -----------------------------------------
      ALIAS 1DIR `SETDOS /l1 %+ 1DIRPLUS`
      ALIAS 1D 1DIR
      ALIAS 1E `SETDOS /l0`

      REM For generally DR DOS/Novell DOS batchjob backward compatibility: -
      REM DR DOS 3.41 undocumented BATCH command (guess):
      ALIAS BATCH = %%&
      REM DR DOS 5.0+/Novell DOS Erase commands:
      ALIAS ERA ERASE
      ALIAS DELQ `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ ECHOS "DEL ...
                   ... /P %&" %+ *DEL /? %& %+ ELSE %+ *DEL /P %& %+ ENDIFF`
      ALIAS ERAQ DELQ
      REM DR DOS 6.0 undocumented error output handling:
      ALIAS ECHOERR `(ECHO %&)>&> \dev\con:`
      ALIAS PAUSEERR `(PAUSE %&)>&> \dev\con:`
      ALIAS HILOAD LH
      REM Fix for Novell DOS/DR DOS "AND" (but may replace message ...
                                                           ... strings, too)
      ALIAS AND IF
      REM No fix for Novell DOS/DR DOS "OR" possible.
      ALIAS SWITCH `*INKEY /D %%choice %+ *GOSUB ...
                        ... %@Word[%@Eval[%choice%-1]%,%&]% %+ *SET choice=`

      REM Misc -------------------------------------------------------------
      SET ;=;
      REM Workaround for 4DOS 5.51/5.52a TYPE bug with passwords
      IF "5.51"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
      IF "5,51"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
      IF "5.52"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
      IF "5,52"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
      :end

                                                                             
  ---------------------------------------------------------------------------

  IV.5. MEM /FREE und /MODULE bei Novell DOS nachrüsten: [96-07-14]
  =================================================================

   Stichworte: MEM, Internationale Batchjob, Greeting_Time

   In Kapitel II.4. wird beschrieben, daß Novell DOS' MEM Befehl die
   von MS-DOS bekannten Optionen /FREE und /MODULE=<name> fehlen, obwohl
   Novell DOS 7 ab Update 14 UMB-Memory-Regions unterstützt. Die fehlenden
   Parameter kann man aber mit dem beiliegenden Batchjob leicht nachrüsten
   (lediglich die Syntax von /MODULE=<name> ist leicht eingeschränkt, denn
   zwischen /MODULE und <name> muß ein Leerfeld vorkommen).

   Nebenbei bietet dieser Wrapper auch noch zwei neue Parameter, nämlich
   /REGION zum Auflisten der einzelnen UMB-Regionen und /VECTORS zum Auf-
   listen der Interrupt-Belegung, wobei noch verschiedene Kriterien ange-
   geben werden können. Gleichzeitig ist dieser Batchjob auch ein Beispiel
   für die 'höhere Kunst der Programmierung von Batchjobs' und deshalb
   nehmen viele Passagen in diesem Dokument auch aus anderen Gründen auf
   bestimmte Features in diesem Beispiel Bezug, z.B. Erkennung des aktuellen
   SwitChars, Erkennung des DOS-Kernels, Erkennung des Kommandoprozessors,
   Erkennung der Landessprache...

   MEM.BAT:

    > Aufgrund der Länge dieses Batchjobs wird dieser Batchjob nun nur  <
    > noch als eigenständige Datei MEM.BAT im Paket mitgeliefert.       <

                                                                             
  ---------------------------------------------------------------------------

  IV.6. Batchjobs und Umleitungen: [97-04-23]
  ===========================================

   Stichworte: MEM.BAT, FIND, SORT, MORE, DEL *.*, DATE, TIME, %Temp%,
               spezielle Steuerzeichen, temporäre Dateien

   - Unter Novell DOS 7 COMMAND.COM ist es möglich, die Ein- und Ausgabe-
     umleitung nicht nur für einzelne Kommandos, sondern auch für ganze
     Batchjobs zu verwenden (DR DOS 6.0 COMMAND.COM bot diese Möglichkeit
     wohl noch nicht).
     Ein Beispiel hierfür gibt der Batchjob MEM.BAT aus dem Kapitel IV.5.
     Allerdings muß man beachten, daß dies nur solange funktioniert, wie
     innerhalb des Batchjobs keine weiteren Umleitungen und Pipes ver-
     wendet werden, da diese ignoriert werden (Wieso eine Umleitung auf
     das Null-Device \dev\nul offenbar nicht stört, ist mir noch nicht
     ganz klar). 4DOS.COM kann hier natürlich wesentlich mehr, denn dort
     sind Umleitungen beliebig verschachtelbar...

     Andererseits kann man für diese Zwecke manchmal auch das Kommando
     CTTY verwenden (siehe Kapitel II.11.) und damit sogar die Ausgabe
     von AUTOEXEC.BAT 'umleiten'.

   - Novells COMMAND.COM (getestet mit Update 15) bietet in Verbindung
     mit Umleitungen eine ganze Reihe undokumentierter Möglichkeiten, die
     Parameter in der Kommandozeile anzuordnen. Normalerweise geht man
     davon aus, daß die Parameter zu einem Kommando, evtl. gefolgt von
     einer Umleitung, unmittelbar nach dem Kommando stehen müssen. Dem
     ist aber nicht notwendigerweise so:
     Ein- und Ausgabeumleitungen ('>', '>>' und '<') werden von einem
     Dateinamen gefolgt (evtl. noch von einem Paßwort) und sind damit
     eindeutig bestimmt. Deshalb kann man dieses Konstrukt an beliebiger
     Stelle anordnen, ohne daß es Probleme mit der Erkennung der Umleitung
     geben würde, auch in gemischter Reihenfolge mit den Parametern des
     Kommandos:

      DIR > dummy.txt *.* /W
      DIR *.* > dummy.txt /W
      > dummy.txt DIR *.* /W

     entsprechen also alle dem üblicheren

      DIR *.* /W > dummy.txt

     Das Pipe-Symbol ('|') kann hiermit allerdings nicht überwunden
     werden und dient (auch) als Trenner zwischen Kommandos (vgl. auch
     Kapitel II.11.). Glücklicherweise akzeptiert auch 4DOS (5.52a)
     diese gemischte Anordnung von Parametern und Umleitungen (und auch
     MS-DOS und PC-DOS COMMAND.COM sollen diese Varianten unterstützen,
     verifiziert habe ich das jedoch noch nicht). Für OS/2 CMD ist diese
     Syntax mit leicht erweiterter Semantik besonders in bedingungsab-
     hängigen Anweisungen verwendbar.

   - Es ist übrigens bei Novells COMMAND.COM (offenbar ebenfalls aus
     Gründen syntaktischer Kompatibilität zu OS/2 CMD) möglich, eine
     Dummy-Umleitung zu verwenden:

      DIR *.* > dummy1.lst > dummy2.lst
      DIR *.* >> dummy1.lst > dummy2.lst
      DIR *.* > dummy1.lst | MORE

     Die in diesen Beispielen verwendete Datei DUMMY1.LST wird ignoriert,
     d.h. sie wird weder angetastet noch erzeugt, auch nicht als temporäre
     Zwischendatei (der Name für diese Zwischendatei würde vom Betriebs-
     system selbst gewählt)! In Wahrheit kann hier ein beliebiger Text
     stehen, der überlesen wird. Diese doppelte Umleitung wird von 4DOS
     (5.52a) als Fehler zurückgewiesen.
     Von Novells COMMAND.COM wird innerhalb eines Blocks nur die jeweils
     letzte gleichartige Umleitung benutzt (gilt für '>', '>>' und '<').

   - Wird das '>'-Zeichen für die Ausgabeumleitung bei Novells COMMAND.COM
     verdoppelt, wird - wie allgemein bekannt - die Zieldatei nicht ge-
     löscht, sondern der neue Inhalt hinten angehängt. Verdreifacht man das
     Zeichen, so wird dies wieder wie *ein* '>'-Zeichen ausgewertet. Ein
     vierfaches '>>>>' wirkt wieder wie ein '>>', usw..
     Im letzten Punkt unterscheidet sich 4DOS wieder, mehr als ein
     verdoppeltes '>'-Zeichen (">>") werden immer als einfaches '>'
     gewertet.

   - Bei der Programmierung von Batchjobs muß man beachten, daß Novell DOS
     COMMAND.COM (im Gegensatz zu 4DOS/NDOS.COM) die Umleitung einer Zeile
     eines Batchjobs auch dann auswertet, wenn am Anfang der Zeile eine
     Bedingung steht, die nicht erfüllt ist. Dies kann, besonders in Ver-
     bindung mit FIND.EXE, SORT.EXE oder MORE.COM (aber auch DEL *.*, TIME,
     DATE etc.), zu schwer auffindbaren Fehlern führen.

     Zur Verdeutlichung ein Beispiel (Auszug aus einem Batchjob):

      ...
      IF "Bytes"=="%1" DIR *.* | FIND "Bytes"
      IF NOT "Bytes"=="%1" DIR *.* | SORT
      ...

     Enthält %1 den Wert "Bytes", so wird der erste DIR Befehl problemlos
     ausgeführt (und FIND extrahiert die Zeilen mit %1). Die zweite Be-
     dingung ist allerdings nicht erfüllt, sollte also übersprungen werden.
     Trotzdem hängt der Batchjob beim zweiten DIR. Dies liegt daran, daß
     zwar die Bedingung nicht erfüllt ist, d.h. das zweite DIR *.* nicht
     ausgeführt wird, aber die Pipe für SORT wird davon nicht beeinflußt.
     COMMAND.COM führt also '| SORT' aus, d.h. SORT wartet ewig auf eine
     Eingabe und ein abschließendes ^Z aus der Eingabeumleitung. Normaler-
     weise läßt sich der Batchjob mit <Ctrl>+<c> abbrechen.
     Enthält %1 nicht den Wert "Bytes", tritt der gleiche Fehler in der
     ersten Bedingung auf. COMMAND.COM führt dann '| FIND "Bytes"' aus,
     d.h. FIND wartet ewig auf eine Eingabe.

     Abhilfe besteht darin, daß derartige Zeilen mit Umleitungen so
     umkonstruiert werden, daß entweder sichergestellt wird, daß Filter
     wie FIND, SORT, MORE etc. auf irgendeine Weise ein abschließendes ^Z
     erhalten oder daß die Zeile, die die Umleitung enthält, nicht ausge-
     führt wird, wenn dadurch dieser Fehler auftreten kann. Ein Beispiel:

      ...
      IF "Bytes"=="%1" GOTO dir1
      IF NOT "Bytes"=="%1" GOTO dir2
      GOTO skip
      :dir1
      DIR *.* | FIND "Bytes"
      GOTO skip
      :dir2
      DIR *.* | SORT
      :skip
      ...

     Die gleichen Probleme treten z.B. auch bei Befehlen wie

      ...
      IF "German"=="%1" ECHO J | DEL *.*
      ...

     auf (und sind in diesem Beispiel besonders gefährlich). Abhilfe
     ist mit folgender Umkonstruktion möglich:

      ...
      IF NOT "German"=="%1" GOTO skip
      ECHO J | DEL *.*
      :skip
      ...

     Umleitungen auf z.B. \dev\nul sind aus diesen Gründen unkritisch.

   - Ein ähnlich gelagerter Fall ist der REM-Befehl. Auch hier wertet
     Novells COMMAND.COM aus Kompatibilität zu MS-DOS Umleitungen aus,
     d.h.

      REM | DIR *.*

     führt durchaus das DIR *.* aus (siehe Kaptitel II.11.).

   - Novell DOS behandelt auch (exotische) Anweisungen wie "DIR /P | MORE"
     problemlos (dies galt nicht für DR DOS, abgesehen von DR DOS 6.0
     Updates nach 1992).

   - Ein anderes Problem mit Umleitungen bei Novells COMMAND.COM (nicht
     bei 4DOS/NDOS) in Verbindung mit SHARE:

      ...
      ECHO Report something to file > %tmp%\report.$$$
      REM If "applic is a batchjob, "applic" shall be called by "CALL" to
      REM avoid exiting this batchjob. But: As a result of redirection, a
      REM sharing violation occurs here, if "applic" actually is a batchjob.
      @CALL applic >> %tmp%\report.$$$
      ...

     Dieses Problem kann umgangen werden, indem man "CALL" durch
     "%ComSpec% /C" ersetzt:

      ...
      ECHO Report > %tmp%\report.$$$
      REM To avoid sharing violation with COMMAND.COM, call via
      @%ComSpec% /C applic >> %tmp%\report.$$$
      ...

     Achtung: Nach dem "/C" ist kein '@'-Zeichen erlaubt, wie man es sonst
     (in einem Batchjob oder unter 4DOS/NDOS) einem Kommando vielleicht
     voranstellen würde! Das '@'-Zeichen vor dem %ComSpec% ist im Prinzip
     überflüssig, hat aber unter 4DOS/NDOS eine besondere Funktion.

     Ein sehr ähnliches Problem mit Umleitungen, CALL und SHARE existiert
     auch bei MS-DOS COMMAND.COM, wenn auch unter leicht anderen Voraus-
     setzungen (siehe MSDOSTIP.TXT). Glücklicherweise kann man beide
     Probleme auf identische Art und Weise aus dem Weg räumen, so daß
     hier keine weitere Fallunterscheidung zwischen MS-DOS und Novells
     COMMAND.COM notwendig ist.

   - Die Zeichen ">", "<" und "|" sind - abgesehen von der Verwendung in
     Umleitungen - verständlicherweise nicht erlaubt.
     Es gibt zwei Ausnahmen:

     a) Novells erweiterte Syntax des IF Befehls läßt die Zeichen ">" und
        "<" auch als 'Größer' und 'Kleiner' (auch in allen Kombinationen mit
        "=") zu, ohne daß sie dabei als Umleitung interpretiert werden. Da
        diese Syntax aber von anderen Kommandoprozessoren nicht unterstützt,
        sondern fehlinterpretiert wird, sollte man auf diese Möglichkeit
        verzichten.

     b) Einige Befehle erlauben/erfordern es, die Argumente in doppelte
        Anführungszeichen (") einzuschließen (z.B. FIND). Innerhalb eines
        solchen Blocks werden Umleitungen nicht ausgewertet, d.h.
        Konstruktionen wie

         DIR *.* | FIND "<DIR>" > dirlist.lst

        sind problemlos möglich (auch bei MS-DOS, und 4DOS/NDOS).
        Näheres zu dieser Klammerungsmöglichkeit in Kapitel II.11. und
        anderen Methoden zur Verzeichnisabfrage in Kapitel IV.3.

   - Das Zeichen "%" ist ebenfalls für Variablen (Parameter, Umgebungs-
     variablen und Systeminformationskonstanten) reserviert. Möchte man
     das Zeichen dennoch ausgeben, muß man es verdoppeln:

      IF ""=="%tmp%" ECHO Die Variable %%tmp%% ist nicht belegt!

     Achtung: Unter anderen Kommandoprozessoren kann dies zu Fehlinter-
              pretationen führen. Weitere Hinweise bezüglich der Ver-
              doppelung von % siehe BATTIPS.TXT.

   - Manchmal ist es bei Problemen mit Batchjobs, die Umleitungen ver-
     wenden, hilfreich, sich im Nachhinein die temporären Dateien mit
     UNDELETE zurückzuholen und danach zu begutachten.

     Die temporären Zwischendateien, die COMMAND.COM bei Umleitungen
     automatisch anlegt und nach Gebrauch wieder löscht, werden im %Temp%\
     Verzeichnis abgelegt. Da hierfür die DOS-API-Funktion zum Erzeugen
     temporärer Dateien mit eindeutigem Namen verwendet wird, haben diese
     Dateien beim Novell DOS (und MS-DOS) Kernel 8 Zeichen lange Namen,
     die ausschließlich Buchstaben enthalten, und keine Endung. Außerdem
     besitzen sie das System-Attribut. DR DOS hingegen erzeugte Dateien,
     die nur Ziffern enthielten. 4DOS benutzt nicht diese API-Funktion und
     erzeugt Namen, die sowohl Ziffern, als auch Buchstaben enthalten und
     die Endung entspricht als Ziffer offenbar der Verschachtelungstiefe(?).

   - Obwohl man üblicherweise Geräten, auf die man umleiten möchte, ein
     \dev\ oder jedes beliebige andere Verzeichnis voransetzen kann, gilt
     dies unter älteren DOS-Versionen und Netz-Treibern nicht für Netz-
     laufwerke. Hier tritt nämlich das Problem auf, daß keiner sich für
     derartige Bezeichnungen zuständig fühlt. Ein Beispiel:

     Ein Text soll über N:\TMP\LPT1 ausgedruckt werden, wobei N:\ ein
     Netzlaufwerk sei, etwa:

      TYPE text.txt > n:\tmp\lpt1

     DOS erkennt nun, daß es sich um ein Netzlaufwerk handelt und gibt
     daher die Anfrage an den Netztreiber weiter. Dieser erkennt jedoch,
     daß es sich um ein Gerät handelt und gibt die Anfrage zurück an DOS,
     das daraufhin eine Fehlermeldung ausgibt.
     Im Zuge der VLM-Updates wurde hier eine Lösung geschaffen, insofern,
     als daß die Netz-Treiber jetzt nur noch "lpt1" an DOS zurückliefern,
     und DOS dann im zweiten Anlauf damit zurecht kommt. Auf diese Weise
     werden auch die anderen Standard-Geräte behandelt.

                                                                           
  ---------------------------------------------------------------------------

  IV.7. Spezielle Umgebungsvariablen von Novell DOS/DR DOS: [97-03-26]
  ====================================================================

   Stichworte: Environment, Systeminformationskonstanten

   Der Platz für Umgebungsvariablen wird während der Initialisierung von
   COMMAND.COM reserviert (Mutterbereich), dazu allerdings vorher der
   Parameter /E:xxxx des Kommandoprozessors bei CONFIG.SYS SHELL= heran-
   gezogen. Das Setzen und Löschen geschieht z.B. über den COMMAND.COM-
   internen Befehl SET.

   - Vordefinierte Umgebungsvariablen:

     Die folgenden ansonsten völlig 'normalen' Variablen werden automatisch
     mit bestimmten Werten belegt, wenn nach der Bearbeitung von CONFIG.SYS
     der Kommando-Interpreter COMMAND.COM geladen wird. Einige dieser
     Variablen werden nur von DR DOS und Novell DOS unterstützt.

      %ComSpec%      Wie allgemein bei allen DOS-Kommandoprozessoren üblich:
                     Vollständiger Pfad+Name des aktuellen Kommando-Inter-
                     preters (COMMAND.COM), z.B. C:\NWDOS\COMMAND.COM.

                     Der Inhalt dieser Variable hängt üblicherweise von dem
                     Pfad ab, denn man bei der Initialisierung des ersten
                     Kommandoprozessors angibt (normalerweise C:\, wenn
                     nicht mittels CONFIG.SYS SHELL= umdefiniert, siehe
                     Kapitel II.11. und III.1.)

                     Kann COMMAND.COM nicht gefunden werden, fragt
                     Novell DOS nach Pfad und Namen zu einer gültigen Datei.
                     Der Pfad dieser Variable wird bei Novell DOS 7 und
                     späten Updates (ab 1992) von DR DOS 6.0 nicht auf
                     einen vollen Netz-Pfad erweitert, was verschiedene
                     diesbezügliche Probleme löst.

      %Os%           Gibt (ausschließlich) bei den Kommandoprozessoren
                     der ehem. Digital Research Betriebssystemfamilie
                     (COMMAND.COM) den Typ des Betriebssystems (eigentlich
                     besser: des Kommandoprozessors) aus der 'Digital
                     Research'-Familie an (für DR DOS und Novell DOS sind
                     die Werte dokumentiert):

                     - Caldera OpenDOS 7.01 : %Os%="OPENDOS"
                     - Novell DOS 7         : %Os%="NWDOS"
                     - DR PalmDOS           : ???
                     - DR DOS 3.40-6.0      : %Os%="DRDOS"
                     - IMS REAL/32          : ???
                     - IMS Multiuser DOS    : ???
                     - CCI Multiuser DOS    : %Os%="MDOS"
                     - DR Multiuser DOS     : %Os%="DRMDOS"
                     - Concurrent DOS       : %Os%="CDOS"
                     - Concurrent DOS/386   : %Os%="CDOS386"
                     - Concurrent PC-DOS    : %Os%="CPCDOS"
                     - DOSPlus              : ???
                     - MS-DOS/PC-DOS        : --           (nicht belegt)
                     - FreeDOS, DOS-C       : --           (nicht belegt)
                     - PTS/DOS, S/DOS       : --           (nicht belegt)

                     Während NetWare-Loginskripten gibt es eine vergleich-
                     bare System-Informationsfunktion namens %OS, die
                     mit der Einstellung NET.CFG: NETWARE DOS REQUESTER
                      DOS NAME=<MSDOS>
                     (siehe Kapitel VI.12.) korrespondiert und z.B. dazu
                     dient, unterschiedlichen Laufwerke in Anhängigkeit
                     von der DOS-Version der Arbeitsstation zu mappen.

      %Ver%          Gibt (ausschließlich) bei den Kommandoprozessoren
                     der ehem. Digital Research Betriebssystemfamilie
                     (COMMAND.COM) die Versionsnummer des Betriebssystems
                     (eigentlich besser: die Stufe des Kommandoprozessors
                     an:

                     - Caldera OpenDOS 7.01 : %Ver%="7" (das 7.01 bei VER
                                              wird festverdrahtet angehängt)
                     - Novell DOS 7         : %Ver%="7" (alle Updates,
                                                     keine Nachkommastelle!)
                     - DR PalmDOS           : ???
                     - DR DOS 6.0           : %Ver%="6.0"  (alle Updates)
                     - DR DOS 5.0           : %Ver%="5.0"
                     - DR DOS 3.41          : %Ver%="3.41"
                     - IMS REAL/32          : ???
                     - IMS Multiuser DOS    : ???
                     - CCI Multiuser DOS    : %Ver%="7.00", "7.21", "7.22"
                     - DR Multiuser DOS     : %Ver%="5.0", "5.1"
                     - DOSPlus              : ???
                     - MS-DOS/PC-DOS        : --           (nicht belegt)
                     - FreeDOS, DOS-C       : --           (nicht belegt)
                     - PTS/DOS, S/DOS       : --           (nicht belegt)

                     Verändert man den Inhalt dieser Variable, ändert sich
                     auch der Wert der Novell DOS 7 Systeminformations-
                     konstante %OS_Version% (s.u.), aber umgekehrt ändert
                     sich der Wert der in der Umgebung repräsentierten
                     Variable %Ver% nicht, wenn man die obige System-
                     informationskonstante mit einer gleichnamigen 'echten'
                     Variable überdeckt.
                     Achtung: %OS_Version% wird auch von NetWare-Clients
                     unterstützt und liefert dann auch bei *anderen*
                     Kommandoprozessoren Versionswerte (s.u.)!!!
                     Die Versionsausgabe des internen Kommandos VER hängt
                     vom Inhalt der Variable %Ver% ab, selbst, wenn man hier
                     keine Zahl angibt, siehe Kapitel II.11. bei VER!

      %Beta%         Undokumentiert und nur bei DR DOS 3.41 (vielleicht
                     noch bei DR DOS 3.40 und 3.42???): Erscheint als
                     zusätzlicher Text beim Laden einer temporären Kopie
                     von COMMAND.COM, und war wohl ursprünglich für zu-
                     sätzliche Ausgaben in der Beta-Testphase gedacht,
                     siehe auch DRDOSTIP.TXT.


   - Reservierte Umgebungsvariablen:

     Die folgenden Variablen haben keine vordefinierten Werte, müssen also
     explizit gesetzt werden. Einige dieser Variablen sind allgemeingültig
     für DOS, andere werden (oder wurden) ausschließlich von ehem. Digital
     Research Betriebssystemen benutzt.

     %Path%          Allg. Standard; (bei MS-DOS 6.0 - und nur dort -
                     ausschließlich in Verbindung mit "PATH /E");
                     siehe bei PATH in Kapitel II.11.

     %Append%        Allg. Standard, "APPEND /E"

     %Prompt%        Allg. Standard, meist $p$g.
                     Allerdings bei Kommandoprozessoren von DR DOS 6.0 und
                     Novell DOS 7 mit allerhand eigenen Ergänzungen, siehe
                     bei PROMPT in Kapitel II.1. und II.11.

     %Temp%          Allg. Standard für ein Temporärverzeichnis

     %HomeDir%       Nur bei DR DOS 5.0/6.0: undokumentiert.

     %$Cls%          Nur bei DR DOS 3.41+ und Novell DOS 7+ COMMAND.COM,
                     aber undokumentiert. Bei CCI Multiuser DOS 7.22 Gold
                     für MDOS.COM/TMP.EXE dokumentiert:
                     Kann mit Escape-Sequenz für ANSI.SYS für den Befehl
                     CLS belegt werden, üblicherweise leer, dann wird
                     je nach dem, ob ein ANSI-Treiber installiert ist,
                     die Sequenz "Esc [2J" ausgegeben oder der Bildschirm
                     durch Aufruf von BIOS-Funktionen gelöscht. Siehe auch
                     Kapitel II.11 bei CLS.

     %$On%           'RevOn', nur bei DR DOS 3.41+, Novell DOS 7+
                     COMMAND.COM, aber undokumentiert und standardmäßig
                     nicht belegt. Bei CCI Multiuser DOS 7.22 Gold für
                     MDOS.COM/TMP.EXE dokumentiert und enthält dort
                     üblicherweise die ANSI-Sequenz "Esc p".
                     Hat man einen ANSI-Treiber installiert, kann man die
                     Variable jedoch auch in Singleuser-Varianten verwenden:
                     Sie spezifiziert eine Sequenz, die vor der Ausgabe
                     von Dateinamen in TYPE-Auflistungen bei Verwendung von
                     Wildcards ausgegeben wird. Auf diese Weise kann man
                     die Dateinamen z.B. farblich hervorheben, einen Seiten-
                     vorschub auslösen, etc. Erlaubt auch die Angabe von
                     Sonderzeichen über die Spezialsyntax \ooo, wobei ooo
                     für die dreistellige Angabe des Zeichencodes als Oktal-
                     zahl steht (mit führender Null). Siehe auch in Kapitel
                     II.11. bei TYPE.

     %$Off%          'RevOff', nur bei DR DOS 3.41+, Novell DOS 7+
                     COMMAND.COM, aber undokumentiert und standardmäßig
                     nicht belegt. Bei CCI Multiuser DOS 7.22 Gold für
                     MDOS.COM/TMP.EXE dokumentiert und enthält dort
                     üblicherweise die ANSI-Sequenz "Esc q".
                     Hat man einen ANSI-Treiber installiert, kann man die
                     Variable jedoch auch in Singleuser-Varianten verwenden:
                     Sie spezifiziert eine Sequenz, die nach der Ausgabe
                     von Dateinamen in TYPE-Auflistungen bei Verwendung von
                     Wildcards ausgegeben wird. Auf diese Weise kann z.B.
                     eine farbliche Hervorhebung (siehe bei %$On%) wieder
                     aufgeben, etc. Erlaubt auch die Angabe von Sonder-
                     zeichen über die Spezialsyntax \ooo, wobei ooo für
                     die dreistellige Angabe des Zeichencodes als Oktalzahl
                     steht (mit führender Null). Siehe auch in Kapitel
                     II.11. bei TYPE.

     %PExec%         Nur bei DR DOS 6.0 und Novell DOS 7 COMMAND.COM:
                     Erweiterung für PROMPT-Execution $x), siehe auch
                     Kapitel II.11. bei PROMPT. Im Hilfeschirm der
                     deutschen Version von PROMPT /? wird der Name der
                     Variablen fälschlicherweise als %Exec% angegeben!

     %DRDOSCFG%      Nur bei DR DOS: Ablagepfad für .CFG- und .INI-Dateien
                     für DR DOS Tools z.B. DRDOS.INI usw.
                     Sollte bei Verwendung von DR VIEWMAX unter Novell DOS
                     auf den gleichen Wert wie %NWDOSCFG% gesetzt werden,
                     wo dann auch die alten TASKMAX.INI und VIEWMAX.INI
                     Dateien liegen sollten.

     %NWDOSCFG%      Novell DOS 7, analog zu %DRDOSCFG%.
                     Ablagepfad für .CFG- und .INI-Dateien für Novell DOS
                     Tools z.B. NWDOS.INI usw.

     %OPENDOSCFG%    Caldera OpenDOS (7.01), analog zu %NWDOSCFG%.
                     Ablagepfad für .CFG- und .INI-Dateien für Caldera
                     OpenDOS Tools z.B. OPENDOS.INI usw.
                     Beim Mischen von Novell DOS 7 und Caldera OpenDOS 7.01
                     Systemen (z.B. im Rahmen von Updates) sollten sie beide
                     Variablen entsprechend belegen und beide Konfigura-
                     tionsdateien NWDOS.INI und OPENDOS.INI im gleichen
                     Verzeichnis ablegen.

     %87%            Nur bei DR DOS, nicht bei Novell DOS:
                     Gültige Werte: "Y" für Ja.
                     Aktiviert Unterstützung für Coprozessor und wird
                     von vielen externen Kommandos unterstützt, die mit
                     Borland C programmiert wurden (z.B. REPLACE.EXE,
                     SSTORCHR.EXE). Wahrscheinlich nur eine Abfrage der
                     Borland RunTime-Library und ohne echte Funktion in
                     den Programmen.

     %FBP_User%      Für Novell DOS 7 FastBackup FBX: Name des Benutzers

     %NWLanguage%    PNW, NetWare: Sprache für das \NLS\%NWLanguage%\
                     Verzeichnis und .MSG-Dateien, z.B. in Großbuchstaben:
                     "DEUTSCH", "ENGLISH", usw., siehe auch Kapitel II.16.
                     Diese Variable kann nicht nur den Namen des Unter-
                     verzeichnisses von \NLS\ aufnehmen, sondern darf eine
                     gültige relative Pfadangabe enthalten. Angenommen, die
                     Dateien würden sich in Wirklichkeit nicht in
                     C:\NWCLIENT\NLS\ sondern in C:\NWCLIENT\TEST\ befinden,
                     könnte man %NWLanguage% mit ..\TEST\DEUTSCH belegen.
                     Siehe auch Kapitel VI.2.
                     Ist %NWLanguage% nicht definiert oder zeigt auf eine
                     falsche Position, so wird üblicherweise %Path% ausge-
                     wertet. Evtl. gab es früher einmal eine andere Variable
                     namens %Language%, jedenfalls taucht dieser Variablen-
                     name immer wieder in den Hilfemeldungen von PNW auf.

     %LoginName%     Nur bei Novell DOS 7 COMMAND.COM:
                     (nicht zu verwechseln mit %Login_Name%!!!).
                     Falls diese Variable mit einem Wert belegt wird,
                     wird der jeweils aktuelle Inhalt für den Spezial-
                     Token $u bei PROMPT eingesetzt, siehe Kapitel II.11.
                     Da die Variablenersetzung nicht bei der Definition des
                     PROMPTs, sondern jedesmal bei Ausgabe des PROMPTs
                     erfolgt, lassen sich damit natürlich auch andere recht
                     interessante 'Spielereien' treiben.

     %TZ%            Nur für Novells Personal NetWare 1.0 SNMP-Dienste
                     (speziell PNWTRAP.VLM):
                     Angabe der örtlichen Zeitzone zur sauberen Synchro-
                     nisation mit entfernten Rechnern, z.B. die Einstel-
                     lungen der amerikanischen Ost-Küste:

                      EST (Eastern Standard Time = Winterzeit) oder
                      EDT (Eastern DayTime = Sommerzeit).

     %TASKMGRWinDir% Undokumentiert, nur vom Novell DOS 7 TASKMGR als
                     Multitasker verwendet, um SYSTEM.INI zu finden;
                     siehe Kapitel VII.2.

     %WinDir%        Von Novells UPDATEW.BAT verwendet (C:\WINDOWS)
                     (siehe automatisches PNW-Update für MS Windows,
                     Kapitel I.2.)

     %PNWDir%        Von Novells UPDATED.BAT verwendet (C:\NWCLIENT)
                     (siehe automatisches PNW-Update für DOS, Kapitel I.2.)

     %DirCMD%        MS-DOS 5.0+ (Default-Kommandos für DIR)
                     bei Novell DOS 7 nur von STACKERs DIR.COM/SDIR.COM,
                     nicht für das 'normale' DIR verwendet, dafür kann man
                     aber ersatzweise die Novell DOS/DR DOS DIR-Optionen
                     /C bzw. /R verwenden, siehe Kapitel II.11.

     %CopyCMD%       MS-DOS (Default-Kommandos für COPY und XCOPY), nicht
                     bei DR DOS/Novell DOS.
                     Die Nachbildung mittels Batchjobs scheidet leider
                     von vornherein aus (nur XCOPY ist ein externes
                     Kommando), und auch mit DOSKEY-Makros dürfte ein
                     Nachbildung schwer fallen, da dort keine aktuellen
                     Variablenwerte verwendet werden können. Außerdem kann
                     das Parameterformat der Kommandos bei MS-DOS 6.2
                     leicht abweichen (/[-|+]opt), so daß keine 100%ige
                     Nachbildung möglich ist.

     %PathTmp%       GEM 3.x, für temp. Speicherung des Original-Pfades

     %Suspend%       GEM 3.x, in Verbindung mit Multiuser-Varianten von
                     DR DOS Betriebssystemen, gültige Werte: "ON".


   - Neue Systeminformationskonstanten bei Novell DOS 7 COMMAND.COM:

     Die folgenden Pseudovariablen - die schon immer während Login-Skripten
     zur Verfügung standen (zumindest mit den englischen Werten) - lassen
     sich unter Novells COMMAND.COM nun in Batchjobs genauso wie Umgebungs-
     variablen ansprechen. Allerdings sind sie nicht im Umgebungsspeicher-
     bereich repräsentiert, d.h. die üblicherweise in Programmen verwendeten
     Compiler-Bibliotheksroutinen zum Auslesen der Umgebung (wie GetEnv()
     bei Borland Pascal) funktionieren hier nicht!
     Wenn keine gleichnamige Umgebungsvariable die Systeminformations-
     konstante überdeckt, dann liefern solche Routinen eine leere Zeichen-
     kette zurück. In Batchjobs lassen sich diese Pseudovariablen jedoch
     genauso wie Umgebungsvariablen abfragen.
     Novells Bezeichnung 'Konstante' ist auch mißverständlich, denn es
     handelt sich vielmehr um Funktionen, als um Variablen oder Konstanten.
     Die jeweiligen Werte werden innerhalb von COMMAND.COM in dem Moment
     bestimmt, wann sie gebraucht werden. Da die Übersicht im DOSBOOK
     recht fehlerbehaftet ist, folgt hier ein eigener Abschnitt:

     %Second%        "00".."59"
     %Minute%        "00".."59"
     %Hour%          "1".."12"
     %Hour24%        "00".."23"

     %Am_Pm%         "am" | "pm"
                     in allen landessprachlichen Versionen (D, U, S, F, I)
                     gleich; im DOSBOOK wird fälschlicherweise für die
                     deutsche Version angegeben: "vorm." | "nachm.".

     %Greeting_Time% Je nach landessprachlicher COMMAND.COM Version:
                     D: "Morgen", "Tag", "Abend"
                     U: "morning", "afternoon", "evening"
                     S: "mańana", "tarde", "noche"
                     F: "Bonjour", "Bonjour", "Bonsoir"
                     I: "giorno", "pomeriggio", "sera"
                     Diese Funktion ist - aufgrund der jeweils nur drei
                     möglichen Werte - auch gut dazu geeignet, um in
                     internationalen Batchjobs landessprachliche Unter-
                     scheidungen zu treffen, siehe auch Kapitel II.17.

     %Month%         "01".."12"

     %Month_Name%    Je nach landessprachlicher COMMAND.COM Version:
                     D: "Januar", "Februar", "März", "April", "Mai", "Juni",
                        "Juli", "August", "September", "Oktober", "Dezember"
                     U: "January", "February", "March", "April", "May",
                        "June", "July", "August", "September", "October",
                        "December"
                     S: "enero", "febrero", "marzo", "abril", "mayo",
                        "junio", "julio", "agosto", "septiembre", "octubre",
                        "noviembre", "diciembre"
                     F: "janvier", "février", "mars", "avril", "mai",
                        "juin", "juillet", "ao˙t", "septembre", "octobre",
                        "novembre", "décembre"
                     I: "Gennaio", "Febbraio", "Marzo", "Aprile", "Maggio",
                        "Giugno", "Luglio", "Agosto", "Settembre",
                        "Ottobre", "Novembre", "Dicembre"
                     Siehe auch Kapitel II.16.

     %Short_Year%    "xx", z.B. "94", "95", "96", ...

     %Year%          "xxxx", z.B. "1994", "1995", "1996", ...

     %Day%           "01".."31"

     %Day_Of_Week%   Im Gegensatz zur Dokumentation im DOSBOOK werden
                     die folgenden Werte geliefert, je nach landes-
                     sprachlicher COMMAND.COM Version:
                     D: "Son", "Mon", "Die", "Mit", "Don", "Fre", "Sam"
                     U: "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
                     S: "dom", "lun", "mar", "mié", "jue", "vie", "sáb"
                     F: "Dim", "Lun", "Mar", "Mer", "Jeu", "Ven", "Sam"
                     I: "Dom", "Lun", "Mar", "Mer", "Gio", "Ven", "Sab"
                     Siehe auch Kapitel II.16.

     %NDay_Of_Week%  "1".."7" ("1"=Sonntag)

     %Os_Version%    Üblicherweise "7" bei Novell DOS 7 und Caldera OpenDOS
                     7.01 COMMAND.COM, aber vgl. auch Variable %Ver% (s.o.)
                     und %Os_Version% bei NetWare-Clients (s.u.)!!!
                     Wird eine Variable %Ver% mit einem Wert belegt,
                     so gibt %Os_Version% den Wert dieser Variable an.
                     Falls Sie nicht mit COMMAND.COM als Master-Kommando-
                     prozessor arbeiten, sondern z.B. 4DOS direkt in
                     CONFIG.SYS SHELL= eintragen, wird die Umgebungs-
                     variable %Ver% niemals belegt und wenn Sie sie nicht
                     manuell mit einem Wert belegen, bekommt %Os_Version%
                     auch keinen internen Defaultwert zugewiesen.
                     Stattdessen erscheint dann "off", wenn Sie 4DOS
                     mit COMMAND.COM überladen und dort %Os_Version%
                     abfragen...

     %ErrorLevel%    Laut Novell DOS 7 DOSBOOK, ist aber nicht implemen-
                     tiert; vermutlich war der Batch-Befehl IF ERRORLEVEL
                     gemeint (siehe Kapitel II.11.). CCI Multiuser DOS
                     bietet hingegeben eine Variable %ErrorLvl% an, die
                     immer dreistellige Werte, d.h. mit führender Null
                     liefert (vgl. der beiliegende Batchjob ERRORLVL.BAT).


   - NetWare-Systeminformationskonstanten bei Novell DOS 7 COMMAND.COM
     (nur in Verbindung mit NetWare-Client):

     %Login_Name%    Login-Name. Funktionierte schon immer mit NETX,
                     seit Update 14 nun aber auch mit PNW, wenn das
                     aktuelle Laufwerk ein PNW-gemapptes Laufwerk ist.
                     Ansonsten erscheint eine leere Zeichenkette.
                     Siehe auch bei PROMPT in Kapitel II.11.

     %P_Station%     Physikalische Stationsnummer im Format "????????????".
                     Korrespondiert i. allg. mit der ID der Netzadapter-
                     karte und sollte weltweit eindeutig sein, kann aber
                     übersteuert werden. Bemerkung siehe %Login_Name%.

     %Station%       Logische Stationsnummer, wahrscheinlich beginnend
                     mit 1 für den ersten Client-Rechner nach dem Laden
                     von ODI+VLM. Die Nummern werden vom File-Server ver-
                     geben und bleiben bis zum Trennen der IPX-Verbindung
                     bestehen, d.h. auch zwischen üblichen Ein-/Auslogg-
                     Vorgängen. Bemerkung siehe %Login_Name%.

     %Full_Name%     Undokumentiert (mit Update 14 nachträglich dokumen-
                     tiert). Enthält - falls vergeben - den vollständigen
                     Benutzernamen des eingeloggten Benutzers.
                     Bemerkung wie bei %Login_Name%, allerdings funk-
                     tioniert %Full_Name% auch nach Update 14 nur mit
                     NETX (vielleicht auch mit NETX.VLM).

     %Os_Version%    Diese Variable wurde - gegenüber den anderen - schon
                     vor Novell DOS 7 COMMAND.COM von NETX und innerhalb
                     von Login-Skripten (%OS_VERSION) unterstützt, und
                     konnte dabei z.B. für MS-DOS 5.0 und 6.00 die Werte
                     "5.00", "6.00" annehmen (zwei Nachkommastellen,
                     angeblich sogar mit einem 'V' davor, dies aber
                     definitiv nicht mit Novell DOS!!!). Siehe auch
                     %Os_Version% bei den Novell DOS 7 Systeminformations-
                     konstanten und bei %Ver% (s.o.).


   Resümee: Wollen Sie die NetWare-bezogenen Systeminformationskonstanten
   nutzen, müssen Sie (zumindest temporär) Novell DOS 7 COMMAND.COM laden
   (4DOS würde nur auf den Inhalt echter Umgebungsvariablen reagieren)
   *und* (ebenfalls temporär) auf ein Netzlaufwerk überwechseln.
   Wieso eigentlich?
   Nun, da es möglich ist, auf mehreren Servern gleichzeitig eingeloggt zu
   sein, muß es irgendein Indiz dafür geben, welcher Server gerade gemeint
   ist, daher muß - zumindest bei %Login_Name%, %Full_Name% und %Station% -
   eine aktuelle 'Zuordnung' zu diesen Server bestehen. Genau zu diesem
   Zweck wurden Laufwerksbuchstaben von Netzlaufwerken gewählt.


   CCI Multiuser DOS Varianten bieten eine große Anzahl ähnlicher
   reservierter Variablen und führen noch eine weitere Variante von
   Variablen ein, die von bestimmten Kommandos gesetzt werden (können),
   dann aber statisch als ganz normale Umgebungsvariablen fungieren, bis
   sie erneut aktualisiert oder manuell modifiziert oder gelöscht werden.
   Die diesbezüglichen Möglichkeiten sind zu umfangreich, um sie hier
   alle aufzulisten. Zur Information sollen hier lediglich die aller-
   wichtigsten Variablennamen erwähnt werden, teilweise anhand eines
   Beispiels illustriert:

   Alle Treiber:

    %Verbose%=None|All|SignOn
    %<drivername>Verbose%=None|All|SignOn|NoDetail|[No_Detail]|[AllPaged]
    %IAmDebugging%=True|False

   Andere Variablen:

    %MDOS_Exec%=Off|On
    %BootDrv%=c:
    %TempDrv%=c:
    %Security%=c:\mdos\security
    %Spool%=c:\mdos\spool
    %User%=001
    %ErrorLvl%=000
    %CCINet%=3.0
    %DRNet%=x.x
    %Node%=00
    %MDOS<00>% - %MDOS<18>%

   Von DATE bzw. TIME jeweils mit Option /E gesetzt:

    %Date%=xx/yy/zz
    %DOW%=SUN|MON|TUE|WED|THU|FRI|SAT
    %DOM%=01..31
    %DOY%=001..366
    %Time%=hh:mm:ss
    %Elapsed%

                                                                             
  ---------------------------------------------------------------------------

  IV.8. Novell DOS aus Batchjobs heraus erkennen: [96-11-12]
  ==========================================================

   Stichworte: COMMAND.COM; 4DOS/NDOS; primärer, sekundärer Kommando-
               prozessor; Master-Kommandoprozessor, SHELL=

   Im folgenden werden einige Methoden beschrieben, wie man innerhalb von
   Batchjobs zwischen primären und sekundären Kopien eines Kommando-
   prozessors, zwischen Novells COMMAND.COM und 4DOS/NDOS unterscheidet
   und wie man unabhängig davon feststellen kann, ob 4DOS unter einem
   Novell DOS 7 Kernel läuft oder nicht. Die Beispiele sind in der ange-
   gebenen Form nur unter bestimmten Randbedingungen wasserdicht und
   sollten als Leitfäden, nicht als fertige Beispiele für eigene Implemen-
   tierungen für die jeweils speziell benötigten Voraussetzungen dienen.


   i. Novell DOS COMMAND.COM als Master-Kommandoprozessor:
   -------------------------------------------------------

    Wird der Kommandoprozessor COMMAND.COM direkt nach der Bearbeitung
    der CONFIG.SYS Datei geladen (vgl. Direktive SHELL=), d.h. als
    Master-Kommandoprozessor, so ist die Erkennung sehr einfach, denn
    in diesem Fall definiert COMMAND.COM die zwei Umgebungsvariablen
    %Os% und %Ver%, die sich in Batchjobs leicht abfragen lassen.

    Solange man diese Variablen nicht explizit löscht, bleiben sie
    auch dann bestehen, wenn man temporär einen weiteren Kommandoprozessor
    lädt, egal, ob es sich hierbei um eine weitere Kopie von COMMAND.COM,
    oder um eine Alternative wie 4DOS.COM/NDOS.COM handelt, denn beim Start
    eines neuen Kommandoprozessors wird die Umgebung des darunterliegenden
    Kommandoprozessors normalerweise übernommen. Dies gilt auch für den
    Kommandoprozessor von FreeDOS, nicht aber für COMMAND.COM von PTS/DOS
    alias S/DOS.

    Die richtigen Werte in %Os% und %Ver% weisen also auf einen DR DOS oder
    Novell DOS Kernel und einen primären COMMAND.COM Kommandoprozessor hin,
    allerdings darf man sich nicht 100%ig auf das Vorhandensein spezieller
    Funktionen des Kommandoprozessors verlassen, da dieser ja auch mit einem
    anderen Prozessor überladen worden sein kann (4DOS bietet zwar i. allg.
    mehr, im Detail aber doch andere Funktionen als Novells COMMAND.COM).
    Außerdem wäre es immerhin möglich, die Variablen %Os% und %Ver% auch
    'per Hand' zu definieren... Bezüglich der möglichen Werte von %Os% und
    %Ver% sei auf Kapitel IV.7. verwiesen.

     Beispiel:

     IF "NWDOS"=="%Os%" IF "7"=="%Ver%" GOTO nwdos
     GOTO skip
     :nwdos
     ECHO Running a Novell DOS 7 COMMAND.COM as master command processor
     ECHO on top of a Novell DOS 7 system kernel!!!
     REM (If variables weren't set manually... The currently active command
     REM processor must not necessarily be the master command processor...)
     IF NOT "4"=="%@Eval[2 + 2]%" ECHO Running Novell DOS 7 COMMAND.COM!!!
     REM (Still, must not necessarily be a master command processor...)
     :skip

   ii. Novell DOS Kernel unter 4DOS 5.0+:
   --------------------------------------

    Wird als Master-Kommandoprozessor 4DOS oder NDOS (oder andere Alter-
    nativen) geladen, werden die beiden Variablen %Os% und %Ver% nicht
    automatisch belegt. Das Vorhandensein von 4DOS/NDOS kann man leicht
    mit der Abfrage

     IF "4"=="%@Eval[2 + 2]%" ECHO Running 4DOS/NDOS now!!!

    checken, und im weiteren Verlauf auch ganz speziell auf deren Versions-
    nummern etc. abtesten. Unter welchem Betriebssystem 4DOS/NDOS aber
    läuft, ist auf diese Weise nicht herauszufinden. Manchmal reicht es
    jedoch nicht aus, den Kommandoprozessor zu identifizieren, sondern
    man muß überprüfen, auf welchem Kernel der Kommandoprozessor läuft.

    Ab 4DOS 5.0+ kann man hierzu den Befehl VER zweckentfremden, indem man
    die umgeleitete Ausgabe dieses Befehls auswertet:

     IF NOT "4"=="%@Eval[2 + 2]%" GOTO skip
     REM Only 4DOS/NDOS come here...
     IF ""=="%tmp%" SET tmp=%Temp%> \dev\nul
     IF NOT ""=="%tmp%" IF NOT EXIST %tmp%\nul MD %tmp% > \dev\nul
     IF "NWDOS"=="%Os%" GOTO nwdos
     IF NOT ""=="%Os%" GOTO skip
     IF EXIST %tmp%\tmp.sem ECHO Warning: "%tmp%\tmp.sem" is locked by ...
                                    ... another task. Waiting for release...
     BREAK on > \dev\nul
     :wait1
     IF EXIST %tmp%\tmp.sem GOTO wait1
     BREAK off > \dev\nul
     REM 4DOS 5.0+ reports "Novell DOS 7" here, but older 4DOS/NDOS releases
     REM report Novell DOS 7 as "DR DOS" or just as "DOS 6.0"...
     VER | @ CALL FIND "Novell DOS 7" > %tmp%\tmp.sem
     IF "0"=="%@FileSize[%tmp%\tmp.sem,b]%" GOTO skip2
     :nwdos
     ECHO Running 4DOS 5.0+ on top of a Novell DOS 7 system kernel, now!!!
     REM (Must not necessarily be a master command processor...)
     :skip2
     IF EXIST %tmp%\tmp.sem DEL %tmp%\tmp.sem > \dev\nul
     :skip


   iii. Sekundäres 4DOS unter Novells COMMAND.COM:
   ------------------------------------------------

    Geht man davon aus, daß der Master-Kommandoprozessor COMMAND.COM
    die Variablen %Os% und %Ver% belegt hat, reicht für eine Abfrage
    dieser Konstellation:

     IF "NWDOS"=="%Os%" IF "7"=="%Ver%" IF "4"=="%@Eval[2 + 2]%" ECHO ...
      ... 4DOS/NDOS running as secondary command processor on top of ...
      ... Novell DOS 7 COMMAND.COM, now!!!


                                                                             
  ###########################################################################
  ###########################################################################

  V. SPEICHER-MANAGEMENT:
  =======================

  ---------------------------------------------------------------------------

  V.1. Bessere Speicherausnutzung durch Option /USE bei HIMEM/EMM386:
  ======================================================[96-07-12]===

   Stichworte: DPMS, EMM386, HIMEM, DPMI, Region-Support, Ein-MegaByte-XTs,
               /CHIPSET, /USE, Optimierung, Shadow-RAM, EMS-Seitenrahmen,
               Stealth, Speicher-Doppelnutzung

   Die Speichermanager von Novell DOS sind sehr leistungsfähig, insbesondere
   in Verbindung mit DPMS (DOS Protected Mode Services).

   Gegenüber den Speichermanagern von MS-DOS und Kompatiblen fehlte bis vor
   Update 14 lediglich der sog. Region-Support für UMBs und die 386er-
   Emulation von EMS-Backfilling. Das erstere wird aber ab Update 14 (sicher
   aber Update 15) auch unter stützt!
   Die entsprechenden DEVICEHIGH= und LH etc. Optionen (/L: und /S),
   die von MS-DOS bekannt sind, wurden aber auch vorher nicht als Fehler
   abgewiesen, sondern lediglich ignoriert (siehe Kapitel III.4., Kapitel
   V.5. und Kapitel V.7.). Auch ohne Region-Support kam Novell DOS bezüglich
   des verfügbaren Speichers schon bei Standard-Konfigurationen auf sehr
   ähnliche bis bessere Werte. Mit dem nun verfügbaren Region-Support
   hat man hier jedoch erheblich mehr Flexibilität, wodurch die Speicher-
   situation auch in Problemfällen noch weiter verbessert werden kann.

   Bereits bei üblicher Ausnutzung der Möglichkeiten des Speichermanagers
   ergibt sich i. allg. eine erheblich bessere Speicherbilanz als bei
   MS-DOS. Über den EMM386-Schalter /DPMI=on ist es sogar möglich, diesen
   'DOS-Extender' direkt allen DPMI-nutzenden Programmen unter DOS zur
   Verfügung zu stellen (MS-DOS kann DPMI nur innerhalb von MS Windows
   bereitstellen).
   Dadurch entfällt die Notwendigkeit, daß speicherhungrige Applikationen
   ihren eigenen DPMI-Support mitbringen müssen. Allerdings kann man auch
   etwas Extended Memory einsparen, wenn man /DPMI=off angibt, wenn man
   den Support auf DOS-Betriebssystemebene nicht benötigt.
   (Lediglich etwas Vergleichbares zur Stealth-Funktion von QEMM fehlt
   (nicht nur) Novell DOS). Die Funktionalität von HIMEM ist weitestgehend
   auch in EMM386 enthalten, daher muß dieser Treiber auf 386ern (und höher)
   nicht mehr geladen werden. In Sonderfällen ist dies aber dennoch möglich,
   sogar die Kombination von MS-DOS HIMEM mit Novell DOS 7 EMM386 und
   umgekehrt ist machbar (wobei allerdings einige schöne Eigenschaften
   von Novell DOS auf der Strecke bleiben).

   Einen automatischen Optimizer bietet Novell DOS nicht und insofern bleibt
   manches Potential darüber hinaus ungenutzt.
   Bei Beachtung verschiedener Randbedingungen kann man jedoch auch unter
   Novell DOS 7 mit MS-DOS MEMMAKER als Analysehilfsmittel für Region-
   Support arbeiten, dabei muß man aber für die Dauer der Analyse in
   CONFIG.SYS und AUTOEXEC.BAT auf alle Novell DOS spezifischen Direktiven
   und Batch-Kommandos verzichten (besonders die Boot-Menüs) und muß zeit-
   weise auch mit den Speichermanagern HIMEM+EMM386 von MS-DOS arbeiten,
   weil deren Aufrufoptionen unterschiedlich sind. Wenigstens stehen nach
   einer solchen Optimierung MEMMAKERs Analysedateien zur Verfügung und
   können praktische Anhaltspunkte für eine optimale Konfiguration unter
   Novell DOS 7 liefern. Da Novell DOS' EMM386 jedoch eine ganze Reihe
   Möglichkeiten mehr bietet, die bei einer MEMMAKER Optimierung natürlich
   nicht berücksichtigt werden, ist mit manueller Nachbearbeitung meistens
   noch wesentlich mehr herauszuholen.

   Deshalb die folgenden Hinweise:


   i. HIMEM.SYS:
   -------------

     Anders als noch bei DR DOS 6.0 und entgegen der Intention der Anleitung
     arbeitet HIMEM von Novell DOS auch auf PC/XTs (8088/8086), die über
     1 MByte Speicher verfügen (zumindest auf einem V20-System getestet)!!!
     Dies ist bei vielen späten Rechnern dieser Generation der Fall, die in
     Speicherbänken 2 und 3 statt mit den eigentlich nur notwendigen 64er-
     Chips mit 256er-Chips ausgestattet sind. Evtl. muß der Adreßdekoder auf
     dem Mainboard (PAL oder 'TTL-Grab') leicht modifiziert werden, um dies
     zu ermöglichen. Eine andere Möglichkeit besteht darin, über spezielle
     UMB-Karten (wie die Uni-RAM-Karte nach c't) permanentes oberes RAM zur
     Verfügung zu stellen. Auf diesen Rechnern können die UMBs ohne Zusatz-
     programme verfügbar gemacht werden, indem man die entsprechenden hohen
     Speicherbereiche mit

      DEVICE=c:\nwdos\HIMEM.SYS /CHIPSET=ram /USE=xxxx-xxxx
      DOS=UMB

     deklariert. So läßt sich noch mancher alte und wackere PC/XT trotz
     vieler geladener TSR-Programme (STACKER etc.) mit größeren DOS-
     Anwendungen fahren!

     Viele frühe ATs mit 286er besitzen mindestens ein MByte Speicher,
     können im ersten MegaByte Speicher aber nur bis max. zur 640 KByte-
     Grenze abbilden, die restlichen 384 KByte sind nur als Extended Memory
     verfügbar und werden daher meist nur für eine VDISK-RAM-Disk verwendet
     (d.h. die Rechner-Hardware erlaubt nicht das Einblenden des Speichers
     zwischen den Adaptern, also im oberen Speicherbereich).
     Selbst die Angabe von /CHIPSET=RAM erschließt auf solchen Rechnern
     nicht die HMA, die eigentlich dennoch für DOS genutzt werden
     könnte. HIMEM bricht mit einer Fehlermeldung ab, und der optionale
     DPMS-Server kann wegen des fehlenden XMS-Servers (durch HIMEM
     bereitgestellt) ebenfalls nicht geladen werden.

     Trotzdem ist es möglich, die 384 KByte Extended Memory für DOS sinnvoll
     zu nutzen (evtl. kann man auch /CHIPSET=none versuchen):

      DEVICE=c:\nwdos\HIMEM.SYS /CHIPSET=ram /USE=FF00-FFFF
      DEVICE=c:\nwdos\DPMS.EXE
      DOS=HIGH

     Diese Angaben (außerhalb der Bereichsgrenzen von USE!!!) in CONFIG.SYS
     erschließen die HMA (64 KByte) für DOS, außerdem kann danach DPMS ge-
     laden werden und verschiedene Systemprogramme (NWCACHE, STACKER,
     DELWATCH, NWCDEX, etc.) können so das restliche Extended Memory für
     DOS nutzen. So sind trotz nicht vorhandener UMBs recht stattliche
     Speicherkonfigurationen möglich!!!

     Achtung: Die DPMS-Version 1.42 (aus Update 14) bereitete mir auf
     zwei verschiedenen 286er-Rechnern (ohne UMBs, aber mit Extended
     Memory) in dieser Kombination Probleme, die zum Hängen des Rechners
     während der Installation des DPMS-Treibers führten. Es ist möglich,
     daß dies auf Ihrem System nicht auftritt, allerdings mußte ich auf
     die Version DPMS 1.41 (aus Update 13) zurückgreifen oder die neue
     Version 1.43 (aus Update 15) verwenden, die hier problemlos arbeitete.

     Sofern das Chipset des Mainboards von HIMEM unterstützt wird, sind
     auch exotische Probleme lösbar, wie etwa auf Rechnern mit 512 KByte
     Basisspeicher 128 KByte umzumappen, um den Speicher bis 640 KByte auf-
     zufüllen. Auch die Nutzung des Video-Speicherbereichs ist möglich
     (aber offenbar nicht für /CHIPSET=RAM in Verbindung mit EGA/VGA).


   ii. EMM386.EXE:
   ---------------

     Auf 386ern wird i. allg. statt HIMEM der Speichermanager EMM386
     verwendet, der durch Speichervirtualisierung (V86-Modus) erheblich
     bessere Möglichkeiten ermöglicht (HIMEM ist im Gegensatz zu MS-DOS
     hier i. allg. nicht notwendig und eher hinderlich; seine Funktionalität
     wird bei Novell DOS von EMM386 bereitgestellt).

     Der Standardaufruf dürfte auf den meisten Systemen wie folgt aussehen:

      DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=xxxx
      DEVICE=c:\nwdos\DPMS.EXE
      DOS=HIGH,UMB

     Die Kombination /MULTI=on /DPMI=on, die sowohl den Multitasking-
     Support, als auch einen DPMI-Server einrichtet, der auch von DOS-
     Programmen ohne eigenen Extender genutzt werden kann, ohne dafür
     unter MS Windows laufen zu müssen, hat mir i. allg. noch keine
     Probleme bereitet.
     Mit frühen Versionen von Novell DOS soll es jedoch zu Problemen mit
     4G-Applikationen gekommen sein: Hinweise bei den Updates beachten.
     Lediglich SemWares TSE 2.0 produziert auch mit Update 15 noch
     Schutzfehler, wenn er unter einem multitaskenden TASKMGR gestartet
     wird und in riesigen Dokumenten schnell geblättert wird. Hier reicht
     es aber, TSE über einen Batchjob aufzurufen, der direkt vor dem Aufruf
     "DPMI off" und direkt danach wieder "DPMI on" ausführt (wirkt für
     jedem Task lokal). Unter anderen Randbedingungen bereitet auch TSE bei
     mir keine Probleme mit /MULTI=on /DPMI=on. Sollten wider Erwarten
     dennoch Probleme auftreten, brauchen Sie deshalb noch lange nicht
     auf Novell DOS verzichten. Richten Sie einfach im Boot-Menü eine
     Konfiguration mit /MULTI=off /DPMI=off ein.
     Damit schrauben Sie die Extrafähigkeiten des Speichermanagers zwar fast
     auf das Niveau von MS-DOS 6.22 EMM386 zurück, aber es können auch keine
     Probleme mehr mit DPMI auftreten. Sollte es sich um eine 4G-Applikation
     handeln, können Sie auch den mit einem Update hinzugefügten Parameter
     /PIC=ON|OFF ausprobieren. Eine andere Lösung ist es, die Applikation
     aus der DOS-Box von MS Windows 3.1x (im Erweiterten 386er Modus) aufzu-
     rufen. MS Windows überdeckt Novells DPMI-Server durch eigenen Support,
     und der gilt schließlich für die meisten DPMI-nutzenden Programme als
     Referenz...

     Es gibt jedoch einige Möglichkeiten, den verfügbaren Speicher zu
     erhöhen:


     a) BIOS-Shadowing:

     Diese Option dient der Erhöhung der Zugriffsgeschwindigkeit auf die
     ROMs (i. allg. 8 oder 16 Bit breit und mit vielen Waitstates versehen),
     indem diese ins 16- oder 32-bittige RAM umkopiert, dort schreib-
     geschützt und an die ursprüngliche Adresse (über die BIOSe) gemappt
     werden. Das Shadowing kostet keinen Adreßraum, benötigt aber genau so
     viel RAM-Speicher (der für anderweitige Nutzung wegfällt), wie Segmente
     als Schattenspeicher eingerichtet werden.

     Das Shadowing ist theoretisch ab XTs mit 1 MByte möglich, praktisch
     alle ATs (ab 286er) bieten Shadow-Möglichkeiten ab Chipset unter
     Kontrolle des BIOS-Setup-Programms an. Ab 386er-Prozessor ist mit
     entsprechendem Speichermanager (EMM386) im V86-Modus auch das virtuelle
     Shadowing möglich. Die etwas geringere Ausführungsgeschwindigkeit der
     Programme im V86-Modus gegenüber dem Real Mode (durch den Overhead
     des ständigen Moduswechsels zwischen Protected Mode und V86-Modus)
     ist meistens kein Problem, da man i. allg. erst durch die Features
     des Speichermanagers die Freiheit bekommt, entsprechend viele Pro-
     gramme zur Systemoptimierung zu laden, die dann diesen Geschwindig-
     keitsnachteil bei Weitem wieder aufwiegen. Sollten Sie jedoch ein
     Chipset haben, daß sehr flexible Einstellungen für BIOS-Shadowing und
     EMS-Hardware-Emulation ermöglicht und sollten Sie weder VCPI, DPMI
     noch die Multitasking-Möglichkeiten des TASKMGR benötigen, mag es
     dennoch im Einzelfall sinnvoller sein, EMM386 nicht zu laden (und
     evtl. auf HIMEM.SYS auszuweichen).

     Es ist wichtig, zwischen zwei 'Ressourcen' zu unterscheiden:

      Verfügbarer RAM-Speicher
      Verfügbarer Adreßraum im ersten MegaByte

     Da die meisten heutigen Rechner über mehrere MegaByte RAM-Speicher
     verfügen, DOS aber prinzipiell nur im ersten MegaByte laufen kann
     (mal von speziellen Strategien wie DPMS (oder DOS-Extendern über DPMI)
     abgesehen), ist der Adreßraum für DOS-Systeme eigentlich die kostbarere
     Ressource. Die Größe des UMB-Speichers, den ein Speichermanager
     für Gerätetreiber, TSRs und den DOS-Kernel verfügbar machen kann, ist
     entscheidend dafür, wie viel Basisspeicher (unterhalb 640 KByte) letzt-
     endlich zur Verfügung steht. U.U. ist es sinnvoller, einige hundert
     KiloByte Extended Memory für einen Speichermanager wie EMM386 zu
     opfern, um mit dessem virtuellen Speicherabbild einige zehn KiloByte
     UMB-Speicher nutzbar zu machen. Dies gilt besonders für das virtuelle
     Shadowing und für die EMS-Emulation, die im folgenden besprochen
     werden:

     Tip:

     Sämtliches Shadow-RAM im BIOS-Setup abschalten, wenn EMM386 in den
     V86-Modus schalten darf (d.h. wenn sich keine Anwendungen an dieser
     Betriebsart stören). Diesen Speicher kann man im BIOS-Setup dem
     Extended Memory zuschlagen (Memory-Relocation enabled). Außerdem
     sollten auch alle anderen Shadow-Programme (wie FASTBIOS.SYS von
     manchen SuperVGA-Karten) entfernt werden.
     Auch wenn dies auf den ersten Blick nicht sinnvoll erscheint (und von
     früheren Rechnergenerationen und älteren, weniger leistungsfähigeren
     Versionen der Speichermanagern her anders gewohnt):
     Das virtuelle Shadowing der BIOS-ROMs, das der Speichermanager EMM386
     von Novell DOS im V86-Modus ermöglicht, kann erheblich besser dosiert
     werden, als es die Rechner-Hardware üblicherweise erlaubt. Daher ist
     diese Software-Möglichkeit der Hardware-Option vorzuziehen, wenn es um
     optimale Speicherausnutzung geht.

     Über Anweisungen der Form

      DEVICE=c:\nwdos\EMM386.EXE /RAM=xxxx-xxxx

     ist es möglich, einzelne BIOSe ganz gezielt als Schattenspeicher zu
     konfigurieren, allerdings kann man hier (im Gegensatz zum Hardware-
     Shadow des Rechners) die notwendigen Bereiche sehr genau angeben
     (die Rechner-Hardware bietet meist nur Segmente mit 32 - 128 KByte
     zur Auswahl).
     Außerdem kann man Bereiche aussparen, die nur während der
     Initialisierung des BIOS benötigt werden, d.h. nur
     einmal durchlaufen werden (also nur den zur Laufzeit wirklich aktiven
     Code als Schattenspeicher aktivieren).

     Ein 32 KByte Video-BIOS ist meist nur mit 20 - 30 KByte Code gefüllt,
     davon werden weitere 5 KByte nur während der Init benötigt, ein
     Shadowing der kompletten 32 KByte (oder mehr, wie allgemein üblich)
     wäre also Speicher- und Adreßraumverschwendung, besonders wenn EMM386
     sowieso verwendet wird.

     Ein 64 KByte Main-BIOS besteht meist aus 32 KByte Setup- und Diagnose-
     Programmen (die wohl nur beim Booten benötigt werden und insofern nicht
     als Schattenspeicher eingerichtet werden müssen), der aktive Code
     dürfte sich meist auf ca. 25 - 30 KByte beschränken. Auch hier läßt
     sich also einiges an Speicher und besonders Adreßraum sparen (und für
     andere Dinge einsetzen), wenn man das Shadowing dem Speichermanager
     überläßt und nicht dem Mainboard.
     Nebenbei werden dadurch auch manche Probleme vermieden, wenn etwa eine
     Netzadapterkarte oder ein Spezialkontroller ein eigenes BIOS mitbringt,
     dem ein Bereich eines Dual-Ported-RAMs (memory mapped IO) folgt
     (worüber z.B. die Kommunikation mit der Karte stattfindet). Wenn der
     Rechner hardware-mäßig nur sehr große Bereiche als Schattenspeicher
     einrichten kann, muß man die Karte i. allg. so konfigurieren, daß
     zumindest ihr RAM-Fenster außerhalb des Shadow-Bereichs liegt (denn
     in als Schattenspeicher eingerichtetes ROM kann man nicht schreiben).
     Dadurch muß man den UMB-Bereich fragmentieren, was wiederum bedeutet,
     daß größere Programme nur sehr schwer im UMB-Bereich untergebracht
     werden können und obendrein an den Übergängen brachliegende Speicher-
     bereiche entstehen.

     Problematisch dürfte es nur sein, die aktiven Bereiche der BIOS heraus-
     zufinden, hier kann nur ein erfahrener Systemprofi weiterhelfen (Dies
     hier auszuführen, würde den Umfang des Dokumentes sprengen; hilfreich
     sind jedoch QEMM und MFT.)

     Eine Steigerungmöglichkeit bietet sich an, wenn man BIOS-Bereiche, die
     nur während der Initialisierung benötigt werden, nicht nur NICHT
     als Schattenspeicher einrichtet, sondern als UMBs freigibt.
     Da der Speichermanager hier jedoch ROM-Code erkannt hat, wird er sich
     normalerweise weigern, diese Bereiche für Programme zu verwenden.

     Mit der Option

      EMM386 /USE=xxxx-xxxx

     kann man jedoch auch kleinere Speicherblöcke gezielt über ungenutzte
     BIOS-Adressen mappen (da dies im virtuellen Modus geschieht, muß man
     auch nicht mit Hardware-Problemen durch aufeinander arbeitende Bus-
     treiber rechnen) und so zum Hochladen von Programmen nutzen.

     Auch hier ergibt sich lediglich das Problem, die Bereiche herauszu-
     finden, die effektiv nicht benutzt werden (d.h. nur während der Init
     oder während des Setups). Im Zweifel hilft Probieren und paragraphen-
     weises (16 Bytes) Herantasten an die Grenzen (allerdings kann EMM386
     Bereiche aufgrund der Hardware-Eigenschaften von 386ern immer nur á
     4 KByte verwalten, so daß z.B. EXCLUDE=x000-x001 den Bereich x000-x100
     ausschließt. Trotzdem ist es anscheinend möglich, durch sich über-
     lappende Angaben auch kleinere Bereiche für Programme zu verwenden.
     MEM liefert hier nicht ganz eindeutige Aussagen. Siehe Kapitel V.2.).
     Dabei sollte man bedenken, daß die Initialisierungsroutinen der BIOSe
     meist an deren Anfang liegen, außerdem meist am Ende von Zusatz-BIOSen
     noch kleinere Bereiche frei sind (Inhalt FFh oder 00h); das Setup-
     Programm liegt i. allg. bei F000-F7FF.

     Achtung:

     Eine Doppelnutzung muß hier mit Sicherheit ausgeschlossen werden,
     andernfalls wird der Rechner früher oder später (meist das erstere)
     abstürzen. EMM386 hat keine Möglichkeit, die Zulässigkeit eines
     Zugriffs auf einen mit /USE freigeschalteten Speicherbereich zu
     überprüfen. /USE mappt virtuell Speicher über die angegebenen
     Bereiche; evtl. darunterliegender BIOS-Code etc. wird (zumindest
     aus der Sicht von DOS) dauerhaft verdeckt.

     Außerdem sollte man beachten, daß logischerweise entsprechend der mit
     /USE deklarierten Speichergröße an anderer Stelle (im Extended Memory)
     Speicher fehlt. Sollte die Rechner-Hardware also selbständig RAM an
     Stellen einblenden, für die auch /USE angegeben wurde, sollte man
     entweder diesen Speicher über hardware-mäßige Memory-Relocation dem
     Extended Memory zuschlagen oder diese Bereiche von /USE ausschließen.
     Nur so kann man verhindern, daß sozusagen zwei Ebenen von Speicher
     übereinander liegen und der 'unten' liegende Speicher verständlicher-
     weise von jeglicher Nutzung ausgeschlossen ist.
     Da man aber durchaus 30 - 50 KByte (!!!) wertvollen UMB-Platz gewinnen
     kann, lohnt sich das etwas aufwendige Tuning.


     b) EMS-Emulation:

     Der Speichermanager EMM386 kann auch EMS-Speicher simulieren. Da der
     Speicher (EMS, XMS) aus einem gemeinsamen Pool bedient wird und man
     sich nicht auf eine exakte Verteilung festlegen muß, bietet es sich
     an, *immer* einen EMS-Seitenrahmen anzulegen, damit auch Programme,
     die EMS-Speicher benötigen, ohne Sonderkonfiguration laufen können
     (es sei denn, keines Ihrer Programme wäre auf EMS angewiesen).
     Das einzige Argument, das noch gegen die Einrichtung eines Seiten-
     rahmens bleibt, ist, daß durch den Seitenrahmen 64 KByte Adreßraum
     (meist) im oberen Speicher 'verschwendet' werden, die man sonst als
     UMBs nutzen könnte.

     Diese Aussage läßt sich aber weitestgehend entschärfen, wenn man den
     Rahmen an eine geschickte Position legt. Wie oben angesprochen, wird
     das Setup-Programm des Main-BIOS i. allg. nur während der Init be-
     nötigt, daher könnte man den EMS-Seitenrahmen zur Hälfte über dieses
     BIOS legen, und so weitere 32 KByte Adreßraum für UMBs gewinnen (dies
     ist bei MS-DOS Speichermanagern nicht möglich). Damit der Speicher-
     manager diese Einstellung akzeptiert, ist es allerdings notwendig,
     die Option /USE zu verwenden, etwa:

      EMM386 /FRAME=E800 /USE=F000-F7FF

     Außerdem sollte man versuchen, evtl. vorhandene Adapter-ROMs (Netz-
     adapterkarten u.ä.) hinter diese Page-Frame zu legen, damit sie nicht
     mehr anderweitig Adreßraum verbrauchen. Diese Doppelnutzung bereitet
     normalerweise keine Probleme, solange nicht z.B. die Netzwerk-Software
     EMS-Speicher benötigt. Ein Treiber für die Karte wird problemlos auf
     das Adapter-ROM zugreifen können, ein Programm, das EMS verwendet,
     mappt seine EMS-Seiten virtuell über dieses ROM und läßt sie bei
     seiner Beendigung auch wieder verschwinden. Theoretisch kann diese
     Doppelnutzung zu Deadlocks führen, wenn Anwendungen von unzulässigen
     Annahmen ausgehen (etwa, daß sie ihre Speicherseiten eingeblendet
     lassen können, oder wenn EMS-nutzende TSRs den aktuellen Zustand bei
     Ein- und Auslagern nicht abspeichern), aber sauber und umsichtig
     programmierte Software sollte damit in den meisten Fällen zurecht-
     kommen. Sollten dennoch Probleme auftauchen, müssen EMS-nutzende
     Programme überprüft werden. Kritisch sind u.U. EMS nutzende Geräte-
     treiber, unkritisch sind TSRs, die sich einfach nur bis zur Aktivierung
     irgendwo hin auslagern wollen (z.B. SDRes).
     Dieses Verfahren kommt übrigens der Stealth-Funktion von QEMM schon
     sehr nahe, nur daß ein äußerer Überwachungsmechanismus fehlt.

     Mit ein bißchen Tüftelei läßt sich so das System stark optimieren
     (meist muß man ja erstmal wissen, daß solche Dinge überhaupt möglich
     sind): Eigene Erfahrungen haben gezeigt, daß dieses Verfahren in sehr
     vielen Fällen sehr gut und stabil funktioniert.


     c) Ein Beispiel:

     Ein Auszug aus einer CONFIG.SYS eines mit VGA (A000-AFFF,B800-BFFF) und
     HGC (B000-B7FF/BFFF) bestückten 386er mit Intel-Chipset und Phönix-BIOS
     (F000-FFFF) und ET4000-BIOS (C000-C7FF):

      DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=E800 /VIDEO
                                 /ROM=C100-C7FF,F800-FFFF
                                 /USE=C800-E7FF,F000-F7FF
                                 /VERBOSE
      DEVICE=c:\nwdos\DPMS.EXE

     Es werden hier nur die im laufenden Betrieb notwendigen Teilbereiche
     der BIOSe als Schattenspeicher eingerichtet (nur dort bringt es einen
     Geschwindigkeitszuwachs), der EMS-Seitenrahmen liegt zur Hälfte über
     dem Main-BIOS (genauer über dem gesamten Setup-Programm).
     (Auf einem anderen ähnlichen Rechner liegt hinter dem EMS-Seitenrahmen
     noch ein HP-IB-Streamer-ROM (E800-EBFF), und es funktioniert...)

     Gegenüber dem Standard (Shadowing durch Rechner-Chipset):

      DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=auto /VIDEO
                                 /VERBOSE
      DEVICE=c:\nwdos\DPMS.EXE

     konnten bei gleicher Performance gegenüber der Standardeinstellung
     (deren Speicherbilanz schon besser als die von MS-DOS war) etlicher
     sonst verschwendeter Speicher (ca. 64 KByte) gespart und obendrein
     mehr UMBs (ca. 32 KByte) zur Verfügung gestellt werden.
     Was will man mehr...


     d) Video-Speicher nutzen:

     Mit einer Kombination aus den Optionen /USE und /VIDEO läßt sich
     auf zwei grundverschiedene Art und Weisen noch mehr Speicher bereit-
     stellen - sowohl als Ergänzung für den konventionellen Speicher
     (bis zu 96 KByte mehr) als auch als zusätzlichen UMB-Speicher
     (ebenfalls bis zu 96 KByte mehr). Näheres hierzu in Kapitel V.6.

                                                                             
  ---------------------------------------------------------------------------

  V.2. Zusätzliche Optionen von EMM386.EXE [97-03-24]:
  ====================================================

   Stichworte: EMM386.EXE, /HANDLES, /PIC, /DMA, DTU, Optionen, Updates

   Neben den im DOSBOOK und im Handbuch erwähnten Optionen bietet der
   Speichermanager noch einige zusätzliche Aufrufparameter, die zum Teil
   wenigstens in der eingebauten Hilfe aufgelistet werden (der einleitende
   SwitChar ist optional):

    EMM386 /HELPDEVICE   Hilfe für CONFIG.SYS-Parameter
    EMM386 /?            Hilfe für Kommandozeilenparameter, akzeptiert
                         werden jedoch auch /H, /HELP bzw. /HILFE.

   Übrigens treten - ganz allgemein - auch bei den anderen Kommandos bei
   Aufruf der jeweils eingebauten /? Hilfe teilweise zusätzliche Optionen
   'zu Tage', so daß bei der Suche nach möglichen Lösungen für Probleme in
   jedem Fall angeraten sei, nicht nur das Handbuch und das DOSBOOK zu
   verwenden. Insbesondere Erweiterungen durch Updates finden nur in der
   in die Kommandos eingebauten Hilfe Niederschlag.

   Obwohl EMM386 in seinen /INCLUDE, /EXCLUDE, /USE, /VIDEO Parametern als
   Bereichsangaben Werte mit einer Genauigkeit eines Paragraphen (16 Bytes)
   akzeptiert (dies ist jeweils die letzte Stelle von xxxx-xxxx), arbeitet
   das virtuelle Mappen (aufgrund von CPU-Gegebenheiten) nur mit Bereichs-
   größen á 4 KByte. Möchten Sie z.B. einen kleinen Bereich ausschließen
   (/EXCLUDE=xxx0-xxx1), so schließt EMM386 in Wirklichkeit den Bereich
   xxx0-xxFF aus. Wenn solche Bereiche nicht genau auf einer 4 KByte-Grenze
   liegen, so kann es vorkommen, daß der auszuschließende Bereich sich nicht
   ganz mit dem ausgeschlossenden Bereich deckt (zumindest wenn man MEM /A
   trauen kann). Hier ist also bei Optimierungen auf's letzte Byte Vorsicht
   geboten (siehe auch Kapitel V.1.).

   Die zusätzlichen Optionen sind:
    (nur in der eingebauten Hilfe dokumentiert)

    EMM386 /HANDLES=1..255    Anzahl EMS- (und XMS-) Handles
    EMM386 /PIC=ON|OFF        Virtualisierung der PICs (der beiden Inter-
                              rupt-Controller 8059) zur Lösung von Problemen
                              mit DOS-4G-Extender-Programmen (ab EMM386
                              3.05+), wie von vielen Spielen verwendet.
                              Mehr dazu wird in der Update HISTORY.TXT und
                              in der /HELPDEVICE Hilfe ausgegeben. Wenn
                              Sie den Parameterwert nicht angeben, wird OFF
                              angenommen. (Evtl. funktioniert auch PIC=Y???)
    EMM386 /DMA=0..65535      DMA-Puffer
    EMM386 /QUIET             Unterdrückt Meldungen (funktioniert aber bei
                              mir nicht, stattdessen erscheint (bei Update
                              15) eine Fehlermeldung des internen Moduls
                              DPMI.SYS...)
    EMM386 /VERBOSE           Gibt (ausführliche) Startmeldungen, offenbar
                              der Standard
    EMM386 /NOVCPI            siehe EMM386 /HELPDEVICE
    EMM386 /NOEMS             siehe ""
    EMM386 /MULTITASKING=ON|OFF  genauso wie /MULTI=ON|OFF
                              Lädt den internen Multitasking-Kernel
                              KRNL386.SYS des Systems (war in der Beta-
                              Phase ein externer Treiber). Wird u.a. für
                              den den TASKMGR als Multitasker benötigt.
    EMM386 /ROM=xxxx          Wird bei xxxx nur die Startadresse angegeben,
                              so versucht der Speichermanager, einen an
                              dieser Adresse liegenden ROM-Header 55h AAh
                              auszuwerten und daraus die Länge des ROMs zu
                              ermitteln. Dies funktioniert aber nur dann,
                              wenn man wirklich die Startadresse des ROMs
                              angibt und nicht etwa nur die Adresse, ab der
                              Shadow-RAM eingeblendet werden soll, denn
                              dort muß nicht unbedingt gerade ein ROM-Header
                              beginnen.

   Undokumentierte Optionen:

    EMM386 /GATEA20=AT|HP|INT15|MCA|PS2|XMS
                              ist bis auf die Einstellung PS2 dokumentiert.
                              Wo der Unterschied zwischen MCA und PS2
                              liegen mag, ist unklar (denn PS/2 Rechner
                              haben üblicherweise einen MCA-Bus). Der
                              Treiber besitzt interne Sonderbehandlungen für
                              ISA, EISA, MCA, PCI, CPQ und XMS; in wieweit
                              dies mit dieser Option zusammenhängt, ist mir
                              nicht bekannt.

    EMM386 /DPMS[=ON|OFF]     Dieser undokumentierte Parameter wird nicht
                              in der Hilfe aufgelistet, obwohl intern sogar
                              eine entsprechende Hilfemeldung implementiert
                              ist, die nur nicht angesprungen wird. Er wird
                              auch nicht - wie andere ungültige Optionen -
                              zurückgewiesen, ist aber dennoch in der
                              ausgelieferten Fassung von EMM386.EXE ohne
                              Funktion, d.h. DPMS-Support kann damit nicht
                              aktiviert werden. Im DPMS-SDK gibt es aber
                              eine spezielle Fassung von EMM386.EXE, die
                              DPMS.SYS enthält. Sie ist notwendig, um DPMS-
                              nutzende Programme zu debuggen - mit dem
                              Windows-Debugger WDEB386.EXE, der in
                              Microsofts Windows SDK/DDK ausgeliefert wird.
                              EMM386.EXE besteht aus einer Vielzahl
                              interner, aber dennoch eigenständiger Treiber
                              (u.a. DPMI.SYS und THREADS.SYS), die von einer
                              LOADER genannten Routine während der Instal-
                              lation von EMM386 bei Bedarf mit eingebunden
                              werden (mit etwas Geschick kann man die
                              einzelnen Bestandteile auch wieder voneinander
                              trennen).
                              Schon in 10/1992 existierte eine Vorversion
                              von DPMS.EXE.

    EMM386 /DEBUG ???         undokumentiert, wird i. allg. (wahrscheinlich
                              nur vom ummantelnden LOADER) zurückgewiesen
                              und EMM386 lädt nicht. Trotzdem haben alle
                              internen Treiber entsprechende Parameter-
                              überprüfungen implementiert. Zwei Vermutungen:
                              Entweder es handelt sich um einen Parameter,
                              der (während der Entwicklung) das Debuggen
                              von EMM386 ermöglicht oder hiermit könnten
                              auch die recht umfangreichen Fehlermeldungen
                              von EMM386 unterdrückt werden (falls per
                              Default /DEBUG=ON wäre (dies könnte dann
                              evtl. etwas mehr XMS Speicher zur Verfügung
                              stellen).
                              Aber: Beides ist reine Spekulation...

    EMM386 /EMS ???           undokumentiert, wird zurückgewiesen. EMM386
                              lädt nicht.

    EMM386 /W[=ON|OFF]        Der Parameter /WEITEK kann wahrscheinlich
                              mit /W abgekürzt werden, im Gegensatz zum
                              Parameter /WEITEK, bei dem immer =ON oder
                              =OFF angegeben werden muß, kann man bei /W
                              den Wert weglassen.

   Weitere Parameter oder spezielle Schlüsselworte, die noch nicht genauer
   zugeordnet werden können: HIMEM, GLOBAL, LOCAL, T3100SX und T4400SX.


   Alte DR DOS Optionen, die nicht mehr unterstützt werden:

    EMM386 /BDOS=AUTO|NONE|FFFF|xxxx  Wird insofern aus Kompatibilität zu
                              DR DOS unterstützt, als daß eine Warnmeldung
                              erscheint, die die Verwendung reklamiert und
                              stattdessen die Verwendung der CONFIG.SYS
                              Direktive DOS=[HIGH,UMB] vorschreibt.
                              Die Möglichkeit, die Ladeadresse explizit
                              anzugeben, fällt damit also weg.
    EMM386 /AUTOSCAN          Wird wie /BDOS nicht mehr unterstützt, aber
                              mit einer entsprechenden Warnung quittiert.
                              Verwenden Sie stattdessen /INCLUDE (was auch
                              direkt angenommen wird).
    EMM386 /KB                Wird ebenfalls nicht mehr unterstützt und
                              erzeugt eine Warnung. Stattdessen kann man
                              (in umgekehrter Logik) mit /INT15 einen
                              Speicherbereich von der Verwendung aus-
                              schließen.
    EMM386 /LOWEMM            Wird nicht mehr unterstützt, da obsolet.
                              EMM386 lädt nicht.


   Wie viele Benutzer anderer Speichermanager an Novell DOS' EMM386 be-
   mängeln, unterbricht dieser Manager relativ häufig die Behandlung und
   meldet verschiedene Arten von Schutzfehlern. Allerdings machen sich die
   meisten Benutzer nicht klar, daß sich EMM386 nicht ohne Grund meldet.
   Irgendein Programm (und zwar NICHT EMM386) hat eine unsaubere Aktion
   ausgeführt, die, wenn sie durch den Schutz des Protected Modes nicht
   abgefangen würde, früher oder später zu einem verdeckten Fehler führen
   würde, der u.U. sehr schwerwiegende Fehlfunktionen oder Datenverluste
   nach sich ziehen könnte. Derartige Schutzvorkehrungen sind insbesondere
   beim Multitasking notwendig.
   Statt den Speichermanager zu beschuldigen, sollte man sich die Mühe
   machen, und die genauen Umstände, die zu diesem Fehler führen, analy-
   sieren und den Herstellern der Probleme bereitenden Programme einen
   Bug-Report schicken. Das Verhalten des EMM386 von Novell DOS hat sich
   bezüglich seiner Eingriffe über den Zeitraum der Updates schon stark
   verbessert (oder ist etwas oberflächlicher geworden und anderen
   Speichermanagern mehr angeglichen - wenn man es von der anderen Seite
   sieht).

   Für Programmierer ist jedoch ein strenger Speichermanager ein wahrer
   Segen, weil man verdeckte Fehler sehr schnell merkt... Der Novell DOS
   Speichermanager ist besonders praktisch noch dazu, weil er nach seiner
   ausführlichen Fehlermeldung auch noch einen INT03h-Debugger-Interrupt
   anwirft. Wenn man im Hintergrund einen Debugger laufen läßt, kann man
   u.U. direkt nach der Ursache forschen. Sehr empfehlenswert zu diesem
   Zweck ist zum Beispiel DTU 1.41+ (Downtown Utilities von Jeroen van
   Disseldorp, <jafcdiss@cs.ruu.nl>;), weil dieses TSR nur 800 Bytes vom
   DOS-Speicher abzweigt (wenn es sich ins EMS auslagern kann), und
   trotzdem Online-ASCII-Tabellen, Taschenrechner, Dateibetrachter und
   Interrupt-Viewer, Speicher-Dump, Disassembler und anderes bietet und
   sich in diesem Fall automatisch aktiviert. Dieses Tool ist FreeWare
   und arbeitet problemlos sogar unter dem Multitasker TASKMGR als auch
   in DOS-Boxen von Windows (mit Novell DOS ab Update 13 reicht Aufruf-
   option DTU /5, mit älteren Novell DOS Speichermanagern benötigt man
   DTU /7).

   Falls Sie PKZIP (2.04g) unter dem multitaskenden TASKMGR (besonders
   in Hintergrundtasks) oder in Verbindung mit exzessiver Harddisk-
   Auslastung (NWCACHE /FLUSH=ON) während des Aufrufs aus Batchjobs (und
   mit DOS-Umleitungen) einsetzen, kommt es schon man vor, daß scheinbar
   zufällig sporadische EMM386-Schutzfehler auftreten (vielleicht auch nur
   auf älteren 386sx-Rechnern???). In einem solche Fall sollten Sie zuerst
   versuchen, ob ein Druck auf <Return> nicht ohne Nachwirkungen die
   Kontrolle an die Anwendung zurückgibt (wie dies bei meinem Testrechner
   der Fall ist).

                                                                             
  ---------------------------------------------------------------------------

  V.3. Zusätzliche Optionen von HIMEM.SYS: [96-10-30]
  ===================================================

   Stichworte: HIMEM.SYS, Ein-MegaByte-XTs, EEMS, EMS-Backfilling, DR DOS

   Obwohl der Treiber HIMEM.SYS auf heutigen Maschinen (ab 386er an auf-
   wärts) unter Novell DOS 7 nur noch sehr selten benötigt wird (denn
   EMM386 enthält im Prinzip auch die Funktionen von HIMEM), ist dieser
   Treiber in Ausnahmesituationen dennoch wichtig. Besitzt Ihr Rechner
   z.B. ein bestimmtes Chipset oder spezielle Zusatzkarten, die von
   HIMEM.SYS unterstützt werden, kann es auch auf 386ern (und höher)
   sinnvoller sein, HIMEM.SYS vor EMM386 zu laden, da HIMEM.SYS dann
   z.B. die Unterstützung für in der Hardware implementiertes EMS
   (3.2 und 4.0) und EEMS bietet. Natürlich kann EMM386 (bis auf eine
   Emulation von EEMS und EMS 4.0 Backfilling) das Ganze auch im V86-Modus
   bereitstellen, aber erstens ist dies etwas langsamer, zweitens kann so
   z.B. keine EMS-Hardware unterstützt werden, und drittens gibt es manche
   Programme, die unbedingt im Real Mode oder sogar im Protected Mode
   laufen wollen. Wenn EMM386 im V86-Modus arbeiten muß, können solche
   Programme nicht ausgeführt werden. 286er-Computer kommen normalerweise
   ohne HIMEM.SYS nicht aus, wenn sie eine Speicherverwaltung benötigen
   (auf ihnen arbeitet EMM386 nicht).

   Achtung: Die HIMEM.SYS-Version 2.3x von Novell DOS 7 verträgt sich
            auf COMPAQ-Rechner nicht mit Novells Client32 für DOS und
            Windows 3.1x, wenn DOS nicht in die HMA geladen wurde. Also
            entweder DOS=HIGH,UMB in CONFIG.SYS einfügen, oder stattdessen
            auf EMM386.EXE ausweichen.

   Neben den im Handbuch und DOSBOOK beschriebenen Optionen kennt auch
   dieser Treiber noch einige Einstellungen mehr, die im folgenden
   aufgelistet werden.


    /CHIPSET=EMSALL | EMSUMB | AM286ZX | HEDAKA | NEAT | SCAT | RAM | NONE

                             Diese Option ist zwar dokumentiert, seine
                             konkrete Verwendung ist allerdings den meisten
                             Benutzern nicht besonders klar. Deshalb sollen
                             hier ein paar nicht unbedingt offensichtliche
                             Details diskutiert werden:

                             Die Option RAM funktioniert auch auf XTs mit
                             1 MByte Speicher, die so UMBs zur Verfügung
                             stellen können (siehe in Kapitel V.1.). Die
                             Option sagt aus, daß in dem angegebenen
                             Adreßbereich permanent RAM vorliegt (wie auch
                             immer es dort 'hingekommen' ist), HIMEM blendet
                             hier keinen Speicher ein. (Bei dem Versuch,
                             hier Video-Speicher einer EGA unterzuschieben,
                             mußte ich allerdings feststellen, daß HIMEM
                             entweder doch auf die Existenz von RAM über-
                             prüft oder den Video-Speicherbereich generell
                             ausschließt...???)

                             Die Möglichkeit von EMS-Backfilling (von EMS
                             4.0/EEMS) kann die Leistung von Multitaskern
                             wie DESQview auf älteren Rechnern erhöhen.
                             Allerdings muß man sich entscheiden, wer
                             diese Möglichkeiten zum Einblenden von Speicher
                             außerhalb der Page-Frame nutzen können soll.
                             EMM386 bietet zwar die Möglichkeit, EMS zu
                             emulieren; das, was man allgemein unter EMS-
                             Backfilling versteht, wird dabei aber nicht
                             nachgebildet (obwohl EMM386 auf gewissen Weise
                             nichts anderes macht, als virtuell Speicher an
                             bestimmte Adreßlagen abzubilden, aber eben
                             nicht über eine EMS-Schnittstelle). HIMEM kann
                             EMS-Hardware generell nicht nachbilden, sondern
                             nur darauf aufsetzen (bei bestimmten unter-
                             stützten Chipsätzen direkt auf der Chipsatz-
                             Hardware oder über einen vorher geladenen
                             herstellerspezifischen Treiber für eine EMS-
                             Hardware über dessen EMS-Software-Schnitt-
                             stelle). Dabei kann HIMEM von einer hardware-
                             mäßig angebotenen Möglichkeit für EMS-Back-
                             filling Gebrauch machen und so auch für
                             Novell DOS 7 ausnutzen:

                             Mit den Einstellungen EMSUMB und EMSALL kann
                             man HIMEM mitteilen, einen per zusätzlichen
                             externen Treiber bereitgestellten EMS-Support
                             zur Einblendung von UMB-Speicher zu 'miß-
                             brauchen'. EMS 4.0/EEMS Hardware kann über den
                             externen Treiber so programmiert werden, daß
                             sie bis zu 128 KByte gleichzeitig an nahezu
                             beliebiger Adreßlage einblenden kann (der hier
                             und im folgenden verwendete Wert von 128 KByte
                             wird in einer nachträglichen Dokumentation zu
                             DR DOS 6.0 HIDOS.SYS, dem Vorgänger von
                             HIMEM.SYS erwähnt, in der Novell DOS Dokumen-
                             tation ist immer von 'gesamtem Speicher' die
                             Rede, vielleicht ist also auch noch mehr
                             möglich. Rückmeldungen willkommen...).
                             Mit der Option EMSALL weist man HIMEM an,
                             diese Möglichkeit eines EMS-Treibers komplett
                             für sich in Anspruch zu nehmen. Auf diese Weise
                             kann HIMEM insgesamt 128 KByte UMB-Speicher zur
                             Verfügung stellen, allerdings sind damit die
                             Paging-Möglichkeiten der EMS-Hardware ausge-
                             schöpft und es kann kein EMS-Speicher für
                             EMS-nutzende Applikationen bereitgestellt
                             werden. Über diese 128 KByte hinausgehender
                             Speicher auf der EMS-Karte ist in dieser
                             Konfiguration zwangsläufig nicht ansprechbar.
                             Allerdings besitzen viele EMS-Karten die
                             Möglichkeit, durch DIP-Schalter auf der Karte
                             zu wählen, ob der Speicher als EMS (Expanded)
                             oder Extended Memory zur Verfügung gestellt
                             werden soll. Meistens kann man den hardware-
                             mäßig bestückten Speicher auch auf beide
                             Methoden aufteilen. In diesem Fall sollten Sie
                             also nur 128 KByte als EMS-Speicher aktivieren
                             und den restlichen Speicher als Extended Memory
                             ab der Adreßlage einblenden, ab der der
                             physikalische Speicher auf dem Mainboard des
                             Rechners aufhört. Auf diese Weise können Sie
                             auch den restlichen Speicher der Zusatzkarte
                             nutzen, wenn auch nicht als EMS-Speicher.

                             Die zweite Möglichkeit besteht in der Angabe
                             der Option EMSUMB, die normalerweise auch von
                             selbst detektiert wird. In diesem Fall benötigt
                             HIMEM ebenfalls 128 KByte freien Adreßraum
                             (üblicherweise im UMB-Bereich des Rechners),
                             allerdings teilt HIMEM die Verwendung des
                             Speichers in 64 KByte fixierten Speicher als
                             UMB und 64 KByte für eine EMS-Page-Frame ein.
                             Auf diese Weise läßt sich der restliche als
                             EMS-Speicher reservierte Speicher auf der
                             Zusatzkarte ganz normal über die Page-Frame
                             benutzen, lediglich die Möglichkeiten, Seiten
                             an beliebigen Stellen einzublenden (Backfilling
                             ist eine der optionalen Erweiterungen von EMS
                             4.0 gegenüber 3.2) bleiben anderen Applika-
                             tionen natürlich versperrt, da diese Ressource
                             jetzt von HIMEM benötigt wird, um UMB-Speicher
                             einzublenden.

                             Damit HIMEM die EMS-Funktionen nutzen kann,
                             muß (und das wird häufig mißverstanden) *vor*
                             HIMEM der entsprechende Hardware-Treiber des
                             Herstellers der Zusatzkarte geladen werden, der
                             das EMS-Interface auf die jeweilige Hardware
                             abbildet. Auf dieses Interface setzt dann HIMEM
                             mit seinen Funktionen auf. (Und auf 386ern und
                             Nachfolgern kann danach natürlich noch EMM386
                             geladen werden um weitere Möglichkeiten zu
                             bieten, normalerweise ist es jedoch in diesem
                             Fall sinnvoller, auf HIMEM zu verzichten.)
                             Dieser Treiber muß so konfiguriert werden, daß
                             er auch die Funktionen bereitstellt, die HIMEM
                             benötigt (z.B. müssen bei bestimmten EMS-
                             Treibern die erlaubten Adreßbereich erst
                             explizit freigeschaltet werden). Viele EMS 3.x
                             Zusatzkarten entfalten mit einem EMS 4.0
                             Treiber auch die Möglichkeiten von EMS 4.0,
                             es gibt aber auch Karten, die die optionalen
                             Erweiterungen von 4.0 (wie Backfilling) nicht
                             unterstützen.

                             Möchten Sie verhindern, daß HIMEM für sich
                             selbst EMS-Speicher nutzt, können Sie z.B.
                             /CHIPSET=NONE angeben oder den EMS-Treiber
                             erst nach HIMEM laden.

    /AUTOSCAN=               dokumentiert
    /INCLUDE=                dokumentiert
    /EXCLUDE=                dokumentiert
    /ROM=xxxx | AUTO | NONE  dokumentiert
                             Wird bei xxxx nur die Startadresse angegeben,
                             so versucht der Speichermanager, einen an
                             dieser Adresse liegenden ROM-Header auszuwerten
                             und daraus die Länge des ROMs zu ermitteln.
                             Dies funktioniert aber nur dann, wenn man
                             wirklich die Startadresse des ROMs angibt und
                             nicht etwa nur die Adresse, ab der Shadow-RAM
                             eingeblendet werden soll.
    /VIDEO=                  dokumentiert
                             Möchten Sie den /VIDEO in Verbindung mit
                             /CHIPSET=EMSUMB verwenden, kann es notwendig
                             sein, dem EMS-Treiber, der von HIMEM geladen
                             wird, explizit mitzuteilen, im Video-Adreß-
                             bereich Speicher einblenden zu können, so z.B.
                             bei ASTs EEMS-Treibern.
                             (Nicht geklärt ist, ob diese Option bei EGA-
                             Karten auch in Verbindung mit CHIPSET=RAM
                             funktioniert. Auf einem Testsystem (286er,
                             640 KByte Basisspeicher, HMA und Extended
                             Memory, ATI EGA Wonder 800+) funktionierte
                             dies jedenfalls nicht. Erfahrungsberichte
                             willkommen.)
                             Siehe auch Kapitel V.6.
    /XBDA                    dokumentiert
    /USE=                    dokumentiert (siehe Hinweise für /CHIPSET=RAM)
    /GATEA20=AT|HP|MCA|XMS   zur Übersteuerung der automatischen Wahl der
                             Steuerung der Adreßleitung A20. Diese Leitung
                             dient auf 286ern (und höher) zum Freischalten
                             der A20-Leitung, um z.B. im Real Mode noch die
                             ersten 64 KByte des zweiten MegaBytes Haupt-
                             speicher adressieren zu können. Dieser Bereich
                             heißt HMA (high memory area) und kann nach der
                             XMS-Spezifikation nur von einer Anwendung
                             gleichzeitig benutzt werden. Ist DOS der
                             Eigentümer, so steht die HMA anderen Programmen
                             wie Windows oder DESQview nicht mehr zur
                             Verfügung. Der von DOS nicht selbst benutzte
                             Speicher kann allerdings über ein DOS-API auch
                             an andere DOS-Applikationen vergeben werden.
    /NOXMS                   nicht dokumentiert. Schaltet XMS-Support ab.
    /BDOS                    wird aus Kompatibilität zu DR DOS 'unter-
                             stützt', indem es abgefangen und mit einer
                             Fehlermeldung quittiert wird. Man soll statt-
                             dessen die CONFIG.SYS Direktive DOS=HIGH
                             verwenden.

                                                                             
  ---------------------------------------------------------------------------

  V.4. Bessere Speicherausnutzung mit selbsthochladenden Programmen:
  =====================================================[96-06-18]===

   Stichworte: Selbsthochlader, UMB, MEMMAX, LH, KEYB, NLSFUNC, SHARE,
               NWCDEX

   Novell DOS bietet verschiedene Möglichkeiten, Programme hochzuladen und
   damit kostbaren DOS-Speicher zu sparen.

   Nachdem man entsprechende Speichermanager geladen hat, kann man bestimmte
   Speicherbereiche gezielt sperren oder zur Verwendung freischalten. Alle
   zu ladenden Programme werden dann automatisch ohne weitere Maßnahmen in
   die freigeschalteten Bereiche geladen.

   Hierzu dient das Kommando MEMMAX, das die Verwendung der folgenden
   Bereiche kontrolliert:

    L Lower Memory: Standardmäßig gilt +L, d.h. die ersten 64 KByte (nicht
                    640 KByte!) sind für Programme verfügbar. Wieso ist dies
                    abschaltbar?
                    Dies liegt in erster Linie an einem Segment-Überlauf-
                    fehler in dem Algorithmus einer frühen Version von
                    Microsofts EXEPACK (einem recht ineffizienten .EXE-
                    Packer) und Linker, mit dem früher viele Programme
                    gepackt wurden (aber auch Vorab-Versionen von MS-DOS
                    6.0). Zu Zeiten, wo sich DOS nicht hochladen konnte,
                    waren die ersten 64 KByte des Systems immer belegt,
                    daher trat dieser Überlauffehler nie auf. Lädt man
                    jedoch DOS hoch, wird der untere Speicher (um Ver-
                    wechselungen mit dem üblichen Low-Memory (0 - 640
                    KByte) vorzubeugen, besser: unterste Speicher) für
                    Programme frei und hier kam dann dieser Bug zu Tage.
                    MS-DOS bietet die gleiche Funktion mit dem Befehl
                    LOADFIX, der im Prinzip nichts weiter macht, als dem
                    Programm vorzutäuschen, die untersten 64 KByte wären
                    bereits belegt. Paradox...

    V Video Memory: Nur mit EMM386.EXE/HIMEM.SYS Option /VIDEO, bei
                    MDA/HGC/CGA standardmäßig +V, bei EGA/VGA standardmäßig
                    -V, muß also bei Bedarf erst freigeschaltet werden.
                    Das Ändern dieses Zustandes ist zumindest mittels
                    MEMMAX nicht unter dem TASKMAX/TASKMGR möglich (wohl
                    aber über direkte API-Aufrufe, die aber die System-
                    stabilität beeinträchtigen können).
                    Siehe auch Kapitel V.1. und V.6.

                    Achtung: Mit 4DOS 5.51 (nicht mit 4DOS 5.5c oder 4DOS
                    5.52a) kann diese Option zu Abstürzen führen, siehe
                    Kapitel IV.4. und VII.3. sowie in 4DOSTIP.TXT.

    U Upper Memory: Standardmäßig gilt -U. Siehe auch Kapitel V.1. und V.6.
                    (Per /USE aktivierte UMBs im Video-Speicherbereich
                    lassen sich mit diesem Schalter steuern, nicht mit +V.)


   LOADHIGH etc. werden hierfür nicht benötigt (bzw. diese Spezialkommandos
   übersteuern temporär die MEMMAX-Einstellungen). Da nicht alle Programme
   in allen Bereichen arbeiten, wird man jedoch im allgemeinen die Default-
   Einstellung beibehalten und LOADHIGH/LH/HILOAD zur gezielten Hochladen
   einzelner Programme verwenden.

   Eine Reihe Programme haben jedoch auch eigene Methoden implementiert,
   sich selbst hochzuladen und sind dabei nicht auf LOADHIGH angewiesen.
   Dies ist nicht etwa unnötiger Luxus, sondern hat einige entscheidende
   Vorteile:

   Das jeweilige Programm 'weiß' über sich selbst am besten Bescheid,
   dadurch ist es möglich, daß es nur bestimmte Teile in Lücken im oberen
   Speicher verlagert, daß es während seiner Initialisierung noch im großen
   konventionellen Speicher arbeitet usw. Manche Programme sind zu groß,
   um mit LOADHIGH in UMBs verlagert zu werden, der spätere residente Kern
   würde jedoch sehr wohl dort Platz finden, trotzdem wird das Programm
   normalerweise nicht hochgeladen werden können. Dadurch, daß das Programm
   seinen eigenen Hochlader mitbringt, kann der UMB-Speicher effizienter
   ausgenutzt werden.

   Neben zunehmend mehr Treiberprogrammen mit dieser Fähigkeit (z.B.
   K3PLUS 6.22+ bzw. FreeKEYB) besitzen die folgenden DOS-Programme
   auch diese Fähigkeit:

    KEYB.COM    (nicht nur UMB, sondern auch HMA)
    NLSFUNC.EXE (nicht nur UMB, sondern auch HMA)
    SHARE.EXE   (nicht nur UMB, sondern auch HMA)

    NWCDEX.EXE  Obwohl der Treiber sich bis auf 7 KByte über DPMS ins
                Extended Memory auslagern kann und diese restlichen 7 KByte
                prinzipiell in UMBs hochgeladen werden können, stellt sich
                dieses Unterfangen in der Praxis leider als sehr schwierig
                dar, da während der Initialisierung zunächst der gesamte
                Code (ca. 85 KByte) in den UMBs Platz finden muß. Dadurch
                muß der Treiber möglichst früh geladen werden. Um NWCDEX
                auch in CONFIG.SYS laden zu können, muß man einige Griffe
                in die Trickkiste anwenden (siehe Kapitel II.4.). All diese
                Design-Beschränkungen gelten in verschärftem Maße auch für
                MSCDEX, das mit mindestens 16 KByte zu Buche schlägt und
                noch mehr Speicher während der Init braucht.

    DELWATCH.EXE (kann sich via DPMS bis auf ca. 464 Bytes in den UMBs
                komplett ins XMS auslagern)

    NWCACHE.EXE
    ...

   Diese Programme sollten *nicht* mit LOADHIGH hochgeladen werden (obwohl
   das durchaus klappen mag), weil sie sich viel besser selbst hochladen
   können.
   Werden sie zusätzlich erst mit LOADHIGH hochgeladen, stehen sie sich bei
   den begrenzten Platzverhältnissen im Upper Memory nur selbst im Weg, u.U.
   versagt sogar das gesamte Hochladen.

   Noch ein Hinweis zum Hochladen via DEVICEHIGH= oder LOADHIGH:

   Diese Direktiven unterstützen undokumentierte zusätzliche Parameter, die
   evtl. beim Optimieren der Konfiguration sinnvoll einsetzbar sind, siehe
   Kapitel III.4. und V.5.

                                                                            
  --------------------------------------------------------------------------

  V.5. Hinweise zu LH/LOADHIGH/HILOAD: [96-06-16]
  ===============================================

   Stichworte: Region-Support, Hochladen

   Die Befehle LH/LOADHIGH von MS-DOS unterstützen die Parameter /L:...
   und /S für spezielle MEMMAKER-Optimierungen.
   Bei Novell DOS 7 sind diese Optionen undokumentiert, da sie bis vor
   Update 14 hier - genau wie bei DEVICEHIGH= - keine nennenswerte Funktion
   hatten (SIZE=size gibt es bei LH nicht).

   Ab Update 14 (sicher aber Update 15) wird nun auch bei Novell DOS 7
   Region-Support unterstützt, d.h. es ist möglich, ganz gezielt anzugeben,
   in welchen Speicherbereich ein Programm geladen werden soll und welche
   Randbedingungen dabei bezüglich der UMB-Bereitstellung gelten sollen.

   Bezüglich der Syntax und Funktion siehe Kapitel III.4., Kapitel II.11.
   (Optimierungsmöglichkeiten) sowie Kapitel V.1. und Kapitel V.7.

                                                                            
  --------------------------------------------------------------------------

  V.6. Video-Speicher für Programme nutzen: [96-02-04]
  ====================================================

   Stichworte: MEMMAX, EMM386.EXE, HIMEM.SYS, HIDOS.SYS, /VIDEO

   i. Erweiterung des konventionellen Speichers (MEMMAX +V):
   ---------------------------------------------------------

   Novell DOS 7 (sowie DR DOS 6.0, mit Einschränkungen auch schon DR DOS
   5.0) bieten eine Möglichkeit, einen ungenutzten Video-Speicherbereich
   als Erweiterung des konventionellen Speichers zu benutzen. Damit kann
   der 640 KByte-Bereich (dauerhaft oder temporär) in Abhängigkeit von der
   installierten Video-Hardware um bis zu 64 KByte (mit MDA/HGC) oder gar
   96 KByte (falls keine MDA/HGC) erweitert werden. Dies wird im Detail
   im DOSBOOK beschrieben. Hier sollen nur ein paar zusätzliche Bemerkungen
   zur dahintersteckenden Technologie gegeben werden:

   - Wird der Video-Speicher per HIMEM.SYS (bzw. HIDOS.SYS) bereitgestellt,
     muß entweder im reservierten Video-Speicherbereich (A000-AFFF/B7FF)
     permanentes RAM vorhanden sein (z.B. durch eine Zusatzkarte) oder der
     Chipsatz des Rechners muß Möglichkeiten bieten, dort RAM hinzumappen.
     Unter Umständen muß man hier mit der Optionen /USE, /RAM und /CHIPSET
     dem Speichermanager auf die Sprünge helfen.

     Mir war es bisher allerdings nicht möglich, den tatsächlich vorhandenen
     Video-Speicher einer EGA-/VGA-Karte forciert als permanentes RAM zu
     deklarieren, obwohl diese Möglichkeit auf den ersten Blick nahe-
     liegend (wenn auch gefährlich) ist.
     Daran kann man auch erkennen, daß der Speichermanager nur den Adreßraum
     des Video-Speichers zum Einblenden von RAM benötigt, aber effektiv
     den dort vorhandenen Speicher einer Grafikkarte nicht benutzt. Dies mag
     verschiedene Gründe haben:

     Zunächst ist der Video-Speicher i. allg. erheblich langsamer im CPU-
     Zugriff und kann (beim ISA-Bus) nur 8- oder 16-bittig angesprochen
     werden, wohingegen Hauptspeicher 16 oder 32 Bit breit ist. Außerdem
     besitzt Video-RAM normalerweise kein Parity-Bit und ist meist von
     minderer Qualität, was ebenfalls Probleme mit sich bringen kann.
     Das größte Problem besteht aber darin, daß der wirkliche Video-Speicher
     (so er denn vorhanden ist), von einer EGA-/VGA-Karte selbst benötigt
     wird (hier liegen z.B. die Fonts). Außerdem kann durch Umprogrammierung
     der Register des Video-Controllers der Video-Speicher in völlig anderer
     Stückelung in diesem Speicherbereich eingeblendet werden (was zu
     absolutem Chaos führen würde, wenn ein Programm gerade diesen Bereich
     nutzen würde). Für einen Treiber wie HIMEM.SYS ist es kaum möglich,
     Zugriffe auf die Video-Register abzufangen. Der einzige Weg bestünde
     darin, eine CGA-Karte zu emulieren, denn diese Karte benutzt den
     Adreßbereich A000-AFFF wirklich nicht.

   - Der Speichermanager EMM386.EXE bietet im Prinzip die Möglichkeit,
     die Video-Hardware zu virtualisieren. Soll der Video-Speicherbereich
     bei einer installierten EGA-/VGA-Karte benutzt werden, so emuliert
     EMM386 eine CGA-Karte. Dies ist übrigens auch der Grund, warum
     Bildschirmausgaben mit MEMMAX +V sehr viel langsamer sind als mit
     MEMMAX -V. Außerdem erklärt diese Emulation auch, wieso nahezu alle
     Programme, die mit dynamisch umdefinierten Text-Fonts arbeiten
     (z.B. pseudographische Darstellung von Maus-Cursor etc., etwa alle
     Novell DOS 7 Programme mit NewUI=On .INI-Dateieinstellung) plötzlich
     nur noch die 'einfache' Textausgabe zeigen und wieso die Farben
     plötzlich ganz anders dargestellt werden (nämlich mit der CGA-Farb-
     palette).

     Auch hier gilt: EMM386 mappt bei MEMMAX +V aus seinem eigenen Speicher-
     Pool (der vorher mit /VIDEO reserviert wurde) RAM über den Bildschirm-
     speicherbereich. Der wirkliche Bildschirmspeicher wird dafür nicht
     angetastet (obwohl dies theoretisch möglich wäre, wenn die Hardware
     entsprechend gut virtualisiert wird). Vielleicht ist es mit /RAM
     möglich, die wirkliche Nutzung des Bildschirmspeichers zu erzwingen
     (dies habe ich bisher nicht ausprobiert). Vielleicht muß man dazu eine
     EGA-/VGA-Karte auch schon vor der Installation des Speichermanagers
     manuell auf CGA-Emulation umschalten, etwa:

      INSTALL=c:\sys\video\vmode.com cga
      DEVICE=c:\nwdos\EMM386.EXE /VIDEO /RAM=A000-AFFF ...

     Aber normalerweise blendet die Hardware-CGA-Emulation einer EGA-/VGA-
     Karte dann auch genau den benötigten Speicher aus, so daß das Unter-
     fangen höchstwahrscheinlich zum Scheitern verurteilt ist.
     (Rückmeldungen willkommen.)

     Übrigens: Wird mit MEMMAX +V eine Anwendung aufgerufen, die in einen
     Grafikmodus schalten will, so meldet sich EMM386 mit einer Fehler-
     meldung, daß man das Programm abbrechen sollte, da Zugriffe auf den
     Video-Speicher sowieso von EMM386 abgefangen werden. Drückt man hier
     nicht <ESC>, so arbeitet das Programm jedoch im Hintergrund weiter
     (und merkt normalerweise auch nicht, daß es überhaupt nicht auf dem
     Bildschirm angezeigt wird - dort steht immer noch die Fehlermeldung
     des EMM386).
     Probleme könnte es dann geben, wenn das Programm den Bildschirmspeicher
     zur Ablage von Informationen verwendet, denn es ist nicht geklärt, ob
     EMM386 einfach nur alle Zugriffe auf den Video-Speicher verwirft oder
     diese Zugriffe auf einen virtuellen Speicherbereich umlenkt, der auch
     wieder ausgelesen werden kann. Ich vermute eher das Erstere, denn bei
     Verwendung des TASKMGR auf Zweimonitorsystemen werden Zugriffe auf die
     jeweils gerade nicht aktuelle Grafikkarte offenbar einfach verworfen.

     Schaltet die Applikation wieder in den Textmodus, gibt EMM386 sofort
     die Anzeige wieder frei.

   - Wie man aus obigen Überlegungen ableiten kann, muß keine EGA-/VGA-Karte
     installiert sein, damit die /VIDEO Option funktioniert! Wenn keine
     EGA-/VGA-Karte installiert ist (also A000-AFFF nicht belegt ist), wird
     bei /VIDEO der Bereich von selbst zugeschaltet. Ist allerdings eine
     EGA/VGA installiert (die diesen Adreßraum ja meist selbst nutzt), wird
     der Speicher nur reserviert und muß explizit mit MEMMAX +V aktiviert
     werden. Dann emuliert EMM386.EXE softwaremäßig eine CGA-Karte.
     (Und offenbar kann HIMEM.SYS dies nicht, so daß die /VIDEO Option in
     diesem Fall versagt!?)

   - Möchte man mit MEMMAX +V residente Programme installieren, ist Vorsicht
     geboten. Da diese Programme nur eine CGA-Karte erkennen können, wäre
     es denkbar, daß sie sich bei der Installation speziell an eine CGA-
     Hardware anpassen - übrigens unabhängig davon, ob der Video-Speicher-
     bereich nun wirklich von der Anwendung benutzt wird oder nicht.
     Schaltet man dann später MEMMAX -V ab, um die Möglichkeiten einer
     EGA-/VGA-Karte ausschöpfen, so ist es möglich, daß das residente
     Programm für EGA-/VGA-Karten keine Unterstützung installiert hat
     und im schlimmsten Fall versagt. Daher sollte man nach Möglichkeit
     MEMMAX -V lassen, solange man es nicht wirklich benötigt (und dann
     explizit freischalten).

   - Arbeitet man auf einem Zweimonitorsystem, hängt es vom gerade aktiven
     Video-System ab, wieviel Speicher bei MEMMAX +V zusätzlich eingeblendet
     wird. Benötigt man besonders viel Speicher, sollte man vor MEMMAX +V
     mit MODE CO80 auf den Farbadapter umschalten, so daß man 96 KByte statt
     64 KByte Speicher erhält (Die konkreten Werte hängen natürlich auch von
     /VIDEO=xxxx-yyyy ab). Diese Speichergröße ändert sich dann auch nicht
     durch Rückwechseln mit MODE MONO (falls möglich) und bleibt bis zum
     nächsten MEMMAX -V bestehen.


   ii. Erweiterung des UMB-Speichers (MEMMAX +U):
   ----------------------------------------------

   Spätestens ab Novell DOS 7 Update 14 ist es mit EMM386 auch möglich,
   Teile des Video-Speicherbereichs als UMB-Speicher zu deklarieren. Dazu
   verwendet man die Option /USE in Bereichen des Bildschirmspeichers.
   (Diese Möglichkeit existiert im Gegensatz zu i.) im Prinzip auch bei
   MS-DOS, dort muß allerdings die Option /INCLUDE verwendet werden.)

   Der äußere Unterschied zur ersten Methode liegt darin, daß dieser
   Speicher mit der MEMMAX +U Option gesteuert wird und nicht mit
   MEMMAX +V, auch wenn der Speicher innerhalb des Video-Speicherbereichs
   liegt.
   Außerdem bleibt ein einmal mit /USE deklarierter Speicherbereich
   immer eingeblendet, auch wenn man Upper Memory mit MEMMAX -U de-
   aktiviert (logisch :-) ). Insofern eignet sich diese Methode auch
   zum Laden von Gerätetreibern und TSRs. In der Praxis habe ich jedoch
   herausgefunden, daß normalerweise nur TSRs (z.B. über INSTALL[HIGH]=
   oder LH geladen) in diesen Bereich geladen werden, Gerätetreiber
   werden weiterhin oberhalb von C800 geladen (Dies gilt natürlich nicht
   für selbsthochladende Treiber)! Ob dies repräsentativ ist, kann ich
   noch nicht sagen.

   Es ist möglich, daß Programme, die in den Video-Speicherbereich geladen
   wurden, ein anderes Verhalten zeigen, als wenn sie in 'normale' UMBs
   geladen würden. Dies kann daran liegen, daß die Verwendung des Video-
   Speicherbereichs für ausführbaren Code ansonsten unüblich ist und
   Programmierer diesen Fall evtl. nicht mit eingeplant haben und dadurch
   Bereichsüberläufe in den programminternen Algorithmen auftreten. Bei
   meinen Tests hat sich aber herausgestellt, daß diese Überlegungen wohl
   eher theoretischer Natur sind. Alle von mir bisher getesteten Treiber
   funktionierten grundsätzlich auch im Video-Speicherbereich. Einmal gab
   es offenbar Probleme mit der Verwendung von Funktionen des Video-BIOS.
   Näheres ist aber noch nicht geklärt.

   Möchten Sie MS Windows im Erweiterten 386-Modus benutzen, so ist es
   notwendig, einen speziellen Treiber namens MONOUMB.386 (von MS-DOS 6.2x)
   in das \WINDOWS\-Verzeichnis zu kopieren (oder den bei MS Windows bei-
   liegenden Treiber zu verwenden) und in der SYSTEM.INI im Abschnitt
   [386Enh] die Zeile DEVICE=MONOUMB.386 einzufügen. Diese Anpassung ist
   definitiv notwendig, ansonsten wird EMM386 eine Seitenzuweisungskonflikt
   melden und fälschlicherweise empfehlen, man solle im SYSTEM.INI Abschnitt
   [386Enh] DualDisplay=No setzen. Damit funktionierte in meinem Fall (mit
   B100-B7FF als UMB) sogar noch der Betrieb des zweiten Monitors im Text-
   modus (und sogar Umleitungen via DUALMON.SYS). Was zu tun ist, wenn Sie
   andere UMB-Bereiche als den Bereich B000-B7FF als UMBs benutzen wollen,
   ist vorerst noch nicht geklärt (es gibt bei MS Windows noch einen
   weiteren Treiber namens MONOUMB2.386...). Offenbar ist es nicht not-
   wendig, den MONOUMB.386 Treiber auch beim multitaskenden TASKMGR zu
   laden (siehe Kapitel VII.2.).

   Theoretisch ist das Laden von Gerätetreibern und TSRs auch im mit
   MEMMAX +V freigeschalteten Speicherbereich möglich, allerdings ist
   dies aus zwei Gründen problematisch:

   - Normalerweise werden die Speicherbereiche von unten nach oben
     gefüllt. Solange man die Allokationsstrategie nicht verändert,
     dürfte man daher kaum in die Verlegenheit kommen, den Speicherbereich
     A000-BFFF (640 - 768 KByte!!!) mit residenten Programmen zu füllen.
   - MEMMAX -V ist danach nicht mehr möglich.

   Die Verwendung von Video-Speicheradreßraum mit der Option /USE
   bedeutet aber auch, daß während der ganzen Session dieser Speicher-
   bereich nicht mehr für die Grafikkarte verwendet werden kann. Über
   CONFIG.SYS Boot-Menüs kann man Fallunterscheidungen einrichten und
   nur dann Bildschirmspeicherbereiche als UMB-Speicher verwenden, wenn
   man bestimmte Eigenschaften der Grafikkarte für die Dauer der Session
   nicht benötigt, dafür aber soviel wie irgend möglich Speicher
   freiräumen muß.

   Achtung: EMM386 kann nicht überprüfen, ob mit /USE freigegebene
   Speicherbereiche tatsächlich von Programmen oder als Video-Speicher
   verwendet wird. Zugriffe auf diese Speicherbereiche als Video-Speicher
   (z.B. MODE MONO) führen zwangsläufig zu Abstürzen, da die dorthin
   geladenen Programme einfach durch Bildschirmausgaben überschrieben
   werden... Dies muß man beachten, wenn z.B. Programme auch im Textmodus
   den Speicher der höheren Textseiten oder gar Grafikbereich als Zwischen-
   ablage verwenden, oder wenn Bildschirmtreiber direkt auf die Grafik-
   Hardware zugreifen (z.B. MODE MONO/CO80 oder der FreeWare-Treiber
   DUALMON.SYS (Geräte MONO/COLOR oder MONODISP/CO80DISP) läuft z.B. nur,
   wenn mindestens die jeweils erste Seite von der Nutzung ausgeschlossen
   wird). Es gibt auch manche SuperVGAs, die nicht mit einer zweiten
   Grafikkarte im System kooperieren können (manche älteren Trident-
   Chipsätze gehören dazu). Da solche SuperVGAs im Grafikmodus auch den
   für die andere Grafikkarte reservierten Adreßraum benutzen (B000-B7FF
   oder B800-BFFF), ist von einer Verwendung als UMBs abzuraten.
   Definitiv keine Probleme bereiten ET4000-Chipsätze (Info wanted!).

   Die Option /USE akzeptiert mit Sicherheit Adressen bis hinab zu A000h
   (640 KByte), evtl. sind aber auch Werte wie 8000h (512 KByte) zulässig
   (nicht überprüft), womit man 512 KByte-Rechner auf 640 KByte 'aufrüsten'
   könnte...


   iii. Kombinationen/Beispiele:
   -----------------------------

   Natürlich können die Methoden i.) und ii.) kombiniert werden, wobei man
   hier aufgrund der vielen Möglichkeiten kaum noch generelle Empfehlungen
   geben kann.

   Mit der Methode i.) sollte ein möglichst großer Speicherbereich für die
   Doppelnutzung als Video-Speicher oder erweiterter konventioneller
   Speicher deklariert werden (/VIDEO). Damit behält man zur Laufzeit
   größtmögliche Freiheit in der Wahl des Speichers.

   Mit der Methode ii.) können Bereiche, die mit der Methode a) nicht
   erreichbar sind (z.B. weil sie oberhalb eines von der Grafikkarte
   verwendeten Bereichs liegen) als UMBs eingebunden werden, sofern sie
   definitiv nicht für die Bildschirmdarstellung benötigt werden (/USE).
   Außerdem ist hier die Angabe von mehr als einem Bereich möglich.

    Adapter:           Benutzte Speicherbereiche:      /VIDEO:   /USE:

    MDA/HGC            B000-B200/B7FF/BFFF             A000-AFFF B800-BFFF
    CGA                B800-BFFF                       A000-B7FF
    EGA/VGA            A000-AFFF,(B000-B7FF),B800-BFFF A000-B7FF (B000-B7FF)
    MDA/HGC + CGA      B000-B7FF + B800-BFFF           A000-B000/B7FF
    MDA/HGC + EGA/VGA  B000-B7FF + A000-AFFF,B800-BFFF A000-B000/B7FF
    Mono-EGA/VGA + CGA A000-AFFF,B000-B7FF + B800-BFFF A000-B7FF

   Neben diesen Anhaltspunkten sollte man sich überlegen, ob man z.B.
   eine MDA-/HGC-Karte evtl. nur im Textmodus nutzt. Dann kann nämlich
   der Adreßraum oberhalb der Speichers für diese Textseite (normalerweise
   eine Textseite á 4096 Zeichen (1000h) ebenfalls für UMBs verwendet
   werden! Bei einer MDA/HGC mit B000-B7FF würde man dann zum Beispiel
   /USE=B100-B7FF angeben können. Verwendet man eine HGC-Karte nicht im
   Grafikmodus gilt hier i. allg. das Gleiche. Analoge Überlegungen kann
   man für die zweite Grafikseite einer HGC (B800-BFFF) und für CGA-Karten,
   aber auch für EGA/VGAs im Textmodus anstellen. Hier sollte man aber
   beachten, daß diese Karten mehrere Bildschirmseiten unterstützen und
   manche Anwendungen diese als Puffer verwenden. Kann man solche Umstände
   ausschließen, sind auch diese Bereiche erlaubt. Bei richtiger Wahl der
   Bereiche bleibt sogar die Möglichkeit erhalten, mit MODE CO80/MONO
   zwischen beiden Adaptern zu wechseln, ohne damit Abstürze zu riskieren!

   Ein konkretes Beispiel für eine Kombination aus VGA+HGC, wobei die HGC
   nur im Textmodus betrieben werden darf:

    ...
    REM Mit MEMMAX +U (Standard) 28 KByte mehr UMB-Speicher aus dem
    REM 'Nichts'. Mit MEMMAX +V je nach aktivem Bildschirm 64/96 KByte
    REM mehr Basisspeicher...
    DEVICE=EMM386.EXE /VIDEO /USE=B100-B7FF
    ...

   Sie benötigen beide Systeme (VGA+HGC) nur im Textmodus und dort jeweils
   nur in der ersten Textseite. Darf's auch etwas mehr sein?

    ...
    REM Mit MEMMAX +U (Standard) 56 KByte mehr UMB-Speicher. Mit MEMMAX +V
    REM je nach aktivem Bildschirm 64/96 KByte mehr Basisspeicher.
    DEVICE=EMM386.EXE /VIDEO /USE=B100-B7FF,B900-BFFF
    ...

   Es ist möglich, daß frühere Versionen von Novells EMM386 diese Möglich-
   keiten nicht sauber unterstützten, mit Update 14 wurden jedenfalls gerade
   diese Möglichkeiten überarbeitet.

                                                                            
  --------------------------------------------------------------------------

  V.7. UMB-Region-Support: [96-05-31]
  ===================================

   Stichworte: MEMMAX +U, DEVICEHIGH=, LH/LOADHIGH/HILOAD, MEM.BAT

   Wie schon in Kapitel III.4. (DEVICEHIGH=) und V.5. (LH/LOADHIGH/HILOAD)
   ausführlich besprochen, unterstützt Novell DOS 7 ab Update 14 nun auch
   Memory-Regions, wie sie von MS-DOS her bekannt sind (Näheres bitte den
   entsprechenden Kapiteln entnehmen).

   Es bleibt anzumerken, daß auch Novell DOS (spätestens) ab Update 14
   innerhalb der UMBs zwischen Gerätetreibern (DEVICEHIGH=) und TSRs
   (INSTALLHIGH=) unterscheidet. Wenn mehr als eine UMB-Region zur Verfügung
   stehen, werden die TSRs default-mäßig in die Memory-Region 1, die Geräte-
   treiber in die Region 2 jeweils von unten nach oben geladen. Mit dem
   Parameter /L:region kann dies natürlich übersteuert werden, außerdem
   weicht Novell DOS von diesem Prinzip ab, sobald in einer Region nicht
   mehr genügend Speicher zur Verfügung steht. Wofür diese Unterscheidung
   gut ist kann ich nicht genau sagen, ich vermute dreierlei Strategien,
   die Speicherverteilung in den UMBs zu optimieren:

   - Gerätetreiber können praktisch nie zur Laufzeit deinstalliert werden,
     so daß es sinnvoll ist, sie zusammenhängend anzuordnen, um einer Frag-
     mentierung des Speichers vorzubeugen.
     TSRs können manchmal deinstalliert werden, wodurch eine Lücke im
     Speicher entsteht. Da unter solchen dynamisch geladenen und entladenen
     TSRs eine größere Fluktuation herrscht, ist die Wahrscheinlichkeit
     größer, daß die Fragmentierung des Speichers hier häufiger wieder
     aufgehoben wird. Novell DOS faßt normalerweise auch hintereinander-
     liegende freie Blöcke zu einem größeren Block zusammen (allerdings
     zumindest mit früheren Ausgaben nicht immer), MS-DOS kann dies nicht
     (hier kann man mit einem kleinen Utility namens DEFRAGM von Herwig
     Feichtinger aus c't 01/1996, S. 288 nachhelfen).

   - TSRs besitzen normalerweise eine Umgebung, die aber nur in den
     seltensten Fällen vom TSR benötigt wird. Deshalb geben umsichtig
     programmierte TSRs ihre Umgebung wieder frei, so daß das Betriebs-
     system sie wieder verwenden kann. Da die Umgebung häufig die gleiche
     Größe behält, paßt die Umgebung des nächsten TSRs häufig genau wieder
     in diesen freien Block (noch besser programmierte TSRs verlagern einen
     Teil ihres Codes in ihren Umgebungsblock, so daß die Fragmentierung
     von vornherein nicht entsteht). Aus den gleichen Gründen wie beim
     ersten Punkt ist es auch hierfür sinnvoller, die TSRs in eine eigene
     Region zu laden. (Siehe auch mein Utility SETENV.COM.)

   - Gerätetreiber (üblicherweise per DEVICE=/DEVICEHIGH=/HIDEVICE= geladen)
     und TSRs (z.B. über INSTALL=/INSTALLHIGH=/HIINSTALL= zu laden) werden
     bei Novell DOS/DR DOS innerhalb der CONFIG.SYS in genau der Reihenfolge
     geladen, in der die Aufrufzeilen abgearbeitet werden. Bei MS-DOS/PC-DOS
     ist dies nicht der Fall: Selbst unter Verwendung von Boot-Menüs werden
     immer zuerst die Treiber per DEVICE= etc. geladen und danach die
     Treiber per INSTALL=, jeweils entsprechend ihrer Reihenfolge des
     Vorkommens (bei Boot-Menüs entsprechend verschachtelt), vgl. auch
     Kapitel III.1. und III.7.
     Dadurch werden üblicherweise bei MS-DOS/PC-DOS auch Gerätetreiber und
     TSRs jeweils in nahen Speicherbereichen angesiedelt. Durch die Auf-
     teilung, die Novell DOS beim Laden in unterschiedliche Memory-Regions
     vornimmt, werden die Treiber *ähnlich* im Speicher angeordnet, wie dies
     unter MS-DOS/PC-DOS resultieren würde.

   Der MEM Befehl unterscheidet zwar in seiner Ausgabe zwischen Geräte-
   treibern (rechtsbündig) und TSRs/Programmen/Daten (linksbündig), kann
   aber (derzeit) noch nicht die Memory-Regions auflisten. Als Ersatz kann
   der Batchjob MEM.BAT aus Kapitel IV.5. verwendet werden, der den MEM
   Befehl unter Novell DOS 7 um die Parameter /FREE, /MODULE und zwei neue
   Parameter /REGION und /VECTORS erweitert.

                                                                            
  --------------------------------------------------------------------------

  V.8. Tuning-Tips für 4DOS-Benutzer: [96-02-06]
  ==============================================

   Stichworte: LH/LOADHIGH/HILOAD, SETLOCAL/ENDLOCAL, Hochladen,
               Fragmentierung

   Da *jedem* TSR eine eigene Umgebung, die die zum Startzeitpunkt
   aktuellen Einstellungen aufnimmt, zugeordnet wird, ist es generell
   ratsam, die Umgebung während des Ladens von TSRs möglichst klein zu
   halten (dies gilt für jedes DOS und jeden Kommandoprozessor).

   4DOS bietet hier einige zusätzliche Möglichkeiten, die häufig die
   letzten Bytes aus dem System quetschen können (obwohl sie rein gar
   nichts mit Speicherverwaltung im eigentlichen Sinne zu tun haben):

   - TSR-Aufrufen sollte ein '@'-Zeichen vorangestellt werden. Dieses
     Zeichen hat für 4DOS neben der üblichen noch eine spezielle Funktion:
     Die Umgebungsvariable %CmdLine% (normalerweise mit der Aufrufzeile
     des gerade aktuellen externen Programms belegt) wird gelöscht, wodurch
     bis zu 128 Bytes in der Umgebung eingespart werden können.
     Leider akzeptiert Novell DOS COMMAND.COM ein vorangestelltes @ nur beim
     ersten Kommando einer Zeile, nicht jedoch bei Verkettungen via Piping.

   - Wird ein Programm hochgeladen (egal auf welchem Wege) und benötigt das
     Programm seine Umgebung nicht wirklich (die wenigsten TSRs tun
     das), sollte man die Umgebung vor dem Laden freigeben und nachher
     wieder einrichten. 4DOS bietet dafür die SETLOCAL/ENDLOCAL und UNSET
     Kommandos:

      REM Umgebung temporär löschen:
      IF "4"=="%@Eval[2 + 2]%" SETLOCAL %+ UNSET *
      REM Nun wird das TSR-Programm hochgeladen:
      LH d:\path\tsr parameters
      REM Umgebung wieder einrichten:
      IF "4"=="%@Eval[2 + 2]%" ENDLOCAL

     Werden innerhalb eines solchen Blocks einige Variablen (wie %Path%)
     trotzdem benötigt, so kann man das Beispiel wie folgt erweitern:

      IF "4"=="%@Eval[2 + 2]%" SETLOCAL %+ ALIAS tmpbuf = c:\_path_.tmp ...
                            ... %+ PATH > tmpbuf %+ UNSET * %+ SET /R tmpbuf
      LH tsr parameters
      IF "4"=="%@Eval[2 + 2]%" DEL tmpbuf > \dev\nul %+ ENDLOCAL

     Wichtig ist jedoch, daß Sie auf diese Art und Weise keine Programme
     laden, die *nicht* oder nicht vollständig hochgeladen werden (z.B.
     SDRES bei EMS-Nutzung, siehe Kapitel II.4.). Denn in diesem Fall
     sparen Sie zwar insgesamt den Platz für die Umgebung fast komplett
     ein, aber dieser Vorteil wird mit dem um Größenordnungen verheerenden
     Nachteil erkauft, daß der konventionelle Speicher fragmentiert wird.
     4DOS speichert nämlich bei SETLOCAL die alte Umgebung/Alias in einem
     Puffer zwischen, der im konventionellen Speicher liegt (und je nach
     Konfiguration einige KiloByte (bei mir 3 KByte) groß ist). Dieser
     Puffer wird zwar bei ENDLOCAL wieder freigegeben, aber dadurch, daß
     das inzwischen in den konventionellen Speicher geladene TSR nun nicht
     mehr dicht an dicht mit seinem Vorgänger liegt, wird die maximale
     zusammenhängende Größe des konventionellen Speichers um genau diesen
     Betrag der zwischengespeicherten SETLOCAL Umgebung verringert. Zwar
     kann auch dieser Speicherbereich wieder verwendet werden, aber der
     Hauptspeicher bleibt fragmentiert.

                                                                             
  ###########################################################################
  ###########################################################################

  VI. NETZWERK:
  =============

  ---------------------------------------------------------------------------

  VI.1. Netzwerk-Hardware: [96-10-30]
  ===================================

   Stichworte: PNW, EtherNet-Hardware, NE2000, DMA, BNC

   Mit Novell DOS 7 gebündelt (aber auch einzeln erhältlich) ist Personal
   NetWare 1.0, der Nachfolger von NetWare Lite (der ehemals kleinste Sproß
   in der Novell NetWare-Familie, war u.a. in späteren Ausgaben von DR DOS
   6.0 beigepackt). Diese Netzwerk-Software ist eine ideale Ergänzung zu
   Novell DOS (aber auch anderen DOS-Versionen, die allerdings nicht schon
   generisch integrierten Netzwerk-Support bieten), wenn man mehrere Rechner
   miteinander verbinden will, aber sich die Anschaffung der großen NetWare
   Produkte nicht lohnt. Dabei ist nicht nur der Preis des Produkts aus-
   schlaggebend, sondern vor allem der Administrationsaufwand, der z.B.
   bei NetWare 3.xx und erst recht bei NetWare 4.xx um ein Vielfaches höher
   liegt. Daher ist Personal NetWare auch für kleinere Firmen mit geringer
   Infrastruktur interessant, wenn nicht mehr als vielleicht 10 - 40 Rechner
   zu vernetzen sind.

   Netzadapterkarten sind mittlerweile schon ab ca. DM 30,- zu haben, ein
   10m Kabel kostet ca. DM 10,-, T-Stücke und Abschlußwiderstände jeweils
   unter DM 5,-.

   Für den privaten Gebrauch empfehlen sich NE2000-kompatible Ethernet-
   Karten (PNW ist nicht an Ethernet gebunden, dies stellt aber das am
   weitesten verbreitetste Netzzugangsverfahren dar).
   Diese Karten stellen zwar nicht das Non-Plus-Ultra an Leistung dar, aber
   sie sind erstens sehr günstig, zweitens reicht die Performance für kleine
   Netze allemal aus und gegenüber vielen teureren Karten bieten sie noch
   einen entscheidenden Vorteil:
   Sie benötigen keinen Adreßraum im UMB-Bereich des Rechners, d.h. man hat
   mehr Platz für Zusatzprogramme (und/oder die Netzwerk-Software) zwischen
   den Adaptern und sie benutzen auch keine DMA-Transfers. (Die sonst häufig
   verwendeten SMC-Ultra-Serien u.a. benötigen demgegenüber ein 8 - 16 KByte
   großes RAM-Fenster im UMB-Bereich, der für anderweitige Nutzung flach-
   fällt). Bei der NE2000 läuft die gesamte Kommunikation interruptgesteuert
   über Port-Zugriffe ab, heutige 16Bit-Karten lassen sich flexibel genug
   einstellen, daß hier selbst mit vielen anderen Zusatzkarten im Rechner
   kaum Adreßkonflikte auftreten werden. Probleme mit Treiber-Updates und
   anderen Betriebssystemen wird es bei dieser Karte aufgrund der weiten
   Verbreitung quasi nie geben.

   Als Default-Adresse hat sich 300h oder 240h (manchmal auch 280h)
   eingebürgert, welche meist auch verwendet werden kann (300h ist der
   Prototyp-Bereich); man sollte aber entgegen üblichen Standards eher
   einen hohen Interrupt (z.B. IRQ 10) verwenden, um Konflikten mit
   seriellen, parallelen Schnittstellen und EGA-/VGA-Karten aus dem Weg
   zu gehen.

   Als Netzwerkkabel kommt ein 50 Ohm BNC-Koaxialkabel in Frage, das sich
   von Karte zu Karte schlängelt. An jede Netzadapterkarte kommt ein sog.
   T-Stück, an beiden äußeren Enden des Stranges ein 50 Ohm-Terminations-
   widerstand (wichtig!). Das Kabel sollte mindestens 10m lang sein (auch
   wenn man diese Länge nicht benötigt), darf aber nicht länger als ca.
   170m lang werden, im privaten Bereich sicherlich kein Problem...
   Das Kabel sollte nicht geknickt werden, die BNC-Stecker sollten
   pfleglich behandelt werden, da sie häufig Ursache für schwer auffindbare
   Fehler sind.

                                                                             
  ---------------------------------------------------------------------------

  VI.2. PNW-Software-Einrichtung: [97-03-02]
  ==========================================

   Stichworte: SETUP /FIRST, DPMS, SERVER, ODI, Frame 802.2, NetWare,
               STARTNET.BAT, STOPNET.BAT, NET.CFG, VLM, NET ADMIN,
               Ressourcen, Geteilte Verzeichnisse, Server nicht geladen,
               Updates, %NWLanguage%, TASKMGR

   Leider ist die Software-Installation von PNW nicht ganz einfach zu
   bewerkstelligen (aber immer noch sehr viel einfacher, als bei der großen
   NetWare). Bezüglich der Erstinstallation siehe DOSBOOK und SETUP /FIRST.

   Hier können nur ein paar Einzelhinweise gegeben werden:

   Um möglichst viel Speicher zu sparen, ist es absolut empfehlenswert,
   Novells DPMS zu laden. Dadurch wird ein Großteil der Netzwerk-Software
   (SERVER) in den Zusatzspeicher verlagert und man kommt trotz geladenem
   Server auf ähnliche Speichergrößen wie in typischen NetWare 3.xx Netzen
   mit IPX/NETX-Treibern etc.
   Der Server belegt ca. 30 - 60 KByte (bei DPMS Nutzung) im ersten Mega-
   Byte, läßt sich nur selten hochladen, nutzt außerdem jedoch Extended
   Memory via DPMS. (Die Datei SERVER.EXE enthält für MS Windows auch den
   virtuellen Gerätetreiber VNWLSERV.386.) Die restlichen Netztreiber
   benötigen weniger Speicher (Größenordnung 25 - 40 KByte).

   (Mit einem undokumentierten SERVER.EXE Parameter "SERVER L" (wohl auch
   "SERVER /L") kann verhindert werden, daß ein spezieller Fix für einen
   falschen NCP-Call, den manche Datenbankapplikationen (DBase, Clipper)
   ausführen, eingebunden wird. Dadurch kann man, wenn man bei SHARE keine
   Extra-Handles benötigt und keine Datenbanken anwendet, ganze 192 Bytes
   einsparen. ;-) )

   PNW 1.0 verwendet ODI-Treiber und sollte auf FRAME 802.2 eingestellt
   werden, wenn man die Anbindung an ältere NetWare 2.xx, 3.xx Netze nicht
   benötigt (dort braucht man FRAME 802.3). Ähnlich wie bei NetWare 4.xx
   arbeitet PNW 1.0 mit der VLM-Technik (virtual loadable module),
   eine Parallelentwicklung zu den NLM (netware loadable module) von
   NetWare 3.xx+, allerdings bis vor das neue Client32-Kit für die Clients.
   Für die Anbindung an NetWare 4.xx werden auch Verzeichnisdienste unter-
   stützt.
   Teilweise ist PNW also auf einem moderneren Stand der Software-Technik
   als die weitverbreitete NetWare 3.xx (besonders, was die beiliegenden
   Tools angeht), natürlich von den Möglichkeiten auf den Bedarf kleiner
   Netze zurückgeschraubt. Trotzdem können bis zu 50 Accounts eingerichtet
   werden (irgendwo in den Novell Foren gibt es auch einen Hinweis auf bis
   zu 244 Accounts).


   Eine typische STARTNET.BAT:

    @ECHO off
    SET NWLanguage=DEUTSCH
    REM Diese Variable spezifiziert das Verzeichnis, in dem PNW nach landes-
    REM sprachlichen Dateien sucht.
    REM Unter DOS muß das \NLS\%NWLanguage%\ Verzeichnis dort liegen, von wo
    REM die Netzwerk-Software geladen wurde: C:\NWCLIENT\NLS\DEUTSCH.
    REM Unter MS Windows muß \nls\%NWLanguage%\ vom Ursprungsverzeichnis der
    REM unter Windows geladenen Shell (i. allg. PROGMAN.EXE) ausgehen. In
    REM dem Fall, daß die verwendete Shell in C:\WINDOWS\ liegt, resultiert
    REM daraus C:\WINDOWS\NLS\DEUTSCH. %NWLanguage% muß eine gültige
    REM relative Pfadangabe enthalten, die aber nicht notwendigerweise auf
    REM den Namen eines Unterverzeichnisses beschränkt sein muß (siehe auch
    REM Kapitel IV.7.). Um ein Beispiel zu geben:
    REM Angaben wie ..\NLS\DEUTSCH sind durchaus gültig. Ist %NWLanguage%
    REM nicht definiert oder ungültig, so wird %Path% ausgewertet.
    REM %NWLanguage% selbst darf keine Pfadliste enthalten.
    c:
    CD c:\nwclient
    LH LSL
    REM LH RXMONSTK für manche Netz-Analyzer-/Management-Programme not-
    REM wendig, sofern für den MLID-Treiber (hier NE2000.COM) das VLM-
    REM Update 2+ eingearbeitet wurde, und die entsprechenden Programme
    REM noch nicht daran angepaßt wurden.
    REM Siehe Hinweise im Archiv VLMUPx.EXE.
    LH NE2000
    REM IPXODI /A kann auf Kosten der Funkionalität Speicher sparen.
    LH IPXODI
    REM Der Versuch SERVER und/oder VLM hochzuladen (LH), führt bei manchen
    REM Konfigurationen zu Abstürzen und Hängen, ausprobieren...
    REM SERVER wird natürlich nur benötigt, wenn dieser Rechner Ressourcen
    REM mit anderen Rechnern teilen soll.
    [LH] SERVER
    REM DEDICATE.COM
    [LH] VLM /V4
    CD \
    NET LOGIN %1 %2 %3 %4 %5 %6 %7 %8 %9

   (Es gibt noch 1001 Optimierungsmöglichkeiten, die aber hier den Rahmen
   sprengen würden).


   Zum Entladen des Netzwerks bietet sich das Umgekehrte an - STOPNET.BAT:

    @ECHO off
    IF ""=="%NWLanguage%" SET NWLanguage=DEUTSCH
    c:
    CD c:\nwclient
    NET LOGOUT
    VLM /U
    SERVER /U
    IPXODI /U
    NE2000 /U
    LSL /U
    CD \


   Die Datei NET.CFG (Beispiel für eine NE2000-Karte):

    Link driver NE2000
     INT 10
     PORT 300
     FRAME Ethernet_802.2

    NetWare DOS Requester
     PREFERRED WORKGROUP = PNWNET ; (offenbar statt WORKGROUP NAME=)
     ; Für die Verwendung des TASKMGR (besonders im Prozeßumschaltmodus)
     ; von SERVER.EXE verwendet
     ALTERNATE CALLDOS = ON
     ; Diagnoseausgaben beim Start auf Maximum einstellen:
     MESSAGE LEVEL = 4
     FIRST NETWORK DRIVE = S
     ; Unterstützte Protokolle NetWare3 BIND,  BIND PNW
     NETWARE PROTOCOL = PNW
     ; Zeige Punkte . und .. in Verzeichnisauflistungen
     SHOW DOTS = ON
     ; Message-Timeout (10000 entspricht 6 Stunden laut DOSBOOK,
     ;                 aber entspricht 9 Minuten laut c't 9/94???)
     MESSAGE TIMEOUT = 10000
     ; Weniger Speicherbedarf bei geringerer Performance:
     ; CACHE BUFFERS = 2
     ; CACHE BUFFER SIZE = 512
     ; Maximale Namenslänge verkürzen (<48>):
     AVERAGE NAME LENGTH = 16
     ; PNW-Responder abschalten:
     ; RESPONDER = OFF
     ; Folgende Module auch swappen:
     ; LOAD LOW CONN = OFF
     ; LOAD CONN TABLE LOW = OFF
     ; LOAD LOW IPXNCP = OFF
     ; Lade alle Standard-VLM und zusätzlich die AUTO und NMR:
     USE DEFAULTS = ON
     VLM = AUTO.VLM
     VLM = NMR.VLM

   Mit den ausgeklammerten Parametern kann man etwas experimentieren, um
   den Speicherbedarf zu drücken, aber leider damit auch teilweise stark
   die Performance zu drosseln. U.U. kann es auch vorkommen, daß die
   Konfiguration instabil wird, austesten...

   Wichtig:

   Am Ende der Datei NET.CFG muß eine Leerzeile stehen (d.h. auch der
   letzte Eintrag muß mit <Return> abgeschlossen werden), ansonsten kann
   es passieren, daß die letzte Zeile überlesen wird!
   Eine Übersicht über die derzeit gültigen NET.CFG Parametern (die sich
   im Laufe der Zeit in einigen Dingen geändert haben), findet sich in
   den VLMUPx.EXE Updates in der Datei NET.CFG, in NETCFG.TXT u.a., siehe
   auch Kapitel VI.12.


   Weitere Server-Einstellungen kann man in NET ADMIN ('Server konfigu-
   rieren') vornehmen, hier sollte man möglichst alle Module laden (außer
   'lokale Bestätigung'), bei den 'erweiterten Einstellungen' muß man
   unbedingt darauf achten, daß man nicht weniger geteilte Ressourcen
   angibt, als wirklich vorhanden sind, sonst kann es vorkommen, daß der
   Server beim nächsten Mal nicht mehr hochfährt und mit der irreführenden
   Fehlermeldung

    "Server konnte nicht geladen werden, da Konfigurationsdatei zu einer
     anderen Version der Servers gehört, oder beschädigt ist."

   abbricht.

   Häufig sucht man den Fehler dann erst wochenlang an völlig anderen
   Stellen. :-(

   Entsprechend muß man die Ressourcen auch hochsetzen, *ehe* man neue
   Hardware einbaut, sonst kann man böse Überraschungen überleben und darf
   u.U. alles wieder ausbauen.

   Hinweis bezüglich 'geteilter Verzeichnisse':

   Diese Angabe muß größer oder gleich der Anzahl logischer Blockgeräte-
   treiber sein, die man in der DOS-Konfiguration lädt. Dabei zählt z.B.
   jede Floppy, jede DOS-Partition einer Harddisk, jeder Eintrag via
   DRIVER.SYS, jede RAM-Disk (RAMDRIVE, VDISK, TurboDSK u.a.), jedes
   komprimierte Laufwerk und Host-Laufwerk (STACKER, DBLSPACE, DRVSPACE
   u.a.), jeder spezielle Treiber für Speziallaufwerke wie CD-ROMs,
   CD-WOs, CD-MOs, spezielle Streamer, die wie Laufwerke angesprochen
   werden.

   Sollten also obige Fehlermeldung auftauchen, muß der Rechner in einer
   Minimal- oder Null-Konfiguration gestartet werden, in der nichts geladen
   wird, was nicht unbedingt zum Booten des Rechners notwendig ist. Wenn
   der Server dann ohne Fehlermeldung lädt, müssen nach und nach alle
   zusätzlichen Programme wieder eingebunden werden, bis der Server nicht
   mehr lädt. Die Ressource, die der zuletzt eingebundene Treiber bereit-
   stellt, muß dann um die entsprechende Anzahl ihrer Bereitstellung hoch-
   gesetzt werden (Auch, wenn es gar nicht gewünscht ist, diese Ressource
   zu teilen: sie ist aber vorhanden und muß verwaltet werden). Wie, wenn
   der Server nicht mehr lädt?
   Der Treiber muß wieder entfernt, der Rechner neu gebootet, der Server
   gestartet und mit NET ADMIN 'Server konfigurieren' der entsprechende
   Eintrag erhöht werden.

   Übrigens ist es sogar möglich, daß dieses Problem bereits nach der Erst-
   installation auftaucht, wenn das SETUP-Programm eine Ressource nicht
   erkannt hat und Default-Einstellungen vornimmt. In so einem Fall nützt
   es überhaupt nichts, verzweifelt den Server neu (auf einem vielleicht
   anderen Weg) installieren zu wollen. Der oben beschriebene Weg sollte
   jedoch auch dann funktionieren.

   Ich hatte lange Zeit auch ein Problem mit einem PNW-Server, auf dem
   immer wieder EMM386-Schutzfehlern auftraten, sobald man Dateien vom
   Server kopieren oder auch nur ansehen wollte. Es stellte sich auch
   heraus, daß in vielen Dateien, die auf den Server kopiert worden waren,
   ab einer immer gleichen Position in der Datei (bei mir Offset 2162) für
   einige Bytes (516 - 520 Bytes) willkürliche Daten eingestreut waren (die
   Dateilänge, Datumsstempel, der Anfang und der Rest der Datei waren völlig
   ok, so daß dies erst spät auffiel). Obwohl die Konfigurationsdateien den
   anderer PNW-Server entsprachen, war das Problem erst zu lösen, nachdem
   ich mit NET ADMIN die Server-Konfiguration so verändert hatte, daß die
   Empfangspuffergröße auf 1024 eingestellt war. Dies kann natürlich nicht
   verallgemeinert werden, bei ähnlichen Problemen sollten Sie aber diese
   Einstellungen sehr genau auf Plausibilität überprüfen und evtl. damit
   experimentieren.

   Eine Fehlermeldung der Art 'VLM xxx-47: Es konnte kein Server gefunden
   werden. Vor dem Fortfahren Verkabelung und Server-Status überprüfen!',
   scheint beim Hochfahren eines Servers 'normal' zu sein, jedenfalls konnte
   ich diese Meldung bisher nicht umgehen (trotz PREFERRED WORKGROUP= und
   PREFERRED SERVER=). Nachteile sind dadurch nicht aufgefallen, sofern der
   Server vorher in Wahrheit doch korrekt geladen wurde (laut seiner eigenen
   Startmeldung). Trotzdem, hat jemand eine Lösung?

   Übrigens: Wie oben schon angedeutet, ist das xxx in der ID der Fehler-
   meldung variabel und entspricht der VLM-Versionsnummer.
   Wenn Sie die entsprechenden Fehlermeldungen im DOSBOOK Anhang E suchen,
   müssen Sie unter "modul-version-nummer" suchen (wobei hier modul=VLM,
   version=1.00 und nummer=47 wäre). 1.00 entsprach dem Stand der VLMs in
   den Beta-Versionen von Novell DOS 7 und PNW.

   Die Netzwerk-Software, die mit PNW 1.0 und Novell DOS 7 mitgeliefert
   wurde, entspricht der Ebene von VLM 1.10. Mittlerweile wurden manche
   PNW-Dateien upgedated (P10G05.EXE) und insbesondere die allgemeine
   Netzwerk-Software mit der Herausgabe von NetWare 4.10 stark aktualisiert.
   Es empfiehlt sich daher dringend, die Dateien aus dem Archiv VLMUP4.EXE
   in die PNW-Client- und Server-Konfiguration einzuarbeiten. Noch besser
   und aktueller geht es mit VLMKT_1.EXE - VLMKT_6.EXE bzw. dem neueren
   VLM121_1.EXE - VLM121_6.EXE, womit die VLMs auf die Software-Ebene 1.20B
   bzw. 1.21 angehoben werden. Dabei sind allerdings einige Dinge zu be-
   achten und es ist leider nicht in jedem Fall gewährleistet, daß man die
   Updates einfach über die alten Dateien kopieren kann.
   Trotzdem ist dies meistens dennoch möglich, wenn man die dem Paket
   beiliegenden ausführlichen Hinweise beachtet (seit kurzem gibt es auch
   ein speziell für PNW konfektioniertes Update-Paket von Novell, Näheres
   siehe Kapitel I.2). Um die Fehlermeldung zu vermeiden, daß man eine alte
   Version einer Message-Datei .MSG verwendet, kann man die entsprechende
   Datei aus dem Unterverzeichnis \NWCLIENT\NLS\ENGLISH\ in das Verzeichnis
   \NWCLIENT\NLS\DEUTSCH\ kopieren, bis deutsche Versionen dieser Dateien
   erhältlich sind (ist mit dem VLM-Kit allerdings der Fall für Deutsch,
   Englisch, Spanisch, Italienisch und Portugisisch).


   Was die Benennung von Ressourcen im Netz angeht, sollte man sich vorher
   Konventionen überlegen, um so später eindeutig zwischen Servern,
   Benutzern, Arbeitsgruppen, Laufwerken, Verzeichnisbäumen, Druckern,
   Queues, Formularen usw. unterscheiden zu können.
   Dazu können die Namen den Typ der Ressource enthalten, indem sie jeweils
   auf einer bestimmten Buchstabenkombination enden, z.B.:

    _PC  für Server
    _GRP für Arbeitsgruppen (oder _NET bei PNW)
    _DRV für Laufwerke
    _PRN für Drucker

   Obwohl dabei mehr als 8 Zeichen erlaubt sind, empfiehlt sich dies aus
   kosmetischen Gründen nicht, da für mehr als 8+3 Zeichen innerhalb des
   versteckten Verzeichnisses \NWCNTL\ gleich mehrere ineinander ver-
   schachtelte Unterverzeichnisse eingerichtet werden, um die Überlänge im
   Namen irgendwo unterzubringen (wegen der 8.3 Namenskonventionen von DOS).
   Dies kann bei manuellen Wartungsarbeiten äußerst störend sein.


   Möchten Sie einen PNW-Server als 'Dedicated Workstation' betreiben?

   In diesem Fall kann u.U. die Performance verbessert werden, wenn Sie
   - am besten in STARTNET.BAT direkt nach dem Aufruf von SERVER - ein
   kleines Tool von NetWare Lite laden: DEDICATE.COM.
   Dieses Progrämmchen macht nichts weiter, als in einer Schleife permanent
   INT28h-Calls abzuschießen (DOS IDLE) und dabei ab und zu die Tastatur
   abzufragen, ob denn eine Taste zum Beenden des Programms gedrückt wurde.
   Ich habe nicht überprüft, ob dies bei PNW wirklich noch notwendig ist,
   bei alten DOS-Versionen könnte es aber von Vorteil sein. Eines steht
   jedenfalls fest: Schaden kann es nicht, wenn Sie den Rechner sowieso
   nicht benutzen (außer eben als PNW-Server). Wenn Sie in Besitz einer
   NetWare Lite Lizenz sind, können Sie das Tool z.B. aus dem Update
   NWL11G.EXE beziehen, andernfalls kann es in wenigen Minuten auch
   selbst geschrieben werden.

   Wird DEDICATE.COM direkt nach Server geladen, hat dies noch einen
   weiteren Vorteil (den man aber auch anders erreichen kann). Solange
   man den Rechner wirklich nur als Server benötigt, wird auch VLM.EXE
   (inkl. seiner .VLMs) noch nicht geladen. Dadurch steht mehr Speicher
   für den hoffentlich geladenen NWCACHE zur Verfügung. Muß man diesen
   Rechner nun doch als 'Non-Dedicated Server' nutzen, braucht man nur
   eine Taste zu drücken: DEDICATE wird beendet, VLM wird geladen und
   man kann sich ins Netz einloggen.
   Für Netzwerk-Anfänger: VLM wird nicht benötigt, wenn Sie den Rechner
   nur als Server benötigen; SERVER wird nicht benötigt, wenn Sie den
   Rechner während einer Session nur als Workstation nutzen! Da insb. der
   SERVER die Performance sehr stark drosselt, sollte er in diesem Fall
   tunlichst nicht geladen werden!

   Arbeitet man immer im Netz und benötigt die Entlademöglichkeit der
   Netztreiber nicht, kann man sowohl die Treiber der IPX-Schicht (bei
   Personal NetWare also LSL.COM, MLID-Hardware-Treiber wie z.B. NE2000.COM,
   sowie IPXODI.COM), als auch den SERVER.EXE per INSTALL[HIGH]= bereits in
   CONFIG.SYS laden, was die Chance zum Hochladen erhöht. VLM.EXE kann
   leider nicht in CONFIG.SYS geladen werden (auch nicht mit INSTCDEX.EXE).

   Übrigens:

   Es ist zwar nicht möglich, VLM.EXE oder SERVER.EXE erst innerhalb eines
   Task des multitaskenden TASKMGR zu laden, sehr wohl funktioniert dies
   jedoch auf einem Novell DOS 7 System in einer DOS-Box im Erweiterten
   386er-Modus von Windows 3.1x (die üblichen zu PNW gehörigen Netztreiber
   für Windowas waren geladen; wahrscheinlich sind sie aber gar nicht mal
   notwendig - nicht überprüft)! Bei meinen Experimenten konnte VLM.EXE
   die Module NMR.VLM und FIO.VLM nicht laden und der SERVER.EXE kein DPMS
   nutzen (was ein paar Probleme bereitet, z.B. stürzt der Server während
   der Ladephase schon mal ab, wenn DPMS durch CLOAKING bereit gestellt
   wird, nicht aber, wenn man CLOAKING über DPMS lädt, siehe Kapitel II.4.),
   ansonsten arbeitete das System stabil. Natürlich ist dies nicht die von
   Novell empfohlene Betriebsart und man ist verschiedenen Einschränkungen
   unterworfen und sollte immer im Hinterkopf behalten, welche impliziten
   Auswirkungen diese Konstallation hat.

   Trotzdem eröffnet sich dadurch eine ganz neue Perspektive:

   Der Nachteil, daß die Netzverbindung ausschließlich in der einen
   DOS-Box genutzt werden kann, wird dadurch aufgewogen, daß in den
   anderen DOS-Boxen überhaupt kein Speicher für die Netzverbindung
   benötigt wird. In der Regel hat man also 50 - 150 KByte mehr freien
   Speicher! Arbeitet man sowieso nicht mit Netzapplikationen (wie in
   der Praxis beim Einsatz von Personal NetWare gerade häufig der Fall),
   so wird die Netzverbindung in erster Linie nur zum schnellen Daten-
   austausch genutzt. Dafür reicht aber gerade auch die Verbindung in
   *einer* DOS-Box prima aus... Daß der Server in dieser Konstellation
   als ein Task unter mehreren natürlich eine wesentlich geringere
   Performance hat, kann auch ein Vorteil sein. So läßt sich nämlich
   in anderen Tasks fast ohne Geschwindigkeitseinbußen arbeiten. Wird
   der Server global geladen, wird sonst die Weiterarbeit auf langsamen
   Server-Rechnern (z.B. 386sx16) zur Qual...

   Sollten Sie regelmäßig mit dieser Sonderlösung arbeiten wollen,
   ist es praktisch, sich dafür eine spezielle DOS-Box vorzudefinieren,
   die automatisch die Netztreiber lädt, indem Sie im PIF-Editor als
   Aufrufparameter z.B. für PNWPRMPT.PIF angeben:

    Programm       : %ComSpec%
    Aufrufparameter: /K c:\nwclient\startnet.bat

   Sogar das Problem mit DPMS und CLOAKING läßt sich hier abfangen,
   wenn Sie STARTNET.BAT ein bißchen erweitern (es wird eine Überprüfung
   benötigt, ob Windows gerade läuft) und eine zusätzliche Abfrage ein-
   bauen, ob das Gerät DPMS installiert ist:

    IF NOT EXIST \dev\DPMSXXX0 GOTO error

   oder - je nachdem -:

    IF EXIST \dev\CLOAK$$$ GOTO error

   Die Ikone für PNWPRMPT.PIF können Sie natürlich auch in die AutoStart-
   Gruppe aufnehmen...

   Noch etwas: Die Treiber der IPX-Schicht können sehr wohl unter dem
   multitaskenden TASKMGR in einem Task geladen werden. Für Programme
   (wie FASTLYNX), die nur diese untere Protokollschicht nutzen, kann
   man diesen Trick also auch unter dem multitaskenden TASKMGR nutzen,
   siehe Kapitel II.8.

                                                                             
  ---------------------------------------------------------------------------

  VI.3. Mehrere PNW-Server in einem Netz: [97-01-04]
  ==================================================

   Stichworte: NetWare, PNW, Bindery, Arbeitsgruppe, NET ADMIN, Ressourcen

   Es ist - im Gegensatz zu den großen NetWare-Versionen - bei PNW möglich,
   auch mit nur *einer* gekauften Version mehrere Server am gleichen Netz
   und in der gleichen Arbeitsgruppe ans Laufen zu bringen (dies verletzt
   allerdings wohl i. allg. die Lizenz - PNW sollte entsprechend häufig
   lizensiert werden) (ein Server kann allerdings nur gleichzeitig in einer
   Arbeitsgruppe angemeldet sein). Die 'Bindery' (oder eher Konfigurations-
   datenbank, PNW besitzt diesbezüglich eine andere Organisationsform als
   die große NetWare: eine Distributed Object Database (DOD)) wird dabei
   nicht zerschossen, wenn man wie folgt vorgeht:

   Jeder Server wird einzeln installiert (ohne, daß eine Verbindung
   zwischen den Rechner besteht) und für jeden Server wird die gleiche
   Arbeitsgruppe eingerichtet (also *nicht* eine bereits auf einem anderen
   Server vorhandene Arbeitsgruppe übernehmen). Dann werden alle Server
   'hochgefahren' und in ihrer Arbeitsgruppe angemeldet (PNW fragt nach,
   welche Arbeitsgruppe gemeint ist, wenn mehrere Gruppen mit dem gleichen
   Namen existieren, jede Arbeitsgruppe läßt sich jedoch trotzdem eindeutig
   zuordnen). Danach loggt man sich ein und startet NET ADMIN, dort wird
   dann die eigene Arbeitsgruppe gelöscht und der Server in die gleich-
   namige Arbeitsgruppe eines anderen Servers verschoben. Die Ressourcen
   sollte man dabei *nicht* übernehmen! Schließlich hat man alle Server
   in der gleichen und i. allg. auch einzigen Arbeitsgruppe versammelt.

   Es ist gut möglich, daß es auch andere Möglichkeiten für dieses Unter-
   fangen gibt.

                                                                             
  ---------------------------------------------------------------------------

  VI.4. PNW Login-Skripte in Multi-Konfigurationen:
  =================================================

   Stichworte: PNWLOGIN.SCR, NET, Umgebungsvariablen, 4DOS

   Benutzer von Multi-Konfigurationen (auch über mehrere Rechner hinweg)
   sollten beim Erstellen von Login-Skripten (Dateien im versteckten
   Verzeichnis C:\NWCNTL\MAIL\xxxxxxxx\PNWLOGIN.SCR) sehr vorsichtig
   sein!

   Wenn man mit NET verschiedene Einstellungen vorgenommen hat und diese in
   seiner Login-Skript speichern will, werden dabei nicht nur die Laufwerk-
   Mappings und Druckerzuordnungen gespeichert, sondern auch die aktuelle
   Umgebung. Arbeitet man nun mit einer anderen Konfiguration als der,
   unter der das Login-Skript erstellt wurde, werden beim Einloggen die
   Variableneinstellungen der falschen Konfiguration wiederhergestellt, was
   je nach Raffinesse der Konfiguration sehr weitreichende Folgen haben
   kann. Besonderen Augenmerk verdienen die Variablen %ComSpec%, %CONFIG%
   und %Path% in den jeweiligen Dateien PNWLOGIN.SCR. Sie sollten vorher mit
   einem REM markiert werden. Für die meisten Fälle wird es am besten sein,
   alle SET Einträge aus den PNWLOGIN.SCR Dateien zu entfernen, damit keine
   ungewünschten Interferenzen auftreten können.

   Beispiel:

   Eine Multi-Konfiguration arbeitet wahlweise mit 4DOS.COM oder COMMAND.COM
   als Kommandoprozessor. Hat man das Login-Skript unter der 4DOS-Konfigura-
   tion erstellt, wird auch dann die Einstellung %ComSpec%=...\4DOS.COM beim
   Login gesetzt, wenn man im Moment lediglich unter COMMAND.COM arbeitet.
   Die Folge ist, daß der Rechner nach Beenden des ersten größeren Pro-
   gramms, das nach dem Einloggen gestartet wurde, mit einer Fehlermeldung
   stehen bleibt (weil der transiente Teil von COMMAND.COM - über %ComSpec%
   referenziert - nicht mehr nachgeladen werden kann).

                                                                             
  ---------------------------------------------------------------------------

  VI.5. NETWARS als Netzanalyse-Werkzeug: [96-05-09]
  ==================================================

   Stichworte: Netzwerk-Hardware, NETWARS, ODI, VLM, SERVER, COMCHECK

   Häufig können schon bei der Hardware-Installation eines Netzes unent-
   deckte Fehler auftauchen, die verhindern, daß die PNW-Software sauber
   arbeiten kann. Ist bereits ein grundlegendes Netz hochgezogen (d.h. die
   ODI-Treiber (ausgenommen VLM und SERVER) sollten geladen sein), kann man
   versuchen, mit dem Spiel NETWARS über das Netz zu mehreren Spielern zu
   spielen (alle Spieler müssen das gleiche 'Universum' wählen). Sollte dies
   gelingen und man tatsächlich feindliche Schiffe - durch die anderen
   Benutzer gesteuert - entdecken, liegt der Fehler mit ziemlicher Sicher-
   heit nicht in der Hardware-Konfiguration, d.h. die Netzadapterkarten und
   die Verkabelung arbeiten sauber, ebenso sind die ODI-Treiber über NET.CFG
   richtig eingestellt.

   Ebenfalls hilfreich für grundlegende Analysen am Netz ist das Utility
   COMCHECK.EXE aus dem Archiv COMCHK.EXE.

                                                                             
  ---------------------------------------------------------------------------

  VI.6. PNW und Dateiattribute: [96-05-05]
  ========================================

   Stichworte: PNW, ATTRIB, Kopieren, System-Attribut, Read-Only-Attribut,
               Client, Server

   i. PNW und Dateiattribute von DOS:
   ----------------------------------

   Gegenüber der großen NetWare benutzt PNW das Dateisystem von DOS.
   Entsprechend sind auch nur die vier üblichen Attribute auf Dateien
   und (wie meist nicht bekannt) Pfade anwendbar: Archiv A, Read-Only R,
   Hidden H und System S (für interne Zwecke gibt es noch zwei Bits mehr:
   Volume V und Directory D). Mit PASSWORD gibt es offiziell noch drei
   'Attribute' (hier Zugriffsrechte) mehr, Multiuser-Varianten verwenden
   noch weitere 'Attribute' (siehe PASSWORD, Kapitel II.4.). Besitzt eine
   Datei allerdings mit PASSWORD vergebene eingeschränkte Zugriffsrechte,
   so kann von entfernten Rechnern nur soweit darauf zugegriffen werden,
   wie dafür kein Paßwort erforderlich ist. Die Übermittlung von Datei-/
   Verzeichnispaßwörtern über das Netz ist nicht möglich.

   Daher sind die Möglichkeiten, den Zugriff auf Dateien zu steuern gegen-
   über der großen NetWare ziemlich beschränkt, für kleinere Netze reichen
   diese Optionen jedoch aus. Die Funktion der Attribute entspricht im
   Prinzip der Funktion unter DOS, allerdings gibt es ein paar Besonder-
   heiten:

   - Read-Only-Attribut erlaubt Mehrfachzugriff:

   By the way: Viele (vor allem ältere) Programme benutzen Methoden, Dateien
   zu öffnen, die in Netzen dazu führen, daß die Datei auch im Lesezugriff
   nur von einem Programm gleichzeitig geöffnet werden kann (gerade, wenn
   ein Benutzer sowieso nur Read-Only-Rechte auf einem PNW-Server hat). In
   diesem Fall hilft es meist, daß Read-Only-Attribut der Datei zu setzen,
   sowohl bei ausführbaren Dateien, als auch bei Datendateien (wenn diese
   nicht verändert werden müssen, z.B. wie diese Textdateien...) Hat der
   Benutzer jedoch Lese- und Schreibrechte funktioniert dies nicht immer...


   ii. Mit PNW Systemdateien über's Netz löschen:
   ----------------------------------------------

   Mit PNW ist es auf den ersten Blick nicht möglich, Dateien zu löschen,
   die auf einem Server das System-Attribut gesetzt haben, bzw. vom Client
   aus solche Dateien per Kopieraktion upzudaten. Wenn man das dennoch
   möchte, muß man zuerst diese Attribute mit ATTRIB löschen, danach können
   die Dateien ganz normal bearbeitet werden.

   Umgekehrt ist es aber sehr wohl möglich, Dateien, die auf dem Client
   mit dem System-Attribut versehen sind, mit Dateien eines Servers zu
   überschreiben.

                                                                             
  ---------------------------------------------------------------------------

  VI.7. Tips für Paßwörter:
  =========================

   Stichworte: Paßwörter, Sicherheit, MS-DOS, PASSWORD, SECURITY, NetWare,
               PNW

   Unter Novell DOS kann man in vielen Situationen Paßwörter angeben.
   Da die Datei-, Pfad- und globalen Paßwörter sich sehr leicht (durch
   Booten unter MS-DOS) ausschalten lassen, sind sie - einzeln genommen -
   eher sinnvoll, um das versehentliche Löschen, Umbenennen oder Modifi-
   zieren wichtiger oder fremder Dateien zu verhindern (mehr dazu in
   Kapitel II.4. bei PASSWORD und SECURITY.OVL). In Verbindung mit einem
   Systempaßwort, das beim Booten abgefragt wird, wird jedoch der Schutz
   vor unberechtigtem Zugriff schon wesentlich verbessert (allerdings
   läßt sich auch dieser Schutz mit einigem Aufwand und evtl. partiellem
   Datenverlust aushebeln).

   Dadurch wird auch die sinnvolle Namenswahl für die Datei- und Ver-
   zeichnispaßwörtern und des globalen Paßworts, das mit dem Anmelde-
   paßwort korrellieren kann, wichtig.

   In Verbindung mit den Novell-Netzen (speziell PNW) wird die Angabe
   von Paßwörtern besonders wichtig. Der hier gebotene Schutz ist sehr
   umfassend (wenn der direkte Zugang zu einem Server verhindert wird,
   etwa indem er in einem gesicherten Raum steht) und im Prinzip nicht
   ausgehebelt werden (wenn bestimmte Voraussetzungen gelten). PNW stellt
   insofern eine gewisse Ausnahme da, als daß durch die Eigenart eines
   Peer-to-Peer-Netzes meist der direkte Zugang zum PC erlaubt ist, aber
   grundsätzlich sind die Paßwortmechanismen genauso sicher bei der
   'großen' NetWare.

   Novell DOS erlaubt ein spezielles Feature der 'einmaligen Anmeldung'
   (One-Time-Login), das nach Angabe des Benutzernamens und Paßwortes den
   Zugriff auf den lokalen Rechner und die zugehörigen Netzverbindungen
   erlaubt.

   Deshalb sollte man bei der Angabe von Paßwörtern verschiedene Grundregeln
   beachten:

   - Der Benutzer muß sich auch nach längerer Zeit an sein Paßwort erinnern
     können (diese Aussage ist besonders wichtig für den SUPERVISOR des
     Netzes).

   - Das Paßwort sollte nirgendwo notiert werden (oder wenn, dann nur so,
     daß der Zugriff durch andere Personen sicher verhindert wird (Tresor).
     Also nicht in der Schreibtischschublade, neben dem Monitor, neben der
     Tastatur!!!)

   - Das Paßwort sollte kein Wort sein, das jemand anderen leicht erraten
     werden kann, also nicht der zweite Vorname, das Geburtsdatum, der Namen
     von Verwandten, der Freundin...

   - Das Paßwort sollte nicht zu lang sein, daß man es sich nicht mehr
     merken kann (und doch irgendwo notiert). Die maximale Länge von Datei-,
     Verzeichnis-, und globalen Paßwörtern beträgt 8 Zeichen, die NetWare-
     Paßwörter bis zu 12 Zeichen.

   - Das Paßwort sollte auch nicht zu kurz sein, daß es durch wenige Ver-
     suche erraten werden kann (also mindestens 5 Zeichen lang).

   - Bei wichtigen Accounts sollte das Paßwort kein Wort sein, das in
     einem Lexikon oder Duden vorkommt, da es sonst durch sukzessives
     Ausprobieren geknackt werden kann (es gibt Programme, die soetwas
     automatisch machen). Also stattdessen zusammengesetzte Wörter,
     Phantasiewörter oder Kombinationen von Buchstaben und Zahlen.

   - In einem Paßwort sollten normalerweise nur Ziffern und Buchstaben
     vorkommen, keine Sonderzeichen oder Umlaute, da diese u.U. bei
     zukünftigen Software-Versionen nicht mehr akzeptiert werden könnten
     (und man sich dann nicht mehr einloggen kann).

   - Manchmal problematisch sind Paßwörter, die 'Y' oder 'Z' enthalten,
     da diese Buchstaben bei der deutschen Tastaturbelegung von der
     amerikanischen Belegung abweichen und es durch eine Software-Änderung
     oder Umkonfiguration vorkommen kann, daß zum Zeitpunkt der Paßwort-
     eingabe keine deutsche Tastatur unterstützt wird (etwa wenn kein
     Tastaturtreiber geladen ist oder während der Systemanmeldung bei einem
     amerikanischen Update für Novell DOS). In diesem Fall würden 'Y' und
     'Z' vertauscht und man könnte sich nicht einloggen. Die Ursache einer
     falschen Tastaturanpassung wird häufig übersehen (weil sie so unwahr-
     scheinlich ist und weil die Paßworteingabe verdeckt erfolgt), gerade
     mit dem Feature der einmaligen Anmeldung (und damit noch vor dem Laden
     eines Tastaturtreibers) ist dies sehr wichtig, wenn man sich später
     unter anderen Bedingungen einloggen möchte.

   - In gewissen Zeitabständen sollte man die Paßwörter (zumindest bei
     NetWare) ändern, damit die Wahrscheinlichkeit des Erratens minimiert
     wird. NetWare (auch PNW) erlaubt hier recht umfangreiche Einstellungs-
     möglichkeiten: minimale Paßwortlänge, forcierter Paßwortwechsel in
     einstellbaren Zeitabständen oder bei einem definierbarem Datum,
     automatisch ablaufende Accounts, die erst wieder freigeschaltet
     werden müssen, Abwehr von Eindringversuche durch Zeitschranken
     zwischen falschen Paßworteingaben oder gesperrte Accounts nach einer
     gewissen Anzahl von falschen Einlog-Versuchen. Außerdem die Angabe,
     zu welchen Zeiten man sich überhaupt nur einloggen darf, usw.

                                                                             
  ---------------------------------------------------------------------------

  VI.8. PNW ohne Novell DOS 7 installieren:
  =========================================

   Stichworte: PNW, SETUP, SETUP2, INSTALL

   Möchten Sie nur den PNW-Teil von Novell DOS 7 installieren, reicht es
   aus, die Novell DOS 7 Disketten auf die Festplatte zu kopieren und die
   Datei SETUP2.EX_ mit PNUNPACK zu entpacken und in SETUP.EXE umzunennen.
   Nach dem Aufruf kann man PNW ohne Novell DOS 7 installieren (denn SETUP2
   übernimmt die Feineinstellung und die Installation einzelner Features
   wie PNW, Security etc. wohingegen INSTALL das Grundsystem bootfähig
   macht). Weitere Hinweise zu INSTALL/SETUP gibt es in Kapitel I.2. .

   Bei Novell kann ein kostenloses Paket D72PNW.EXE (Lesart "DOS 7 'to'
   PNW") bezogen werden, das aus den 3,5" Original-Installationsdisketten
   ein einzeln installierbares PNW-System generiert. Diese Lösung ist
   natürlich der obigen 'Do-it-Yourself'-Methode vorzuziehen.

                                                                             
  ---------------------------------------------------------------------------

  VI.9. Hinweise zu NET.EXE: [97-01-04]
  =====================================

   Stichworte: PNW, NET.EXE

   Die Benutzeroberfläche von PNWs NET.EXE läßt sich genauso wie die
   Novell DOS Programme konfigurieren.

   Die folgenden Möglichkeiten sind undokumentiert:

   Die Konfiguration des Benutzer-Interfaces wird der Datei
   %NWDOSCFG%\NWDOS.INI entnommen. Nur wenn diese Datei nicht existiert,
   wird alternativ die Datei %NWDOSCFG%\COLORS.INI (bzw. COLORS.INI)
   ausgewertet. (Leider ist die Priorität nicht umgekehrt, was noch etwas
   mehr Flexibilität ermöglichen würde.)
   Innerhalb dieser Datei wird - falls vorhanden - die Gruppe [NET] nach
   den Direktiven

    NewUI=on|off
    CurrentColor= (Palettennummer 0..9)

   durchsucht, falls diese Gruppe nicht existiert, wird die Default-
   Einstellung für NewUI= und CurrentColor= aus der Gruppe [COLORS]
   gewählt. Dort sind auch die einzelnen Farbpaletten mit ColorSetX=
   Direktiven definiert (X=<CurrentColor> aus 1..9, Näheres siehe Kapitel
   II.4.).

   Außerdem wertet NET.EXE bei Bedarf für den integrierten Editor auch
   noch die Gruppe [EDITOR] (Kapitel II.4.) aus und entnimmt ihr ebenfalls
   NewUI= und CurrentColor=.

   In der NET.CFG Datei werden von NET.EXE die folgenden Direktiven

    NETWARE DOS REQUESTER
      PREFERRED WORKGROUP=<workgroup name>; (offenbar statt WORKGROUP NAME=)
      WORKGROUP NET=<workgroup net address>
      BROADCAST RETRIES=<2>            ; 0..255
      BROADCAST TIMEOUT=<3>            ; 1..255
      BROADCAST SEND DELAY=<0>         ; 0..255

   ausgewertet (siehe Kapitel VI.12.).

   Sollte der in NET.EXE integrierte DOS-Extender??? (RTLink/Plus) Probleme
   mit der Speicherverwaltung bekommen, kann er mit verschiedenen
   Umgebungsvariablen konfiguriert werden: Die Verwendung einer bestimmten
   Speichersorte für ein bestimmtes Modul wird dabei durch den Wert 0 de-
   aktiviert. Mögliche Variablen sind (vgl. bei SETUP.EXE in Kapitel II.4.):

    VM-Manager:      RTVMEXT, RTVMEXP, RTVMCONV
    Overlay-Manager: RTOVEXT, RTOVEXP, RTOVCONV


   NET.EXE kann man auch als SHELL für eine Reihe Dienstprogramme be-
   trachten, die bei der großen NetWare als externe Tools vorliegen.
   Über Aufrufparameter lassen sich nahezu alle (und noch einige andere)
   Möglichkeiten der Oberfläche auch direkt aus Batchjobs heraus abwickeln,
   z.B. in Login-Skripten oder für Wartungsjobs. Im Fehlerfall liefert
   NET.EXE dabei Errorlevel größer 0 zurück, so daß man in Batchjobs mit

    IF ERRORLEVEL 1 GOTO error

   auf Fehlerzustände überprüfen kann.

   NET.EXE unterstützt noch eine Reihe zusätzlicher Parameter, die nicht
   oder nur unvollständig im DOSBOOK oder in der eingebauten Parameterhilfe
   (NET /? oder NET /? thema) dokumentiert sind:

    NET ATTACH  wie NET CONNECT (d.h. siehe NET /? CONNECT)
    NET CAPTURE nur im DOSBOOK dokumentiert sind die zwei Schalter:
                S=name zur Angabe eines Initialisierungszeichenkette, die
                       vor einem Ausdruck an den Drucker gesendet wird.
                       Der Standard S=default schickt keine zusätzliche
                       Sequenz ab.
                W=time zur Angabe der Wartezeit, die einen abgeschickten
                       Druckjob auch ohne explizite Beendigung beendet,
                       so daß einzelne Druckjobs, die in genügend großen
                       zeitlichen Abständen eintreffen, automatisch von-
                       einander getrennt behandelt werden. Werden Druck-
                       aufträge zu früh abgeschnitten, muß diese Wartezeit
                       erhöht werden.
    NET CASTON  Diese beiden Schalter erlauben das Aktivieren oder Unter-
    NET CASTOFF drücken von eintreffenden Meldungen. Falls aktiv, werden
                eingehende Meldungen mit einer Message angekündigt. In
                manchen Fällen kann dies sehr störend sein oder Probleme
                verursachen, da die Abarbeitung der Applikation ohne
                Timeout solange aussetzt (nachteilig bei unbemanntem
                Betrieb, z.B. über Nacht). Auch nicht netztaugliche Grafik-
                programme (z.B. PC DRAFT) bereiten schon 'mal Probleme,
                weil die Meldung im Grafikmodus nicht angezeigt wird aber
                trotzdem bestätigt werden muß. Viele Benutzer kommen dann
                nicht auf die Idee, 'blind' <Ctrl>+<Enter> zu drücken und
                halten die Anwendung für abgestürzt (siehe PCDTIPS.TXT).
   NET DETACH   Hiermit kann gezielt die Verbindung zu einem bestimmten
                Server aufgehoben werden und wirkt damit gegenteilig wie
                NET ATTACH alias NET CONNECT. Obwohl undokumentiert,
                existiert eine eingebaute Hilfe: NET /? DETACH, auf die
                man nur durch Zufall stoßen muß...
   NET MAP DEL  Diese Option ist nur in der eingebauten Hilfe NET /? MAP
                dokumentiert.
   NET RIGHTS DEL  kann statt NET RIGHTS DELETE verwendet werden.
   NET USER    wirkt exakt wie NET und startet die Benutzer-Oberfläche.

   Sollten Sie Probleme mit NET.EXE haben, ist für Sie vielleicht
   interessant, daß das derzeitige Archiv PNWUPD.EXE (05/1996) eine
   aktuellere Version (1.05), als das PNW-Update 5 P10G05.EXE enthält
   (1.03).


   Noch ein kleiner Hinweis am Rande (wenn auch etwas aus des dem
   Zusammenhang):

   .VLM-Dateien, die zu .EXE umbenannt und direkt, statt über VLM auf-
   gerufen wurden, kehren sofort mit Fehlercode 6 zurück.

                                                                             
  ---------------------------------------------------------------------------

  VI.10. Hinweise zur Universal Naming Convention (UNC): [96-03-26]
  =================================================================

   Stichworte: PNW, UNC, MAP, Capture

   Die Universal Naming Convention gliedert die unterschiedlichsten Netz-
   ressourcen in Form eines Verzeichnisbaums, bei der man am Anfang den
   Server angibt, der die Ressource bereitstellt, und dann den Namen der
   Ressource spezifiziert. Bei weiterer Unterteilung dieser Ressource
   (bei Laufwerken etwa Unterverzeichnisse) ist auch die Angabe von
   Pfaden möglich.

   Neben der üblichen Methode, entfernte Laufwerke über ihre Drive-Mappings
   (MAP, NET MAP) anzusprechen, bietet die UNC also eine manchmal sinn-
   vollere Möglichkeit, weil man die Ressource 'physikalisch' benennen kann
   und nicht wie sonst über den Umweg einer 'relativen' Substitution.
   Allerdings werden die Pfadangaben dadurch auch länger und manchmal ist
   es gerade wünschenswert, 'relative' Konfigurationen zu erstellen.

   Laut Novell dürfen die Pfade unter DR DOS 6.0 und Novell DOS 7 für
   lokale Ressourcen bis zu 128 Zeichen lang sein, ansonsten gilt die
   übliche DOS-Beschränkung für maximale Pfadlängen von 67 Zeichen
   (ausprobiert habe ich dies nicht).

   Syntax:                (SERVER ist der vergebene Name für die Netz-
                          ressource SERVER, und VOLUME der für ein Laufwerk,
                          d.h. nicht der Volume-Name, den man mit LABEL
                          einstellen kann.)

    SERVER/VOLUME:DIR\    über MAP oder SUBST an ein logisches Laufwerk
                          gekoppelt. Statt des '/' kann auch '\' geschrieben
                          werden. Klappt immer!
    SERVER\VOLUME:DIR\    direkte Angabe (klappt unter 4DOS und Novells
                          COMMAND.COM immer mit Laufwerken, offenbar aber
                          auch mit anderen Ressourcen wie Druckerports.
    \\SERVER\VOLUME\DIR\  entsprechend UNC (klappt ebenfalls fast immer,
                          zumindest unter 4DOS und COMMAND.COM)

   Beispiele: (PNWSRV1_DRV1 sei ein Netzlaufwerk)

    DIR pnwsrv1_pc\pnwsrv1_drv1:\
    DIR \\pnwsrv1_pc\pnwsrv1_drv1\

   Wie angesprochen, kann statt des VOLUME bei UNC allgemein auch eine
   andere Ressource genannt werden. DOS bietet hier vergleichsweise ein-
   geschränkte Möglichkeiten, soweit diese Ressourcen aber auch unter DOS
   quasi wie Dateinamen angegeben werden konnten (und können), sollte die
   Angabe entsprechend UNC möglich sein (Namen von Block-Devices werden bei
   DOS bekanntlich fast wie Dateinamen behandelt).
   Ist PNWPRN1_LPT1 eine Ressource, die einen Druckerport auf dem Server
   PNWSRV1_PC darstellt, sollten also Angaben wie

    DIR *.* > \\pnwsrv1_pc\pnwprn1_lpt1\

   erlaubt sein, d.h. man könnte auf das Capturen des Ports auf dem lokalen
   Rechner verzichten (allerdings funktionierte diese Methode bei meinen -
   zugegeben bisher nur flüchtigen - Tests mit einem separaten PNW-Netz
   (VLMUP4) nicht. Es erschien die Fehlermeldung: Netzwerkfehler 071).
   Ohne geladene Netzshell (NETX bzw. VLM) sind derartige Zugriffe ver-
   ständlicherweise (prinzipiell) nicht zulässig.

   Bezüglich Einschränkungen und Änderungen im Laufe der Versionsgeschichte
   von COMMAND.COM und .VLM-Updates sei auch auf die HISTORY.TXT Datei aus
   den Novell DOS 7 Updates verwiesen.

                                                                             
  ---------------------------------------------------------------------------

  VI.11. PNW-Server und Sharing von Wechselmedien: [96-04-14]
  ===========================================================

   Stichworte: Floppy-Sharing, CD-ROM-Sharing, Drucker-Sharing

   Richtet man einen PC als PNW-Server ein, muß man sich u.a. entscheiden,
   welche Laufwerke man 'shareable' machen möchte, d.h. anderen Client-
   Rechnern zur Verfügung stellen will.
   Dabei sollte man - von Ausnahmen abgesehen - darauf achten, nur solche
   Ressourcen zu teilen, die immer verfügbar sind (oder es zumindest
   bleiben, nachdem sich ein Benutzer eines Clients einloggen konnte).
   Dazu zählen in erster Linie Festplatten, wo es nur selten Probleme gibt.

   Kritisch ist das 'Teilen' von Floppies, da ein Client normalerweise
   nicht sicherstellen kann, daß auf dem Server eine Diskette eingelegt ist.
   Greift man trotz nicht eingelegter Diskette auf ein Floppy-Laufwerk zu,
   so erscheint im günstigsten Fall nach kurzer Zeit eine Fehlermeldung auf
   dem Client. Es ist aber auch möglich, daß die DOS-Fehlermeldung "Abbruch,
   Wiederholen, Ignorieren" auf dem Server erscheint, der vielleicht in
   diesem Moment gar nicht besetzt ist oder wo jemand gerade eine wichtige
   Berechnung in einer Applikation durchführt...
   Besonders unangenehm fallen hierbei die 5,25" Floppy-Laufwerke auf:
   Aufgrund ihrer Mechanik ist es möglich, eine Diskette zwar einzulegen,
   die Laufwerksklappe aber nicht zu schließen. Die Mehrzahl der Laufwerke
   (auch von Markenherstellern) können diese Situation nicht als "Keine
   Diskette eingelegt" erkennen, sondern nur als "Diskette eingelegt,
   Zugriff nicht möglich". In diesem Fall ist mit extrem langen Wartezeiten
   beim Zugriff auf ein solches Laufwerk zu rechnen, bis DOS oder die
   Applikation es aufgibt, auf das Laufwerk zuzugreifen.
   All dies wäre noch erträglich, wenn man sicherstellen könnte (und würde),
   daß nur dann (bewußt) auf ein Floppy-Laufwerk zugegriffen wird, wenn auch
   ein Medium eingelegt ist. Leider ist dem nicht so: Sehr viele Programme
   (z.B. viele Utilities der Norton Utilities oder der PC-Tools, aber auch
   MS Windows und Netzanalyse-Programme) greifen beim Start auf jedes ver-
   fügbare Laufwerk zu, um den aktuellen Status einzuholen. Auf diese Weise
   werden auch die entfernten Laufwerke 'durchgescannt'. Sind Floppy-
   Laufwerke darunter, tritt das oben beschriebene Szenario in Kraft, und
   zwar in den allermeisten Fällen, ohne daß man die Möglichkeit hätte,
   dies zu umgehen. Nur sehr wenige Programme (etwa PROSHELL) lassen es zu,
   daß man in der Konfigurationsdatei angibt, ob und wenn welche Laufwerke
   gescannt werden dürfen.

   Ähnliche Situationen können sich auch mit CD-ROM-Laufwerken, Wechsel-
   festplatten, bestimmten intelligenten Streamern oder zur Laufzeit in
   der Größe verstellbaren RAM-Disks (wie etwa TDSK) ergeben. Teilweise
   kann man per Software-Option (z.B. viele CD-ROM-Treiber) verhindern,
   daß man das Medium wechseln kann. Auch Drucker (Papierstau, Papierende)
   können von diesem Problem betroffen sein, in der Regel führt dies aber
   nicht zu langen Hängern, sondern zu einer unmißverständlichen Meldung.
   Außerdem werden Drucker auch nur selten beim Start einer Applikation
   initialisiert.

                                                                             
  ---------------------------------------------------------------------------

  VI.12. NET.CFG Parameter: [97-02-13]
  ====================================

   Stichworte: SERVER.EXE, VLM.EXE, VLMs, NET.EXE

   Die folgende Auflistung beschreibt, welche NET.CFG Parameter von welchen
   Netztreibern ausgewertet werden (und erhebt derzeit noch nicht den
   Anspruch auf Vollständigkeit, z.Z. werden hier lediglich die Gruppen
   NETWARE DOS REQUESTER und DESKTOP SNMP behandelt).

   Mit den VLM-Updates sind eine ganze Reihe neuer Parameter hinzugekommen
   (besonders bei v1.10 und v1.21); es gibt aber auch noch etliche Para-
   meter aus Zeiten lange vor dem VLM-Client, die heutzutage nicht mehr
   ausgewertet werden und daher in dieser Auflistung auch nicht mehr
   auftauchen. Teilweise durchsuchen die Programme (SERVER.EXE) die Datei
   NET.CFG und wenn diese nicht auffindbar ist, die ältere Datei SHELL.CFG
   (aus IPX/NETX-Zeiten). Weitere Hinweise in NETCFG.TXT und SAMPLNET.CFG
   aus den VLM-Kits und natürlich im DOSBOOK!

   Die Auflistung geschieht hier - im Gegensatz zu anderen Übersichten -
   anhand der jeweiligen Treiber, weil m.E. so ein besseres Verständnis
   für die Wirkung eines Treibers möglich wird.

   PNW-Server SERVER.EXE (getestet mit v1.23):
    (sucht die Dateien C:\NWCLIENT\NET.CFG, C:\PNETWARE\NET.CFG,
     NET.CFG, SHELL.CFG)

    NETWARE DOS REQUESTER          ;
     ALTERNATE CALLDOS=on|<off>    ; Für Prozeßumschalter
     NETWARE SHARING MODE=         ;
     OS2=on|<off>                  ; Für OS/2 Support


   VLM.EXE (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     CONFIRM CRITICAL ERROR ACTION=<on>|off ; (erst ab v1.10+)
     EXCLUDE VLM=<vlm>             ; kann wiederholt werden
     MESSAGE LEVEL=<1>             ; 0..4
            ; 0 = V_LEVEL_STD     always display message and critical errors
            ; 1 = V_LEVEL_WARNING display warning type messages
            ; 2 = V_LEVEL_PROG    display the program load message
            ; 3 = V_LEVEL_CONFIG  display configuration information
            ; 4 = V_LEVEL_DIAG    display diagnostic information
     NETWARE PROTOCOL=[NDS] [BIND] [PNW]; die nicht benötigten VLMs werden
                                   ; nicht geladen
                                   ; (nicht NETWARE PROTOCOLS= !!!)
     SET STATION TIME=<on>|off     ;
     USE DEFAULTS=on|off           ; lade Default-VLMs (erspart die meisten
                                   ; der VLM= Anweisungen)
     VLM=<vlm>                     ; kann wiederholt werden


   AUTO.VLM (setzt REDIR.VLM voraus) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     AUTO RECONNECT=<on>|off       ;
     AUTO RETRY=<0>                ; 0..3640
     AUTO LARGE TABLE=on|<off>     ; Mit <off> ist die max. Länge für Namen
                                   ; und Paßwörter auf 16 Zeichen beschränkt
     BIND RECONNECT=on|<off>       ;
     CONNECTIONS=<8>               ; 2..50


   BIND.VLM (setzt TRAN.VLM voraus) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     BIND RECONNECT=on|<off>       ;
     ;PREFERRED SERVER=<server name> (angeblich mit v1.10, nicht aber v1.21)


   CONN.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     AVERAGE NAME LENGTH=<48>      ; 2..48
     CONNECTIONS=<8>               ; 2..50
     LOAD CONN TABLE LOW=on|<off>  ;
     LOAD LOW CONN=<on>|off        ;
     MAX TASKS=<31>                ; 5..254


   FIO.VLM (benötigt NWP.VLM) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     CACHE BUFFERS=<5>             ; 0..64
     CACHE BUFFER SIZE=<media dependent>; (nicht CACHE BUFFERS SIZE= !!!)
     CACHE WRITES=<on>|off         ;
     CONNECTIONS=<8>               ; 2..50
     LOAD LOW FIO=on|<off>         ; (erst ab v1.10+)
     MAX IPG=                      ; <nichts>, 0..63, 257 (erst ab v1.20B+)
     PB BUFFERS=<3>                ; 0..10, 0=off, sonst=on
     PBURST READ WINDOW SIZE=<16>  ; 2..64
                                   ; (nicht PBURST READ WINDOWS SIZE= !!!)
     PBURST WRITE WINDOW SIZE=<10> ; 2..64
                                   ; (nicht PBURST WRITE WINDOWS SIZE= !!!)
     TRUE COMMIT=on|<off>          ;


   GENERAL.VLM (benötigt NWP.VLM) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     DOS NAME=<MSDOS>              ; max. 5 Zeichen (vgl. Kapitel IV.7.)
     FIRST NETWORK DRIVE=<1st avail>; A..Z
     FORCE FIRST NETWORK DRIVE=on|<off>; (erst ab v1.10+)
     LOCK DELAY=<1>                ; 0..255 (vollständig ab v1.20+)
     LOCK RETRIES=<3>              ; 0..255 (vollständg ab v1.20+)
     LONG MACHINE TYPE=<IBM_PC>    ; max. 6 Zeichen
     SEARCH MODE=<1>               ; 0..7
     SHORT MACHINE TYPE=<IBM>      ; max. 4 Zeichen


   IPXNCP.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     ALTERNATE SOCKETS=            ; (erst ab v1.21+)
     CHECKSUM=<1>                  ; 0..33
     HANDLE NET ERRORS=<on>|off    ;
     LARGE INTERNET PACKETS=<on>|off
     LIP START SIZE=<0>            ; 0, 576..65536 (ab v1.20+)
     LOAD LOW IPXNCP=<on>|off      ;
     MINIMUM TIME TO NET=<value>   ; (erst ab v1.10+)
     PB BUFFERS=<3>                ; 0..10, 0=off, sonst=on


   NDS.VLM (benötigt TRAN.VLM, RSA.VLM) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     ; AUTO RECONNECT=<on>|off     ; (angeblich bei v1.10, nicht be v1.21)
     CONNECTIONS=<8>               ; 2..50
     NAME CONTEXT="<context>"      ;
     PREFERRED TREE=<tree>         ;


   NETX.VLM (benötigt REDIR.VLM, PRINT.VLM) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     DOS NAME=<MSDOS>              ; max. 5 Zeichen (vgl. Kapitel IV.7.)
     EOJ=<on>|off                  ; (erst ab v1.10+)
     FIRST NETWORK DRIVE=<1st avail>; A..Z
     LOAD LOW NETX=on|<off>        ; (erst ab v1.10+)
     ;LOCK DELAY=<1>     0..255    (angeblich teilweise bei v1.10, voll-
     ;LOCK RETRIES=<3>   0..255    ständig bei v1.20, nicht bei 1.21)
     LONG MACHINE TYPE=<IBM_PC>    ; max. 6 Zeichen
     SHORT MACHINE TYPE=<IBM>      ; max. 4 Zeichen


   NWP.VLM (benötigt BIND.VLM, PNW.VLM) (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     CHECKSUM=<1>                  ; 0..3
     LARGE INTERNET PACKETS=off|<on>
     ;LIP START SIZE=<0>  0,576..65536 (angeblich bei v1.10, nicht bei 1.21)
     MESSAGE TIMEOUT=<0>           ; 0..10000
     SIGNATURE LEVEL=<1>           ; 0..3


   PNW.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     BROADCAST RETRIES=<2>         ; 0..255
     BROADCAST SEND DELAY=<0>      ; 0..255
     BROADCAST TIMEOUT=<3>         ; 1..255
     PREFERRED WORKGROUP=<workgroup>; (offenbar statt des im DOSBOOK
                                   ; beschriebenen WORKGROUP NAME=)
     RESPONDER=off|<on>            ;
     MOBILE MODE=<0>               ; 0..65535
     WORKGROUP NET=                ;


   PRINT.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     LOCAL PRINTERS=<3>            ; 0..9
     NETWORK PRINTERS=<3>          ; 0..9 (0 lädt PRINT.VLM nicht)
     PRINT BUFFER SIZE=<64>        ; 0..256
     PRINT HEADER=<64>             ; 0..1024
     PRINT TAIL=<15>               ; 0..1024
     RESET PRINTER FLAGS=          ; (erst ab v1.21+)


   REDIR.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER          ;
     EOJ=off|<on>                  ; (erst ab v1.10+)
     FIRST NETWORK DRIVE=<1st avail>; A..Z (angeblich nicht mit v1.10...)
     LOAD LOW REDIR=<off>|on       ; (erst ab v1.10+)
     READ ONLY COMPATIBILITY=<off>|on; (vor v1.10 war Default <on>)
     SHOW DOTS=<off>|on            ;


   SECURITY.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER         ;
     CONNECTIONS=<8>              ; 2..50
     SIGNATURE LEVEL=<1>          ; 0..3


   WSASN1.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER         ;
     LOAD LOW WSASN1=off|on       ; (nicht mit v1.00)
    DESKTOP SNMP                  ;
     ENABLE CONTROL COMMUNITY=off|any|specified|[ommitted]
     ENABLE MONITOR COMMUNITY=off|any|specified|[ommitted]
     MONITOR COMMUNITY="name|public|private"
     CONTROL COMMUNITY="name|public|private"


   WSREG.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER         ;
     LOAD LOW WSREG=off|on        ; (nicht mit v1.00)


   WSSNMP.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER         ;
     LOAD LOW WSSNMP=off|on       ; (nicht mit v1.00)
    DESKTOP SNMP                  ;
     ASYNCHRONOUS TIMEOUT=<20>    ;
     SNMPENABLEAUTHENTRAPS=<off>|on
     SYSCONTACT="<mail address>"  ;
     SYSLOCATION="<description system location>"
     SYSNAME="<description system name>"


   WSTRAP.VLM (getestet mit v1.21):

    NETWARE DOS REQUESTER         ;
     LOAD LOW WSTRAP=off|on       ;
    DESKTOP SNMP                  ;
     TRAP COMMUNITY="name|public|private"
     ENABLE TRAP COMMUNITY=off|any|specified|[ommitted]; (auch 'any'!!!)


   Die VLMs MIB2IF.VLM, MIB2PROT.VLM, NMR.VLM, PNWMIB.VLM, RSA.VLM,
   TRAN.VLM, WSDRVPRN.VLM lesen selbst keine Konfigurationsparameter aus
   der NET.CFG Datei (getestet mit v1.21). Der im DOSBOOK beschriebene
   Parameter WORKGROUP NAME= innerhalb der NETWARE DOS REQUESTER Gruppe
   wird von PNW.VLM offenbar nicht ausgewertet (und scheint durch den
   später dokumentierten Parameter PREFERRED WORKGROUP= ersetzt worden
   zu sein).

   NET.EXE (getestet mit v1.05) (siehe Kapitel VI.9.):

    NETWARE DOS REQUESTER
     BROADCAST RETRIES=<2>        ; 0..255
     BROADCAST TIMEOUT=<3>        ; 1..255
     BROADCAST SEND DELAY=<0>     ; 0..255
     PREFERRED WORKGROUP=<workgroup name>; (offenbar statt WORKGROUP NAME=)
     WORKGROUP NET=<workgroup net address>

                                                                             
  ###########################################################################
  ###########################################################################

  VII. MULTITASKING UND PROZESSUMSCHALTUNG:
  =========================================

  ---------------------------------------------------------------------------

  VII.1. Fehlverhalten von TASKMGR mit älteren Maustreibern: [97-01-13]
  =====================================================================
                                       (Bug behoben - getestet 01/1995)

   Stichworte: TASKMGR, Multitasking, TASKMGR Menü, GMOUSE, MAUSALL,
               Logitech-Maus, Updates, Microsoft Mouse

   Der Task-Manager hatte im Multitasker-Modus Probleme mit verschiedenen
   älteren (und ganz neuen Microsoft) Maustreibern, insbesondere wenn
   mehrere Applikationen gleichzeitig eine Maus verwenden oder wenn um-
   programmierte Text-Fonts für VGA-Karten (Schlagwort: New User Interface,
   Pseudo-Grafikmodus im Textmodus) verwendet werden.

   Mögliche Symptome:

   - die Maus wird in einer oder mehreren Applikationen 'abgeschossen'
   - während des TASKMGR-Menüs erscheint kein eigener Maus-Cursor
   - der Task-Manager schmiert während der Umschaltung zwischen den
     Prozessen sogar ab, wenn man die Maus bewegt
   - EMM386 meldet eine Schutzverletzung während der Programmumschaltung
     zwischen Prozessen.

   Ausgangslage für dieses Problem (muß nicht repräsentativ sein):

   - In CONFIG.SYS: DEVICEHIGH=GMOUSE.SYS (V9.06/1991)
     für Genius 3-Tasten-Maus (PC-/Mouse-Systems-Mouse-Mode)
   - In AUTOEXEC.BAT hochgeladen: MAUSALL.COM
     für Maussimulation über Cursor-Tasten für Nicht-Maus-Anwendungen
   - TASKMGR mit und ohne /F Option.

   Abhilfe:

   Im vorliegenden Fall war der ältere Maustreiber die Fehlerursache, der
   allerdings ansonsten bisher keinerlei Probleme bereitete. Die Probleme
   konnten jedoch auch mit anderen älteren Maustreibern (Noname, Agiler-
   Maus, Z-Mouse) reproduziert werden.

   Nach verschiedenen Tests konnte der Fehler nur dadurch beseitigt werden,
   daß kein Maustreiber installiert wurde.

   Ein Logitech-Treiber (MouseWare 6.30+/1993) funktioniert jedoch
   während der Umschaltung der Tasks einwandfrei (leider nicht im Mouse-
   Systems-Mouse-Mode, also nur als 2-Tasten-Maus). Der verwendete Treiber
   unterstützt u.a. die neue Software-Schnittstelle VESA-VCI (Video Cursor
   Interface), dafür aber keine CGA-Karten und macht zudem eine Reihe
   anderer Probleme, u.a. auf Zwei-Monitor-Systemen mit der Umschaltung auf
   den anderen Bildschirm, wenn zum Installationszeitpunkt die Monochrom-
   Karte aktiv war, oder mit einem selbstdefinierten Maus-Cursor mancher
   Anwendungen (z.B. stürzt IOMegas QBACKUP 3.x bei mir immer ab); dies
   ist aber für die Probleme nicht ausschlaggebend.
   (Nebenbei: Um den Treiber auf Zweimonitor-Systemen zu benutzen, sollte
   man vor derInstallation des Treibers (wenigstens temporär) auf die Farb-
   Karte umschalten, z.B. mit INSTALL=c:\nwdos\mode.com CO80. Um dem Absturz
   unter QBACKUP abzuhelfen, hilft es oft, solche Problemappikationen nur
   unter einem anderen Maustreiber zu starten. In meinem Fall reichte es,
   den Genius-Maustreiber GMOUSE 10.20 über den Logitech-Treiber zu laden
   und nach der Rückkehr zum Prompt mit /U wieder zu entladen.)

   Falls nur im TASKMGR-Menü kein Maus-Cursor erscheint, reicht es, MAUSALL
   wegzulassen.

   Mittlerweile ist sowohl EMM386 als auch TASKMGR mehrfach aktualisiert
   worden (Update 10+), die oben beschriebenen Probleme mit dem Genius-
   Maustreiber sind mit der aktuellen Version komplett beseitigt worden
   (jedenfalls bin ich wieder auf den in vielen anderen Belangen stabileren
   Genius-Maustreiber 9.06 umgestiegen, wodurch z.B. MS Windows erheblich
   stabiler arbeitet). Ein neuerer Maustreiber 10.20 (1993) ist mittlerweile
   auf SimTel verfügbar - leider auch nicht ganz unproblematisch - mehr dazu
   in Kapitel VIII.2.

   Novell weist in einem FaxBack-Infopaper aus ND7TID.EXE darauf hin, daß
   es auch mit Microsoft Mousetreibern der Versionen 9.xx und 10.xx Probleme
   gibt. Laut Novell funktionieren ältere Microsoft-Maustreiber. Außerdem
   können Microsoft Mäuse auch mit den Maustreibern von Genius und vielen
   anderen bedient werden.

                                                                             
  ---------------------------------------------------------------------------

  VII.2. Undokumentierte Einstellungen für den TASKMGR: [97-02-26]
  ================================================================

   Stichworte: TASKMGR, TASKMGR.INI, TCP/IP, VxD, MS Windows,
               K3PLUS, FreeKEYB

   Innerhalb des TASKMGR (und TASKMAX) Menüs haben neben den bekannten
   Tasten noch die Tasten <F2> und <F4> besondere Bedeutung:

    <F2> ist gleichwertig mit <Ins>
    <F4>        ""            <Del>

   Novells TASKMGR besteht im Prinzip aus zwei eigenständigen Modulen
   (für den Prozeßumschalter und den Multitasker) und einem Lader, der
   für beide Module gemeinsam gilt.
   Übrigens: Zumindest theoretisch kann TASKMGR mit INSTALL= etc. sogar
   in CONFIG.SYS geladen werden, nachdem vorher der Speichermanager
   EMM386.EXE und SHARE.EXE geladen wurden. In seltenen Fällen und bei
   entsprechender Konfiguration mag diese Option sinnvoll sein, da alle
   Programme/Treiber, die erst nach dem TASKMGR geladen werden, für den
   jeweiligen Task lokal bleiben. Auf diese Weise sind nebeneinander
   rudimentäre Tasks mit extrem viel Speicher und einem blank liegenden
   Systemkern und andere mit viel Komfort möglich. In der Praxis reicht es
   dazu jedoch meist aus, den TASKMGR früh in AUTOEXEC.BAT zu laden, was
   erheblich weniger Probleme bereitet und stabiles Arbeiten garantiert
   (das Laden in CONFIG.SYS ist bisher von mir noch nicht genauer unter-
   sucht worden). Besonders vorteilhaft ist die Möglichkeit, Treiber nur
   in einem Task des Multitaskers zu laden, wenn Sie zwar Treiber für den
   IPX-Stack, nicht aber die restliche Client- oder gar Server-Software
   von Personal NetWare benötigen (etwa für FASTLYNX, das Punkt-zu-Punkt
   Verbindungen auch über IPX aufbauen kann, siehe Kapitel II.8.)

   Der TASKMGR wird sowohl in der Prozeßumschalt- als auch in der Multi-
   tasking-Version mit der Datei TASKMGR.INI (im Pfad %Path% oder im
   Verzeichnis %NWDOSCFG%) konfiguriert. Wenn auch nicht im Handbuch oder
   dem DOSBOOK, so sind wenigstens in dieser Datei alle wichtigen Parameter
   erklärt (falls diese Erklärungen fehlen (DR DOS 6.0 VIEWMAX löscht sie
   zumindest in der verwandten Datei TASKMAX.INI), sollte man sich das
   Original von den Installationsdisketten besorgen). Groß- und Klein-
   schreibung ist unerheblich (im Gegensatz zu VIEWMAX.INI). Es gibt hier
   wirklich eine Menge Feintuning-Möglichkeiten, die besonders bei Problemen
   nicht übergangen werden sollten.

   In der Gruppe [COLORS] sind normalerweise nur die Direktiven COLORSET0=
   bis COLORSET7= vordefiniert. TASKMGR akzeptiert hier auch noch COLORSET8=
   und COLORSET9=.


   i. Multitasker:
   ---------------

   Im Multitasking-Modus gibt es neben den dokumentierten Parametern noch
   drei weitere Parameter in TASKMGR.INI:

   Zwei davon befinden sich im Abschnitt

    [KEYS]

    #      Die im Abschnitt [KEYS] verwendeten Zustände der Umschalttasten
    #      sind Dezimalwerte, die den Tasten UMSCHALT, STRG und ALT ent-
    #      sprechen. Deren numerische Äquivalente sind: 1=UMSCHALT rechts,
    #      2=UMSCHALT links, 4=STRG, 8=ALT. Der Tastenwert ist ein PC-
    #      Scancode. Der Standardwert von 1 ist die ESC-Taste.
    #      Bleibt zu ergänzen:
    #      Es können mehrere Umschalttasten kombiniert werden. Soll z.B. der
    #      TASKMGR auf <Ctrl>+<Alt>+<Taste> reagieren, ersetzt man den Wert
    #      4 (Default für <Ctrl>) durch 12. Hier ist jedoch <Ctrl>+<Alt>
    #      ungleich <AltGr>, wie dies sonst pauschal in Verbindung mit dem
    #      erweiterten deutschen Tastaturtreiber K3/K3PLUS/FreeKEYB gilt,
    #      d.h. <AltGr>+<Taste> aktiviert die gewünschte Funktion nicht!
    #      Linke und rechte <Ctrl> bzw. <Alt> Taste werden nicht unter-
    #      schieden, daran ändert auch Einträge 'STANDARD' nichts, die sich
    #      nur auf die Taste, nicht aber auf den Umschaltstatus beziehen.

    MAINNUMKEYS=    # bezeichnet den PC-Scancode der Zifferntaste auf der
                    # Haupttastatur, analog zu den übrigen Einträgen 'KEYS'
    NUMSTANDARD=    # normalerweise bedeutet beim Eintrag 'STANDARD':
                    # 1=Tasten auf der Haupttastatur,
                    # 0=Tasten im erweiterten Tastaturbereich (Cursor-Block,
                    # NumPad), dies wird auch hier so sein,
                    # siehe Aufrufoption /M

   und einer im Abschnitt

    [DEBUG]
    Level=0         # Weiteres ist unbekannt.

   Im Multitasking-Modus wird in der Gruppe [MEMORY] nur LIMIT= ausgewertet,
   die Gruppe [DISK] und die undokumentierte Gruppe [VIRTUAL] hingegen über-
   haupt nicht.

   Die Standardtastenkombination für das TASKMGR-Menü ist <Ctrl>+<Esc>. Will
   man jedoch unter Windows gezielt das Menü des Windows' TaskMan und nicht
   das des Novell TASKMGR wählen, muß man das TASKMGR-Menü auf eine andere
   Tastenkombination legen. Da unter der graphischen Oberfläche GEOWORKS
   [PRO] ENSEMBLE nur die Tastenkombination <Shift>+<Esc> (laut einer Quelle
   bei Digital Research nur <Ctrl>+<Esc>???) für den TASKMGR verwendet
   werden kann (alle anderen Tasten werden abgefangen), sollte man z.B.
   auch für MS Windows diese Tastenkombination wählen.

   Novell empfiehlt, Oberflächen, die im Hinblick auf DR DOS TASKMAX ge-
   schrieben wurden (z.B. GEOWORKS ENSEMBLE 2.xx oder DR DOS 6.0 VIEWMAX),
   nur unter dem TASKMGR als Prozeßumschalter zu starten, oder - unter dem
   Multitasker - die TASKMAX-Task-Steuer-Funktionen der Oberfläche abzu-
   schalten. Eigene Versuche haben ergeben, daß es durchaus möglich ist,
   auch den Multitasker zu verwenden (siehe NWDOS7UN.TXT), dies aber nicht
   immer sicher funktioniert und außerdem die Übersicht über die laufenden
   Tasks zwischen der Oberfläche und dem TASKMGR+Menü nicht unbedingt
   synchronisiert wird (in Wahrheit unterstützt der neue TASKMGR im
   Prozeßumschaltmodus und Multitasking-Modus nahezu alle API-Funktionen
   des alten TASKMAX, abgesehen von Copy/Paste). In einem amerikanischen
   Buch habe ich übrigens die Behauptung gefunden, daß TASKMGR als Prozeß-
   Umschalter Copy/Paste unterstützt (auf dem TASKMGR-Menü nicht abge-
   bildet). Ich kann das leider nicht bestätigen, da zumindest in der
   deutschen Ausgabe auch die interne Unterstützung dafür entfernt wurde.

   Wenn TCP/IP-Anwendungen 'gefahren' werden oder mehrere Tasks parallel auf
   das Netz zugreifen wollen, kann es notwendig sein, im Abschnitt [DRIVERS]
   weitere Einträge der Form 'GLOBALPAGES=2' einzubauen.

   Außerdem existiert im Abschnitt [Drivers] ein Eintrag für virtuelle
   Gerätetreiber (hier vIPX) in der Form 'VXD=laufwerk:pfad\vipx.386',
   der meist auf das \WINDOWS\SYSTEM\ Verzeichnis verweist, in das die
   Datei VIPX.386 während der Installation kopiert wird. Da diese Datei
   auch im C:\NWDOS\ Verzeichnis vorkommt (oder notfalls dorthin kopiert
   werden kann), sollte die dortige Datei verwendet werden, indem man den
   Eintrag wie folgt ändert:

    VXD=c:\nwdos\vipx.386

   Wenn das Netzwerk geladen ist und man den TASKMGR im Multitasking-Modus
   startet, sollte der Treiber 'OK' melden, sonst ist etwas schief gelaufen.
   Ohne geladenes Netzwerk wird der Treiber vIPX nicht 'OK' melden, was aber
   dann auch nicht stört.

   Der TASKMGR bildet in vielerlei Punkten die Mechanismen von MS Windows
   nach. Das hat den Vorteil, daß z.B. evtl. notwendige virtuelle Geräte-
   treiber für Windows (VxD) auch für den TASKMGR verwendet werden können!
   Leider funktioniert dies nicht mit allen MS Windows .386-Treibern. Wenn
   der Treiber problemlos initialisiert worden ist, meldet TASKMGR dies mit
   'OK' beim Start. Ansonsten wird nur der Name des Treibers angegeben. Mehr
   oder weniger interessehalber habe ich eine ganze Reihe VxD-Treiber der
   unterschiedlichsten Software-Pakete getestet. Bei den folgenden Treibern
   meldet TASKMGR sogar 'OK': MS-DOS/MS Windows MONOUMB.386, Novells
   FASTBACK.386, Logitech MouseWare 6.30 LVMD.386, Borlands WINDPMI.386,
   Microsofts 32Bit-Erweiterung W32S.386). Durch diese Möglichkeit ver-
   ringert sich natürlich der Entwicklungsaufwand und bei Problemen bestehen
   große Chancen, daß ein Treiber für Windows ein gleichartige Aufgabe auch
   beim TASKMGR erfüllt.
   Die eingebundenen Treiber sind jedenfalls aktiv, wie Versuche mit dem
   virtuellen Maustreiber LVMD.386 zeigen. Natürlich macht das Ganze nicht
   immer Sinn: W32S.386 kann zwar völlig ohne Windows unter dem TASKMGR
   geladen werden, eine Verwendungsmöglichkeit dafür ist mir allerdings
   noch nicht eingefallen... ;-)

   Ein anderer Punkt ist, daß der TASKMGR auch die Start-/Exit-Broadcasts
   von Windows nachbildet. Dies kann allerdings auch manche Anwendungen
   leicht verwirren:
   Dies gilt z.B. für K3PLUS/FreeKEYB in der derzeitigen Implementation.
   Der Bildschirmschoner wird nur für die Dauer der TASKMGR-Session
   abgeschaltet, so daß er innerhalb eines Tasks mit K3_ENZZ wieder
   aktiviert werden muß. Dies kann man bei Verwendung von Exec=True und
   4DOS auch innerhalb der 4START.BAT Datei erledigen, wobei man eine
   Sonderbehandlung für MS Windows einbauen muß, damit dies dort nicht
   geschieht.

   Kann TASKMGR das Windows-Verzeichnis nicht ermitteln, sollten Sie die
   undokumentierte Umgebungsvariable %TaskMgrWinDir% mit dem Pfad zur
   SYSTEM.INI Datei angeben; siehe Kapitel IV.7.

   Obwohl der Multitasker normalerweise ungültige Parameter beim Start
   zurückweist, trifft dies für den Parameter /F (eigentlich nur für den
   Prozeßumschalter) nicht zu. Ob dieses Verhalten aber mehr als nur ein
   Dummy zur Wahrung der Aufrufkompatibilität mit dem Prozeßumschalter
   ist, ist noch nicht geklärt.

   Der Multitasker kann auch DPMI- oder VPCI-nutzende Applikationen
   ausführen, allerdings werden Hintergrund-Tasks, die VCPI nutzen, wie
   beim Taskswitcher ausgesetzt, bis sie wieder in den Vordergrund geholt
   werden. Dies ist notwendig, da das VCPI-Protokoll per se keine Unter-
   stützung für Multitasker erlaubt. Da auch MS Windows 3.0 bzw.
   MS Windows 3.1x im Standardmodus (WIN /S) VCPI-Applikationen sind,
   wird auch MS Windows als Hintergrund-Task unter dem TASKMGR ausgesetzt.

   ii. Prozeßumschalter:
   ---------------------

   Im Prozeßumschalt-Modus des TASKMGR werden eine ganze Reihe der im
   Multitasking-Modus verwendeten Einstellungen nicht benötigt, im Einzelnen
   sind dies die kompletten Gruppen [DRIVERS], [SLICE], [COM1] - [COM4],
   [LPT1] - [LPT3], [MOUSE], [NETWORK], [SHELL], [WINFUNC], [POPUP] und
   [DEBUG]. In der Gruppe [KEYS] werden MENUSTANDARD=, NEXTSTANDARD=,
   PREVSTANDARD= und die undokumentierte Direktive NUMSTANDARD= nicht
   ausgewertet. [KEYS] MAINNUMKEYS= wird wie im Multitasking-Modus unter-
   stützt. In der Gruppe [MEMORY] wird alles außer LIMIT= ausgewertet und
   die Gruppe [DISK] mit der einzigen Einstellung SWAPDIR= wird sowieso
   nur vom Prozeßumschalter benötigt. Wird hier nichts angegeben, möchte
   TASKMGR die Auslagerungsdatei TASKMGR.SWP in C:\NWDOS\TMP anlegen.

   Außerdem existiert in der Gruppe [MEMORY] noch eine undokumentierte
   Direktive

    [MEMORY]
    MINIMUM=        # für die minimale Größe des Auslagerungsspeichers

   und eine komplett undokumentierte Gruppe [VIRTUAL] mit den Direktiven:

    [VIRTUAL]       # Die Bedeutung im Einzelnen ist noch unklar:
    DEVICE=         # Da TASKMGR normalerweise nicht in CONFIG.SYS geladen
    INSTALL=        # wird, scheidet die Angabe von Treibernamen, die
    TSR=            # geladen werden müssen, eigentlich aus. Vermutlich
                    # handelt es sich hier um Schalter (TRUE/FALSE), die
    TASK=           # bestimmen, ob entsprechende Ressourcen virtualisiert
    VIDEO=          # werden oder nicht. Dies würde ungefähr mit den
                    # speziellen Gerätetreibereinstellungen des Multi-
                    # taskers einher gehen.
                    # Eine andere Möglichkeit wäre ein Analogon zu Windows
                    # [386Enh] LocalTSR= und Local= zum Instancing.
                    # VIDEO= könnte auch eine Default-Angabe des Parameters
                    # /V sein.

   Im Prozeßumschaltmodus gibt es eine ganze Reihe undokumentierter Aufruf-
   parameter für TASKMGR (nur während der Initialisierung des Prozeßum-
   schalters). Die Funktionen sind noch nicht im Einzelnen geklärt, hier
   aber schon mal ein paar Eigenschaften:

    /Z         Dient offenbar dazu, nur einen Dummy-TASKMGR zu laden.
               Jedenfalls ist kein weiterer Task mehr startbar und die
               Task-Liste enthält null (=Zero) Tasks (das Umbenennen des
               ersten Tasks mittels /N wird allerdings nicht zurückge-
               wiesen). Bei Druck auf den Aktivierungs-Hotkey des TASKMGR
               ertönt nur ein Piepser; es erscheint kein Menü. Auch unter
               VIEWMAX (von DR DOS 6.0) sind in der Task-Liste keine Tasks
               zu sehen (normalerweise wird wenigstens der Root-Task
               angezeigt).

    /U         Unbekannt (User???)

    /B         Unbekannt. Ohne diese Option wird der Bildschirm normaler-
               weise beim Start des TASKMGR für einen Augenblick dunkel,
               mit /B wird dies unterdrückt. Könnte daher etwas mit der
               Hardware-Erkennung zu tun haben (aber sicher nicht für
               B&W-Darstellung).

    /T[=value] oder /T[:value]
               Unbekannt, hat aber definitiv nichts mit der Task-Anzahl zu
               tun. Da beliebige dezimale Werte akzeptiert werden, könnte
               dies etwas mit einem Timeout zu tun haben. Allerdings konnte
               ich bisher noch keinen Unterschied in den Umschaltzeiten beim
               Starten neuer Tasks erkennen. Allerdings liefen nach Angabe
               dieser Option Tasks nicht reproduzierbar sehr viel langsamer.
               (Auch COMMAND.COM besitzt einen undokumentierten Parameter
               /T, und unter Multiuser DOS gibt es eine EXIT /T Option.
               Vielleicht haben beide etwas miteinander zu tun?)

   Der folgende Parameter steht nur *nach* der bereits erfolgten
   Installation des Prozeßumschalters zur Verfügung:

    /R[=devicename]                                   <Default-Wert ist CON>

               Angabe eines logischen Gerätes, an das die Standardein-
               und -ausgabe (des Tasks???) gekoppelt werden (wird für
               Remote-Zwecke benutzt). Gibt man nichts an, wird CON, die
               Konsole gewählt und man kann Eingaben vornehmen (die man
               auch sofort sieht). Die Eingabe von CON kann man bekanntlich
               mit <Ctrl>+<z> abbrechen.

   Der residente Teil des Novell DOS 7 TASKMGR als Prozeßumschalter ist
   weitestgehend identisch mit dem von DR DOS 6.0 bekannten TASKMAX (der
   allerdings noch Copy & Paste Funktionen bot). Es werden auch alle hier
   beschriebenen dokumentierten und undokumentierten TASKMGR.INI Direktiven
   vom älteren TASKMAX in TASKMAX.INI unterstützt.
   TASKMAX unterstützte auch alle der hier beschriebenen Aufrufparameter
   (logischerweise außer /S), zusätzlich aber (nach oder während der
   Installation???) noch die undokumentierten Parameter /P (unbekannt,
   vielleicht in Verbindung mit 'Paste' oder 'Permanent') und /M (für
   'Main-Keyboard' statt Ziffernblock). Außerdem existierte in TASKMAX.INI
   noch eine Gruppe [COPY+PASTE] mit den Einträgen PASTESPEED=, NUMERIC=,
   TEXT= und ENTER= (Näheres hierzu in DRDOS6UN.TXT).
   Diese Einstellungen werden vom TASKMGR mangels Copy & Paste Funktionen
   leider nicht mehr unterstützt (auch nicht auf API-Ebene). Leider ist es
   mir bisher noch nicht gelungen, TASKMAX unter Novell DOS 7 zu starten,
   obwohl dies evtl. nach ein paar Patches möglich ist.

   Offenbar bietet der TASKMGR im Prozeßumschaltmodus (und TASKMAX) eine
   Möglichkeit über Port 3F8h (normalerweise COM1:) gesteuert zu werden oder
   dort Statusinformationen abzuliefern. Laut einer Quelle unterstützt der
   TASKMGR zumindest als Prozeßumschalter auch DR Multiuser DOS. Bisher
   konnte dies nicht überprüft werden. Näheres ist nicht bekannt.

                                                                             
  ---------------------------------------------------------------------------

  VII.3. Novell DOS TASKMGR und 4DOS kombinieren: [96-12-03]
  ==========================================================

   Stichworte: TASKMGR, 4DOS, NDOS, Updates, Kommandoprozessor, 4DOS.INI,
               TASKMGR.INI, Exec=TRUE/FALSE, TASKMGR /C

   Zuerst ein genereller Hinweis: Diese Beschreibung bezieht sich auf
   TASKMGR 2.02+, Novell DOS 7 Update 15+ und 4DOS 5.5c/5.52a (mit Ab-
   strichen 5.51). Sie sollten immer diese oder aktuellere Versionen
   verwenden, da es mit älteren Versionen verschiedene Probleme gab.

   Achtung: 4DOS 5.51 (nicht 4DOS 5.5a/b/c und 4DOS 5.52a) brachte auf
   meinen Testsystemen eher eine Verschlimmbesserung der Situation, zu-
   mindest MEMMAX +V führte auf mehreren Rechnern zum Totalabsturz mit
   Verlust des CMOS-RAM-Inhalts.
   Abhilfe war allerdings dadurch möglich, daß man MEMMAX nur indirekt
   über einen Batchjob/Alias aufruft, der vorher COMMAND.COM nachlädt
   (klappt nicht immer, siehe 4DOSTIP.TXT), z.B.:

    MEMMAX.BAT:

     COMMAND /C c:\nwdos\memmax.com %1 %2 %3 %4 %5 %6 %7 %8 %9


   Nun jedoch die generellen Lösungsmöglichkeiten:

   Es gibt verschiedene Möglichkeiten Novell DOS und 4DOS (JP Software)
   bzw. NDOS (von den Norton Utilities) zu kombinieren.

   Solange dabei weder die Netzkomponente Personal NetWare noch der
   TASKMGR ins Spiel kommen, ist die Konfiguration denkbar einfach und
   kann der Dokumentation zu 4DOS entnommen werden.

   Es gibt zwei generelle Methoden der Kombination:

   - 4DOS ersetzt COMMAND.COM komplett:

     Diese Methode wird von JP Software empfohlen, da sie u.a. weniger
     Speicher beansprucht und sehr einfach dadurch zu bewerkstelligen ist,
     daß man die CONFIG.SYS-Zeile

      SHELL=...\command.com /E:xxxx /P

     durch

      SHELL=...\4dos.com @...\4dos.ini /E:xxxx /P

     ersetzt.

     Diese Methode hat allerdings den Nachteil, daß alle erweiterten
     Features des Kommandoprozessors COMMAND.COM von Novell DOS nicht
     verfügbar sind (damit natürlich auch nicht die erweiterten internen
     Befehle und die zusätzlichen Umgebungsvariablen). Außerdem be-
     handelt 4DOS (getestet bis 5.52a) nicht alle internen Datenstrukturen
     von Novell DOS genauso wie COMMAND.COM das tun würde, was zu einigen
     (normalerweise aber unkritischen) Unstimmigkeiten in den internen
     Tabellen führen kann (siehe z.B. Kapitel III.6. und III.1. sowie
     in 4DOSTIP.TXT). Bis diese Probleme bei 4DOS gelöst wurden, empfehle
     ich das kurzzeitige Dummy-Laden von COMMAND.COM zu Beginn der Ab-
     arbeitung der AUTOEXEC.BAT:

      @c:\nwdos\command.com /c EXIT> \dev\nul

     Dieser Befehl hinterläßt einige bleibende Auswirkungen in den internen
     Strukturen, die durch diese Maßnahme besser an DR DOS/Novell DOS ange-
     paßt sein sollten.

   - 4DOS ergänzt COMMAND.COM:

     Diese Methode lädt im Prinzip zwei Kommandoprozessoren, die beide
     permanent bleiben. Der Nachteil ist, daß für den zusätzlichen
     COMMAND.COM ca. 3 KByte mehr Basisspeicher nötig sind. Dafür ergeben
     sich aber einige Vorteile:

     Alle COMMAND.COM Features bleiben erhalten (wenn sie auch durch 4DOS
     verdeckt werden und zum Teil erst über ALIAS etc. zugänglich gemacht
     werden müssen). Alle Variablen (nicht aber Pseudovariablen) von
     COMMAND.COM sind verfügbar. Um Speicher zu sparen, sollte man den
     COMMAMD.COM spezifizierenden SHELL= Eintrag in CONFIG.SYS so verändern,
     daß /E:129 nur noch den Minimalwert angibt.
     Multi-Konfigurationen sind einfacher zu realisieren, da sich an den
     Einstellungen der CONFIG.SYS nichts ändert (in CONFIG.SYS müßte man
     bei Mehrfachkonfigurationen nur eine Variable SET CONFIG=xxx setzen
     (mit xxx=cfg_std oder cfg_4dos) und diese dann in einzelnen Blöcken
     der AUTOEXEC.BAT abfragen). Außerdem erlaubt diese Methode auch mit
     Updates vor 15 das <F8>-Tracen der AUTOEXEC.BAT Datei; mit neueren
     Updates funktioniert dies nun auch mit Fremdkommandoprozessoren.

     4DOS wird erst in der AUTOEXEC.BAT nachgeladen. Von JP Software wird
     hier eine spezielle Methode empfohlen, die folgende Behandlung ist
     meines Erachtens aber sinnvoller:

     @ECHO off
     REM Anfang der AUTOEXEC.BAT:
     REM -- Abfangen von Endlosschleife beim Laden von 4DOS ----------------
     IF "%@Eval[2 + 2]%"=="4" GOTO _4dos_done
     IF NOT "cfg_4dos"=="%config%" GOTO _4dos_done
     LH c:\sys\4dos\4dos.com c:\sys\4dos @c:\sys\4dos\4dos.ini /E:2048 /P
     :_4dos_done

     REM Rest der AUTOEXEC.BAT: --------------------------------------------
     ...

     Natürlich können Sie auch die erste Methode anwenden und manuell die
     fehlenden Umgebungsvariablen setzen. Ob bei Verwendung von ALIAS
     mit nachgeladenem COMMAND.COM allerdings auch die Pseudo-Umgebungs-
     variablen für NetWare funktionieren, wurde nicht überprüft (allerdings
     klappt das auch nicht, wenn 4DOS über COMMAND.COM geladen wird - nur
     hat man hier evtl. etwas weniger Schwierigkeiten).


   In der Datei 4DOS.INI sollten - unabhängig von der oben gewählten
   Methode - einige spezielle Einstellungen gemacht werden, um optimal
   mit Novell DOS zusammenzuarbeiten (nur diese Einstellungen werden hier
   aufgelistet). Einige dieser Einstellungen weichen von Empfehlungen der
   Software-Häuser ab, arbeiten jedoch nach eigenen Erfahrungen besser:

     [Primary]

     ; Basic Directives: ---------------------------------------------------
     Environment        = 1024   ; Beispielwerte
     EnvFree            = 512
     Swapping           = XMS, EMS, c:\tmp, None
     4StartPath         = c:\sys\4dos
     LocalAliases       = Yes
     LocalHistory       = Yes
     LocalDirHistory    = Yes
     UMBAlias           = Yes
     UMBDirHistory      = Yes
     UMBHistory         = Yes
     UMBEnvironment     = Yes
     UMBLoad            = No/Yes
                       ; Yes klappt leider nur in einer speziellen Kombi-
                       ; nation: TASKMGR im Multitasking-Modus mit der
                       ; Einstellung EXEC=TRUE in TASKMGR.INI.
                       ; Näheres siehe nachfolgende Erklärungen!!!

     ; Configuration Directives --------------------------------------------
     BatchEcho          = Yes
     UpperCase          = Yes

     ; Key Mapping Directives ----------------------------------------------
     BackSpace          = Ctrl-H ; mit diesen Einstellungen wird während der
     BeginLine          = Ctrl-Q ; Eingaben am 4DOS-Prompt die WordStar-
     Del                = Ctrl-G ; Belegung der Tastatur unter Novells
     DelToBeginning     = Ctrl-B ; COMMAND.COM nachgebildet.
     DelToEnd           = Ctrl-K ; Die folgenden Sonderfunktionen können
     DelWordRight       = Ctrl-T ; dabei nicht berücksichtigt werden:
     Down               = Ctrl-X ; Suchmodi mit <Ctrl>+<r> und <Ctrl>+<_>;
     EndLine            = Ctrl-W ; sowie erweiterte Belegung der Funktions-
     EraseLine          = Ctrl-Y ; tasten
     ExecLine           = Ctrl-M
     Ins                = Ctrl-V
     Left               = Ctrl-S
     Right              = Ctrl-D
     Up                 = Ctrl-E
     WordLeft           = Ctrl-A
     WordRight          = Ctrl-F

     ; Advanced and Test Directives ----------------------------------------
     FullInt2E          = Yes ; für volle Unterstützung der undokumentierten
                              ; Schnittstelle; besonders sinnvoll in Ver-
                              ; bindung mit Novells TASKMGR (ist aber nicht
                              ; unbedingt erforderlich)
     UniqueSwapName     = Yes ; für Multitasker (MS Windows, TASKMGR) und
                              ; Multiuser-Umgebungen (Netzwerke)
     SwapReOpen         = Yes ; für Novell-Netze
     SDFlush            = No  ; instruiert SMARTDRV (bzw. NWCACHE), seine
                              ; Cache-Puffer vor der Rückkehr zum Prompt
                              ; nicht auszuschreiben. Das Resultat hängt
                              ; davon ab, ob SMARTDRV (bzw. NWCACHE) darauf
                              ; auch reagiert...
                              ; In Verbindung mit NWCACHE /FLUSH=ON sollte
                              ; man hier SDFlush=Yes einstellen, was sich
                              ; aber negativ auf die Performance auswirkt.
     DRSets             = Yes ; Spezialparameter für DR DOS CONFIG.SYS SET=
                              ; Befehl (ist nicht unbedingt erforderlich)
     NetWareNames       = Yes ; Spezialparameter für Novell-Netze

   Sollen auch noch der TASKMGR und/oder PNW verwendet werden, sind noch
   einige weitere Dinge zu beachten (die meisten Einstellungen der 4DOS.INI
   sind schon für diese Zusammenarbeit gewählt).

   JP Software und Novell geben verschiedene Hinweise bezüglich Einstel-
   lungen der TASKMGR.INI Konfigurationsdatei. Eigene Erfahrungen münden
   jedoch in der Erkenntnis, daß es derzeit nur 5 Kombinationen gibt, in
   der 4DOS mit dem TASKMGR in seinen unterschiedlichen Betriebsarten
   zurechtkommt, leider nur zwei, in den beide Modi des TASKMGR ohne
   Umkonfiguration stabil arbeiten (natürlich muß für den Multitasking-
   Betrieb zusätzlich die Voraussetzung via EMM386 /MULTI=on geschaffen
   worden sein) und nur eine, die als wirklich stabil angesehen werden kann:


   Eine Übersicht über die 5 Kombinationsmöglichkeiten:

      TASKMGR.INI:   4DOS.INI:    TASKMGR Multitasker  Prozeßumschalter
      [Shell]        [Primary]

   1. Exec=True      UMBLoad=Yes           Ja        (Nein) Ja mit Update 15
   2. Exec=True      UMBLoad=No            Ja               Ja
   3. Exec=False     UMBLoad=No            Ja               Ja

   Jede dieser Möglichkeiten hat verschiedene Vor- und Nachteile:

   Bei (1) müssen Sie darauf achten, daß der TASKMGR nur im Multitasking-
   Modus startet (d.h. /MULTI=on bei EMM386 und genug freier Speicher und
   noch kein anderer Multitasker - wie MS Windows - gestartet), ansonsten
   wird Ihr Rechner abstürzen (nach meinen Tests zumindest bis zur ersten
   Version von Update 15).
   Diese Kombination hat den Vorteil, daß man mit UMBLoad=Yes ca. 3 KByte
   DOS-Speicher einsparen kann, aber wegen Exec=True Probleme mit auto-
   matisch gestarteten Batchjobs bekommt (siehe unten) (und außerdem den
   gewonnenen Speicher wieder verliert). Diese Kombination kann als wirk-
   lich stabil angesehen werden.
   Mit Update 15 hat sich das Verhalten stark stabilisiert, ich habe jetzt
   quasi keine Probleme mehr mit dem Multitasker und dem Prozeßumschalter
   unter 4DOS 5.5c und 4DOS 5.52 (mit Einschränkungen 4DOS 5.51). Beim
   Prozeßumschalter sollten neue Tasks allerdings nach wie vor nur über
   TASKMGR /c %ComSpec% gestartet werden und nicht über <Ins>, JP Software
   gibt dies nur für Exec=FALSE an.

   Bei (2) und (3) brauchen Sie nicht darauf achten, in welchem Modus der
   TASKMGR startet, aber mit UBMLoad=No haben Sie ca. 3 KByte weniger Basis-
   speicher zur Verfügung. Ob Sie dann Exec=True oder Exec=False wählen,
   hängt von den Randbedingungen ab; solange nichts anderes gefordert ist,
   sollten Sie Exec=False verwenden. Diese Kombinationen arbeiten mit
   4DOS 5.5b ziemlich stabil, wenn man das System aber total ausreizt
   und 'absichtlich an die Grenzen der Möglichkeiten des TASKMGR geht',
   kommt es hier ab und zu zu reproduzierbaren Abstürzen mit Speicher-
   schutzfehlern, die aber leider nicht genauer zugeordnet werden können.


   Die Variable %ComSpec% sollte auf 4DOS.COM weisen, wenn mit 4DOS ge-
   arbeitet wird (aber natürlich nur dann, siehe andere Tips).

   Zusätzlich sind auch andere Empfehlungen für TASKMGR.INI und PNWLOGIN.SCR
   (aus *diesem* Dokument) zu beachten.

   Sofern man eine EGA-/VGA-Karte besitzt, ist es generell besser, TASKMGR
   mit der Option /F zu starten (da dadurch Zeichensätze für jeden Prozeß
   einzeln gesichert werden).

   Beim Laden einzelner Prozesse des bereits aktiven TASKMGR (Prozeßum-
   schalter und Multitasker) wird empfohlen, diese nur über die Kommando-
   zeile zu starten (dies scheint mittlerweile nicht mehr notwendig zu sein,
   erst recht nicht mit Exec=True, ich starte mit Update 15 jedenfalls die
   Tasks üblicherweise über das TASKMGR Menü):

   TASKMGR /c %ComSpec%

   Das Beenden geschieht dann über den DOS-Befehl EXIT (dies gilt auch für
   die Direktive Exec=TRUE in TASKMGR.INI). EXIT klappt allerdings nicht,
   wenn Exec=FALSE gesetzt ist.

   Leider ergeben sich durch Exec=TRUE einige Schwierigkeiten, wenn man
   TASKMGR aus einem Batchjob (AUTOEXEC.BAT) heraus mit diversen Hinter-
   grundprozessen starten möchte. Mit 4DOS lassen sich diese Probleme über
   Tricks mittels automatischer Batchjobs 4START.BAT lösen.
   Leider scheint es derzeit keine Möglichkeit zu geben, TASKMGR direkt
   dazu überreden zu können, seinen Root-Prozeß weiter zu bearbeiten (der
   aufrufende Job wird erst mit Beenden des TASKMGR weiterbearbeitet).
   Dadurch ist es mit Exec=TRUE z.Z. nicht möglich, schon aus AUTOEXEC.BAT
   heraus ein paar Hintergrund-Tasks für Serviceaufgaben zu starten
   (Viren-Scanner, etc.) - ich habe bereits etliche erfolglose Versuche
   unternommen :-(. Dies bezieht sich aber nur auf die Startphase von
   TASKMGR, zusätzliche Prozesse können sehr wohl aus einem Batchjob heraus
   gestartet werden, nach wenigen Sekunden (Ladephase der Prozesse) schaltet
   der TASKMGR jeweils wieder auf den alten Vordergrundtask um.

   Ganz generell sollte man übrigens darauf achten, daß der Wechsel des
   Vordergrundprozesses nicht in einem Moment vorkommt, wo ein anderer
   Prozeß geladen wird. Zumindest auf meinem System kommt es in solchen
   Fällen immer wieder zu EMM386 Seitenausnahmefehlern im neu gestarteten
   Task, sowohl mit COMMAND.COM als auch mit 4DOS.COM (Exec=True).
   Normalerweise wartet der TASKMGR einige Sekunden mit der Umschaltung
   zum aufrufenden Task, in Einzelfällen kann aber diese Phase zu kurz
   sein. Dann sollte man manuell eingreifen und *während* des Ladens des
   neuen Prozesses das TASKMGR-Menü aktivieren und explizit auf den neuen
   Task zurückschalten. Besonders kritisch scheinen Programme zu sein, die
   XMS oder DPMI benutzen.

   Es ist also noch keine generelle Entwarnung für das Problem der Kombi-
   nation von 4DOS mit Novell DOS' TASKMGR gegeben.
   Bei Beachtung der obigen Hinweise kann man jedoch NWDOS und 4DOS zu
   stabil laufenden Multitasking-Systemen kombinieren. Sollte jemand andere
   Erfahrungen gemacht haben, wäre ich für entsprechende Hinweise dankbar.

                                                                             
  ---------------------------------------------------------------------------

  VII.4. TASKMGR Multitasker in Verbindung mit 4DOS aus Batchjobs aktivieren:
  ==============================================================[96-04-20]===

   Stichworte: TASKMGR, 4DOS, Batchjobs, Background-Tasks, TASKMGR.INI,
               Resynchronisation, Exec=TRUE, 4START.BAT, AUTOEXEC.BAT,
               Viren-Scanner, AUTOEXEC.BAT, 4START.BAT

   Im vorausgehenden Abschnitt wurden schon einige detaillierte Hinweise
   für das stabile Zusammenspiel des TASKMGR mit 4DOS gegeben.
   Dabei wurde auch angesprochen, daß mit der teilweise notwendigen
   Direktive Exec=TRUE in der Datei TASKMGR.INI auch eine komfortable
   Möglichkeit flachfällt, z.B. direkt beim Booten des Rechners ein paar
   Hintergrundtasks für Serviceaufgaben anzuwerfen, die etwa die Platte nach
   Viren durchsuchen, Verzeichnisse überprüfen und reorganisieren (geht mit
   Einschränkungen auch unter einem Multitasker) und und und...

   Das Problem entsteht dadurch, daß der TASKMGR - aus einem Batchjob wie
   AUTOEXEC.BAT gestartet - normalerweise nach wenigen Sekunden, die er dem
   neuen Task für seine Initialisierung einräumt, auf den alten Task zurück-
   schaltet und z.B. den Batchjob fortsetzt - nicht so mit Exec=TRUE.

   Auf der Kommandoebene von Novell DOS scheint es keine Möglichkeiten zu
   geben, dieses Problem zu umgehen (Manipulationen der Variable %ComSpec%
   führen wohl nicht zum Erfolg, evtl. würde es über simulierte Tastatur-
   eingaben z.B. mit KEYSTACK/KSTACK oder K3PLUS/FreeKEYB funktionieren,
   aber unter einem Multitasker, der sich gerade in der Umschaltphase
   zwischen Tasks befindet, ist auch das auch nicht unbedingt sicher).

   4DOS bietet jedoch eine Möglichkeit der Abhilfe in Form von optionalen
   4START.BAT-Jobs, die beim Starten von 4DOS.COM (als primäre oder
   sekundäre Shell) noch vor AUTOEXEC.BAT und dem Erscheinen des Prompt-
   zeichens abgearbeitet werden.

   Eine einzelne 4START.BAT Datei ist allerdings viel zu unflexibel für
   solche Aufgaben. Mit ein paar Tricks läßt sich aber ein Workaround
   realisieren, das der fortgeschrittene 4DOS-Anwender leicht an seine
   Bedürfnisse anpassen kann (und muß, denn es gibt hierbei einige
   implizite Voraussetzungen, die aber der Anschaulichkeit halber nicht
   aufgelöst wurden):


   AUTOEXEC.BAT:

    @ECHO off > \dev\nul
    REM Flexibler Resychronisationssprung:
    IF NOT ""=="%1" GOTO %1
    ...
    REM @CALL c:\nwclient\startnet.bat
    ...
    REM Erzeuge temporären Resync-Job:
    REM Erster ECHO Parameter bezeichnet d. Job, der von 4START.BAT
    REM aufgerufen werden soll, der zweite Parameter die anzuspringende
    REM Resync-Marke, weitere Parameter sind natürlich optional noch
    REM möglich.
    ECHO @c:\autoexec.bat resync > %tmp%\4start_.bat

    REM Starte TASKMGR Multitasker (Exec=TRUE) mit 4DOS:
    REM 4DOS wird 4START.BAT automatisch aktivieren.
    @CALL TASKMGR /f
    REM Kommt hier erst nach Beenden aller Tasks hin zurück.
    GOTO end

    :resync
    REM Sehr wichtig, um Rekursion und Task-Überläufe zu verhindern!
    DEL %tmp%\4start_.bat > \dev\nul

    REM Ein paar Beispiele:
    @CALL TASKMGR /c vir_scan.bat
    @CALL TASKMGR /c diskfix c: d: e: f: /test
    GOTO end

    :end
    REM Ende der AUTOEXEC.BAT


   4START.BAT:

    @IF EXIST %tmp%\4start_.bat %tmp%\4start_.bat

   Der Trick besteht darin, daß über einen temporär erzeugten Job wieder in
   den alten Ablauf zurückgesprungen wird.

   Wichtig:

   - %ComSpec%, %tmp%, %NWDOSCFG% und %Path% müssen richtig gesetzt sein.
   - Exec=TRUE in TASKMGR.INI (damit dieser Aufruf arbeitet, nach Kapitel
     VII.3. nicht unbedingt erforderlich für den TASKMGR in Verbindung mit
     4DOS, wohl aber für dieses Beispiel).
   - Der TASKMGR muß als Multitasker starten können (dazu muß genug Speicher
     vorhanden sein und EMM386 /MULTI=on muß aktiviert sein).
   - Die Datei 4START.BAT muß für 4DOS auffindbar sein, notfalls mit einer
     Direktive 4StartPath= in 4DOS.INI.
   - Die Marke :end muß am Ende der AUTOEXEC.BAT stehen, danach darf nichts
     weiteres mehr kommen, sonst würde TASKMGR dies bearbeiten, nachdem alle
     Tasks geschlossen wurden.

   Über solche Tricks ist es sogar möglich, für komplizierte Verwaltungs-
   aufgaben die Multitasking-Fähigkeiten des Systems voll auszunutzen und
   eine regelrechte Kommunikation der Batchjobs mittels 'Message-Dateien'
   aufzubauen (allerdings ist dies für Laien kaum machbar, da Multitasking,
   Prozeß-Synchronisation und Parallelisierung eine ganze Vielzahl von
   möglichen Fallstricken (Deadlocks, Rekursionen u.a.) mit sich bringen,
   die man sonst nicht beachten muß, wenn man *nur* mehrere unabhängige
   sequentielle Abläufe oder Applikationen anwendet, siehe Kapitel VII.5.).
   Es ist übrigens aus diesen Gründen eben gerade nicht möglich, diese
   Minimalform der Kommunikation (wie im Beispiel) statt über eine Datei
   über Umgebungsvariablen abzuwickeln (es wäre ja soviel komforta-
   bler...), dies würde fast unweigerlich zu Rekursionsüberläufen führen,
   der TASKMGR würde permanent neue Tasks erzeugen.

                                                                             
  ---------------------------------------------------------------------------

  VII.5. TASKMGR & Multiuser-Betrieb: [97-03-04]
  ==============================================

   Stichworte: DR DOS, Multitasking, Ressourcen-Sharing, Server, Host, PNW,
               TASKMGR, UART, FIFO, IRQ, CTTY, CON, PROCOMM

   Digital Research (der Entwickler von DR DOS, dem Vorgänger von
   Novell DOS) bot schon immer spezielle DOS-Clones mit Multitasking-
   und Multiuser-Funktionen an (Concurrent PC-DOS, Concurrent CP/M,
   Concurrent DOS, DR Multiuser DOS, etc.). Soweit mir bekannt, brauchte
   dazu z.B. bei DR Multiuser DOS 5 lediglich ein spezieller Treiber
   geladen werden, der wohl auch mit DR DOS 6 arbeitete. Zu anderen
   Multiuser-Betriebssystemen von Digital Research habe ich leider keine
   Informationen (Info wanted!).

   Fest steht, daß Novell DOS 7 einerseits im Bereich 'Multiuser' zugelegt
   hat, indem wesentliche Funktionen eines solchen Systems, etwa im Bereich
   Netzwerk - wenn auch mit anderer Ausprägung - nun in Form der Personal
   NetWare direkt mitgeliefert werden.
   Außerdem bieten viele der externen Novell DOS Programme - wenn auch
   undokumentiert - definitiv spezielle Funktionen für DR Multiuser DOS an,
   manche dieser Programme sogar schon bei DR DOS 6.0 (siehe Kapitel II.4.
   und II.9.). Laut Insider-Aussagen stammt Novell DOS 7 sogar ursprünglich
   von DR Multiuser DOS und nicht - wie oft angenommen - von DR DOS 6.0 ab.
   Es gibt einige Fakten, die dies bestätigen würden, allerdings besteht
   auch eine große Ähnlichkeit zu DR DOS 6.0.
   Dies deutet darauf hin, daß die zukünftige Entwicklung offenbar die
   beiden Produktlinien Multiuser und Singleuser vereinen sollte, und das,
   obwohl Novell 1993 den Support für DR Multiuser DOS 5.0 und 5.1 selbst
   eingestellt und an Fremdfirmen abgegeben hat (siehe Kapitel IX.11.,
   die Firma Concurrent Controls Inc. bietet derzeit (03/1997) ein
   Multiuser DOS 7.22 Gold als kostenlose Demo an). Im April 1994 wurde die
   Weiterentwicklung von Novell DOS 7 ebenfalls eingestellt (einmal von den
   Updates und Support abgesehen, die erst Anfang 1996 eingestellt wurden).
   Offenbar war bis zu diesem Zeitpunkt also eine Integration geplant.
   Inwieweit die Novell DOS 7 Programme unter einem existierenden DR Multi-
   user DOS arbeiten, kann ich in Ermangelung dieses Betriebssystems leider
   nicht herausfinden. Andererseits wurden aber auch einige diesbezügliche
   API-Funktionen, die DR DOS 6.0 - ohne irgendwelche zusätzlichen Treiber -
   bereits ab Kernel anbot (etwa File-Owner) wieder entfernt und werden von
   Novell DOS 7 nicht mehr unterstützt, siehe z.B. Ralf Browns Interrupt-
   Liste (s.o.).

   Eine dem Multiuser-Betrieb ähnliche Konstellation (aber ohne ent-
   sprechende Verwaltungs- und Schutzmechanismen) kann man auf zweierlei
   Weise auch unter Novell DOS erzeugen.

   Die erste Möglichkeit besteht in der Verwendung der Personal NetWare,
   mit der man allerdings nur Ressourcen (wie Laufwerke und Drucker) eines
   anderen Rechners und nicht direkt Rechenleistung nutzen kann.
   Die andere Möglichkeit besteht in der Verwendung des TASKMGR als Multi-
   tasker und ist sehr einfach zu realisieren, indem man über serielle
   Schnittstellen mehrere entfernte Rechner als Terminals an einen Haupt-
   rechner anschließt.

   Hierzu sind Nullmodem-Kabel und möglichst schnelle UART-Chips notwendig
   (allerdings kann man bei geringer Auslastung durchaus noch auf Chips mit
   FIFO verzichten). Nach der Verkabelung und der Einstellung der Schnitt-
   stellenparameter, die bei jedem Schnittstellenpärchen übereinstimmen
   müssen, kann man loslegen. Achtung: Es sollte möglichst keine IRQ-Doppel-
   belegungen geben. Novell weist in ihren FaxBack-Dokumenten darauf hin,
   daß ein Hintergrundbetrieb von seriellen Schnittstellen (auch) unter dem
   (multitaskenden) TASKMGR offiziell nicht unterstützt wird (serielle
   Schnittstellen werden nicht oder zumindest nur teilweise virtualisiert),
   allerdings gibt es verschiedene Einstellungen, die eine solche Betriebs-
   art u.U. trotzdem problemlos arbeiten lassen. Dazu sollte man in
   TASKMGR.INI die folgenden Einstellungen vornehmen:

   [Slice]
   Foreground=1
   # Das Verhältnis von Vordergrund- zu Hintergrund-Tasks, d.h. die Anzahl
   # der 'Ticks', die der Vordergrund-Task am Stück arbeiten darf, ehe der
   # Scheduler/Dispatcher (es handelt sich um preemtives Multitasking)
   # wieder zuschlägt. Bei mir tat es auf einem 386sx18 auch das i. allg.
   # sinnvollere Foreground=10.

   # Granularität des Systemtakts in Einheiten von 1/18,2 Sekunden,
   # mit denen der Scheduler/Dispatcher intern arbeitet.
   # (sollte normalerweise sowieso 1 sein!!!)
   TickRate=1

   [COMx]
   # Es werden COM1-COM4 bzw. LPT1-LPT3 unterstützt.
   # Der Timeout-Wert erlaubt die folgenden Einstellungen:
   # AUTO       = Default-Einstellung, offenbar 5 Sekunden für COMx und
   #              15 Sekunden für LPTx.
   # 0          = Die Schnittstelle wird nicht virtualisiert, d.h. alle
   #              Task können ohne Overhead direkt auf der Hardware ar-
   #              beiten, was natürlich bei unkoordiertem, d.h. gleich-
   #              zeitigem Zugriff zum Chaos führt.
   # 1..65534   = Die Angabe eines Timeout-Wertes virtualisiert die
   #              Schnittstelle. Durch den Zugriff eines Tasks auf die
   #              Schnittstelle wird dieser Task der Eigentümer der
   #              Schnittstelle. Der Zugriff für andere Tasks bleibt
   #              vorerst gesperrt. In der ersten Halbzeit des Timeouts
   #              hat der Task vollen Zugriff auf die Schnittstelle, danach
   #              klinkt sich der Multitasker wieder ein und überprüft, ob
   #              der Task die Schnittstelle noch benutzt. Benutzt der
   #              Task die Schnittstelle innerhalb der zweiten Hälfte des
   #              Timeouts, so zieht sich der Multitasker sofort wieder
   #              zurück. Ansonsten wird die Schnittstelle nach Ablauf des
   #              Timeouts wieder für den allgemeinen Zugriff freigegeben,
   #              bzw. dem nächsten wartenden Task zugeordnet.
   # 65535 = -1 = Unbegrenzter Timeout, d.h. sobald ein Task die Schnitt-
   #              stelle angesprochen hat, bleibt sie bis zum Beenden des
   #              Tasks für alle anderen Tasks gesperrt.
   TimeOut=65535

   [Shell]
   Idle=FALSE
   # Schaltet die dynamische Wartezeiterkennung ab. Bei mir funktionierte
   # auch das i. allg. sinnvollere Idle=TRUE.

   [Mouse]
   # MousePort=AUTO   Hier sollte man die COM-Adresse der Maus,
   #                  verringert um eins, angeben
   # MouseIRQ=AUTO    Hier sollte man den wirklichen IRQ der Schnittstelle
   #                  angeben. (COM1 und COM3 üblicherweise 4, COM2 und
   #                  COM4 meist 3.)

   Der TASKMGR/TASKMAX als Prozeßumschalter ist logischerweise nicht für
   eine serielle Verbindung im 'Hintergrund' geeignet. Trotzdem ist es
   auch hier oft praktisch, eine serielle Verbindung in einer Anwendung
   aufzubauen und in Übertragungspausen auf eine andere Applikation
   umschalten zu können. In diesem Fall ist es bei Telefonverbindungen
   allerdings wichtig, daß sowohl das Modem, als auch das Kommunikations-
   programm so konfiguriert werden, daß sie den Status der DTR-Leitung
   (data terminal ready) ignorieren, sonst würde das Modem nämlich beim
   Umschalten in den Hintergrund die Telefonverbindung unterbrechen.

   Auf dem Hauptrechner (dessen Rechenleistung genutzt werden soll) wird
   der TASKMGR als Multitasker gestartet und in jedem Task, der durch ein
   Host-Terminal genutzt werden soll, aktiviert man CTTY COMx (dies kann
   man auch schon in der Aufrufzeile von COMMAND.COM sowie bei SHELL= an-
   geben, siehe Kapitel II.11. und III.1.). (Der Prozeßumschalter bietet
   in diesem Zusammenhang die evtl. interessante undokumentierte Option
   /R=devicename, der Multitasker bietet diese Option aber nicht.)
   Auf dem jeweiligen Host-Rechner lädt man ein Terminal-Programm wie z.B.
   PROCOMM (dieser Rechner kann durchaus auch wieder unter dem TASKMGR als
   Multitasker laufen, wodurch man in anderen Tasks auch lokal arbeiten
   kann). Im Terminalbetrieb erscheinen alle Ausgaben an DOS-CON nun auf
   dem Fremdrechner und alle Eingaben werden übermittelt. Dabei kann der
   TASKMGR des Hauptrechners in jedem laufenden Task andere Schnittstellen
   bedienen.

   Es ist sogar möglich, gleichzeitig noch das Netzwerk zu laden und
   den Hauptrechner auch zum File-Server zu machen, wodurch man auch den
   direkten Dateizugriff auf dem Hauptrechner bekommt. Solange man die
   Kommandozeile verwendet, kann man so auch den Netzwerk-Server fernbe-
   dienen. Trotzdem ist diese Kombination etwas paradox, schließlich muß
   einerseits eine Netzwerkverkabelung (bei Ethernet meist Strang) und
   eine sternförmige Verkabelung mit seriellen Kabeln installiert sein.
   Theoretisch sollte es aber mit entsprechenden Treibern möglich sein,
   serielle Datenströme auf ein anderes Gerät umzuleiten, etwa durch das
   Netz zu 'tunneln' oder umgekehrt den Netzverkehr über serielle Schnitt-
   stellen abzuwickeln: Sollte jemand mit solchen Lösungen (auch unabhängig
   von der 'Multiuser'-Idee) Erfahrungen gesammelt haben, wäre ich für
   Hinweise dankbar (ein paar Ideen finden sich in Kapitel II.8.).

   Einziger Nachteil: Alle Programme müssen so konfiguriert werden, daß sie
   für Ein- und Ausgaben ausschließlich DOS verwenden, ansonsten ist es
   möglich, daß man vom Host aus ein Programm auf dem Server aufruft, das
   weitere Eingaben über das BIOS abwickelt oder seine Ausgaben über BIOS
   oder direkten RAM-Zugriff auf dem Server und nicht auf dem Host anzeigt.
   Dadurch verliert der Host die Kontrolle über seinen Task auf dem Haupt-
   rechner und das Programm muß dann direkt am Hauptrechner beendet werden
   (der natürlich in lokalen Tasks auch anderweitig genutzt werden kann).

   Auch das wechselseitige Nutzen von Rechenleistung ist möglich, wenn
   auf allen Rechner der TASKMGR als Multitasker geladen wird und in einem
   Task immer ein Terminalprogramm mit der Verbindung zum anderen Rechner
   läuft. So ließe sich zumindest theoretisch eine optimale Ausnutzung der
   auf bestimmten Rechnern vorhandenen Ressourcen erreichen, in der Praxis
   scheitert dies jedoch meistens daran, daß die Anzahl der ausschließlich
   DOS verwendenden Programme beschränkt ist.

   Nachbemerkung: Eine Anwendung für diese Möglichkeiten ist bei mir seit
   einiger Zeit unter dem Projektnamen JOBMGR in Entwicklung. Die bisherigen
   Ergebnisse sind recht erfolgversprechend. Am Horizont steht ein Steuer-
   programm (selbst realisiert unter ausschließlicher Verwendung der Batch-
   Sprache!!!), das ein DOS-Netz (wie z.B. PNW oder NetWare) und/oder
   einen multitaskenden Novell DOS 7 TASKMGR so nutzen können wird, daß
   Unix-konform Aufträge (Batchjobs) abgeschickt werden können, die dann im
   Hintergrund (in anderen lokalen Tasks oder - im Netzverbund - auf
   anderen Rechnern) ausgeführt werden. Einerseits gibt es damit eine
   Möglichkeit, Rechenleistung anderer DOS-Rechner zu nutzen (z.B. im
   Netz einen 'Job-Server' einzurichten) und andererseits bietet das Konzept
   den Komfort der sofort zurückkehrenden Kommandozeile und erweitert
   Batchjobs um 'Multithreading' und 'Parallelprocessing'-Funktionen sowie
   neue Möglichkeiten in der Zeitsteuerung (permanente Prozesse, AT, etc.).
   Die Netzfunktionen sollen auch mit anderen DOS-Versionen als
   Novell DOS 7 arbeiten, für den Multitasker ist Novell DOS 7 natürlich
   notwendige Voraussetzung.

                                                                             
  ---------------------------------------------------------------------------

  VII.6. TASKMGR und LOCK:
  ========================

   Stichworte: LOCK, TASKMGR, permanenter Prozeß

   Die Verwendung der Zeitoption LOCK /T kann unter dem TASKMGR nicht
   richtig arbeiten. LOCK sollte deshalb vor TASKMGR geladen werden.
   Speziell für den TASKMGR gibt es eine Möglichkeit, LOCK als permanenten
   Prozeß zu laden:

    TASKMGR /C LOCK password /P

   wobei password das Paßwort zum Entsperren des Systems darstellt.

   Achtung: LOCK.EXE von Novell DOS 7 hat absolut nicht mit den bei MS-DOS 7
   (MS Windows95/Chicago) neuen internen Befehlen LOCK und UNLOCK zu tun!!!

                                                                             
  ---------------------------------------------------------------------------

  VII.7. Tastaturprobleme unter dem multitaskenden TASKMGR: [96-05-29]
  ====================================================================

   Stichworte: Tastatur; 'klebende' Modifizierzustände

   Auf langsamen Rechnern kommt es schon mal vor, daß beim Editieren von
   Dateien unter dem multitaskenden TASKMGR unmotiviert Geistertastendrücke
   wie die Zahlen '2', '4', '6' oder '8' eingestreut werden oder die Shift-
   Zustände (<Shift>, <Alt>, <Ctrl>) plötzlich verändert sind. Dies ist kein
   Problem oder Bug des TASKMGR, sondern liegt an der nicht gerade idealen
   Realisierung des Tastatur-Interfaces AT-kompatibler Rechner, bzw. der
   Programme, die dieses Interface bedienen. Ich möchte an dieser Stelle
   nicht auf Details eingehen (wer sich dafür interessiert, kann z.B. im
   Dokument IA.TEC von Quarterdeck oder der Anleitung zum erweiterten
   Tastaturtreiber K3PLUS/FreeKEYB Hintergrundinformationen finden).
   Das Problem ist auch nicht an den TASKMGR gebunden, sondern kann auch
   sonst auftreten, das Auftreten ist aber mit Programmen wie dem TASKMGR,
   EMM386-Treibern und bei hoher System-/Interrupt-Auslastung sehr viel
   wahrscheinlicher, sobald der Fehler latent vorhanden ist.

   Das Problem wird i. allg. durch ein altes Programm oder einen alten
   Treiber verursacht, das/der den Tastatur-Interrupt INT09h statt
   INT15h/4Fh etc. benutzt. Dabei muß dies nicht notwendigerweise das
   zuletzt installierte Programm sein. Abhilfe ist entweder ein Update
   des betreffenden Programms (falls man tatsächlich den wahren Übeltäter
   ermitteln kann, was aufgrund der Natur des Fehlers sehr schwer ist,
   es sei denn, man kennt den Quellcode der Programme), oder als Workaround
   eine verminderte Keyboard-Repeat-Rate (MODE), ein schnellerer Rechner,
   weniger (interruptintensive) Hintergrund-Tasks, ein schnellerer Editor
   (die BP IDE ist z.B. äußerst träge bei eingeschaltetem Syntax-High-
   lighting), keinen PNW Server auf diesem Rechner laden...

   Im konkreten Fall können Sie die Shift-Zustände (Blockmarkierungen
   etc.) wieder normalisieren, indem Sie die drei linken Modifizierer-
   tasten (<Shift>, <Ctrl>, <Alt>) jeweils nacheinander drücken und wieder
   loslassen. Verwenden Sie möglichst nicht die Cursor-Tasten und den grauen
   Sechserblock einer MF2-Tastatur (viele Editore erlauben auch auf andere
   Weise das Navigieren im Text, z.B. über die WordStar-Belegung mit
   <Ctrl>+<s>, <Ctrl>+<d>, <Ctrl>+<e>, <Ctrl>+<x>).

   Klemmt die Tastatur als Ganzes, hilft es häufig, kurz das TASKMGR-Menü
   aufzurufen und wieder zu verlassen, denn dabei wird auch das Tastatur-
   Interface neu initialisiert.

   (Weitere Hinweise willkommen...)

                                                                             
  ###########################################################################
  ###########################################################################

  VIII. NOVELL DOS 7 UND MS WINDOWS 3.xx:
  =======================================

  ---------------------------------------------------------------------------

  VIII.1. Novell DOS und MS Windows 3.xx kombinieren: [97-02-12]
  ==============================================================

   Stichworte: Beta-Windows, DR DOS, AARD, Redirektor, Umadressierer, SETUP,
               SYSTEM.INI, SHARE, NWCACHE, TBIM2.COM, VCPI, DPMI, PNW,
               NETWARER.DRV, %NWLanguage%, WINA20.386, NWDOS.386, TASKMGR,
               DOSPRMPT.PIF, %ComSpec%; VLM-Kit VLM121

   Novell DOS ist mit MS Windows 3.xx kompatibel. Trotzdem kann es - wie
   mit jedem DOS als Grundlage - eine Reihe Probleme geben, die man schnell
   beseitigen kann, wenn man die Ursachen kennt. (Diese Beschreibung bezieht
   sich hauptsächlich auf MS Windows 3.1 und 3.11.)

   Deshalb hier einige Anmerkungen:


   i. Der AARD-Code - eine peinliche 'Historie':
   ---------------------------------------------

   Manche späten Beta-Versionen von MS Windows 3.1 konnten unter DR DOS
   (dem Vorgänger von Novell DOS) nicht gestartet werden, es erschien eine
   suspekte Fehlermeldung:

   Nicht fataler Fehler: Nr: #2726
   Bitte wenden Sie sich an den Beta-Support für Microsoft Windows.

   Danach wurde die Ausführung von WIN.COM abgebrochen. Nach genauen
   Analysen konnte der Code, der dieses Verhalten erzeugt, isoliert
   werden; er ist unter dem Namen AARD-Code bekannt geworden und in
   diversen Büchern und Zeitschriften publiziert worden. Dieser ver-
   schlüsselte und hochgradig selbstmodifizierende Code (der sogar
   Debugger abhängt) überprüft eine Reihe undokumentierter Eigenschaften
   von DOS (dies ist auch einigermaßen legitim - ohne Unterstützung
   dieser Fähigkeiten würde Windows nicht arbeiten können), gegen Ende
   aber noch eine wild aus dem Zusammenhang gerissene Bedingung
   (Redirector/System FCB/Case Map Test), die in keiner Weise für die
   ordnungsgemäße Funktion von Windows relevant war (dies wurde mittler-
   weile ebenfalls nachgewiesen).
   Bei dieser Überprüfung fiel DR DOS (und frühe Beta-Versionen von
   Novell DOS) durch; MS-DOS, PC-DOS und OEMs wurden akzeptiert.
   In der Final-Release von Windows 3.1 ist dieser Code weiterhin enthalten
   (jeder braucht nur mit einem Hex-Editor nach der Fehlermeldung oder der
   Zeichenkette 'AARD' in WIN.COM oder SETUP.COM und manchen anderen Dateien
   zu suchen), allerdings vorübergehend außer Funktion gesetzt: Der Code
   wurde so erweitert, daß eine zusätzliche interne Variable überprüft wird.
   Wenn diese den Wert 0 hat, wird die Fehlermeldung übersprungen, hat sie
   einen anderen Wert, geschieht dasselbe wie bei der Windows Beta-Version.
   D.h. durch gezieltes Ändern eines einzigen Bytes könnte dieser Prüfcode
   wieder aktiviert werden, und damit DR DOS abwehrt werden.
   Microsoft hat die Existenz des AARD-Codes 'im Prinzip nicht dementiert'
   (Microsoft Deutschland hat die Existenz dieses Codes sogar offen zuge-
   geben) - jeder mag sich seinen Teil dabei denken...

   Wenige Tage nach dem Erscheinen von MS Windows 3.1 hatte Digital Research
   allerdings ein 'Business' Update für DR DOS 6.0 herausgegeben, daß neben
   verschiedenen anderen Anpassungen und Bugfixes auch diese Überprüfung
   umging. Leider hat die Öffentlichkeit von diesem und einigen anderen
   Updates zu wenig erfahren, deshalb wurde DR DOS oft als nicht mit
   MS Windows 3.1 kompatibel abgestempelt (obwohl es ja zum Teil eher
   umgekehrt war) - nach diesem Update gab es keine Probleme mit DR DOS
   und MS Windows 3.1...


   ii. Modifikationen am Windows-System durch Novell DOS SETUP:
   ------------------------------------------------------------

   Bei der Installation von Novell DOS nimmt das Setup-Programm einige
   Anpassungen des Windows-Systems vor. Sollten Sie MS Windows jedoch
   erst später installieren oder updaten, müssen Sie diese Einstellungen
   per Hand vornehmen (besonders wichtig, da oft vergessen: TASKMAN.EXE=).
   Dies kann auch notwendig sein, wenn Sie eine Netzinstallation von
   Windows vornehmen:

   Folgende wichtige Modifikationen werden u.a. in SYSTEM.INI gemacht:

   Im Abschnitt [boot]:            network.drv= wird ersetzt durch
                                   network.drv=netware.drv
                                   (Dies lädt die 'NetWare user'
                                   Programme, evtl. in dieser Form nur
                                   für PNW notwendig)

                                   taskman.exe=taskman.exe
                                   wird ersetzt durch
                                   taskman.exe=c:\nwdos\TASKMGR.EXE
                                   (oder ein entsprechendes anderes
                                   Verzeichnis z.B. \WINDOWS\)

                                   Sie sollten sicherstellen, daß die
                                   Datei TASKMGR.EXE auch bei Novell DOS
                                   Updates mit upgedatet wird. Die Kopie
                                   in das Windows-Verzeichnis wird dabei
                                   häufig vergessen.

   Im Abschn. [boot.description]:  network.drv= wird ersetzt durch
                                   network.drv=Personal NetWare (V1.0)
                                   (Dies definiert, welche Personal NetWare
                                   Geräteversion Sie verwenden, natürlich
                                   nur bei PNW so notwendig.)

   Im Abschnitt [386Enh]:          network=dosnet wird ersetzt durch
                                   network=*vnetbios;vipx.386;vnetware.386
                                   (Dies legt den Typ des Netzes fest,
                                   der mit dem Erweiterten 386er Modus von
                                   MS Windows verwendet wird.)

                                   Diese Einstellungen galten auch schon für
                                   NetWare Lite:

                                   TimerCriticalSection= wird ersetzt durch
                                   TimerCriticalSection=10000
                                   (Personal NetWare verwendet diese
                                   Einstellung, um sicherzustellen, daß
                                   der Netzverkehr auf Ihrem Computer
                                   gleichmäßig verläuft. Angeblich soll
                                   notfalls auch noch 500 laufen.)

                                   ReflectDOSInt2A=TRUE wird hinzugefügt.

                                   OverlappedIO=OFF wird hinzugefügt.

                                   PSPIncrement=5 wird hinzugefügt.

                                   UniqueDOSPSP=TRUE wird hinzugefügt.

                                   device=fastback.386 wird für FastBack-
                                   Software hinzugefügt, aber nur bei
                                   Floppy-Backups (nicht lokale Festplatten
                                   oder Netzlaufwerke) benötigt. Dieser
                                   Treiber verträgt sich nicht mit QIC80-
                                   Streamer-Software (z.B. QBACKUP-Win für
                                   "IOMega insider 250") im Erweiterten
                                   386er-Modus, muß daher häufig wieder ent-
                                   fernt werden. In Novells FaxBack-Doku-
                                   menten wird auf Probleme beim Formatieren
                                   von Cartridges mit IOMegas 250 MByte
                                   Floppy-Streamer unter Novell DOS 7 be-
                                   richtet; ich hatte allerdings (offen-
                                   sichtlich mit genau diesem Streamer)
                                   keinerlei Probleme. Bei dieser Gelegen-
                                   heit noch ein Hinweis am Rande: IOMegas
                                   QBACKUP 3.x verträgt sich offensichtlich
                                   nicht (immer) mit Logitech-Maustreibern
                                   (aufgefallen mit MouseWare 6.50). Hier
                                   hilft es, den Logitech-Maustreiber für
                                   die Dauer von QBACKUP mit einem anderen
                                   Maustreiber (etwa GMOUSE 10.20) zu über-
                                   laden.

   Im Abschnitt [NetWare]:         NWShareHandles=1  sofern gewünscht

   Im Abschnitt [VIPX]: (siehe auch in Novells VIPX.DOC)

    ; alle Parameter sind optional und nur selten erforderlich:
    VipxMappingPages         =[number of 4K pages] ; <16>
    VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VpicdFix                 =[ON|OFF|TRUE|FALSE]  ; <ON>
    AutoIrqVirtualize        =[ON|OFF|TRUE|FALSE]  ; <ON>
    VirtualizeIrq[0-F]       =[ON|OFF|TRUE|FALSE]  ; <OFF>
    KeepLongLivedSocketsOpen =[ON|OFF|TRUE|FALSE]  ; <OFF>
    ; Diese Parameter existieren nur in Beta-Versionen von VIPX.386:
    VipxErrorMessages        =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VipxWarningMessages      =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VipxBreakOnErrors        =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VipxBreakOnWarnings      =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VipxOutDebugStrOnErrors  =[ON|OFF|TRUE|FALSE]  ; <OFF>
    VipxOutDebugStrOnWarnings=[ON|OFF|TRUE|FALSE]  ; <OFF>


   Folgende Modifikationen werden in WIN.INI gemacht:

   Im Abschnitt [Windows]:         load= wird ersetzt durch
                                   load=nwpopup.exe
                                   (Dies erlaubt die Anzeige von
                                   Netzmeldungen in MS Windows)

                                   Netwarn=1 wird hinzugefügt
                                   (Wenn diese Einstellung aktiviert ist,
                                   das Netzwerk jedoch nicht geladen ist,
                                   zeigt MS Windows bei Start ein PopUp-
                                   Fenster an, das meldet, daß das Netzwerk
                                   nicht geladen ist.)


   Bei der Einrichtung von STACKER wird in WINFILE.INI eingetragen:

   Im Abschnitt [AddOns]:          Stacker Extension=c:\nwdos\stacfm.dll

   Bei dieser Gelegenheit können Sie - sofern Sie nicht mit dem Lösch-
   schutz von MS-DOS arbeiten - im Abschnitt [AddOns] auch einen evtl.
   vorhandenen Eintrag:

   MS-DOS Tools Extentions=c:\msdos\mstools.dll

   und im Abschnitt [Settings] einen Eintrag

   UNDELETE.DLL=c:\msdos\mstools.dll

   von einer vorherigen MS-DOS-Installation entfernen, die Sie nicht mehr
   brauchen.


   Von den Speichermanagern wird nur EMM386 benötigt. Die Parameter /DPMI
   und /MULTI können aktiviert werden; VCPI braucht *nicht* mittels /NOVCPI
   abgeschaltet werden. Der Schalter /WINSTD wird nicht benötigt und auch
   nicht empfohlen, wenn Sie mit MS Windows 3.1 arbeiten. DPMS kann eben-
   falls ohne Probleme genutzt werden.
   Außerdem wird dringend empfohlen, vor MS Windows 3.xx die Novell DOS 7
   Programme SHARE und NWCACHE (notfalls SMARTDRV) zu laden (MS-DOS hat
   SHARE intern realisiert, bei Novell DOS 7 muß man für den gleichen
   API-Umfang das TSR SHARE laden).


   iii. Netzwerk (PNW) Einrichtung für Windows:
   --------------------------------------------

   Ein zu verwendendes Netzwerk (ob NetWare oder PNW) muß vor MS Windows
   geladen werden, wenn man es innerhalb von Windows global einsetzen
   möchte (Ausnahme: siehe Kapitel VI.2. und II.8.).

   Für PNW sind eine ganze Reihe von Dateien im Windows-Verzeichnis nötig.
   Dabei wird von einer lokalen Installation ausgegangen (für eine Windows
   Netzinstallation siehe Kapitel VIII.3.).

   Eine Übersicht gibt die folgende Auflistung:

   c:\windows\taskmgr.exe          Opt., über Pfad auch in C:\NWDOS möglich
   c:\windows\nwdos.grp            Gruppendatei für Novell DOS und PNW
   c:\windows\netware.ini          Einstellungen der PNW-Tools

   c:\windows\nwdrvwin.bmp         Diese Netz-Treiber nur mit dem VLM-Kit
   c:\windows\nwrcon.pif           VLM121_1.EXE - VLM121_6.EXE...
   c:\windows\loginw31.exe         Diese Datei ist für PNW nicht unbedingt
                                   erforderlich.

   c:\windows\system\bwcc.dll      Für Search & Destroy Viren-Scanner,
                                   siehe Kapitel II.4. bei WSDRES/WSDSCAN
   c:\windows\system\fastback.386  Für Fifth Generation FBWX

   c:\windows\system\netware.hlp   Hilfedatei für Netz-Tools wie NWUSER.EXE
                                   Nur bei PNW *hier*, mit VLM121_1.EXE
                                   bis VLM121_6.EXE dagegen in
                                   C:\WINDOWS\NLS\DEUTSCH\
   c:\windows\system\netwhelp.hlp  nur bei PNW
   c:\windows\system\netwpnw.dll   nur bei PNW
   c:\windows\system\nwnetapi.dll  nur bei PNW (ersetzt durch NWCALLS.DLL)
   c:\windows\system\pnwdiagw.dll  nur bei PNW

                                   Diverse gemeinsame Netz-Treiber:
   c:\windows\system\netware.drv   NetWare Client Windows Treiber
   c:\windows\system\nwcalls.dll   NCP Kommunikation zwischen Server/Client
   c:\windows\system\nwgdi.dll     NetWare Graphical Device Interface
   c:\windows\system\nwipxspx.dll  IPX/SPX Kommunikation
   c:\windows\system\nwlocale.dll  Lokalisierung/Internationalisierung
   c:\windows\system\nwnet.dll     Netzwerkunterstützung für NDS usw.
   c:\windows\system\nwpopup.exe   wird beim Start von Windows geladen...
   c:\windows\system\nwpsrv.dll    für Druckerserver (ersetzt NWPSERV.DLL)
   c:\windows\system\pnw.dll       für grafische PNW-Utilities
   c:\windows\system\taskid.com    für korrekte Task-Zuordnung unter Task-
                                   switchern
   c:\windows\system\tbmi2.com     für Task-Switcher wie DOSSHELL, TASKMAX,
                                   TASKMGR als Prozessumschalter, Windows
                                   3.xx im Standardmodus
   c:\windows\system\vipx.386      Virtueller IPX/SPX Treiber
   c:\windows\system\vnetware.386  Virtueller NetWare-Treiber
                                   sollten identischen mit den Dateien
                                   in C:\NWDOS\ sein, die der TASKMGR.EXE
                                   bei Bedarf verwendet.

   c:\windows\system\audwin16.dll  Diese Netz-Treiber nur mit dem VLM-Kit
   c:\windows\system\calwin16.dll  VLM121_1.EXE - VLM121_6.EXE, teilweise
   c:\windows\system\clnwin16.dll  auch schon mit dem älteren VLM-Kit
   c:\windows\system\clxwin16.dll  VLMKT1.EXE - VLMKT6.EXE...
   c:\windows\system\ctl3dv2.dll
   c:\windows\system\lgnw3116.dll
   c:\windows\system\locwin16.dll
   c:\windows\system\loginw31.dll
   c:\windows\system\ncpwin16.dll
   c:\windows\system\netwin16.dll
   c:\windows\system\nwuser.exe    Nützliches Tool
   c:\windows\system\prtwin16.dll
   c:\windows\system\tli_spx.dll
   c:\windows\system\tli_tcp.dll
   c:\windows\system\tli_win.dll

   c:\windows\nls\1252_uni.001     Allgemeine Unicode-Dateien:
   c:\windows\nls\1252_uni.002     Nicht alle dieser Dateien werden in
   c:\windows\nls\1252_uni.003     Deutschland wirklich benötigt (nur
   c:\windows\nls\1252_uni.031     .001, .049), aber der Einfachheit
   c:\windows\nls\1252_uni.032     halber habe ich alle möglichen der
   c:\windows\nls\1252_uni.033     bei PNW mitgelieferten Dateien auf-
   c:\windows\nls\1252_uni.034     gelistet. Die großen NetWare-Ausgaben
   c:\windows\nls\1252_uni.039     unterstützen noch wesentlich mehr
   c:\windows\nls\1252_uni.041     Codeseiten und Länder; siehe auch
   c:\windows\nls\1252_uni.044     Kapitel II.16.
   c:\windows\nls\1252_uni.045     Sollten Sie Unterstützung für andere
   c:\windows\nls\1252_uni.046     Länder oder Codeseiten benötigen,
   c:\windows\nls\1252_uni.047     finden Sie im 'Novell Client Kit for
   c:\windows\nls\1252_uni.049     DOS & Windows 3.xx' sicherlich die
   c:\windows\nls\1252_uni.061     nötigen Dateien; siehe auch Kapitel I.2.
   c:\windows\nls\1252_uni.081
   c:\windows\nls\1252_uni.351
   c:\windows\nls\1252_uni.358
   c:\windows\nls\437_uni.001
   c:\windows\nls\437_uni.003
   c:\windows\nls\437_uni.031
   c:\windows\nls\437_uni.032
   c:\windows\nls\437_uni.033
   c:\windows\nls\437_uni.034
   c:\windows\nls\437_uni.039
   c:\windows\nls\437_uni.041
   c:\windows\nls\437_uni.044
   c:\windows\nls\437_uni.046
   c:\windows\nls\437_uni.049
   c:\windows\nls\437_uni.061
   c:\windows\nls\437_uni.358
   c:\windows\nls\uni_1252.001
   c:\windows\nls\uni_1252.002
   c:\windows\nls\uni_1252.003
   c:\windows\nls\uni_1252.031
   c:\windows\nls\uni_1252.032
   c:\windows\nls\uni_1252.033
   c:\windows\nls\uni_1252.034
   c:\windows\nls\uni_1252.039
   c:\windows\nls\uni_1252.041
   c:\windows\nls\uni_1252.044
   c:\windows\nls\uni_1252.045
   c:\windows\nls\uni_1252.046
   c:\windows\nls\uni_1252.047
   c:\windows\nls\uni_1252.049
   c:\windows\nls\uni_1252.061
   c:\windows\nls\uni_1252.081
   c:\windows\nls\uni_1252.351
   c:\windows\nls\uni_1252.358
   c:\windows\nls\uni_437.001
   c:\windows\nls\uni_437.003
   c:\windows\nls\uni_437.031
   c:\windows\nls\uni_437.032
   c:\windows\nls\uni_437.033
   c:\windows\nls\uni_437.034
   c:\windows\nls\uni_437.039
   c:\windows\nls\uni_437.041
   c:\windows\nls\uni_437.044
   c:\windows\nls\uni_437.046
   c:\windows\nls\uni_437.049
   c:\windows\nls\uni_437.061
   c:\windows\nls\uni_437.358
   c:\windows\nls\uni_col.001
   c:\windows\nls\uni_col.002
   c:\windows\nls\uni_col.003
   c:\windows\nls\uni_col.031
   c:\windows\nls\uni_col.032
   c:\windows\nls\uni_col.033
   c:\windows\nls\uni_col.034
   c:\windows\nls\uni_col.039
   c:\windows\nls\uni_col.041
   c:\windows\nls\uni_col.044
   c:\windows\nls\uni_col.045
   c:\windows\nls\uni_col.046
   c:\windows\nls\uni_col.047
   c:\windows\nls\uni_col.049
   c:\windows\nls\uni_col.061
   c:\windows\nls\uni_col.081
   c:\windows\nls\uni_col.351
   c:\windows\nls\uni_col.358
   c:\windows\nls\uni_mon.001
   c:\windows\nls\uni_mon.002
   c:\windows\nls\uni_mon.003
   c:\windows\nls\uni_mon.031
   c:\windows\nls\uni_mon.032
   c:\windows\nls\uni_mon.033
   c:\windows\nls\uni_mon.034
   c:\windows\nls\uni_mon.039
   c:\windows\nls\uni_mon.041
   c:\windows\nls\uni_mon.044
   c:\windows\nls\uni_mon.045
   c:\windows\nls\uni_mon.046
   c:\windows\nls\uni_mon.047
   c:\windows\nls\uni_mon.049
   c:\windows\nls\uni_mon.061
   c:\windows\nls\uni_mon.081
   c:\windows\nls\uni_mon.351
   c:\windows\nls\uni_mon.358

   c:\windows\nls\deutsch\netwarer.drv   Referenziert über %NWLanguage%

   c:\windows\nls\deutsch\netware.hlp    Das VLM-Kit VLM121_1.EXE -
   c:\windows\nls\deutsch\login.dat      VLM121_6.EXE benötigt eine Reihe
   c:\windows\nls\deutsch\login.msg      weiterer Dateien, die hier aufge-
   c:\windows\nls\deutsch\loginw31.hlp   listet werden, aber nur bei Ver-
                                         wendung von LOGINW31.EXE benötigt
                                         werden.

   c:\windows\nls\deutsch\taskid.msg     Eventuell brauchen Sie auch noch
   c:\windows\nls\deutsch\tbmi2.msg      diese Dateien.

   Sollten Sie einmal eine Fehlermeldung erhalten, daß die Datei
   NETWARER.DRV ncht gefunden werden kann, sollten Sie überprüfen ob

   1. die Variable %NWLanguage% z.B. in STARTNET.BAT korrekt gesetzt wird.
      Sie muß den Namen des Unterverzeichnisses von \WINDOWS\NLS\DEUTSCH
      enthalten, hier also 'DEUTSCH' (siehe Kapitel II.16., IV.7., VI.2.),
      als auch

   2. ob Sie MS Windows über ein Substitut-Laufwerk o.ä. aufgerufen haben.
      Falls dies zutrifft, sollten Sie stattdessen MS Windows über einen
      Batchjob aufrufen, der vorher auf das Windows-Laufwerk und Verzeichnis
      wechselt. U.U. kann man auch auf den undokumentierten Befehl TRUENAME
      ausweichen (nicht getestet).


   iv. Weitere Hinweise:
   ---------------------

   Es ist auch möglich, MS Windows als einen Task des DOS-Task-Managers
   TASKMGR auszuführen (allerdings arbeitet MS Windows dann nur im Standard
   Modus /S), wenn Sie nach dem Netzwerk, aber noch vor MS Windows den
   TASKMGR als Multitasker laden. Auf diese Weise können Sie - zumindest
   theoretisch - z.B. MS Windows mit preemptivem Multitasking-Fähigkeiten
   ausrüsten und sogar mehrere Windows-Sessions nebeneinander laufen lassen,
   in der Praxis ist der dafür notwendige Aufwand meist viel zu groß.
   Wenn Sie stattdessen TASKMGR als Prozeßumschalter laden, kann MS Windows
   sogar im Erweiterten 386er Modus ausgeführt werden. Umgekehrt ist es auch
   möglich, den TASKMGR in einer Windows-DOS-Box als Prozeßumschalter zu
   starten - die Vielfalt kennt keine Grenzen. Wenn dabei immer der gleiche
   TASKMGR (und nicht TASKMAN) zum Einsatz kommt, kann man sogar aus dem
   Task-Menü von Windows die DOS-Tasks, die vor Windows gestartet wurden,
   sowie auf die Tasks innerhalb einer DOS-Box umschalten, d.h. alle Tasks
   des Systems über das TASKMGR-Menü steuern. Achten Sie in diesem Fall
   besonders auf die für das TASKMGR-Menü gewählte Tastenkombination.

   Wenn Sie MS Windows im Standard Modus in Verbindung mit dem Task-Manager
   ausführen wollen, müssen Sie u.U. noch das Programm TBIM2 laden, das
   Netzanforderungen in unterschiedlichen Tasks koordiniert.

   Ein Beispiel für einen Batchjob dieser Art:

   WIN.BAT:

    @ECHO off > \dev\nul
    REM Das Starten über ein Substitut-Laufwerk führt dazu, daß der Treiber
    REM NETWARER.DRV (Deutsch) nicht gefunden wird.
    c:
    CD c:\windows
    REM Video-Speicher freigeben bei DR DOS/Novell DOS.
    REM Achtung: Mit 4DOS 5.51 (only) kann dies Probleme verursachen, wenn
    REM Video-Speicher aktiv war.
    IF EXIST %dos%\MEMMAX.EXE CALL MEMMAX -v
    REM Im Standard Modus wird ein spezieller Treiber für TASKMGR benötigt.
    REM Warntöne (von TBMI2) werden ebenfalls ins Null-Device geschickt! ;-)
    FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 > \dev\nul
    REM In Verbindung mit älteren Versionen von K3PLUS war K3_DISZZ/K3_ENZZ
    REM evtl. erforderlich (mit neueren Versionen von K3PLUS/FreeKEYB nicht
    REM mehr):
    REM @CALL k3_diszz
    @win.com %1 %2 %3 %4 %5 %6 %7 %8 %9
    REM @CALL k3_enzz
    FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 /u > \dev\nul
    IF EXIST c:\nwdos\nwcache.exe CALL NWCACHE /size=max


   Sollten Sie beim Start von MS Windows Fehlermeldungen der Art 'Konnte
   wichtigen Gerätetreiber, der evtl. für den Erweiterten 386er Modus not-
   wendig ist, nicht finden' bekommen, sollten Sie versuchen, MS Windows
   über einen Batchjob aufzurufen und vorher in das Windows-Verzeichnis zu
   wechseln. Alternativ können Sie in der SYSTEM.INI auch die kompletten
   Pfade auf die Treiber angeben oder Sie können dieses Verzeichnis auch
   in die PATH-Anweisung aufnehmen, wodurch solche Probleme generell
   vermieden werden.
   Bei derartigen Problemen hilft es oft, WIN /B aufzurufen; dadurch
   wird während des Starts von Windows in der Datei BOOTLOG.TXT ein
   Startprotokoll aufgezeichnet.
   Überprüfen Sie, ob NWDOS.386 im Hauptverzeichnis liegt und sichtbar ist.
   Ansonsten können Sie den Pfad zu dieser Datei in der CONFIG.SYS bei
   EMM386 angeben oder eine Anweisung SWITCHES= entsprechend Microsofts
   Konventionen verwenden.

   WINA20.386 und NWDOS.386 werden nur für Windows 3.0 benötigt, ansonsten
   können diese Dateien gelöscht werden. Allerdings muß man dann auch den
   entsprechenden Eintrag in der SYSTEM.INI entfernen, damit die Fehler-
   meldung unterbleibt.

   Überprüfen Sie auch die Einstellungen in der %NWDOSCFG%\TASKMGR.INI
   Datei. Bei richtiger Konfiguration wird statt MS Windows' TASKMAN
   Novell DOS' TASKMGR als Manager für MS Windows geladen, deshalb sind
   dessen Einstellungen u.U. nicht unrelevant.

   Noch ein Tip zum Schluß: Gerade auch im Zusammenspiel unterschiedlicher
   Kommandoprozessoren in DOS-Boxen unter Windows ist es meist empfehlens-
   wert, in der DOSPRMPT.PIF Datei nicht direkt COMMAND.COM (bzw. 4DOS.COM)
   anzugeben, sondern %ComSpec%, das immer den richtigen Eintrag enthalten
   sollte. Beim Speichern dieser Einstellung wird der PIF-Editor eine
   Fehlermeldung bezüglich einer falschen Dateiendung ausgeben. Diese kann
   getrost ignoriert werden, Windows macht nach dem Speichern genau das,
   was es soll und ersetzt später die Variable durch ihre aktuelle Belegung.
   (Beim ersten Speichern ist Windows unbarmherzig, hier muß man also
   zunächst COMMAND.COM angeben, speichern, dann durch %ComSpec% ersetzen
   und erneut speichern...)

   Danach sollte MS Windows unter Novell DOS ebenso stabil wie unter
   MS-DOS laufen (meine vielleicht paradoxe persönliche Erfahrung:
   erstaunlicherweise stabiler!!!).

   Haben Sie auf einem neuen Rechner zunächst Novell DOS 7 und dann
   MS Windows 3.xx installiert, wollen Sie sicherlich die Installation
   der Windows-Tools von Novell DOS 7 nachholen (sehr empfehlenswert).
   Dafür müssen Sie u.U. Novells SETUP.INI (in %NWDOSCFG% alias C:\NWDOS\)
   modifizieren:

   WinPath=Pfad auf Windows-Verzeichnis (meist C:\WINDOWS\)
   FirstTime=Yes
   Element0Installed=Yes
   Element1Installed=No
   Element2Installed=Yes
   NetCFGDir=Pfad auf die PNW (meist C:\NWCLIENT\)
   WINDOWS=No

                                                                             
  ---------------------------------------------------------------------------

  VIII.2. Novell DOS, MS Windows 3.xx und Genius-Maustreiber 10.20:
  ====================================================[96-02-05]===

   Stichworte: Genius-Maus, 3-Tasten-Modus, GMOUSE.SYS/COM/DRV, SimTel,
               TASKMGR, Windows, 4DOS

   Über SimTel ist ein neuer Genius-Maustreiber 10.20 (1993) verfügbar,
   den viele Benutzer von Genius-Mäusen wohl schon lange vergeblich gesucht
   haben, da die letzte weitverbreitete Version 9.06 (1991) schon etliche
   Jahre zurücklag und mit verschiedener Software Probleme bereitete (u.a.
   auch mit dem TASKMGR aus frühen Versionen von Novell DOS 7, siehe
   Kapitel VII.1.).

   Der neue Treiber in seiner MS Windows Version GMOUSE.DRV ermöglicht
   ruckfreies Arbeiten mit der Maus, auch im 3-Tasten-Modus. Die bisherigen
   Treiber (die bei MS Windows beilagen) oder diverse andere Fremdtreiber
   arbeiteten leider nicht völlig problemlos mit MS Windows über Novell DOS:
   der Zeiger sprang bei Diskettenzugriffen schon bei kleinsten Bewegungen
   der Maus wild über den Bildschirm und beruhigte sich erst, wenn der
   Cache NWCACHE nach der Startphase zur Ruhe gekommen ist (mit MS-DOS
   und SMARTDRV zeigte sich dieses Verhalten nicht, aber repräsentativ
   muß das nicht sein).

   Leider stürzt das SETUP-Programm zu diesem Genius-Maustreiber während
   der Installation ab, da es u.a. nicht mit Novell DOS- (und DR DOS-)
   spezifischen Einträgen in CONFIG.SYS (Boot-Menüs) zurechtkommt. Aber
   auch ansonsten gibt es eine Reihe von Problemen mit diesem Programm
   (beschränkte Verzeichniswahl, z.B. keine Verzeichnisse mit einem Punkt).
   Es bleibt die manuelle Installation, bei der man für MS Windows in
   SYSTEM.INI den MOUSE.DRV=\path\GMOUSE.DRV eintragen muß.

                                                                             
  ---------------------------------------------------------------------------

  VIII.3. Novell DOS und MS Windows 3.xx Netzinstallation: [96-06-13]
  ===================================================================

   Stichworte: Netzinstallation, PNW, SYSTEM, SETUP.INI

   Die Dateien NETWARE.DRV, FASTBACK.386 und VNETWARE.386 müssen ins
   Windows-Netzverzeichnis kopiert werden, ins lokale Windows \SYSTEM\
   Verzeichnis gehören NETWPNW.DLL, NW*.DLL, PNW.DLL und PNDDIAGW.DLL.
   Die lokale SYSTEM.INI muß die in Kapitel VIII.1. beschriebenen
   Einstellungen vorweisen (nach c't 08/1994 S.195).

   Bezüglich FASTBACK.386 und PNW siehe auch Kapitel VIII.1.

                                                                             
  ---------------------------------------------------------------------------

  VIII.4. Windows-Maus in DOS-Boxen im Fenster benutzen: [96-12-19]
  =================================================================

   Stichworte: Logitech LVMD.386, SYSTEM.INI, Drag & Drop, Copy & Paste,
               CLOAKING, DPMS

   Dieser Tip funktioniert unabhängig von der installierten DOS-Version
   (also auch mit MS-DOS/PC-DOS)!

   Viele haben sich sicherlich schon darüber geärgert, daß man zwar
   unter MS Windows 3.xx DOX-Boxen öffnen kann, die Maussteuerung einer
   dort gestarteten Applikation jedoch normalerweise nur dann funktioniert,
   wenn man die Applikation im Vollbildmodus startet.
   Schaltet man dann auf den Fensterbetrieb um, so ist die Maus plötzlich
   verschwunden. Stattdessen kann man mit der Windows-Maus arbeiten,
   auf die aber das DOS-Fenster nicht reagiert. Schaltet man zurück in den
   Vollbildmodus, kommt es - abhängig von der jeweiligen Applikation - sogar
   vor, daß nun auch hier die Maus verschwunden ist.
   Startet man die Applikation jedoch im Fenster, erscheint die DOS-Maus
   erst gar nicht und bleibt üblicherweise auch beim Umschalten in den
   Vollbildmodus verschwunden.
   Diese Probleme sind nur logisch, denn die Applikation wird nicht ständig
   versuchen, eine evtl. beim Start nicht verfügbare Maus nachträglich zu
   aktivieren.

   Allerdings gibt es eine Möglichkeit, dieses Problem sehr elegant
   zu lösen, und zwar unabhängig von den verwendeten DOS- und Windows-
   Maustreibern:

   Logitech und OEMs liefern zu ihren Mäusen ein Treiberpaket namens
   "MouseWare" mit. Dieses Paket ist aber auch an vielen Stellen in den
   Datennetzen verfügbar. In der Version 6.30 dieses Pakets befindet sich
   u.a. ein virtueller Gerätetreiber LVMD.386 für MS Windows 3.xx, der statt
   des Standard-Treibers in der SYSTEM.INI [386Enh] Sektion eingetragen
   werden muß (falls der Treiber nicht im \WINDOWS\SYSTEM\ Verzeichnis
   liegt, bei Bedarf mit Pfadangabe).

    SYSTEM.INI:

    [386Enh]
    ...
    ; z.B. einen Eintrag wie
    ; mouse=mscvmd.386
    ; ersetzen durch einen Logitech-Treiber
    mouse=lvmd.386
    ...

   Der 'normale' Windows-Maustreiber in SYSTEM.INI und der üblicherweise
   in CONFIG.SYS oder AUTOEXEC.BAT geladene DOS-Maustreiber braucht nicht
   geändert zu werden (eine einigermaßen aktuelle API-Unterstützung des
   Treibers vorausgesetzt: GMOUSE 10.20 und verschiedene Microsoft-Treiber
   funktionierten jedenfalls).

   Nach dieser Änderung kann man nun auch in DOS-Boxen, die im Fenster
   laufen, den Windows-Mauszeiger benutzen:

   Befindet sich der Mauszeiger über dem Fenster der DOS-Box, beziehen sich
   alle Tastendrücke, Drag & Drop-Operationen etc. auf die in der DOS-Box
   laufende Applikation (besonders praktisch z.B. für den Norton Commander
   NC 5.0x, der neuerdings über Drag & Drop Möglichkeiten verfügt. Kleiner
   Seitenhieb: Ob der NC eigentlich immer noch der meistgenutzte Datei-
   manager unter Windows ist? ;-) ).
   Außerhalb des Fensters bezieht sich die Maus natürlich wie gewohnt auf
   die Windows-Anwendungen.
   Die einzige Einschränkung ist, daß Mausoperationen bei MS Windows 3.xx
   nicht über die Grenzen eines Fensters hinweg möglich sind, denn
   schließlich läuft jede DOS-Box in einer eigenen virtuellen Maschine und
   bekommt ohne spezielle Kommunikation mit Windows nichts davon mit, daß
   sie in einem Fenster unter Windows läuft.

   Mit Windows95 hat sich dies jedoch geändert (und das unabhängig von
   obigem Treiber); hier werden beschränkte Drag & Drop und Copy & Paste
   Operationen zwischen DOS- und Windows-Applikationen geboten.

   Eine Copy & Paste Funktion (und unter Zuhilfenahme dieses Tricks auch
   mit kompletter Windows-Mausunterstützung für die DOS-Box) bietet aller-
   dings auch schon MS Windows 3.xx:

   Läuft eine DOS-Box im Fenster, so kann man über das Systemmenü
   (links oben in der Fensterumrahmung) unter dem Punkt 'Bearbeiten'
   auf 'Markieren' gehen und dann Bildschirmausschnitte des angezeigten
   Fensters markieren. Bezüglich der genauen Arbeitsweise (und anderer
   Möglichkeiten, etwa im Vollbildmodus) sei auf die Online-Hilfe von
   NOTEPAD.EXE (der Zwischenablage) verwiesen.
   Normalerweise kann man dafür (im Fensterbetrieb) nur die Cursor-Tasten
   in Verbindung mit <Shift> benutzen. Mit dem oben angesprochenen Logitech-
   Treiber kann man jedoch nach Aktivierung des 'Markieren'-Menüpunktes
   (sonst bezieht sich die Maussteuerung ja wie oben erläutert auf die
   Applikation selbst) wie gewohnt den Windows-Mauszeiger benutzen
   (linke Maustaste), um Bereiche zu markieren und dann mit 'Kopieren' in
   die Zwischenablage zu kopieren. Von dort kann sie dann mit 'Bearbeiten'/
   'Einfügen' als simulierte Tastatureingabe in eine andere DOS-Anwendung
   übernommen werden oder aus der Zwischenablage auch in Windows-Anwendungen
   eingebunden werden.

   Nachbemerkung:

   In der Logitech MouseWare 6.50+ befindet sich auch eine neue Version
   des 'normalen' DOS-Maustreibers, der vielleicht für Sie interessant ist:
   Diese neue Version unterstützt das CLOAKING-API, und kann sich, wenn
   man vorher den beiliegenden Treiber CLOAKING.EXE geladen hat (kann auch
   in CONFIG.SYS mit DEVICE=/DEVICEHIGH= geladen werden), bis auf 1 KByte
   aus dem ersten MegaByte auslagern (statt sonst 27 KByte zu belegen)!
   (Dies funktioniert sogar in CONFIG.SYS, wenn man auch MOUSE.EXE per
   DEVICE=/DEVICEHIGH= lädt...)
   CLOAKING ist eine Entwicklung von Helix Software und kostet selbst nur
   1 KByte Speicher. CLOAKING ist von seinem Einsatzzweck und der Funk-
   tionalität Novells DPMS äußerst ähnlich, in Wahrheit enthält der
   CLOAKING-Treiber (undokumentiert) selbst einen 'Cloaked DPMS-Server',
   d.h. das CLOAKING-API ist eine Obermenge von Novells DPMS-Standard!!!
   Obwohl laut Logitech offiziell nicht unterstützt, arbeitet CLOAKING
   natürlich nicht nur deswegen in praktisch allen Konfigurationen (mit
   /MULTI=on) einwandfrei mit Novells Speichermanagern zusammen (getestet
   mit Update 15, lediglich der TASKMGR stürzte bei mir immer ab, sobald
   CLOAKING geladen war :-( ). Weitere Hinweise zu CLOAKING und DPMS finden
   sich in Kapitel II.5. bei DPMS.

                                                                             
  ###########################################################################
  ###########################################################################

  IX. LITERATUR:
  ==============

  ---------------------------------------------------------------------------

  IX.1. Novell DOS 7 Handbuch:
  ============================

   Autoren  : nicht bekannt (Novell)
              (Übersetzung des DR DOS 6.0 Handbuchs: Monika Fürst, BDÜ)
   Sonstiges: DOSBOOK

   Gute Einführung in Novell DOS 7 (auch einige didaktische Hinweise für
   Anfänger, allerdings war hier das DR DOS 6 Handbuch ausführlicher),
   enthält aber leider nicht die komplette Dokumentation des Systems. An
   vielen Stellen wird auf die wesentlich ausführlichere Online-Hilfe
   DOSBOOK verwiesen. Diese Idee des elektronischen Handbuchs ist eigentlich
   auch ganz praktisch, allerdings ist das DOSBOOK nicht ganz frei von
   kleinen Fehlern und fehlerhaften Verknüpfungen, die sich leider wegen
   der komprimierten Form des Buches nicht selbst korrigieren lassen.
   Auf einer Novell DOS 7 CD-ROM (BHV-Verlag) soll allerdings eine Text-
   Version des DOSBOOKs existieren, die damit die nachträgliche Bearbeitung
   durch den Benutzer (Kommentare etc.) erlauben würde (allerdings dann
   wieder nicht die Einbindung in DOSBOOK bietet...).


  ---------------------------------------------------------------------------

  IX.2. Das große Buch zu Novell DOS 7 (Data Becker):
  ===================================================

   Autoren  : Klemens Mai, Dirk Larisch, H. Tronsdorf, M. Tronsdorf
   ISBN     : 3-8158-1030-2
   Sonstiges: 1. Auflage 1994, 1086 Seiten, 3,5" Diskette, DM 69,-

   Für meine Begriffe die beste Fremddokumentation zu Novell DOS 7. Zwar
   enthält auch dieses Buch einige kleinere Fehler, kann aber sowohl für
   absolute Anfänger als auch für DOS-Profis eine ständige Referenz neben
   dem DOSBOOK sein. Erläutert DOS-Grundlagen für Anwender verständlich
   und deckt - bis auf komplett ausgesparte undokumentierte Details und
   ganz spezielle Kniffe und Workarounds für Freaks - eigentlich das ganze
   System (auch PNW) gebührend ab. Viele Beispiele aus der Praxis und eine
   komplette Kommandoübersicht. Viel Info, übersichtliches Layout.
   Wirkliche Problemfälle, die auch DOS-Profis zum Verzweifeln bringen
   können, deckt dieses Buch allerdings auch nur am Rande ab (vielleicht zu
   viel verlangt von einem Buch). Beschränkt sich auf offizielle Eigen-
   schaften des Systems, ist darin aber sehr gut.

   Der auf der Diskette enthaltene Bildschirmschoner BLACKOUT ist so
   unzureichend, daß man ihn getrost vergessen kann (Ersatz z.B. durch
   den in den erweiterten Tastaturtreiber K3PLUS/FreeKEYB eingebauten
   Bildschirmschoner - zu beziehen über mich). Die Oberfläche TEMPEST 1.0
   erinnert leicht an VIEWMAX von DR DOS 6, bietet aber leider nicht eine
   direkte Unterstützung für TASKMAX/TASKMGR. Ob dies in späteren Versionen
   nachgeholt wurde, ist mir nicht bekannt.

   An einer Stelle werden sogar die frühen Updates zu Novell DOS erwähnt
   (allerdings mittlerweile völlig veraltet), was aber darauf schließen
   läßt, daß dieses Buch nicht ganz in der sonst üblichen Eile produziert
   (am besten noch vor Erscheinen des Betriebssystems) publiziert wurde.

   Kostet offiziell DM 69,-, wurde aber nach dem Abgang von Novell DOS 7
   für DM 10,- bis 20,- verrammscht (die sich in jedem Fall lohnen).


  ---------------------------------------------------------------------------

  IX.3. Novell DOS 7 - Das Kompendium (Markt & Technik):
  ======================================================

   Autoren  : Kai Hamann, Michael Kolberg
   ISBN     : 3-87791-556-6
   Sonstiges: 10/1994, 750 Seiten, 3,5" Diskette, DM 69,-

   Relativ gute Einführung in Novell DOS, deckt die wichtigsten Themen und
   alle Hauptbelange des Systems (auch PNW) aus Anwendersicht ab. Enthält
   relativ wenig Fehler. Recht komplette Kommandoübersicht und einiger-
   maßen übersichtliches Layout. Spezialthemen (wie z.B. Codeseiten-
   Einrichtung) werden nicht behandelt bzw. nur auf das SETUP-Programm
   verwiesen.

   Enthält in einem Anhang auch Tips und Tricks zu Workarounds und un-
   dokumentierten Eigenschaften des Systems. Diese Hinweise sind nicht
   immer korrekt, nicht vollständig oder gelten nur für frühe Versionen
   von Novell DOS. Trotzdem ist dieser Ansatz lobenswert, da durch Anwendung
   der Tips teilweise mehr aus dem System herausgeholt werden kann (für
   Leser *dieser* Datei aber nichts Neues mehr). Besonders lobenswert ist,
   daß dieses Buch anscheinend nicht in der sonst üblichen Eile produziert
   wurde, sondern tatsächlich einmal Praxiserfahrungen mit einer Final-
   Release (und Updates) eingeflossen sind.

   Die auf der Diskette mitgelieferten Treiber-Updates zu Novell DOS 7
   (06/1994) sind mittlerweile hoffnungslos veraltet. Zusätzlich enthält
   die Diskette auch noch einige andere NetWare-Updates, und einige Screen-
   shots von Novell DOS Utilities.

   Kostet offiziell DM 69,-, wurde aber zuletzt für ca. DM 10,- bis 15,-
   verrammscht, die sich durchaus lohnen.


  ---------------------------------------------------------------------------

  IX.4. Novell DOS 7 und Personal NetWare (Addison Wesley): [96-05-29]
  ====================================================================

   Autoren  : Michael Gerding, Björn Kibbel
   ISBN     : 3-89319-758-3
   Sonstiges: 1. Auflage 1994, 919 Seiten, DM 79,-

   Dieses Buch aus der Reihe Software-Klassiker hat bei mir leider keinen so
   guten Eindruck hinterlassen.
   Obwohl das Buch im Prinzip - wie die beiden anderen Bücher auch - fast
   das gesamte System (auch PNW) aus Anwendersicht abdeckt, ist es von den
   Beispielen eher für absolute Newcomer in DOS geeignet (Wer schon gewisse
   Erfahrungen mit DOS hat, kommt sich bei vielen Beispielen und 'wichtigen'
   Hinweisen teilweise eher hochgenommen vor). Trotzdem ist es für mich
   fraglich, ob der absolute Newcomer hier das System in der didaktisch
   geeignetsten Form dargeboten bekommt. Die Suche nach detaillierten
   Informationen zu einem ganz speziellen Thema ist nahezu unmöglich, da
   die Informationen im Rahmen der Einführung weit gestreut sind.
   Speziellere Themen wie z.B. Codeseitenunterstützung fehlen komplett.
   Allerdings muß man den Autoren zugute halten, daß der Ansatz hier im
   Vergleich zu vielen anderen Büchern etwas anders liegt: Die Autoren
   versuchen durch Einführungen in die PC-Welt (Geschichte, Hardware,
   Software, DOS allgemein, auch Windows-Einführung) eine Allround-
   Dokumentation für PC-Newcomer zu bieten. Sie gehen auch auf die
   externe Version von PNW ein.

   Das Layout ist teilweise äußerst unübersichtlich und verschwenderisch
   zugleich, außerdem enthält dieses Buch wirklich eine extreme Anzahl
   von typographischen und sachlichen Fehlern. Vieles wurde anscheinend
   ohne Überprüfung von einem Buch über MS-DOS kopiert, viele Parameter
   gelten für MS-DOS (teilweise sogar nur für ziemlich alte MS-DOS Ver-
   sionen), nicht für Novell DOS. Die Kommandoübersicht ist relativ un-
   vollständig (verglichen mit den Übersichten der anderen Bücher), die
   Parameter sind nicht alphabetisch sortiert.
   Enthält auch einige Hinweise auf bei Novell DOS 7 neue oder undokumen-
   tierte Eigenschaften und veranlaßte mich nach der Suche von versteckten
   Features (leider kam dabei nichts Neues heraus), entsprechende Andeu-
   tungen im Buch galten also entweder für Beta-Versionen von Novell DOS
   oder sind schlichtweg falsch.

   Aufgrund der Vielzahl der negativen Kritikpunkte (die wohl so ziemlich
   jedem Leser aufstoßen werden, sobald er sie bemerkt), stellt sich die
   Frage, ob dieses Buch nicht eher ein unfertiges Manuskript war, das viel
   zu früh in Druck gegangen ist. Mein normalerweise recht positiver Ein-
   druck von diesem Verlag hat mich hier doch äußerst arg enttäuscht.

   Kostet offiziell DM 79,-, in Ausverkaufsaktionen für ca. DM 20,- zu
   haben, die sich m.E. nach für etwas erfahrene DOS-Benutzer nicht lohnen.


  ---------------------------------------------------------------------------

  IX.5. Novell DOS 7 - Networking, Multitasking, Systemoptimierung:
  ======(Addison-Wesley)==============================[97-01-14]===

   Autoren  : Frank Grieser, Andreas Winterer
   ISBN     : 3-89319-676-5
   Sonstiges: 1. Auflage 1994, 386 Seiten, DM 60,-

   Dieses vergleichsweise kompakte Buch beschäftigt sich entsprechend seinem
   Titel im Gegensatz zu den anderen Büchern weniger mit den Einsteiger-
   problemen und setzt ein paar System- und Konfigurationskenntnisse voraus
   (aber nicht allzu viel).
   Die Zusammenstellung hat bei mir einen recht positiven Eindruck hinter-
   lassen, und ich denke, das Buch kann in der Praxis gute Dienste erweisen.
   Allerdings konnte ich in dem Buch und auf der beiliegenden Diskette -
   von BACKUP, RESTORE, HIBUFFERS= und einigen NET.EXE-Optionen abgesehen -
   keine Hinweise auf undokumentierte Systemeigenschaften und größere
   Fehlerkorrekturen bezüglich Novells eigener Dokumentation entdecken,
   wie auf dem Rückdeckel spektakulär geworben wurde. Obwohl auch dieses
   Buch eine ganze Reihe Fehler enthält (die dann allerdings im Novell-
   Handbuch meist genauso falsch beschrieben werden), enthielt das Buch
   genügend Novell DOS spezifische Hinweise, so daß bei mir hier nicht
   der Eindruck eines übereilten 'Updates' eines MS-DOS Buches entstand.
   Die beiden auf der Diskette beiliegenden Hypertext-Online-Referenzen zu
   Novell DOS Kommandos und NET.EXE (von den Autoren entwickelt auf der
   Basis von Davids ReadMe-Compiler) haben mir - trotz der Fehler - gut
   gefallen und können das DOSBOOK in manchen Punkten ergänzen. Das Update 4
   zu Novell DOS, das ebenfalls mitgeliefert wird, ist natürlich hoffnungs-
   los veraltet...

   Ich konnte das Werk kürzlich als Restposten für ganze DM 5,- ergattern,
   die sicherlich lohnen, denn auch für Leser dieser Datei sind darin
   noch einige neue Tips, wenn auch keine neuen undokumentierten Details
   enthalten.


  ---------------------------------------------------------------------------

  IX.6. Undocumented DOS (Addison Wesley):
  ========================================

   Autoren  : Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michels,
              Jim Kyle
   ISBN     : 0-201-63287-X
   Sonstiges: 2. Auflage, US $44.95, ca. DM 118,-, 856 Seiten, 3,5" Diskette

   Kein Buch für Anwender, stattdessen ein absolutes Muß für ernsthafte DOS-
   und Windows-Programmierer. Die zweite Ausgabe enthält auch erste Hinweise
   zu Novell DOS 7 Features (war noch im Beta-Stadium), obwohl hauptsächlich
   MS-DOS Interna beschrieben werden (die aber fast komplett auch für
   Novell DOS 7 gelten). Sehr gut geschrieben, deckt viele Zusammenhänge
   äußerst plastisch auf. Leicht verständliches Englisch.
   Viele Details der ersten Ausgabe sind in das leider mittlerweile
   vergriffene, aber nach wie vor äußerst empfehlenswerte Buch 'DOS 5 für
   Programmierer - Die endgültige Referenz' von Arne Schäpers eingeflossen
   (der auch ausführlich auf DR DOS 3.41 und 5.0 eingeht), die zweite
   Ausgabe von 'Undocumented DOS' enthält aber wiederum viele Informationen
   aus diesem Buch bezüglich der DR DOS Spezifika. Neben einer Vielzahl
   sinnvoller Programmiertools ist auf der Diskette die Interrupt-Liste
   von Ralf Brown enthalten, die aber mittlerweile in einer erheblich ver-
   besserten und erweiterten Form über das Internet zu beziehen ist (siehe
   Bezugshinweis am Beginn dieses Dokuments).

   Wie gesagt, für Anwender völlig ungeeignet, für Programmierer ein Muß.


  ---------------------------------------------------------------------------

  IX.7. DOS 5 für Programmierer - Die endgültige Referenz (Addison Wesley):
  ============================================================[97-01-03]===

   Autor    : Arne Schäpers
   ISBN     : 3-89319-350-2
   Sonstiges: 1. Nachdruck 1991, DM 99,-, 1123 Seiten, 360 KByte 5.25" Disk

   Ebenfalls ein Buch 'for programmers only'. Auch wenn mittlerweile reich-
   lich betagt (nach meinem Kenntnisstand ist auch keine Neuauflage mehr
   zu erwarten (Wer interessiert sich schon noch für DOS??? Na, Sie - wenn
   Sie tatsächlich dieses Dokument bis hierhin durchgelesen haben! ;-) ),
   bleibt dieses Buch auch neben der 2. Auflage von Undocumented DOS ein
   essentieller Fundus für DOS-Interna, der ausführlich auf MS-DOS bis 5.0
   und DR DOS 3.41 und 5.0 eingeht. Da vieles - wenn auch lange nicht
   alles - DR DOS-Spezifische auch für Novell DOS 7 gilt, sehr empfehlens-
   wert. Allerdings enthält auch dieses Buch einige massive sachliche Fehler
   oder Fehlschlüsse (nun, wer im Glashaus sitzt, sollte nicht mit Steinen
   werfen, sorry ;-) ), aber die Unzahl von Beispielprogrammen zu allen
   DOS-Funktionen entschädigen wirklich mehr als gut dafür!
   Als Restposten teilweise für gut angelegte DM 15,- zu ergattern.

                                                                             
  ---------------------------------------------------------------------------

  IX.8. Weitere Literatur: [97-02-26]
  ===================================

   Bemerkung: Der Vollständigkeit halber eine einfache Auflistung...
              Da mir die Mehrzahl der Bücher nicht vorliegt, meist
              ohne irgendeine Wertung...

   - "Einsteigerseminar - Novell DOS 7"
     bhv, 1994, 427 Seiten, DM 20,-
     ISBN 3-89360-735-8

   - "Novell DOS 7" (H. Mehlig, J. Waßermann)
     Rowohlt, 1994, 430 Seiten, DM 23,-
     ISBN 3-499-19814-2

   - "Novell DOS 7 und Personal NetWare optimal einsetzen"
     (B. Kibbel, B. Kretschmer, Herausgeber: Haselier???, Fahnenstich)
     Econ & Addison-Wesley, 1994, 363 Seiten, DM 20,-
     ISBN 3-612-28047-3
     Bemerkung: Wirkt teilweise wie eine Kurzfassung des Buches aus IX.4.
                und enthält genauso falsche Informationen über angebliche
                Aufrufoptionen bestimmter Novell DOS 7 Tools (ein paar
                Beispiele FASTOPEN, NWCACHE etc.), die eigentlich eher für
                MS-DOS gelten.

   - "Novell DOS 7 Unleashed" (Jonathan Kamin)
     Sams, 03/1994, 808 Seiten + 3,5" Disk, DM 95,- / f 79,- / $ 40,-
     ISBN 0-672-30328-0
     Bemerkung: Englischsprachiges Buch über die US-Version von Novell DOS

   - "Using Novell DOS 7" (King, Harper, Langley)
     Que Corp., 1994, 841 Seiten, f 65,-, $ 30,-
     ISBN 1-56529-104-2
     Bemerkung: Englischsprachiges Buch über die US-Version von Novell DOS

   - "Inside Personal NetWare" (Dorothy Cady)
     NRP, 1994, $ 25,-, DM 70,-
     ISBN 1-56205-232-2
     Bemerkung: Englischsprachiges Buch über die US-Version von Personal
                NetWare in Verbindung mit Novell DOS 7, DR DOS, MS-DOS
                Windows und OS/2 mit einem eindeutigen Schwerpunkt auf der
                recht detaillierten Beschreibung von Personal NetWare.
                Beschreibt auch viele Praxislösungen.

  - "Novell DOS 7: Memory Management, Multi-Tasking, Networking,
     and Data Protection" (Brian Underdahl)
     John Wiley & Sons, 12/1993, $ 23,-, 326 pages
     ISBN 0-471-01629-2

   - "Bright Books: Novell DOS versie 7"
     Addison Wesley NL, 1994, f 15,-
     ISBN 90.6789-467.2
     Bemerkung: In niederländischer Sprache

   - "Novell DOS 7 Handboek" (van Bedem)
     Addison Wesley NL, 1994, f 60,-
     ISBN 90.6789-400.1
     Bemerkung: In niederländischer Sprache

   - "Werken met Novell DOS 7" (de Jong)
     Sybex Nederland, 1993, f 70,-
     ISBN 90.5160-633.8
     Bemerkung: Dieses niederländische Buch behandelt angeblich auch
                Windows NT???

   - "Das große DR DOS 6.0 Buch" (H. Tornsdorf, M. Tornsdorf)
     Data Becker, 1991, 1003 Seiten, DM 59,-
     ISBN 3-89011-510-1
     Bemerkung: Der Vorläufer von "Das große Buch zu Novell DOS 7" (siehe
                IX.2.) enthielt eine Reihe Hinweise zu DR DOS 6.0, die zwar
                auch noch für Novell DOS 7 interessant sind, im Nachfolge-
                band aber - wohl aus Platzgründen - nicht berücksichtigt
                wurden. Enthält auch einige kleinere Fehler.


   Das folgende englische Buch war angekündigt, wurde aber offenbar nie
   veröffentlicht:

   - "Novell DOS 7: Instant Reference", evtl. auch
     "Novell's Guide to Novell DOS 7.0"
     Novell Press/Sybex, 08/1995, $30,-
     ISBN 0782114075
     Bemerkung: Wahrscheinlich sollte es sich hierbei um eine gedruckte
                Fassung der oben erwähnten Tutorials zu Novell DOS 7
                handeln.

                                                                             
  ---------------------------------------------------------------------------

  IX.9. c't/iX Artikel: [97-02-12]
  ================================

   Autoren  : div.
   Sonstiges: c't - magazin für computertechnik, Heise Verlag, Hannover

   Dieser Überblick soll nur stichwortartig die mir bekannten c't-Artikel
   zum Thema 'Novell DOS' (und Vorgängern) behandeln, und erhebt alles
   andere als den Anspruch auf Vollständigkeit. Trotzdem möchte ich noch
   einmal darauf hinweisen, daß die in diesem Dokument wiedergegebenen
   Fakten nicht auf den genannten Artikeln basieren, sondern auf meinen
   eigenen Erfahrungen. Natürlich habe ich die Informationen - wo immer
   möglich - gegeneinander abgeglichen.

   - "Taskdynamik"
     DESQview und Concurrent DOS unter Novell (Detlef Borchers)
     iX 04/1989, S. 40
     Stichworte: DR Concurrent DOS, 'review'

   - "Spätlese"
     Digital Researchs MS-DOS-Alternative (Marcus Gröber, Bert Ungerer)
     c't 03/1990, S. 172
     Stichworte: 'review', DR DOS 3.41

   - "Neues altes DOS"
     DR-DOS 5.0 steht vor der Markteinführung (Bert Ungerer)
     c't 07/1990, S. 31

   - "Raum für DOS"
     Vier virtuelle Speichermanager für 386er (Dr. Reinhard Ellinghaus)
     c't 12/1990, S. 130
     Stichworte: EMS, 386ToTheMAX, BlueMax, QEMM-386, DR-DOS 5.0, Turbo EMS

   - "Belebende Konkurrenz"
     DR DOS 6.0 mit neuen Features (Bert Ungerer)
     c't 10/1991, S. 25
     Stichworte: 'aktuell'

   - "DOS to the max"
     DR DOS 6.0 mit vielen Utilities (Marcus Gröber)
     c't 11/1991, S. 96
     Stichworte: 'review'

   - "Die Alternativen"
     PC-Betriebssysteme neben dem Standard (Detlef Borchers)
     c't 06/1992, S. 58
     Stichworte: Prologue, Theos, L3, PC-MOS, Multiuser-DOS, DESQview

   - "Verstohlene Seitenblicke"
     Der Interrupt 21h beim DOS-Bootvorgang (Harald Milz)
     c't 07/1992, S. 198
     Stichworte: TSR-Programme & Gerätetreiber, CONFIG.SYS, Booten,
                 DRDOS, PCDOS, MSDOS

   - "Just in Time"
     Echtzeit-Betriebssysteme, Teil 2: Marktreport (Arno Keppke)
     c't 09/1992, S. 202
     Stichworte: u.a. FlexOS

   - "Leichtnetz mit Anhang"
     Netware Lite v1.1 im Paket mit DR DOS (Bert Ungerer)
     c't 12/1992, S. 124f.
     Stichworte: DR DOS 6.0, Netware Lite, Novell, 'kurz vorgestellt'

   - "Die wahre DOS-Version"
     DOS-Versionsermittlung im Detail (Matthias Wolf)
     c't 02/1993, S. 106
     Stichwort: reale DR DOS Versionen

   - "Knackpunkt"
     PCs contra Datensicherheit: Das Beispiel DR DOS (Mark Torben Rudolph)
     c't 03/1993, S. 130ff.
     Stichworte: DEL, FORMAT, PASSWORD, LOGIN, UNDELETE, DISKMAP, DELWATCH,
                 DELPURGE, LOCK, COMPRESS, SuperStor, DR DOS 6.0

   - "Ableger im Aufwind"
     Frankfurter NetWorld findet Anklang (Bert Ungerer)
     c't 07/1993, S.20
     Stichworte: Novell DOS 7 Ankündigung, 'aktuell'

   - "Netz-DOS"
     Novell DOS 7 kurz vor der Fertigstellung (Bert Ungerer)
     c't 09/1993, S. 30f.
     Stichworte: Beta, Multitasking, 'aktuell'

   - "DOS novellieren?"
     Novell DOS 7 fordert PC- und MS-DOS heraus (Bert Ungerer)
     c't 03/1994, S. 74ff.
     Stichworte: PC-DOS 6.1, MS-DOS 6.20, PNW, STACKER, DBLSPACE, SuperStor,
                 'report'
     Bemerkung:  Interessanter Vergleich der Funktionalität der drei
                 zu diesem Zeitpunkt aktuellen DOS Betriebssysteme. Das
                 Fazit ist ziemlich eindeutig...

   - "Ziffernlifting"
     IBMs PC-DOS 6.3: Fast alles beim alten (Bert Ungerer)
     c't 04/1994, S. 28
     Stichworte: Novell DOS 7, PC-DOS 6.3, MS-DOS 6.21 und 6.22, CeBIT,
                 'aktuell'

   - "Natürlich undokumentiert"
     Novells Personal Netware unter OS/2 (Dieter Brors)
     c't 07/1994, S. 176f.
     Stichworte: IBM OS/2 2.11, PNW, Peer-to-Peer, HPFS, DPMS, NWCACHE,
                 DOS-Box, NET.CFG: Netware DOS Requester OS2=on
     Bemerkung:  Da ich diesbezüglich noch keine Erfahrungen gesammelt habe,
                 verweise ich für Novell DOS 7 & PNW unter OS/2 auf diesen
                 Artikel, der sich allerdings mit dem mittlerweile
                 veralteten OS/2 2.11 beschäftigt. Weitere Hinweise zu
                 Novell DOS 7 unter/mit OS/2 gibt es auch in den Dokumenten
                 von Novells FaxBack-Systems, das zusammengefaßt auch in
                 dem am Anfang erwähnten Archiv ND7TID.EXE verfügbar ist.

   - "Licht und Schatten"
     Ein kritischer Blick auf Novell DOS 7 (Arne Schäpers)
     c't 08/1994, S. 193ff.
     Stichworte: DPMI, DPMS, Übertragungsraten, Windows, Updates, APIs,
                 Undokumentiertes, DR DOS, Probleme, DBLSPACE
     Bemerkung:  Die allermeisten der in diesem Artikel beschriebene Pro-
                 bleme (Update 4) gehören mittlerweile (Update 15) der
                 Vergangenheit an; Novell war trotz eingestellter Weiter-
                 entwicklung in den vergangenen 1,5 Jahren nicht untätig...
                 Trotzdem ist die Lektüre (wie bei den meisten Artikeln
                 und Büchern von Arne Schäpers) interessant, auch wenn
                 Novell DOS hier nicht besonders gut abschneidet, was
                 zwar in manchen Punkten gerechtfertigt ist, in anderen
                 Punkten jedoch eine klare Frage des Standpunktes ist
                 (meinen sollten Sie ja inzwischen auch kennen...).

   - "Watteweicher Kompromiß"
     Microsoft einigt sich mit Kartellbehörden (Ingo T. Storm, Sabine Dutz)
     c't 09/1994, S. 16

   - "Fertigserver"
     Zeniths Z-Stor mit vorkonfigurierter Personal NetWare (Bert Ungerer)
     c't 09/1994, S. 72

   - "Virtuelle Einrichtung"
     Konfigurationstips für Novells DOS-Requester (Bert Ungerer)
     c't 09/1994, S. 194
     Stichworte: Netze, VLMs, Novell DOS 7, NET.CFG, LAN, Personal NetWare

   - "Novell kippt DOS 7"
     Netz-Marktführer konzentriert Aktivitäten (Ralf Hüskes)
     c't 11/1994, S. 16
     Stichworte: Novell DOS 7 & Personal Edition UnixWare eingestellt,
                 AppWare und WordPerfect, Super NOS, NetWorld+InterOp,
                 'Markt'
     Bemerkung:  No comment!

   - "Vobis und Escom setzen auf OS/2"
     MS Windows gibt es nur noch gegen Aufpreis (Christian Persson)
     c't 12/1994, S. 16
     Stichworte: OS/2 3.0 Warp, Microsoft Chicago/Windows95, Novell DOS 7
     Bemerkung:  Hat zwar nicht lange funktioniert (die Mark siegt), hat
                 aber mal wieder die Grundproblematik mit Microsoft als
                 Software-Monopolisten deutlich vor Augen geführt. Ohne
                 'Abweichler' wird die Lage bestimmt nicht besser...

   - "Novell DOS lähmt CD-ROM"
     c't 06/1995, S. 244
     Stichworte: MS-DOS 6.2, CD-ROM, MSCDEX, NWCDEX, SMARTDRV, NWCACHE,
                 'Hotline'

   - "Misch-DOS"
     IBM PC-DOS profitiert von Novell DOS (Alexander Hoch)
     c't 09/1995, S. 210f.
     Stichworte: PC-DOS 7.0, Novell DOS 7, DPMS, STACKER, NWCACHE, NWCDEX

   - Nachtrag zu "Misch-DOS"
     c't 10/1995, S. 11
     Stichworte: NWCACHE, Update 14, 'Ergänzungen + Berichtigungen'

   - "Windows95: altes DOS für neues Windows" (Peter Siering)
     c't 05/1996, S. 284f.
     Stichworte: Beschreibt das geänderte Boot-Verhalten von MS-DOS 7 und
                 wie man unter Windows95 ein altes MS-DOS/PC-DOS bootfähig
                 macht und, daß dieses mit Novell DOS 7 nicht funktioniert
                 (wäre bei Microsoft ja auch nicht anders zu erwarten ge-
                 wesen). [Mit einigen kleinen Patches müßte es meiner
                 Meinung nach trotzdem funktionieren, allerdings tut's ja
                 auch der OS/2- oder PTS/Boot-Manager], 'Hotline'

   - "Frontal gegen Microsoft"
     DR-DOS-Käufer reicht Antitrust-Klage ein (Christian Persson)
     c't 09/1996, S. 16
     Stichworte: Übernahme von Novells "DR DOS" durch Caldera Inc.,
                 Raymond J. Noorda, Bryan Sparks, Antitrust-Klage

   - "Laokoons Enkel"
     Windows NT 4.0 und die Konkurrenz im Netzwerk (Jürgen Kuri)
     c't 09/1996, S. 148ff.
     Stichworte: PNW
     Bemerkung:  Geht am Rande auf Novells Politik der letzten Jahre ein.
                 Hat nicht direkt etwas mit Novell DOS zu tun.

   - "Der Koloß von Provo"
     Windows NT versus Novell NetWare (Axel Kossel)
     c't 09/1996, S. 160
     Bemerkung: Geht auf Novells Stellung im Markt ein. Hat nicht direkt
                etwas mit Novell DOS zu tun.

   - "Anschluß gesucht"
     30 PCI-SCSI-Hostadapter im Vergleich (Georg Schnurer)
     c't 09/1996, S. 218ff.
     Bemerkung: Beschreibt, daß die EMM386-Speichermanager von "DR-DOS 7.x"
                (und PC-DOS 7) im Gegensatz zu MS-DOS bis 6.21 keine Pro-
                bleme mit dem PCI-Bus (bei Speicher-Ressouren oberhalb des
                ersten MegaByte) hatten (in Wahrheit hatten selbst einige
                Versionen von 6.22 noch Probleme mit PCI-Boards, erst der
                Treiber aus MS-DOS 7 half hier).

   - "Dschungelbuch"
     Novell stellt IntranetWare vor (Jürgen Kuri)
     c't 11/1996, S. 98ff.

   - "Des Kaisers neue Kleider"
     Novell sucht Antworten auf die Fragen nach der Zukunft von NetWare
     (Detlef Borchers)
     c't 03/1997, S. 48ff.
     Bemerkung: Beschreibt u.a. die Einführung von IntranetWare FSB (for
                Small Business), das als Nachfolger von Personal NetWare 1.0
                und NetWare 3.xx angesehen werden kann. Für Personal
                NetWare, NetWare, Novell DOS u.a. gibt es relativ günstige
                Upgrades. Außerdem gibt der Artikel ein paar Hintergrund-
                infos über die Ära Raymond Noorda und Novells neuen Kurs.

                                                                             
  ---------------------------------------------------------------------------

  IX.10. Andere Zeitschriftenartikel: [96-09-04]
  ==============================================

   [Weitere, hier noch nicht verzeichnete Artikel zum Thema sind, z.B. in
   Form einer Kopie, sehr willkommen.]

   - "Neue DOS-Betriebssysteme"
     Markt, Macht und Betriebssysteme - Novell DOS 7.0 contra MS-DOS 6.2
     DOS 03/1994, S. 130ff.
     Stichworte: Multitasking, Netz, DPMS, Windows
     Bemerkung:  Interessanterweise stimmt das Fazit haargenau mit dem aus
                 c't 03/1994 überein...

   - "66 Tips für Novell DOS" (Kai Hamann, Michael Kolberg)
     Computer Persönlich, 06/1994
     Bemerkung: Ein Abdruck dieser Tips wurde auch mit IX.3. publiziert.

   - "Novell DOS 7: Is It Time to Switch?" (Steve Kalman)
     Unbekanntes Computermagazin??? 03-04/1994, S. 32-35

   - "Novell: Kapitulation vor der Windows-Dominanz"
     PC-Welt, 11/1994, S. 14
     Rubrik    : Aktuell; Windows, DOS und OS/2
     Stichworte: "The war is over". Novell Mitarbeiter finden DOS nur noch
                 für PDA (persönliche digitale Assistenten) attraktiv...

   - "Novell DOS - Übereifriger Cache"
     PC-Welt, 11/1994, S. 31
     Stichworte: Beschreibt den Schönheitsfehler in der Statistik von
                 NWCACHE /S, wenn "VERIFY on" ist. Wurde mit einem Update
                 behoben.

   - "Wegen Windows: Novell DOS stirbt"
     PC-Welt, 11/1994, S. 55f.
     Rubrik    : Aktuell; Vorstellung Software
     Stichworte: Ab sofort Schmusekurs mit Microsoft; zu diesem Zeitpunkt
                 allein in Deutschland 700.000 verkaufte Novell DOS 7
                 Lizenzen
     Bemerkung : (das war noch vor dem großen Preisrutsch...).

   - "Peer-to-Peer Netz: Mini-Netz mit alten Rechnern (mit Novell DOS 7)"
     PC-Welt, 12/1994, S. 315f.
     Bemerkung : Beschreibt grob die Einrichtung eines PNW-Netzes.

                                                                             
  ---------------------------------------------------------------------------

  IX.11. Interessante Web-Sites bezüglich Novell DOS: [97-04-21]
  ==============================================================

   [Weitere Web-Sites bezüglich Novell DOS und Caldera OpenDOS finden
   sich in Kapitel I.]

   - "Novell DOS - Erste Erfahrungen" (Willibald Klein)
     URL: http://www.rz.uni-sb.de/rzinfo19/novell.html
     WWW-Artikel aus dem Magazin RZ-Info 19 (1994) der Stelle für
     Öffentlichkeitsarbeit der Uni des Saarlandes; entspricht
     weitestgehend meinen Erfahrungen. [05/1996]

   - "Pflege eines PNW-Servers" (Willibald Klein, Bernhard Stumpf)
     URL: http://www.rz.uni-sb.de/rzinfo20/rz20s491.html
     WWW-Artikel aus dem Magazin RZ-Info 20 (1994) der Stelle für
     Öffentlichkeitsarbeit der Uni des Saarlandes. [10/1996]

   - "Multitasking and Networking build into Novell DOS 7" (Scott Fletcher)
     URL: http://tcp.ca/May/NovellDOS7.html
     WWW-Artikel, entspricht weitestgehend meinen Erfahrungen. [05/1996]

   - "Novells Newest DOS" (Terje Mathisen)
     URL: http://www.byte.com/art/9406/sec9/art7.htm
     WWW-Dokument entspricht dem BYTE-Artikel 06/1994 in der Rubrik "Review"
     und beschreibt eine Reihe der positiven und negativen Erfahrungen mit
     einer - seltsamerweise trotz des Datums - offenbar sehr frühen US-
     Ausgabe von Novell DOS 7 (wohl fast noch Beta-Stadium). [10/1996]

   - "Voyager - Novell DOS 7" (Alexander Walz)
     URL: http://www-users.informatik.rwth-aachen.de/~afw/nwdos7.html
     Zusammenfassender WWW-Artikel über Geschichte und Funktionsumfang von
     DR DOS und Novell DOS. [10/1996]
     Ist derzeit nicht mehr im Angebot... [02/1997]

   - "Digital Research - The untold story: The story behind the story"
     URL: http://www.ctyme.com/dri.html
     "The 07-21-91 Summary: How the Novell buyout of Digital Research
     started"
     URL: http://www.ctyme.com/dri1.html
     "The NovOS spec: The original written proposal of NovOS to Novell"
     URL: http://www.ctyme.com/dri2.html
     "Letters to Ray Noorda about NovOS"
     URL: http://www.ctyme.com/dri3.html
     (Marc Perkel, Computer Tyme)

     Verschiedene interessante Dokumente eines hemmungslosen Visionärs
     über die Hintergründe zu Novells Aufkauf von Digital Research
     (1991) und über das, was aus "Novell DOS" noch alles hätte werden
     können...
     Marc Perkel nimmt darin für sich in Anspruch, Novell von der Idee
     einer ob seiner Features, Flexibilität und Zukunftssicherheit
     konkurrenzlosen Alternative zu MS-DOS, MS Windows usw. begeistert
     zu haben und die erste Spezifikation dafür geliefert zu haben. Von
     Digital Researchs DR DOS als Grundlage für dieses "NovOS" war dabei
     zunächst gar nicht die Rede...
     Im weiterem Verlauf der Dinge sei er dann von Novell regelrecht
     'ausgebootet' worden, was wohl auch der Beweggrund für die Ver-
     öffentlichung dieser Seiten war.
     Gleichzeitig dürfte dies auch eine der Quellen für die lange Zeit
     anhaltenden Gerüchte gewesen sein, daß Novell ein eigenes Super-
     Betriebssystem mit GUI etc. entwickeln wollte (aber wohl auch
     vom 'Corsair'-Projekt und X/GEM angeheizt). [06/1996]
     Vielleicht sind einige der besonders spitzen Bemerkungen mit der
     Übernahme von DR DOS durch Caldera überholt, aber urteilen Sie
     selbst... [08/1996]
     Mittlerweile sind diese provokaten Seiten leider wieder von
     Internet verschwunden (vermutlich hat auch Marc Perkel die
     jüngsten Entwicklungen positiv eingeschätzt); an den Hintergründen
     besonders Interessierte können die Dateien auf Anfrage aber auch
     noch von mir beziehen. [10/1996]

   - "Concurrent Control, Inc. - Multiuser DOS 7 Gold"
     URL: http://www.conctrls.com/gold.htm
     URL: http://www.conctrls.com/f-why.htm
     Diese Firma - ein ehemaliger Master VAR von DR Multiuser DOS -
     vertreibt nach wie vor Multiuser DOS 7 Gold und CCI Concurrent DOS,
     die auf DR Concurrent DOS und DR Multiuser DOS basieren. Derzeit
     wird eine am 1997-02-10 freigegebene kostenlose Demo-Version von
     Multiuser DOS 7.22 Gold zum Download angeboten. Interessanterweise
     gehen dabei einige Novell-Copyrights bis ins Jahr 1996. [03/1997]

   - "Logan Industries, Inc."
     URL: http://www.lii.com/
     Diese Firma vertreibt in den USA das Echtzeit-System IMS REAL/32 (seit
     der Version 7.50+ der neue Name für das ehemalige IMS Multiuser DOS)
     des englischen Entwicklers IMS, ebenfalls ein Abkömmling der alten
     DR Multiuser DOS Linie. Offenbar basiert das System zum Teil auch auf
     Quellen früher Novell DOS-Ausgaben, etwa ist der IMSCDEX.EXE Treiber
     ein Abkömmling des NWCDEX.EXE v1.00. Interessant ist, daß das als
     äußerst stabil angesehene Multitasking-/Multiuser-System in der Lage
     ist, neben normalen DOS-, DR DOS- und Multiuser DOS- alias CP/M-86-
     Anwendungen auch mehrere Sessions von Windows 3.xx gleichzeitig zu
     fahren, bei voller Anbindung an diverse Netze, wie z.B. NetWare und
     Abkömmlinge des alten DR Net. [03/1997]

   - "Microsoft faces antitrust suit over DR DOS"
     URL: http://biz.yahoo.com/bin/jump?/finance/96/07/24/msft_2.html
     URL: http://www.online.reuters.com/.../jump
     Reuters [08/1996]

   - "Microsoft hit with antitrust suit" (Mike Ricciuti, 1996-07-24)
     URL: http://www.cnet.com/Content/News/Files/???/cnet.clp
     CNET Inc. [08/1996]

   - "Noorda's new company acquires DR-DOS, sues Microsoft"
     (Maria Seminerio & Charles Cooper)
     URL: http://www.pcweek.com/news/0722/24esuit.html
     URL: http://www.zdnet.com/plweb-cgi/pcweek/.../24esuit.html
     PC WEEK, Ziff Davis Publishing [08/1996]

   - Web-Server der Caldera Inc., Provo, Utah  [08/1996-05/1997]
     URL: http://www.caldera.com/
     URL: http://www.caldera.com/dos/
     URL: http://www.caldera.co.uk/
     URL: http://caldera.co.uk/

     Der Web-Server der Caldera Inc. ist insofern sehr interessant für
     Novell DOS 7 Benutzer, als daß Caldera in 07/1996 alle Rechte an
     der ehemaligen Digital Research Betriebssystempalette von Novell
     übernommen hat, u.a. zu dem Zweck, das Betriebssystem DR DOS (alias
     Novell DOS) inklusive Personal NetWare, jedoch um Internet-Fähig-
     keiten, TCP/IP und eventuell sogar ein GUI bereichert unter dem Namen
     Caldera OpenDOS wieder auf den Markt zu bringen. Die englische Fassung
     von Caldera OpenDOS 7.01 ist am 1997-02-03 freigegeben worden und
     kann - für Ausbildungsstätten, Studenten und Schüler kostenlos - auf
     Calderas Web-Server bezogen werden kann. Allerdings entspricht diese
     Fassung zu noch fast 100% dem Novell DOS 7, siehe Kapitel I.5.

     Der Name ist auch gleich Programm, denn Caldera begann am 1997-04-21
     mit der Pre-Release der Quellen des Caldera OpenDOS 7.01 Kernels
     damit, nach und nach die Quelltexte von OpenDOS und natürlich
     auch der Betriebssysteme CP/M, DOSPlus, DR DOS, DR PalmDOS,
     DR Concurrent DOS, DR Multiuser DOS und Novell DOS (von GEM war
     in diesem Zusammenhang bislang nicht die Rede) im Internet öffentlich
     zugänglich machen (abgesehen von den Quelltexten der Zukäufe), um so
     einer breiten Masse ein fundiertes, sicheres Betriebssystem-KnowHow
     zu vermitteln und dadurch der weiteren Entwicklung von DOS-Programmen
     eine solide Basis zu verschaffen (keine undokumentierten Details mehr;
     nach dem alten Unix-Motto "Use the Source, Luke!" ist die bestmögliche
     Dokumentation der Quelltext).
     Natürlich bleiben die Quelltexte auch weiterhin unter dem Copyright von
     Caldera (ein wesentlicher Unterschied zu FreeDOS oder Linux, die unter
     der GPL, der "GNU General Public License" stehen), können aber für
     eigene kommerzielle Produkte lizensiert werden. Caldera will auch
     mit dem FreeDOS-Team zusammenarbeiten.
     Daß dieses fortschrittliche Konzept funktionieren kann, zeigt die
     Entwicklung des FreeWare-Unix Linux, für das Caldera ihren CND (jetzt
     COL) anbieten, nur zu gut. Bleibt zu hoffen, daß das Beispiel Schule
     macht und eine generelle Trendwende in der Betriebssystementwicklung
     einleitet.

     Der DOS-Markt ist zwar kein zukunftsorientierter Massenmarkt mehr
     (zumindest nicht bezüglich der 'Innovationsfreude' bei den bisherigen
     DOS-Versionen), eine kleine Firma wie Caldera könnte aber auch in
     Zukunft ganz gut davon leben, wenn erst einmal alle anderen DOS-
     Hersteller ihre Entwicklung endgültig eingestellt haben (Microsoft
     dürfte kein Interesse mehr an einer Weiterentwicklung von MS-DOS
     haben; und wenn, dann ist es *jetzt* zu spät; sie werden wohl kaum
     die Quellen von MS-DOS & MS Windows zur freien Verfügung stellen).
     Anbetracht der Langlebigkeit längst totgesagter Betriebssysteme
     (man vergegenwärtige sich beispielsweise einmal das starke Echo in
     CP/M-Newsgroups!!!) und der bei Weitem nicht 'so' weit (wie oft
     pauschal angenommenen) fortgeschrittenen globalen Durchdringung der
     Gesellschaft mit Computern neuster Bauart (siehe Ost-Europa, Mittel-
     Asien und Afrika) könnte sich bei weltweitem Vertrieb aus dem
     horizontalen DOS-Markt ein lukrativer vertikaler Nischenmarkt auftun,
     in dem durchaus noch langfristig Innovation möglich ist. Die Nähe zu
     Unix (Linux) ist dabei nur eine mögliche Entwicklungsrichtung.
     In jedem Fall hat eine Fortentwicklung von DOS und die *sinnvolle*
     Einbettung in moderne Betriebssystemkonzepte den unschlagbaren Vorteil,
     daß das geistige Potential und der Erfahrungsschatz von vielen tausend
     DOS-Profis und die Investitionen von Millionen DOS-Benutzern nicht
     plötzlich wertlos werden (sog. Migration Path); ein Ansatz, den
     zumindest ich mir schon seit Jahren sehnlichst gewünscht habe...

     Der Server enthält ausführliche Infos bezüglich Calderas wiederauf-
     gerollter Antitrust-Klage gegen Microsoft als Monopolisten, sowie
     diesbezügliche Pressemitteilungen und bestätigt viele der Fakten,
     die ich auch aus vielen anderen Quellen erfahren habe und die sich -
     was Betriebssystem-Interna angeht - auch mit meinen persönlichen
     Erfahrungen decken.


  ###########################################################################
  ###########################################################################


Converted to HTML by TXT2HTML (©Thomas Antoni), 29.06.2011, 17:35:56