########################################################################### ########################################################################### [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. ########################################################################### ###########################################################################