###########################################################################
########################################################################### [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馘駻ic 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:\nwdos1050円.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:\nwdos1050円.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:\nwdos1050円.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:\nwdos1050円.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:\nwdos1050円.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馥 activada attivata aktiviert ?
"deaktiviert" disabled d駸activ馥 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 0ドルA 0ドルD (für Linefeed/Wagenrücklauf), die bei
MS-DOS üblich ist (oder 0ドルD 0ドルA wie bei NDOS der Norton Utilities),
wird hier die Zeichenfolge 20ドル 0ドルD 0ドルA (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 0ドルD 0ドルA wie
auch 0ドルA 0ドルD 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 0ドルA 0ドルD
(also LineFeed/Carriage Return) enthält.
DATE < echo_.inp > protokoll.dat
b) Ein kleines Utility schreiben, das nur die Zeichenfolge 0ドルA 0ドルD
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 0ドルD 0ドルA. 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騅rier", "mars", "avril", "mai",
"juin", "juillet", "ao?t", "septembre", "octobre",
"novembre", "d馗embre"
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畸"
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%=...4円DOS.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=...4円dos.com @...4円dos.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:\sys4円dos4円dos.com c:\sys4円dos @c:\sys4円dos4円dos.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:\sys4円dos
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%4円start_.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%4円start_.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%4円start_.bat %tmp%4円start_.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\nls1252円_uni.001 Allgemeine Unicode-Dateien:
c:\windows\nls1252円_uni.002 Nicht alle dieser Dateien werden in
c:\windows\nls1252円_uni.003 Deutschland wirklich benötigt (nur
c:\windows\nls1252円_uni.031 .001, .049), aber der Einfachheit
c:\windows\nls1252円_uni.032 halber habe ich alle möglichen der
c:\windows\nls1252円_uni.033 bei PNW mitgelieferten Dateien auf-
c:\windows\nls1252円_uni.034 gelistet. Die großen NetWare-Ausgaben
c:\windows\nls1252円_uni.039 unterstützen noch wesentlich mehr
c:\windows\nls1252円_uni.041 Codeseiten und Länder; siehe auch
c:\windows\nls1252円_uni.044 Kapitel II.16.
c:\windows\nls1252円_uni.045 Sollten Sie Unterstützung für andere
c:\windows\nls1252円_uni.046 Länder oder Codeseiten benötigen,
c:\windows\nls1252円_uni.047 finden Sie im 'Novell Client Kit for
c:\windows\nls1252円_uni.049 DOS & Windows 3.xx' sicherlich die
c:\windows\nls1252円_uni.061 nötigen Dateien; siehe auch Kapitel I.2.
c:\windows\nls1252円_uni.081
c:\windows\nls1252円_uni.351
c:\windows\nls1252円_uni.358
c:\windows\nls437円_uni.001
c:\windows\nls437円_uni.003
c:\windows\nls437円_uni.031
c:\windows\nls437円_uni.032
c:\windows\nls437円_uni.033
c:\windows\nls437円_uni.034
c:\windows\nls437円_uni.039
c:\windows\nls437円_uni.041
c:\windows\nls437円_uni.044
c:\windows\nls437円_uni.046
c:\windows\nls437円_uni.049
c:\windows\nls437円_uni.061
c:\windows\nls437円_uni.358
c:\windows\nls\uni_1252.001
c:\windows\nls\uni_1252.002
c:\windows\nls\uni_1252.003
c:\windows\nls\uni_1252.031
c:\windows\nls\uni_1252.032
c:\windows\nls\uni_1252.033
c:\windows\nls\uni_1252.034
c:\windows\nls\uni_1252.039
c:\windows\nls\uni_1252.041
c:\windows\nls\uni_1252.044
c:\windows\nls\uni_1252.045
c:\windows\nls\uni_1252.046
c:\windows\nls\uni_1252.047
c:\windows\nls\uni_1252.049
c:\windows\nls\uni_1252.061
c:\windows\nls\uni_1252.081
c:\windows\nls\uni_1252.351
c:\windows\nls\uni_1252.358
c:\windows\nls\uni_437.001
c:\windows\nls\uni_437.003
c:\windows\nls\uni_437.031
c:\windows\nls\uni_437.032
c:\windows\nls\uni_437.033
c:\windows\nls\uni_437.034
c:\windows\nls\uni_437.039
c:\windows\nls\uni_437.041
c:\windows\nls\uni_437.044
c:\windows\nls\uni_437.046
c:\windows\nls\uni_437.049
c:\windows\nls\uni_437.061
c:\windows\nls\uni_437.358
c:\windows\nls\uni_col.001
c:\windows\nls\uni_col.002
c:\windows\nls\uni_col.003
c:\windows\nls\uni_col.031
c:\windows\nls\uni_col.032
c:\windows\nls\uni_col.033
c:\windows\nls\uni_col.034
c:\windows\nls\uni_col.039
c:\windows\nls\uni_col.041
c:\windows\nls\uni_col.044
c:\windows\nls\uni_col.045
c:\windows\nls\uni_col.046
c:\windows\nls\uni_col.047
c:\windows\nls\uni_col.049
c:\windows\nls\uni_col.061
c:\windows\nls\uni_col.081
c:\windows\nls\uni_col.351
c:\windows\nls\uni_col.358
c:\windows\nls\uni_mon.001
c:\windows\nls\uni_mon.002
c:\windows\nls\uni_mon.003
c:\windows\nls\uni_mon.031
c:\windows\nls\uni_mon.032
c:\windows\nls\uni_mon.033
c:\windows\nls\uni_mon.034
c:\windows\nls\uni_mon.039
c:\windows\nls\uni_mon.041
c:\windows\nls\uni_mon.044
c:\windows\nls\uni_mon.045
c:\windows\nls\uni_mon.046
c:\windows\nls\uni_mon.047
c:\windows\nls\uni_mon.049
c:\windows\nls\uni_mon.061
c:\windows\nls\uni_mon.081
c:\windows\nls\uni_mon.351
c:\windows\nls\uni_mon.358
c:\windows\nls\deutsch\netwarer.drv Referenziert über %NWLanguage%
c:\windows\nls\deutsch\netware.hlp Das VLM-Kit VLM121_1.EXE -
c:\windows\nls\deutsch\login.dat VLM121_6.EXE benötigt eine Reihe
c:\windows\nls\deutsch\login.msg weiterer Dateien, die hier aufge-
c:\windows\nls\deutsch\loginw31.hlp listet werden, aber nur bei Ver-
wendung von LOGINW31.EXE benötigt
werden.
c:\windows\nls\deutsch\taskid.msg Eventuell brauchen Sie auch noch
c:\windows\nls\deutsch\tbmi2.msg diese Dateien.
Sollten Sie einmal eine Fehlermeldung erhalten, daß die Datei
NETWARER.DRV ncht gefunden werden kann, sollten Sie überprüfen ob
1. die Variable %NWLanguage% z.B. in STARTNET.BAT korrekt gesetzt wird.
Sie muß den Namen des Unterverzeichnisses von \WINDOWS\NLS\DEUTSCH
enthalten, hier also 'DEUTSCH' (siehe Kapitel II.16., IV.7., VI.2.),
als auch
2. ob Sie MS Windows über ein Substitut-Laufwerk o.ä. aufgerufen haben.
Falls dies zutrifft, sollten Sie stattdessen MS Windows über einen
Batchjob aufrufen, der vorher auf das Windows-Laufwerk und Verzeichnis
wechselt. U.U. kann man auch auf den undokumentierten Befehl TRUENAME
ausweichen (nicht getestet).
iv. Weitere Hinweise:
---------------------
Es ist auch möglich, MS Windows als einen Task des DOS-Task-Managers
TASKMGR auszuführen (allerdings arbeitet MS Windows dann nur im Standard
Modus /S), wenn Sie nach dem Netzwerk, aber noch vor MS Windows den
TASKMGR als Multitasker laden. Auf diese Weise können Sie - zumindest
theoretisch - z.B. MS Windows mit preemptivem Multitasking-Fähigkeiten
ausrüsten und sogar mehrere Windows-Sessions nebeneinander laufen lassen,
in der Praxis ist der dafür notwendige Aufwand meist viel zu groß.
Wenn Sie stattdessen TASKMGR als Prozeßumschalter laden, kann MS Windows
sogar im Erweiterten 386er Modus ausgeführt werden. Umgekehrt ist es auch
möglich, den TASKMGR in einer Windows-DOS-Box als Prozeßumschalter zu
starten - die Vielfalt kennt keine Grenzen. Wenn dabei immer der gleiche
TASKMGR (und nicht TASKMAN) zum Einsatz kommt, kann man sogar aus dem
Task-Menü von Windows die DOS-Tasks, die vor Windows gestartet wurden,
sowie auf die Tasks innerhalb einer DOS-Box umschalten, d.h. alle Tasks
des Systems über das TASKMGR-Menü steuern. Achten Sie in diesem Fall
besonders auf die für das TASKMGR-Menü gewählte Tastenkombination.
Wenn Sie MS Windows im Standard Modus in Verbindung mit dem Task-Manager
ausführen wollen, müssen Sie u.U. noch das Programm TBIM2 laden, das
Netzanforderungen in unterschiedlichen Tasks koordiniert.
Ein Beispiel für einen Batchjob dieser Art:
WIN.BAT:
@ECHO off > \dev\nul
REM Das Starten über ein Substitut-Laufwerk führt dazu, daß der Treiber
REM NETWARER.DRV (Deutsch) nicht gefunden wird.
c:
CD c:\windows
REM Video-Speicher freigeben bei DR DOS/Novell DOS.
REM Achtung: Mit 4DOS 5.51 (only) kann dies Probleme verursachen, wenn
REM Video-Speicher aktiv war.
IF EXIST %dos%\MEMMAX.EXE CALL MEMMAX -v
REM Im Standard Modus wird ein spezieller Treiber für TASKMGR benötigt.
REM Warntöne (von TBMI2) werden ebenfalls ins Null-Device geschickt! ;-)
FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 > \dev\nul
REM In Verbindung mit älteren Versionen von K3PLUS war K3_DISZZ/K3_ENZZ
REM evtl. erforderlich (mit neueren Versionen von K3PLUS/FreeKEYB nicht
REM mehr):
REM @CALL k3_diszz
@win.com %1 %2 %3 %4 %5 %6 %7 %8 %9
REM @CALL k3_enzz
FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 /u > \dev\nul
IF EXIST c:\nwdos\nwcache.exe CALL NWCACHE /size=max
Sollten Sie beim Start von MS Windows Fehlermeldungen der Art 'Konnte
wichtigen Gerätetreiber, der evtl. für den Erweiterten 386er Modus not-
wendig ist, nicht finden' bekommen, sollten Sie versuchen, MS Windows
über einen Batchjob aufzurufen und vorher in das Windows-Verzeichnis zu
wechseln. Alternativ können Sie in der SYSTEM.INI auch die kompletten
Pfade auf die Treiber angeben oder Sie können dieses Verzeichnis auch
in die PATH-Anweisung aufnehmen, wodurch solche Probleme generell
vermieden werden.
Bei derartigen Problemen hilft es oft, WIN /B aufzurufen; dadurch
wird während des Starts von Windows in der Datei BOOTLOG.TXT ein
Startprotokoll aufgezeichnet.
Überprüfen Sie, ob NWDOS.386 im Hauptverzeichnis liegt und sichtbar ist.
Ansonsten können Sie den Pfad zu dieser Datei in der CONFIG.SYS bei
EMM386 angeben oder eine Anweisung SWITCHES= entsprechend Microsofts
Konventionen verwenden.
WINA20.386 und NWDOS.386 werden nur für Windows 3.0 benötigt, ansonsten
können diese Dateien gelöscht werden. Allerdings muß man dann auch den
entsprechenden Eintrag in der SYSTEM.INI entfernen, damit die Fehler-
meldung unterbleibt.
Überprüfen Sie auch die Einstellungen in der %NWDOSCFG%\TASKMGR.INI
Datei. Bei richtiger Konfiguration wird statt MS Windows' TASKMAN
Novell DOS' TASKMGR als Manager für MS Windows geladen, deshalb sind
dessen Einstellungen u.U. nicht unrelevant.
Noch ein Tip zum Schluß: Gerade auch im Zusammenspiel unterschiedlicher
Kommandoprozessoren in DOS-Boxen unter Windows ist es meist empfehlens-
wert, in der DOSPRMPT.PIF Datei nicht direkt COMMAND.COM (bzw. 4DOS.COM)
anzugeben, sondern %ComSpec%, das immer den richtigen Eintrag enthalten
sollte. Beim Speichern dieser Einstellung wird der PIF-Editor eine
Fehlermeldung bezüglich einer falschen Dateiendung ausgeben. Diese kann
getrost ignoriert werden, Windows macht nach dem Speichern genau das,
was es soll und ersetzt später die Variable durch ihre aktuelle Belegung.
(Beim ersten Speichern ist Windows unbarmherzig, hier muß man also
zunächst COMMAND.COM angeben, speichern, dann durch %ComSpec% ersetzen
und erneut speichern...)
Danach sollte MS Windows unter Novell DOS ebenso stabil wie unter
MS-DOS laufen (meine vielleicht paradoxe persönliche Erfahrung:
erstaunlicherweise stabiler!!!).
Haben Sie auf einem neuen Rechner zunächst Novell DOS 7 und dann
MS Windows 3.xx installiert, wollen Sie sicherlich die Installation
der Windows-Tools von Novell DOS 7 nachholen (sehr empfehlenswert).
Dafür müssen Sie u.U. Novells SETUP.INI (in %NWDOSCFG% alias C:\NWDOS\)
modifizieren:
WinPath=Pfad auf Windows-Verzeichnis (meist C:\WINDOWS\)
FirstTime=Yes
Element0Installed=Yes
Element1Installed=No
Element2Installed=Yes
NetCFGDir=Pfad auf die PNW (meist C:\NWCLIENT\)
WINDOWS=No
---------------------------------------------------------------------------
VIII.2. Novell DOS, MS Windows 3.xx und Genius-Maustreiber 10.20:
====================================================[96-02-05]===
Stichworte: Genius-Maus, 3-Tasten-Modus, GMOUSE.SYS/COM/DRV, SimTel,
TASKMGR, Windows, 4DOS
Über SimTel ist ein neuer Genius-Maustreiber 10.20 (1993) verfügbar,
den viele Benutzer von Genius-Mäusen wohl schon lange vergeblich gesucht
haben, da die letzte weitverbreitete Version 9.06 (1991) schon etliche
Jahre zurücklag und mit verschiedener Software Probleme bereitete (u.a.
auch mit dem TASKMGR aus frühen Versionen von Novell DOS 7, siehe
Kapitel VII.1.).
Der neue Treiber in seiner MS Windows Version GMOUSE.DRV ermöglicht
ruckfreies Arbeiten mit der Maus, auch im 3-Tasten-Modus. Die bisherigen
Treiber (die bei MS Windows beilagen) oder diverse andere Fremdtreiber
arbeiteten leider nicht völlig problemlos mit MS Windows über Novell DOS:
der Zeiger sprang bei Diskettenzugriffen schon bei kleinsten Bewegungen
der Maus wild über den Bildschirm und beruhigte sich erst, wenn der
Cache NWCACHE nach der Startphase zur Ruhe gekommen ist (mit MS-DOS
und SMARTDRV zeigte sich dieses Verhalten nicht, aber repräsentativ
muß das nicht sein).
Leider stürzt das SETUP-Programm zu diesem Genius-Maustreiber während
der Installation ab, da es u.a. nicht mit Novell DOS- (und DR DOS-)
spezifischen Einträgen in CONFIG.SYS (Boot-Menüs) zurechtkommt. Aber
auch ansonsten gibt es eine Reihe von Problemen mit diesem Programm
(beschränkte Verzeichniswahl, z.B. keine Verzeichnisse mit einem Punkt).
Es bleibt die manuelle Installation, bei der man für MS Windows in
SYSTEM.INI den MOUSE.DRV=\path\GMOUSE.DRV eintragen muß.
---------------------------------------------------------------------------
VIII.3. Novell DOS und MS Windows 3.xx Netzinstallation: [96-06-13]
===================================================================
Stichworte: Netzinstallation, PNW, SYSTEM, SETUP.INI
Die Dateien NETWARE.DRV, FASTBACK.386 und VNETWARE.386 müssen ins
Windows-Netzverzeichnis kopiert werden, ins lokale Windows \SYSTEM\
Verzeichnis gehören NETWPNW.DLL, NW*.DLL, PNW.DLL und PNDDIAGW.DLL.
Die lokale SYSTEM.INI muß die in Kapitel VIII.1. beschriebenen
Einstellungen vorweisen (nach c't 08/1994 S.195).
Bezüglich FASTBACK.386 und PNW siehe auch Kapitel VIII.1.
---------------------------------------------------------------------------
VIII.4. Windows-Maus in DOS-Boxen im Fenster benutzen: [96-12-19]
=================================================================
Stichworte: Logitech LVMD.386, SYSTEM.INI, Drag & Drop, Copy & Paste,
CLOAKING, DPMS
Dieser Tip funktioniert unabhängig von der installierten DOS-Version
(also auch mit MS-DOS/PC-DOS)!
Viele haben sich sicherlich schon darüber geärgert, daß man zwar
unter MS Windows 3.xx DOX-Boxen öffnen kann, die Maussteuerung einer
dort gestarteten Applikation jedoch normalerweise nur dann funktioniert,
wenn man die Applikation im Vollbildmodus startet.
Schaltet man dann auf den Fensterbetrieb um, so ist die Maus plötzlich
verschwunden. Stattdessen kann man mit der Windows-Maus arbeiten,
auf die aber das DOS-Fenster nicht reagiert. Schaltet man zurück in den
Vollbildmodus, kommt es - abhängig von der jeweiligen Applikation - sogar
vor, daß nun auch hier die Maus verschwunden ist.
Startet man die Applikation jedoch im Fenster, erscheint die DOS-Maus
erst gar nicht und bleibt üblicherweise auch beim Umschalten in den
Vollbildmodus verschwunden.
Diese Probleme sind nur logisch, denn die Applikation wird nicht ständig
versuchen, eine evtl. beim Start nicht verfügbare Maus nachträglich zu
aktivieren.
Allerdings gibt es eine Möglichkeit, dieses Problem sehr elegant
zu lösen, und zwar unabhängig von den verwendeten DOS- und Windows-
Maustreibern:
Logitech und OEMs liefern zu ihren Mäusen ein Treiberpaket namens
"MouseWare" mit. Dieses Paket ist aber auch an vielen Stellen in den
Datennetzen verfügbar. In der Version 6.30 dieses Pakets befindet sich
u.a. ein virtueller Gerätetreiber LVMD.386 für MS Windows 3.xx, der statt
des Standard-Treibers in der SYSTEM.INI [386Enh] Sektion eingetragen
werden muß (falls der Treiber nicht im \WINDOWS\SYSTEM\ Verzeichnis
liegt, bei Bedarf mit Pfadangabe).
SYSTEM.INI:
[386Enh]
...
; z.B. einen Eintrag wie
; mouse=mscvmd.386
; ersetzen durch einen Logitech-Treiber
mouse=lvmd.386
...
Der 'normale' Windows-Maustreiber in SYSTEM.INI und der üblicherweise
in CONFIG.SYS oder AUTOEXEC.BAT geladene DOS-Maustreiber braucht nicht
geändert zu werden (eine einigermaßen aktuelle API-Unterstützung des
Treibers vorausgesetzt: GMOUSE 10.20 und verschiedene Microsoft-Treiber
funktionierten jedenfalls).
Nach dieser Änderung kann man nun auch in DOS-Boxen, die im Fenster
laufen, den Windows-Mauszeiger benutzen:
Befindet sich der Mauszeiger über dem Fenster der DOS-Box, beziehen sich
alle Tastendrücke, Drag & Drop-Operationen etc. auf die in der DOS-Box
laufende Applikation (besonders praktisch z.B. für den Norton Commander
NC 5.0x, der neuerdings über Drag & Drop Möglichkeiten verfügt. Kleiner
Seitenhieb: Ob der NC eigentlich immer noch der meistgenutzte Datei-
manager unter Windows ist? ;-) ).
Außerhalb des Fensters bezieht sich die Maus natürlich wie gewohnt auf
die Windows-Anwendungen.
Die einzige Einschränkung ist, daß Mausoperationen bei MS Windows 3.xx
nicht über die Grenzen eines Fensters hinweg möglich sind, denn
schließlich läuft jede DOS-Box in einer eigenen virtuellen Maschine und
bekommt ohne spezielle Kommunikation mit Windows nichts davon mit, daß
sie in einem Fenster unter Windows läuft.
Mit Windows95 hat sich dies jedoch geändert (und das unabhängig von
obigem Treiber); hier werden beschränkte Drag & Drop und Copy & Paste
Operationen zwischen DOS- und Windows-Applikationen geboten.
Eine Copy & Paste Funktion (und unter Zuhilfenahme dieses Tricks auch
mit kompletter Windows-Mausunterstützung für die DOS-Box) bietet aller-
dings auch schon MS Windows 3.xx:
Läuft eine DOS-Box im Fenster, so kann man über das Systemmenü
(links oben in der Fensterumrahmung) unter dem Punkt 'Bearbeiten'
auf 'Markieren' gehen und dann Bildschirmausschnitte des angezeigten
Fensters markieren. Bezüglich der genauen Arbeitsweise (und anderer
Möglichkeiten, etwa im Vollbildmodus) sei auf die Online-Hilfe von
NOTEPAD.EXE (der Zwischenablage) verwiesen.
Normalerweise kann man dafür (im Fensterbetrieb) nur die Cursor-Tasten
in Verbindung mit <Shift> benutzen. Mit dem oben angesprochenen Logitech-
Treiber kann man jedoch nach Aktivierung des 'Markieren'-Menüpunktes
(sonst bezieht sich die Maussteuerung ja wie oben erläutert auf die
Applikation selbst) wie gewohnt den Windows-Mauszeiger benutzen
(linke Maustaste), um Bereiche zu markieren und dann mit 'Kopieren' in
die Zwischenablage zu kopieren. Von dort kann sie dann mit 'Bearbeiten'/
'Einfügen' als simulierte Tastatureingabe in eine andere DOS-Anwendung
übernommen werden oder aus der Zwischenablage auch in Windows-Anwendungen
eingebunden werden.
Nachbemerkung:
In der Logitech MouseWare 6.50+ befindet sich auch eine neue Version
des 'normalen' DOS-Maustreibers, der vielleicht für Sie interessant ist:
Diese neue Version unterstützt das CLOAKING-API, und kann sich, wenn
man vorher den beiliegenden Treiber CLOAKING.EXE geladen hat (kann auch
in CONFIG.SYS mit DEVICE=/DEVICEHIGH= geladen werden), bis auf 1 KByte
aus dem ersten MegaByte auslagern (statt sonst 27 KByte zu belegen)!
(Dies funktioniert sogar in CONFIG.SYS, wenn man auch MOUSE.EXE per
DEVICE=/DEVICEHIGH= lädt...)
CLOAKING ist eine Entwicklung von Helix Software und kostet selbst nur
1 KByte Speicher. CLOAKING ist von seinem Einsatzzweck und der Funk-
tionalität Novells DPMS äußerst ähnlich, in Wahrheit enthält der
CLOAKING-Treiber (undokumentiert) selbst einen 'Cloaked DPMS-Server',
d.h. das CLOAKING-API ist eine Obermenge von Novells DPMS-Standard!!!
Obwohl laut Logitech offiziell nicht unterstützt, arbeitet CLOAKING
natürlich nicht nur deswegen in praktisch allen Konfigurationen (mit
/MULTI=on) einwandfrei mit Novells Speichermanagern zusammen (getestet
mit Update 15, lediglich der TASKMGR stürzte bei mir immer ab, sobald
CLOAKING geladen war :-( ). Weitere Hinweise zu CLOAKING und DPMS finden
sich in Kapitel II.5. bei DPMS.
###########################################################################
###########################################################################
IX. LITERATUR:
==============
---------------------------------------------------------------------------
IX.1. Novell DOS 7 Handbuch:
============================
Autoren : nicht bekannt (Novell)
(Übersetzung des DR DOS 6.0 Handbuchs: Monika Fürst, BDÜ)
Sonstiges: DOSBOOK
Gute Einführung in Novell DOS 7 (auch einige didaktische Hinweise für
Anfänger, allerdings war hier das DR DOS 6 Handbuch ausführlicher),
enthält aber leider nicht die komplette Dokumentation des Systems. An
vielen Stellen wird auf die wesentlich ausführlichere Online-Hilfe
DOSBOOK verwiesen. Diese Idee des elektronischen Handbuchs ist eigentlich
auch ganz praktisch, allerdings ist das DOSBOOK nicht ganz frei von
kleinen Fehlern und fehlerhaften Verknüpfungen, die sich leider wegen
der komprimierten Form des Buches nicht selbst korrigieren lassen.
Auf einer Novell DOS 7 CD-ROM (BHV-Verlag) soll allerdings eine Text-
Version des DOSBOOKs existieren, die damit die nachträgliche Bearbeitung
durch den Benutzer (Kommentare etc.) erlauben würde (allerdings dann
wieder nicht die Einbindung in DOSBOOK bietet...).
---------------------------------------------------------------------------
IX.2. Das große Buch zu Novell DOS 7 (Data Becker):
===================================================
Autoren : Klemens Mai, Dirk Larisch, H. Tronsdorf, M. Tronsdorf
ISBN : 3-8158-1030-2
Sonstiges: 1. Auflage 1994, 1086 Seiten, 3,5" Diskette, DM 69,-
Für meine Begriffe die beste Fremddokumentation zu Novell DOS 7. Zwar
enthält auch dieses Buch einige kleinere Fehler, kann aber sowohl für
absolute Anfänger als auch für DOS-Profis eine ständige Referenz neben
dem DOSBOOK sein. Erläutert DOS-Grundlagen für Anwender verständlich
und deckt - bis auf komplett ausgesparte undokumentierte Details und
ganz spezielle Kniffe und Workarounds für Freaks - eigentlich das ganze
System (auch PNW) gebührend ab. Viele Beispiele aus der Praxis und eine
komplette Kommandoübersicht. Viel Info, übersichtliches Layout.
Wirkliche Problemfälle, die auch DOS-Profis zum Verzweifeln bringen
können, deckt dieses Buch allerdings auch nur am Rande ab (vielleicht zu
viel verlangt von einem Buch). Beschränkt sich auf offizielle Eigen-
schaften des Systems, ist darin aber sehr gut.
Der auf der Diskette enthaltene Bildschirmschoner BLACKOUT ist so
unzureichend, daß man ihn getrost vergessen kann (Ersatz z.B. durch
den in den erweiterten Tastaturtreiber K3PLUS/FreeKEYB eingebauten
Bildschirmschoner - zu beziehen über mich). Die Oberfläche TEMPEST 1.0
erinnert leicht an VIEWMAX von DR DOS 6, bietet aber leider nicht eine
direkte Unterstützung für TASKMAX/TASKMGR. Ob dies in späteren Versionen
nachgeholt wurde, ist mir nicht bekannt.
An einer Stelle werden sogar die frühen Updates zu Novell DOS erwähnt
(allerdings mittlerweile völlig veraltet), was aber darauf schließen
läßt, daß dieses Buch nicht ganz in der sonst üblichen Eile produziert
(am besten noch vor Erscheinen des Betriebssystems) publiziert wurde.
Kostet offiziell DM 69,-, wurde aber nach dem Abgang von Novell DOS 7
für DM 10,- bis 20,- verrammscht (die sich in jedem Fall lohnen).
---------------------------------------------------------------------------
IX.3. Novell DOS 7 - Das Kompendium (Markt & Technik):
======================================================
Autoren : Kai Hamann, Michael Kolberg
ISBN : 3-87791-556-6
Sonstiges: 10/1994, 750 Seiten, 3,5" Diskette, DM 69,-
Relativ gute Einführung in Novell DOS, deckt die wichtigsten Themen und
alle Hauptbelange des Systems (auch PNW) aus Anwendersicht ab. Enthält
relativ wenig Fehler. Recht komplette Kommandoübersicht und einiger-
maßen übersichtliches Layout. Spezialthemen (wie z.B. Codeseiten-
Einrichtung) werden nicht behandelt bzw. nur auf das SETUP-Programm
verwiesen.
Enthält in einem Anhang auch Tips und Tricks zu Workarounds und un-
dokumentierten Eigenschaften des Systems. Diese Hinweise sind nicht
immer korrekt, nicht vollständig oder gelten nur für frühe Versionen
von Novell DOS. Trotzdem ist dieser Ansatz lobenswert, da durch Anwendung
der Tips teilweise mehr aus dem System herausgeholt werden kann (für
Leser *dieser* Datei aber nichts Neues mehr). Besonders lobenswert ist,
daß dieses Buch anscheinend nicht in der sonst üblichen Eile produziert
wurde, sondern tatsächlich einmal Praxiserfahrungen mit einer Final-
Release (und Updates) eingeflossen sind.
Die auf der Diskette mitgelieferten Treiber-Updates zu Novell DOS 7
(06/1994) sind mittlerweile hoffnungslos veraltet. Zusätzlich enthält
die Diskette auch noch einige andere NetWare-Updates, und einige Screen-
shots von Novell DOS Utilities.
Kostet offiziell DM 69,-, wurde aber zuletzt für ca. DM 10,- bis 15,-
verrammscht, die sich durchaus lohnen.
---------------------------------------------------------------------------
IX.4. Novell DOS 7 und Personal NetWare (Addison Wesley): [96-05-29]
====================================================================
Autoren : Michael Gerding, Björn Kibbel
ISBN : 3-89319-758-3
Sonstiges: 1. Auflage 1994, 919 Seiten, DM 79,-
Dieses Buch aus der Reihe Software-Klassiker hat bei mir leider keinen so
guten Eindruck hinterlassen.
Obwohl das Buch im Prinzip - wie die beiden anderen Bücher auch - fast
das gesamte System (auch PNW) aus Anwendersicht abdeckt, ist es von den
Beispielen eher für absolute Newcomer in DOS geeignet (Wer schon gewisse
Erfahrungen mit DOS hat, kommt sich bei vielen Beispielen und 'wichtigen'
Hinweisen teilweise eher hochgenommen vor). Trotzdem ist es für mich
fraglich, ob der absolute Newcomer hier das System in der didaktisch
geeignetsten Form dargeboten bekommt. Die Suche nach detaillierten
Informationen zu einem ganz speziellen Thema ist nahezu unmöglich, da
die Informationen im Rahmen der Einführung weit gestreut sind.
Speziellere Themen wie z.B. Codeseitenunterstützung fehlen komplett.
Allerdings muß man den Autoren zugute halten, daß der Ansatz hier im
Vergleich zu vielen anderen Büchern etwas anders liegt: Die Autoren
versuchen durch Einführungen in die PC-Welt (Geschichte, Hardware,
Software, DOS allgemein, auch Windows-Einführung) eine Allround-
Dokumentation für PC-Newcomer zu bieten. Sie gehen auch auf die
externe Version von PNW ein.
Das Layout ist teilweise äußerst unübersichtlich und verschwenderisch
zugleich, außerdem enthält dieses Buch wirklich eine extreme Anzahl
von typographischen und sachlichen Fehlern. Vieles wurde anscheinend
ohne Überprüfung von einem Buch über MS-DOS kopiert, viele Parameter
gelten für MS-DOS (teilweise sogar nur für ziemlich alte MS-DOS Ver-
sionen), nicht für Novell DOS. Die Kommandoübersicht ist relativ un-
vollständig (verglichen mit den Übersichten der anderen Bücher), die
Parameter sind nicht alphabetisch sortiert.
Enthält auch einige Hinweise auf bei Novell DOS 7 neue oder undokumen-
tierte Eigenschaften und veranlaßte mich nach der Suche von versteckten
Features (leider kam dabei nichts Neues heraus), entsprechende Andeu-
tungen im Buch galten also entweder für Beta-Versionen von Novell DOS
oder sind schlichtweg falsch.
Aufgrund der Vielzahl der negativen Kritikpunkte (die wohl so ziemlich
jedem Leser aufstoßen werden, sobald er sie bemerkt), stellt sich die
Frage, ob dieses Buch nicht eher ein unfertiges Manuskript war, das viel
zu früh in Druck gegangen ist. Mein normalerweise recht positiver Ein-
druck von diesem Verlag hat mich hier doch äußerst arg enttäuscht.
Kostet offiziell DM 79,-, in Ausverkaufsaktionen für ca. DM 20,- zu
haben, die sich m.E. nach für etwas erfahrene DOS-Benutzer nicht lohnen.
---------------------------------------------------------------------------
IX.5. Novell DOS 7 - Networking, Multitasking, Systemoptimierung:
======(Addison-Wesley)==============================[97-01-14]===
Autoren : Frank Grieser, Andreas Winterer
ISBN : 3-89319-676-5
Sonstiges: 1. Auflage 1994, 386 Seiten, DM 60,-
Dieses vergleichsweise kompakte Buch beschäftigt sich entsprechend seinem
Titel im Gegensatz zu den anderen Büchern weniger mit den Einsteiger-
problemen und setzt ein paar System- und Konfigurationskenntnisse voraus
(aber nicht allzu viel).
Die Zusammenstellung hat bei mir einen recht positiven Eindruck hinter-
lassen, und ich denke, das Buch kann in der Praxis gute Dienste erweisen.
Allerdings konnte ich in dem Buch und auf der beiliegenden Diskette -
von BACKUP, RESTORE, HIBUFFERS= und einigen NET.EXE-Optionen abgesehen -
keine Hinweise auf undokumentierte Systemeigenschaften und größere
Fehlerkorrekturen bezüglich Novells eigener Dokumentation entdecken,
wie auf dem Rückdeckel spektakulär geworben wurde. Obwohl auch dieses
Buch eine ganze Reihe Fehler enthält (die dann allerdings im Novell-
Handbuch meist genauso falsch beschrieben werden), enthielt das Buch
genügend Novell DOS spezifische Hinweise, so daß bei mir hier nicht
der Eindruck eines übereilten 'Updates' eines MS-DOS Buches entstand.
Die beiden auf der Diskette beiliegenden Hypertext-Online-Referenzen zu
Novell DOS Kommandos und NET.EXE (von den Autoren entwickelt auf der
Basis von Davids ReadMe-Compiler) haben mir - trotz der Fehler - gut
gefallen und können das DOSBOOK in manchen Punkten ergänzen. Das Update 4
zu Novell DOS, das ebenfalls mitgeliefert wird, ist natürlich hoffnungs-
los veraltet...
Ich konnte das Werk kürzlich als Restposten für ganze DM 5,- ergattern,
die sicherlich lohnen, denn auch für Leser dieser Datei sind darin
noch einige neue Tips, wenn auch keine neuen undokumentierten Details
enthalten.
---------------------------------------------------------------------------
IX.6. Undocumented DOS (Addison Wesley):
========================================
Autoren : Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michels,
Jim Kyle
ISBN : 0-201-63287-X
Sonstiges: 2. Auflage, US 44ドル.95, ca. DM 118,-, 856 Seiten, 3,5" Diskette
Kein Buch für Anwender, stattdessen ein absolutes Muß für ernsthafte DOS-
und Windows-Programmierer. Die zweite Ausgabe enthält auch erste Hinweise
zu Novell DOS 7 Features (war noch im Beta-Stadium), obwohl hauptsächlich
MS-DOS Interna beschrieben werden (die aber fast komplett auch für
Novell DOS 7 gelten). Sehr gut geschrieben, deckt viele Zusammenhänge
äußerst plastisch auf. Leicht verständliches Englisch.
Viele Details der ersten Ausgabe sind in das leider mittlerweile
vergriffene, aber nach wie vor äußerst empfehlenswerte Buch 'DOS 5 für
Programmierer - Die endgültige Referenz' von Arne Schäpers eingeflossen
(der auch ausführlich auf DR DOS 3.41 und 5.0 eingeht), die zweite
Ausgabe von 'Undocumented DOS' enthält aber wiederum viele Informationen
aus diesem Buch bezüglich der DR DOS Spezifika. Neben einer Vielzahl
sinnvoller Programmiertools ist auf der Diskette die Interrupt-Liste
von Ralf Brown enthalten, die aber mittlerweile in einer erheblich ver-
besserten und erweiterten Form über das Internet zu beziehen ist (siehe
Bezugshinweis am Beginn dieses Dokuments).
Wie gesagt, für Anwender völlig ungeeignet, für Programmierer ein Muß.
---------------------------------------------------------------------------
IX.7. DOS 5 für Programmierer - Die endgültige Referenz (Addison Wesley):
============================================================[97-01-03]===
Autor : Arne Schäpers
ISBN : 3-89319-350-2
Sonstiges: 1. Nachdruck 1991, DM 99,-, 1123 Seiten, 360 KByte 5.25" Disk
Ebenfalls ein Buch 'for programmers only'. Auch wenn mittlerweile reich-
lich betagt (nach meinem Kenntnisstand ist auch keine Neuauflage mehr
zu erwarten (Wer interessiert sich schon noch für DOS??? Na, Sie - wenn
Sie tatsächlich dieses Dokument bis hierhin durchgelesen haben! ;-) ),
bleibt dieses Buch auch neben der 2. Auflage von Undocumented DOS ein
essentieller Fundus für DOS-Interna, der ausführlich auf MS-DOS bis 5.0
und DR DOS 3.41 und 5.0 eingeht. Da vieles - wenn auch lange nicht
alles - DR DOS-Spezifische auch für Novell DOS 7 gilt, sehr empfehlens-
wert. Allerdings enthält auch dieses Buch einige massive sachliche Fehler
oder Fehlschlüsse (nun, wer im Glashaus sitzt, sollte nicht mit Steinen
werfen, sorry ;-) ), aber die Unzahl von Beispielprogrammen zu allen
DOS-Funktionen entschädigen wirklich mehr als gut dafür!
Als Restposten teilweise für gut angelegte DM 15,- zu ergattern.
---------------------------------------------------------------------------
IX.8. Weitere Literatur: [97-02-26]
===================================
Bemerkung: Der Vollständigkeit halber eine einfache Auflistung...
Da mir die Mehrzahl der Bücher nicht vorliegt, meist
ohne irgendeine Wertung...
- "Einsteigerseminar - Novell DOS 7"
bhv, 1994, 427 Seiten, DM 20,-
ISBN 3-89360-735-8
- "Novell DOS 7" (H. Mehlig, J. Waßermann)
Rowohlt, 1994, 430 Seiten, DM 23,-
ISBN 3-499-19814-2
- "Novell DOS 7 und Personal NetWare optimal einsetzen"
(B. Kibbel, B. Kretschmer, Herausgeber: Haselier???, Fahnenstich)
Econ & Addison-Wesley, 1994, 363 Seiten, DM 20,-
ISBN 3-612-28047-3
Bemerkung: Wirkt teilweise wie eine Kurzfassung des Buches aus IX.4.
und enthält genauso falsche Informationen über angebliche
Aufrufoptionen bestimmter Novell DOS 7 Tools (ein paar
Beispiele FASTOPEN, NWCACHE etc.), die eigentlich eher für
MS-DOS gelten.
- "Novell DOS 7 Unleashed" (Jonathan Kamin)
Sams, 03/1994, 808 Seiten + 3,5" Disk, DM 95,- / f 79,- / $ 40,-
ISBN 0-672-30328-0
Bemerkung: Englischsprachiges Buch über die US-Version von Novell DOS
- "Using Novell DOS 7" (King, Harper, Langley)
Que Corp., 1994, 841 Seiten, f 65,-, $ 30,-
ISBN 1-56529-104-2
Bemerkung: Englischsprachiges Buch über die US-Version von Novell DOS
- "Inside Personal NetWare" (Dorothy Cady)
NRP, 1994, $ 25,-, DM 70,-
ISBN 1-56205-232-2
Bemerkung: Englischsprachiges Buch über die US-Version von Personal
NetWare in Verbindung mit Novell DOS 7, DR DOS, MS-DOS
Windows und OS/2 mit einem eindeutigen Schwerpunkt auf der
recht detaillierten Beschreibung von Personal NetWare.
Beschreibt auch viele Praxislösungen.
- "Novell DOS 7: Memory Management, Multi-Tasking, Networking,
and Data Protection" (Brian Underdahl)
John Wiley & Sons, 12/1993, $ 23,-, 326 pages
ISBN 0-471-01629-2
- "Bright Books: Novell DOS versie 7"
Addison Wesley NL, 1994, f 15,-
ISBN 90.6789-467.2
Bemerkung: In niederländischer Sprache
- "Novell DOS 7 Handboek" (van Bedem)
Addison Wesley NL, 1994, f 60,-
ISBN 90.6789-400.1
Bemerkung: In niederländischer Sprache
- "Werken met Novell DOS 7" (de Jong)
Sybex Nederland, 1993, f 70,-
ISBN 90.5160-633.8
Bemerkung: Dieses niederländische Buch behandelt angeblich auch
Windows NT???
- "Das große DR DOS 6.0 Buch" (H. Tornsdorf, M. Tornsdorf)
Data Becker, 1991, 1003 Seiten, DM 59,-
ISBN 3-89011-510-1
Bemerkung: Der Vorläufer von "Das große Buch zu Novell DOS 7" (siehe
IX.2.) enthielt eine Reihe Hinweise zu DR DOS 6.0, die zwar
auch noch für Novell DOS 7 interessant sind, im Nachfolge-
band aber - wohl aus Platzgründen - nicht berücksichtigt
wurden. Enthält auch einige kleinere Fehler.
Das folgende englische Buch war angekündigt, wurde aber offenbar nie
veröffentlicht:
- "Novell DOS 7: Instant Reference", evtl. auch
"Novell's Guide to Novell DOS 7.0"
Novell Press/Sybex, 08/1995, 30,ドル-
ISBN 0782114075
Bemerkung: Wahrscheinlich sollte es sich hierbei um eine gedruckte
Fassung der oben erwähnten Tutorials zu Novell DOS 7
handeln.
---------------------------------------------------------------------------
IX.9. c't/iX Artikel: [97-02-12]
================================
Autoren : div.
Sonstiges: c't - magazin für computertechnik, Heise Verlag, Hannover
Dieser Überblick soll nur stichwortartig die mir bekannten c't-Artikel
zum Thema 'Novell DOS' (und Vorgängern) behandeln, und erhebt alles
andere als den Anspruch auf Vollständigkeit. Trotzdem möchte ich noch
einmal darauf hinweisen, daß die in diesem Dokument wiedergegebenen
Fakten nicht auf den genannten Artikeln basieren, sondern auf meinen
eigenen Erfahrungen. Natürlich habe ich die Informationen - wo immer
möglich - gegeneinander abgeglichen.
- "Taskdynamik"
DESQview und Concurrent DOS unter Novell (Detlef Borchers)
iX 04/1989, S. 40
Stichworte: DR Concurrent DOS, 'review'
- "Spätlese"
Digital Researchs MS-DOS-Alternative (Marcus Gröber, Bert Ungerer)
c't 03/1990, S. 172
Stichworte: 'review', DR DOS 3.41
- "Neues altes DOS"
DR-DOS 5.0 steht vor der Markteinführung (Bert Ungerer)
c't 07/1990, S. 31
- "Raum für DOS"
Vier virtuelle Speichermanager für 386er (Dr. Reinhard Ellinghaus)
c't 12/1990, S. 130
Stichworte: EMS, 386ToTheMAX, BlueMax, QEMM-386, DR-DOS 5.0, Turbo EMS
- "Belebende Konkurrenz"
DR DOS 6.0 mit neuen Features (Bert Ungerer)
c't 10/1991, S. 25
Stichworte: 'aktuell'
- "DOS to the max"
DR DOS 6.0 mit vielen Utilities (Marcus Gröber)
c't 11/1991, S. 96
Stichworte: 'review'
- "Die Alternativen"
PC-Betriebssysteme neben dem Standard (Detlef Borchers)
c't 06/1992, S. 58
Stichworte: Prologue, Theos, L3, PC-MOS, Multiuser-DOS, DESQview
- "Verstohlene Seitenblicke"
Der Interrupt 21h beim DOS-Bootvorgang (Harald Milz)
c't 07/1992, S. 198
Stichworte: TSR-Programme & Gerätetreiber, CONFIG.SYS, Booten,
DRDOS, PCDOS, MSDOS
- "Just in Time"
Echtzeit-Betriebssysteme, Teil 2: Marktreport (Arno Keppke)
c't 09/1992, S. 202
Stichworte: u.a. FlexOS
- "Leichtnetz mit Anhang"
Netware Lite v1.1 im Paket mit DR DOS (Bert Ungerer)
c't 12/1992, S. 124f.
Stichworte: DR DOS 6.0, Netware Lite, Novell, 'kurz vorgestellt'
- "Die wahre DOS-Version"
DOS-Versionsermittlung im Detail (Matthias Wolf)
c't 02/1993, S. 106
Stichwort: reale DR DOS Versionen
- "Knackpunkt"
PCs contra Datensicherheit: Das Beispiel DR DOS (Mark Torben Rudolph)
c't 03/1993, S. 130ff.
Stichworte: DEL, FORMAT, PASSWORD, LOGIN, UNDELETE, DISKMAP, DELWATCH,
DELPURGE, LOCK, COMPRESS, SuperStor, DR DOS 6.0
- "Ableger im Aufwind"
Frankfurter NetWorld findet Anklang (Bert Ungerer)
c't 07/1993, S.20
Stichworte: Novell DOS 7 Ankündigung, 'aktuell'
- "Netz-DOS"
Novell DOS 7 kurz vor der Fertigstellung (Bert Ungerer)
c't 09/1993, S. 30f.
Stichworte: Beta, Multitasking, 'aktuell'
- "DOS novellieren?"
Novell DOS 7 fordert PC- und MS-DOS heraus (Bert Ungerer)
c't 03/1994, S. 74ff.
Stichworte: PC-DOS 6.1, MS-DOS 6.20, PNW, STACKER, DBLSPACE, SuperStor,
'report'
Bemerkung: Interessanter Vergleich der Funktionalität der drei
zu diesem Zeitpunkt aktuellen DOS Betriebssysteme. Das
Fazit ist ziemlich eindeutig...
- "Ziffernlifting"
IBMs PC-DOS 6.3: Fast alles beim alten (Bert Ungerer)
c't 04/1994, S. 28
Stichworte: Novell DOS 7, PC-DOS 6.3, MS-DOS 6.21 und 6.22, CeBIT,
'aktuell'
- "Natürlich undokumentiert"
Novells Personal Netware unter OS/2 (Dieter Brors)
c't 07/1994, S. 176f.
Stichworte: IBM OS/2 2.11, PNW, Peer-to-Peer, HPFS, DPMS, NWCACHE,
DOS-Box, NET.CFG: Netware DOS Requester OS2=on
Bemerkung: Da ich diesbezüglich noch keine Erfahrungen gesammelt habe,
verweise ich für Novell DOS 7 & PNW unter OS/2 auf diesen
Artikel, der sich allerdings mit dem mittlerweile
veralteten OS/2 2.11 beschäftigt. Weitere Hinweise zu
Novell DOS 7 unter/mit OS/2 gibt es auch in den Dokumenten
von Novells FaxBack-Systems, das zusammengefaßt auch in
dem am Anfang erwähnten Archiv ND7TID.EXE verfügbar ist.
- "Licht und Schatten"
Ein kritischer Blick auf Novell DOS 7 (Arne Schäpers)
c't 08/1994, S. 193ff.
Stichworte: DPMI, DPMS, Übertragungsraten, Windows, Updates, APIs,
Undokumentiertes, DR DOS, Probleme, DBLSPACE
Bemerkung: Die allermeisten der in diesem Artikel beschriebene Pro-
bleme (Update 4) gehören mittlerweile (Update 15) der
Vergangenheit an; Novell war trotz eingestellter Weiter-
entwicklung in den vergangenen 1,5 Jahren nicht untätig...
Trotzdem ist die Lektüre (wie bei den meisten Artikeln
und Büchern von Arne Schäpers) interessant, auch wenn
Novell DOS hier nicht besonders gut abschneidet, was
zwar in manchen Punkten gerechtfertigt ist, in anderen
Punkten jedoch eine klare Frage des Standpunktes ist
(meinen sollten Sie ja inzwischen auch kennen...).
- "Watteweicher Kompromiß"
Microsoft einigt sich mit Kartellbehörden (Ingo T. Storm, Sabine Dutz)
c't 09/1994, S. 16
- "Fertigserver"
Zeniths Z-Stor mit vorkonfigurierter Personal NetWare (Bert Ungerer)
c't 09/1994, S. 72
- "Virtuelle Einrichtung"
Konfigurationstips für Novells DOS-Requester (Bert Ungerer)
c't 09/1994, S. 194
Stichworte: Netze, VLMs, Novell DOS 7, NET.CFG, LAN, Personal NetWare
- "Novell kippt DOS 7"
Netz-Marktführer konzentriert Aktivitäten (Ralf Hüskes)
c't 11/1994, S. 16
Stichworte: Novell DOS 7 & Personal Edition UnixWare eingestellt,
AppWare und WordPerfect, Super NOS, NetWorld+InterOp,
'Markt'
Bemerkung: No comment!
- "Vobis und Escom setzen auf OS/2"
MS Windows gibt es nur noch gegen Aufpreis (Christian Persson)
c't 12/1994, S. 16
Stichworte: OS/2 3.0 Warp, Microsoft Chicago/Windows95, Novell DOS 7
Bemerkung: Hat zwar nicht lange funktioniert (die Mark siegt), hat
aber mal wieder die Grundproblematik mit Microsoft als
Software-Monopolisten deutlich vor Augen geführt. Ohne
'Abweichler' wird die Lage bestimmt nicht besser...
- "Novell DOS lähmt CD-ROM"
c't 06/1995, S. 244
Stichworte: MS-DOS 6.2, CD-ROM, MSCDEX, NWCDEX, SMARTDRV, NWCACHE,
'Hotline'
- "Misch-DOS"
IBM PC-DOS profitiert von Novell DOS (Alexander Hoch)
c't 09/1995, S. 210f.
Stichworte: PC-DOS 7.0, Novell DOS 7, DPMS, STACKER, NWCACHE, NWCDEX
- Nachtrag zu "Misch-DOS"
c't 10/1995, S. 11
Stichworte: NWCACHE, Update 14, 'Ergänzungen + Berichtigungen'
- "Windows95: altes DOS für neues Windows" (Peter Siering)
c't 05/1996, S. 284f.
Stichworte: Beschreibt das geänderte Boot-Verhalten von MS-DOS 7 und
wie man unter Windows95 ein altes MS-DOS/PC-DOS bootfähig
macht und, daß dieses mit Novell DOS 7 nicht funktioniert
(wäre bei Microsoft ja auch nicht anders zu erwarten ge-
wesen). [Mit einigen kleinen Patches müßte es meiner
Meinung nach trotzdem funktionieren, allerdings tut's ja
auch der OS/2- oder PTS/Boot-Manager], 'Hotline'
- "Frontal gegen Microsoft"
DR-DOS-Käufer reicht Antitrust-Klage ein (Christian Persson)
c't 09/1996, S. 16
Stichworte: Übernahme von Novells "DR DOS" durch Caldera Inc.,
Raymond J. Noorda, Bryan Sparks, Antitrust-Klage
- "Laokoons Enkel"
Windows NT 4.0 und die Konkurrenz im Netzwerk (Jürgen Kuri)
c't 09/1996, S. 148ff.
Stichworte: PNW
Bemerkung: Geht am Rande auf Novells Politik der letzten Jahre ein.
Hat nicht direkt etwas mit Novell DOS zu tun.
- "Der Koloß von Provo"
Windows NT versus Novell NetWare (Axel Kossel)
c't 09/1996, S. 160
Bemerkung: Geht auf Novells Stellung im Markt ein. Hat nicht direkt
etwas mit Novell DOS zu tun.
- "Anschluß gesucht"
30 PCI-SCSI-Hostadapter im Vergleich (Georg Schnurer)
c't 09/1996, S. 218ff.
Bemerkung: Beschreibt, daß die EMM386-Speichermanager von "DR-DOS 7.x"
(und PC-DOS 7) im Gegensatz zu MS-DOS bis 6.21 keine Pro-
bleme mit dem PCI-Bus (bei Speicher-Ressouren oberhalb des
ersten MegaByte) hatten (in Wahrheit hatten selbst einige
Versionen von 6.22 noch Probleme mit PCI-Boards, erst der
Treiber aus MS-DOS 7 half hier).
- "Dschungelbuch"
Novell stellt IntranetWare vor (Jürgen Kuri)
c't 11/1996, S. 98ff.
- "Des Kaisers neue Kleider"
Novell sucht Antworten auf die Fragen nach der Zukunft von NetWare
(Detlef Borchers)
c't 03/1997, S. 48ff.
Bemerkung: Beschreibt u.a. die Einführung von IntranetWare FSB (for
Small Business), das als Nachfolger von Personal NetWare 1.0
und NetWare 3.xx angesehen werden kann. Für Personal
NetWare, NetWare, Novell DOS u.a. gibt es relativ günstige
Upgrades. Außerdem gibt der Artikel ein paar Hintergrund-
infos über die Ära Raymond Noorda und Novells neuen Kurs.
---------------------------------------------------------------------------
IX.10. Andere Zeitschriftenartikel: [96-09-04]
==============================================
[Weitere, hier noch nicht verzeichnete Artikel zum Thema sind, z.B. in
Form einer Kopie, sehr willkommen.]
- "Neue DOS-Betriebssysteme"
Markt, Macht und Betriebssysteme - Novell DOS 7.0 contra MS-DOS 6.2
DOS 03/1994, S. 130ff.
Stichworte: Multitasking, Netz, DPMS, Windows
Bemerkung: Interessanterweise stimmt das Fazit haargenau mit dem aus
c't 03/1994 überein...
- "66 Tips für Novell DOS" (Kai Hamann, Michael Kolberg)
Computer Persönlich, 06/1994
Bemerkung: Ein Abdruck dieser Tips wurde auch mit IX.3. publiziert.
- "Novell DOS 7: Is It Time to Switch?" (Steve Kalman)
Unbekanntes Computermagazin??? 03-04/1994, S. 32-35
- "Novell: Kapitulation vor der Windows-Dominanz"
PC-Welt, 11/1994, S. 14
Rubrik : Aktuell; Windows, DOS und OS/2
Stichworte: "The war is over". Novell Mitarbeiter finden DOS nur noch
für PDA (persönliche digitale Assistenten) attraktiv...
- "Novell DOS - Übereifriger Cache"
PC-Welt, 11/1994, S. 31
Stichworte: Beschreibt den Schönheitsfehler in der Statistik von
NWCACHE /S, wenn "VERIFY on" ist. Wurde mit einem Update
behoben.
- "Wegen Windows: Novell DOS stirbt"
PC-Welt, 11/1994, S. 55f.
Rubrik : Aktuell; Vorstellung Software
Stichworte: Ab sofort Schmusekurs mit Microsoft; zu diesem Zeitpunkt
allein in Deutschland 700.000 verkaufte Novell DOS 7
Lizenzen
Bemerkung : (das war noch vor dem großen Preisrutsch...).
- "Peer-to-Peer Netz: Mini-Netz mit alten Rechnern (mit Novell DOS 7)"
PC-Welt, 12/1994, S. 315f.
Bemerkung : Beschreibt grob die Einrichtung eines PNW-Netzes.
---------------------------------------------------------------------------
IX.11. Interessante Web-Sites bezüglich Novell DOS: [97-04-21]
==============================================================
[Weitere Web-Sites bezüglich Novell DOS und Caldera OpenDOS finden
sich in Kapitel I.]
- "Novell DOS - Erste Erfahrungen" (Willibald Klein)
URL: http://www.rz.uni-sb.de/rzinfo19/novell.html
WWW-Artikel aus dem Magazin RZ-Info 19 (1994) der Stelle für
Öffentlichkeitsarbeit der Uni des Saarlandes; entspricht
weitestgehend meinen Erfahrungen. [05/1996]
- "Pflege eines PNW-Servers" (Willibald Klein, Bernhard Stumpf)
URL: http://www.rz.uni-sb.de/rzinfo20/rz20s491.html
WWW-Artikel aus dem Magazin RZ-Info 20 (1994) der Stelle für
Öffentlichkeitsarbeit der Uni des Saarlandes. [10/1996]
- "Multitasking and Networking build into Novell DOS 7" (Scott Fletcher)
URL: http://tcp.ca/May/NovellDOS7.html
WWW-Artikel, entspricht weitestgehend meinen Erfahrungen. [05/1996]
- "Novells Newest DOS" (Terje Mathisen)
URL: http://www.byte.com/art/9406/sec9/art7.htm
WWW-Dokument entspricht dem BYTE-Artikel 06/1994 in der Rubrik "Review"
und beschreibt eine Reihe der positiven und negativen Erfahrungen mit
einer - seltsamerweise trotz des Datums - offenbar sehr frühen US-
Ausgabe von Novell DOS 7 (wohl fast noch Beta-Stadium). [10/1996]
- "Voyager - Novell DOS 7" (Alexander Walz)
URL: http://www-users.informatik.rwth-aachen.de/~afw/nwdos7.html
Zusammenfassender WWW-Artikel über Geschichte und Funktionsumfang von
DR DOS und Novell DOS. [10/1996]
Ist derzeit nicht mehr im Angebot... [02/1997]
- "Digital Research - The untold story: The story behind the story"
URL: http://www.ctyme.com/dri.html
"The 07-21-91 Summary: How the Novell buyout of Digital Research
started"
URL: http://www.ctyme.com/dri1.html
"The NovOS spec: The original written proposal of NovOS to Novell"
URL: http://www.ctyme.com/dri2.html
"Letters to Ray Noorda about NovOS"
URL: http://www.ctyme.com/dri3.html
(Marc Perkel, Computer Tyme)
Verschiedene interessante Dokumente eines hemmungslosen Visionärs
über die Hintergründe zu Novells Aufkauf von Digital Research
(1991) und über das, was aus "Novell DOS" noch alles hätte werden
können...
Marc Perkel nimmt darin für sich in Anspruch, Novell von der Idee
einer ob seiner Features, Flexibilität und Zukunftssicherheit
konkurrenzlosen Alternative zu MS-DOS, MS Windows usw. begeistert
zu haben und die erste Spezifikation dafür geliefert zu haben. Von
Digital Researchs DR DOS als Grundlage für dieses "NovOS" war dabei
zunächst gar nicht die Rede...
Im weiterem Verlauf der Dinge sei er dann von Novell regelrecht
'ausgebootet' worden, was wohl auch der Beweggrund für die Ver-
öffentlichung dieser Seiten war.
Gleichzeitig dürfte dies auch eine der Quellen für die lange Zeit
anhaltenden Gerüchte gewesen sein, daß Novell ein eigenes Super-
Betriebssystem mit GUI etc. entwickeln wollte (aber wohl auch
vom 'Corsair'-Projekt und X/GEM angeheizt). [06/1996]
Vielleicht sind einige der besonders spitzen Bemerkungen mit der
Übernahme von DR DOS durch Caldera überholt, aber urteilen Sie
selbst... [08/1996]
Mittlerweile sind diese provokaten Seiten leider wieder von
Internet verschwunden (vermutlich hat auch Marc Perkel die
jüngsten Entwicklungen positiv eingeschätzt); an den Hintergründen
besonders Interessierte können die Dateien auf Anfrage aber auch
noch von mir beziehen. [10/1996]
- "Concurrent Control, Inc. - Multiuser DOS 7 Gold"
URL: http://www.conctrls.com/gold.htm
URL: http://www.conctrls.com/f-why.htm
Diese Firma - ein ehemaliger Master VAR von DR Multiuser DOS -
vertreibt nach wie vor Multiuser DOS 7 Gold und CCI Concurrent DOS,
die auf DR Concurrent DOS und DR Multiuser DOS basieren. Derzeit
wird eine am 1997年02月10日 freigegebene kostenlose Demo-Version von
Multiuser DOS 7.22 Gold zum Download angeboten. Interessanterweise
gehen dabei einige Novell-Copyrights bis ins Jahr 1996. [03/1997]
- "Logan Industries, Inc."
URL: http://www.lii.com/
Diese Firma vertreibt in den USA das Echtzeit-System IMS REAL/32 (seit
der Version 7.50+ der neue Name für das ehemalige IMS Multiuser DOS)
des englischen Entwicklers IMS, ebenfalls ein Abkömmling der alten
DR Multiuser DOS Linie. Offenbar basiert das System zum Teil auch auf
Quellen früher Novell DOS-Ausgaben, etwa ist der IMSCDEX.EXE Treiber
ein Abkömmling des NWCDEX.EXE v1.00. Interessant ist, daß das als
äußerst stabil angesehene Multitasking-/Multiuser-System in der Lage
ist, neben normalen DOS-, DR DOS- und Multiuser DOS- alias CP/M-86-
Anwendungen auch mehrere Sessions von Windows 3.xx gleichzeitig zu
fahren, bei voller Anbindung an diverse Netze, wie z.B. NetWare und
Abkömmlinge des alten DR Net. [03/1997]
- "Microsoft faces antitrust suit over DR DOS"
URL: http://biz.yahoo.com/bin/jump?/finance/96/07/24/msft_2.html
URL: http://www.online.reuters.com/.../jump
Reuters [08/1996]
- "Microsoft hit with antitrust suit" (Mike Ricciuti, 1996年07月24日)
URL: http://www.cnet.com/Content/News/Files/???/cnet.clp
CNET Inc. [08/1996]
- "Noorda's new company acquires DR-DOS, sues Microsoft"
(Maria Seminerio & Charles Cooper)
URL: http://www.pcweek.com/news/0722/24esuit.html
URL: http://www.zdnet.com/plweb-cgi/pcweek/.../24esuit.html
PC WEEK, Ziff Davis Publishing [08/1996]
- Web-Server der Caldera Inc., Provo, Utah [08/1996-05/1997]
URL: http://www.caldera.com/
URL: http://www.caldera.com/dos/
URL: http://www.caldera.co.uk/
URL: http://caldera.co.uk/
Der Web-Server der Caldera Inc. ist insofern sehr interessant für
Novell DOS 7 Benutzer, als daß Caldera in 07/1996 alle Rechte an
der ehemaligen Digital Research Betriebssystempalette von Novell
übernommen hat, u.a. zu dem Zweck, das Betriebssystem DR DOS (alias
Novell DOS) inklusive Personal NetWare, jedoch um Internet-Fähig-
keiten, TCP/IP und eventuell sogar ein GUI bereichert unter dem Namen
Caldera OpenDOS wieder auf den Markt zu bringen. Die englische Fassung
von Caldera OpenDOS 7.01 ist am 1997年02月03日 freigegeben worden und
kann - für Ausbildungsstätten, Studenten und Schüler kostenlos - auf
Calderas Web-Server bezogen werden kann. Allerdings entspricht diese
Fassung zu noch fast 100% dem Novell DOS 7, siehe Kapitel I.5.
Der Name ist auch gleich Programm, denn Caldera begann am 1997年04月21日
mit der Pre-Release der Quellen des Caldera OpenDOS 7.01 Kernels
damit, nach und nach die Quelltexte von OpenDOS und natürlich
auch der Betriebssysteme CP/M, DOSPlus, DR DOS, DR PalmDOS,
DR Concurrent DOS, DR Multiuser DOS und Novell DOS (von GEM war
in diesem Zusammenhang bislang nicht die Rede) im Internet öffentlich
zugänglich machen (abgesehen von den Quelltexten der Zukäufe), um so
einer breiten Masse ein fundiertes, sicheres Betriebssystem-KnowHow
zu vermitteln und dadurch der weiteren Entwicklung von DOS-Programmen
eine solide Basis zu verschaffen (keine undokumentierten Details mehr;
nach dem alten Unix-Motto "Use the Source, Luke!" ist die bestmögliche
Dokumentation der Quelltext).
Natürlich bleiben die Quelltexte auch weiterhin unter dem Copyright von
Caldera (ein wesentlicher Unterschied zu FreeDOS oder Linux, die unter
der GPL, der "GNU General Public License" stehen), können aber für
eigene kommerzielle Produkte lizensiert werden. Caldera will auch
mit dem FreeDOS-Team zusammenarbeiten.
Daß dieses fortschrittliche Konzept funktionieren kann, zeigt die
Entwicklung des FreeWare-Unix Linux, für das Caldera ihren CND (jetzt
COL) anbieten, nur zu gut. Bleibt zu hoffen, daß das Beispiel Schule
macht und eine generelle Trendwende in der Betriebssystementwicklung
einleitet.
Der DOS-Markt ist zwar kein zukunftsorientierter Massenmarkt mehr
(zumindest nicht bezüglich der 'Innovationsfreude' bei den bisherigen
DOS-Versionen), eine kleine Firma wie Caldera könnte aber auch in
Zukunft ganz gut davon leben, wenn erst einmal alle anderen DOS-
Hersteller ihre Entwicklung endgültig eingestellt haben (Microsoft
dürfte kein Interesse mehr an einer Weiterentwicklung von MS-DOS
haben; und wenn, dann ist es *jetzt* zu spät; sie werden wohl kaum
die Quellen von MS-DOS & MS Windows zur freien Verfügung stellen).
Anbetracht der Langlebigkeit längst totgesagter Betriebssysteme
(man vergegenwärtige sich beispielsweise einmal das starke Echo in
CP/M-Newsgroups!!!) und der bei Weitem nicht 'so' weit (wie oft
pauschal angenommenen) fortgeschrittenen globalen Durchdringung der
Gesellschaft mit Computern neuster Bauart (siehe Ost-Europa, Mittel-
Asien und Afrika) könnte sich bei weltweitem Vertrieb aus dem
horizontalen DOS-Markt ein lukrativer vertikaler Nischenmarkt auftun,
in dem durchaus noch langfristig Innovation möglich ist. Die Nähe zu
Unix (Linux) ist dabei nur eine mögliche Entwicklungsrichtung.
In jedem Fall hat eine Fortentwicklung von DOS und die *sinnvolle*
Einbettung in moderne Betriebssystemkonzepte den unschlagbaren Vorteil,
daß das geistige Potential und der Erfahrungsschatz von vielen tausend
DOS-Profis und die Investitionen von Millionen DOS-Benutzern nicht
plötzlich wertlos werden (sog. Migration Path); ein Ansatz, den
zumindest ich mir schon seit Jahren sehnlichst gewünscht habe...
Der Server enthält ausführliche Infos bezüglich Calderas wiederauf-
gerollter Antitrust-Klage gegen Microsoft als Monopolisten, sowie
diesbezügliche Pressemitteilungen und bestätigt viele der Fakten,
die ich auch aus vielen anderen Quellen erfahren habe und die sich -
was Betriebssystem-Interna angeht - auch mit meinen persönlichen
Erfahrungen decken.
###########################################################################
###########################################################################
Converted to HTML by TXT2HTML (©Thomas Antoni), 29.06.2011, 17:35:56