###########################################################################
########################################################################### [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: <[email protected]>
(<[email protected]>)
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.:
<[email protected]>
- 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
<[email protected]>
und andere Hintergrund-Infos,
die von DJ Delorie
<[email protected]>,
dem Entwickler von DJGPP,
zusammengestellt wurden.
URL: http://www.deltasoft.com/ Inoffizielle OpenDOS-Homepage
von Marek 'Mark' Habersack
<[email protected]>.
URL: http://null.musc.edu/opendos/ "OpenDOS known bug list"
von Paul W. Brannan
<[email protected]>.
URL: http://www.pipo.com/plug/COD.html Kommentare des franz�sischen
Clubs PLUG zu OpenDOS von
Fr�d�ric Renet <[email protected]>
und Vincent Renardias
<[email protected]>.
URL: http://www.naf.cz/arachne/english.htm ARACHNE, der zuk�nftige
Web-Browser 'WebSpyder' f�r
OpenDOS der xChaos SoftWare
von Michael Polak
<[email protected]>.
Anlaufstellen u.a. f�r Caldera OpenDOS, Novell DOS und DR DOS sind:
<[email protected]> Allgemeine Infos und Kontaktaufnahme
<[email protected]> Support speziell f�r OpenDOS
<[email protected]> u.a. f�r Hinweise bzgl. OpenDOS FAQ
<[email protected]> Bug-Reporte
<[email protected]> 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 <[email protected]>.
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: [email protected]
Subject:
Text: SUBSCRIBE NOVELL-DE
Das Abmelden funktioniert wie folgt:
Mail-Adresse: [email protected]
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: [email protected]
Subject: ND7: Thema... (Beispiel)
Text: ...
Ein aus dieser Liste zusammengestelltes FAQ (Frequently Asked Questions)
betreut Thomas Demmer <[email protected]> (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 (<[email protected]>,
<[email protected]>, 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 <[email protected]> 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 <[email protected]>, 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: [email protected]
Subject:
Text: SUBSCRIBE
Das Abmelden funktioniert wie folgt:
Mail-Adresse: [email protected]
Subject:
Body: UNSUBSCRIBE
Die eigentliche Diskussion l�uft in englischer Sprache auch hier �ber
eine andere Adresse ab, n�mlich:
Mail-Adresse: [email protected]
Subject: Thema...
Body: ...
Weiterhin gibt es noch drei 'inoffizielle' Mailing-Listen zum Thema,
gewartet von DJ Delorie <[email protected]> (fr�her von Gene Buckle
<[email protected]>). Die Anmeldung erfolgt wie folgt:
Mail-Adresse: [email protected]
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
<[email protected]>, <[email protected]>, bzw.
<[email protected]> 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 <[email protected]> (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 [[email protected]]
REM -----------------------------------------------------------------
FOR %%x IN (swc.btm SWC.BTM) DO IF "%%x"=="%0" GOTO rename
GOTO start
:rename
ECHO Warning: "SWC.BAT" must not be renamed to "%0"! Exiting...
GOTO end
:start
IF ""=="%tmp%" SET tmp=%Temp%> \dev\nul
IF NOT ""=="%tmp%" IF NOT EXIST %tmp%\nul MD %tmp% > \dev\nul
BREAK on > \dev\nul
IF EXIST %tmp%\swc.btm ECHO Warning: "%tmp%\swc.btm" is locked ...
... by another task. Waiting for release...
:wait
IF EXIST %tmp%\swc.btm GOTO wait
BREAK off > \dev\nul
IF NOT "4"=="%@Eval[2 + 2]%" GOTO no4dos
ECHOS `SET `> %tmp%\swc.btm
SETDOS | @ CALL FIND "SWITCH=" >> %tmp%\swc.btm
@ CALL %tmp%\swc.btm > \dev\nul
DEL %tmp%\swc.btm > \dev\nul
FOR %%x IN (on ON On off OFF Off) DO IF "%%x"=="%batdbg%" ...
... BREAK %batdbg% > \dev\nul
GOTO end
:no4dos
REM Check for undocumented feature of Caldera OpenDOS 7.01,
REM Novell DOS 7, DR DOS 6.0 COMMAND.COM: If current SwitChar
REM is not '/', the 1st '\' from CD/CHDIR and PROMPT $p path
REM output is replaced by '/'. Since DR DOS 6.0 COMMAND.COM prior
REM to updates 1992 did copy files with zero length, this should
REM not be enabled for original DR DOS 6.0 COMMAND.COM of 1991.
REM IF "DRDOS"=="%Os%" IF "6.0"=="%Ver%" GOTO drdos6
IF NOT "NWDOS"=="%Os%" IF NOT "OPENDOS"=="%Os%" GOTO end
:drdos6
CD | CALL FIND "/" > %tmp%\swc.btm
IF NOT EXIST %tmp%\swc.btm GOTO end
BREAK on > \dev\nul
IF EXIST %tmp%\swc.$$$ ECHO Warning: "%tmp%\swc.$$$" is locked ...
... by another task. Waiting for release...
:wait2
IF EXIST %tmp%\swc.$$$ GOTO wait2
BREAK off > \dev\nul
IF EXIST %tmp%\swc.btm COPY %tmp%\swc.btm %tmp%\swc.$$$ > \dev\nul
IF EXIST %tmp%\swc.btm DEL %tmp%\swc.btm > \dev\nul
IF EXIST %tmp%\swc.$$$ IF ""=="%switchar%" SET switch=-> \dev\nul
IF NOT EXIST %tmp%\swc.$$$ SET switch=> \dev\nul
IF EXIST %tmp%\swc.$$$ DEL %tmp%\swc.$$$ > \dev\nul
:end
IF ""=="%switch%" SET switch=%switchar%> \dev\nul
IF ""=="%switch%" SET switch=/> \dev\nul
REM To avoid a parsing bug in an older MS-DOS COMMAND.COM release
REM
Sobald ein anderes Zeichen als '/' eingestellt ist (�blicherweise ein
'-', m�glich ist aber jedes beliebige Zeichen), signalisiert der PROMPT
von Novell DOS 7 und DR DOS 5.0 & 6.0 COMMAND.COM (nicht aber DR DOS
3.41) dies durch einen ver�nderten Schr�gstrich in seinem $p Token,
statt dem �blichen
c:\nwdos>
f�r ein PROMPT $p$g nun also
c:/nwdos>
(d.h. das erste Zeichen nach der Laufwerksangabe ist '/'). Die gleiche
Ver�nderung zeigt sich auch bei Ausgaben des Befehls CD/CHDIR (z.B. wenn
man CD ohne Parameter aufruft) und kann hier sogar sinnvoll f�r eine
automatische Erkennung in Batchjobs (wie oben) verwendet werden, da sich
die Ausgabe von CD umleiten und mit FIND auswerten l��t.
Einen verdrehten Schr�gstrich kann der Benutzer also als visuelle
Erinnerung interpretieren, da� Novell DOS COMMAND.COM nun neben '\' in
Pfadangaben auch '/' zul��t. M�glich wird dies dadurch, da� '/' nun
eben nicht mehr als Parametereinleitungszeichen verwendet wird. (Auf
API-Ebene ist diese Unterscheidung nicht notwendig. Pfade k�nnen von
jeher sowohl mit '/' als auch mit '\' angegeben werden).
Gleichzeitig m�ssen aber alle Parameter mit dem nun eingestellten
Parametereinleitungszeichen beginnen. Falls also SwitChar auf '-'
eingestellt ist, m�ssen alle Parameter mit '-', statt mit '/' anfangen.
Soweit bisher getestet, unterst�tzen nahezu alle externen Novell DOS 7
Programme (zumindest die wichtigen und h�ufig verwendeten, bis auf
EXE2BIN und MEMMAX, und ab Update 15 auch alle COMMAND.COM-internen
Kommandos) diese Umschaltung und �ndern bis auf wenige Ausnahmen
(eben z.B. die internen Befehle) sogar die entsprechende Ausgaben
der Hilfeschirme (die bei SwitChar=- nat�rlich mit -? aufgerufen
werden. ;-)
Problematisch ist es nur, wenn der SwitChar zwar unterst�tzt wird,
aber ein bestimmter Parameter dadurch mehrdeutig wird (etwa XDIR,
XCOPY mit dem -H Parameter, der versteckte Dateien ausschlie�en soll,
in Verbindung mit SwitChar=- aber mit -H f�r Hilfe kollidiert).
In solchen F�llen m�ssen Sie entweder genau darauf achten, wo der
Parameter steht (ein Hilfeparameter sollte an erster Position stehen,
andere Parameter hinten), oder man mu� auf SwitChar=/ zur�ckschalten.
Siehe die Befehls�bersicht weiter unten. (Bei DR DOS honorieren die
meisten externen Utilities ebenfalls SwitChar, jedoch COMMAND.COM
offenbar nicht.)
Anscheinend wurde die M�glichkeit des variablen SwitChar ausgerechnet
bei COMMAND.COM selbst 'vergessen'. In der Aufruf-Syntax von COMMAND.COM
wurde der SwitChar-Support integriert, aber die Hilfeschirme aller
internen Befehle von COMMAND.COM m�ssen weiterhin mit /? aufgerufen
werden, auch wenn der SwitChar verstellt ist (getestet mit Update 15).
Andererseits w�rde es auch neue (l�sbare) Probleme aufwerfen, wenn auch
die Hilfeschirme SwitChar-abh�ngig w�ren.
Diese undokumentierte M�glichkeit kann f�r manche Belange (insbesondere
f�r an die Unix-Konventionen Gew�hnte) praktisch sein, da aber nicht alle
Fremdprogramme diese M�glichkeit unterst�tzen, ist der Nutzen begrenzt.
Aufruf an alle Programmierer:
Bitte unterst�tzen Sie in Ihren Programmen die SwitChar-Funktion, indem
Sie den entsprechenden Interrupt nach der aktuellen Einstellung abfragen,
oder wenigstens die g�ngigsten Alternativen ('/' und '-') unterst�tzen.
ii. �bersicht �ber unterschiedliche SwitChar-Unterst�tzung:
-----------------------------------------------------------
Da die einzelnen Novell DOS Kommandos leider h�chst unterschiedlich
auf einen ver�nderten SwitChar reagieren, hier eine �bersicht...
Symptome:
- (1) Akzeptiert 'festverdrahtet' nur '/' als Parametereinleitung
+ (2) Akzeptiert immer '-' und '/' als Parametereinleitung
+ (3) Pa�t sich exakt an den aktuellen SwitChar an
++ (4) Pa�t sich an einen SwitChar an, akzeptiert aber immer auch
noch '-' und '/' (Abweichungen m�glich, z.B. beliebige Zeichen,
oder auch gar kein SwitChar)
- (5) Hilfeschirm nur mit /? (andernfalls siehe oben)
- (6) Hilfeschirm zeigt immer '/' an (Sch�nheitsfehler, unkritisch)
+ (7) Hilfeschirm pa�t sich teilweise an aktuellen SwitChar an
++ (8) Hilfeschirm pa�t sich komplett an den aktuellen SwitChar an
+ (9) Konfliktfreie Doppeldeutigkeiten bei gleichnamigen SwitChars
wie '-' und '+'
- (10) Unl�sbare Doppeldeutigkeiten bei gleichnamigen SwitChars wie
'-' und '+'
Tabelle f�r Aufruf-Syntax (Novell DOS 7 Kommandos, unvollst�ndig):
Kommandos: Compiler: SwitChar-Verhalten:
vor Update 15 Update 15
COMMAND.COM Aufruf (ASM???) +3 -6
COMMAND.COM interne Kommandos -1 -5 -6 +3 -5 -6
4DOS.COM zum Vergleich (Helpverhalten unterschiedl.) +3 -6 -10
APPEND.EXE (ASM) -1 -5 -6 -10
ASSIGN.COM (BC++91) +3 ++8
ATTRIB.EXE (BC++91) +3 ++8 -10
BACKUP.COM (BC++91) +3 -6
CHKDSK.EXE (BC++91) +3 -6
CHOICE.COM (BC++91) +3 -6
COMP.COM (BC++91) +3 +7
CREATE.COM -1 -5 -6
CURSOR.EXE (BC++91) -1 -5 -6
DCONVERT.COM, DCONVRT2.EXE +2 ++4 (alles) ??
DEBUG.EXE (ASM) +2 ++4 (alles) ??
DELPURGE.EXE +2 ++4 (alles) +9
DELWATCH.EXE -1 -5 -6
DISKCOMP.COM +3 -6
DISKCOPY.COM +3 -6
DISKMAP.EXE +2 -6
DISKOPT.EXE +3 -6
DOSBOOK.EXE +3 ++8
DOSKEY.EXE +3 ++8
DPMI.EXE -1 ++8
DPMS.EXE +2 -6
EDIT.COM +2 +7
EMM386.EXE +2 ++4 (alles)
EXE2BIN.EXE -1 -5 -6
FBX.EXE +2 ++4 -6
FC.COM +3 ++8
FDISK.COM +3 -6
FILELINK.EXE +3 ++8
FIND.EXE (BC++91) +3 ++8
FORMAT.COM (BC++91) +3 +7
GRAFTABL.COM -1 -5 -6
GRAPHICS.COM -1 -5 -6
JOIN.EXE +2 ++4 (alles) -6
KEYB.COM -1 -5 -6
LABEL.COM +3 ++8
LOCK.EXE +2 ++4 (alles) -6
MEM.EXE +3 ++8
MEMMAX.COM -1 -5 -6
MODE.COM -1 -5 -6
MORE.COM -1 -5 -6
MOVE.EXE +3 ++8
NETWARS.EXE -1 -5 -6
NLSFUNC.EXE -1 -5 -6
NWCACHE.EXE -1 -5 -6
NWCDEX.EXE +3 -6
PASSWORD.EXE +3 ++8
PNUNPACK.EXE +3 -6
PRINT.COM +3 ++8
RECOVER.COM +3
RENDIR.EXE +3 -6
REPLACE.EXE +3 ++8 ??
RESTORE.COM +3 ++8
SCRIPT.EXE -1 -5 -6
SDRES.EXE +2 -6
SDSCAN.EXE +2 -6
SERNO.EXE +3 -6
SETUP.EXE -1 -5 -6
SETVER.EXE +3 ++8
SHARE.EXE -1 -5 -6
SORT.EXE +3 ++8
SUBST.EXE +3 +7
SYS.COM +3 -6
TASKMGR.EXE +2 -6
TOUCH.EXE +3 ++8
TREE.COM +3 ++8
UNDELETE.EXE +2 ++4 (alles) ++8
UNFORMAT.EXE +2
XCOPY.EXE (BC++91) +3 ++8 -10??
XDEL.EXE (BC++91) +3 ++8
XDIR.EXE (BC++91) +3 ++8 -10
---------------------------------------------------------------------------
II.2. Konfigurationsdateien CONFIG.SYS und AUTOEXEC.BAT umgehen:
===================================================[96-01-03]===
Stichworte: Booten, <F5>, <F8>, CONFIG.SYS, SWITCHES=/N, DBLSPACE,
DRVSPACE
Wie MS-DOS 6.xx bietet nun auch Novell DOS 7 eine M�glichkeit, die
Konfigurationsdateien CONFIG.SYS und AUTOEXEC.BAT zu umgehen, um z.B.
ein absolut minimales Wartungssystem hochzuziehen, wenn ein neuer
Treiber das �bliche Booten verhindert.
Wenn Sie w�hrend oder vor der zwei Sekunden andauernden Meldung
'Starten von DOS...' die Taste <F5> (oder das gleichwertige <Ctrl>+<F5>)
dr�cken, werden die CONFIG.SYS und AUTOEXEC.BAT Dateien komplett
�bergangen. Dabei unterbleibt beim Disketten-Boot jeglicher Zugriff
auf die Festplatte, d.h. evtl. Boot-Probleme mit noch nicht initiali-
sierten IDE-Festplatten sollten damit umgangen werden k�nnen (ohne
<F5> h�ngt u.U. der Rechner beim ersten Zugriff auf eine ung�ltige
Partitionstabelle - bei jeder DOS Version) (eine L�sung dieses Boot-
Problems ist z.B. die Option FDISK "Master-Ladesatz schreiben",
siehe Kapitel II.4.).
Wenn Sie stattdessen einen Einzelschrittbetrieb fahren m�chten und
wie mit '?' vor jedem Befehl gefragt werden wollen, ob Sie ihn auch
wirklich ausf�hren m�chten, dr�cken Sie stattdessen die Taste <F8>
(bzw. <Ctrl>+<F8>).
Diese M�glichkeit l��t sich auch prima zum Debuggen komplexer CONFIG.SYS
Dateien benutzen. M�chte man den Ablauf nur genau verfolgen, ohne ins
Geschehen einzugreifen, ist das st�ndige Dr�cken auf die Ja-Taste sehr
l�stig. Mit den undokumentierten M�glichkeiten von TIMEOUT= und YESCHAR=
kann man jedoch einen automatischen Scroll-Effekt erzielen:
TIMEOUT=1,J
YESCHAR=J (mehr dazu in Kapitel III.1.)
Zur�ck zum Thema:
Bei MS-DOS k�nnen Sie im Einzelschrittbetrieb (<F8>) jederzeit mit <F5>
alle restlichen Eintr�ge von CONFIG.SYS und AUTOEXEC.BAT umgehen. Dies
ist mit Novell DOS nicht m�glich. Au�erdem k�nnen Sie bei MS-DOS die
beiden Tasten auch noch w�hrend der Anzeige eines Boot-Men�s dr�cken.
Diese M�glichkeit gibt es bei Novell DOS ebenfalls nicht.
Ob die erweiterten M�glichkeiten <Ctrl>+<F5> und <Ctrl>+<F8>, die bei
MS-DOS auch DBLSPACE bzw. DRVSPACE umgehen, bei Novell DOS auch arbeiten,
wurde nicht �berpr�ft (auch nicht, ob STACKER sie unterst�tzt), es ist
jedoch wahrscheinlich der Fall (siehe auch Kapitel II.6.). Innerhalb
IBMBIO.COM werden sie jedenfalls genauso wie <F5> und <F8> behandelt
(und deshalb hier auch nicht weiter erw�hnt).
Neben <F5> kann die Abarbeitung bei Novell DOS auch durch Dr�cken der
<Shift>-Taste umgangen werden (was einen Vorteil hat: Die <Shift>-Taste
l��t den Tastaturpuffer auch bei dauerhaftem Druck nicht �berlaufen.
Dadurch unterbleibt das l�stige Piepsen).
Der undokumentierte CONFIG.SYS Schalter SWITCHES=/N von MS-DOS wird
auch bei Novell DOS (zumindest ab Update 13) ausgewertet. Damit kann
die Behandlung von <F5> und <F8> unterbunden werden. Bei Novell DOS
ist aber generell auch die Position der CONFIG.SYS Direktiven in dieser
Datei ausschlaggebend. Je nachdem, wo Sie also SWITCHES= platzieren,
k�nnen unterschiedliche Dinge passieren. Wenn Sie das Verhalten von
MS-DOS nachbilden wollen, m�ssen Sie diese Anweisung in die erste
Zeile der CONFIG.SYS Datei schreiben. N�heres zu diesem Ph�nomen siehe
Kapitel III.1. Mit Update 15 hat es einige Fixes bez�glich des <F5>/<F8>-
Handling gegeben; ob darunter auch dieses Ph�nomen f�llt, ist noch
nicht �berpr�ft.
Ab Update 15 wird eine aktivierte <F8>-Behandlung - wie bei MS-DOS -
�ber die neu eingef�hrte Option COMMAND.COM /Y an den Kommandoprozessor
weitergegeben (siehe Kapitel II.11.), vorher wurde offenbar ein anderes
Verfahren verwendet.
Das erweiterte Verhalten, das mit MS-DOS 7 eingef�hrt wurde, kann das
1,5 Jahre fr�her eingef�hrte Novell DOS 7 nat�rlich noch nicht kennen.
---------------------------------------------------------------------------
II.3. CD-ROMs und Cache: [97-04-02]
===================================
Stichworte: CD-ROM, NWCDEX, MSCDEX, NWCACHE, SMARTDRV, DPMS, Speicher
Dieser Abschnitt geht auf einige Besonderheiten des Cache- und CD-ROM-
Supports unter Novell DOS 7 ein und stellt Alternativen und Workarounds
vor, wie Sie bestimmte Probleme vermeiden k�nnen.
Statt dem Programm MSCDEX liefert Novell ein Programm namens NWCDEX mit
(unbedingt die aktuelle Version 2.81+ aus Update 15 verwenden).
Dieses Programm bietet die gleichen Funktionen wie MSCDEX, allerdings
braucht es selbst bei maximaler Gr��e der Puffer nur 7 KByte im ersten
MegaByte. Dieser Teil kann auch komplett hochgeladen werden, sofern
w�hrend der Initialisierung des Treibers mehr als 85 KByte freier
Speicher in den UMBs verf�gbar sind. Mit anderen Worten: NWCDEX mu�
sich erst mal komplett dort einnisten k�nnen! Danach kann sich NWCDEX
unter Benutzung von DPMS bis auf 7 KByte ausgelagern (der DPMS-Treiber
selbst ben�tigt ca. 1 KByte im konventionellen Speicher). DPMS arbeitet
auch mit MS-DOS/PC-DOS, so da� der Wechsel von MSCDEX (braucht 16 KByte
nach Auslagerung) zu NWCDEX auch f�r MS-DOS Benutzer sinnvoll sein kann.
Zu PC-DOS 7 wird ebenfalls ein DPMS-Treiber ausgeliefert und auch der mit
manchen TSRs, Netz-Clients und BIOSen ausgelieferte Protected Mode
TSR-Server CLOAKING.EXE von Helix Software unterst�tzt undokumentiert
das API von DPMS, ja sogar PTS/DOS (alias S/DOS) scheint DPMS benutzen
zu k�nnen, so da� sich dieser Standard langsam etabliert (siehe auch
Kapitel II.4. bei DPMS).
(Weitere interessante Hinweise speziell zur Installation und Optimierung
von NWCDEX finden sich in Kapitel II.4. bei NWCDEX.)
Statt SMARTDRV bietet Novell DOS den Cache NWCACHE, der bei subjektiv
besserer Performance und Stabilit�t mehr Funktionalit�t bietet. Unter
anderem kann er bei Bedarf auch DOS-Programmen Speicher ausleihen
(SMARTDRV kann dies nur bei MS Windows), bietet verz�gertes Schreiben,
verwendet adaptive Cache-Strategien und er unterst�tzt wie NWCDEX
ebenfalls DPMS.
Ein direkter Vergleich (ja, SMARTDRV funktioniert als eines der wenigen
MS-DOS Programme auch unter Novell DOS, wohl, weil es auch bei MS Windows
beiliegt) brachte folgendes zutage:
SMARTDRV NWCACHE
bis 640 KByte 16 KByte 0 KByte (1 KByte f�r DPMS)
UMBs 12 KByte 16 KByte + 5 KByte
(16 KByte ist der Maximalwert des 'voraus-
schauenden' Puffers, der bis auf 4 KByte
reduziert werden kann)
via DPMS --- restlicher Code ausgelagert.
(Ohne DPMS ben�tigt NWCACHE mindestens 10 KByte
konventionellen Speicher, also immer noch
weniger als SMARTDRV. Bei Verwendung von XMS
statt EMS steigt ohne DPMS auch der ben�tigte
Basisspeicher mit der Gr��e des Caches um
einige KiloByte an.)
Das bedeutet, da� NWCACHE bei sinnvoller Konfiguration locker 7 KByte
kostbaren Speicher weniger ben�tigt und obendrein �berhaupt keinen
konventionellen Speicher verwendet. (Es ist u.U. m�glich, da� sich
SMARTDRV in anderen Konfigurationen ebenfalls hochladen kann.)
Ein Nachteil sei allerdings nicht verschwiegen:
NWCACHE kann - entgegen anderslautenden Meldungen - derzeit keine
CD-ROMs cachen (SMARTDRV kann das auch erst in der neusten Versionen zu
MS-DOS 6.20+ (vgl. SMARTDRV /U)). Das liegt daran, da� CD-ROM-Laufwerke
nicht �ber einen herk�mmlichen Blocktreiber, sondern auf v�llig andere
Art und Weise - wie heutzutage auch Netzwerke - �ber den Umadressierer
(Redirektor) eingebunden werden, und entfernte Netzlaufwerke puffert
NWCACHE aus Sicherheitsgr�nden ebenfalls nicht. Lokale Laufwerke werden
nat�rlich gepuffert, was auch der Performance eines PNW-Servers zugute
kommt. Andere Caches, die verz�gert schreiben, k�nnen auf PNW-Rechnern
(und in anderen Netzen) zu Datenverlusten f�hren.
Wenn Sie auf gecachete CD-ROMs *nicht* verzichten k�nnen, sollten Sie
entweder einen zus�tzlichen CD-ROM-Cache eines Drittanbieters benutzen
(wie z.B. CD-Quick CDQ.EXE) oder auf die Kombination DPMS+NWCDEX+SMARTDRV
ausweichen. Eventuell reicht es aber auch aus, die Zwischenpuffer der
beiden CD-ROM-Treiber zu erh�hen und weiterhin NWCACHE zu verwenden.
In diesem Fall k�nnen Sie die Einstellung /M:value (z.B. NWCDEX /M:32)
und/oder zus�tzlich die Zwischenpuffereinstellung des Hardware-Treibers
erh�hen (h�ufig ebenfalls Option /M:value, z.B. f�r 64 XMS-Puffer bei
Mitsumi FX-001 etc.: DEVICEHIGH=MTMCDAE.SYS /M:64 /X).
Je nach Einstellung der anderen Optionen ist es m�glich, diese Puffer,
die teilweise sehr viel Platz ben�tigen, ebenfalls ins XMS auszulagern.
Ob diese Alternative f�r Ihre Konfiguration annehmbare Performance bei
besserer Speicherbilanz als die Kombination DPMS+NWCDEX+SMARTDRV bietet,
m�ssen Sie selbst herausfinden. Die Kombination MSCDEX+SMARTDRV ist
dagegen nicht besonders zu empfehlen, da die Pufferung von CD-ROMs, wie
sie SMARTDRV vornimmt, in dieser Form nicht sehr effektiv ist und zu-
s�tzlichen Speicher kostet, der besser in einen speziellen CD-ROM-Cache
eines Drittanbieters (s.o.) investiert wird. Oft begn�gt sich ein solcher
Cache schon mit dem Speicher, der bei MSCDEX durch Reduzierung der Puffer
eingespart werden kann, so da� die Speicherbilanz ausgeglichen bleibt.
Da NWCDEX aber DPMS nutzen kann und damit die Puffer ausgelagert werden
k�nnen, tritt dieses g�nstige Paradoxon hier leider nicht auf.
Sie sollten �brigens bei Benutzung von CD-ROMs (mit DMA-Nutzung) unter
MS Windows 3.xx die Direktive DMABUFFERSIZE=128 in SYSTEM.INI [386Enh]
eintragen (bzw. erh�hen), um die Systemstabilit�t zu erh�hen.
Weitere Hinweise zu NWCDEX und NWCACHE gibt es in Kapitel II.4.
---------------------------------------------------------------------------
II.4. Undokumentierte Eigenschaften externer Kommandos: [97-03-24]
==================================================================
Stichworte: Alle externen Kommandos und Treiber
Im folgenden �berblick sind fast *nur* nicht offensichtliche Eigen-
schaften und undokumentierte M�glichkeiten einiger externer Novell DOS
Kommandos und Treiber aufgef�hrt. Bez�glich der generellen Funktion
und aller offiziellen Parameter (auch der bei Novell DOS neu eingef�hrten
Parameter) sei auf das DOSBOOK und die /? Hilfe verwiesen.
Ein Teil dieser Hinweise fu�t lediglich auf Vermutungen (wird erw�hnt),
die noch best�tigt werden m�ssen. Wer also diesbez�gliche Erfahrungen
sammelt, sollte mir seine Erkenntnisse bitte �bermitteln.
ASSIGN.COM F�r die Angabe der Statusinformationen sind folgende
Parameter erlaubt: /S, /STA, /STATUS, andere Formen
sind ung�ltig.
Au�erdem wird - undokumentiert - auch noch die DR DOS
Option /A unterst�tzt, die genauso wie die neue dokumen-
tierte Option /S eine �bersicht �ber die aktuellen Zu-
ordnungen ausgibt.
Die von CCI Multiuser DOS 7.22 Gold unterst�tzte Option
/B f�r eine Ausgabe mit vorangestelltem ASSIGN zur
Wiederverwendung in Batchjobs in Verbindung mit Umleitung
gibt es bei Novell DOS und Caldera OpenDOS 7.01 leider
nicht, dies kann aber leicht nachtr�glich implementiert
werden.
ASSIGN sollte nicht auf Netzlaufwerke angewendet werden.
Obwohl DOS zun�chst ordnungsgem�� zu arbeiten scheint,
soll es zu Fehlverhalten kommen k�nnen (nicht �berpr�ft).
ASSIGN sollte man nicht ohne weiteres auf die Festplatte
C: (bzw. das Laufwerk, von dem der Kommandoprozessor
geladen wird) anwenden. Nach ASSIGN ist sonst die alte
%ComSpec% Einstellung u.U. ung�ltig, der transiente Teil
des Kommandoprozessors kann nicht mehr nachgeladen werden
und DOS kann nicht mehr weiterarbeiten (vgl. Kapitel
IV.7.). Arbeitet man mit Novells COMMAND.COM, bekommt
man jedoch u.U. die M�glichkeit, einen neuen Pfad zum
Kommandoprozessor anzugeben, sobald Novell DOS feststellt,
da� die alte %ComSpec% Einstellung ung�ltig ist.
Im Gegensatz zu DR DOS' ASSIGN werden bei Novells ASSIGN
aus Kompatibilit�tsgr�nden gegen�ber MS-DOS die alten
Einstellungen gel�scht, sobald neue angegeben wurden.
Es gibt aber die M�glichkeit, mehrere Verkn�pfungen mit
einem Aufruf anzugeben. N�heres hierzu im FaxBack-Infopaper
15196.TXT aus ND7TID.EXE.
In Update 12 (ASSIGN 1.05) gab es einen Fix, der
daf�r sorgte, da� nur noch Verkn�pfungen unterhalb
von LASTDRIVE= angezeigt werden.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok oder Hilfeschirm
3 Benutzerabbruch (<Ctrl>+<c> etc.)
4 Syntax-Fehler
ATTRIB.EXE Unterst�tzt �ber die undokumentierte Syntax /U:name
die Angabe eines zul�ssigen Benutzeranmelde- oder
Gruppennamens (maximal 12 Zeichen lang). Diese Option
ist nicht in jeder Betriebssystemkonfiguration verf�gbar
und hat in Novell/DR Multiuser-Varianten oder in Ver-
bindung mit lokalen Benutzerkonten oder einmaliger
Anmeldung eine Bedeutung, sofern die Systemabsicherung
aktiviert ist.
Sie k�nnen auch mehrere Attribute mit einem '+'/'-'-
Zeichen koppeln, etwa:
ATTRIB c:\*.* +shr
Haben Sie schon mal das Problem gehabt, ein Verzeichnis
l�schen zu wollen, dessen Hidden-Attribut gesetzt war
(etwa C:\NWCNTL\ oder C:\SENTRY\)? Mit DIR werden solche
Verzeichnisse nicht angezeigt, wohl aber mit ATTRIB.
Allerdings kann man sie mit ATTRIB nicht l�schen. Entweder
man verwendet daf�r den Norton Commander, XDEL oder wendet
einen kleinen Trick an, der bei der Beschreibung von
PASSWORD.EXE steht...
MS-DOS 4.0+ unterst�tzte teilweise einige undokumentierte
Optionen (siehe MSDOSTIP.TXT: /FILESIZE, /DATE, /TIME,
/CODEPAGE, /CP), die Novell DOS 7 und DR DOS fremd
sind, vgl. aber die M�glichkeiten von Novell DOS/DR DOS
TOUCH.EXE.
Errorlevel (unvollst�ndig):
0 normales Ende (MS-DOS/PC-DOS, angeblich auch bei
DR DOS 6.0)
Novell DOS 7: normales Ende oder Datei nicht gefunden
1 Datei nicht gefunden (MS-DOS/PC-DOS, angeblich bei
DR DOS 6.0)
3 Abbruch (MS-DOS/PC-DOS, angeblich auch DR DOS 6.0)
31 Novell DOS 7: Benutzerabbruch durch <Ctrl>+<Break>
oder unzul�ssige Aufrufoption
APPEND.EXE Verwendet bei entsprechender Einstellung (/E) eine
Umgebungsvariable %Append%. Die von CCI Multiuser DOS 7.22
Gold unterst�tzte Option /B f�r eine Ausgabe mit voran-
gestelltem APPEND zur Wiederverwendung in Batchjobs in
Verbindung mit Umleitung gibt es bei Novell DOS und
Caldera OpenDOS 7.01 leider nicht, dies kann aber leicht
nachtr�glich implementiert werden.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 normales Ende
3 Benutzerabbruch (<Ctrl>+<c> etc.)
BACKUP.COM BACKUP erstellt Sicherungskopien Ihrer Dateien.
Sie k�nnen ganze Festplatten und Disketten sichern oder
Dateiverzeichnisse, Dateigruppen und sogar einzelne
Dateien. Die Sicherungskopien m�ssen mit dem Kommando
RESTORE geladen werden, bevor sie als DOS-Dateien ver-
wendet werden k�nnen.
Das Kommando BACKUP ist bei Novell DOS undokumentiert
(abgesehen von neuerlichen Hinweisen im FaxBack-System),
wohl weil ein leistungsf�higeres zugekauftes Programm
namens FBX (FastBack Express/Plus) beiliegt (abgesehen
davon sind Disketten-Backups bei heutigen Festplatten-
kapazit�ten weder vom Zeitbedarf, noch von der Anzahl der
n�tigen Disketten kaum noch zumutbar, h�chstens mit
Programmen wie PC-BACKUP von den PC-Tools).
Trotzdem, aus Kompatibilit�tsgr�nden sind BACKUP.COM und
RESTORE.COM weiterhin vorhanden.
Dabei ist BACKUP mit MS-DOS/PC-DOS BACKUP/RESTORE Version
3.30 und h�her vollst�ndig kompatibel, d.h. mit RESTORE
k�nnen auch Fremd-Backups gelesen werden und Novells
BACKUP kann auch von MS-DOS RESTORE restauriert werden.
(Bei MS-DOS wurde BACKUP nur bis zur DOS-Version 5.0
ausgeliefert und war teilweise inkompatibel zur jeweiligen
Vorg�ngerversion.) Die bei MS-DOS BACKUP vorhandenen
Parameter (/C, /P und - undokumentiert - /HP) werden
von Novells BACKUP nicht unterst�tzt.
Verwenden Sie das Programm BACKUP nicht bei Platten/
Disketten, auf die das Kommando ASSIGN, JOIN oder SUBST
einwirkt (ist mehr eine Vorsichtsma�nahme als eine
Bedingung).
Das Format der Datums-/Zeitangaben h�ngt von der
jeweiligen COUNTRY-Einstellung ab.
Durch Pa�wort gesch�tzte Dateien und Unterverzeichnisse
werden *nicht* gesichert, wenn nicht das globale Pa�wort
gesetzt wurde, bevor BACKUP gestartet wird, und die Dateien
mit demselben Pa�wort gesch�tzt sind.
Parameter�berblick:
(soweit ist noch alles von DR DOS bekannt)
/A F�gt neue Dateien in Sicherung ein, ohne
die alten zu l�schen. Damit kann auch ein
vorhandenes Backup fortgesetzt werden
(fr�he Version von DR DOS 6.0 unterst�tzten
dies noch nicht).
/D:tt.mm.jj Seit einem best. Datum ge�nderte Dateien
werden gesichert.
/F[:n] Formatieren d. Zieldisketten (optional mit
Angabe der Kapaz. n).
/L[:dateispez] Alle Aktionen der Sicherung werden in einer
Protokolldatei (Standardname: \BACKUP.LOG)
aufgezeichnet: Datum und Uhrzeit der
Sicherung und die Nummer der Sicherungs-
diskette, auf der jede Datei gesichert ist.
Die Protokolldatei wird im Hauptinhaltsver-
zeichnis der Ursprungsplatte-/diskette
abgelegt. Wenn Sie den Namen einer bereits
existierenden Protokolldatei im Haupt-
inhaltsverzeichnis angeben, werden die
neuen Protokollinformationen an die be-
stehenden Daten angeh�ngt.
/M Nur seit dem letzten Sichern ge�nderte
Dateien werden gesichert. (Mit diesem
Schalter werden alle Dateien gesichert, f�r
die das Archivierungs-Bit gesetzt ist. Dies
kann nat�rlich mit ATTRIB manuell gesetzt
werden.)
/S Dateien in Unterverzeichnissen werden auch
gesichert. Zur Sicherung einer ganzen
Festplatte/Diskette m�ssen Sie sich im
Hauptinhaltsverzeichnis befinden und /S
angeben.
Standardm��ig wird nur das *aktuelle*
Inhaltsverzeichnis gesichert.
/T:hh:mm:ss Seit einem bestimmten Zeitpunkt ge�nderte
Dateien werden gesichert (mit /D).
Errorlevel (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 2.00+, Novell DOS 7,
Caldera OpenDOS 7.01, DR DOS 6.0 und CCI Multiuser DOS
7.22 Gold)
0 normales Ende
1 keine Dateien zur Sicherung gefunden
2 einige Dateien wegen Zugriffskonflikt nicht gesichert
3 Sicherung durch <Ctrl>+<Break> abgebrochen
4 Sicherung durch Fehler abgebrochen oder ung�ltige
Parameter angegeben.
Weitere Hinweise:
Der Parameter /F:format erlaubt alle (undokumentierten)
Varianten des FORMAT.COM /F: Kommandos, da bei der Angabe
dieses Parameters �ber die Variable %Path% das externe
Kommando FORMAT.COM gesucht und intern gestartet wird.
Der undokumentierte Schalter /U:name erlaubt die Angabe
eines zul�ssigen Benutzeranmelde- oder Gruppennamens.
Diese Option ist nicht unter jedem Betriebssystem ver-
f�gbar und hat in Novell/DR Multiuser-Varianten oder
in Verbindung mit lokalen Benutzerkonten und einmaliger
Anmeldung eine Bedeutung, sofern die Systemabsicherung
aktiviert ist.
CHKDSK.EXE Novells CHKDSK wurde gegen�ber fr�heren Versionen und
gegen�ber MS-DOS extrem erweitert und kann von den M�glich-
keiten durchaus mit Programmen wie DISKFIX (PC-Tools) oder
NDD (Norton Utilities) mithalten, wenn es auch bei Weitem
nicht so komfortabel ist.
Trotzdem wird der Benutzer in vielen kritischen Situationen
�ber m�gliche Risiken informiert und bekommt regelrechte
Ablaufpl�ne angezeigt, die ihm helfen, die jeweilige
Situation zu meistern.
Es besitzt Erkennungsm�glichkeiten f�r alle g�ngigen Multi-
tasker wie TASKMGR, Windows, DESQview, OS/2, als auch f�r
PNW. PNW-Server m�ssen nach Best�tigung automatisch beim
Start von CHKDSK deaktiviert werden, wenn Fehler korrigiert
werden sollen.
Verlorene Bl�cke werden in Dateien namens FILExxxx.CHK
gespeichert.
CHKDSK kommt neben normalen Festplatten mit SuperStor-,
DoubleDisk- und insbesondere STACKER-Laufwerken zurecht.
F�r STACKER 3 Laufwerke gibt es die Spezialparameter /D
und /S (interne STACKER-�berpr�fung). F�r den inkompa-
tiblen STACKER 4 wurde mit Update 13 (CHKDSK 1.21) ein
neuer Parameter /NS eingef�hrt, der STACKER-Laufwerke
�bergeht. Diese Version enth�lt auch einige andere Fixes.
Weitestgehend unbekannt, wenn auch nicht ganz undokumen-
tiert ist die Tatsache, da� CHKDSK auch eine Analyse �ber
die Fragmentierung von Dateien ausgeben kann, wenn man
dazu als Parameter die Dateispezifikation (Wildcards
erlaubt) angibt. Alle spezifizierten Dateien im gew�hlten
Verzeichnis, die nicht in einem St�ck auf der Platte
gespeichert sind, werden in einer Liste ausgegeben.
Um zerst�ckelte Dateien zusammenzufassen, kann man danach
z.B. DISKOPT aufrufen.
CHKDSK c:\*.*
Hierf�r gab es einen Fix mit Update 15 (Januar 1996).
Die Angabe des Gesamtplatzbedarfs f�r Dateien bei CHKDSK
beziehen sich auf den verwendeten Speicherplatz auf dem
Laufwerk, wohingegen sich die Angaben bei TREE auf die
Dateien selbst beziehen. Die Angaben von CHKDSK sind also
etwas gr��er. (N�heres zum Thema Clusterisierung siehe bei
FDISK in Kapitel II.4.)
Obwohl Novell DOS 7 (ab einem Update) Medienseriennummern
unterst�tzt, werden diese von COMMAND.COM w�hrend des DIR-
Befehls nicht ausgegeben. Um die Medienseriennummer zu
erfahren (vorausgesetzt das Medium besitzt eine, was von
der DOS-Version und -Hersteller abh�ngt, unter dem das
Medium formatiert wurde), kann man CHKDSK aufrufen.
Achtung: Bei DR DOS 3.41 und DR DOS 5.0 besa� CHKDSK eine
gro�e Anzahl Optionen, die mit DR DOS 6.0 weggefallen sind
(sehr viel manuelle Feineinstellung war m�glich, offenbar
wurde auch noch CP/M unterst�tzt). Im Einzelnen waren von
dieser Ausd�nnung die alten Optionen /A, /B, /C, /D, /L,
/M, /P, /R und /S betroffen, so da� DR DOS 6.0 CHKDSK nur
noch /F, /V, /H und /? unterst�tzte (DR DOS 5.0 CHKDSK
startet auch unter Novell DOS, d�rfte aber nur einge-
schr�nkt verwendungsf�hig sein). Novell DOS 7 hat gegen�ber
DR DOS 6.0 CHKDSK einige neue Optionen, die teilweise mit
den Buchstaben der alten DR DOS 3.41/5.0 Optionen kolli-
dieren: /B, /D und /S.
Achtung: CHKDSK kommt derzeit noch nicht mit MS Windows95
langen Dateinamen zurecht! Caldera hat aber Abhilfe daf�r
versprochen, die aber mit Caldera OpenDOS 7.01 noch nicht
mitgeliefert wird.
Errorlevel (verifiziert f�r CCI Multiuser DOS 7.22 Gold):
0 alles ok
1 es gibt offene Dateien, CHKDSK kann nicht arbeiten
255 CHKDSK hat einen Fehler entdeckt
COMP.COM Dieses Kommando bietet bei DR DOS und Novell DOS einen
Parameter /M:n, der die Anzahl der Unstimmigkeiten vor
dem Abbruch angibt (Standard ist laut DOSBOOK 10, wie
auch bei MS-DOS/PC-DOS, bei CCI Multiuser DOS 7.22 Gold
jedoch wohl 20). Der Parameter selbst existiert allerdings
bei MS-DOS/PC-DOS nicht (abgesehen davon, da� COMP dort
sowieso mit MS-DOS 6.20 abgeschafft wurde und nur noch
auf einer Supplemental-Disk zu finden ist).
Im Gegensatz zum h�herentwickelten FC.COM arbeitet COMP.COM
immer zeichenweise, kann allerdings die Informationen auch
in Einheiten von Zeilen aufbereiten. Eine Resynchronisation
ist bei COMP.COM nicht m�glich, dementsprechend fragt COMP
auch explizit nach (J/N), wenn sich die Dateil�nge der
beiden Dateien unterscheidet (siehe Kapitel II.16. zur
Vermeidung von Problemen in Batchjobs).
Die von CCI Multiuser DOS 7.22 Gold bekannten Optionen
/B (f�r explizite Bin�rvergleiche, auch wenn die Dateien
nicht eine der Endungen .EXE, .COM, .SYS, .OBJ, .BIN oder
.LIB aufweisen), /W (f�r Unterdr�ckung von WhiteChars, d.h.
Leerfeldern und Tabs w�hrend eines ASCII-Vergleichs) und
/Gn (Anzahl der Zeilen, die vor einer Resynchronisation
�bereinstimmen m�ssen, Default f�r n ist 5) kennt Novells
COMP.COM nicht, da diese Funktionen dort mit dem neueren
FC.COM bereitgestellt werden, das CCI Multiuser DOS noch
nicht kennt. Wie gesagt, Novells COMP arbeitet f�r alle
Dateien zeichenweise, also 'bin�r', daher sind alle drei
Optionen hier �berfl�ssig.
Da COMP.COM standardm��ig die Unterschiede zwischen den
Dateien als absolute Position innerhalb der Dateien angibt,
ist es erw�hnenswert, da� bei Novell DOS auch (neben DEBUG)
ein Werkzeug zur Verf�gung steht, mit dem man diese
Informationen 'verarbeiten' kann: Novells EDIT zeigt
n�mlich u.a. die absolute Zeichenposition an, wodurch es
in Textdateien besonders leicht ist, die Fundstelle zu
lokalisieren (siehe auch bei EDIT.COM in diesem Kapitel).
In der Dokumentation wird nicht erw�hnt, da� COMP.COM auch
interaktiv eingesetzt werden kann:
Gibt man keine Dateispezifikationen an, fragt COMP.COM
von selbst nach, wobei auch hier Wildcards etc. angegeben
werden k�nnen.
Errorlevel (unvollst�ndig):
(nur f�r Novell DOS 7 verifiziert!)
0 normaler Ablauf, auch falls Zieldatei nicht gefunden
oder bei unterschiedlich gro�en Dateien
3 Benutzerabbruch (<Ctrl>+<c> etc.)
4 keine Dateien oder Quelldatei nicht gefunden, oder bei
falscher Aufruf-Syntax
DEBUG.EXE Erhebliche Erweiterungen, die ein eigenes Kapitel f�llen:
siehe Kapitel II.5.
M�chte man den Boot-Vorgang �berwachen, kann man DEBUG.EXE
(wie fast jedes andere Programm auch) nat�rlich auch in
CONFIG.SYS aufrufen, z.B.:
INSTALL=c:\nwdos\debug.exe
Bugfixes mit Update 12 (DEBUG 1.41: Keine Probleme mehr
mit zerst�rten Rootmappings, falls DEBUG von solchen Lauf-
werken gestartet wurde) und Update 13 (DEBUG 1.42: Fixes
f�r -I und -O Kommandos). Mit Update 14 wurde die Datei
nochmals ver�ndert (ca. 1 KByte kleiner) hat aber nach
wie vor die Versionsnummer 1.42 und in der History sind
keine �nderungen erkennbar.
DELPURGE.EXE Ist mit MS-DOS 6.xx UNDELETE /PURGE vergleichbar, basiert
aber auf einem anderen L�schverfolgungskonzept (siehe
DELWATCH.EXE).
Unterst�tzt seit DR DOS 6.0 �ber die undokumentierte
Syntax /U:name die Angabe eines zul�ssigen Benutzeranmelde-
oder Gruppennamens (maximal 12 Zeichen lang). Diese Option
ist nicht unter jedem Betriebssystem verf�gbar und hat
in Novell/DR Multiuser-Varianten oder in Verbindung mit
lokalen Benutzerkonten und einmaliger Anmeldung eine
Bedeutung, sofern die Systemabsicherung aktiviert ist.
DELPURGE unterst�tzt - wie auch Novells UNDELETE - neben
den dokumentierten Parametern noch eine Reihe weiterer
neuer Parameter (wie von MS-DOS/PC-Tools UNDELETE bekannt):
/ALL identisch mit /A
/LIST identisch mit /L
/DT nur "Delete-Tracking-Methoden" verwenden, d.h.
nur die Unterst�tzung durch DISKMAP und DELWATCH
w�hlen. Der Sinn ist mir speziell bei DELPURGE,
das sich doch immer auf eine DELWATCH-L�sch-
verfolgung beziehen mu�, nicht klar...
/DOS nur "DOS-L�schmethoden" verwenden, d.h. auf
DISKMAP und DELWATCH verzichten.
Der Sinn ist mir speziell bei DELPURGE, das sich
doch immer auf eine DELWATCH-L�schverfolgung
beziehen mu�, nicht klar...
*.* Alles
Novells DELPURGE zeigt sowohl den Datums-/Zeitstempel
der ehemaligen Datei, als auch des L�schzeitpunktes an;
letzteres eine Angabe, die UNDELETE in seinen Ausgaben
unterschl�gt.
Mit DELPURGE aus der L�schverfolgung genommene Dateien
lassen sich mit Novells UNDELETE *nicht* wieder restau-
rieren, denn DELPURGE tr�gt statt des zwischengespeicherten
ersten Buchstabens bei Offset +0Dh (BYTE) im reservierten
Bereich des jeweiligen Verzeichniseintrags ein E5h ('�')
ein (daran �ndert auch /DT oder /DOS nichts). Erst nachdem
man hier den wahren ersten Buchstaben der Datei hinschreibt
oder diesen Eintrag zu Null setzt, kann Novells UNDELETE
wieder arbeiten. Man kann aber stattdessen auch auf
PC-Tools 9.0 UNDEL.EXE ausweichen.
MS Windows95 alias MS-DOS 7 benutzt dieses Feld leider f�r
die 10 Millisekunden Einheiten des Zeitpunktes der Datei-
erzeugung, was UNDELETE verwirren k�nnte (bisher noch nicht
�berpr�ft). Evtl. kann man das mit der dort neuen CONFIG.SYS
Direktive ACCDATE= unterdr�cken und so die Kompatibilit�t
wahren.
Die Parameter /D:dd.mm.yy (bzw. /D:-nnn) und /T:hh:mm[:ss]
(in landesspezifischem Format) sind - im Gegensatz zu
UNDELETE (vgl. Kapitel II.4.) - bei DELPURGE exakt
dokumentiert und bieten wirklich nur die beschriebene
Funktionalit�t, beziehen sich also ausschlie�lich auf
den L�schzeitpunkt.
Da trotzdem gewisse Analogien zwischen den Parametern
von DELPURGE und UNDELETE bestehen, sei folgende Anmerkung
erlaubt: Beziehen sich die Angaben der Bereichsgrenzen bei
UNDELETE auf den Bereich *seit* dem angegebenen Zeitpunkt,
so gelten sie bei DELPURGE auf den Bereich *vor* dem ange-
gebenen Zeitpunkt, wie dies auch dem Wesen der beiden
Kommandos entspricht.
W�hrend der Freigabe von entl�schbaren Dateien wird das
jeweilige Laufwerk gesperrt, um Deadlocks zu vermeiden.
Bugfixes mit Update 14 (DELPURGE 1.01: Gibt nun auch bei
installiertem DELWATCH korrekte Datumswerte aus) und Update
15 (DELPURGE 1.02: Fix f�r verlorene Cluster in seltenen
Situationen). Leider gibt es offenbar immer noch einen Bug
(getestet bis Update 15, Januar 1996), der dazu f�hrt, da�
in seltenen Situationen bei DELPURGE /S die Meldung
"Bitte warten..." nicht mehr verschwindet und das System
h�ngt. In einem solchen Fall hilft Neubooten und erneutes
Ausf�hren von DELPURGE, evtl. ohne DELWATCH vorher zu laden
und evtl. mit "NWCACHE -". N�heres ist noch nicht gekl�rt.
Wird Novell DOS 7 DELPURGE auf Dateien angewendet, die noch
mit DR DOS 6.0 DELWATCH gel�scht wurden, so wird wahr-
scheinlich ein v�llig falsches L�schdatum angezeigt
(1980-01-01???). Dies liegt daran, da� DR DOS 6.0 DELWATCH
sich in diesem Punkt von Novell DOS 7 DELWATCH unter-
scheidet (siehe DELWATCH).
DELWATCH.EXE Sollte nicht nach dem TASKMGR geladen werden.
Das L�schen der ersten Datei nach dem Start von DELWATCH
kostet u.U. einige Sekunden Zeit, wenn eine gro�e Anzahl
entl�schbarer Dateien eingestellt wurde. Sp�tere L�sch-
aktionen erleiden keinen merklichen Geschwindigkeitsein-
bruch.
Man sollte versuchen, zu verhindern, da� das Tempor�r-
laufwerk bzw. -verzeichnis (%Temp%) in die L�schver-
folgung ger�t, was leider nicht immer zu bewerkstelligen
ist, da die naheliegende M�glichkeit, DELWATCH einfach
nur f�r Substitut-Laufwerke zu benutzen, deswegen aus-
geschlossen ist, da DELWATCH nur mit physikalischen
Laufwerken arbeiten kann (Netzlaufwerke werden ggf. von
dem jeweiligen Server verwaltet, so da� trotzdem UNDELETE
durchaus auch f�r entfernte Laufwerke funktioniert). (Es
fehlt eine M�glichkeit, bestimmte Verzeichnisse von der
Erfassung der L�schverfolgung auszuschlie�en...). Praktisch
ist die Verwendung einer RAM-Disk als Tempor�rlaufwerk.
Um das meist unn�tige 'Puffern' von tempor�ren Dateien
zu verhindern und damit die Effektivit�t bez�glich der
L�schverfolgung zu optimieren, sollte man diese Dateien
von vornherein von der L�schverfolgung ausschlie�en, z.B.:
DELWATCH /E:TMP+$$$+@@@+SWP+ION+SEM+00?+IMM+$@?+~*
M�chten Sie hingegen eine Einschlu�liste verwenden, ist es
ratsam, hier die Dateiendungen von Dokumenten, Datendateien
und Konfigurationsdateien anzugeben und auf .EXE, .COM,
.OVL, .DLL, .HLP, usw. zu verzichten, da diese Dateien
notfalls von den Original-Disketten neu installiert werden
k�nnen.
Diese Angabe der Ausschlu�- oder Einschlu�liste
(Parameter /O: und /E:, die nicht gleichzeitig erlaubt
sind) ist nur global f�r alle Laufwerke gemeinsam
m�glich, kann aber auch nachtr�glich ge�ndert werden.
Wie dokumentiert, k�nnen jeweils bis zu 10 Dateier-
weiterungen (auch mit Wildcards) angegeben werden, die
mit '+' voneinander getrennt werden m�ssen. Doch wie
gibt man z.B. eine 'leere' Endung an? Ganz einfach:
Bei Novell DOS nicht mehr dokumentiert ist n�mlich die
M�glichkeit, da� man jede der Dateierweiterungen mit
einem optionalen Punkt ('.') einleiten kann (etwa:
/E:.SWP+.TMP). Eine leere Endung wird daher durch einen
einfachen Punkt spezifiziert (z.B. /E:., /E:.SWP+. oder
/E:.+BAK+SIK). Die Zeichen vor einem Punkt werden
ignoriert.
In der Dokumentation wird auch unterschlagen, da� die
Parameter /F:, /B: und /MB? f�r jedes Laufwerk getrennt
eingestellt werden k�nnen. Statt alle Laufwerke auf einmal
zu aktivieren, ruft man dazu DELWATCH mehrfach hinter-
einander f�r jedes Laufwerk einzeln auf, wobei die Para-
meter jeweils wie gew�nscht angepa�t werden. Nat�rlich
gelten die Werte von /F: und /B: f�r jedes der aktivierten
Laufwerke extra, auch wenn mehrere Laufwerke auf einmal
angegeben werden.
Im DOSBOOK wird beschrieben, da� DELWATCH Dateien bis zu
einer einstellbaren Anzahl (mit /F:count (65535 f�r unbe-
grenzt) und davon mit gleichem Namen /B:doublets (von
1..65535)) in der L�schverfolgung h�lt, solange der Platz
auf dem Laufwerk daf�r ausreicht. Ist die Kapazit�t der
Platte ersch�pft, so werden die �ltesten dieser Dateien
gel�scht, es sei denn, man hat die Option /F:ALL angegeben,
die in dieser Situation erst das explizite Entfernen von
Dateien aus der L�schverfolgung (Purgen) erfordert.
In der Praxis habe ich allerdings die Erfahrung gemacht,
da� diese Beschreibung sehr sinnvollen Verhaltens leider
in einigen Punkten *nicht* der Realit�t entspricht:
Ist die Anzahl der mit /F:count (count=1..65534) angege-
benen Dateien noch nicht erreicht und schon jetzt die
Kapazit�t der Platte ersch�pft, so m�ssen auch hier erst
explizit Dateien aus der L�schverfolgung entfernt werden,
um Platz auf dem Laufwerk zu schaffen, d.h. die Option /F:
stellt leider gleichzeitig eine Untergrenze dar (dies
war auch schon bei DR DOS 6.0 so). Dies macht DELWATCH
mit dem eigentlich proklamierten Default-Verhalten nahezu
unbrauchbar, wenn die Anzahl und durchschnittliche Gr��e
der in der L�schverfolgung stehenden Dateien die freie
Kapazit�t der Platte nahezu ersch�pft, was besonders bei
gro�en Werten f�r /F: und fast vollen Platten l�stig wird.
Sinnvoll w�re es, hier in Zukunft Parameter zur getrennten
Einstellung der Unter- und Obergrenze einzuf�hren oder
zumindest die Untergrenze zu beseitigen.
(Sollten Sie andere Erfahrungen gemacht haben, teilen Sie
mir bitte Ihre Aufrufzeile von DELWATCH mit, denn - der
Literatur nach zu urteilen - scheint seltsamerweise au�er
mir niemand sonst dieses Verhalten zu beobachten...)
Weiterhin sind die dokumentierten Sonderf�lle /F:65535
und /F:ALL (getestet mit DELWATCH 2.1) nicht funktions-
f�hig: /F:65535 wird als ung�ltiger Wert zur�ckgewiesen,
und /F:ALL f�hrt den Rechner ins sofortige Daten-Nirwana...
(Bei DR DOS 6.0 wurden beide Einstellungen anstandslos
akzeptiert, allerdings hatte /F:65535 dort noch keine
Sonderfunktion. Leider arbeitet DR DOS 6.0 DELWATCH 1.0
jedoch unter Novell DOS 7 nicht korrekt.)
Und: Obwohl man auf den ersten Blick vermuten k�nnte,
mit /B: eine M�glichkeit zu haben, h�ufig aktualisierte
Dateien quasi in mehreren Versionen auf der Platte halten
zu k�nnen, ist dies in der Regel ein Trugschlu�. Meist
werden dabei n�mlich existierende Dateien nur durch
neuere Versionen �berschrieben (z.B. beim COPY Befehl);
der L�schschutz w�rde aber nur aktiv, wenn die alte,
bereits existierende Datei vorher gel�scht w�rde.
Manchmal kann man dieses Verhalten aber in Batchjobs
durch explizites L�schen vor dem '�berschreiben' er-
zwingen.
Praktischerweise gehen die meisten Editore genau so vor
(z.B. Novells EDIT oder SemWares QEDIT und TSE), wenn
sie eine bereits existierende .BAK-Datei durch eine
neuere Version �berschreiben. Um mehrere .BAK-Dateien
in der L�schverfolgung zu halten, darf die Endung .BAK
(bzw. .SIK o.�.) nat�rlich nicht mit /E: ausgeschlossen
werden...
Das L�schverfolgungskonzept von DELWATCH unterscheidet
sich ziemlich von dem unter PC-Tools (alias MS-DOS 6.xx
UNDELETE), und auch leicht von dem noch von DR DOS 6.0
DELWATCH verwendeten Verfahren (siehe DELPURGE und
UNDELETE).
MS-DOS UNDELETE /LOAD (von PC-Tools) verschiebt (bei
maximalem Schutz 'L�sch�berwachung' alias 'L�sch-
verfolgung') die gel�schten Dateien in ein unsichtbares
Verzeichnis namens \SENTRY\ oder verwaltet (bei geringerem
Schutz 'L�schprotokoll') eine Datei PCTRACKR.DEL, die
Verweise auf gel�schte Dateien enth�lt. Die FAT-Infor-
mation bleibt intakt, dadurch gibt es keine Wechsel-
wirkungen mit anderen Festplattenpflegeprogammen. Das
UNDELETE-Programm mu� sich daf�r allerdings mit 13,5 KByte
resident machen.
DR DOS/Novell DOS verwendet ein anderes Verfahren,
da� in seiner Realisierung etwas leistungsf�higer und
flexibler, wenn auch etwas problematischer ist. Statt
die Dateien zu verschieben oder eine Verweisdatei auf
dem Laufenden zu halten (soetwas �hnliches gibt es mit
DISKMAP auch), werden (zumindest bei Novell DOS) nur die
Dateiattribute auf eine unm�gliche Kombination gesetzt,
d.h. das Volume-Attribut wird zus�tzlich gesetzt. Au�erdem
wird der erste Buchstabe der Datei durch 05h ersetzt.
Erst, wenn die Dateien mit DELPURGE etc. aus der L�sch-
verfolgung entfernt werden, wird die �bliche DOS-L�sch-
methode (erstes Byte E5h '�') verwendet. Au�erdem wird
bei Novell DOS beim L�schen einer Datei generell auch
der erste Buchstabe an anderer Stelle im jeweiligen
Verzeichniseintrag zwischengespeichert (Offset +0Dh
(BYTE)). Wird eine Datei mit DELPURGE aus der L�schver-
folgung genommen, wird hier stattdessen E5h eingetragen,
wodurch die Datei f�r UNDELETE unsichtbar wird, obwohl
sie eigentlich immer noch auf herk�mmlichem Wege entl�sch-
bar w�re. In Verbindung mit Novell DOS 7 DELWATCH wird der
Datums-/Zeitstempel der Datei ebenfalls an andere Stelle
verschoben (Datum bei Offset +12h (WORD) und Zeit bei
Offset +10h (WORD)) und der normale Datums-/Zeitstempel
(Datum bei Offset +18 (WORD), Zeit bei Offset +16h (WORD))
durch die aktuelle Zeit (L�schdatum) ersetzt.
DR DOS 6.0 DELWATCH unterscheidet sich in diesem Punkt,
denn es l��t das Originaldatum wo (und wie) es ist und
verzichtet auf die Speicherung des L�schdatums. Dummerweise
wurde unter DR DOS 6.0 und Multiuser-Varianten das Feld bei
Offset +12h (WORD) noch zur Speicherung der Benutzer-ID
verwendet, Novell DOS 7 DELWATCH �berschreibt dieses Feld
nun einfach mit einem Datum... (Besonders tragisch ist
das nicht, da es ja, wenn man einmal die M�glichkeit eine
Datei zu restaurieren, au�er Acht l��t, nur solche Dateien
betrifft, die bereits gel�scht wurden, und dort sollte der
Eigent�mer eigentlich keine gro�e Rolle mehr spielen...
Bei RENAME o.�. wird der gesamte reservierte Bereich
innerhalb der Verzeichnisstruktur �brigens nicht ge-
l�scht, sondern vom System mitgeschleppt, so da� sich
Owner-IDs wieder reimplementieren lie�en, siehe auch
bei PASSWORD.EXE und in Kapitel II.21.)
Durch die oben beschriebene Vorgehensweise ist das eigent-
liche Verfahren etwas schneller als bei MS-DOS/PC-DOS und
DELWATCH ist (mit DPMS) in der Lage, sich bis auf 464 Bytes
(die nat�rlich in UMBs liegen k�nnen) ins XMS auszulagern!
Die Startphase dauert allerdings bei gro�er Dateianzahl
auf einem Laufwerk recht lange, da hierf�r die gesamte
Platte durchsucht werden mu�. Andererseits sind keine
besonderen Dateien auf der Platte n�tig und das Konzept ist
nicht an freien Speicher, maximale Anzahl der Dateien etc.
gekn�pft.
Die Divergenzen (bez�glich MS-DOS/PC-DOS) in den Ver-
zeichniseintr�gen sind ziemlich unkritisch, da diese
nat�rlich nicht wirklich defekt sind: Allerdings kommen
viele Disk-Tools von Fremdherstellern (etwa PC-Tools 9.0
DISKFIX, nicht aber Norton Utilities NDD) nicht absolut
sauber damit zurecht und meckern eine fehlerhafte Ver-
zeichnisstruktur an (denn innerhalb der bis zu MS-DOS 6.22
'reservierten' Bereiche - sonst mit Nullen gef�llt -
wurden von DELWATCH einige Daten eingetragen, die nun
DISKFIX verwundern). Wenn Sie dann 'Korrigieren' w�hlen,
werden entweder gel�schte Dateien wieder 'entl�scht',
oder eher, entl�schbare Dateien dauerhaft gel�scht (d.h.
aus der L�schverfolgung entnommen). Ich empfehle, vorher
DELPURGE /S laufen zu lassen, was allerdings nicht mehr
funktionieren mag, wenn die Struktur *wirklich* defekt ist.
Meist k�nnen Sie auch ganz auf solche Fremd-Tools ver-
zichten und z.B. Novells recht leistungsf�higes CHKDSK
verwenden. Alternativ dazu k�nnen Sie, wenn Sie den daf�r
notwendigen Speicher �brig haben, statt der Benutzung von
DELWATCH/DELPURGE nat�rlich auch auf MS-DOS 6.2x UNDELETE
/LOAD ausweichen.
MS-DOS UNDELETE /LOAD ist aber nur sehr beschr�nkt f�r
Netzlaufwerke geeignet; es m�ssen volle Schreibrechte auf
dem Laufwerk vergeben werden, was in Netzumgebungen nur
sehr ungern zugestanden wird. Mit Novells Gespann aus
DELWATCH/UNDELETE gibt es diese Einschr�nkung nicht, denn
es arbeitet direkt mit den Mechanismen der NetWare zusammen
und dabei ersetzt UNDELETE z.B. das alte Novell NetWare
SALVAGE. Auf einem PNW-Server mu� DELWATCH installiert
sein, damit man von einem anderen Rechner aus Novells
UNDELETE f�r Dateien auf dem PNW-Server ausf�hren kann.
Es kann vorkommen, da� Fremdprogramme den freien Platz
auf einem Laufwerk nicht korrekt analysieren; dies liegt
einfach daran, da� in der L�schverfolgung h�ngende Dateien
effektiv solange nicht gel�scht sind, bis die Dateien mit
DELPURGE aus der L�schverfolgung genommen werden, der
Diskettenplatz nicht mehr ausreicht oder eine einstellbare
freie maximale Anzahl von in der L�schverfolgung verweilen-
den Dateien �berschritten wird. Mit anderen Worten: Solange
entl�schbare Dateien in der L�schverfolgung existieren,
gibt es also einen entsprechend gro�en 'unsichtbaren'
Bereich auf dem jeweiligen Laufwerk, der von der wahren
Kapazit�t verloren geht.
Novells DELWATCH kollidiert mit MS-DOS 7 Long-Filename-
Support und ACCDATE=. F�r Eintr�ge von langen Datei- und
Verzeichnisnamen wird die unm�gliche Attributkombination
0Fh=Read-Only+Hidden+Systen+Volume verwendet, und dies
k�nnte mit gel�schten, aber von DELWATCH �berwachten
Systemdateien unter Novell DOS kollidieren, bzw. MS-DOS 7
als defekte Long-Filename-Eintr�ge aufsto�en...
Da der Long-Filename-Support allerdings mit Pr�fsummen
arbeitet, sollte eine ordentliche Implementation �ber
solche Eintr�ge hinwegsehen.
MS-DOS 7 neue CONFIG.SYS ACCDATE= Funktion benutzt jedoch
f�r die Speicherung des letzten Zugriffsdatums das gleiche
Feld im reservierten Bereich, das auch DELWATCH zur
Zwischenpufferung des Datumsanteils einer gel�schten, aber
noch in der L�schverfolgung stehenden Datei benutzt
(Offset +12h (WORD)). Obwohl diese Doppelnutzung trickreich
ist, k�nnte es hier zu Problemen kommen, wenn ein Teil vom
anderen nichts wei� (oder wissen will...).
Und auch die neuen Eintr�ge f�r die Dateierzeugung �ber-
lagern Novells Eintr�ge von DELWATCH und PASSWORD (Offset
+0Dh (BYTE) = 10 Millisekunden-Raster nach der Dateier-
zeugung, deren Zeit bei Offset +0Eh (WORD) und Datum bei
Offset +10h (WORD) gespeichert ist), aber dies bezieht
sich wohl nur auf neue Dateien unter MS Windows95.
Fest steht, da� bei geeigneter R�cksichtnahme in der Imple-
mentation alle Funktionen (Microsofts Long-Filenames &
ACCDATE= sowie Novells DELWATCH und Pa�w�rter) einiger-
ma�en kollisionsfrei nebeneinander existieren k�nnten (die
DR DOS 6.0 Owner-IDs sind nat�rlich verloren, aber Novell
DOS 7 unterst�tzt diese M�glichkeit sowieso nicht mehr im
API). (Siehe auch bei PASSWORD.EXE und in Kapitel II.21.)
Caldera hat daf�r aber Abhilfe versprochen, die aber mit
Caldera OpenDOS 7.01 noch nicht mitgeliefert wird.
Errorlevel (unvollst�ndig):
(nur f�r Novell DOS DELWATCH 2.1 aus Update 15 verifiziert)
0 normal
>27 nur in Verbindung mit Option /MBL: Entspricht, nach
Subtraktion von 27 dem Wert der explizit mit /F:n
angegebenen oder implizit angenommenen Anzahl der
maximal in der L�schverfolgung h�ngenden Dateien f�r
das/die aktivierte(n) Laufwerk(e), d.h. ohne Angabe
von /F:n f�r Diskettenlaufwerke 47 (20 Dateien) oder
f�r Festplattenlaufwerke 227 (200 Dateien).
DISKCOMP.COM Diese beiden Kommandos werten die Variablen %Temp% und
DISKCOPY.COM %tmp% aus, wenn eine tempor�re Auslagerungsdatei auf der
Harddisk erzeugt werden mu� (wenn der Speicher nicht
ausreicht). Nat�rlich wird zun�chst EMS- und XMS-Speicher
zur Zwischenpufferung verwendet (evtl. kein XMS-Speicher
unter Windows 3.1). Auf diese Weise wird (ab DR DOS 6.0
(5.0?)) das bis zu zehnmalige Diskettenwechseln beim
Kopieren verhindert, das bei MS-DOS bis vor 6.2 Usus war.
Auf diese Weise ist auch Kopieren im Hintergrund unter
Multitaskern m�glich.
In diesem Zusammenhang wurde mit MS-DOS 6.2 ein neuer
Parameter DISKCOPY /M eingef�hrt, der eine v�llig andere
Funktion als der von DR DOS & Novell DOS 7 bekannte
Parameter /M hat: Statt Diskettenabzugsdateien (�bliche
Dateiendung daf�r ist .IMG) zu unterst�tzen, wird damit
die Verwendung des Festplattenspeichers unterdr�ckt.
Hinweis: Beim Vergleich (DISKCOMP) von mit DISKCOPY
kopierten Disketten �lteren Datums kann es zu Unter-
schieden auf Seite 0 Spur 0 kommen, obwohl die Kopie
fehlerfrei ist. Dieses Ph�nomen tritt auch bei
MS-DOS/PC-DOS vor 5.0 auf:
Fixes mit Update 14 (DISKCOMP 2.04): Beim DISKCOPY werden
jetzt au�er der Seriennummer keine Ver�nderungen mehr
vorgenommen, so da� jetzt mit DISKCOMP keine Fehlerreporte
mehr nach erfolgreichem DISKCOPY auftreten. DISKCOPY
formatiert Floppies nur noch, falls unbedingt notwendig
(d.h. nicht formatiert oder anderes physikalisches Format).
Errorlevel f�r DISKCOMP (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
wahrscheinlich auch DR DOS 6.0)
0 normales Ende
1 Disketten verschieden
oder bei Novell DOS 7 auch: Vergleich nicht ausgef�hrt,
bei DR DOS 6.0 auch : ung�ltiges Laufwerk,
falsche Syntax
2 Abbruch durch Benutzer (<Ctrl>+<c> etc.)
3 Hardware-Fehler, kein Vergleich durchgef�hrt
4 Initialisierungsfehler, zu wenig Speicher, Laufwerk
oder Syntax falsch
Errorlevel f�r DISKCOPY (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
wahrscheinlich auch DR DOS 6.0)
0 normales Ende
1 ung�ltiges Laufwerk, falsche Syntax,
nicht fataler Lese-/Schreibfehler
2 Abbruch durch Benutzer (<Ctrl>+<c> etc.)
3 fataler Hardware-Fehler, kein Vergleich durchgef�hrt,
kann Quelle nicht lesen oder Ziel nicht formatieren/
schreiben
4 Initialisierungsfehler, zu wenig Speicher, Laufwerk
oder Syntax falsch
DISKMAP.EXE Die angelegte Datei hei�t DISKMAP.DAT und ist normalerweise
schreibgesch�tzt, aber nicht versteckt. Wird die bereits
existierende Datei allerdings manuell versteckt, z.B. mit
ATTRIB diskmap.dat +h
so bleiben diese Attribute auch erhalten, wenn die Datei
beim n�chsten Aufruf von DISKMAP.EXE (n�chstes Booten)
aktualisiert wird. DISKMAP ist kein TSR wie DELWATCH.
Achtung: Normalerweise sollten Programme wie DISKMAP,
PC-Tools' MIRROR oder Norton Utilities' IMAGE mindestens
bei jedem Bootvorgang des Rechners aufgerufen werden, um
die Verweisdateien zu aktualisieren. Im Falle eines
schweren Fehlers in der Festplattenorganisation, der
nicht behoben werden kann, ohne den Rechner zun�chst zu
booten, sollte man diese Aufrufe jedoch tempor�r aus
AUTOEXEC.BAT entfernen, damit wenigstens die letzten noch
g�ltigen Daten nicht mit einer nun fehlerhaften Struktur
�berschrieben werden (siehe UNFORMAT.EXE).
Manchmal mag es sinnvoll sein, DISKMAP bei jeder R�ckkehr
zum Prompt aufzufrischen: Dies ist unter DR DOS 6.0
und Novell DOS mit PROMPT $x und %PExec% m�glich, siehe
Kapitel II.11. und IV.7.
Siehe auch bei DELPURGE.EXE, DELWATCH.EXE und UNDELETE.EXE
in Kapitel II.4.
DISKOPT.EXE Unterst�tzt Disketten, Festplatten, SuperStor-, Double-
Space- und STACKER-Laufwerke und stellt einen recht
hochentwickelten Entfragmentierer �hnlich wie COMPRESS,
OPTIMIZR (PC-Tools) oder SPEEDISK (Norton Utilities) dar.
Multitasker wie TASKMGR und Windows als auch PNW m�ssen
vor einem Optimierungslauf beendet werden. Ein laufender
PNW-Server kann beim Start von DISKOPT automatisch de-
aktiviert werden (Frage J/N).
DISKOPT ist kompatibel mit allen g�ngigen Cache-Programmen
wie NWCACHE, NLCACHE, SMARTDRV 3.xx und 4.xx, PC-CACHE,
Norton-CACHE, HyperDisk und PC-Kwik und deaktiviert diese
Programme (inkompatible Cache-Programme sollten vorher
beendet werden).
Werden alte STACKER-Formate erkannt, k�nnen diese in ein
aktuelles und effektiveres Format umgewandelt werden.
Besitzt ein eingebautes Hilfesystem.
Zus�tzliche unbekannte oder undokumentierte Parameter:
/RESTORE=[laufwerk:]\STACVOL.EXT stellt das STACKER-
Laufwerk wieder her, falls die Optimierung
durch Neustart oder Stromausfall unterbrochen
wurde (und das Laufwerk nicht aktiviert wird).
Undokumentierte Parameter (wie von MS-DOS DEFRAG), nur in
Verbindung mit STACKERs SDEFRAG, das intern DISKOPT mit-
verwendet, verf�gbar (bei SDEFRAG /? sind u.a. diese
Parameter dokumentiert):
/GL �ndert die erwartete Kompressionsrate
/GP Erh�ht die Gr��e des STACKER-Laufwerks
/BW Schaltet Anzeige auf Monochrom
/LCD Schaltet Anzeige auf LCD-Darstellung
/BATCH Wartet nicht auf best�tigenden Tastendruck
/SKIPHIGH L�dt keine Daten in den oberen Speicher
/G0 (in Worten: "G-Null") Deaktiviert die graphische
Maus und den graphischen Zeichensatz (NewUI=Off)
Die Datei NWDOS.INI (�ber %NWDOSCFG%) enth�lt die Grund-
einstellungen f�r DISKOPT.
Spezielle Einstellungen f�r DISKOPT sind in der Gruppe
[DISKOPT] m�glich (dies ist undokumentiert), ansonsten
werden die Einstellungen aus der Default-Gruppe [COLORS]
�bernommen:
CurrentColor=
NewUI=on|off
Die offiziell vorhandene Einstellung [DISKOPT] MapColor=
scheint hingegen in der derzeitigen Ausgabe von DISKOPT.EXE
keine Bedeutung mehr zu haben.
Au�erdem wird die Direktive [COLORS] ColorSetX= ausgewertet
(X=<CurrentColor> aus 1..9).
DISKOPT verschiebt keine Dateien mit gesetztem Hidden- oder
System-Attribut.
Nach einem Lauf von DISKOPT k�nnen nur noch solche Dateien
mit UNDELETE wiederhergestellt werden, die in der L�sch-
verfolgung von DELWATCH etc. lagen. Normal gel�schte
Dateien werden beim Umstrukturieren der Platte �ber-
schrieben, unter der Kontrolle von DELWATCH gel�schte
Dateien werden jedoch nicht sofort gel�scht, sondern sind
nur f�r normale Programme nicht mehr sichtbar. Auf diese
Weise werden sie aber bei derartigen Umstrukturierungen
wie existierende Dateien behandelt und daher umkopiert
statt �berschrieben.
Sicherheitshalber sollten Sie nach einem DISKOPT-Lauf
den Rechner neu booten (insb. wenn Sie FASTOPEN= verwenden)
und DISKMAP aufrufen, um die Verweisdatei zu aktualisieren.
Anscheinend gibt es eine optionale Datei DISKOPTJ.EXE, die
in Verbindung mit dem Modus 'Japanisch' notwendig ist.
N�heres ist mir bisher unbekannt, eine japanische Ausgabe
von Novell DOS konnte ich bisher noch nirgendwo entdecken,
obwohl sie urspr�nglich angek�ndigt wurde.
Achtung: DISKOPT kommt derzeit nicht mit langen Datei-
namen von MS Windows95 zurecht (wie sollte es auch?).
Caldera hat aber Abhilfe versprochen, die aber mit
Caldera OpenDOS 7.01 noch nicht mitgeliefert wird.
DISPLAY.SYS Die Aufruf-Syntax (inkl. undokumentierter Erweiterungen)
ist in Kapitel II.16. beschrieben.
Die Unterst�tzung f�r EGA-, MCGA- und VGA-Karten er-
fordert immer die Angabe der Option 'EGA', da die Code-
seitenunterst�tzung von DOS bisher auch keine besonderen
Funktionen der VGA ausnutzt (vom Font 16x8 einmal abge-
sehen). Ebenfalls siehe Kapitel II.16.
Die .CPI-Dateien von DR DOS 6.0 und Novell DOS 7 (DRFONT)
enthalten einen undokumentierten vierten Font 6x8. Dieser
theoretisch f�r Grafikmodi und Textmodi mit mehr als 43
Zeilen auf Super-EGAs, bzw. mehr als 60 Zeilen auf Super-
VGAs, vielleicht im Hinblick auf DR PalmDOS auch f�r
PalmTops mit speziellen reduzierten LCD-Anzeigen interes-
sante Font ist aber offenbar �blicherweise nicht freige-
schaltet, zumindest nicht explizit.
Die von MS-DOS her bekannten Dummy-Ger�tetypen 'MONO' und
'CGA' unterst�tzt Novell DOS nicht; sie sind aber auch bei
MS-DOS funktionslos, schlie�lich bieten MDA, HGC und CGA
nur *einen* Hardware-Font (vgl. GRAFTABL.COM), der nicht
per Software �nderbar ist.
Der Typ 'LCD' und die bei MS-DOS undokumentierten Unter-
typen 'EGA 8','EGA 14' und 'EGA 14M' werden nicht unter-
st�tzt (letztere aber auch nicht zur�ckgewiesen), d�rften
aber sowieso obsolet sein, da man (fast) das Gleiche wohl
�ber die Angabe der zu installierenden Fonts erreichen
kann. Wie .CPI-Dateien von MS-DOS unter Novell DOS ver-
wendet werden k�nnen und wie damit dennoch die Unter-
st�tzung f�r 'LCD' bzw. 'EGA 8' m�glich ist, wird in
Kapitel II.16. beschrieben.
Haben Sie sowohl eine MCGA/EGA/VGA-Karte als auch eine
MDA/HGC-Karte in Ihrem Rechner installiert, so scheitert
die Einrichtung der Codeseitenumschaltung f�r den Farb-
adapter, wenn das aktive Bildschirmsystem zum Zeitpunkt
des Aufrufs von DISPLAY.SYS die Monochromkarte ist. In
diesem Fall m�ssen Sie entweder die DIP-Schalter auf dem
Mainboard so stellen, da� die Farbkarte default-m��ig
gew�hlt wird oder Sie verwenden MODE, um vorher auf die
Farbkarte umzuschalten. Au�erdem sollten Sie in diesem
Fall auch auf die Angabe einer Codeseite verzichten,
da sonst eine Fehlermeldung erscheint (siehe Kapitel
II.16):
CONFIG.SYS:
INSTALL=c:\nwdos\mode.com co80
DEVICE=c:\nwdos\display.sys con=(EGA,,(1,3))
ANSI-Treiber und andere Ger�tetreiber f�r CON: sollten vor
DISPLAY.SYS geladen werden, damit diese den DISPLAY.SYS
Treiber nicht abkoppeln k�nnen.
Achtung: Die bei DISPLAY.SYS notwendige Angabe der Code-
seite bezieht sich auf die hardware-m��ig installierte
Codeseite (da DOS dies nicht �berpr�fen kann, mu� diese
Angabe �berhaupt erst vorgenommen werden). Auch wenn Sie
sp�ter mit Codeseite 850 etc. arbeiten wollen, sollten Sie
hier noch die Codeseite 437 angeben, die zumindest f�r
alle in den USA und West-Europa erh�ltlichen Grafikkarten
(BIOSe und Fonts) die Grundlage darstellt. Wenn Sie hier
eine andere Codeseite als die wirklich unterst�tzte
Hardware-Codeseite angeben und sp�ter nicht f�r *alle*
ben�tigten Codeseiten installierbare Codeseiten einrichten,
kann die Codeseitenunterst�tzung von DOS nicht sauber
arbeiten, da sie von falschen Voraussetzungen ausgeht.
Allerdings: Auch wenn die Hardware-Codeseite �blicherweise
mit der Codeseite 437 �bereinstimmt (so da� die zus�tzliche
Einrichtung einer installierbaren Codeseite 437 entfallen
kann), unterscheidet das Betriebssystem sehr wohl zwischen
einer Hardware- und einer installierbaren Codeseite:
Mu� DOS eine vorbereitete Codeseite aktivieren, wird
der Font aus der zugeh�rigen .CPI-Datei geladen; bei
Aktivierung der Hardware-Codeseite wird der Font aus
dem BIOS der Grafikkarte benutzt. Die Hardware-Codeseite
ist unter der Nummer ansprechbar, die Sie bei DISPLAY.SYS
daf�r angegeben haben. Fehlt die Angabe, nimmt DISPLAY.SYS
in Anh�ngigkeit von Grafikkarte und COUNTRY= Einstellung
pauschal eine Codeseite an, ohne dies wirklich �berpr�fen
zu k�nnen (normalerweise also 437).
Da die Einrichtung von Codeseiten mit zu den komplizier-
testen Angelegenheiten in der Konfiguration von DOS
geh�rt, seien ein paar zus�tzliche �berlegungen erlaubt
(die mit Novell DOS 7 �berpr�ft wurden):
Angenommen, die Hardware-Codeseite Ihrer Video-Karte
entspricht Codeseite 437 (fast immer der Fall), dann reicht
es meist aus, lediglich alle anderen zus�tzlich ben�tigten
Codeseiten mit MODE con: CODEPAGE PREPARE vorzubereiten.
Die Anzahl der zu reservierenden Codeseiten bei DISPLAY.SYS
entspricht dann dieser Zahl der zus�tzlichen Codeseiten.
Selbstverst�ndlich k�nnen Sie auch die Codeseite 437 be-
nutzen, obwohl sie nicht extra vorbereitet wurde; DOS
schaltet dann einfach auf die Hardware-Codeseite um. F�r
den Fall, da� Sie zus�tzlich nur noch Codeseite 850 be-
n�tigten (und dabei alle Fontgr��en), s�he die Konfigura-
tion etwa wie folgt aus (nat�rlich kann man den Treiber
auch hochladen):
CONFIG.SYS:
DEVICE=c:\nwdos\display.sys con=(EGA,437,(1,3))
AUTOEXEC.BAT:
MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
CHCP 437
Wenn Sie jedoch auch eine andere *Darstellung* der Code-
seite 437 w�nschen, als sie in Ihrem Video-BIOS-EPROM
eingebrannt ist, k�nnen Sie die Codeseite 437 durch einen
Font aus einer .CPI-Datei ersetzen. Nat�rlich wird f�r
diesen Font eine vorzubereitende Codeseite veranschlagt,
was zus�tzlichen Speicherplatz kostet. Angenommen, Sie
m�chten die Darstellung der Codeseite 437 durch eine
andere Darstellung (z.B. einen ISO-Font) ersetzen und
zus�tzlich noch mit der Codeseite 850 arbeiten, dann
m�ssen Sie jetzt zwei Codeseiten vorbereiten (437 und 850).
Die Hardware-Codeseite, die Sie - entsprechend obigen An-
weisungen - ebenfalls als Codeseite 437 deklariert hatten,
ist in dieser Konstellation nicht mehr erreichbar.
Im Beispiel:
CONFIG.SYS:
DEVICE=c:\nwdos\display.sys con=(EGA,437,(2,3))
AUTOEXEC.BAT:
MODE con: CODEPAGE PREPARE=((437,850) c:\nwdos\ega.cpi)
CHCP 437
Allerdings h�lt Sie niemand davon ab, als Kennung der
Hardware-Codeseite einfach eine andere Nummer als 437
anzugeben (die noch nicht einmal einer g�ltigen Codeseiten-
Kennung entsprechen mu�). Erlaubt sind alle Zahlen von
0..32767. (32768..65535 sind eigentlich auch g�ltig, aber
MODE gibt diese Nummern sp�ter als negative Zahlen aus.)
Die Hardware-Codeseite k�nnen Sie dann sp�ter unter dieser
Nummer (cp) mit
MODE con: CODEPAGE SELECT=cp
erreichen, auch wenn die wahre Kennung der Hardware-Code-
seite (nat�rlich immer noch 437, schlie�lich hat sich
am EPROM-Inhalt nichts ge�ndert) mit einer vorbereiteten
Codeseite �berdeckt wurde. (Allerdings wird der Hardware-
Font nicht in allen F�llen reaktiviert, sondern offenbar
nur initialisiert. N�heres hierzu ist noch nicht gekl�rt.)
In obigen Beispiel:
CONFIG.SYS:
DEVICE=c:\nwdos\display.sys con=(EGA,999,(2,3))
AUTOEXEC.BAT:
MODE con: CODEPAGE PREPARE=((437,850) c:\nwdos\ega.cpi)
CHCP 437
Anmerkung: In diesem Beispiel habe ich f�r diese Dummy-
Kennung die Nummer 999 verwendet, weil diese Kennung mit
keiner existierenden Codeseiten-Nummer kollidiert und
obendrein bei Novells KEYB intern f�r benutzerdefinierte
Codeseiten reserviert ist und insofern ganz gut pa�t.
Wie gesagt, jede beliebige Nummer ist erlaubt, da DOS
sowieso nicht �berpr�fen kann, ob die Hardware-Codeseite
wirklich zu dieser Nummer geh�rt oder nicht.
Aufgrund des h�heren Speicherplatzbedarfs sollten die
zweite und dritte Alternative allerdings nur verwendet
werden, wenn Sie aus gutem Grund auch die Darstellung
des Fonts 437 ver�ndern wollen, z.B. bei Verwendung
fremder .CPI-Dateien mit anderen Schriftarten, etwa wie
ISO-, Kursiv- oder Schreibschriften etc. Nat�rlich m�chten
Sie dann die ge�nderte Darstellung der Schriften nicht
nur in den zus�tzlichen Codeseiten genie�en, sondern auch
mit Codeseite 437... Den Hardware-Font aus dem Video-BIOS
mit einer gleichwertigen oder gar bin�r identischen Font-
Darstellung aus einer .CPI-Datei zu �berladen, ist reine
Speicherplatzverschwendung. N�heres hierzu auch bei
MODE.COM in diesem Kapitel.
Der Speicherbedarf von DISPLAY.SYS gliedert sich in
mehrere Bereiche und h�ngt auch von der Anzahl der zu
installierenden Fonts und vorzubereitenden Codeseiten ab:
Fonts: Zahl der vorzubereitenden Codeseiten:
1 2 3 ...
(6x8) (5168 Bytes) (7728 Bytes) (10288 Bytes)
1: (+1536=) (+2*1536=) (+3*1536=)
8x8 6704 Bytes 10800 Bytes 14896 Bytes
2: (+2048=) (+2*2048=) (+3*2048=)
8x8, 14x8 8752 Bytes 14894?Bytes 21040 Bytes
3: (+3584=) (+2*3584=) (+3*3584=)
8x8, 14x8, 16x8 12336 Bytes 22064 Bytes 31792 Bytes
davon enthalten die eigentlichen Font-Daten pro Codeseite:
(6x8) : (1536 Bytes)
8x8 : 2048 = 2048 Bytes
8x8, 14x8 : 2048 + 3584 = 5632 Bytes
8x8, 14x8, 16x8 : 2048 + 3584 + 4096 = 9728 Bytes
Wie Sie sehen k�nnen, lassen diese Daten �brigens darauf
schlie�en, da� der jeweils gr��te Font �berhaupt nicht
innerhalb dieser Datenstruktur definiert wird, sondern
offenbar innerhalb des Grafikkarten-RAMs abgelegt wird
(das m��te es erlauben, eine eigene Darstellung eines
Fonts der Codeseitenunterst�tzung unterzuschieben, indem
man den Fontbereich der Grafikkarte direkt mit einem
eigenen Font beschreibt (nicht �berpr�ft)) und da� der
Font 6x8 tats�chlich geladen wird.
Und: Der Speicherbedarf von DISPLAY.SYS ist trotzdem bei
mehr als einer vorzubereitenden Codeseite ganz betr�cht-
lich, so da� hier noch Optimierungsspielraum insofern
best�nde, da� die gerade nicht ben�tigten Daten ausge-
lagert w�rden (z.B. XMS, EMS oder Festplatte).
Die gleichen Prinzipien lassen sich �brigens auch auf
PRINTER.SYS und .CPI-Dateien f�r Drucker anwenden, sind
dort allerdings erheblich sinnvoller, wenn auch noch
komplizierter zu verwenden, sobald Sie andere als die
standardm��ig unterst�tzten Drucker ansteuern m�chten.
Weitere Informationen finden sich bei PRINTER.SYS und
in Kapitel II.16.
DOSBOOK.EXE Das Online-Handbuch zu Novell DOS - DOSBOOK - d�rfte
normalerweise keine Bedienungsprobleme aufwerfen. Hat man
sich jedoch mit Querverweisen immer tiefer verschachtelte
Informationen durchgelesen und m�chte nun zum jeweiligen
Hauptkontext (Inhalt, Glossar, Index) zur�ck, um dort das
n�chste Thema anzuschauen, so w�hlen viele Benutzer aus
Unwissen die langsame Methode (<Alt>+<z> f�r 'Zur�ck'),
um sich Schritt f�r Schritt zur�ckzuhangeln.
Stattdessen ist es viel einfacher, in das Hilfe-Men� zu
gehen (<Alt>+<h>) und dort eines der drei Hauptgebiete
anzuw�hlen. DOSBOOK verzweigt dann direkt zum passenden
Eintrag des aktuellen Themas im gew�hlten Hauptkontext.
Z.B. findet <Alt>+<h>-<a> (f�r 'Inhalt') wirklich die
Stelle im Kontext 'Inhalt', die das aktuelle Thema
behandelt.
Die Datei NWDOS.INI enth�lt in der Gruppe [DOSBOOK] die
Grundeinstellungen des Hilfesystems:
InitialZoom=1 # 0=Fenster, 1=Vollbild
#
# DOSBook-Druckereinstellungen:
#
PrintDevice=PRN # Druckerger�tename
LeftMargin=8 # Anzahl leerer Spalten links vom Text
# im Ausdruck (Rand f�r Heftung).
TextColumns=64 # Anzahl der Textspalten im Ausdruck.
# F�r breite Drucker oder Ausdrucke im
# Querformat k�nnen Sie hier auch
# wesentlich h�here Werte angeben.
LinesPerPage=62 # Verwenden Sie 0 f�r: Kein Seitenumbruch
# im Ausdruck.
Underline1=45 # Zeichencode f�r Einzelunterstreichung
# im Ausdruck, hier '-'.
Underline2=61 # Zeichencode f�r Doppelunterstreichung
# im Ausdruck, hier '='.
sowie in [DOSBOOK] (hier undokumentiert) oder in [COLORS]
CurrentColor=
NewUI=on|off
Au�erdem wird die Einstellung ColorSetX= aus [COLORS] aus-
gewertet (X=<CurrentColor> aus 1..9). Offenbar gibt es auch
noch eine Direktive OLHfile= f�r eine externe Hilfedatei
und eine Gruppe [DRDOS] (n�heres ist noch nicht gekl�rt).
Eine meines Erachtens besonders angenehme Farbeinstellung
f�r das DOSBOOK finden Sie in Kapitel II.19.
Noch ein Hinweis:
Leider sind nicht alle Links im DOSBOOK korrekt, au�erdem
fehlen manche wenige Optionen und Befehle komplett (z.B.
BACKUP und RESTORE). Deshalb sollte man in jedem Fall auch
'befehl /?' aufrufen, wo meist alle offiziellen Parameter
angezeigt werden.
Errorlevel (unvollst�ndig):
0 alles ok
31 Syntax-Fehler in Parameter
DOSKEY.EXE Dieses TSR zur erweiterten Kommandozeileneditierung ent-
spricht in seinem Verhalten fast 100% dem Gegenst�ck von
MS-DOS (DR DOS/Novell DOS bot und bietet f�r Kommando-
zeileneditierung zus�tzlich noch die HISTORY= Funktion ab
CONFIG.SYS an, die bei MS-DOS erst mit DOSKEY bereitge-
stellt wird, entsprechend bezieht sich die /B[UFSIZE]
Option auch nur auf den Makropuffer und nicht auch auf
den Kommandozeilenpuffer, wie im DOSBOOK f�lschlicherweise
angegeben, vgl. Kapitel III.1. und II.12.).
In der deutschen Ausgabe zu Novell DOS gibt es eine
Datei LIESMICH.TXT, die darauf hinweist, da� die Kommando-
zeilenparameter von DOSKEY auch abgek�rzt werden k�nnen.
Im DOSBOOK wird die Langform beschrieben, die zwar nicht
zur�ckgewiesen wird, in Wahrheit aber auch nicht komplett
ausgewertet wird, d.h. wenn der erste Buchstabe des Para-
meters stimmt, wird die Option schon akzeptiert.
Die Option /R[EINSTALL] l�scht bei Novell nur alle
Makros, eine neue Kopie von DOSKEY wird nicht geladen.
Neben den in der Dokumentation beschriebenen Token $t,
$T (vgl. <Ctrl>+<t> in Kapitel II.11.), $l (das im der
deutschen Ausgabe des DOSBOOKs �brigens f�lschlicher-
weise als $I beschrieben wurde), $L, $b, $B, $1..$9
funktionieren nat�rlich auch die anderen von MS-DOS/
PC-DOS bekannten Token:
$$ f�r das '$' Zeichen selbst
$* f�r *alle* Parameter, d.h. $1 $2 $3 $4 $5 $6 $7 $8 $9
Zus�tzlich bietet Novells DOSKEY undokumentiert noch:
$0 analog zum eigenen Programmnamen %0, hier also der
eigene Makroname.
Da die Dokumentation zu DOSKEY sehr l�ckenhaft ist, hier
noch ein paar Anmerkungen:
Mit DOSKEY ist es m�glich, Aliase und Makros zu definieren,
dabei k�nnen auch interne Kommandos redefiniert werden.
M�chte man zwischenzeitlich zwischen dem Original und dem
Makros/Alias unterscheiden, gibt es dazu die von MS-DOS
bekannte Methode, dem Kommando Leerfelder voranzustellen
(ein vorangestelltes '@'-Zeichen mu� trotzdem weiterhin
in der ersten Spalte stehenbleiben).
Nur Kommandos, die in der ersten Spalte beginnen, werden
ggf. als Makro/Alias ausgewertet, einger�ckte Kommandos
immer als Originalbefehl (wichtig in Batchjobs, wenn man
ein bestimmtes Verhalten sicherstellen mu�). (Leider
stimmt diese Regel f�r Novells Implementation nicht ganz,
Ausnahmen siehe unten.)
Interessanterweise kann man bei Novells COMMAND.COM den
*internen* Befehlen aber auch ein Zeichen aus '.', ';',
'+' und '=' voranstellen (etwa =DIR), das genauso wie ein
Leerfeld wirkt, solange es kein Makro/Alias gibt, das
ebenfalls dieses Zeichen im Befehlsnamen hat. Da hier
eine Reihe Fallstricke existieren und 4DOS z.B. etwas
anders reagiert, sei auf die ausf�hrlicheren Hinweise
in Kapitel II.11. verwiesen.
Novells DOSKEY v0.01 hat allerdings derzeit auch noch
ein paar Designschw�chen (Update 15):
- Leider funktioniert die Unterscheidung zwischen Makro/
Alias und Originalkommando anhand der Position in der
Eingabezeile bei Novell nicht ganz genauso wie bei
MS-DOS. Bei *internen* Kommandos kann man direkt am
Prompt das Originalkommando *nicht* durch ein voran-
gestelltes Leerfeld erreichen (als Workaround ist hier
allerdings z.B. ein vorangestelltes Gleichheitszeichen,
etwa =DIR *.* m�glich). In den anderen F�llen ist das
Verhalten identisch.
- Geben Sie bei einem Makro niemals mehr als 9 Parameter
an, denn Parameter 10 und dar�ber hinaus werden auf die
Parameter 0 usw. zur�ckgefaltet, die dadurch zerst�rt
werden. Die Resultate sind v�llig konfus.
- Das Zeichen direkt nach einem $ wird immer verschluckt,
auch wenn es sich nicht um ein Token handelt (ist aller-
dings sinnvoll, um die Kompatibilit�t mit zuk�nftigen
Erweiterungen zu sichern).
- Die Makroexpandierung arbeitet nicht, wenn der Kommando-
prozessor 4DOS/NDOS ist, dies gilt auch f�r COMMAND.COM
von MS-DOS. In einer tempor�r geladenen Kopie von
COMMAND.COM funktioniert allerdings alles einwandfrei.
4DOS bietet aber gleichwertige Ersatzfunktionen an. Wenn
Sie also nicht unbedingt die Kompatibilit�t mit DOSKEY
wahren m�ssen, brauchen Sie DOSKEY mit 4DOS/NDOS �ber-
haupt nicht zu laden.
- Dem '!' kommt eine Sonderfunktion als Alias f�r $T zu
und deshalb kann es nicht als normales Zeichen ver-
wendet werden, bzw. wird es doch verwendet, so dient es
als Trenner zwischen Kommandos.
Unter CCI Multiuser DOS ist das '!'-Zeichen in Dateinamen
nicht erlaubt (CCI Multiuser DOS 7.22 Gold), daher kann
die hier beschriebene Funktion als Trenner auch an der
Kommandozeile von MDOS.COM/TMP.EXE verwendet werden
(siehe Kapitel II.20.). Unter normalem DOS ist das
Ausrufezeichen aber ein g�ltiges Zeichen f�r Dateinamen,
daher unterst�tzt Novells COMMAND.COM nach au�en hin
diese Funktion nicht! Intern arbeiten aber alle
COMMAND.COM Versionen der ehemaligen Digital Research
Linie mit dieser speziellen Funktion (schauen Sie sich
diesbez�glich einfach mal den Beginn von COMMAND.COM mit
einem Dump-Betrachter an:
Sie werden eine gewisse Parallele bei !date!time f�r den
Start von COMMAND.COM ohne AUTOEXEC.BAT entdecken.)
Partielle M�glichkeiten, mehrere Kommandos in einer
Zeile anzugeben, werden in Kapitel II.11. beschrieben.
- DOSKEY hat mit MS-DOS 7 eine Reihe mehr oder weniger
sinnvolle Erweiterungen erfahren, die dem 1,5 Jahre
fr�her eingef�hrten Novell DOS 7 nat�rlich noch fremd
sind. Zumindest die M�glichkeit eines erweiterten
Tastaturpuffers kann aber nach wie vor wesentlich
effektiver von dem erweiterten Tastaturtreiber K3PLUS
bzw. FreeKEYB bereitgestellt werden.
DPMI.EXE Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok
1 Aufruf von DPMI ohne Parameter bei deaktiviertem
DPMI (z.B. vorheriges DPMS off).
DPMS.EXE DPMS.EXE (Novells DOS Protected Mode Services - eine Art
Protected Mode DOS-Extender/-Server f�r TSRs) funktioniert
mit Prozessoren ab 286er und sollte normalerweise unmittel-
bar nach den anderen Speichermanagern per DEVICE= geladen
werden. Je nach vorhandener CPU wird entweder ein 286er-
Overlay oder ein 386er-Overlay (derzeit auch f�r h�here
Prozessoren) eingebunden. Unterst�tzt auch 32Bit-Protected-
Mode-Anwendungen. Der Treiber enth�lt auch einen virtuellen
Ger�tetreiber f�r MS Windows (der evtl. f�r DOS-Boxen be-
n�tigt wird, wenn dort Programme DPMS nutzen wollen???).
Es ist sogar m�glich, DPMS.EXE erst in AUTOEXEC.BAT oder
sp�ter (bzw. per INSTALL= in CONFIG.SYS) zu laden. Obwohl
die Funktionalit�t identisch ist, erscheint das logische
Ger�t DPMSXXX0 nur beim Laden als Ger�tetreiber (siehe
Kapitel IV.3.). Da in lezterem Fall auch der Speicher-
bedarf geringf�gig niedriger ist, empfiehlt sich in
jedem Fall das Laden als Ger�tetreiber.
DPMS.EXE kann nicht hochgeladen werden. Sehr fr�he
Versionen (noch vor Update 3) konnten zwar hochgeladen
werden, f�hrten aber nur zum Absturz des Rechners, da
das Hochladen des Treibers schon damals nicht zul�ssig
war und nur nicht abgefangen wurde. Heutzutage alloziert
der Treiber w�hrend der Initialisierung absichtlich so
viel Speicher, da� kein Speichermanager ihn hochladen
kann...
Der Real Mode Stub des Treiber ben�tigt ca. 1 KByte (je
nach Treiberversion und geladenem Overlay 0,7 - 1,4 KByte)
im konventionellen Speicher, die sich - in Anbetracht des
enormen Speichergewinns bei DPMS-nutzenden TSRs - allemal
lohnen, geopfert zu werden.
Mit der Version 1.42 aus dem Update 14 traten auf
verschiedenen Testsystemen Probleme auf. Ich empfehle
daher entweder die Version 1.41 aus Update 13 oder die
neue Version 1.43 aus Update 15. N�heres siehe Kapitel I.2.
DPMS.EXE (zumindest die Version 1.43 aus Update 15)
unterst�tzt offenbar zwei undokumentierte Parameter,
deren Funktion noch nicht gekl�rt ist (der SwitChar ist
optional):
/N ???
/O ??? DPMS installiert nicht, scheint wie OFF zu
wirken.
/O=wert ??? Eine Wertangabe wird nicht zur�ckgewiesen,
Funktion unbekannt ('Overlay'???).
Die folgenden Parameter sind zwar offensichtlich, aber im
DOSBOOK und der Online-Hilfe nicht erw�hnt:
/OFF deaktiviert DPMS-Funktionen f�r zu ladende TSRs.
/ON reaktiviert DPMS wieder. Bereits geladene DPMS-
nutzende TSRs k�nnen nat�rlich weiterhin den
DPMS-Service nutzen.
Die Option "EMS=0" des Speichermanagers 386MAX ist nicht
DPMS-kompatibel. Stattdessen mu� man 386MAX so umkon-
figurieren, da� die NOFRAME-Option verwendet wird.
"Und was n�tzt der ganze Aufwand f�r die Programmierung
von DPMS-aware TSRs, wenn nur Novell DOS 7 diesen Standard
unterst�tzt?" - Da haben Sie sich aber get�uscht!
Bei IBM PC-DOS 7 liegt (wohl nur wegen des dort mitge-
lieferten STACKER 4) nun ebenfalls ein DPMS-Treiber bei,
der kompatibel zu Novells DPMS ist. Allerdings sollte man
auch f�r PC-DOS 7 einen aktuell upgedateten Treiber von
Novell verwenden, da dieser wesentlich kleiner ist und
besser arbeiten soll. Es sieht so aus, als ob auch PTS/DOS
(alias S/DOS) DPMS nutzen kann und auch Caldera OpenDOS
unterst�tzt DPMS.
Helix Software entwickelte ebenfalls um 1993-1994 einen
Protected Mode TSR-Server namens CLOAKING (im Deutschen
etwas ungl�ckliche Wortwahl, bedeutet allerdings soviel
wie 'Ummanteln' oder 'Tarnen') zum Auslagern ihrer
Netzwerk-Software ins Extended Memory. Der Hauptteil der
CLOAKING-nutzenden Treiber l�uft dann im Protected Mode
und nur ein kleiner Stummel (der Stub) bleibt zur Kommuni-
kation mit DOS im Real Mode Adre�raum (sowohl der Stub des
Servers als auch der der TSRs k�nnen hochgeladen werden;
bei Novells DPMS mu� der Stub des Servers im 640 KByte-
Bereich liegen). Helix entwickelte in Zusammenarbeit
mit Award auch CLOAKING-nutzende BIOSe und bietet den
CLOAKING.EXE Treiber auch f�r andere TSRs an. So unter-
st�tzt z.B. der Logitech-Maustreiber aus MouseWare 6.50+
das CLOAKING-API und ben�tigt so statt 27 KByte nur noch
1 KByte im ersten MegaByte!
"Ok, nun gibt es also zwei verschiedene Standards (DPMS und
CLOAKING) f�r denselben Zweck, TSRs aus dem DOS-Speicher
nahezu komplett auszulagern und die Vorteile des Protected
Mode nutzen zu k�nnen?!?"
Im Prinzip haben Sie Recht und es ist sicherlich aufwendig,
beide APIs in Ihren TSRs zu unterst�tzen (abgesehen davon,
da� es schon schwierig genug ist, �berhaupt erst einmal ein
DPMS-SDK zu bekommen, obwohl es nicht sehr teuer ist.
Letzteres Problem ist mit der �bernahme von DR DOS durch
Caldera nun endlich gel�st...).
Aber: Der Helix CLOAKING.EXE Treiber (getestet Version
2.01 auf 386ern bis Pentiums mit EMM386 /MULTI=on /DPMI=on;
CLOAKING funktioniert offenbar nicht mit 286ern) unter-
st�tzt undokumentiert auch das API von DPMS (meldet sich
als DPMS 1.00 OEM "HELIX")!!! Dabei wird der integrierte
DPMS-Server selbst zum CLOAKING-nutzenden Treiber und der
CLOAKING-Stub ben�tigt nach wie vor nur 1 KByte konven-
tionellen Speicher!
Wird w�hrend der Installation von CLOAKING.EXE kein DPMS-
Server erkannt, so stellt CLOAKING.EXE die DPMS-Funktionen
default-m��ig selbst zur Verf�gung. Dieser 'Cloaked DPMS-
Server' kostet nur ca. 100 Bytes im ersten MegaByte. Mit
der undokumentierten CLOAKING-Option /NODPMS kann man ver-
hindern, da� DPMS-Support eingebunden wird. Obwohl Sie
auch beide Treiber (DPMS.EXE und CLOAKING.EXE) laden
k�nnen (sollte es tats�chlich einmal Probleme geben),
reicht es deshalb normalerweise v�llig aus, nur noch den
CLOAKING.EXE Treiber zu laden. Die DPMS-nutzenden TSRs
(von Novell DOS und PC-DOS etc.) k�nnen damit genauso gut
arbeiten, wie mit ihrem Original... Das gilt insbesondere
auch bei Benutzung von MS Windows 3.xx in allen Betriebs-
arten, obwohl CLOAKING im Gegensatz zu DPMS keinen
virtuellen DPMS-Ger�tetreiber bereitstellt.
Lediglich Novells TASKMGR kommt als Multitasker an-
scheinend mit CLOAKING nicht zurecht: Sobald CLOAKING.EXE
geladen wird, st�rzt er meist ab (egal, ob DPMS aktiviert
ist oder nicht, und unabh�ngig davon, von welchem Treiber
es zur Verf�gung gestellt wird). Etwas stabiler wurde der
Multitasker ohne geladenen DPMS-Treiber und erst in
AUTOEXEC.BAT geladenem CLOAKING-Treiber (mit der Option
/NOSHAREV86). Wer hier der Schuldige ist (CLOAKING oder
TASKMGR), und ob evtl. doch noch Abhilfe in Sicht ist,
ist noch nicht gekl�rt. Hinweise willkommen!
Und in einer extrem un�blichen Konstellation bereitet auch
der PNW 1.0 SERVER.EXE manchmal Probleme, wenn er in einer
DOS-Box unter Windows geladen wird (siehe Kapitel VI.2.)
und DPMS dabei von CLOAKING zur Verf�gung gestellt wird.
L�dt man jedoch CLOAKING �ber DPMS treten diese Probleme
nicht auf. Vielleicht gibt es ja auch schon ein Update f�r
CLOAKING.EXE (Version 2.01 von 1994)?
Wird der DPMS-Support von CLOAKING bereitgestellt, sollte
man auf keinen Fall "DPMS.EXE off" eingeben, um den DPMS-
Support abzuschalten. In diesem Fall kommt Helix' DPMS-
Treiber durcheinander (schaltet evtl. wirklich komplett ab)
und DPMS-nutzende Applikationen st�rzen ab. Da dies auch
kritische Programme wie NWCACHE etc. betrifft, besteht
gro�e Gefahr f�r die Integrit�t des Dateisystems, wenn Sie
nicht sofort neu booten!
Fazit: Wenn Sie DPMS-nutzende Treiber entwickeln, unter-
st�tzen Sie automatisch beide Standards und befinden sich
keineswegs in einer Sackgasse, sondern auf der sicheren
Seite! Na, denn los...
Infos zu DPMS und CLOAKING gibt's auch in Ralf Browns
Interrupt-Liste.
DRIVER.SYS Siehe auch bei DRIVPARM= in Kapitel III.1.
EDIT.COM Dieser Editor stellt (wenn Sie nicht QEDIT oder TSE ein-
setzen) eine sehr leistungsf�hige Alternative zu vielen
anderen Editoren dar.
Die Grundkonfiguration wird der Datei NWDOS.INI �ber
%NWDOSCFG% entnommen:
Wenn nicht durch Einstellungen aus der undokumentierten
Gruppe [EDITOR] �bersteuert, werden die Einstellungen der
Default-Gruppe [COLORS] ausgewertet (Achtung: Die Gruppe
[EDITOR] wird auch von PNW 1.0 NET.EXE verwendet, siehe
Kapitel VI.9.):
NewUI=on|off Pseudografikdarstellung ein/aus
(Unterst�tzung f�r einige spezielle VGA-
Karten ist in EDIT implementiert.)
CurrentColor=
ColorSetX=
Direktiven, die jedoch (auch) in [EDITOR] vorkommen,
�bersteuern die jeweilige Einstellung aus der Gruppe
[COLORS] (ColorSetX= kann nur in [COLORS] vorkommen,
X=<CurrentColor> aus 1..9). Eine meines Erachtens
besonders angenehme Farbeinstellung f�r EDIT finden
Sie in Kapitel II.19.
Falls das 'NewUI' benutzt wird, so definiert EDIT einige
Zeichen des ASCII-Zeichensatzes um, um die pseudographische
Darstellung zu erm�glichen. Sie sollten sich also nicht
wundern, warum z.B. die Zeichen '+' (ASCII-180), '+'
(ASCII-193), '+' (ASCII-194) und '+' (ASCII-195) anders
als erwartet aussehen. Mit einigen Cirrus-VGA-Adaptern
soll es zu Problemen kommen, aber gl�cklicherweise kann
man bei Bedarf die herk�mmliche Darstellung (NewUI=Off)
mittels der Option EDIT /N w�hlen, auch ohne daf�r die
generelle Einstellung in der Konfigurationsdatei �ndern
zu m�ssen. Falls Ihnen EDIT zu langsam erscheint, k�nnen
Sie auf diese Weise auch die Geschwindigkeit steigern.
F�r die OS-Shell wird �ber %ComSpec% der zugeh�rige
Kommandoprozessor (meist COMMAND.COM) geladen, vgl.
Kapitel IV.7. Dabei wird dem Prompt �ber %Prompt% eine
'[EDIT]' Zeichenkette vorangestellt, so da� man nicht
vergi�t, da� man in einer tempor�ren Shell arbeitet.
F�r den integrierten Hilfeverweis zu DOSBOOK mu� die
Datei DOSBOOK.EXE auffindbar sein, die allerdings nur
benutzt, aber nicht direkt ausgef�hrt wird.
Die umfangreichen Editierm�glichkeiten von EDIT sollten
Sie sich nicht entgehen lassen und die entsprechende
Dokumentation wirklich durchlesen.
Innerhalb des Editors sind die �blichen WordStar-<Ctrl>-
Tastenkombinationen erlaubt. Da verschiedentlich behauptet
wurde, EDIT w�rde keine M�glichkeit besitzen, Dateien unter
einem neuen Namen zu speichern, hier die entsprechenden
Tastenkombinationen... (aber dies ist noch lange nicht
alles, was dieser Editor zu bieten hat):
<Ctrl>+<k>-<b> Blockanfang markieren.
<Ctrl>+<k>-<k> Blockende markieren.
<Ctrl>+<k>-<w> Block schreiben (fragt nach Dateiname)
Dies ist sogar als eigener Men�punkt
unter dem Men� 'Block' vorhanden!
Interessant ist, da� EDIT w�hrend des Editierens sowohl
die aktuelle Spaltenposition als auch die absolute Position
innerhalb der Datei (*Zeichen*) anzeigt, eine manchmal
wichtige Information, die selten offeriert wird (vgl.
COMP.COM und FC.COM in diesem Kapitel). Leider haben die
Entwickler dar�ber scheinbar vergessen, die aktuelle
*Zeilen*position anzuzeigen, ein Mi�stand, der hoffentlich
in einem zuk�nftigen Update noch ausgebessert wird (zu-
mindest intern ist daf�r schon beim EDITOR von DR DOS 6.0
die entsprechende Meldung *Zeile* vorbereitet).
Aus Sicherheitsgr�nden erlaubt EDIT nicht das Editieren
von Dateien mit der Endung .BAK. Diese m�ssen ggf. vorher
umbenannt werden. Ist eine bereits existierende Datei
(oder deren Sicherung mit der Endung .BAK) schreibge-
sch�tzt, so meldet EDIT direkt beim Start, da� die Datei
zwar betrachtet, nicht aber editiert werden kann.
Ggf. m�ssen Sie das Read-Only-Dateiattribut vorher
mit ATTRIB -R entfernen, oder - umgekehrt - k�nnen Sie
das Editieren von vornherein verhindern, indem Sie das
Attribut setzen.
Interessant ist auch, da� EDIT im Prinzip keine Probleme
mit gro�en Dateien (mehr als 64 KByte) hat (sollte heut-
zutage eigentlich selbstverst�ndlich sein, ist es aber
nicht, wie die Praxis immer wieder zeigt) und auch Texte
mit mehr als 255 Zeichen pro Zeile problemlos anzeigen
kann: Es wird zwar offensichtlich keine virtuelle
Speicherverwaltung eingesetzt (evtl. aber EMS), aber
solange der verf�gbare Speicherplatz auf dem Tempor�r-
laufwerk (das �ber %Temp% referenziert wird) f�r zwei
tempor�re Dateien namens ED??????.$$$ ausreicht, gibt
es wohl keine Grenze (evtl. wurde bei DR DOS 6.0 EDITOR
zus�tzlich auch noch eine Datei EDCONFIG.$$$ erzeugt).
Jedenfalls konnte ich mehrere MByte gro�e Dateien
editieren, die sogar Zeilen mit mehr als 1024 Zeichen
enthielten. Erst wenn der Platz auf dem Tempor�rlaufwerk
nicht f�r die komplette Datei ausreicht, wird EDIT unge-
m�tlich: Wenn man beim Editieren an die entsprechende
Grenze st��t, erscheint dauernd die Meldung 'Diskette/
Platte voll' und auch das r�ckw�rtige Editieren ist nicht
mehr einwandfrei m�glich (in manchen F�llen wird sogar die
Mausunterst�tzung deaktiviert). Wenn Sie Sinn f�r Humor
haben, versuchen Sie einfach einmal, eine solche Datei mit
EDIT von MS-DOS bis einschlie�lich 6.22 zu laden...
In diesem Zusammenhang gibt es auch einen schweren Bug in
EDIT (getestet bis zum Update 15 von Dezember 1996, mit
dem Update 15 von Januar 1996 konnte ich das Verhalten
bisher nicht mehr reproduzieren):
Wenn man eine ge�nderte Datei zur�ckschreiben will,
bekommt die alte Datei zun�chst die Endung .BAK, danach
wird die neue Datei zur�ckgeschrieben. (Eine bereits
existierende .BAK-Datei wird zun�chst gel�scht, daher
k�nnen mit DELWATCH /B:nnn auch mehrere Versionen der
Dateien in der L�schverfolgung gehalten werden).
Dies funktioniert normalerweise wunderbar, auch bei
riesigen Dateien. Reicht allerdings der Platz auf dem
Laufwerk nicht mehr aus, um die alte *und* die neue Datei
gleichzeitig aufzunehmen, wird die neue Datei nur soweit
zur�ckgeschrieben, wie der Platz daf�r reicht (evtl. h�ngt
das Auftreten des Fehlers zus�tzlich noch davon ab, wo
das Tempor�rlaufwerk liegt und wo in der Datei editiert
wurde???)!
Da keine Fehlermeldung erscheint, geht man normalerweise
davon aus, da� alles sauber funktioniert hat. In Wirklich-
keit ist die Datei aber abgeschnitten (und die �nderungen
sind u.U. verloren). Solange man dies rechtzeitig bemerkt,
ist der Schaden noch ertr�glich. L�dt man die Datei aber
erneut und speichert sie wieder ab, wird die alte Original-
datei (jetzt .BAK) mit der neuen .BAK-Datei �berschrieben
und damit ist ein Gro�teil der Arbeit unwiederbringlich
verloren!!! Deshalb: Bis dieser Bug behoben wurde, sollten
Sie unbedingt darauf achten, da� genug freier Platz auf dem
Laufwerk vorhanden ist. U.U. k�nnen Sie unter Zuhilfenahme
von Wordstar-Codes auch darauf ausweichen, die Datei auf
ein anderes Laufwerk zu schreiben, aber prinzipiell wird
die Datei auch hier abgeschnitten, wenn der Platz nicht
mehr reicht!!! Als partielles Workaround kann man einen
Batchjob schreiben, der vor dem Aufruf von EDIT den zur
Verf�gung stehenden Platz auf dem Laufwerk �berpr�ft und
nach der Beendigung von EDIT ein DIR ausf�hrt, mit dem
man nach dem Editieren schnell die Dateigr��en vergleichen
kann (um wenigstens die .BAK-Datei zu retten), etwa:
EDIT.BAT:
@ ECHO off > \dev\nul
REM Rudiment�res Workaround f�r Novells EDIT Bug
REM Eine zu editierende Datei mu� im aktuellen Ver-
REM zeichnis liegen und beim Aufruf von EDIT mit
REM angegeben werden. Andere Optionen m�ssen nach
REM dem Dateinamen angegeben werden.
REM 96-11-24 -mp
IF NOT "NWDOS"=="%Os%" GOTO start
IF ""=="%1" GOTO start
@ FOR %%x IN (/h /H -h -H .) DO IF "%%x"=="%1" GOTO help
IF "/?"=="%1" GOTO help
IF "-?"=="%1" GOTO help
@ XCOPY %1 ed$$$$$$.tmp /f > \dev\nul
IF ERRORLEVEL 1 GOTO error
@ IF EXIST ed$$$$$$.tmp DEL ed$$$$$$.tmp > \dev\nul
GOTO start
:help
@ EDIT.COM %1 %2 %3 %4 %5 %6 %7 %8 %9
GOTO end
:error
IF EXIST ed$$$$$$.tmp DEL ed$$$$$$.tmp > \dev\nul
ECHO Novells EDIT hat eine Bug, der zum Verlust ...
... Ihrer Originaldatei f�hren k�nnte!
PAUSE Sie k�nnen jetzt mit Ctrl+C abbrechen oder ...
... mit beliebiger Taste fortsetzen...
:start
@ EDIT.COM %1 %2 %3 %4 %5 %6 %7 %8 %9
IF ERRORLEVEL 1 ECHO Ein Fehler ist aufgetreten!
DIR *.*
:end
Update 14 (EDIT 2.01) enth�lt Fixes f�r das Wildcard-
Management in Dateiauswahlmasken (speziell die Ausgabe
von Unterverzeichnissen war betroffen).
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok
3 Benutzerabbruch (<Ctrl>+<c> etc.)
4 Syntax-Fehler
FASTOPEN.COM Dummy-Befehl, siehe Kapitel III.1. bei FASTOPEN=.
FBX.EXE Benutzt eine eigene Konfigurationsdatei FASTBACK.CFG
(Vorlage in DEFAULT.CFG) in %NWDOSCFG%, weicht also
von den sonst bei Novell DOS 7 �blichen .INI-Dateien ab.
Au�erdem werden im c:\nwdos\ Verzeichnis Benutzer-
konfigurationen als .FB (DEFAULT.FB) abgelegt.
(DEFAULT.FB wird offenbar bei jedem Start als Makro
abgearbeitet.)
Beim Customizing von FastBackup f�r Novell DOS ist die
M�glichkeit entfernt worden, echte Makrodateien abzu-
speichern. Nichtsdestotrotz kann FBX FB-Makrodateien mit
der Endung .FB oder .FBM abarbeiten, wenn man diese als
Aufrufparameter angibt. Hinweise dazu kann man dem bei
Novell DOS beiliegenden HWTEST.FBM entnehmen, das einen
Hardware-Test des DMA-Controllers durchf�hrt, f�r den
man eine leere Diskette ben�tigt. Das Resultat dieses
Tests wird offenbar teilweise auch in die .FB-Datei
�bertragen, die �ber %FBP_User% referenziert wird.
Genaueres ist allerdings noch nicht untersucht.
In jedem Fall k�nnen Sie in diesen Dateien Eintr�ge wie
DMASpeed("Niedrig")
DMAXMSDisable("Aus")
per Hand dem Ergebnis des Tests anpassen. M�gliche Werte
sind "Niedrig", "Mittel" oder "Hoch", bzw. "Aus" oder
"Ein". Auf diese Weise k�nnen Sie aus Ihrem Rechner die
optimale Leistung herausholen.
(F�r Besitzer einer externen Fast-Backup Express Version:
bez�glich der vielf�ltigen Anpassungsm�glichkeiten via
Makrodateien siehe diesbez�gliche Anleitung).
FBX unterst�tzt sowohl in der DOS- als auch der Windows-
Version auch einige Diskettensonderformate (wie 400 KByte,
800 KByte oder 1,28 MByte (bei 5,25") oder 800 KByte,
1,52 MByte oder Macintosh HFS 1,44 MByte (bei 3,5"),
siehe auch Kapitel III.1. bei DRIVPARM=). Der Treiber
FASTBACK.386 wird nur f�r Backup/Restore auf lokalen
Floppies in Windows' Erweiterten 386er Modus ben�tigt
(siehe Kapitel VIII.1.). Der Treiber kann auch unter dem
multitaskenden TASKMGR geladen werden, ob dies aber
notwendig ist, ist nicht gekl�rt (siehe Kapitel VII.2.).
FC.COM FC verwendet die Dateiendung als Kennzeichen f�r den
Dateityp und entscheidet daraufhin, ob default-m��ig ein
Bin�r- oder ASCII-Vergleich durchgef�hrt werden soll.
FC vergleicht folgende Dateitypen standardm��ig bin�r:
.EXE, .COM, .SYS, .OBJ, .BIN und .LIB. Allerdings wird
im Gegensatz zu MS-DOS FC zus�tzlich auch .CMD bin�r
verglichen (dies wird in der FC /? Hilfe unterschlagen).
.CMD ist unter CP/M und Multiuser DOS eine Endung f�r
ausf�hrbare Dateien, ist aber auch eine g�ltige Endung
f�r Klarschrift-Skripte unter OS/2.
Bei Bin�rvergleichen werden Unterschiede als absolute
Positionsangaben ausgegeben, eine Angabe die man u.U.
f�r Novells EDIT benutzen kann, um die Fundstelle schnell
zu lokalisieren (obwohl EDIT f�r echte Bin�rdateien
eigentlich nicht geeignet ist), siehe bei EDIT.COM in
diesem Kapitel.
Die Kommandozeilen-Syntax unterst�tzt auch zusammengefa�te
Parameter, wie /NP statt /N /P. Parameter mit Zahlenangaben
m�ssen in diesem Fall allerdings hinten stehen, denn sonst
k�nnte es zu Doppeldeutigkeiten kommen.
FC bietet neben den dokumentierten Parametern noch zwei
weitere undokumentierte Parameter f�r ASCII-Vergleiche:
/G:n Aus Kompatibilit�t zu DR DOS: Zeilenanzahl, die
vor einer Synchronisation �bereinstimmen mu�.
Der Standard war bei DR DOS 6.0 noch 5, aber da
Novells FC aus Kompatibilit�tsgr�nden an die
ansonsten identische, erst sp�ter bei MS-DOS
eingef�hrte Option /n (d.h. einfach nur die Zahl n)
angepa�t wurde, und dort der Standard auf 2 ein-
gestellt ist, d�rfte dies auch hier gelten.
Der Doppelpunkt ist optional. Die Angabe /G ohne
Zahl wird zur�ckgewiesen.
/LB:n Aus Kompatibilit�t zu MS-DOS: Gibt die Anzahl
der Zeilen des internen Puffers an, die f�r
die Synchronisation bereitgestellt werden. Der
Default-Wert ist bei MS-DOS/PC-DOS/DR DOS und
wohl auch Novell DOS 7 100 Zeilen.
Da /LB:n nur bei ASCII-Vergleich verwendet wird,
gibt es auch keine Doppeldeutigkeiten mit dem
Parameter /B, wenn mehrere Parameter zusammen-
gefa�t werden.
Leider ist die maximale Zeilenl�nge bei ASCII-Vergleichen
auf 255 Zeichen beschr�nkt (getestet mit Update 15), in
diesem Punkt kann MS-DOS' FC ausnahmsweise einmal mehr...
CCI Multiuser DOS 7.22 Gold kennt FC.COM immer noch
nicht, dort wird diese Funktion aber weitestgehend von
einer um entsprechende Funktionen erweiterten Fassung
von COMP.COM �bernommen.
Errorlevel (unvollst�ndig):
(nur f�r Novell DOS 7 verifiziert!)
0 normaler Ablauf, egal ob Dateien gleich oder ungleich
sind, oder Hilfeschirm
1 Datei(en) nicht gefunden oder falsche Aufruf-Syntax
3 Benutzerabbruch (<Ctrl>+<c> etc.)
FDISK.COM Im Gegensatz zum entsprechenden MS-DOS Kommando arbeitet
Novells FDISK (als auch das DR DOS FDISK) nicht nur als
Festplattenpartitionierer, sondern formatiert die Parti-
tionen auch gleich, so da� man sich FORMAT (/X bei
Novell DOS) sparen kann.
Die undokumentierte Option /MBR (und andere, siehe
MSDOSTIP.TXT) von MS-DOS bietet Novells FDISK nicht
(offenbar aber einige Fassungen von CCI Multiuser DOS),
daf�r ist aber seit DR DOS 6.0 genau diese Funktion direkt
aus dem FDISK-Men� heraus erreichbar (Master-Ladesatz
schreiben). Dabei wird (bei Novell DOS) der alte Boot-
Sektor in einer (versteckten) Datei namens C:\OLDMBR.BIN
gesichert und kann auch wieder zur�ckgeschrieben werden,
solange man diese Datei nicht l�scht.
Hilfreich ist diese Funktion bei Virenbefall (siehe Kapitel
II.4 bei SDRES) oder zum Initialisieren einer nagelneuen
Festplatte, die partout nicht booten will (auch nicht bei
Floppy-Boots, siehe Kapitel II.2.).
Au�erdem kann man das Ganze nat�rlich auch andersherum
verwenden, um einen speziell pr�parierten Master-Ladesatz
auf die Festplatte zur�ckzuschreiben, ohne sich die Finger
mit DEBUG etc. schmutzig machen zu m�ssen.
Achtung: Da es hier immer wieder Verwechselungen gibt:
Der Master-Boot-Record (MBR) ist nicht dasselbe wie der
Boot-Record (jeden Laufwerks), der z.B. mit SYS geschrieben
wird (siehe bei SYS.COM in Kapitel II.4.). Wird ein neuer
MBR geschrieben, werden auch Boot-Manager wie Linux' LILO,
der OS/2 Boot-Manager oder der PTS/Boot-Manager abgeh�ngt
und m�ssen wieder neu installiert werden. Das gleiche gilt
offenbar auch f�r MS Windows95. Eine Boot-Diskette mit den
notwendigen Tools sollte also vorhanden sein!
Es gibt seit DR DOS 3.41 einen bei Novell DOS 7 aus-
schlie�lich im DOSBOOK dokumentierten Parameter /D, der
beim Aufruf von FDISK angegeben werden mu�, um auch das
L�schen von Nicht-DOS-Partitionen innerhalb des Men�s zu
erlauben (Die Vorgehensweise ist identisch zum L�schen
einer DOS-Partition). Normalerweise ben�tigt man zum
L�schen von Nicht-DOS-Partitionen das entsprechende
Programm des jeweiligen Betriebssystems (sollte man
sicherheitshalber auch verwenden, falls m�glich). Ob
dieser Parameter allerdings wirklich noch existiert,
ist noch nicht genau gekl�rt (hab's einfach noch nicht
selbst gebraucht... DR DOS 6.0 FDISK hatte diese Funktion
allerdings mit Sicherheit noch.).
Ein paar generelle Hinweise zur Partitionierung von
Festplatten (gleicherma�en auch f�r MS-DOS etc. g�ltig):
M�chten Sie - als Programmierer - Ihre Programme unter
einer alten DOS-Version (vor 4.0) �berpr�fen, m�ssen Sie
alle daf�r notwendigen Dateien auf der ersten Partition
der ersten Festplatte unterbringen. Diese Partition darf
nicht gr��er als 32 MByte sein, weil �ltere DOS-Versionen
Partitionen nur bis zu dieser Gr��e handhaben k�nnen
("FAT12").
F�r heutige Rechner existiert eine �hnliche Beschr�nkung
bei einer Partitionsgr��e von 504 MByte (aber nicht ver-
ursacht durch DOS, das mit seiner "FAT16" bis zu zwei
GigaByte gro�e Partitionen verwalten kann). Selbst wenn
Sie diese Gr��e nur minimal �berschreiten, werden Sie -
ohne zus�tzliche Treiber oder ein entsprechendes BIOS -
nicht einwandfrei auf eine solche Partition zugreifen
k�nnen (Vor DR DOS 6.0 Update 1992 kamen noch nicht ein-
mal FDISK mit gr��eren Partitionen sauber zurecht).
Novell DOS 7 gibt hier recht aussagekr�ftige Meldungen,
bei MS-DOS kann es aber vorkommen, da� alles scheinbar
anstandslos funktioniert, Sie aber sp�ter permanent
unerkl�rliche Probleme beim Zugriff auf diese Platte
haben (Bad-Sectors etc.). Wenn Sie den Speicher f�r
einen speziellen Treiber sparen wollen oder von mehreren
Betriebssystemen aus auf die Partition zugreifen wollen,
sollten Sie in jedem Fall unter dieser Schranke bleiben.
Ohne hier ins Detail gehen zu wollen, sollten Sie sich
genau �berlegen, wieviele Partitionen Sie einrichten
wollen. In der Regel ist die Wartung eines Systems
leichter, wenn Sie handliche Partitionsgr��en einstellen,
die z.B. noch jeweils komplett auf ein Streamer-Band
passen. Gerne werden runde MByte-Zahlen als Partitions-
gr��en gew�hlt. Man mu� sich dann aber klar machen, da�
im FAT-Dateisystem gr��ere Partitionen auch gr��ere
Cluster-Einheiten vorschreiben. Gr��ere Cluster (d.h.
mehrere zusammenh�ngend adressierte Sektoren auf der
Platte) haben den Vorteil des schnelleren Zugriffs (bei
Dateien, die wesentlich gr��er sind als die Cluster-Gr��e),
aber den Nachteil des gro�en Verschnitts bei Dateien, die
kleiner sind.
Betr�gt die Cluster-Gr��e z.B. 8 KByte, so werden auf der
Festplatte auch f�r eine nur ein Byte (als auch f�r eine
8 KByte) gro�e Datei 8 KByte belegt, f�r eine 8 KByte +
1 Byte (8097 Bytes) gro�e Datei direkt 16 KByte, usw.
Der �berhang betr�gt im Mittel also 4 KByte pro Datei!
Haben Sie also auf einem Laufwerk haupts�chlich viele
kleine Dateien, so sollten Sie die Cluster-Gr��e auch
m�glichst klein halten, also eine eher kleine Partition
einrichten. Umgekehrt ist f�r eher wenige, daf�r aber
sehr gro�e Dateien eine h�here Cluster-Gr��e wegen der
h�heren Zugriffsgeschwindigkeit von Vorteil. Dies gilt
in besonderem Ma�e f�r Laufwerke, auf denen solche
Riesendateien wie die Windows-Auslagerungsdatei oder
- als Host-Laufwerke - die Volume-Dateien eines kompri-
mierten Laufwerks liegen (komprimierte Laufwerke ver-
wenden intern meist eine dynamische Clusterisierung,
d.h. sie sind f�r die Speicherung vieler kleiner Dateien
besonders effizient). U.U. ist es also m�glich, da� Sie
effektiv *mehr* Dateien (und Daten) auf eine etwas
*kleinere* Partition bekommen, als auf eine etwas
gr��ere Partition, die daf�r aber eine gr��ere
Cluster-Gr��e aufweist. Besonders an den Grenzwerten
zwischen verschiedenen Cluster-Gr��en sollten Sie also
bewu�t eine etwas kleinere oder gr��ere Partitions-
gr��e w�hlen (wobei ich normalerweise eine ganz knapp
unter dem n�chsten Sprung der Cluster-Gr��e liegende
Partitionsgr��e bevorzuge).
Normalerweise gilt folgende Zuordnung, wobei teilweise ein
gewisser Spielraum besteht, der aber von den DOS-eigenen
Programmen nicht ausgew�hlt werden kann.
Partitionsgr��e FAT-Gr��e Sektoren/Cluster Cluster-Gr��e
------------------ --------- ---------------- -------------
bis 15,9 MByte 12 Bit 8 4 KByte
16 - 127,9 MByte 16 Bit 4 2 KByte
128 - 255,9 MByte 16 Bit 8 4 KByte
256 - 511,9 MByte 16 Bit 16 8 KByte
512 - 1023,9 MByte 16 Bit 32 16 KByte
1024 - 2047,9 MByte 16 Bit 64 32 KByte
In obigem Beispiel w�re �blicherweise eine Partitionsgr��e
von 255,9 MByte einer Partition von 256 MByte vorzuziehen,
weil Sie dort im Schnitt einige MegaByte mehr Daten unter-
bringen k�nnen (so paradox es auf den ersten Blick klingt)!
Die Konsequenzen einer falschen Wahl k�nnen Sie sich anhand
obiger Tabelle leicht selbst ausmalen (von 100% Ausnutzung
der Plattenkapazit�t im optimalen Fall bis hin zu 99,9%
Verschwendung im Worst-Case ist alles m�glich...)
Unter diesem Gesichtspunkt ist �brigens die Einrichtung von
komprimierten Laufwerken oft selbst dann von Vorteil, wenn
die auf dem Laufwerk gespeicherten Daten nur wenig kom-
primiert werden k�nnen.
Die maximal zul�ssige Partitionsgr��e ist bei Novells
FDISK offiziell ein GigaByte, die maximal handhabbare
Laufwerksgr��e betr�gt zwei GigaByte. Da aber DR DOS 6.0
schon offiziell Partitionsgr��en bis zwei GigaByte unter-
st�tzte, vermute ich, da� auch Novell DOS 7 damit zurecht
kommt. Meine eigenen Versuche, solche Partitionen einzu-
richten und mit NWCACHE zu cachen, best�tigen dies. Sollte
es also tats�chlich ein diesbez�gliches Problem gegeben
haben, so ist es entweder l�ngst gel�st oder es h�ngt von
veralteten Rechner-BIOSes oder Festplatten-Technologien ab.
Allerdings sollte man bei Verwendung noch gr��erer Fest-
platten der automatischen Gr��enbeschr�nkung auf 2 GByte
nicht trauen: Ein kleiner Bug in FDISK sorgt daf�r, da�
die Partition geringf�gig zu gro� angelegt wird, was zur
Folge hat, da� sie sich unter DOS nicht ansprechen l��t:
Die unter Novell DOS formatierte Partition war exakt
2.146.762.752 Bytes gro�, unter MS-DOS ergaben sich
2.146.631.680 Bytes, als exakt 128 KByte kleiner. Eventuell
versucht sich Novells FDISK hier in 64 KByte-Clustern, die
aber nur von MS Windows/NT unterst�tzt werden, und MS-DOS
CHKDSK zu einem "Division durch Null"-Fehler, Novells
CHKDSK lediglich zu falschen Angaben verleiten...).
Gibt man manuell die richtige Kapazit�t an und bleibt
dabei unter dieser Grenze, tritt das Problem nicht auf.
Auch MS-DOS/PC-DOS (bis 7) schaffen eine maximale
Partitionsgr��e von zwei GigaByte. (Mit MS Windows95b,
dem Update 2 zu MS Windows95 (Ende 1996) wurde ein neues
FAT32-Modell eingef�hrt werden, das unter Einb��ung der
Kompatibilit�t diese Systemgrenze des FAT16-Modells l�st.)
Novells FDISK arbeitet nicht nur mit Novell DOS 7
(IBMBIO.COM, IBMDOS.COM), sondern unterst�tzt in irgend-
einer Weise auch eine Reihe der alten Digital Research
Betriebssysteme (CCPM.SYS, DOSPLUS.SYS, NETPLUS.SYS,
CCPMNET.SYS, CPCDOS.SYS, CDOS.SYS, DOS.SYS, DRDOS.SYS,
FLEX286.SYS, FLEX386.SYS). Dazu �berpr�ft FDISK auf
Multiuser-F�higkeiten des Betriebssystems und verwendet
bei Bedarf sogar eine Reihe der alten CP/M-86 System-
aufrufe. Anscheinend gibt es eine M�glichkeit, eine
diesbez�gliche Auswahl zu treffen (bisher aber noch
unbekannt, vielleicht in Verbindung mit /D).
Auch OS/2-, NetWare- und Unix-Partitionen werden erkannt,
im Zweifelsfall wird die ID ausgegeben (bei MS-DOS FDISK
lediglich lapidar Nicht-DOS, obwohl offenbar intern auch
andere Typen erkannt werden k�nnen???).
Men�bedienung: Das Men� kann man mit <Esc> verlassen.
Achtung: Je nach Situation �ndert sich die Durch-
nummerierung der einzelnen Men�punkte, deshalb sollte
man sich vor jedem Tastendruck immer erst versichern,
da� man die richtige Ziffer dr�ckt. Die Folgen einer
Fehlbedienung w�ren katastrophal!!! Die Men�f�hrung
ist etwas anders als beim Gegenst�ck von MS-DOS,
meiner Meinung nach allerdings sinnvoller.
Update 15 (FDISK 1.76) enth�lt eine �nderung, die daf�r
sorgt, da� die landes�bergreifende Angabe von Ja/Nein-
Zeichen �ber Eingabeumleitung vereinfacht wird, indem
ab sofort alle anderen Zeichen als die Ja/Nein-Zeichen
zur�ckgewiesen werden (siehe auch Kapitel II.16.). Auf
diese Weise ist es z.B. f�r PC-H�ndler besonders einfach,
eine Festplatte automatisch ohne Interaktion einzurichten.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 normale Bearbeitung
3 Benutzerabbruch (<Ctrl>+<c> etc.)
FILELINK.EXE Um das Kommando FILELINK SLAVE abzubrechen, kann man kurz
<Ctrl>+<c> dr�cken. Nach einiger Zeit stoppt FILELINK dann.
Achtung: Wenn der Tastaturpuffer �berl�uft, kann das zum
H�ngen des Rechners f�hren (evtl. mit Update 13 behoben).
Alle Langformen der Aufrufparameter k�nnen auch als drei-
buchstabige Abk�rzungen geschrieben werden:
DIRECTORY : DIR
DUPLICATE : DUP
RECIEVE : REC
TRANSMIT : TRA
SETUP : SET
SLAVE : SLA
QUIT : QUI
GETFL??
FLDUP??
Holt seine Konfigurationseinstellungen aus zwei unter-
schiedlichen Konfigurationsdateien:
NWDOS.INI in %NWDOSCFG%:
Die Direktiven aus [FILELINK] (hier undokumentiert) oder
aus [COLORS] steuern die Bildschirmdarstellung:
CurrentColor=
NewUI=on|off
Au�erdem wird die Einstellung ColorSetX= aus [COLORS]
ausgewertet (X=<CurrentColor> aus 1..9).
FILELINK.CFG in %NWDOSCFG% (undokumentiert):
Enth�lt in der ersten Zeile die Hardware-Einstellungen wie
COMx:baudrate<ASCII-13> mit x =1..2
baudrate=115200, 57600, 38400,
19200, 9600, 4800,
2400, 1200, 600, 300,
150, 110.
LPTy<ASCII-13> y =1..3
Bemerkung:
Wenn man diese Konfigurationsdatei per Hand modifiziert,
sind auch andere Werte f�r COMx und LPTy m�glich, etwa
COM6 oder LPT4. FILELINK scheint diese Werte dann auch
zu akzeptieren, bekommt aber evtl. Schwierigkeiten beim
Hardware-Zugriff. Deshalb mu� man diese Einstellungen
auch �berpr�fen, wenn man vorher verwendete Schnitt-
stellen aus seinem Rechner entfernt hat.
M�chte man pa�wortgesch�tzte Dateien �bertragen, so
fragt FILELINK nach dem Pa�wort. Am Ziel ist die Datei
nicht mehr pa�wortgesch�tzt, hat aber nach wie vor das
Hidden-Attribut gesetzt. Das Kopieren von Dateien in
pa�wortgesch�tzten Verzeichnissen ist auch m�glich,
wenn man *vorher* in dieses Verzeichnis verzweigt (siehe
Kapitel II.4. bei PASSWORD und Kapitel II.9.).
Update 13 (FILELINK 3.01) enth�lt ein Bugfix f�r unmoti-
vierte Systemh�nger und Verzeichnisse mit mehr als 1000
Eintr�gen.
FIND.EXE Kommt auch mit Dateien gr��er 63 KByte problemlos zurecht
(was f�r einige MS-DOS/PC-DOS Implementierungen ein
echtes Problem darstellt).
Normalerweise wird der Suchtext bei FIND in doppelte
Anf�hrungszeichen eingerahmt, um ihn sicher von den rest-
lichen Parametern zu unterscheiden. Solange dadurch keine
Doppeldeutigkeiten auftreten, sind diese Anf�hrungszeichen
jedoch optional, d.h. in erster Linie dann, wenn der Such-
text keine Leerfelder enth�lt und als erster Parameter
angegeben wird.
FIND durchsucht beliebige Dateien, allerdings wird die
Suche in Bin�rdateien bei einem ^Z (altes Dateiendezeichen)
in der Dateien abgebrochen.
Interessant ist auch, da� FIND es standardm��ig nicht
sehr genau mit der Umwandlung von Gro�- und Kleinschreibung
nimmt. Der genaue Mechanismus dahinter ist noch nicht ganz
klar, aber ein Treffer kann auch dann erfolgen, wenn der
Suchtext nicht nur in Gro�- oder Kleinschrift vom ge-
fundenen Text abweicht, sondern auch, wenn er 'nicht
n�her zuzuordnende' Sonderzeichen enth�lt, d.h. im
Zweifelsfall findet FIND mehr Treffer, als eigentlich
vorhanden. Eine manchmal sicherlich praktische Eigenart.
Bez�glich der sicheren Verwendung in Batchjobs siehe
Kapitel IV.6.
Errorlevel (unvollst�ndig):
(nur f�r Novell DOS 7 verifiziert):
0 normale Bearbeitung
bei MS-DOS 6.2: Muster mindestens einmal gefunden
bei Novell DOS auch: keine Dateien zu durchsuchen
1 nur MS-DOS: normale Bearbeitung, aber Muster nicht
gefunden
2 nur MS-DOS: Falsche Parameter
31 Benutzerabbruch (<Ctrl>+<c> etc.), falsche Parameter
oder kein Suchtext (Novell DOS 7)
FORMAT.COM Der Parameter /F:format erlaubt die Formatangabe in vielen
Schreibweisen, die gr��tenteils nicht dokumentiert sind:
5,25 3,5
2880KB, 2880K, 2880, 288, 2.88MB, 2.88M, 2.88 - x
1440KB, 1440K, 1440, 144, 1.44MB, 1.44M, 1.44 - x
1230KB, 1230K, 1230, 123, 1.23MB, 1.23M, 1.23 (1) x -
1220KB, 1220K, 1220, 122, 1.22MB, 1.22M, 1.22 (2) x -
1200KB, 1200K, 1200, 120, 1.2MB , 1.2M , 1.2 (3) x -
720KB, 720K, 720 - x
640KB, 640K, 640 (4) x -
360KB, 360K, 360 x -
320KB, 320K, 320 x -
180KB, 180K, 180 x -
160KB, 160K, 160 x -
(1) und (4) undokumentierte Formate f�r 5.25 Zoll
Diskettenlaufwerke, unterst�tzt von Novells
FORMAT
(2) und (3) andere Schreibweise f�hren zu leichten
Differenzen in der Kapazit�ts*angabe*, nicht
jedoch in der Kapazit�t
�brigens: Wenn Sie '�berformatierte' Disketten (FDFORMAT,
2M, VGACOPY, etc.) benutzen, m�ssen Sie normalerweise eine
'Lesehilfe' wie VGAREAD.EXE oder FDREAD w�hrend des Bootens
einbinden, um transparent auf diese Disketten zugreifen zu
k�nnen.
Offenbar kann Novell DOS zumindest einige dieser Sonder-
formate auch ohne diese zus�tzlichen TSRs lesen und
schreiben. Am besten ist es, Sie probieren einfach
einmal aus was passiert, wenn Sie Ihren Treiber weglassen
(und berichten mir dann das Resultat...?). (Zumindest auf
1,77 MByte formatierte 1,44 MByte Floppies funktionierten
bei mir ohne zus�tzliche Treiber, genaueres habe ich
allerdings noch nicht untersucht.
Novells FORMAT ist auch in der Lage, (einige) solche �ber-
formate zu formatieren, wenn Sie die Parameter /N:sectors
und /T:tracks angeben. Eine Auflistung g�ngiger Sonder-
formate findet sich bei DRIVPARM= in Kapitel III.1.)
Neben den dokumentierten Parametern existiert bei
Novell DOS 7 noch ein undokumentierter Parameter /QUIET,
der alle Meldungen unterdr�ckt und FORMAT automatisch
ablaufen l��t. Offenbar war dieser Parameter u.a. f�r
Utilities wie BACKUP.COM gedacht, wird aber dort nicht
verwendet. /QUIET mu� als letzter Parameter angegeben
werden, denn alle Parameter nach /QUIET werden ignoriert.
Den Parameter /C (Check Bad) von MS-DOS 6.22 FORMAT bietet
Novells FORMAT nicht, ebenso fehlen alle undokumentierten
MS-DOS 4.00+ Parameter: /AUTOTEST, /BACKUP, /SELECT (aber
genau f�r diese Zwecke l��t sich Novells Parameter /QUIET
gut verwenden, siehe auch MSDOSTIP.TXT). Um nur die Frage
nach dem Volume-Namen zu unterdr�cken, geben Sie bei
Novell DOS einfach den Parameter /V ohne Wert an.
FORMAT kann nicht auf Netzlaufwerke und per ASSIGN, SUBST
oder JOIN umgeleitete Laufwerke angewendet werden.
Die Option /B ist bei Novell DOS 7 undokumentiert, da seit
langem (wohl ab DR DOS 3.41+, sicher aber DR DOS 5.0+)
�berfl�ssig. Dennoch ist sie in vollem Umfang funktions-
f�hig. Sie diente fr�her (und dient teilweise selbst noch
bei MS-DOS 6.22 und PC-DOS 7) dazu, Platz f�r die System-
dateien auf dem Medium zu reservieren (zum sp�teren
'SYS'en' alter DOS-Versionen). Da bei Novell DOS die
Systemdateien aber an beliebiger physikalischer Stelle
auf dem Medium liegen k�nnen, ist dies nicht mehr not-
wendig. Bei MS-DOS 6.0+ wurde die Beschr�nkung bei Floppies
aufgehoben, bei Festplatten gilt sie aber offenbar in
einigen F�llen immer noch, obwohl deren Dokumentation das
Gegenteil behauptet (die Dateien m�ssen zwar nicht mehr
direkt aufeinander folgen, aber einige Regionen in den
Systemdateien d�rfen nicht fragmentiert auf dem Medium
gespeichert werden). Allerdings bewirkt diese Option auch,
da� die Floppy zwar mit 9 Sektoren formatiert wird, davon
aber nur 8 verwendet werden (nur bei 5,25" Laufwerken).
Aus Sicherheitsgr�nden (und weil diese Funktion bei DR DOS/
Novell DOS schon in FDISK enthalten ist), kann man Fest-
platten nur formatieren, wenn man zus�tzlich /X angibt.
Wird daraufhin ein Schnell-Format angewendet, sollte man
die Formatierung - zumindest unmittelbar danach - mit
UNFORMAT.EXE wieder r�ckg�ngig machen k�nnen, sofern
gen�gend freier Platz auf dem Laufwerk vorhanden war, um
die Informationen abzulegen (wohl in einem Block namens
UNFORMATDR, der die Kennung JS10 enth�lt). Mal ehrlich,
wem ist es noch nicht passiert, versehentlich die falsche
Festplatte zu formatieren...? ;-)
Sollte UNFORMAT trotzdem nicht funktionieren, Ruhe
bewahren und bei UNFORMAT.EXE weiterlesen.
FORMAT /S �bertr�gt die Systemdateien (IBMBIO.COM,
IBMDOS.COM und wohl auch STACKER.BIN) auf das formatierte
Medium, dabei wird allerdings MS-DOS DBLSPACE.BIN/
DRVSPACE.BIN nicht ber�cksichtigt, mu� also ggf. nach-
tr�glich umkopiert werden. Zus�tzlich wird wohl auch
DRMDOS.SYS f�r DR DOS Multiuser-Varianten unterst�tzt.
Boot-Sektoren k�nnen wohl vom Typ "NWDOS 7.0" oder
"OSLOADER" sein (k�nnte was mit Novells Multi-Boot-
Utility LOADER.ZIP zu tun haben???). FORMAT /S �bernimmt
den Datumsstempel der Originalsystemdateien (bei DR DOS
wird - bis auf DR DOS 6.0 Updates nach 1992 - das aktuelle
Datum verwendet).
FORMAT /U wird zum Formatieren eines Mediums ohne Restau-
rationsm�glichkeit verwendet und ist damit auch besonders
f�r ATA-Cards (PCMCIA) und - in Verbindung mit den Optionen
/T:tracks /N:sectors - f�r SRAM-Cards (PCMCIA) verwendbar.
Eine �bersicht �ber die Hardware-Parameter f�r be-
stimmte Diskettenformate finden Sie in Kapitel III.1.
bei DRIVPARM=.
Update 13 (FORMAT 2.06) enth�lt eine verbesserte Version,
die nur noch dann formatiert, wenn dies unbedingt notwendig
ist.
Errorlevel (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 4.0+, Novell DOS 7 und
DR DOS 6.0)
0 normales Ende
3 Benutzerabbruch durch <Ctrl>+<c> etc.
4 Fataler Fehler (Datentr�ger, falscher Name)
5 Antwort 'Nein' auf Frage, ob Festplatte formatiert
werden soll
GRAFTABL.COM Entgegen vielen anderslautenden Meldungen in der Literatur
wird dieser Treiber nur f�r CGA-Karten und - mit ent-
sprechender zus�tzlicher BIOS-Unterst�tzung durch einen
Spezialtreiber - f�r HGC-Karten ben�tigt, wenn auch im
Grafikmodus die ASCII-Zeichen 128 bis 255 dargestellt
werden sollen. (Oft wird behauptet, GRAFTABL w�re auch
f�r den Textmodus und/oder auf neueren Grafikkarten not-
wendig. Dies ist jedoch nicht der Fall, obwohl man GRAFTABL
in speziellen F�llen zweckentfremden k�nnte...)
Da die Bitmaps der Zeichen 128 bis 255 je nach gew�nschter
Codeseite variieren, mu� GRAFTABL mehrere Zeichens�tze im
Format 8x8 enthalten (jeweils nur die obere H�lfte des
Zeichensatzes).
Auf den ersten Blick liegt mit GRAFTABL also etwas wie ein
"Codeseiten-Support des kleinen Mannes" vor, der leider
nur im Grafikmodus sichtbar werden kann. Daher d�rfte
GRAFTABL auch nicht in die Umschaltung von Codeseiten
mittels MODE und CHCP einbezogen worden sein (nicht
�berpr�ft), obwohl dies f�r den Grafikmodus durchaus
m�glich w�re (interessanterweise testet zumindest Novells
DISPLAY.SYS aber auf GRAFTABL ab...).
Ein Standard-Font 8x8 (f�r die Hardware-Codeseite 437)
mit den ASCII-Zeichen 0 bis 127 befindet sich immer im
Haupt-BIOS des Rechners, das immer MDA (HGC) und CGA
unterst�tzt. Und im Textmodus werden die Bitmaps f�r die
einzelnen Zeichen bei MDA, HGC und CGA direkt aus einem
Zeichensatz-ROM geladen, der nicht etwa ein BIOS enth�lt.
Insofern kann man hier ohne Hardware-Manipulation sowieso
keine Zeichen umdefinieren. (CGA-Karten besitzen meist
einen Jumper, um zwischen zwei im ROM eingebrannten Fonts
f�r Codeseite 437 zu wechseln und bei neueren HGC-Karten
kann man h�ufig ein eigenes EPROM statt des mitgelieferten
oder bereits im Controller integrierten ROMs einsetzen.
HGC+ RAMFONT Karten erlauben zwar installierbare Zeichen-
s�tze, werden aber von DOS nicht gesondert behandelt, weil
DOS sich dabei auf die Video-BIOS-Unterst�tzung (MCGA/EGA/
VGA) verl��t. Dies bietet eine HGC+ RAMFONT Karte nicht,
lie�e sich bei Caldera OpenDOS relativ leicht mit einem
zus�tzlichen Treiber nachr�sten...)
Bei Grafikkarten mit eigenem BIOS (MCGA/EGA/VGA) residieren
dort sowieso verschieden viele Fonts in voller L�nge.
Au�erdem erlauben diese Karten auch installierbare Text-
Fonts und damit den Einsatz von DISPLAY.SYS. Daher ist dort
GRAFTABL �berfl�ssig. Selbst wenn Sie eine MDA-, HGC- oder
CGA-Karte neben einer MCGA-, EGA- oder VGA-Karte instal-
liert haben, brauchen Sie GRAFTABL nicht zu laden. Das
Video-BIOS der h�herentwickelten Grafikkarte stellt den
h�heren Anteil des 8x8-Fonts n�mlich auch f�r die andere
Grafikkarte zur Verf�gung.
Bei GRAFTABL sind die Zeichensatz-Daten im Treiber selbst
enthalten, k�nnen also nicht erweitert werden. (Notfalls
kann man aber auch den Treiber patchen, jeder der halben
Fonts ist exakt 1024 Zeichen lang, wobei der residente
Treiber ca. 1.5 KByte gro� ist.)
Vielleicht werden Sie jetzt noch einwerfen, da� das Video-
BIOS h�herer Grafikkarten aber nur Fonts f�r die Codeseite
437 enth�lt. Richtig, aber gl�cklicherweise k�nnen die
Fonts aus .CPI-Dateien sowohl im Text- als auch im Grafik-
modus verwendet werden, so da� auch in diesem Fall GRAFTABL
�berfl�ssig bleibt.
F�r die Angabe der Statusinformationen sind folgende
Optionen zul�ssig: /S und /STATUS, andere Formen dieser
Option sind ung�ltig (bei MS-DOS ist noch /STA m�glich).
Interessanterweise werden die Namen der Codeseiten auch
in der deutschen Version in Englisch ausgegeben (437="USA",
850="Multilingual", 860=Portuguese, 863="Can French" und
865="Nordic") ausgewiesen (bei MS-DOS 6.2x hei�t 850=
"Multi-lingual" und 863="Can. French", au�erdem existiert
dort noch eine weitere Codeseite 852="Latin-2"), siehe
auch Kapitel II.16.
Gl�cklicherweise scheint MS-DOS GRAFTABL auch unter
Novell DOS zu laufen.
Errorlevel (dokumentiert f�r Novell DOS 7, gelten auch
f�r MS-DOS 4.0+ und OS/2 2.0+):
0 GRAFTABL erfolgreich geladen
1 GRAFTABL bereits geladen, Codeseite aktualisiert
2 Dateifehler
3 Parameterfehler, keine weitere Aktion
4 Falsche Version des Betriebssystems
GRAPHICS.COM Dieser Treiber erm�glicht Bildschirm-Hardcopies mit <Print>
auch im Grafikmodus. Ohne GRAPHICS (oder Fremdtreiber) sind
die Resultate im Grafikmodus unbrauchbar, lediglich der
Textmodus wird default-m��ig unterst�tzt. Der residente
Treiber kostet ca. 4,5 KByte Speicher.
Unterst�tzt - wie wenig bekannt - mit Option 'COLOR' auch
Farbdrucker (8 Farben mit CMY-Farbband f�r Cyan, Magenta,
Gelb und Schwarz). Neben den dokumentierten Parametern
erlaubt GRAPHICS noch einige Einstellungen mehr:
Neben 'COLOR' f�r Farbdrucker, kann man auch die bei MS-DOS
gewohnten Schl�sselworte 'COMPACT' f�r den IBM PC Compact
Printer oder 'GRAPHICS' f�r den IBM PC Graphics Printer
oder Kompatible angeben.
Die bei Novell DOS ebenfalls undokumentierte Option '/B'
(Background) sorgt daf�r, da� auch der Hintergrund in der
gew�nschten Farbe ausgedruckt wird (nur bei 'COLOR').
MS-DOS 6.22 GRAPHICS bietet allerdings noch erheblich
mehr M�glichkeiten, u.a. auch f�r Laser- und Tintenstrahl-
drucker, die in einer Datei GRAPHICS.PRO auch an eigene
Bed�rfnisse angepa�t werden k�nnen.
Auch die alten Optionen f�r IBM AP PCs und Drucker
('THERMAL' und '/LCD') werden von Novell DOS nicht
unterst�tzt.
Die Option 'COLOR' von Novell DOS entspricht �brigens der
Option 'COLOR8' bei MS-DOS ('COLOR4' f�r vier Farben mit
RGB-Farbb�ndern wird nicht unterst�tzt, 'COLOR1' f�r
Schwarz ist obsolet...). Siehe auch Kapitel II.16.
JOIN.EXE Novells JOIN erlaubt *auch* die Zuordnung eines Laufwerks
auf ein Unterverzeichnis des *gleichen* Laufwerks (getestet
bis Update 15 bei geladenem Netz-Client). Da das Laufwerk
aufgrund der JOIN-Zuordnung nun aber nicht mehr ansprechbar
ist, m�chte ich bezweifeln, da� dies f�r irgendetwas n�tz-
lich sein k�nnte (w�rde ja schlie�lich eine Rekursion
ausl�sen)... (F�llt Ihnen etwas ein?)
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 MS-DOS 5.0+ : alles ok
1 MS-DOS 5.0+ : ung�ltiger Parameter
Novell DOS 7: Verzeichnis f�r JOIN nicht anlegbar
3 Novell DOS 7: Benutzerabbruch (<Ctrl>+<c> etc.)
32 Novell DOS 7: Ausgabe der JOIN-Zuordnungsliste
43 Novell DOS 7: Fehler
255 Novell DOS 7: erfolgreich Zuordnung hergestellt
KEYB.COM Novells KEYB benutzt - im Gegensatz zu KEYB von MS-DOS -
den BIOS-Treiber mit. Hierdurch, und durch die M�glichkeit,
sich in die HMA zu 'verdr�cken', ben�tigt der Treiber ver-
gleichsweise wenig Speicherplatz (4 KByte statt 7,4 KByte
wie der Treiber von MS-DOS). Allerdings kann diese Ver-
fahrensweise auch nachteilig sein.
Die Tabellen f�r die Tastaturlayouts sind bei Novells
KEYB im Treiber selbst untergebracht (nicht wie bei MS-DOS
in einer externen Datei KEYBOARD.SYS). Es existieren der-
zeit noch drei Platzhalter f�r zus�tzliche Layouts. Eine
Tabelle zum Patchen der jeweils g�ltigen Codeseiten ist
wegen der Zeichenkette "valid codepages (2 per country)-->"
leicht zu finden.
Ab dem Update 9 (KEYB 2.09) unterst�tzt dieser Treiber
(weitestgehend undokumentiert) auch Brasilien/Lateinamerika
(KEYB BR) und enth�lt einen Fix f�r <Ctrl>+<Tab>. Update 12
(KEYB 2.10) unterst�tzt sowohl <Shift>+<Tab>, als auch
<Ctrl>+<Tab>. <Alt> Belegungen 'schimmern' nun bei nicht
definierten <AltGr> Belegungen durch. KEYB 2.11 aus Update
13 l�st Probleme mit Nortons NCACHE2, wenn beide in die
HMA geladen wurden. Update 14 enth�lt einen Fix f�r das
ungarische Layout (KEYB 2.12).
Leider unterst�tzt auch der Treiber aus Update 15 noch
nicht die neuen Windows95-Tasten (unter DOS) sowie Tasten
von 122-Tasten-Tastaturen (und auch nicht alle neuen
Tastatur-Layouts und IDs von MS-DOS 6.22 wie YU, YC, RO,
CZ, PL, IS, BG, SL). JP wird offenbar in Spezialversionen
unterst�tzt. (JA, KO, CH und TN werden von keiner euro-
p�ischen DOS-Version unterst�tzt, weder von MS-DOS noch
von Novell DOS). Statt TR gibt es die zwei neuen Optionen
TF und TQ. Bez�glich landesspezifischer Details siehe
Kapitel II.16.
Sollten Sie bestimmte M�glichkeiten von MS-DOS KEYB bei
Novell DOS 7 vermissen, k�nnen Sie auch den Treiber von
MS-DOS unter Novell DOS 7 verwenden. Dazu ist es aller-
dings notwendig die DOS-Version mit SETVER anzupassen
(z.B. SETVER KEYB.COM 6.22 f�r KEYB von MS-DOS 6.22).
Novells KEYB kann nicht unter MS-DOS gestartet werden.
Ganz allgemein eine bessere Alternative zu KEYB (von
jedem DOS) ist der stark erweiterte FreeWare-Tastatur-
treiber K3PLUS 6.50+ bzw. FreeKEYB, die trotz unz�hliger
Erweiterungen auch nur ungef�hr 8,5 KByte Speicher
ben�tigen (zu beziehen �ber mich).
LABEL.COM Dieses Kommando unterst�tzt (auch mit Update 15) im Gegen-
satz zum Pendant von MS-DOS 6.2x noch nicht die Ausgabe von
Medienseriennummern (obwohl der Novell DOS 7 Kernel im
Rahmen der Updates mittlerweile Seriennummern unterst�tzt).
Allerdings kann man f�r diesen Zweck auch LABEL.COM von
MS-DOS 6.22 ausleihen, das auch unter Novell DOS arbeitet.
Novells Implementation arbeitet allerdings im Gegensatz
zu MS-DOS' Realisierung auch auf Netz-, CD-ROM- und
Substitut-Laufwerken. In diesem Fall wird nur der Medien-
name des Laufwerks ausgegeben und es erscheint eine
Meldung, da� der Name nicht ge�ndert werden kann.
Logischerweise unterbleibt dann auch die J/N-Frage nach
einem neuen Namen.
Obwohl LABEL auch direkt die Angabe des neuen Namens als
Parameter erlaubt, mag es in manchen F�llen sinnvoll sein,
den neuen Namen des Mediums aus einer Datei zu holen, etwa:
LABEL < newname.lbl
Auf gemeinsam benutzten Laufwerken, Floppies und RAM-Disks
kann dies jedoch mi�lingen (auch bei MS-DOS/PC-DOS), wenn
der neue Name des Mediums einem bereits auf dem Medium
bestehenden Namen einer Datei im Hauptverzeichnis ent-
spricht. Denn der Name des Mediums wird dort im Prinzip
wie jede andere Datei gespeichert, nur mit (normalerweise
ausschlie�lich) gesetztem Volume-Attribut (aber andere
Attributkombinationen sind auch m�glich). Daraus resul-
tiert auch die etwas seltsam anmutende maximale L�nge von
11 Zeichen (8 + 3 Bytes). Auf physikalischen Festplatten-
laufwerken wird der Name an anderer Stelle gespeichert,
so da� dieses Problem hier nicht auftritt.
In sehr seltenen F�llen kann es vorkommen, da� Sie den
Namen einer Diskette unter MS-DOS/PC-DOS nicht mehr nach-
tr�glich �ndern k�nnen: Falls die Diskette mit den Norton
Utilities formatiert oder nach einem Fehler restauriert
wurde, wird der Name des Mediums statt mit Leerfeldern
(ASCII-32) mit Null-Zeichen (ASCII-0) bis zur vollen L�nge
aufgef�llt. Mit derartigen Namen kommen MS-DOS/PC-DOS
und einige andere Programme (z.B. �ltere Versionen von
PKZIP) jedoch nicht zurecht.
Gl�cklicherweise ist es jedoch unter Novell DOS 7 �ber-
haupt kein Problem, den Namen derartiger Disketten zu
�ndern!
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 erfolgreich
1 MS-DOS 5.0+: Laufwerk nicht vorhanden/ung�ltig
2 Novell DOS 7: Benutzerabbruch (<Ctrl>+<c> etc.)
4 Novell DOS 7: falscher Parameter, Laufwerk nicht
vorhanden/ung�ltig
LOCK.EXE Achtung: Dieses Utility ist kein Schutz gegen unbeab-
sichtigtes Benutzen des Rechners! Schaltet ein skrupel-
loser Zeitgenosse den Rechner w�hrend der Abwesenheit
des Benutzers ab, ist der Schutz von LOCK aufgehoben
(und was schlimmer ist: Evtl. nicht gesicherte Daten
sind verloren - deshalb vorher m�glichst Daten sichern).
Begrenzte Abhilfe ist durch Setzen eines Systempa�wortes
(mittels SETUP und SECURITY) m�glich, das beim Booten
eingefordert wird. Siehe auch bei PASSWORD bez�glich
der Eingabe des globalen Pa�wortes.
Unterst�tzt MDA-, HGC-, HGC+-, HGC-InColor-, CGA-, EGA-
und VGA-Grafikkarten. Speichert das Schirmbild in einer
tempor�ren Datei in %Temp% namens SCREEN.SAV (bei Angabe
des Parameters /S). Besondere Grafikmodi und SuperVGAs
werden anscheinend nicht komplett unterst�zt, was aber
auch nicht verwunderlich w�re. (Ausweichempfehlung:
Den erweiterten Tastaturtreiber K3PLUS alias FreeKEYB
mit eingebautem Universal-Bildschirmschoner verwenden.
Aber: Falls dieser Treiber geladen ist, k�nnen Sie LOCK
mit dessen 'Break-to-DOS'-Funktion (<Ctrl>+<Alt>+<Break>,
sofern aktiviert) auch ohne Angabe des korrekten Pa�wortes
beenden, wobei das System danach sofort neu gebootet
werden sollte. Daher sollten Sie sich nicht zu viel
von LOCK versprechen.)
LOCK entnimmt seine Einstellungen f�r die Bildschirm-
darstellung undokumentiert und entgegen den �blichen
Konventionen unter Novell DOS einer optionalen Datei
DOS.INI im Verzeichnis C:\NWDOS (oder evtl. im %Path%)
aus der Rubrik [COLORS]:
MaxColors=
CurrentColor=
ColorSetX= (X=<CurrentColor> aus 1..9)
Die Einstellungen sind ansonsten v�llig analog zu den
Einstellungen in der Datei NWDOS.INI, die hier allerdings
v�llig ignoriert wird.
U.U. werden einige Einstellungen aus noch aus der Windows-
Datei CONTROL.INI geholt und evtl. spielt dabei LOCKBITMAP
eine Rolle.
Novell DOS 7 LOCK arbeitet weitestgehend anders als
noch DR DOS 6.0 LOCK, obwohl die nach au�en sichtbare
Funktionalit�t �hnlich ist.
Ab Update 12 und sp�ter 14 (LOCK 2.01) werden Fassungen
ausgeliefert, die verschiedene Probleme fixen (nicht aber
das oben beschriebene Verhalten �ndern).
LOCK.EXE kann auch unter Windows gestartet werden.
Achtung: LOCK.EXE hat absolut nichts mit den bei MS-DOS 7
(MS Windows95/Chicago) neuen internen Befehlen LOCK und
UNLOCK zu tun!!!
MEM.EXE Wie nur teilweise dokumentiert, kann man die folgenden
Optionen auch abk�rzen:
/HELP : /H /? (der Parameter /HILFE existiert nicht,
/DEBUG : /D sondern ist lediglich das Resultat
/CLASSIFY : /C eines �bereifrigen �bersetzers...)
Die Option /PROGRAM l��t sich nicht mit /P abk�rzen, da /P
f�r 'Page' zum Anhalten der Anzeige nach jeder Seite ver-
wendet wird (dies gilt nun �brigens auch f�r MS-DOS 7).
Die bei MS-DOS vorhandenen Optionen /FREE und
/MODULE=module bietet Novell DOS' MEM nicht.
In Kapitel IV.5. wird ein Batchjob beschrieben, der
diese Funktionen auch bei Novell DOS 7 nachr�stet und
dabei noch um zwei neue Parameter /REGION und /VECTORS
erg�nzt.
Die bei MS-DOS undokumentierte Option /A zur Anzeige der
HMA-Information kollidiert mit der Anzeige der Gesamtinfo
(/A) unter Novell DOS. F�r die Anzeige der HMA-Belegung
(d.h. des Segments FFFF) dient unter Novell DOS 7 die
Option /F.
Novells MEM.EXE funktioniert teilweise auch unter MS-DOS
und MS Windows95, allerdings f�hren die Parameter /D und
/F unter MS Windows95 zu einem Absturz (getestet mit der
urspr�nglichen Original-Version von Novell DOS 7).
MEMMAX.COM Liefert Errorlevel 3 bei Benutzerabbruch durch <Ctrl>+<c>.
Weitere Hinweise siehe Kapitel V.6.
MODE.COM Dieses vielseitige Einstellungsprogramm bietet (ab DR DOS
5.0) im 'Japan-Modus' M�glichkeiten, japanische Drucker und
Grafikkarten (und Tastaturen) so anzusteuern, da� die
japanischen Schriftzeichen erscheinen. Wie dieser Modus
aktiviert wird, ist noch unklar (evtl. geht dies auch nur
mit speziellen Kernel-Versionen). Standardm��ig ist der
'Englisch-Modus' aktiv und die optionalen Werte werden
gr��tenteils zur�ckgewiesen.
Im folgenden werden nur die Hilfeschirme aufgelistet, die
in der Dokumentation unvollst�ndig angegeben sind, die
restlichen Optionen erfahren Sie im DOSBOOK bzw. mit
MODE /?.
MODE LPT#:[n][,[m][,[P][,s]]] Druckereinstellung
#=Nummer der Druckerschnittstelle
n=Zeichen pro Zeile (80, 132 oder J f�r Japan)
m=Zeilen pro Zoll (6 oder 8)
P=St�ndige Wiederholung
Permanenten Teil von MODE zur Steuerung von
Wiederholungen installieren, kann mit
<Ctrl>+<Break> abgebrochen werden.
Die bei MS-DOS 4 - 6 m�glichen Optionen
[R[ETRY=]]E|B|R|N|NONE|P f�r Error, Busy, Ready,
None, Permanent statt des einfachen P sind bei
Novell DOS 7 leider nicht m�glich. Im Fehlerfall
erscheint eine DOS-Fehlermeldung Abbrechen (=N),
Wiederholen (=P), Ignorieren (=R), Fehler (=E).
s=Leerraum zwischen japanischen Zeichen
(12..50, C, D, E, P)
MODE COM#:b[,p][,d][,s][,P] Serielle Schnittstelle
#=Nummer der seriellen Schnittstelle
b=Baudrate - 110..19200
p=Parit�t - Gerade (E), Keine (N), Ungerade (O)
d=Daten-Bits - 7 oder 8
s=Stopp-Bits - 1 oder 2
P=St�ndige Wiederholung trotz Zeitschranken-
�berschreitung.
Permanenten Teil von MODE zur Steuerung von
Wiederholungen installieren, kann mit
<Ctrl>+<Break> abgebrochen werden.
Die bei MS-DOS 4 - 6 m�glichen Optionen
[R[ETRY=]]E|B|R|N|NONE|P f�r Error, Busy, Ready,
None, Permanent statt des einfachen P und die
anderen Syntax-Erweiterungen sind bei Novell DOS
und DR DOS leider nicht m�glich.
MODE modus,zeilen Anzeigemodus
modus=40 oder BW40: 40 Spalten; keine Farbe (CGA+)
80 oder BW80: 80 Spalten; keine Farbe (CGA+)
CO40: 40 Spalten; in Farbe (CGA+)
CO80: 80 Spalten; in Farbe (CGA+)
MONO: 80 Spalten; monochrom (MDA/HGC)
JT80: 80 Spalten (Japanischer Text)
Auf Zweimonitorsystemen schalten
BW40 und BW80 bzw. CO40 und CO80 auf
den Farbadapter um, w�hrend MONO den
Monochrom-Adapter zum aktiven Video-
System macht. Das Bild des jeweils
anderen Monitors wird dabei nicht
gel�scht. Nat�rlich kann man mit BW40
oder BW80 keine Graustufendarstellung
auf einem Farbadapter erzwingen,
solange eine MDA/HGC im System ist.
Mit 40 oder 80 wird die aktive
Video-Karte nicht umgeschaltet,
sondern nur die andere Darstellungs-
art gew�hlt (40 ist auf MDA/HGC un-
m�glich).
zeilen=Textzeilen : 25, 43 oder 50
MODE LPT#[:]=COM#|LPT# Umleitung eines Druckers
Im Gegensatz zur Dokumentation, die ausschlie�lich
die Umleitungsm�glichkeit eines parallelen Druckers
auf eine serielle Schnittstelle beschreibt, gibt
es eine �u�erst interessante M�glichkeit, auch auf
einen *anderen* parallelen Drucker umzuleiten,
etwa: LPT1:=LPT2. Auch in diesem Fall wird ein
kleiner (ca. 500 Bytes) gro�er residenter Codeteil
geladen. Eine M�glichkeit zur Default-Einstellung
von PRN: und AUX: bietet sich damit allerdings
immer noch nicht. Allerdings k�nnte man hierf�r
ein kleines Utility schreiben, da� die DEVICE-
Verkettung umpatcht (vielleicht gibt es soetwas
schon?). Diese M�glichkeit bestand auch schon
bei DR DOS.
(Bei DR DOS gab es offenbar noch zwei unbekannte Optionen
J80/40?? und A80/40??, die bei Novell DOS 7 weggefallen
sind.)
Es gibt eine gr��ere Anzahl erlaubter Abk�rzungen f�r
einige Schl�sselworte:
LINES : LIN
COLS : COL
DELAY : DEL
CODEPAGE : CP, CODE Diese Optionen werden
PREPARE : PREP auch in Verbindung mit
SELECT : SEL DISPLAY.SYS und PRINTER.SYS
REFRESH : REF in diesem Kapitel n�her
/STATUS : /STA erl�utert.
Zus�tzliche Hinweise finden
sich weiter unten und in
Kapitel III.16.
Bez�glich der Optionen f�r die Codeseiten-Unterst�tzung
seien noch einige (insb. f�r Novell DOS 7 verifizierte)
Anmerkungen angebracht, da diese M�glichkeiten die
meisten Benutzer hoffnungslos �berfordern und allgemein
in der existierenden Literatur viel Unsinn bez�glich der
Codeseiten-Unterst�tzung von DOS verbreitet wurde...
Zum Prinzip:
Um Codeseiten-Support f�r MCGA-/EGA-/VGA-Anzeigen oder
Drucker einzurichten, mu� man in CONFIG.SYS mittels
DISPLAY.SYS und PRINTER.SYS deklarieren, unter welchen
Codeseiten-Kennungen die Hardware-Codeseiten erreichbar
sein sollen und wieviele zus�tzliche Codeseiten man
gleichzeitig unterst�tzen m�chte. Mit dem Laden dieser
Treiber wird der hardware-abh�ngige residente Code der
Codeseiten-Unterst�tzung installiert und gleichzeitig
Platz f�r entsprechend gro�e Tabellen und Datenbereiche
zur Aufnahme der Codeseiten- und Font-Informationen f�r
alle vorzubereitenden Codeseiten reserviert (welche
Codeseiten das einmal sein werden, steht zu diesem
Zeitpunkt noch in den Sternen). Die Codeseiten selbst
werden in diesem Fall noch nicht aktiviert; es gilt
weiterhin die Hardware-Codeseite. Sp�ter (z.B. in
AUTOEXEC.BAT) k�nnen die reservierten Slots mittels
MODE CODEPAGE PREPARE belegt werden, indem man in der
Parameterzeile die einzelnen Codeseiten-Slots (�ber die
Reihenfolge der Angabe der Codeseiten) mit Codeseiten-
Nummern aus dem Repertoire einer anzugebenen .CPI-Datei
verkn�pft. Damit werden die jeweiligen Fonts in die von
den Treiber DISPLAY.SYS bzw. PRINTER.SYS daf�r reservierten
Bereiche geladen, allerdings noch nicht an die jeweiligen
Ger�te abgeschickt. MODE selbst bleibt hier daher nicht
resident im Speicher!
Nun kann man mittels MODE CODEPAGE SELECT oder (wegen
der zus�tzlichen Verkn�pfung mit den Landesdaten aus
COUNTRY.SYS nur bei zus�tzlich geladenem NLSFUNC) auch
mit CHCP auf die so pr�parierten Codeseiten umschalten.
Die residenten Treiber DISPLAY.SYS bzw. PRINTER.SYS
schicken in diesem Fall in erster Linie die zugeh�rigen
Font-Daten aus ihren Datenbereichen an die jeweiligen
Ger�te (Grafikkarte und Drucker).
W�hrend die Gr��e der zu reservierenden Datenbereiche f�r
die Bildschirmfonts anhand deren Anzahl im voraus berechnet
werden kann, steht die L�nge von Download-Zeichens�tzen f�r
Drucker nicht unbedingt vorher fest. Dies ist auch der
Grund daf�r, warum das einfache Ersetzen von Drucker-.CPI-
Dateien durch eigene .CPI-Dateien nur unter bestimmten
Voraussetzungen gelingt, denn der PRINTER.SYS Treiber
selbst enth�lt auch unver�nderliche Teile der Sequenzen.
Da die Einrichtung von Codeseiten durchaus einigen
Speicher kostet, sollte man sich im Falle eines Falles
genau �berlegen, ob es notwendig ist, mehr als eine
vorzubereitende Codeseite einzurichten, so da� man -
inklusive der Hardware-Codeseite - mit MODE CODEPAGE SELECT
oder CHCP zwischen drei und mehr Codeseiten wechseln
kann. H�ufig ben�tigt man im st�ndigen Wechsel neben der
Hardware-Codeseite nur eine weitere Codeseite. Daher
reicht es auch aus, nur eine Codeseite vorzubereiten.
Sollte nun wirklich eine weitere Codeseite ben�tigt werden,
kann man auch zur Laufzeit den Slot f�r die vorbereitete
Codeseite mittels MODE CODEPAGE PREPARE durch die gew�nsch-
te neue Codeseite ersetzen. Neu-Booten etc. ist daf�r nicht
erforderlich. Konkret:
Sie arbeiten zwar meist mit der Hardware-Codeseite 437,
brauchen aber h�ufiger auch die Codeseiten 850 und 860,
letztere allerdings nie im schnellen Wechsel miteinander?
Dann sollten Sie statt zwei vorzubereitender Codeseiten
CONFIG.SYS:
DEVICE=c:\nwdos\display.sys con=(EGA,437,2)
DEVICE=c:\nwdos\printer.sys prn=(1050,437,2)
AUTOEXEC.BAT:
MODE con: CODEPAGE PREPARE=((850,860) c:\nwdos\ega.cpi)
MODE prn: CODEPAGE PREPARE=((850,860) c:\nwdos\1050.cpi)
NLSFUNC
CHCP 437
REM Sie k�nnen jetzt mit CHCP zwischen 437, 850 und 860
REM umschalten (sofern COUNTRY.SYS das unterst�tzt,
REM siehe Kapitel II.16.)...
nur eine Codeseite vorbereiten:
CONFIG.SYS:
DEVICE=c:\nwdos\display.sys con=(EGA,437,1)
DEVICE=c:\nwdos\printer.sys prn=(1050,437,1)
AUTOEXEC.BAT:
MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
NLSFUNC
CHCP 437
REM Sie k�nnen jetzt mit CHCP nur noch zwischen 437 und
REM 850 umschalten, aber den Rest holen wir schnell
REM nach:
SWITCHCP.BAT:
MODE con: CODEPAGE PREPARE=((%1) c:\nwdos\ega.cpi)
MODE prn: CODEPAGE PREPARE=((%1) c:\nwdos\1050.cpi)
REM CHCP kann - abh�ngig vom Land - eine Fehlermeldung
REM ausgeben (siehe Kapitel II.16.)...
CHCP %1
In diesem rudiment�ren Beispiel k�nnen Sie jetzt -
obwohl nur eine Codeseite vorbereitet wurde - jederzeit
mit SWITCHCP zwischen 850, 860, etc. umschalten. Diese
L�sung braucht aber nur ca. halb soviel Speicherplatz
wie die erste M�glichkeit.
Auf die gleiche Weise, wie hier der Slot f�r die einzige
vorbereitete Codeseite bei Bedarf mit neuen Codeseiten
belegt wird, lassen sich auch einzelne Codeseiten ersetzen,
wenn man mehr als eine Codeseite vorbereitet hat. Im
DOSBOOK wird die dazu notwendige Syntax erl�utert (man
gibt bei MODE CODEPAGE PREPARE einfach eine Liste der neu
zu belegenden Codeseiten in der Reihenfolge ihrer Slots an
und l��t dabei einfach die Slots aus, die nicht ver�ndert
werden sollen).
Wenn Sie NLSFUNC (und CHCP) nicht sowieso ben�tigen,
k�nnen Sie auch auf das Laden von NLSFUNC verzichten
und die Codeseiten stattdessen mit MODE CODEPAGE SELECT
umschalten.
Zur Syntax:
Gibt man nur den Ger�tenamen an (etwa: MODE CON: oder
MODE PRN: etc.), so erh�lt man eine �bersicht �ber die
aktuelle Konfiguration dieses Ger�tes. In diesem Fall
sind die Parameter CODEPAGE, CP, CODE und /STATUS, /STA
optional. M�chte man /STATUS, /STA verwenden, mu� man
allerdings auch CODEPAGE, CP oder CODE angeben.
Arbeitet sowohl mit DR DOS/Novell DOS als auch mit
MS-DOS/PC-DOS .CPI-Dateien, siehe auch Kapitel II.16.
MORE.COM Dieser Seiten-Filter wird bei Novell DOS nur noch f�r
die wenigsten DOS-Kommandos ben�tigt, da diese meist
selbst eine /P Option f�r seitenweise Ausgabe anbieten.
Andererseits liegt z.B. bei Verwendung von MORE in Ver-
bindung mit FOR schon ein signifikanter Unterschied
darin, ob man den Filter auf mehrere Ausgaben ver-
schiedener Kommandos gemeinsam anwendet, oder jeweils
die seitenweise Ausgabeoption der einzelnen Kommandos
selbst nutzt:
FOR %%x IN (config.sys autoexec.bat) DO TYPE %%x | MORE
FOR %%x IN (config.sys autoexec.bat) DO TYPE %%x /p
(�brigens soll TYPE /p in �lteren Versionen von
COMMAND.COM nicht sauber mit FOR zusammenarbeiten.
Mit Update 15 klappt's jedoch wunderbar...)
Kommt auch mit Dateien gr��er 64 KByte problemlos zurecht
(was f�r einige MS-DOS/PC-DOS Implementierungen ein Problem
darstellt). Auch bei Ausgabeumleitung wird die Meldung
"Bitte eine Taste dr�cken ..." auf dem Bildschirm angezeigt
(StdErrOut), und man mu� auch tats�chlich jede Seite
best�tigen.
Bez�glich der sicheren Verwendung in Batchjobs siehe
Kapitel IV.6.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 Hilfeschirm angezeigt
3 Benutzerabbruch (<Ctrl>+<c> etc.) w�hrend der
Eingabe (auch Eingabeumleitung).
255 Nach ordnungsgem��em Ablauf, auch im Falle eines
Benutzerabbruchs (<Ctrl>+<c>) w�hrend der Ausgabe
(auch bei Ausgabeumleitung).
MOVE.EXE Das Kommando MOVE ist eine Mischung zwischen REN und COPY.
Wird eine Datei auf dem gleichen physikalischen Laufwerk
verschoben, so arbeitet MOVE intern genauso wie REN
(auch bez�glich des Handlings von Pa�w�rtern, nur mit dem
Fehler, da� aufgrund eines Bugs (getestet bis Update 15)
bereits in der Kommandozeile angegebene Pa�w�rter ignoriert
werden, d.h. MOVE fragt bei Bedarf explizit nach, siehe
Kapitel II.11.).
Dieses Umbenennen ist nat�rlich sehr viel schneller als das
normalerweise durchzuf�hrende Kopieren mit anschlie�endem
L�schen des Originals, kann aber verst�ndlicherweise nur
auf dem gleichen physikalischen Laufwerk angewendet werden.
Substitut-Laufwerke etc. werden dabei �brigens korrekt
ber�cksichtigt.
Da z.B. der Norton Commander beim Verschieben mit <F6>
keine Substitut-Laufwerke auf die physikalisch zugrunde-
liegenden Laufwerke zur�ckf�hrt, dauert hier das Ver-
schieben zwischen unterschiedlichen Laufwerksbuchstaben
immer genausolange wie Kopieren plus anschlie�endes
L�schen. In solchen F�llen lohnt es sich also, den
Norton Commander zu verlassen.
Wird jedoch das effektive Kopieren notwendig, weil das
Ziel auf einem anderen Laufwerk liegt, so arbeitet MOVE
wie COPY + DEL. Sind die Dateien jedoch pa�wortgesch�tzt,
so weicht das Verhalten davon ab: In diesem Fall wird die
Quelldatei nicht angetastet, daf�r besitzt die Zieldatei
allerdings keinen Pa�wortschutz mehr (im Gegensatz zu COPY
wird bei MOVE hier auch das Hidden-Attribut nicht gel�scht,
getestet bis Update 15. Es d�rfte sich hier um ein oder
zwei kleine Bugs handeln).
Achtung: Unter 4DOS wird normalerweise der 4DOS-interne
MOVE Befehl verwendet. Hier unterscheidet sich das Ver-
halten nicht zwischen pa�wortgesch�tzten Dateien und
normalen Dateien, und daher weicht das Verhalten bei
pa�wortgesch�tzten Dateien stark von Novells externem
MOVE ab:
Solange die Datei nur umbenannt werden mu� (d.h. nicht
�ber die Grenzen des physikalischen Laufwerks hinaus
verschoben wird) gleicht das Verhalten dem von Novell DOS.
Mu� die Datei aber wirklich kopiert werden, so wird sie
im Gegensatz zu Novells MOVE an der Quelle gel�scht und
zum Ziel kopiert, wobei die Datei im Ziel zwar noch das
Hidden-Attribut besitzt, aber keinen Pa�wortschutz mehr.
Leider ber�cksichtigt 4DOS dabei nicht, da� bei implizit
gleichen Laufwerke (wie z.B. bei Substitut-Laufwerken)
eventuell gar nicht kopiert, sondern nur umbenannt werden
mu� (getestet mit 4DOS 5.5c).
Offensichtlich ist es nicht m�glich, ein Pa�wort �ber die
Laufwerksgrenzen hinweg zu �bertragen. Entweder handelt es
sich dabei einfach um eine Nachl�ssigkeit bei der Implemen-
tierung, oder es k�nnte sich um eine Sicherheitsma�nahme
im Kernel handeln, der es z.B. nur erlaubt, Pa�w�rter zu
setzen und abzutesten, aber nicht zu �bertragen.
Dies w�re eine Erkl�rung daf�r, warum Pa�w�rter nur dann
erhalten bleiben (sowohl bei Novell DOS Kommandos wie auch
bei 4DOS), wenn die Datei physikalisch gar nicht bewegt
werden mu�.
Zu beachten ist also, da� man mit MOVE nur dann die
Plattenstruktur defragmentiert, wenn Dateien wirklich
�ber Laufwerksgrenzen hinweg bewegt werden m�ssen. D.h.,
wenn man Daten verschieben will, sollte man auch wirklich
MOVE oder REN und nicht eine Kombination aus COPY + DEL
verwenden.
Notwendige Pa�w�rter k�nnen - wie bei Novell DOS und
DR DOS �blich - durch ein Semikolon getrennt an die
Dateispezifikation angeh�ngt werden:
d:filename.ext;password
(N�heres bez�glich Syntax und Fehlervermeidung in Kapitel
II.9., N�heres zum Dateimanagement bei PASSWORD.EXE.)
Wurden noch bei DR DOS beim Angabe der Option /S und einem
Pfad als Quelle die Verzeichnisse am Ziel nicht wieder-
hergestellt, so ist diese Situation unter Novell DOS ent-
sch�rft: die Verzeichnisse werden �bernommen, das Quell-
verzeichnis bleibt erhalten. Zum Verschieben mit L�schen
verwendet man die Option /T.
Falls nicht klar ist, ob es sich bei der Zielangabe um
eine Datei oder ein Verzeichnis handelt, fragt der MOVE
Befehl explizit nach: <D> steht f�r Datei und <V> steht
f�r Verzeichnis (was bei anderssprachigen MOVE Dateien
Verwirrung stiftet). Handelt es sich bei der Quelle um
ein Verzeichnis, steht damit auch fest, da� auch das Ziel
ein Verzeichnis sein mu�. Handelt es sich um eine Datei-
maske ist i. allg. auch klar, da� das Ziel ein Verzeichnis
sein mu�. Handelt es sich jedoch um eine einzelne Datei,
kann normalerweise nicht erkannt werden, ob das Ziel eine
Datei oder ein Verzeichnis sein soll (es sei denn, da�
das Ziel bereits existiert). Gibt man jedoch im Ziel
einen '\' am Ende an, so ist auch klar, da� es sich um ein
Verzeichnis handeln mu�. Der Fall, in dem MOVE nachfragt,
ist jedoch nicht trivial, denn die Angabe von <D> oder <V>
gilt nat�rlich nur f�r die deutsche Ausgabe dieses
Kommandos, d.h. ohne weitere Vorkehrungen ist es nicht
m�glich, einen Batchjob zu schreiben, der in allen
Landesvarianten mit einer automatisierten Eingabeumleitung
arbeitet, aus der die Antwort auf diese Frage kommt. Da in
der englischen Version <F>=file und <D>=directory verwendet
werden, sollte man in die Datei f�r die Eingabeumleitung
die Antworten f�r 'Datei' in der Reihenfolge angeben, da�
keine Mi�deutung als 'Verzeichnis' erfolgen kann (N�heres
bez�glich internationaler Batchjobs siehe Kapitel II.16.).
REM (F und D sind gesichert, E und A nur Vermutungen!)
ECHO FEAD | MOVE oldfile newfile
Gl�cklicherweise akzeptiert Novells MOVE bei der besagten
Frage keine anderen Buchstaben als die beiden Buchstaben
f�r 'Datei' und 'Verzeichnis', so da� diese Methode wirk-
lich funktioniert.
Au�erdem unterst�tzt MOVE �ber die undokumentierte Syntax
/U:name die Angabe eines zul�ssigen Benutzeranmelde- oder
Gruppennamens (maximal 12 Zeichen lang). Diese Option ist
nicht unter jedem Betriebssystem verf�gbar und hat in
Novell/DR Multiuser-Varianten oder in Verbindung mit
lokalen Benutzerkonten und einmaliger Anmeldung eine
Bedeutung, sofern die Systemabsicherung aktiviert ist.
Die beiden mit MS-DOS 6.2 eingef�hrten Parameter /Y und
/-Y zur Best�tigung vor dem �berschreiben unterst�tzt
Novell DOS 7 (getestet bis Update 15) noch nicht, da es
viel fr�her eingef�hrt wurde.
NLSFUNC.EXE Dieser Treiber sollte in jedem Fall geladen werden, da er
vollen Zugriff auf die L�nderunterst�tzung f�r alle in
COUNTRY.SYS enthaltenen L�nder garantiert und auch f�r
CHCP ben�tigt wird, wenn man damit Codeseiten umschalten
will. Ein Gro�teil des residenten Codes f�r die L�nder-
unterst�tzung ist sowieso im Kernel enthalten und wird
von NLSFUNC nur noch freigeschaltet, so da� das Laden des
Treiber auch nur sehr wenig Speicher ben�tigt, der auch
in der HMA liegen kann (ca. 900 Bytes statt ca. 2,8 KByte
wie bei MS-DOS). Der Treiber arbeitet auch unter DR DOS 6.0
"Business Update 1993" (wahrscheinlich aber nicht unter
fr�heren Versionen) und l��t sich nur unter Singleuser-
Varianten installieren, w�rde wahrscheinlich aber auch
in einer Multiuser-Umgebung funktionieren. Weitere Hinweise
in Kapitel II.16. Der Treiber akzeptiert auch COUNTRY.SYS
Dateien von DR DOS 5.0 und DR DOS 6.0 (diese besitzen wie
Novell DOS die Format-Revision R2.01), nicht aber die von
DR DOS 3.41 (R2.00), bei denen noch der mit DOS 4 einge-
f�hrte DBCS-Support fehlte.
Wenn Sie NLSFUNC nicht laden, unterst�tzt das System
lediglich den Landesinformationen, die mit COUNTRY= in
CONFIG.SYS eingestellt wurden. Auch die Umschaltung des
Landes zur Laufzeit (etwa mit meinem FreeWare-Utility
COUNTRY.EXE aus dem Paket COUNTRY.ZIP) ist nur bei
geladenem NLSFUNC Treiber m�glich. Die Umschaltung kann
je nach Codeseiteneinrichtung durchaus mehrere Sekunden
dauern.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 normales Ende
3 Benutzerabbruch (<Ctrl>+<c> etc.)
NWCACHE.EXE Die Overlay-Dateien zu NWCACHE sind nicht ladbar, wenn
NWCACHE in CONFIG.SYS mittels INSTALL= geladen wird.
Entweder man ersetzt INSTALL= durch DEVICE= oder man
l�dt NWCACHE erst in AUTOEXEC.BAT. NWCACHE.EXE/OV1/OV2
sind gr��tenteils identisch und unterscheiden sich
haupts�chlich in der Speichersorte, in der sie den
Cache-Puffer ablegen: NWCACHE.EXE dient als Wrapper
f�r alle Module, sowie speziell f�r den Cache im XMS,
NWCACHE.OV1 f�r EMS und NWCACHE.OV2 f�r den Cache im
konventionellen Speicher). Welches der drei Module
effektiv geladen wird, h�ngt von der gew�nschten
Speicherverwendung (/E /L) ab. Alle drei Module sind
im Prinzip aber komplett eigenst�ndig lauff�hige
Programme (wenn man .OV? in .EXE umbenennt).
(Beim Vorg�nger NLCACHE aus NetWare Lite waren die
Cache-Module von vornherein eigenst�ndige Programme
NLCACHE?.EXE, z.B. siehe Update-Archiv NWL11G.EXE.)
Die Verwendung der verschiedenen Speichersorten f�r die
einzelnen Bestandteile ist durch die Vielfalt etwas ver-
wirrend, wenn auch sehr gut gel�st:
- Programmcode (Stub 5 KByte + Hauptteil variabel):
Mit DPMS ist der unterhalb des ersten MegaByte
verbleibende Hauptteil 5 KByte, mit EMS
ca. 8 KByte und mit XMS ab ca. 8 KByte mit
zunehmender Cache-Gr��e noch etwas weiter
steigend.
/ML f�r beide Teile im unteren Speicher
/MU f�r beide Teile im UMB-Speicher (im unteren
Speicher, falls keine UMBs verf�gbar)
/MLX f�r Stub im unteren Speicher und Hauptteil im
Extended Memory, angesprochen �ber DPMS. Falls
kein DPMS verf�gbar ist, �ber XMS oder INT15h,
sonst auch im unteren Speicher.
/MUX wie /MLX, nur - falls m�glich - mit Stub in
UMBs.
- Hauptpuffer (max. 7 MByte):
normalerweise in XMS (via DPMS???)
Bemerkung: Angeblich soll Calderas NWCACHE 1.02
auch gr��ere Cache-Puffer als 7 MByte akzep-
tieren, wenn man die Parameterzeile per Hand
modifiziert. Bisher kann ich dies jedoch noch
nicht best�tigen. Evtl. h�ngt dies aber auch
von der Cluster-Gr��e der gepufferten Parti-
tionen ab, und w�re daher nur auf sehr gro�en
Partitionen m�glich (was ich aber ebenfalls
nicht nachvollziehen konnte)???
/X:adr wahlweise Extended Memory �ber INT15h oder
direkt???
/E im EMS
/L im unteren Speicher
- Vorausschauender Puffer (4 - 16 KByte):
/BE:size im EMS-Speicher (nur m�glich mit /E)
/BU:size im UMB-Speicher (evtl. nicht m�glich mit /L)
/BL:size im unteren Speicher
NWCACHE besitzt zwei gesperrte undokumentierte Optionen
/HMA (vorgesehen, um die Cache-Tabellen in der HMA unter-
zubringen) und /NOXMS (f�r den Ausschlu� der XMS-Nutzung).
Obwohl intern einige Vorbereitungen f�r diese Optionen
getroffen wurden, existieren leider in keinem der drei
Module weder Auswerteroutinen f�r diese Parameter, noch der
Code f�r die entsprechende Spezialbehandlung (/HMA w�re
das T�pfelchen auf dem "i" ;-), /NOXMS ist eigentlich
obsolet, da die Verwendung des Speichers �ber die
vorhandenen Optionen ebenso gut eingestellt werden kann).
Dies gilt auch noch f�r Caldera OpenDOS 7.01 mit NWCACHE
v1.02. Die in der Sekund�rliteratur teilweise zitierten
Optionen /MH und /MHX (ebenfalls f�r HMA) existieren in
den offiziell ausgelieferten Versionen von NWCACHE jeden-
falls nicht. (Im Tutorial NWCH_TUT.TXT, das offenbar auf
der Beta 12 von NWCACHE basierte, wurde �brigens behauptet,
mit der Option /B[x]=0 k�nnte man die vorausschauende
Pufferung abschalten und f�r den Betrieb unter MS Windows
w�re /DELAY=OFF zwingend notwendig. Beides kann ich nicht
best�tigen, und soweit ich wei�, schaltet NWCACHE
automatisch in den Durchschreibemodus, sobald MS Windows
gestartet wird.)
Der Vorg�nger NLCACHE aus NetWare Lite konnte unter be-
stimmten Umst�nden die HMA verwenden. Obwohl die Codebasis
und das Grundprinzip der Aufteilung weitestgehend identisch
war, unterst�tzte er z.B. noch kein DPMS und einige andere
Funktionen fehlten ebenfalls. Zudem besa� er ein reichlich
verwirrendes Kommandozeilen-Interface, das sich nahezu
vollkommen von NWCACHEs Optionen unterscheidet. Aus diesem
Grund gab es sogar ein eigenes Konfigurationsprogramm f�r
NLCACHE. Einige Spezialbehandlungen, die sich bei NLCACHE
noch w�hlen lie�en (etwa bei inkompatiblen Festplatten-
BIOSen mit gro�en Platten nur die ersten 256 MByte zu
cachen, und verschiedene Integrit�tskontrollen z.B. f�r
langsame EMS-Karten), kennt NWCACHE nicht mehr. Entweder
sind nur entsprechende Parameter weggefallen und der
Treiber erkennt diese Sonderf�lle nun automatisch, oder
Sie sollten bei Schwierigkeiten mit NWCACHE auf ganz alten
Rechner einfach einmal NLCACHE ausprobieren (vorausgesetzt,
Sie sind Besitzer von NetWare Lite, dann ist das Update
NWL11G.EXE sicherlich f�r Sie interessant).
Das Modul NWCACHE.OV1 wertet dar�ber hinaus die Option /A20
nicht aus, das Modul NWCACHE.OV2 kennt neben /A20 auch
/LEND nicht. Die anderen Parameter werden nicht zur�ck-
gewiesen, aber f�r NWCACHE.OV2 ist z.B. /CHECK obsolet.
Achtung: Wenn Sie NWCACHE direkt als zu einer .EXE-Datei
umbenanntes .OV1/.OV2-Modul geladen haben und nun wieder
entladen wollen, m�ssen Sie daf�r das gleiche Modul ver-
wenden, ansonsten wird eine Fehlermeldung ausgegeben.
Entgegen dem Hilfeschirm ist es mit NWCACHE 1.01(.1)
offenbar nur eingeschr�nkt m�glich, den DELAY-Wert nach
der Erstinstallation zu �ndern (ON|OFF ist m�glich und
wird auch in der Statusmeldung best�tigt). Damit ein
ge�nderter Zeitwert f�r DELAY auch in der Meldung auf-
taucht, mu� der Cache vorher entladen werden. Allerdings
�ndert sich sehr wohl das Pufferungsverhalten von Floppies:
Bei sehr kleinen DELAY-Werten (auf einem 386sx18 ca.
50ms..58ms, auf einem 386sx16 gar nur 50ms..55ms) werden
diese Laufwerke im gepufferten Schreibmodus benutzt, sonst
nur im Durchschreibmodus (wie auch in der Statusmeldung
aufgef�hrt). Dies deutet darauf hin, da� die �nderung des
DELAY-Wertes auch zur Laufzeit durchaus m�glich ist, nur
in der Zeitangabe der Statusmeldung nicht explizit ge�ndert
wird.
Reicht der g�ltige Wertebereich von 50..5000ms nicht aus,
sollte es m�glich sein, zumindest den Maximalwert (1388h)
zu patchen (drei Vorkommen pro Datei, das dritte Vorkommen
ist der Default-Wert; nicht ausprobiert!).
F�r optimale Performance sollten Sie /FLUSH=OFF einstellen,
was aber auch nicht ganz ungef�hrlich ist, wenn Sie den
Rechner nach der Arbeit ohne Wartepause am Prompt (ca.
10 Sekunden) einfach ausschalten oder einen inkompatiblen
Tastaturtreiber einsetzen, der vor einem Boot-Vorgang via
<Ctrl>+<Alt>+<Del> die Cache-Puffer nicht ausschreiben
l��t (K3PLUS 6.18p5+ bzw. FreeKEYB unterst�tzen diese
Funktion in vollem Umfang). In Verbindung mit 4DOS/NDOS
sollten Sie die Einstellung SDFlush=Yes|No in der
4DOS.INI/NDOS.INI Datei entsprechend einstellen (siehe
Kapitel VII.3.).
Fr�he NWCACHE Versionen gaben in der /S �bersicht teilweise
(mit VERIFY ON) ziemlichen Unsinn f�r gesparte Schreib-
zugriffe aus (astronomisch hohe Zahlen, aber 0%). Dies
wurde mit Update 13 korrigiert. Allerdings zeigt NWCACHE /S
immer noch keine gesparten Schreibzugriffe an, solange
VERIFY ON ist. Da es eigentlich auch mit VERIFY ON eine
(geringere) Anzahl einzusparender Schreibzugriffe geben
'k�nnte', ist dies nicht ganz einsichtig. Andererseits
weist Novell ausdr�cklich darauf hin, da� VERIFY ON
jeglichen Cache-Bem�hungen entgegenl�uft und daher bei
Verwendung von NWCACHE oder NetWare-Anbindung ausgeschaltet
werden sollte (mehr zu diesem Thema in Kapitel II.14.).
Mit VERIFY OFF verbessert sich die NWCACHE Performance
jedenfalls drastisch, was sich insbesondere bei sehr
langsamen Laufwerken bemerkbar macht (s.u.).
Achtung: Die mit Caldera OpenDOS 7.01 ausgelieferte
Version NWCACHE v1.02 enth�lt diesen alten Bug nun wieder,
obwohl der bei Novell DOS mit NWCACHE v1.01 beseitigt
wurde (intern enthalten alle diese Ausgaben eine alte
Angabe VeRsIoN=1.01.1 von 1993).
Offiziell ist die maximale Laufwerks- (oder Partitions-
gr��e???), die NWCACHE bearbeiten kann, ein Gigabyte.
Dar�ber k�nnen angeblich nur noch Floppies gepuffert
werden, der Treiber sollte dann unmittelbar nach
HIMEM/EMM386/DMPS in CONFIG.SYS geladen werden. Vielleicht
wurde diese Schranke mit einem Update beseitigt, denn
ich konnte NWCACHE aus Update 15/2 auf einer 3.2 GByte
Festplatte mit einer (testweise installierten) 2 GByte
Partition erfolgreich und stabil einsetzen.
NWCACHE kann alle Laufwerke cachen, die via Blocktreiber
ins System eingebunden sind (d.h. aber keine CD-ROMs,
die via Umadressierer eingebunden sind, daher auch keine
entfernten Netzlaufwerke). Daran hat sich auch mit
NWCACHE v1.02 aus Caldera OpenDOS 7.01 noch nichts ge-
�ndert. Eine Abhilfe bieten z.B. spezielle CD-ROM-Caches
von Drittanbietern, etwa CD-Quick (CDQ.EXE), die auch mit
meinem INSTCDEX.EXE Utility problemlos funktionieren,
allerdings bei Verwendung des DPMS-nutzenden NWCDEX statt
MSCDEX einen schmerzlichen Verlust von kostbarem DOS-
Speicher bewirken (aber mit SMARTDRV und/oder MSCDEX sind
Sie auch nicht besser bedient...).
Wenn Sie z.B. �ber einen Tape-Streamer verf�gen, der sich
�ber Treiber als (extrem langsame) 'Harddisk' wahlfrei an-
sprechen l��t (z.B. 2x33 MByte HP9142 mit DC-600 Medien an
HP-IB/GP-IB/IEEE-488-Karte), so k�nnen damit schon nach
kurzer Betriebszeit die Wartezeiten (normalerweise bis zu
mehrere Minuten f�r einen Verzeichniswechsel!) drastisch
verk�rzt werden. Bei derartig langsamen 'Laufwerken' ist
es �brigens zweckm��ig, den Schreib-Cache explizit zu
aktivieren (falls NWCACHE das w�hrend der Installation
noch nicht von selbst macht) und VERIFY OFF zu setzen.
(Bei obigem Streamer dauerte ein 30 MByte Backup mit dem
Norton Commander bzw. COPY ohne NWCACHE und mit VERIFY ON
etwa 3 Tage (BUFFERS=3, FASTOPEN=0), mit NWCACHE (mit
Schreib-Cache) und VERIFY ON etwa 2 Tage und als letzte
Alternative mit VERIFY OFF ca. 7 Stunden. ;-) )
Diese Ergebnisse lassen �brigens darauf schlie�en, da�
VERIFY ON|OFF bei Novell DOS 7 (und auch schon bei DR DOS)
wirklich einschneidende �berpr�fungen vornimmt. Mehr dazu
in Kapitel II.14.
�brigens ist NWCACHE in einigen Punkten kompatibel zu
SMARTDRV: Das SMARTDRV 4.0+ API wird gr��tenteils nach-
gebildet. Daher braucht NWCACHE auch nicht aus der Kon-
figuration entfernt werden, wenn etwa ein Defragmentierer
wie PC-Tools COMPRESS/OPTIMIZR warnt, alle Caches au�er
SMARTDRV usw. (aber nicht NWCACHE) zu entfernen. Ich
hatte mit NWCACHE noch nie diesbez�gliche Probleme mit
derartigen Pflegeprogrammen.
NWCDEX.EXE Speicheroptimierter (weil DPMS-nutzender) Ersatz f�r
Microsofts MSCDEX.EXE, siehe auch Kapitel II.3. und V.4.
Arbeitet auch mit DR DOS 5.0 und 6.0 (nicht aber mit 3.41).
Da NWCDEX im DOSBOOK nicht dokumentiert ist, m�ssen Sie
auf die eingebaute Hilfe ausweichen, die NWCDEX /? selbst
ausgibt. NWCDEX unterst�tzt - dokumentiert - alle Parameter
von MSCDEX.EXE sowie einige eigene Optionen. Der Parameter
/L:driveletter kann bei NWCDEX auch einen Doppelpunkt
enthalten (etwa /L:E:), da MSCDEX dies aber nicht akzep-
tiert, sollten Sie darauf verzichten.
Sogar die MSCDEX-Option /S (zum CD-ROM-Sharing in Ver-
bindung mit MS-NET oder MS Windows for Workgroups) wird -
undokumentiert - nicht zur�ckgewiesen (getestet mit Update
15), �ndert bei NWCDEX aber absolut nichts am Speicher-
verbrauch, k�nnte also ein Dummy sein (MSCDEX ben�tigt
ca. 0,5 KByte mehr, wenn die /S Option angegeben wurde). Im
Zweifelsfall schadet die Angabe bestimmt nicht. NWCDEX.EXE
erlaubt in jedem Fall das Sharing des CD-ROM-Laufwerks in
Verbindung mit PNW (andere Netze noch nicht getestet,
Hinweise willkommen).
MSCDEX �ndert mit /S die Unterst�tzung von TRUENAME:
Normalerweise werden CD-ROM-Laufwerke in einer speziellen
Variante der UNC-Notation angegeben (z.B. \\D.\A.), jeden-
falls wird das Laufwerk �ber diesen Pfad in der CDS
(Current Directory Structure) referenziert. Obwohl sich
daran auch mit /S nichts �ndert, ergibt TRUENAME interes-
santerweise auch f�r das CD-ROM-Laufwerk einen normalen
Pfad (z.B. D:\). Obwohl MSCDEX unter MS-DOS problemlos
mit der Option /S aufgerufen werden kann, wird das Laden
des Treibers (meiner bisherigen Erfahrung nach) mit der
Option /S unter Novell DOS immer zur�ckgewiesen, auch bei
installiertem SHARE.
Sollen mehrere CD-ROMs ins System eingebunden werden,
kann man die Angabe /D:name mehrfach angeben. M�chte man
das gleiche Laufwerk unter mehreren Buchstaben ansprechen,
so ist sogar die mehrfache Ankopplung an den gleichen
Hardware-Treiber m�glich.
NWCDEX/MSCDEX sollte vor den Netztreibern geladen werden,
zwingend notwendig ist dies aber nicht.
Es gibt einige Installationsprogramme von CD-ROM-Laufwerken
(z.B. 4fach-speed CD-ROM-Laufwerke von Mitsumi), die die
Konfigurationsdateien nach einem MSCDEX-Treiber durchsuchen
und nicht funktionieren, wenn Sie das Gegenst�ck NWCDEX von
Novell benutzen. In solchen F�llen sollten Sie NWCDEX.EXE
kurzfristig in MSCDEX.EXE umbenennen oder die Installation
manuell vornehmen. Das Problem ist lediglich in der Igno-
ranz solcher Installationsprogramme begr�ndet und ist kein
Kompatibilit�tsproblem: Die CD-ROM-Laufwerke funktionieren
nat�rlich genausogut mit NWCDEX wie mit MSCDEX!
Einzige Designschw�che: W�hrend der Initialisierung be-
n�tigt der Treiber enorm viel freien Speicher. Obwohl es
mit geladenem DPMS (oder CLOAKING, siehe Kapitel II.4. bei
DPMS) kein Problem ist, die unter DOS ben�tigte Gr��e des
residenten Codes von ca. 83 KByte auf 7 KByte schrumpfen
zu lassen (MSCDEX ben�tigt hier noch �ber das Doppelte
(16 KByte) und kann sich nicht ohne Weiteres auslagern),
ist es enorm schwierig, diese restlichen 7 KByte in den
UMBs zu verstauen.
Interessanterweise ist der insgesamt ben�tigte Speicher-
bedarf beider Treiber bis auf ca. ein KiloByte gleich, mit
dem Unterschied, da� man NWCDEX besser auslagern kann.
Trotzdem:
In den allermeisten F�llen wird sich der Treiber nicht
hochladen k�nnen und belegt dann diese 7 KByte im Basis-
speicher (wo er besonders st�rt). Offenbar kann der
Treiber nur dann hochgeladen werden, wenn zum Zeitpunkt
der Initialisierung der komplette Code in den UMBs unter-
gebracht werden kann, auch wenn er sp�ter nur besagte
7 KByte ben�tigt.
Vielleicht kann man hier mit QEMMs Squeeze-Technik etwas
ausrichten, unter EMM386 konnte ich jedoch noch keine DOS-
eigene L�sung f�r dieses Hochladeproblem finden.
Mit MEM direkt vor dem Aufruf des NWCDEX-Treibers k�nnen
Sie feststellen, wieviel UMB-Speicher ggf. fehlt, um NWCDEX
hochzuladen. Sollten auf Ihrem System nur 4 KByte oder
weniger fehlen, k�nnen Sie folgenden Trick versuchen:
PKLITE NWCDEX.EXE -x
entpackt den NWCDEX.EXE-Treiber auf Originalgr��e und
streift den PKLITE-Selbstentpacker von der Datei NWCDEX.EXE
ab. Da nun dieser Selbstentpacker w�hrend der Ladephase
des Treibers nicht *auch* noch Speicher ben�tigt (maximal
4 KByte bei PKLITE 1.xx, jedoch bis zu 85 KByte bei PKLITE
2.xx), kann es sein, da� NWCDEX.EXE nun gerade doch noch
hochgeladen werden kann.
Wegen dieses Hochladeproblems ist es besonders �rgerlich,
da� NWCDEX (wie auch MSCDEX, von MS-DOS 7 abgesehen)
normalerweise nicht in CONFIG.SYS geladen werden kann, wo
i. allg. noch mehr als genug UMB-Speicher zur Verf�gung
steht. Da� der Treiber in CONFIG.SYS nicht geladen werden
kann, liegt daran, da� oft nicht gen�gend Laufwerksbuch-
staben zur Verf�gung stehen. Die CONFIG.SYS Einstellung
LASTDRIVE= wirkt erst *nach* der Abarbeitung der CONFIG.SYS
(mehr zu LASTDRIVE= in Kapitel III.1. und III.2.). So kommt
es, da� NWCDEX (als auch MSCDEX) oft die Meldung 'Kein
Laufwerksbuchstabe verf�gbar' ausgibt, wenn Sie versuchen,
NWCDEX.EXE etc. per INSTALL=/INSTALLHIGH= etc. zu laden.
Das Laden per DEVICE=/DEVICEHIGH= etc. scheitert daran,
da� NWCDEX und MSCDEX keinen entsprechenden Treiberkopf
bereitstellt.
Um diesem Problem abzuhelfen und dadurch NWCDEX (oder
MSCDEX) doch komplett hochladen zu k�nnen, habe ich ein
kleines Utility namens INSTCDEX.EXE geschrieben, das alle
diese Probleme l�st, indem es erm�glicht, einen bereits
benutzten Laufwerksbuchstaben wieder f�r ung�ltig zu er-
kl�ren (was man nat�rlich nur mit Bedacht f�r Dummy-
Laufwerke anwenden sollte) oder selbst die Laufwerkstabelle
erweitert, um dadurch das Laden von Umadressierern wie
NWCDEX/MSCDEX bereits in CONFIG.SYS zu erlauben. Damit ist
das CD-ROM-Laufwerk in CONFIG.SYS bereits ansprechbar
(nachweisbar mit INSTALL=c:\nwdos\command.com). Auf diese
Weise k�nnen sogar in CONFIG.SYS Treiber direkt von CD-ROMs
geladen werden! Da beim endg�ltigen Laden des Kommando-
prozessors auf dem �blichen Weg (SHELL=) nach CONFIG.SYS
unter Novell DOS (nicht bei MS-DOS) die internen Laufwerks-
tabellen verschoben und erneut ver�ndert werden, w�rde
das CD-ROM-Laufwerk aber in AUTOEXEC.BAT und sp�ter wieder
abgekoppelt sein. Auch mit diesem Problem wird INSTCDEX.EXE
fertig, indem es erm�glicht, den aktuellen Status des
Laufwerks in einer Datei C:\CDS_?.DAT zu speichern und
sp�ter wieder zu laden.
Beispiel zum Hochladen von NWCDEX.EXE in CONFIG.SYS:
CONFIG.SYS:
REM (EMM386.EXE/DPMS.EXE bereits geladen...)
DEVICEHIGH=c:\sys\cdrom\mscd001.sys /d:mscd001 ...
REM Laufwerksbuchstaben bereitstellen (hier H:=7)...
DEVICEHIGH=c:\nwdos\DRIVER.SYS /d:7 /f:7
DRIVPARM=/d:7 /c /f:8 /n
INSTALL=INSTCDEX.EXE /prepare /drive=h
REM Nun kann NWCDEX doch geladen werden, denn der bereit-
REM gestellte Laufwerksbuchstabe H: ist wieder verf�gbar.
INSTALLHIGH=c:\nwdos\nwcdex.exe /d:mscd001 /m:32 /l:h ...
REM Nur bei Novell DOS notwendig:
INSTALL=INSTCDEX.EXE /cdrom /save /drive=h
AUTOEXEC.BAT:
REM CD-ROM-Laufwerk ist nicht mehr ansprechbar...
REM Nur bei Novell DOS notwendig:
INSTCDEX.EXE /restore /drive=h
REM Nun ist das CD-ROM-Laufwerk wieder ansprechbar...
Falls Sie auf diese Art und Weise mehr als ein CD-ROM-
Laufwerk einbinden wollen (/D: siehe oben), m�ssen Sie
entsprechend viele Laufwerke mit INSTCDEX.EXE pr�parieren.
Unter Novell DOS und Caldera OpenDOS gibt es sogar noch
eine (unsaubere) Methode, ganz auf den zus�tzlichen
Treiber zu verzichten: Hierzu dient die INSTCDEX-Option
/LASTDRIVE. N�heres zu INSTCDEX findet sich in dem Archiv
INSTCDEX.ZIP.
NWCDEX (getestet bis Update 15) setzt im Gegensatz zu
MSCDEX in seinem CDS-Eintrag nicht das 'Local CD-ROM-Bit'.
Daher k�nnte theoretisch das Laufwerk f�lschlicherweise
in Netzlaufwerksauflistungen auftauchen (allerdings f�r
PNW nicht notwendig), sicherheitshalber k�nnen Sie mit
Hilfe von INSTCDEX.EXE /CDROM dieses Bit nachtr�glich
setzen. Dieses Bit hat nichts mit der Option /S zu tun.
Zu guter Letzt noch eine Anmerkung am Rande (die Details,
die zu diesem Verhalten f�hren, sind noch nicht genauer
eingekreist): Wechselt man eine CD-ROM-Medium, w�hrend
man sich auf dem zugeh�rigen CD-ROM-Laufwerk in einem
Unterverzeichnis befindet, so synchronisiert der Kernel
erst dann auf die Verzeichnisstruktur des neuen Mediums
(d.h. dessen Wurzelverzeichnis), wenn man explizit darauf
wechselt (z.B. mit "CD\"). Alle anderen Dateioperationen
auf dem Laufwerk werden mit 'Ung�ltiger Pfad' zur�ckge-
wiesen; der Pfad bleibt auf der Einstellung f�r das vor-
herige Medium stehen und kann 'weiterverwendet' werden,
wenn man das zugeh�rige Medium wieder einlegt. Nicht ganz
unlogisch, aber auch nicht unbedingt ergonomisch in jeder
Situation.
Und noch ein interessanter Hinweis: Der CD-ROM-Umadres-
sierer IMSCDEX aus IMS REAL/32 (einem Nachfolger von
DR Multiuser DOS), ist nichts weiter als eine modifizierte
Fassung von Novells NWCDEX.EXE (1.00).
PASSWORD.EXE Einstellen und L�schen von Datei-, Pfad-, und globalen
Pa�w�rtern (wie auch bei DR DOS), aber zus�tzlich auch
die Angabe eines Anmeldungspa�wortes (im Rahmen des
Features der 'einmaligen Anmeldung' unter Zuhilfenahme
der SECURITY-Datenbank).
Alle dateibezogenen Novell DOS Kommandos, die bei ihrer
Bearbeitung auf pa�wortgesch�tzte Dateien/Pfade sto�en
k�nnten, erlauben nach der Angabe der Dateispezifikation
- getrennt durch ein Semikolon - die optionale Angabe
des jeweiligen Pa�wortes (dies wird zwar im DOSBOOK
beschrieben, ist aber ansonsten fast undokumentiert).
Au�erdem ist die gleiche Schreibweise auch innerhalb
der Eingabemasken von beliebigen Fremdprogrammen erlaubt,
falls diese nicht in Unkenntnis von Novells Feature das
Semikolon als ung�ltiges Zeichen zur�ckweisen. Diese
erweiterte Syntax war auch schon bei DR DOS vorhanden.
Das Ganze funktioniert auch in DOS-Boxen von Windows
und betrifft sogar die Windows-Anwendungen selbst, falls
diese unter Novell DOS oder DR DOS laufen.
Beispiele:
F�r Novells COMMAND.COM und externe Kommandos:
DIR c:\autoexec.bat;password
Unter 4DOS ist die Angabe von DR DOS/Novell DOS-
Pa�w�rtern ebenfalls m�glich, wegen der Kollision mit
deren Dateilisten (inclusion list) mu� das Semikolon
allerdings bei (fast allen) 4DOS.COM internen Kommandos
verdoppelt werden:
DIR c:\autoexec.bat;;password
Tricks zur Vermeidung dieser Kompatibilit�tsschw�che
in Kapitel II.9. (Achtung: Verwenden Sie nicht 4DOS 5.51/
5.52a TYPE mit pa�wortgesch�tzte Dateien: Aufgrund eines
Bugs in 4DOS st�rzt sonst der Rechner ab.)
Wie offiziell dokumentiert, werden Pa�w�rter mit PASSWORD
gesetzt, �berpr�ft und gel�scht (wobei das �berpr�fen etwa
mit PASSWORD *.* nicht mit gesch�tzten Verzeichnissen
funktioniert). Die erweiterte Syntax mit Semikolon dient
hingegen dazu, das Pa�wort beim Zugriff auf die Dateien und
Verzeichnisse angeben zu k�nnen (wenn sie nicht mit dem
globalen Pa�wort �bereinstimmen). Undokumentiert ist aller-
dings die M�glichkeit, mit dieser erweiterten Syntax auch
implizit Pa�w�rter zu *setzen*:
Beispiele:
ECHO Hello World!> c:\test.txt;password
setzt implizit das PASSWORD /R:password f�r die erzeugte
Datei c:\test.txt (Inhalt: "Hello World!")
COPY c:\test.txt;password c:\test2;newpassword
Genauso ist es m�glich, mit COPY oder MOVE Befehlen auch
direkt ein neues Pa�wort f�r die Zieldatei anzugeben, denn
wie noch gezeigt wird, wird der Schutz dabei normalerweise
aufgehoben.
MD c:\test;password
setzt implizit das PASSWORD /P:password f�r das erzeugte
Verzeichnis c:\test\
Obwohl dies im Gro�en und Ganzen auch unter 4DOS funktio-
niert, gibt es dort noch einige Schwierigkeiten, so da�
man bei gemischten Systemen auf diese implizite Angabe
von neuen Pa�w�rtern verzichten sollte: Teilweise akzep-
tiert 4DOS hier nur ein Semikolon und nicht die Verdop-
pelung (etwa bei CD), au�erdem k�nnen Pa�w�rter bei 4DOS
nicht in Umleitungen verwendet werden. Der Befehl
ECHO Hello World!> c:\test.txt;;password
bewirkt bei 4DOS etwas v�llig anderes als bei COMMAND.COM:
Die erzeugte Datei c:\test.txt enth�lt
"Hello World! ;;password" statt "Hello World!". Es d�rfte
sich hier um einen Bug in 4DOS handeln (4DOS.COM 5.5c,
5.51, 5.52a), vgl. auch Kapitel II.11.
Ein echtes Problem entsteht unter 4DOS, wenn man auf
pa�wortgesch�tzte Dateien zugreifen m�chte, die in pa�-
wortgesch�tzten Verzeichnissen liegen. Der Novell DOS
Kernel will hier (aufgrund der 4DOS-internen Behandlungs-
weise) grunds�tzlich *beide* Pa�w�rter wissen (auch dann,
wenn man sich bereits im jeweiligen Verzeichnis befindet).
Unter Novells COMMAND.COM wird dies - von ausf�hrbaren
Dateien abgesehen - normalerweise nicht ben�tigt, wenn
man sich bereits im entsprechenden Verzeichnis befindet.
Aber auch, wenn man von au�en auf eine solche Datei zu-
greifen will, gibt es unter Novell DOS' und DR DOS'
COMMAND.COM eine zwar einleuchtende, aber undokumentierte
Eingabevariante:
c:\testdir sei pa�wortgesch�tzt mit
Pa�wort "hello" und
c:\testdir\dummy.txt sei pa�wortgesch�tzt mit
Pa�wort "world"
TYPE c:\testdir;hello\dummy.txt;world funktioniert!!!
Diese Schreibweise (oder die Verwendung von sp�ter noch
vorzustellenden Master-Pa�w�rtern) ist *immer* notwendig,
wenn es darum geht, Programmdateien zu starten, die in
pa�wortgesch�tzten Verzeichnissen liegen, selbst dann,
wenn man sich bereits in dem entsprechenden Verzeichnis
befindet.
Unter 4DOS wird diese besondere Form der Dateispezifikation
zur�ckgewiesen (auch mit verdoppeltem Semikolon).
Au�erdem ist problematisch, da� Pa�w�rter unter MS-DOS und
PC-DOS generell als Eingabefehler zur�ckgewiesen werden.
Dieses Problem l��t sich f�r Batchjobs, die unter jedem DOS
funktionieren sollen, auf zwei Weisen aus dem Weg r�umen:
Entweder man verzichtet auf diese Syntax und arbeitet mit
st�ndig anzupassenden globalen Pa�w�rtern (PASSWORD /G).
Die andere M�glichkeit besteht darin, die Pa�w�rter in
Umgebungsvariablen unterzubringen. Dies wird in Kapitel
II.9. ausf�hrlicher beschrieben.
Da man mit den gespeicherten Einzelpa�w�rtern keine Datei-
gruppen bearbeiten k�nnte, kann man mit PASSWORD auch ein
'globales' Pa�wort definieren, das automatisch bei allen
Pa�wortabfragen eingesetzt wird. Dieses Pa�wort bleibt im
laufenden System (nicht auf der Festplatte) aktiv, bis es
wieder aufgehoben wird oder bis man den Rechner neu bootet.
Zwischenzeitlich kann man trotzdem mit expliziten anderen
Pa�w�rtern arbeiten.
Da unter Windows die wenigsten Programme in Dateieingabe-
masken die Angabe eines Semikolon akzeptieren, werden Sie
besonders hier auf die Angabe eines Master-Pa�wortes
(PASSWORD /G) ausweichen m�ssen. Da im laufenden System
nur ein Master-Pa�wort existiert (auch in unterschiedlichen
Tasks eines Multitaskers) k�nnen Sie zu diesem Zweck auch
problemlos eine DOS-Box �ffnen und dort das Master-Pa�wort
angeben, das sofort auf alle Windows- und DOS-Applikationen
wirkt.
Der Pa�wortschutz kann (bei Novell DOS 7) 'offiziell' drei
verschiedene Hierarchieebenen umfa�en:
/R:password Schutz vor allen Operationen (auch Lesen=Read)
(/P: f�r Verzeichnisse wirkt im Prinzip wie
/R: f�r Dateien)
/W:password Schutz vor Schreiben und Modifizieren (Write)
Kann Gelesen und
/D:password Schutz vor L�schen, Umbenennen und Verschieben
Da es hier auch in der Literatur immer wieder Verwechsel-
ungen gab: Es besteht ein signifikanter Unterschied darin,
ob alle Dateien eines Verzeichnisses mit einem Pa�wort
gesch�tzt werden, oder ob das Verzeichnis selbst pa�wort-
gesch�tzt wird!
Angenommen, C:\TESTDIR\ sei das Verzeichnis:
PASSWORD c:\testdir /R:test sch�tzt alle Dateien aus
c:\testdir\*.* mit "---",
PASSWORD c:\testdir /P:test l��t die Dateien in
C:\TESTDIR v�llig in Ruhe
(k�nnen eigenen Pa�wort-
schutz besitzen oder auch
nicht) und versieht das
Verzeichnis C:\TESTDIR\
selbst mit dem Pa�wort-
schutz "---"
Gro�-/Kleinschreibung bei der Angabe von Pa�w�rtern wird
ignoriert. Bez�glich sinnvoller Namensvergabe f�r Pa�w�rter
siehe Kapitel VI.7.
Achtung: Der Umfang des Pa�wortschutzes wird bei
Novell DOS 7 PASSWORD mit Masken wie "---", "RWD", usw.
angegeben. Hier besteht gro�e Verwechselungsgefahr:
DR DOS 6.0 PASSWORD gab die Bits n�mlich noch genau
invertiert an!
D.h. bei DR DOS wurde ein "-" angezeigt, wenn der Pa�wort-
schutz f�r die jeweilige Operation NICHT gesetzt war
(irgendwie logisch), normale Dateien hatten also "---".
Bei Novell DOS 7 werden stattdessen die 'Rechte' an der
Datei ohne Angabe eines Pa�wortes angegeben, d.h. normale
Dateien haben "RWD". Obwohl ich pers�nlich die alte Logik
bevorzuge (da sie der internen Realisierung in der API-
Funktion und der Verzeichnisstruktur entspricht, wohlge-
merkt bei DR DOS *und* Novell DOS), verwende ich in diesen
Dokumenten (au�er in DRDOS6UN.TXT und DRDOSTIP.TXT) die
neue Schreibweise, wie von Novell DOS 7 verwendet.
Noch alles klar? ;-)
M�chte man ein Pa�wort wieder aufheben, benutzt man
�blicherweise PASSWORD /N, das automatisch bei allen
pa�wortgesch�tzten Dateien nach dem Pa�wort fragt. Der
Parameter /N erlaubt jedoch keine direkte Angabe des
Pa�wortes: K�nnte man die Angabe jedoch auch �ber die
Dateispezifikation vornehmen (Wildcards, Listendateien
und Dateilisten sind erlaubt), so kann man die Angabe
auch vorweg vornehmen (etwa in Batchjobs), z.B.:
PASSWORD *.txt;password /N
Pa�w�rter k�nnen nicht �ber ein Netzlaufwerk vergeben/
verschickt werden (w�re ja auch unsicher, die in der
Dateispezifikation enthaltenen Pa�w�rter unverschl�sselt
�ber das Netz zu senden). Der Zugriff auf entfernte
Dateien, die pa�wortgesch�tzt sind, ist - im Rahmen der
Zugriffsrechte des Benutzers - also nur in dem Ma�e
m�glich, wie f�r die Operation kein Pa�wort n�tig ist.
Ung�ltige Operationen werden mit einem Ger�tefehler
zur�ckgewiesen ("Schutz vor Recht").
Ob dieses Verhalten sich in Multiuser-Varianten �ndert,
kann ich nicht sagen, auf diese Weise besteht aber eine
M�glichkeit, die Zugriffsrechte auch zwischen entfernten
Benutzern und lokalen Benutzern aufzuteilen und zus�tzlich
zu den Dateiattributen und den jeweils geltenden Zugriffs-
rechten des jeweiligen Benutzer-Accounts auf dem Laufwerk
einzustellen.
Aus dem oben Beschriebenen kann man ein sinnvoll pa�wort-
gesch�tztes System aufbauen, indem alle Dateien jedes
Benutzers mit jeweils einem anderen Pa�wort versehen
werden. Ausgeschlossen davon bleiben andere wichtige
Dateien, die Pa�wortgruppen wie 'System', 'ProjektX'
zugeordnet werden sollten. Gibt nun der jeweilige Benutzer
beim Systemstart *sein* globales Pa�wort (im Rahmen der
lokalen Benutzerkonten) an, kann er nicht versehentlich
andere Dateien bearbeiten, die anderen Benutzern geh�ren
oder f�r die Systemfunktion notwendig sind. Dieses Pa�wort
kann man �ber die Sicherheitsfunktion 'einmalige Anmeldung'
auch f�r den jeweiligen Account im PNW-Netz verwenden, so
da� sich jeder Benutzer nur einmal einloggen mu�.
Pa�wortgesch�tzte Dateien bekommen das Hidden-Attribut,
werden aber unter Novell DOS/DR DOS trotzdem ganz normal
angezeigt. Auch wenn man dieses Hidden-Attribut wieder
l�scht, bleiben die Dateien nat�rlich pa�wortgesch�tzt.
Unter 4DOS.COM werden normalerweise Dateien mit Hidden-
Attribut nicht angezeigt bzw. bearbeitet, solange man bei
dem entsprechenden Kommando nicht explizit diese Dateien
einschlie�t (so sagt es die 4DOS-Dokumentation).
Allerdings wurde auf meinem Testsystem (4DOS 5.5c) das
Verhalten von Novell DOS kopiert, indem pa�wortgesch�tzte
Dateien (fast) ganz normal angezeigt bzw. bearbeitet
werden k�nnen, als w�re das Hidden-Attribut nicht gesetzt
(bis auf die optionale Attribut-Einf�rbung bei DIR-Aus-
gaben, hier wird die den Attributen entsprechende Farbe
gew�hlt und das Hidden-Attribut nicht ignoriert). Wichtig
ist nur, da� man das Pa�wort angibt.
Achtung: Die Pa�w�rter werden bei Kopieroperationen (z.B.
mit COPY oder XCOPY) nicht an neue Dateien vererbt. D.h.,
man mu� zwar vor der Ausf�hrung im Rahmen des gesetzten
Schutzes ein Pa�wort angeben, aber eine kopierte Datei ist
dann nicht automatisch wieder pa�wortgesch�tzt und mu� bei
Bedarf wieder neu gesch�tzt werden (entweder implizit �ber
die Angabe eines Pa�wortes in erweiterter Syntax oder
explizit mit PASSWORD). Au�erdem wird ein gesetztes Hidden-
Attribut gel�scht.
Bei Verwendung von Kommandos wie REN[AME] werden das Pa�-
wort und die Attribute �bernommen. Au�erdem werden in
diesem Fall auch die restlichen Felder des reservierten
Bereichs der Verzeichnisstruktur �bernommen, so da� auch
andere Daten, wie DR DOS 6.0 Owner-IDs und alles andere
gleich bleiben (mehr dazu etwas weiter unten). In diesem
Punkt ist die Unterst�tzung f�r Owner-IDs mit Novell DOS 7
also nicht weggefallen, d.h. alle Daten, die auf irgend-
eine Weise mit dem Verzeichniseintrag der Datei verkn�pft
wurden, werden dann vom System solange mitgeschleppt, bis
die Datei gel�scht wird (auf welche Weise auch immer,
siehe folgende Bemerkungen bei MOVE).
Das Kommando MOVE ist eine Mischung aus REN[AME] und COPY,
daher ist auch das Verhalten davon abh�ngig, ob effektiv
ein REN oder ein COPY ausgef�hrt wird: Solange die Datei
effektiv nur umbenannt (d.h. innerhalb des gleichen Lauf-
werks verschoben) wird, verh�lt sich alles wie bei REN
(das bezieht sich �brigens auf die physikalischen Lauf-
werke, d.h. Substitut-Laufwerke etc. werden korrekt
ber�cksichtigt). Wird die Datei jedoch effektiv kopiert
(auf ein anderes physikalisches Laufwerk), so wird wie bei
COPY auch MOVE der Pa�wortschutz bei der Zieldatei ent-
fernt, allerdings das Hidden-Attribut nicht gel�scht (das
d�rfte ein Bug in der Implementation von MOVE sein).
Allerdings wird die Datei nicht wirklich verschoben,
sondern trotz MOVE nur kopiert. Das bedeutet, da� die
Quelldatei am Ursprung weiterhin vorhanden bleibt und
�ber die gleichen Attribute und Pa�wortschutz wie bisher
verf�gt.
Dieses Verhalten wird auch unter 4DOS nachgeahmt, au�er
da� die Kommandos bei fehlender Pa�wortangabe nicht
w�hrend der Bearbeitung des Kommandos automatisch das
Pa�wort erfragen, d.h. das Pa�wort mu� immer beim Aufruf
angegeben werden und damit kann es Schwierigkeiten geben,
wenn w�hrend der Abarbeitung mehrere unterschiedliche Pa�-
w�rter angegeben werden m�ssen und man nicht mit einem
Master-Pa�wort arbeitet.
Unter anderen Betriebssystemen (wie MS-DOS oder PC-DOS),
die diese Pa�wortfunktionen nicht kennen, sind die pa�wort-
gesch�tzten Dateien stattdessen versteckt, aber nach Ent-
fernen des Hidden-Attributs ohne Pa�wort zug�nglich!
Damit besteht also auch eine M�glichkeit, an Dateien
heranzukommen, deren Pa�wort vergessen wurde. Diese m�ssen
unter MS-DOS oder PC-DOS nur 'effektiv' in eine neue Datei
kopiert werden (also nicht nur REN), danach kann man auch
unter Novell DOS/DR DOS wieder an diese Dateien heran-
kommen. Entscheidend daf�r, ob der Pa�wortschutz aktiv ist
oder nicht, ist die Kernel-Implementation, nicht die des
Kommandoprozessors.
Problematisch ist lediglich, da� auch pa�wortgesch�tzte
Verzeichnisse das Hidden-Attribut besitzen und dieses
Attribut mit dem normalen ATTRIB-Kommando bei Verzeich-
nissen nicht zur�ckgesetzt werden kann. Hier mu� man
entweder auf Fremd-Utilities oder Disk-Editore ausweichen,
die diese Kombination nicht zur�ckweisen (gibt es noch aus
der Zeit, wo DOS selbst noch kein ATTRIB kannte), oder z.B.
den Norton Commander zuhilfe nehmen (die Option 'Show
Hidden-Files' mu� aktiviert werden). Im NC kann man dann
ganz normal in diesem versteckten Verzeichnis arbeiten.
Will man den Schutz aufheben, sollte man den Verzeichnis-
inhalt zwischenspeichern, das gesch�tzte Verzeichnis
l�schen, und danach wieder alles zur�ckkopieren.
Alternativ dazu ist es im Norton Commander auch m�glich,
das Hidden-Attribut von Verzeichnissen zu l�schen. Danach
kann man dann auch wieder DOS-Befehle auf das Verzeichnis
anwenden.
Eine verwandter Trick, um ein Hidden-Attribut eines Ver-
zeichnisses zu l�schen, ist es, mit PASSWORD ein Dummy-
Pa�wort f�r das Verzeichnis zu setzen und direkt danach
wieder zu l�schen. Dabei wird dann auch das Hidden-Attribut
gel�scht.
�brigens: Ein Pa�wort bleibt (zumindest mit DELWATCH) auch
erhalten, wenn eine Datei gel�scht und danach wieder ent-
l�scht wird.
Etwas zur Physik der Verzeichniseintr�ge:
Die Pa�w�rter werden bei Novell DOS und DR DOS uni-
direktional verschl�sselt in bei MS-DOS reservierten Be-
reichen innerhalb der 32 Byte gro�en Verzeichniseintr�ge
gespeichert: Das unidirektional verschl�sselte Pa�wort
liegt als Pr�fsumme bei Offset +0Eh (WORD) (von Windows95
f�r das Erzeugungszeitpunkt einer Datei benutzt), die
Zugriffssperren WRED (Write/Read/Execute/Delete) jeweils
f�r "World", "Group" und "Owner" im leider auch von OS/2
benutzten Feld "EA-Handle" bei Offset +14h (Word), und
zwar in der Bit-Logik, wie bei DR DOS angegeben (d.h.
invers zu der Ausgabe von PASSWORD bei Novell DOS 7).
Normalerweise haben diese drei Bit-Gruppen unter
'Singleuser' DR DOS/Novell DOS immer den gleichen Wert
(0000h, 0111h, 0555h, 0DDDh). Man erkennt, da� die mit
PASSWORD einstellbaren drei Kombinationen von Zugriffs-
rechten nur einen Bruchteil der m�glichen Kombinationen
abdecken. Der Schutz f�r Verzeichnisse entspricht
�brigens auch 0DDDh, auch wenn die API-Funktionen selbst
etwas anders angesprochen werden m�ssen.
PASSWORD setzt (zumindest unter dem �blichen 'Singleuser'
Novell DOS 7) die Access-Rights gleichzeitig f�r alle
drei internen Benutzerklassen "World", "Group" und "Owner",
und kennt jeweils auch nur "RWD" (nichts, bzw. /N), "RW-"
(/D), "R--" (/W) und "---" (/R), da diesbez�glich nur bei
Multiuser-Varianten unterschieden wird (bei DR DOS ist die
Funktionsweise zwar gleich, aber die Bits werden genau in
umgekehrter Logik angezeigt, s.o.). Auch haben die drei
Execute-Lock-Bits (nicht angezeigt) unter DR DOS/Novell DOS
keine Bewandtnis (und wurden wohl nur von FlexOS benutzt).
Sollte Execute-Lock doch gesetzt sein, wird es als Read-
Only-Recht (nicht Attribut!!!) behandelt, allerdings nur,
wenn zus�tzlich auch andere Bits gesetzt sind. Die Execute-
Lock-Bits und die restlichen 4 unbenutzten Bits werden bei
�nderungen in den Zugriffsrechten nicht angetastet.
Beim Testen der Zugriffsrechte wertet 'Singleuser' DR DOS/
Novell DOS offenbar alle drei Gruppen nach einem noch unbe-
kannten Schema aus und bildet daraus 'ungef�hr' die Access-
Rights, die am meisten restriktiv sind.
Au�erdem wird im Attribut-Byte (Offset +0Bh) das Hidden-
Attribut gesetzt, aber davon h�ngt der Pa�wortschutz nicht
ab. Die Zugriffsrechte haben nichts mit den �blichen Datei-
attributen zu tun, obwohl sie auch so etwas wie 'Attribute'
darstellen!!! Weil es ein Read-Only-Dateiattribut, einen
Read-Only-Pa�wortschutz und im Netz noch Read-Only-
Zugriffsrechte in Abh�ngigkeit vom Laufwerk und Benutzer
gibt, und im speziellen auch noch SHARE-Modi f�r die
erlaubten Zugriffsvarianten auf eine Datei verantwortlich
sind, kommen viele Benutzer hier immer wieder durcheinander
(ist zugegebenerma�en auch nicht einfach).
Wie weiter oben beschrieben wurde, werden diese
Eintr�ge in der Verzeichisstruktur normalerweise vom
System �ber die gesamte 'echte' Lebensdauer dieser
Datei mitgeschleppt; die bei Novell DOS 7 weggefallene
Unterst�tzung f�r DR DOS 6.0 Owner-IDs lie�e sich also
relativ leicht wieder mit einem kleinen Treiber re-
implementieren (siehe auch bei DELWATCH.EXE und in
Ralf Browns Interrupt-Liste INTER53+).
Einige �ltere Plattenpflegeprogramme meckern die ver-
�nderten Eintr�ge auch als Fehler in der Plattenstruktur
an, was aber nat�rlich nicht stimmt. L��t man sie von
solchen Programmen korrigieren, ist das Schlimmste, was
passieren kann, ein aufgehobener Pa�wortschutz.
Die Pa�w�rter sollten keinerlei Probleme mit Long-
Filename-Support (wie bei MS-DOS 7 aus MS Windows95
aktivierbar) bereiten. Auch das bei MS-DOS 7 neue Last-
Access-Datum bei Offset +12h (Word) ist unkritisch
(ACCDATE=). Allerdings kollidieren die Pa�w�rter mit
OS/2 Extended Attributes und MS Windows95 Datei-Erzeugungs-
zeitpunkt, sollten in diesem Fall also nicht verwendet
werden. Eine Belegungs�bersicht gibt Kapitel II.21.
Fest steht, da� bei geeigneter R�cksichtnahme in der
Implementation alle anderen Funktionen (Microsofts Long-
Filenames & ACCDATE= sowie Novells DELWATCH und Pa�w�rter)
kollisionsfrei nebeneinander existieren k�nnten. Einzige
Ausnahme scheint das Datei-Erzeugungsdatum von MS Windows95
zu sein, das daraus resultierende Verhalten habe ich aber
noch nicht untersucht (selbst das k�nnte bedingt sogar
klappen). (Siehe auch DELWATCH.EXE und in Kapitel II.21.).
PNUNPACK.EXE Undokumentiertes Entpackprogramm von Novell DOS, PNW und
NetWare Lite.
PNUNPACK [/?] [@]source [target] [/O]
@ bei Angabe einer Listendatei
source Quelldatei (kann Laufwerk und Pfad enthalten)
target Zieldatei/pfad
/O �berschreiben existierender Dateien erlauben
Dieses Programm akzeptiert auch Wildcards, solange alle
damit spezifizierten Dateien gepackt sind. Innerhalb einer
gepackten Datei k�nnen auch mehrere Dateien gepackt sein.
Normalerweise unterscheidet sich die Dateiendung der
gepackten Dateien durch ein '_' als letztes Zeichen,
dies ist aber keine notwendige Voraussetzung. Da bei
Novell DOS und PNW die urspr�nglichen Dateinamen intern
abgelegt sind, k�nnen die alten Namen auch dann wieder
hergestellt werden, wenn die Datei umbenannt wurde. Vor
den gepackten Daten befindet sich ein Header "Packed File
xxxxxxxx.xxx"+1Ah+02h, wobei xxxxxxxx.xxx der wirkliche
Dateiname ist.
In Verbindung mit Wildcards ist an PNUNPACK problematisch,
da� es bei einem Fehler die Operation nicht nur f�r die
jeweilige Datei, sondern komplett abbricht. Dem kann man
mit folgendem Batchjob abhelfen:
FOR %%x IN (%1) DO PNUNPACK %%x %2 %3 %4 %5 %6 %7 %8 %9
Im Client Kit (VLMKT1.EXE bis VLMKT6.EXE bzw. dem neueren
VLM121_1.EXE bis VLM121_6.EXE) wird ein sehr �hnliches
Programm NWUNPACK.EXE mitgeliefert, das offenbar weitest-
gehend kompatibel ist.
Sollten Sie z.B. mit bestimmten Dateien von NetWare Lite
(mit Dateiendung .??@) Probleme mit der Benutzung von
PNUNPACK haben, indem PNUNPACK einen ung�ltigen Dateinamen
als Ziel angibt und dann abbricht, l��t sich das Problem
leicht aus dem Weg r�umen, indem Sie den Header der
gepackten Datei mit einem Hex-Editor (oder DEBUG)
patchen: H�chstwahrscheinlich ist lediglich der Eintrag
xxxxxxxx.xxx, der oben erw�hnt wurde, ung�ltig. Schreiben
Sie hier einfach einen g�ltigen Dateinamen hin (es reicht,
die Zeichen bis zur folgenden Null mit einem beliebigen
Buchstaben zu �berschreiben). Die so ge�nderte Datei
sollte von PNUNPACK problemlos auf den gepatchten
Dateinamen hin entpackt werden k�nnen.
PRINT.COM Die Angabe des Ger�tes f�r die Ausgabe l��t leider nur
die vom System vordefinierten Ger�te PRN, AUX, CON, LPT1-3
und COM1-4 zu, auch wenn man durch entsprechende Ger�te-
treiber weitere Devices eingebunden hat. (Dies ist aller-
dings bei MS-DOS genauso.)
Da dies vielen Benutzern nicht klar ist: Der Drucker-
puffer, den PRINT einrichtet, mu� nicht etwa gro� genug
sein, um alle gew�nschten Dateien gleichzeitig aufnehmen
zu k�nnen (dann w�rde PRINT viel zu viel Speicherplatz
kosten, als da� es etwas nutzen k�nnte), sondern es
handelt sich dabei lediglich um einen Zwischenpuffer,
der die Daten enth�lt, die unmittelbar vor der Ausgabe
an den Drucker stehen. Normalerweise ist daher die
Default-Einstellung, die mit 512 mehrere Zeilen eines
Textes fassen kann, schon reichlich bemessen.
Neben diesem Zwischenpuffer ben�tigt der residente Teil
von PRINT auch noch Platz f�r die Liste von Dateinamen,
die in der Warteschlange zum Ausdruck stehen. Pro Datei-
spezifikation sind ca. 70 Bytes zu veranschlagen, die
Default-Einstellung 10 Dateien schl�gt als mindestens
ebenso zu Buche, wie der Puffer selbst. Defaultm��ig
werden vom gesamten residenten Treiber ca. 6 KByte Speicher
ben�tigt.
PRINTER.SYS Geh�rt bei MS-DOS 7 und PC-DOS 7 nicht mehr zum Liefer-
umfang, ist bei Novell DOS 7 aber noch vertreten:
DEVICE = PRINTER.SYS dev=(typ [,hwcp] [,n]) ...
dev Druckerschnittstellen: PRN, LPT1, LPT2 oder LPT3
PRN und LPT1 identisch; die Einstellung eines Ger�tes
konfiguriert automatisch auch innerhalb des Treibers
das jeweils andere Ger�t mit.
(PRN ist evtl. bei MS-DOS nicht m�glich.)
typ Druckertypen: 1050, 4201, 4208 oder 5202
hwcp Hardware-Codetabelle: 0..32767 (z.B. 437)
(auch 32768..65535, mit �berlauf in der Anzeige
von MODE als negative Zahlen)
n Anzahl vorzubereitender Codetabellen (1..12),
f�r die Speicher reserviert werden mu� (werden
sp�ter mit MODE CODEPAGE PREPARE belegt)
Andere Typen werden leider nicht zur Verf�gung gestellt
und durch die Festverdrahtung ist es anscheinend auch
nicht ohne weiteres m�glich, eigene Typen zu generieren
und einzubinden (h�chstens unter einem falschen Namen
durch das Ersetzen eines vorhandenen Druckertyps):
Die Sequenzen zur Steuerung des Druckers stammen -
zumindest f�r die Hardware-Codeseite - offensichtlich
nicht aus einer sp�ter mit MODE zugeordneten .CPI-Datei,
sondern sind direkt in PRINTER.SYS kodiert. Zum Teil
gilt das offenbar auch noch f�r andere Druckertypen,
zumindest f�r alle Treiber vom Typ 2 (Codeseiten-Um-
schaltung statt Download-Daten). Gute Erfahrungen habe
ich bisher nur mit dem Ersetzen der 1050.CPI Datei (eine
Datei mit Download-Daten) durch eigene .CPI-Dateien
gemacht. Siehe auch Kapitel II.16.
Achtung: Die bei PRINTER.SYS notwendige Angabe der Code-
seite bezieht sich auf die hardware-m��ig installierte
Codeseite des Druckers (da DOS dies nicht �berpr�fen kann,
mu� diese Angabe �berhaupt erst vorgenommen werden). Auch
wenn Sie sp�ter mit Codeseite 850 etc. arbeiten wollen,
m�ssen Sie hier in den allermeisten F�llen noch die Code-
seite 437 angeben. In Druckerhandb�chern wird diese Ein-
stellung oft als IBM Zeichensatz 2, World Trade Character
Set oder PC-8 Zeichensatz bezeichnet. Die Zuordnung zu
Codeseite 437 erhalten Sie bei den meisten Druckern �b-
licherweise dann, wenn der Drucker den obigen Zeichensatz
aktiviert hat, und f�r die Zeichen 128..255 die IBM-Grafik-
zeichen statt der Epson-Schr�gschrift (Italics) benutzt.
Wenn Sie hier eine andere Codeseite als die wirklich unter-
st�tzte Hardware-Codeseite angeben, kann die Codeseiten-
Unterst�tzung von DOS sp�ter nicht sauber arbeiten, da sie
von falschen Voraussetzungen ausgeht. Eine Ausnahme davon
ist die Angabe einer Dummy-Kennung f�r die Hardware-Code-
seite (meine Empfehlung: 999), z.B. wenn Sie eine fremde
.CPI-Datei verwenden und sicherstellen wollen, da� wirklich
alle Steuerinformationen f�r diesen Drucker aus der .CPI-
Datei und nicht aus dem PRINTER.SYS-Treiber kommen.
In diesem Fall m�ssen Sie aber bei PRINTER.SYS *jede*
sp�ter genutzte Codeseite vorbereiten (also �blicherweise
eine mehr, da die Nutzung der Hardware-Codeseite (meist
437) dann flachf�llt).
Beachten Sie bitte, da� PRINTER.SYS in Abh�ngigkeit vom
verwendeten Drucker und Anzahl der vorzubereitenden
Codeseiten (n) unterschiedlich viel Platz beansprucht:
Drucker: Typ: Basis-Code: + Code/Daten je Codeseite:
4201 1 (DL-Fonts) ca. 1616 Bytes + n * ca. 7000 Bytes
4208 2 (Page-Switch) 1616 Bytes + n * 496 Bytes
5202 2 (Page-Switch) 1120 Bytes + n * 496 Bytes
1050 1 (DL-Fonts) 1600 Bytes + n * 2304 Bytes
Die L�nge der Datenbereiche repr�sentieren also gleich-
zeitig Obergrenzen f�r die L�nge der Sequenzen, die zum
Drucker geschickt werden k�nnen (wobei der Platz nicht
nur f�r die Sequenz selbst, sondern auch f�r jeweils
zus�tzlichen Code ben�tigt wird).
F�r jedes Ger�t (PRN/LPT1, LPT2, LPT3) wird bei Bedarf ein
kompletter eigener PRINTER.SYS Treiber installiert.
Die Details bez�glich der Unterscheidung von Hardware-
und vorzubereitenden Codeseiten sind sehr ausf�hrlich
bei DISPLAY.SYS in diesem Kapitel beschrieben, hier nur
zwei Beispiele:
Einrichtung des "1050"-Treibers f�r alle
Epson FX850/1050-kompatiblen Drucker
(in dessen Grundeinstellung f�r USA):
CONFIG.SYS:
DEVICE=c:\nwdos\printer.sys prn=(1050,437,1)
AUTOEXEC.BAT:
MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
CHCP 437
Ersetzung des "1050"-Treibers durch eine eigene
.CPI-Datei, hier f�r die NEC Pinwriter Serie:
CONFIG.SYS:
DEVICE=c:\nwdos\printer.sys prn=(1050,999,2)
AUTOEXEC.BAT:
REM (NECPINW.CPI kann �ber mich bezogen werden.)
MODE prn: CODEPAGE PREPARE=((437,850) ...\necpinw.cpi)
CHCP 437
Weitere Hinweise finden sich auch bei MODE.COM in
diesem Kapitel.
Hinweis: In vielen Betriebsanleitungen von Matrix- und
Tintenstrahldruckern finden Sie einen Hinweis, da� der
Drucker im deutschen Sprachraum auf deutsche Landesein-
stellungen umgestellt werden sollte (per Software-Setup
oder DIP-Schalter). Viele Anwender setzen daraufhin die
Hardware-Konfiguration auf 'Deutsch' und wundern sich dann,
warum sie unter DOS manche Zeichen (z.B. den Backslash)
nicht richtig ausdrucken k�nnen. Nun, das Problem liegt
ganz einfach darin begr�ndet, da� auch die PCs in ihrer
Grundkonfiguration nicht 'deutschsprachig' sind, sondern
f�r US-amerikanische Verh�ltnisse konstruiert sind, d.h.
Codetabelle 437 des von IBM erweiterten ASCII-Zeichensatzes
mit 256 Zeichen verwenden. Daher sollte auch der Drucker
in der US-amerikanischen Einstellung verbleiben (ist meist
die Werkseinstellung), so da� PC, Drucker und DOS zun�chst
einmal mit dem gleichen zugrundeliegenden Zeichensatz (437)
arbeiten. F�r die Druckereinstellung 'Deutsch' gibt es
keine Entsprechung in den Codetabellen von DOS; in
Wahrheit handelt es sich hierbei auch nur um ein Relikt
aus l�ngst vergessenen Tagen, wo unter ASCII noch aus-
schlie�lich ein 7Bit-Zeichensatz (mit 128 Zeichen) ver-
standen wurde und damalige Typenraddrucker (Diabolo) und
fr�he Matrixdrucker (haupts�chlich von Epson) in einem be-
stimmten Codefenster (sog. Substitut-Codeseiten) je nach
Landesvariante wichtige nationale Buchstaben zugeordnet
hatten, wodurch es damals im deutschen Sprachraum �berhaupt
erst die M�glichkeit zur Verwendung von Umlauten und '�'
gab (diese entsprechen ISO 646 in deutscher Anpassung, bzw.
ISO 21). In der Codetabelle 437 liegen diese Buchstaben
jedoch im Bereich von 128..255, daher st�rt heutzutage ein
auf 'deutsche Konventionen' eingestellter Drucker nur den
reibungslosen Ablauf (es sei denn, Sie arbeiten mit Uralt-
Textverarbeitungen aus CP/M-Zeiten...).
RECOVER.COM Liefert Errorlevel 3 bei Benutzerabbruch durch <Ctrl>+<c>
(verifiziert f�r Novell DOS 7).
RESTORE.COM RESTORE ist mit allen BACKUP Versionen von DR DOS
und MS-DOS/PC-DOS kompatibel.
Weitere Hinweise siehe BACKUP.COM.
RESTORE sollte nicht auf Laufwerke angewendet werden, auf
die ASSIGN, JOIN oder SUBST wirkt (Vorsichtsma�nahme).
Das Format der Datums-/Zeitangaben h�ngt von der jeweiligen
COUNTRY-Einstellung ab.
Parameter�bersicht (alles von DR DOS bekannt):
/A:tt.mm.jj Nachladen von Dateien, die an oder nach dem
angegebenen Datum ge�ndert wurden.
/B:tt.mm.jj Nachladen von Dateien, die an oder vor einem
dem Datum ge�ndert wurden.
/E:hh:mm:ss Nachladen von Dateien, die an oder vor dem
angegebenen Zeitpunkt ge�ndert wurden.
/L:hh:mm:ss Nachladen von Dateien, die an oder nach dem
angegebenen Zeitpunkt ge�ndert wurden.
/M Nachladen von Dateien, die seit dem letzten
Sichern ge�ndert oder gel�scht wurden.
/N Nachladen von Dateien, die im Zielbereich
nicht mehr existieren.
/P Fragen vor dem Nachladen von seit der
letzten Sicherung ge�nderten Dateien
(bei DR DOS auch schreibgesch�tzte Dateien).
/R Angabe der Dateien, die nachgeladen W�RDEN
ohne diese jedoch wirklich nachzuladen.
Testet auch die Unversehrtheit der
Disketten.
/S Nachladen auch von Dateien in Unterver-
zeichnissen. Unterverzeichnisse werden
automatisch erstellt, allerdings nicht, wenn
man gleichzeitig die Option /R angibt (bei
DR DOS 6.0 Updates vor 1992 war dies noch
anders).
MS-DOS 6.0+ RESTORE bietet eine 'neue' Option /D an, die
von Novells RESTORE nicht unterst�tzt wird. Genau diese
Funktion wird aber bei Novell DOS mit der Option /R er-
f�llt, die bei DR DOS 6.0 noch nicht vorhanden war.
Errorlevel (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 4.0+, Novell DOS 7,
Caldera OpenDOS 7.01, DR DOS 6.0 und CCI Multiuser DOS 7.22
Gold)
0 normales Ende
1 keine Dateien zur Wiederherstellung gefunden
2 einige Dateien wegen Zugriffskonflikt nicht wieder-
hergestellt
3 Ende der Wiederherstellung mit <Ctrl>+<Break>
4 Abbruch der Wiederherstellung durch Fehler oder
ung�ltiger Parameter angegeben
SCREATE.COM (auch SFORMAT)
SDRES.EXE Der Viren-Scanner Search & Destroy 33.01 liegt f�r DOS und
SDSCAN.EXE MS Windows jeweils als residentes Programm und als normale
WSDRES.EXE Applikation vor (die deutsche �bersetzung von SDRES ist
WSDSCAN.EXE allerdings katastrophal).
Es ist keine Schande, irgendwann einmal eine virenver-
seuchte Diskette/CD zu bekommen, aber es ist sehr wohl
eine Schande, es im Falle eines Falles an der n�tigen
Sorgfalt in der Vor- und Nachsorge fehlen zu lassen!!!
Dazu geh�rt es u.a.
- den Verursacher ausfindig zu machen und umgehend zu
benachrichtigen,
- alle Rechner, an denen man zuletzt gearbeitet hat,
zu untersuchen und alle anderen Benutzer von ver-
seuchten Rechnern zu warnen,
- alle verwendeten Diskettenbest�nde mit aktuellen
Viren-Scannern zu �berpr�fen,
- entdeckte Viren zu vernichten (durch Desinfizieren
oder L�schen der betreffenden Dateien, Formatieren
der Diskette oder notfalls physikalisches Zerst�ren
des Mediums, siehe auch in Kapitel II.4. bei FDISK,
FORMAT und SYS). Sollten infizierte Disketten aus
besonderen Gr�nden aufbewahrt werden, m�ssen diese
auff�llig als mit einem Virus verseucht gekennzeichnet
werden,
- sich angew�hnen, den Schreibschutz von Disketten
wirklich nur dann zu entfernen, wenn man bewu�t auf
eine Diskette schreiben m�chte (m.E. die h�ufigste
und schlimmste Nachl�ssigkeit vieler Benutzer),
- Fremd-Disketten vor der Benutzung zu scannen.
Wenn Sie h�ufig Disketten an 'ungesicherten Orten' (z.B.
Firma oder Institut) beschreiben, kann ich nur dringend
empfehlen, *immer* einen residenten Viren-Scanner im
Hintergrund laufen zu haben (und zwar zu einem Zeitpunkt
installiert, wo Ihr eigenes System mit Sicherheit noch
unverseucht war). Die Optionen, jede neu eingelegte
Diskette und jede ausf�hrbare Datei automatisch zu scannen,
sollte unbedingt aktiviert sein (schlie�lich kostet das
nur Sekundenbruchteile).
Ich habe pers�nlich mit einem resident installierten
SDRES (ins EMS ausgelagert) wesentlich bessere Erfahrungen
gemacht, als etwa mit McAfees residentem Viren-Scanner
VSHIELD: Bei einem nicht repr�sentativen Testlauf mit
einigen im Laufe der Zeit 'gesammelten' virenverseuchten
Disketten zeigte sich SDRES (s�mtliche Scanner-Optionen
aktiviert) als sehr viel zuverl�ssiger als z.B. VSHIELD
(eine Version von Herbst 1996!). Alle verseuchten Disketten
wurden erkannt. SDRES hat durch seine Alarmmeldungen schon
manches Mal eine Virenverseuchung *meiner* Rechner ver-
hindert!!!
Und bei Versuchen mit einem virenverseuchten Rechner
(nicht meiner ;-) ) konnten SDRES/SDSCAN sogar Viren
zuverl�ssig erkennen *und* beseitigen, obwohl der Virus
aktiv im Speicher war. Zu diesem Zweck wurde der Virus
'totgepatcht'. McAfees SCAN und VSHIELD sind in dieser
Situation zu keinem von beiden geeignet.
Die Aufruf-Syntax von SDRES.EXE und SDSCAN.EXE akzeptiert
sowohl '/' als auch '-' als Parametereinleitungszeichen.
Auf meinem System wurden vom SETUP-Programm f�r SDRES.EXE
die Optionen "-uc:\nwdos\sdscan.exe -m 640" gew�hlt. Diese
Einstellung ist jedoch nicht effektiv, vor allem mu� die
Angabe f�r den Scanner mit -s eingeleitet werden. Auf
meinem System arbeitet "-sc:\nwdos\scscan.exe 640" zu-
friedenstellend, allerdings konnte sich SDRES.EXE auf
meinem System entweder nur in UMBs laden oder zum gro�en
Teil in EMS auslagern. Im letzten Fall wurden auf meinem
System lediglich 1,9 KByte vom Basisspeicher abgezwackt,
die sich nicht hochladen lie�en. Dies kann man aber fast
immer verschmerzen.
Die Angabe 640 steht f�r die �bliche Gr��e des Basis-
speichers. In einigen F�llen (besonders auf Rechnern
neuerer Generation mit SCSI- und PCI-Bussen) wird aber
von diesem Speicher schon standardm��ig ein ca. 1 - 5
KByte gro�er Bereich f�r interne Zwecke abgezweigt, in
solchen F�llen (und nur dann) sollten Sie die Angabe 640
entsprechend reduzieren, um eine prompte Warnung von SDRES
zu verhindern.
Im Zusammenhang mit der Speicherkonfiguration von SDRES
noch ein Hinweis f�r 4DOS-Benutzer:
Sofern SDRES sich in EMS auslagern soll, d.h. einen
1,9 KByte gro�en Stummel im konventionellen Speicher
hinterl��t, sollten Sie unbedingt die Hinweise in Kapitel
V.8. beachten.
�ber die Tastenkombination <Ctrl>+<Alt>+<u> kann man das
Konfigurationsmen� von SDRES aufrufen und zur Laufzeit auf
drei Seiten (<PageUp>, <PageDown>) die Scanner-Optionen
einstellen. Das Fenster kann sich nur in �blichen Textmodi
einblenden, und auch nur dann, wenn eine Applikation keinen
eigenen Tastaturtreiber mitbringt, ansonsten poppt das
SDRES-Fenster erst auf, nachdem man die Anwendung verlassen
hat. Leider habe ich in SDRES selbst keine M�glichkeit
entdecken k�nnen, diese Einstellungen auch direkt abzu-
speichern, so da� sie auch nach dem n�chsten Booten noch
verf�gbar w�ren. Auch die Kommandozeile bietet nur minimale
Einstellungsm�glichkeiten und in SDSCAN.EXE lassen sich
ebenfalls keine Einstellungen f�r SDRES.EXE/WSDRES.EXE
vornehmen. So erscheint es zun�chst notwendig, die Scanner-
Optionen bei jedem Booten neu einzustellen oder mit der
Standard-Einstellung (die bei Weitem nicht alle M�glich-
keiten aktiviert) vorlieb zu nehmen. Gl�cklicherweise ist
dem nicht so:
Als Workaround kann man n�mlich MS Windows starten und
dort WSDRES.EXE aufrufen (das in die AUTOSTART-Gruppe auf-
genommen werden sollte). Das Programm verkleinert sich
sofort auf Symbolgr��e. Wenn man auf das Symbol klickt
und 'Wiederherstellen' w�hlt, kann man jedoch alle Ein-
stellungen von SDRES.EXE und WSDRES.EXE �ndern und auch
abspeichern. Diese Einstellungen werden sofort von einer
evtl. in DOS laufenden SDRES.EXE Version �bernommen und
sind dann auch nach dem n�chsten Booten wieder aktiv!
Die Bedienung der normalen Scanner SDSCAN.EXE und
WSDSCAN.EXE d�rfte keine Probleme bereiten. Es sei
lediglich darauf verwiesen, da� die Version f�r MS Windows
(WSDSCAN.EXE) auch die Optionseinstellungen f�r die
residenten Programme SDRES.EXE und WSDRES.EXE zul��t
(dabei sind sogar zwei zus�tzliche Optionsseiten verf�gbar,
die in den residenten Programmen selbst nicht angeboten
werden: 'Ressourcen' und 'Messages'. Dazu geh�ren die
Einstellung der Hochladem�glichkeiten, die Angabe der
Speichergr��e, die Angabe des im Notfall zu startenden
Viren-Scanners und der zu verwendenden Datenbank, die
M�glichkeit zur Laufzeitkonfiguration, die Auswahl-
m�glichkeiten bei Virenalarm u.a. Anscheinend werden
aber nicht alle dieser Einstellungen sofort von einer
bereits gestarteten Version von SDRES/WSDRES �bernommen.
Wenn man WSDSCAN erst nachtr�glich per Hand in ein
bestehendes MS Windows System einf�gt, kam es auf meinen
Testsystemen (MS-DOS 6.22) manchmal dazu, da� sich der
Scanner in der Startphase aufhing. Vermutlich mu� man
noch eine Einstellung in der Windows-Konfiguration �ndern,
denn auf Systemen, wo das Novell DOS SETUP-Programm
Search & Destroy eingerichtet hat, traten diese Probleme
nicht auf.
Die Konfigurationsdaten f�r alle 4 Programme werden in der
'Untouchable'-Datenbank UT.CDB gespeichert. Au�erdem werden
noch UI.CDB, VIR-INFO.VRB und WSDSCAN.HLP ben�tigt. Die
Dateien BWCC.DLL und DEFAULT.INI (mit angepa�ten Pfaden)
werden von den Scannern ebenfalls genutzt, aber k�nnen
h�ufig auch entfallen.
Da die Virendatenbank aus dem Jahre 1994 ist und im Rahmen
der Novell DOS 7 Updates noch kein Update f�r diese
Datenbank ausgeliefert wurde, mu� man sich dieses entweder
von Fifth Generation besorgen (unklar) oder sollte auf
andere Viren-Scanner wie F-PROT oder McAfees SCAN nicht
verzichten.
Trotzdem bieten die mit Novell DOS 7 ausgelieferten Scanner
auch jetzt noch (11/1996) einen gewissen Schutz, da die
residenten Programme nicht nur nach bestimmten Viren
suchen, sondern auch heuristisch bestimmte nicht an einen
bestimmten Virus gekn�pfte Aktivit�ten aufdecken k�nnen.
Die deutsche �bersetzung von SDRES ist �u�erst holprig und
fehlerbehaftet. Leider hat der Fehlerteufel auch nicht
vor dem Alarm-PopUp-Fenster halt gemacht. Die Frage
'Abbruch', 'Weiter' kann man z.B. nicht mit <w> f�r
'Weiter' quittieren, sondern mu� stattdessen <c> f�r
'Continue' dr�cken (in einem Buch habe ich einen Hinweis
auf <f> f�r 'Fortfahren' gefunden, es k�nnte sich hier
noch um eine Beta-Version gehandelt haben). Gl�cklicher-
weise gilt dies nicht auch noch f�r <a> = Abbruch = Abort.
Die SDRES-Option '�berpr�fen auf einen Begleit-Virus'
kollidiert mit der Erzeugung von .COM-Dateien mittels
EXE2BIN, weil genau dieses Verhalten (von einer ge�ffneten
.EXE-Datei wird eine gleichnamige .COM-Datei erstellt) von
vielen Viren verwendet wird. Wenn Sie EXE2BIN anwenden,
sollten Sie die entsprechende SDRES-Option also vorher
abschalten. Dies ist aber besonders bei automatisierten
Abl�ufen st�rend, hier hilft das folgende Workaround
(auch f�r ATTRIB):
REN program.exe program.ex_
EXE2BIN program.ex_ program.com
REM REN program.ex_ program.exe oder DEL program.ex_
Bei SDRES in Verbindung mit NWCACHE sollte man entweder
die '�berpr�fung der DOS Fehlerbehandlung' deaktivieren,
SDRES erst nach NWCACHE laden oder mit den SDRES-Optionen
-M und -R experimentieren. NWCACHE verbiegt die DOS-
Fehlerbehandlung w�hrend der Installation und falls zu
diesem Zeitpunkt SDRES geladen ist, wird sofort falscher
Alarm geschlagen, falls diese Option aktiviert ist (denn
mit Option -M biegt SDRES sofort den INT21h Vektor wieder
auf sich zur�ck, mit -R geschieht dies nur 'manuell').
Das gleiche Problem tritt auch auf, wenn man den TASKMGR
als Proze�umschalter startet (zumindest bei TASKMGR.INI
[Shell] Exec=True, siehe auch in den Kapiteln VII.2.,
VII.3, VII.4.). Das Starten des Multitaskers ist hingegen
unkritisch.
Auch der Aufruf von PC-Tools 9.0 MIRROR.COM f�hrt zu einem
unbegr�ndeten Viren-Alarm bez�glich eines verbogenen
'Critical Error-Handlers'.
�hnliche Probleme sind mit Dienstprogrammen wie FDISK,
FORMAT, SYS etc. zu erwarten, wenn in SDRES die ent-
sprechenden Optionen scharf gemacht wurden. Nat�rlich
handelt es sich hier nicht um eine Virenverseuchung.
Wenn man die Option 'Boot-Diskette vor Booten durchsuchen'
aktiviert hat, kann ein kleines Problem auftreten, wenn
Sie als Laufwerk A: noch ein 5.25" Laufwerk installiert
haben. Ist in diesem Laufwerk eine Diskette eingelegt und
die Verriegelung nicht geschlossen, so versucht SDRES bei
den meisten Laufwerksmodellen unendlich lange, die
Diskette zu lesen (Disketten-LED leuchtet, nichts pas-
siert). In diesem Fall hilft es nur, die Verriegelung zu
schlie�en oder *vorher* die Diskette aus dem Schacht zu
entfernen.
Die Option 'Dateien vor der Ausf�hrung durchsuchen' kann
im Netzwerk nicht mit veralteten Netz-Shells arbeiten (bis
ca. 1992-1993, ist also f�r PNW �berhaupt kein Problem,
wohl aber in vielen lange nicht gewarteten Firmennetzen
auf der Basis von NetWare 3.xx). Wird eine alte Version
der Netztreiber installiert, gibt SDRES eine Warnung aus,
da� man diesen Treiber aktualisieren mu� und deaktiviert
automatisch die obige Scan-Option. Da diese F�higkeit aber
gerade eine der wichtigsten M�glichkeiten von SDRES dar-
stellt, sollte man die Netztreiber unbedingt auch wirklich
updaten!
SDRES kann w�hrend des Starts einen 'K�der' auslegen, um
zu testen, ob bereits residente Viren darauf anspringen.
Dieses Verfahren hinterl��t bei bereits installiertem
DELWATCH eine entl�schbare ?????.IMM Datei. Um zu ver-
hindern, da� DELWATCH hiermit unn�tigerweise belastet
wird, empfiehlt es sich, im Bootverlauf SDRES erst nach
DELWATCH zu laden oder derartige Dateien mit DELWATCH
/E:IMM von der L�schverfolgung auszuschlie�en.
Wenn ein Virenalarm ert�nt, sollte man unbedingt mit jedem
Tastendruck warten, bis der Jingle verklungen ist. Wenn
dies nicht beachtet wird, kommen die Tastatur-LEDs durch-
einander: SDRES mi�braucht auf ATs im Alarmfall die
Tastatur-LEDs von AT- und MF2-Tastaturen als 'Lauflicht'
und offenbar gibt es hier einen kleinen Bug in der An-
steuerung der Tastatur...
SDRES gibt mit -? einen Hilfeschirm �ber die m�glichen
Optionen aus, bietet allerdings noch zwei weitere, un-
dokumentierte Optionen:
-V Unbekannt (V=Virus??)
-X Durchsucht den Speicher nach Viren und 'reaktiviert'
den residenten Scanner. Was dies aber genau bedeutet
ist noch nicht gekl�rt.
SDSCAN bietet ebenfalls noch zwei undokumentierte Optionen:
-M Durch Angabe dieser Option wird das automatische
Verlassen des Scanners bei einem batch-gesteuerten
Aufruf unterdr�ckt, d.h. nach dem Scandurchlauf bleibt
die Bearbeitung auf der �bersichtsseite stehen und mu�
per Hand abgebrochen werden.
-N Ruft man "SDSCAN -N" ohne weitere Optionen auf, so
wird nur der Speicher und keine Datei durchsucht (auch
in PNW-Netzen nicht), danach wird der Scanner wieder
verlassen, so da� man diese M�glichkeit gut f�r den
Batch-Betrieb benutzen kann.
Bei SDRES und SDSCAN m�ssen die Optionen nicht unbedingt
alle extra mit einem Optionseinleitungszeichen ("-" oder
"/") beginnen, es sind auch Kombinationen wie -AB statt
-A -B m�glich.
SECURITY.OVL Wird die Datei SECURITY.OVL in NWLOGIN.EXE umgenannt, kann
(NWLOGIN.EXE) darin enthaltene Programm NWLOGIN direkt aufgerufen werden.
Die Angabe eines Systempa�wortes ist kein 100% Schutz gegen
b�swillige Eindringlinge (wenn auch wesentlich sicherer als
noch bei DR DOS, wo man den Schutz durch Booten mit MS-DOS
umgehen konnte), da er mit etwas Trickserei mit Programmen
wie NDD (Norton Utilities) - evtl. unter partiellem Daten-
verlust - entsch�rft werden kann. Die Systemabsicherung
verschl�sselt n�mlich nicht etwa die Daten auf der Fest-
platte, sondern unterbindet den Zugriff auf ein Laufwerk
lediglich durch Ver�nderungen in der Partitionstabelle.
Im Rahmen der 'einmaligen Anmeldung' soll es m�glich sein,
sich mit der einmaligen Angabe des Benutzernamens und Pa�-
wortes sowohl lokal, als auch im Netz anzumelden (dazu
m�ssen neben den Netz-Accounts auch lokale Benutzerkonten
eingerichtet sein, was m�glich ist, sobald die System-
absicherung per SETUP aktiviert wurde).
Die Angabe des Masterpa�wortes gibt den lokalen Rechner
frei (f�r Notwartungsarbeiten), arbeitet aber nicht mit
der einmaligen Anmeldung zusammen.
Das Kommando UNSECURE auf der 1. Installationsdiskette
von Novell DOS 7 erlaubt es nach der Angabe des Master-
pa�wortes, einen lokalen Rechner wieder von seinem
Security-Schutz zu befreien.
SECURITY.OVL alias NWLOGIN.EXE entnimmt seine Konfiguration
der Datei %NWDOSCFG%\NWDOS.INI und wertet dort die folgen-
den Abschnitte aus, wobei Eintragungen aus [SECURITY] die
von [COLORS] �bersteuern:
[SECURITY]
CurrentColor=
[COLORS]
ColorSetX= (X=<CurrentColor> aus 1..9)
NewUI=on|off
Au�erdem werden in irgendeiner Form die Dateien
C:\NWCNTL\SECURITY und C:\@FDS.SAV verwendet.
SERNO.EXE Im DOSBOOK undokumentiert. Gibt die Seriennummer der
Betriebssystem- oder PNW-Installation aus. Die Seriennummer
wird in der Datei SETUP.INI in %NWDOSCFG% in der Gruppe
[Registration] SerialNumber=abcd-1234-123456 (entsprechend
dem Diskettenaufkleber auf der Installationsdiskette 1)
gespeichert.
Theoretisch ist auch das �ndern der Seriennummer von
Novell DOS und PNW �ber die Option /S m�glich (es kann
jeweils eine entsprechende Frage erscheinen, wobei ich
bisher nur die Frage nach der Seriennummer von DOS er-
zeugen konnte, selbst wenn PNW geladen war), allerdings
akzeptiert das Kommando nur acht- bzw. 4-4-6-stellige
Zahlenkombinationen, nicht aber die vierstellige Buch-
stabenkombination in der Seriennummer, die Novell zu-
mindest f�r die deutschen Seriennummern verwendet. (U.U.
wird auch die Datei SERVER.EXE �ber %Path% untersucht.)
Die Meldungen von SERNO sind (gewollt?) etwas irref�hrend:
Die Seriennummer wird keineswegs 'direkt auf der Platte',
sondern - wie oben beschrieben - in einer speziellen Datei
gespeichert. D.h. die Medienseriennummer, die nun auch
Novell DOS 7 (sp�testens ab Update 14) unterst�tzt, wird
nicht beeinflu�t, genausowenig werden die vorbereiteten
Felder f�r Seriennummern in den Systemdateien wie
COMMAND.COM (bei Caldera OpenDOS 7.01 �brigens mit
SeRiAlNuMbEr=xxxx-xxxx-xxxxxx gekennzeichnet, siehe auch
bei VERSION.EXE), noch werden im Boot-Sektor Eintr�ge
ver�ndert.
SETFIFO.EXE Dieses externe Kommando ist erst mit einem Update dazuge-
kommen, wohl auch, um Performance-Probleme mit seriellen
Schnittstellen zu mildern (auch unter dem Multitasker
TASKMGR). Es erlaubt den FIFO von neueren UART-Chips 16550
mit FIFO einzustellen. Das Kommando kann mit zwei Para-
metern gef�ttert werden oder fragt interaktiv nach den
notwendigen Einstellungen. Leider scheint dieser
'Quick-Hack' keine (anderen) Kommandozeilenparameter
auszuwerten und kann obendrein nur mit COM1 und COM2
arbeiten. Als wesentlich besseren Ersatz kann das
FreeWare-Utility ACOM.COM herhalten, das nebenbei
auch so ziemlich alle anderen Einstellungsarbeiten
an seriellen Schnittstellen bew�ltigen kann (zu beziehen
�ber mich - Adresse siehe oben).
SETUP.EXE (enth�lt INSTALL.EXE)
SETUP /A[DVISE] schaltet in den 'Anleitungsmodus', der das
System analysiert und ein Ergebnisprotokoll
ausgibt. Achtung: Wenn diese Datei
INSTALL.EXE hei�t, bewirkt /A etwas v�llig
anderes!!!
/COLORS Farbunterst�tzung (zumindest f�r PNW-Setup)
/STACKER F�r STACKER-Setup
/FIRST F�r PNW-Setup
Weitere ungekl�rte Optionen:
/RESULTS /DONE_SCAN /QA /QUIET
Dieses Programm akzeptiert andere Parameter, wenn es zu
INSTALL.EXE umbenannt wird. INSTALL /? gibt diese M�glich-
keiten aus.
Durch entsprechende �nderungen der Setup-Dateien l��t sich
die Setup-Prozedur in weiten Bereichen einstellen/�ndern.
Offenbar kann man den integrierten DOS-Extender??? (RTLink/
Plus) bei Bedarf mit folgenden Umgebungsvariablen f�r
die Verwendung bestimmter Speichersorten konfigurieren
(vgl. NET.EXE in Kapitel VI.9.) (0=deaktivieren):
VM-Manager: RTVMEXT, RTVMEXP, RTVMEXPLOW, RTVCONV
Overlay-Manager: RTOVEXP, RTOVEXT, RTOVCONV
Achtung: Falls Ihre CONFIG.SYS eine Dateigr��e von mehr als
7462 Bytes oder die AUTOEXEC.BAT gr��er als 9500 Bytes ist,
besteht akute Gefahr, da� SETUP.EXE Ihre Konfigurations-
dateien ab dieser Gr��e abschneidet. Sichern Sie die beiden
Konfigurationsdateien unbedingt vor dem Aufruf von SETUP
und kopieren Sie die alten Dateien zur�ck, bevor Sie den
Rechner neu starten. Mittels SETUP vorgenommene Eintr�ge
k�nnen mit FC relativ schnell gefunden werden und in Ihre
eigenen Konfigurationsdateien �bernommen werden.
SETVER.EXE Die Versionstabellen werden in der SETVER.EXE Datei selbst
gespeichert. Dabei sind optional auch Pfadangaben zu den
einzelnen Dateien erlaubt, um Doppeldeutigkeiten bei
gleichnamigen Dateien vorzubeugen (seltsamerweise funktio-
niert dies aber bei mir nicht..., im Zweifelsfall geben
Sie keine Pfade angeben). Die ausgelieferte Version
enth�lt bereits eine Reihe Voreinstellungen f�r bekannte
Programme, die eigentlich nur unter einer bestimmten
DOS-Versionsnummer laufen wollen, aber unter Novell DOS 7
auch funktionieren.
Da jeder Eintrag zur Laufzeit Speicherplatz kostet (jeweils
der vollst�ndige Dateiname plus 3 Bytes), sollten Sie zu-
n�chst alle nicht wirklich ben�tigten Eintr�ge aus der
Tabelle l�schen (Option /D).
Wegen der Ver�nderungen an der Datei sollten Sie ein
Original von der Installationsdiskette (unter einem
anderen Namen) aufbewahren.
Gibt man eine ung�ltige DOS-Version f�r eine Datei an, so
wird Errorlevel 1 zur�ckgeliefert. Erlaubte Versionsnummern
sind x.y (Hauptversion.Unterversion) jeweils im Bereich
0..255, wobei der 255 als Unterversionsnummer eine un-
dokumentierte Sonderfunktion zukommt (s.u.).
Die vorget�uschten Versionsnummern beziehen sich auf den
'offiziellen' DOS-API Call (INT21h/30h) f�r Versionscheck,
nicht auf die API-Funktion zur Ermittlung der 'wahren'
DOS-Version (INT21h/3306h, Novell DOS 7 liefert hier
�brigens selbst mit Update 15 immer noch Revision 00) und
auch nicht auf DR DOS/Novell DOS ureigene Versions-APIs
(INT21h/4451h und INT21h/4452h).
Ausnahme: Wurde eine Unterversion 255 angegeben (also
x.255), so liefert zwar INT21h/30h ebenfalls diese
Versionsnummer zur�ck, aber zus�tzlich wird die Novell DOS-
eigene Versionsabfrage INT21h/4452h mit Fehlercode AX=0001h
beantwortet. Sollte es ein Programm geben, das bewu�t auf
DR DOS/Novell DOS abtestet, um dann unter diesem Betriebs-
system die Arbeit zu verweigern, so kann man hiermit die
entsprechende Interrupt-Funktion f�r dieses Programm
einfach verschwinden lassen und das Programm kann nicht
mehr erkennen, da� es unter DR DOS/Novell DOS gestartet
wird... Testet ein Programm hingegen 'echte Funktionalit�t'
von DR DOS/Novell DOS ab, so l��t sich dies nat�rlich nicht
mit diesem kleinen Schwindel �berlisten...
Neben den dokumentierten Parametern kennt Novells SETVER
noch zwei undokumentierte Parameter:
/G version �ndert die globale Versionsnummer, die f�r
alle Programme gemeldet wird, die nicht
extra aufgelistet werden.
(Standard ist 6.00, da Novell DOS 7 das
API von IBM PC-DOS 6.1 nachbildet, das den
API-Level 6.00 hat und mit MS-DOS 6.00
�bereinstimmen d�rfte.)
Wenn Sie wollen, k�nnen Sie hier mit
/G 7.00 Novell DOS 7 zu seiner wahren
Versionsnummer verhelfen, dies k�nnte
aber eine Reihe Kompatibilit�tsprobleme
mit Anwendungen verursachen... ;-)
Die oben beschriebene Ausnahme gilt auch
f�r die globale Versionsnummer.
Ist DEVICEHIGH=SETVER.EXE nicht geladen,
gibt sich Novell DOS 7 immer als PC-DOS 6.1
(d.h. API-Level 6.00) aus (zumindest alle
Versionen von Update 3 bis Update 15). Es
ist m�glich, da� sich ganz fr�he Versionen
von Novell DOS 7 wirklich als "Novell DOS
6.00, API-Level 6.00" ausgegeben haben.
/P "Page" h�lt die Ausgabe nach jeder Seite
an.
Sollten Ihnen die M�glichkeiten von SETVER f�r einen
speziellen Anwendungsfall nicht ausreichen, k�nnen Sie von
mir das FreeWare-Tool FREEVER.COM anfordern, das �hnlich
wie SETVER.EXE Versionsnummern t�rken kann, sich dabei aber
nicht auf INT21h/30h beschr�nkt, sondern auch die wahre
Versionsnummer INT21h/3306h und die DR DOS/Concurrent DOS/
DR Multiuser DOS/Novell DOS Versionsabfragen bei
INT21h/4412h, 4451h und 4452h detailgetreu nachbildet.
Au�erdem emuliert das AMIS-konforme Tool das SETDRVER.COM-
API und MS-DOS 4 INT2Fh/122Fh. Nat�rlich ist die Anwendung
nicht ungef�hrlich und erfolgt ausschlie�lich auf Ihr
Risko!
SHARE.EXE Dieses TSR sollte bei Novell DOS 7 unbedingt geladen
werden. Im Gegensatz zu (zumindest �lteren) MS-DOS Ausgaben
besitzt der Novell DOS 7 Kernel keine (oder nur sehr
eingeschr�nkte) SHARE-Funktionalit�t (bei alten DR DOS
Ausgaben war SHARE dahingegen wohl haupts�chlich bereits
Bestandteil des Kernels und intern v�llig anders
realisiert). Um also ein mit MS-DOS gleichwertiges
System zu erhalten, mu� SHARE geladen werden (besonders
f�r Multitasker und MS Windows). Die urspr�ngliche Version
war auf maximal 1024 Dateisperrungen beschr�nkt, mit
Update 13 (SHARE 2.03) wurde jedoch eine Version ausge-
liefert, die bis zu /F:60000 oder /L:4900 erlaubt, wobei
der Speicher (12 Bytes pro Sperrung) im Gegensatz zu fr�her
dynamisch alloziert wird, so da� der Speicher nur dann
belegt wird, wenn er auch wirklich ben�tigt wird. Mit
Update 13 wurde SHARE 2.04 ausgeliefert.
Siehe auch Kapitel V.4.
Bez�glich FILES= und FCBS= sei auf Kapitel III.1. ver-
wiesen. Insgesamt k�nnen vom System maximal 255 Handles
zur Verf�gung gestellt werden, nat�rlich gibt es innerhalb
von Applikationen und in Netzen die M�glichkeit, diese
Schranke in Eigenregie zu umgehen (daher macht es auch
Sinn, da� SHARE mehr Dateien verwalten kann).
DR DOS 3.41-6.0 bot noch eine Option /X zum Deakti-
vieren von SHARE nach dem Laden. Diese Option wird von
Novell DOS 7 nicht mehr unterst�tzt, weil die neue MS-DOS-
konforme Implementation dies nicht mehr erlauben w�rde.
SORT.EXE Im Gegensatz zu MS-DOS 6.2x SORT.EXE kann Novells SORT
auch problemlos Dateien/Umleitungsdaten mit mehr als
64 KByte bearbeiten! Da SORT i. allg. in Verbindung mit
Umleitungen angewendet wird, sollte jedoch genug Platz
auf dem Tempor�rlaufwerk frei sein.
SORT verwendet nach M�glichkeit die landesspezifischen
Einstellungen zur Bestimmung der Sortierreihenfolge (in
einigen B�chern wird das Gegenteil behauptet, vermutlich
war auf den Testsystemen die Landesunterst�tzung falsch
konfiguriert).
M�chten Sie eine Datei nach den Konventionen eines anderen
Landes sortieren, m�ssen Sie vorher mit einem kleinen
Utility wie COUNTRY.EXE das 'aktuelle Land' umstellen
(siehe auch Ralf Browns Interrupt-Liste) oder CONFIG.SYS
COUNTRY= �ndern und neu booten).
F�r den Parameter /+n mit n=Offset der Spalte, ab der
sortiert werden soll, sind Werte von 0..65535 zul�ssig,
d.h. SORT kommt auch mit exotischen Textdateien zurecht.
Anscheinend wirkt /+0 dabei genauso wie /+1, was auch dem
Default-Wert entspricht, wenn man nichts angibt (jedenfalls
konnte ich bisher keinen Unterschied feststellen).
Beispiel (Sortieren eines Verzeichnisses nach Dateigr��e):
DIR *.* | SORT /+14 | MORE
Bez�glich der sicheren Verwendung in Batchjobs siehe
Kapitel IV.6.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 normale Bearbeitung
1 offenbar bei MS-DOS/PC-DOS: Datei zu gro� (gr��er
64 KByte). Bei Novell DOS wahrscheinlich nicht belegt,
da Novell DOS auch mit gr��eren Dateien zurecht kommt.
2 Benutzerabbruch (<Ctrl>+<c>)
4 falscher Parameter
STACHIGH.SYS Verwendet %Path%, %DirCMD%, SDIR/DIR.COM??, STACKER.INI
und bietet anscheinend besondere Unterst�tzung f�r DIR,
CHKDSK, DEFRAG und DBLSPACE. SDIR.COM ist ein Tool, das
zu den einzeln erh�ltlichen Versionen von STACKER mitge-
liefert wird, bei Novell DOS 7 ist es nicht enthalten,
weil DIR entsprechend erweitert wurde (SDIR bietet �brigens
auch undokumentierte Parameter...).
SUBST.EXE Obwohl dieses Kommando rein �u�erlich genau die gleichen
Funktionen wie bei MS-DOS bereitstellt, ist es doch intern
besser realisiert: Z.B. k�nnen Sie auch implizite Lauf-
werksangaben machen, wie etwa:
SUBST i: c:\nwdos
SUBST j: i:\cfg (wenn c:\nwdos\cfg existieren w�rde)
SUBST k: c:\nwdos
SUBST l: k:.
Ein Detail ist aber noch nicht ganz zu Ende gedacht (ist
aber eine Frage der Kernel-Implementation, nicht der von
SUBST): Wenn Sie einen Verzeichnisnamen �ndern, der gleich-
zeitig in der Wurzel eines substituierten Laufwerks liegt,
so wird diese Laufwerkszuordnung aufgehoben und auf das
Wurzelverzeichnis gesetzt und nicht - wie es sinnvoller
w�re - dem neuen Laufwerksnamen zugeordnet. Etwa:
Eingabe: Ausgabe:
SUBST m: c:\test1
RENDIR c:\test1 c:\test2
SUBST "m: c:\" statt "m: c:\test2"
Ein Fehler ist das allerdings nicht, versuchen Sie dies
'mal bei MS-DOS...
Interessante Optimierungsm�glichkeiten des Speicherbedarfs
residenter TSRs in Verbindung mit SUBST finden sich bei
LH in Kapitel II.11. (gelten auch f�r INSTALLHIGH=).
Novells SUBST kennt die von CCI Multiuser DOS 7.22 her
bekannte Option /B f�r eine batch-konforme Ausgabe in
Verbindung mit Umleitungen leider nicht.
Errorlevel (nur f�r Novell DOS 7 verifiziert):
0 ok
1 ung�ltiger Parameter, zuwenig Parameter
3..67 nur Novell DOS: Entspricht der L�nge des
TRUENAMEs eines ge�nderten SUBST-Laufwerks
(bei diesen Errorleveln k�nnte es sich um ein
�u�erst praktisches Zufallsresultat handeln).
Um eine Vorstellung von der sinnvollen Verwendung der
Errorlevel von Novells SUBST zu geben, hier ein
praktisches Beispiel. Der folgende Batchjob erlaubt
(in meiner Konfiguration) das komfortable, aber sicher-
lich noch verbesserungsw�rdige Umsetzen des Tempor�r-
laufwerks, das hier unter dem Buchstaben T:\ verf�gbar
sein soll:
SETTMP.BAT:
@ ECHO off > \dev\nul
REM 1995-11-25 -mp
IF NOT ""=="%1" GOTO start
ECHO SETTMP: Changes temporary drive/dir setting.
ECHO Syntax: SETTMP ['reset'] [path\]
:start
IF ""=="%1" GOTO end
IF "reset"=="%1" GOTO reset
SET old_tmp=%tmp%> \dev\nul
SET old_temp=%Temp%> \dev\nul
SET tmp=%1> \dev\nul
SET Temp=%tmp%> \dev\nul
GOTO perform
:reset
IF NOT ""=="%old_tmp%" SET tmp=%old_tmp%> \dev\nul
IF NOT ""=="%old_temp%" SET Temp=%old_temp%> \dev\nul
SET old_tmp=> \dev\nul
SET old_temp=> \dev\nul
:perform
c:
CD \
@ SUBST t: /d > nul
@ SUBST t: %tmp%
IF NOT "NWDOS"=="%Os%" IF NOT "OPENDOS"=="%Os%" ...
... GOTO end
IF NOT ERRORLEVEL 4 ECHO Warning: Root dir specified!
IF NOT ERRORLEVEL 4 IF EXIST t:\*.* DIR t:\*.*
:end
SYS.COM Beim 'SYS'en' eines Boot-Mediums wird der Boot-Sektor des
jeweiligen Laufwerks �berschrieben und es werden die beiden
zum Booten notwendigen 'BIOS'- und 'DOS'-Dateien (bei
Novell DOS: IBMBIO.COM und IBMDOS.COM) von einem boot-
f�higen Medium �berspielt. Au�erdem wird der Kommando-
prozessor (ohne den keine Eingaben am Prompt m�glich w�ren)
kopiert. Daf�r wird die Variable %ComSpec% ausgewertet,
vgl. Kapitel IV.7.
Achtung: Die Datei, auf die %ComSpec% zeigt, wird als
Kommandoprozessor notwendigerweise - da die Existenz einer
CONFIG.SYS Datei mit einem Eintrag SHELL= nicht vorausge-
setzt werden darf - unter dem Namen COMMAMD.COM auf das
Boot-Medium kopiert. Dies geschieht auch dann, wenn man
nicht mit COMMAND.COM, sondern etwa mit 4DOS.COM arbeitet.
Das System kann problemlos von einem solchen Medium booten;
der 'falsche' Name COMMAND.COM und das abweichende Ver-
halten k�nnte aber einen arglosen Benutzer etwas ver-
wundern. Wenn Sie das st�rt, und Sie in jeder Situation
sicherstellen wollen, da� COMMAND.COM auf das Bootmedium
�bertragen wird, k�nnen Sie folgendes probieren:
SYS.BAT:
@COMMAND /C SYS.COM %1 %2 %3 %4 %5 %6 %7 %8 %9
Dabei ist es wichtig, da� SYS.BAT in einem Batch-
Verzeichnis liegt, das in %Path% vor dem C:\NWDOS\
Verzeichnis durchsucht wird. Au�erdem m�ssen Sie
beachten, da� Sie die Dateiendung von SYS.COM angeben
m�ssen, damit keine Rekursion entsteht (auch bei MS-DOS
hat das SYS-Programm die Endung .COM).
Die bei SYS unter MS-DOS ebenfalls �bertragenen Dateien
DBLSPACE.BIN/DRVSPACE.BIN werden nicht ber�cksichtigt,
m�ssen also ggf. nachtr�glich umkopiert werden.
Bei DR DOS 5.0+/Novell DOS k�nnen die Systemdateien offen-
bar an beliebiger physikalischer Stelle auf dem Laufwerk
liegen, bei MS-DOS 6.0+ gilt dies in dieser Allgemeinheit
nur f�r Floppies (fr�her noch nicht einmal das, man denke
an FORMAT /B), wodurch mit MS-DOS manchmal Probleme auf-
tauchen, wenn mehr als eine DOS/Windows-Betriebssystem-
version auf der gleichen Partition installiert ist.
Ein spezielles Problem tritt in Multi-Boot-Konfigurationen
auf (etwa mit Novells LOADER-Tool, das z.B. zum Liefer-
umfang von CCI Multiuser DOS 7.22 Gold geh�rt und problem-
los auch mit Novell DOS, OpenDOS, MS Windows95 mit Dual-
Boot und/oder dem OS/2-Bootmanager zusammenarbeitet): Sind
die Namen der Systemdateien in der meisten F�llen unter-
schiedlich (IO.SYS und MSDOS.SYS bei MS-DOS, BOOT.SYS bei
CCI Multiuser DOS, oder IBMBIO.COM/IBMDOS.COM bei PC-DOS),
so tritt in Verbindung mit DR DOS 5.0+, Novell DOS 7 oder
Caldera OpenDOS das Problem auf, da� diese Systeme die
gleichen Dateinamen verwenden. Viele Boot-Manager sind
mit dieser Konstellation �berfordert und k�nnen PC-DOS
nicht parallel zu einem System der DR-Familie installiert
haben, selbst leistungsf�hige Boot-Manager haben oft
Schwierigkeiten, mehrere Versionen des gleichen Systems
(etwa DR DOS 5.0, DR DOS 6.0, Novell DOS 7 oder OpenDOS)
nebeneinander bootf�hig installiert zu haben. Hier hilft
eine SYS-Option weiter, der ab DR DOS 6.0 existiert:
Mit dem undokumentierten Parameter "SYS /DR:ext" kann man
SYS.COM veranlassen, beim Schreiben des Boot-Sektors und
der IBMBIO.COM-Datei die Dateiendungen interner Referenzen
auf die Standardnamen (d.h. im Bootsektor auf IBMBIO.COM
und in IBMBIO.COM auf IBMDOS.COM und [D]CONFIG.SYS) auf
den Wert von "ext" zu patchen: Bei DR DOS 6.0 sollte man
�blicherweise "SYS /DR:DR6" angeben, bei Novell DOS 7
entsprechend "SYS /DR:NW7". Auf diese Art und Weise
ist es sogar m�glich, die Kernel-Dateien mehrerer
Novell DOS 7 Updates nebeneinander bootf�hig zu halten
(etwa /DR:D01, /DR:D02, usw.). Ein Beispiel:
SYS /DR:NW7 a:
schreibt einen Bootsektor, der die Datei IBMBIO.NW7
statt der Datei IBMBIO.COM l�dt. Diese Datei IBMBIO.NW7
entspricht dem Original bis auf einen Patch, der seiner-
seits auf die Dateien IBMDOS.NW7 statt IBMDOS.COM, und
auf [D]CONFIG.NW7 statt auf [D]CONFIG.SYS verweist.
Innerhalb dieser Datei kann man mit einer modifizierten
SHELL= Anweisung auf einen anderen Kommandoprozessor und
eine andere AUTOEXEC.BAT Datei verweisen, sonst wird -
wie �blich - COMMAND.COM und AUTOEXEC.BAT gew�hlt. Auf
diese Weise ist eine saubere Trennung der einzelnen
Kernel-Dateien m�glich. Die Syntax f�r SHELL= lautet z.B.:
SHELL=c:\nwdos\command.com c:\nwdos /P:autoexec.nw7
Hat man bereits ein Multi-Boot-System mit LOADER und
Konsorten eingerichtet, ist die Anwendung von SYS auf
die so pr�parierte Partition immer mit dem Risiko ver-
bunden, da� dabei der Boot-Manager durch das Neuschreiben
des Boot-Sektors oder gar des MBRs wieder abgekoppelt
wird. Aus diesem Grunde empfehle ich in solchen Situa-
tionen, von Diskette das betreffende Betriebssystem aus
der DR-Familie zu booten und dann unter Zuhilfenahme der
/DR:ext Option eine andere Diskette bootf�hig zu machen.
Von dieser Diskette kann man dann die entsprechend
modifizierten Dateien IBMBIO.??? und IBMDOS.??? in das
Hauptverzeichnis des ersten Festplattenlaufwerks kopieren
und die LOADER.INI Datei mit einem normalen Text-Editor
manuell um die Eintr�ge f�r das neue System zu erweitern.
�brigens kann man durch das �ndern der Dateiendung auf
eine nicht ausf�hrbare Endung auch einem anderen Fehler
vorbeugen, n�mlich der M�glichkeit, versehentlich (etwa
im NC) eine der Dateien IBMBIO.COM oder IBMDOS.COM zu
starten (z.B. .SYS oder .BIN). Dies f�hrt sonst un-
weigerlich zum Absturz des Systems. Nicht ohne Grund
sind diese beiden Dateien mit Hidden- und System-
Attributen versehen.
Bemerkung: F�r ein zuk�nftiges Update f�r Calderas
OpenDOS 7.01 habe ich den Startcode von IBMBIO.COM so
modifiziert, da� er - falls f�lschlicherweise als normales
Programm gestartet - ohne Absturz zur Kommandozeile
zur�ckkehrt. Wann diese Sicherheitsfunktion in die
offizielle Version Einzug halten wird, ist jedoch noch
nicht abzusehen.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok
3 Benutzerabbruch (<Ctrl>+<c> etc.), oder
kann Boot-Sektor nicht schreiben
4 Syntax-Fehler
In manchen F�llen mag es notwendig sein, direkten Zugriff
auf den Boot-Sektor eines Laufwerks zu bekommen (z.B. um
den Boot-Sektor zu retten oder um einen eigenen modifi-
zierten Boot-Sektor aufzuspielen). Dies kann man mit Hilfe
von DEBUG bewerkstelligen. Beachten Sie, da� der Boot-
Sektor eines Laufwerks nichts mit dem Master-Boot-Sektor
(MBR) zu tun hat, den man mit FDISK bearbeiten kann (siehe
bei FDISK in Kapitel II.4.). In beiden folgenden Beispielen
steht ??? f�r die nullbasierte Laufwerksnummer (A:=0, B:=1,
C:=2), d.h. �blicherweise wird man hier 2 als Boot-Laufwerk
einsetzen!
Speichern des Boot-Sektors des jeweiligen Laufwerks in
einer Datei \BOOTSECT.BIN:
DEBUG
-L 100 ??? 0 1
-Rcx=200
-N \bootsect.bin
-W
-Q
Aufspielen eines neuen (pr�parierten) Boot-Sektors auf
ein Laufwerk aus einer Datei \BOOTSECT.BIN:
DEBUG \bootsect.bin
-W 100 ??? 0 1
-Q
SYS.COM kann man auch prima zum Entfernen von Boot-Viren
(etwa der weitverbreitete "PARITY B"-Virus) benutzen,
solange das laufende System selbst noch nicht verseucht
ist: Einfach das Medium neu 'SYS'en', wodurch der in-
fizierte Boot-Sektor �berschrieben wird. Danach kann man
die drei System-Dateien auch wieder l�schen, vgl. Kapitel
II.4. bei SDRES.
TOUCH.EXE Es gibt neben den dokumentierten Parametervarianten noch
TREE.COM eine speziell selektive undokumentierte Syntax, die die
XDEL.EXE Angabe eines Benutzeranmelde- oder Gruppennamens erlaubt
XDIR.EXE (Syntax: /U:name; der Name darf normalerweise maximal
12 Zeichen lang sein). Diese Option ist nicht in jeder
Betriebssystemkonfiguration verf�gbar und hat eine
besondere Bedeutung in Novell/DR Multiuser-Varianten oder
bei lokalen Benutzerkonten und bei einmaliger Anmeldung,
sofern die Systemabsicherung aktiviert ist.
Haben Sie schon mal das Problem gehabt, da� Sie den Inhalt
eines kompletten Laufwerks mit XDIR.EXE /S ausgeben lassen
wollten und XDIR.EXE dann nach einiger Zeit mit einer
Fehlermeldung abbricht, es h�tte nicht genug Speicherplatz
einige 10.000 Dateien zu Sortieren?
Wenn Sie lediglich eine �bersicht �ber alle Dateien haben
wollten, k�nnen Sie in diesem Fall auf XDIR.EXE /S /N
oder das Kommando TREE.COM /F ausweichen, wobei die Dateien
dann nicht sortiert werden.
F�r Hinweise zu TOUCH.EXE siehe auch bei ATTRIB.EXE.
Errorlevel f�r Novell DOS 7 TOUCH (unvollst�ndig):
0 ok, Hilfe
31 kein Dateiname, Syntax-Fehler, TOUCH f�r einige
Dateien fehlgeschlagen
Errorlevel f�r Novell DOS 7 TREE (unvollst�ndig):
0 ok
1 Syntax-Fehler, Laufwerks(zugriffs-)fehler
3 Benutzerabbruch (<Ctrl>+<c> etc.)
4 Lesefehler (Diskette fehlt)
XCOPY.EXE Es gibt neben den dokumentierten Parametervarianten noch
eine speziell selektive undokumentierte Syntax, die die
Angabe eines Benutzeranmelde- oder Gruppennamens erlaubt
(Syntax: /U:name; der Name darf normalerweise maximal
12 Zeichen lang sein). Diese Option ist nicht in jeder
Betriebssystemkonfiguration verf�gbar und hat eine
besondere Bedeutung in Novell/DR Multiuser-Varianten
oder bei lokalen Benutzerkonten und bei einmaliger
Anmeldung, sofern die Systemabsicherung aktiviert ist.
Au�erdem wird die DR DOS Option /C auch noch bei
Novell DOS 7 unterst�tzt, ist aber undokumentiert.
Sie wirkt genauso wie die neue Option /P.
Die beiden mit MS-DOS 6.2 eingef�hrten Parameter /Y und
/-Y zur Best�tigung vor dem �berschreiben unterst�tzt
Novell DOS 7 (getestet bis Update 15) noch nicht, da es
viel fr�her eingef�hrt wurde.
Errorlevel (unvollst�ndig):
(verifiziert f�r MS-DOS/PC-DOS 4.0+, Novell DOS 7,
wahrscheinlich auch DR DOS 6.0)
0 normales Ende
1 Keine Dateien zu kopieren
2 Benutzerabbruch durch <Ctrl>+<Break> etc.
4 Initialisierungsfehler, zuwenig Speicher, ung�ltige
Optionen, Diskette voll, Datei/Pfad nicht gefunden
5 INT24h-Fehler beim Lesen/Schreiben der Daten
UNDELETE.EXE UNDELETE stellt das Gegenst�ck zu Kommandos wie DEL,
ERASE, ERA, XDEL dar und kann - je nach installiertem
L�schschutz - unterschiedlich komfortabel und sicher
bereits gel�schte Dateien zur�ckholen.
Viele Benutzer haben gewisse Anschauungsprobleme, deshalb
folgendes Bild:
Wird Novells UNDELETE auf in der DELWATCH-L�schverfolgung
befindliche Dateien angewendet (die gewisserma�en in einem
'unsichtbaren' Bereich des Laufwerk liegen), so kann man
UNDELETE auch im Kontext von Novells DELPURGE betrachten:
UNDELETE holt die gel�schten Dateien aus dem unsichtbaren
Bereich zur�ck in die Sichtbarkeit, wohingegen DELPURGE
sie zwar auch aus dieser Pufferzone entfernt, aber daf�r
'in entgegengesetzter Richtung', indem es sie dem freien
Speicherbereich des Laufwerks zuschl�gt.
Wie schon angesprochen, unterst�tzt Novells UNDELETE
neben der DOS-Methode auch DISKMAP und DELWATCH, aller-
dings keine Fremdkonzepte wie etwa das von MS-DOS/PC-Tools
UNDELETE.
PC-Tools 9.0 UNDEL.EXE kommt hingegen sowohl mit MS-DOS
UNDELETE /LOAD als auch mit DR DOS/Novell DOS DELWATCH
zurecht. Dies ist interessant zu wissen, wenn Sie statt
DELWATCH evtl. Microsofts 6.2x UNDELETE /LOAD verwenden,
um die Probleme, die DELWATCH mit verschiedenen Disk-Tools
bereitet, zu l�sen (siehe bei DELWATCH/DELPURGE).
UNDEL.EXE findet auch dann noch gel�schte Dateien, wenn
sie mit DELPURGE aus der L�schverfolgung entfernt wurden.
Diese Dateien sind offenbar mit Novells UNDELETE nicht
mehr zu restaurieren (siehe DELPURGE und DELWATCH). Mehr
Hintergrund-Informationen zur Physik der Verzeichnis-
eintr�ge gibt Kapitel II.21.
Unterst�tzt, wie Novells DELPURGE.EXE, neben den dokumen-
tierten Parametern noch eine Reihe weiterer neuer Parameter
(wie auch MS-DOS/PC-Tools UNDELETE.EXE):
/ALL identisch mit /A
/LIST identisch mit /L
/DT nur "Delete-Tracking-Methoden" verwenden, d.h.
nur die Unterst�tzung durch DISKMAP und DELWATCH
w�hlen. Wollen Sie zwischen DISKMAP und DELWATCH
unterscheiden, m�ssen Sie stattdessen /R:DISKMAP
oder /R:DELWATCH angeben.
/DOS nur "DOS-L�schmethoden" verwenden, d.h. wie
/R:UNAIDED. Dies bezieht sich gleichzeitig
sowohl auf die 'alte' DOS-Methode (wie auch
bei MS-DOS/PC-DOS), bei der der erste Buchstabe
des Dateinamens verloren geht und vor der
Restaurierung erfragt werden mu�, als auch
auf die 'neue' Methode unter Novell DOS,
wenigstens diesen Buchstaben an anderer Stelle
im reservierten Bereich der Verzeichnisstruktur
zwischenzuspeichern, wodurch die l�stige und
fehlertr�chtige Fragerei unterbleiben kann.
Werden /DOS und /DT gleichzeitig angegeben,
hat /DT offenbar den Vorrang.
*.* Alles
Die undokumentierte Syntax /U:name erlaubt die Angabe eines
zul�ssigen Benutzeranmelde- oder Gruppennamens (maximal 12
Zeichen lang). Diese Option ist nicht unter jedem Betriebs-
system verf�gbar und hat in Novell/DR Multiuser-Varianten
oder in Verbindung mit lokalen Benutzerkonten und
einmaliger Anmeldung eine Bedeutung, sofern die System-
absicherung aktiviert ist.
Der MS-DOS 6 UNDELETE /T Parameter hat eine g�nzlich
andere Funktion als Novells /T: Parameter!
Die Parameter /D: bzw. /T: (in landesspezifischem Format)
erlauben bei Novell DOS UNDELETE die zeitliche Ein-
schr�nkung des Suchbereichs f�r Dateien, wobei das
exakte Verhalten nicht so pauschal (und damit gr��tenteils
falsch) beschrieben werden kann, wie dies in der Novell-
und Fremd-Dokumentation geschieht (zwar bietet auch
DELPURGE gleichnamige Parameter mit gewisserma�en
'umgekehrtem Vorzeichen' an, dort sind sie allerdings
exakt beschrieben und beziehen sich ausschlie�lich auf
den Bereich *vor* dem angegebenen *L�sch*zeitpunkt):
Die Parameter /D:dd.mm.yy (absolut) bzw. /D:-nnn (relativ
bezogen auf das aktuelle Datum) bewirken eine doppelte
Suchmaske, die einerseits als Angabe des Zeitraum *seit*
der letzten *�nderung* (vor dem L�schen) der zu suchenden
Dateien gilt und andererseits gleichzeitig bei Dateien,
die in der DELWATCH-L�schverfolgung h�ngen, zus�tzlich auf
das *exakte* *L�sch*datum pa�t.
Dieses etwas gew�hnungsbed�rftige Konzept erlaubt gewisser-
ma�en eine Doppelnutzung der Parameter und liefert in den
meisten F�llen genau die richtigen gew�nschten Dateien
(im Zweifel wenige Dateien mehr), denn der Unterschied
wird erst dann sehr offensichtlich, wenn das letzte
�nderungsdatum einer Datei sich stark vom L�schdatum
unterscheidet und weit zur�ckliegt.
Beispiele:
/D:-0 f�r Dateien, die heute gel�scht wurden (plus die,
die - mit falschem Datumsstempel - in der Zukunft
ge�ndert und gel�scht 'wurden'... ;-) )
/D:-1 f�r bereits gel�schte Dateien, die noch gestern
oder heute ge�ndert wurden, plus alle in der
L�schverfolgung stehenden Dateien, die gestern
gel�scht wurden.
/D:-7 f�r bereits gel�schte Dateien, die noch innerhalb
der letzten Woche ge�ndert wurden, plus alle in
der L�schverfolgung stehenden Dateien, die vor
exakt 7 Tagen gel�scht wurden.
Zum sukzessiven r�ckw�rtigen Durchsuchen *aller* in der
letzten Woche gel�schten Dateien mu� man also der Reihe
nach die Optionen /D:-0 .. /D:-7 durchprobieren (die
Dokumentation beschreibt dies falsch)! Gleiches gilt
nat�rlich auch bei absoluter Angabe eines Datum mit
/D:dd.mm.yy.
Der Parameter /T:hh:mm[:ss] bezieht sich immer auf den
L�schzeitpunkt und spezifiziert den Zeitraum *seitdem*.
Ohne die Angabe eines genaueren Datums mit /D: (bzw.
des L�schdatums einer durch die /D: Maske in Frage
kommenden Datei) bezieht sich /T: auf das aktuelle Datum.
Sollten Sie bei in der DELWATCH-L�schverfolgung befind-
lichen Dateien neben dem Original-Datums-/Zeitstempel auch
noch den Zeitpunkt des L�schens erfahren wollen, k�nnen
Sie daf�r das Kommando DELPURGE /L verwenden, denn UNDELETE
verwendet zwar intern auch das L�schdatum f�r seine /D: und
/T: Parameter, zeigt diese Informationen aber nicht an.
Novell DOS 7 UNDELETE d�rfte zwar unter DR DOS 6.0 ge-
l�schte Dateien problemlos entl�schen k�nnen, da aber
DR DOS 6.0 und Novell DOS 7 DELWATCH sich bez�glich der
Speicherung des L�schdatums unterscheiden, k�nnte es sein,
da� Novells UNDELETE alte, unter DR DOS 6.0 gel�schte
Dateien mit falschem Datum anzeigt, das Originaldatum
mit dem L�schdatum verwechselt und die Dateien nach
dem Restaurieren ein v�llig falsches Datum haben
(1980-01-01???). Schwerwiegendere Probleme sind
allerdings nicht zu erwarten. (Nicht getestet.)
Nur, wenn UNDELETE ganz ohne Parameter aufgerufen wird,
erscheint die integrierte Men�oberfl�che, ansonsten ar-
beitet das Programm konsolenorientiert. Lediglich die
Parameter /B (f�r Schwarz/Wei�-Darstellung) und/oder /N
(f�r EGA/VGA-Zeichensatz) sind auch in diesem Fall erlaubt
(und k�nnen entgegen der Dokumentation auch gleichzeitig
angegeben werden). Standardm��ig wirkt UNDELETE dann f�r
das aktuelle Laufwerk, dies kann aber innerhalb der Ober-
fl�che auch ge�ndert werden.
M�chten Sie hingegen von vornherein den Konsolenmodus
aktivieren, reicht es aus, einfach eine Laufwerksspezifi-
kation (und sei es auch nur die des aktuellen Laufwerks)
anzugeben.
UNDELETE wertet in der Datei %NWDOSCFG%\NWDOS.INI die
Gruppen [UNDELETE] CurrentColorX= (x=1..9) und [COLORS]
ColorSetX und NewUI=on|off aus (wie oben schon erw�hnt).
Evtl. wird auch noch eine Variable %ADDSTOR% (SuperStor)
untersucht.
Wird UNDELETE auf JOIN-Laufwerke angewendet, werden keine
zu entl�schenden Dateien angezeigt, auch wenn in Wirklich-
keit Dateien vorhanden sind. In diesem Fall mu� die Zu-
ordnung aufgehoben werden und mit dem Original-Laufwerks-
buchstaben gearbeitet werden (vgl. auch DELWATCH, das
nur mit physikalischen Laufwerken arbeitet).
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok???
2 ???
31 Allgemeiner Fehler (Fehlercode: xx),
z.B. Fehlercode 3 hervorgerufen durch ung�ltige
Zahlenwerte im Zeitformat des
/T: Parameters.
UNFORMAT.EXE Die meisten Anwender w�rden dieses Kommando am liebsten
verkennen, ging seinem Einsatz doch in der Regel ein
essentieller und peinlicher Fehler in der Benutzung der
DOS-Kommandozeile voraus... ;-)
Trotzdem, wenn Sie versehentlich FORMAT /X auf eine Fest-
platte angewendet haben, sollten Sie normalerweise alle
Daten dieser Platte wiederherstellen k�nnen (besonders,
wenn Sie DISKMAP, MS-DOS/PC-Tools MIRROR oder Norton
Utilities IMAGE verwendet haben).
Ich hatte bisher erst einmal Kontakt mit diesem Kommando,
und prompt funktionierte das gerade beschriebene Procedere
NICHT! UNFORMAT weigerte sich, auf die Platte auch nur
zuzugreifen und auch CHKDSK oder PC-Tools DISKFIX lie�en
sich nicht dazu �berreden. Nortons NDD fand nur Bad-
Sectors. Kein gutes Zeichen. Des R�tsels L�sung:
W�hrend des FORMAT /X war offenbar ein Fehler aufgetreten,
und die DOS-internen Datenstrukturen wiesen diese Platte
nun als nicht ansprechbar ('nicht formatiert') aus. Also
hie� es, sicherheitshalber alle DISKMAP, MIRROR, IMAGE etc.
Tools tempor�r aus der AUTOEXEC.BAT entfernen (damit diese
weiterhin den alten Zustand dokumentierten) und den Rechner
neu booten. Und prompt war die Platte wieder ansprechbar,
als w�re nichts gewesen...
MS-DOS 6.2 UNFORMAT /TEST bietet Novell DOS 7, welches
vor MS-DOS 6.2 auf den Markt kam, verst�ndlicherweise
noch nicht. Sollten die M�glichkeiten von Novells UNFORMAT
einmal nicht ausreichen, k�nnen Sie auch das bis auf die
Unterst�tzung f�r Novells FORMAT leistungsf�higere
UNFORMAT.COM von MS-DOS 6.2 verwenden (da dieses Programm
eigentlich von Central Point PC-Tools stammt, arbeitet es
auch mit Novell DOS).
UNFORMAT kann nur funktionieren, wenn zum Zeitpunkt des
FORMATs auf dem Laufwerk gen�gend freier Speicherplatz
vorhanden war, um die UNFORMAT-Informationen zu sichern
(bei 1,2 MByte-Floppy ca. 4 KByte) und das Format nicht
ge�ndert wurde. Au�erdem d�rften die neu auf das Medium
kopierten Dateien noch nicht die UNFORMAT-Informationen
�berschrieben haben, wie dies geschieht, wenn das Medium
voller wird.
Errorlevel:
(unvollst�ndig, nur f�r Novell DOS 7 verifiziert)
0 ok
1 unzul�ssiges Laufwerk
3 Benutzerabbruch (<Ctrl>+<c> etc.)
4 Kann Laufwerk nicht lesen (keine Diskette)
VERSION.EXE Diese kleine Novell-Utility (in C:\NWCLIENT\) erm�glicht
die Berechnung von (extrem langen) Dateipr�fsummen und
die Ausgabe der in vielen Novell-Dateien intern gespeicher-
ten Versionsangaben.
Die Syntax ist VERSION [filespec] [/N], wobei auch Wild-
cards erlaubt sind.
Das Programm durchsucht die Datei nach bestimmten
standardisierten Zeichenketten, hinter denen die gesuchten
Informationen entsprechend Novells Konventionen bei der
Erzeugung eingetragen wurden. Die wichtigsten Zeichenketten
sind "VeRsIoN=", "VeRsIoN#", "CoPyRiGhT=" und f�r die
Option /N noch "NaMe SeRvIcE=" (und "NeTwArE="???).
Nat�rlich kann man diese Methode auch praktisch f�r eigene
Programme �bernehmen, wenn man das richtige Format einh�lt,
z.B.
DB "NaMe SeRvIcE=Dies ist ein Dummy!", NUL, CR, LF
DB "VeRsIoN=1.00 REV A (970130)", NUL, CR, LF
DB "CoPyRiGhT=(C) Copyright 1997 by ??", NUL, CR, LF
Dabei sollte das Datum unabh�ngig von der eigenen Landes-
einstellung immer im japanischen Datumsformat und ohne
Separatoren angegeben werden. Zumindest die letzten
beiden Zeichenketten m�ssen mit NUL (ASCII-0) abgeschlossen
werden; das CR (ASCII-13), LF (ASCII-10) ist optional,
aber sinnvoll. Die Versionsangabe sollte nicht mit einem
Satzzeichen enden, da VERSION.EXE hier automatisch einen
Punkt setzt. Es m�ssen nicht alle Zeichenketten angegeben
werden.
Bei "VeRsIoN#" kann die Angabe einer Versionsnummer
(optional mit Revisionscode) direkt bin�r erfolgen
(f�r Seriennummern). Daf�r werden offenbar die unmittelbar
auf das '#'-Zeichen folgenden 3 DWORDs als Version, Unter-
version und Revision ausgewertet.
Ein Problem ergibt sich, wenn Dateien, die solche Infor-
mationen enthalten, mit einem Online-Kompressor wie PKLITE
bearbeitet werden. VERSION.EXE kann dann die Informationen
nicht mehr finden. Allerdings kann man die Informationen
normalerweise auch an das Ende der komprimierten Datei an-
h�ngen (etwa mit einem speziellen Batchjob). Um optimale
Konsistenz zu erhalten, ist folgende Vorgehensweise sinn-
voll:
- Ausf�hrbare Datei erzeugen (mit internen Informationen
f�r VERSION.EXE)
- Die internen Versionsinformationen mit einem Utility
auslesen und zwischenspeichern
- Ausf�hrbare Datei komprimieren (z.B. mit PKLITE)
- Die zwischengespeicherten Informationen wieder in das
richtige Format bringen und zus�tzlich an die ausf�hr-
bare Datei anh�ngen.
- Virenscanner, Pr�fsummenschutz, etc. laufen lassen
Dieses auf den ersten Blick recht komplizierte Unterfangen
kann sogar mit einem trickreichen Batchjob gel�st werden
(wer's braucht, kann XVERSION.BTM bei mir anfordern).
Noch eine Bemerkung zum Schlu�: Bei einer Komprimierung
mit PKLITE werden die Token wie VeRsIoN=, CoPyRiGhT= usw.
oft nur teilweise komprimiert und bleiben auch von 'au�er-
halb' sichtbar. Dies kann VERSION.EXE verwirren, wenn es
diese Fragmente vor den neu angeh�ngten Eintr�gen in der
Datei findet. Ein kleiner Trick hilft hier: Wenn Sie im
Code unmittelbar vor dem Auftauchen der Zeichenketten
einen Teil des Musters vorweg angeben, kann PKLITE den
eigentlichen Eintrag besser komprimieren und es bleiben
keine verwirrenden Fragmente mehr �brig, z.B. funktioniert:
DB "VeCoP"
... <hier die eigentlichen Eintr�ge vornehmen>
Zwar wertet VERSION.EXE den folgenden Eintrag nicht
aus, aber bei Caldera OpenDOS 7.01 wird der Eintrag der
Seriennummer in COMMAND.COM erstmals speziell mit
"SeRiAlNuMbEr=" gekennzeichnet.
VDISK.SYS Novells VDISK unterst�tzt neben normalem DOS und DR DOS
auch Concurrent DOS/XM 6.0+, Concurrent DOS/386 2.0+,
DR Multiuser DOS 5.1+ und Concurrent DOS 5.1+. Die ausge-
lieferte Version unterst�tzt kein DPMS; in dem DPMS-SDK
gibt es aber einen Beispiel-VDISK-RAM-Disk-Treiber, der
DPMS nutzt und damit nur 400 Bytes im Real Mode-Adre�raum
bel��t. Trotzdem:
Im FreeWare-Bereich existieren zwei sehr viel flexiblere
(Gr��e zur Laufzeit einstellbar) und kleinere RAM-Disk-
Treiber, die obendrein noch etwas schneller sind:
TurboDSK (TDSK, selbsthochladender Ger�tetreiber/TSR,
ebenfalls nur ganze ca. 400 Bytes gro� (!!!), Nutzung
aller Speichersorten) bzw. BitDisk, der wohl kleinste
RAM-Disk-Treiber der Welt (ebenfalls ein Selbsthochlader,
lediglich ca. 256 Bytes gro�, Nutzung von XMS), beide
geschrieben von Ciriaco Garc�a de Celis. Beide sind auch
mit deutscher Dokumentation erh�ltlich, z.B. �ber meine
Web-Page.
---------------------------------------------------------------------------
II.5. Undokumentierte M�glichkeiten von DEBUG: [96-07-15]
=========================================================
Stichworte: DEBUG, Bugs, Kompatibilit�t, OpCodes, 286er, Pentium, /X,
Breakpoints, Symbole, Selbstdokumentierung, Makros,
Berechnung von Werten, Remote-Debugging
Das Kommando DEBUG von Novell DOS ist nahezu 100% kompatibel mit dem
Gegenst�ck von MS-DOS und arbeitet mit jedem DOS 2.11+ zusammen. Es
gibt nur ganz wenige Unterschiede, aber - leider zum gr��ten Teil un-
dokumentiert - sehr viele praktische Erweiterungen, die zum Teil noch
vom Vorg�nger SID (DR DOS 6.0) abstammen (SID wiederum hat seine Vor-
fahren in SID86 von DR DOS 3.41 - der �brigens spezielle Befehle zum
Debuggen unter GEM (und VIEWMAX) besa� - und der wiederum basierte auf
Debuggern f�r CP/M, wie etwa DDT). Leider sind im Detail nicht alle
F�higkeiten von SID �bernommen worden (z.B. die angesprochenen GEM-
Features), das allermeiste ist allerdings wiederzufinden.
Novell DOS DEBUG stellt sich wahrlich als Fundgrube undokumentierter
Eigenschaften dar und d�rfte damit das am meisten verkannte Utility von
Novell DOS sein (Beim Vergleich mit der Konkurrenz dr�ngt sich einem
unweigerlich der ungerechte Vergleich von Porsche und K�fer auf...).
Im DOSBOOK findet sich (allerdings etwas versteckt ganz am Ende) eine
recht ausf�hrliche Dokumentation �ber alle offengelegten Kommandos und
Funktionen dieses �u�erst m�chtigen und wichtigen Werkzeugs, das trotz
diverser Hochsprachen-Debugger und wesentlich flexiblerer Tools wie
Borlands Turbo-Debugger manchmal unumg�nglich ist, um bestimmte Dinge
auszuf�hren.
i. Inkompatibilit�ten zu MS-DOS DEBUG:
--------------------------------------
- Im Assemble-Modus (-A) mu� man bei Novell DOS 7 gew�nschte Zeichen-
ketten in doppelte Anf�hrungszeichen (DB "Teststring") setzen, bei
MS-DOS tun's auch die einfachen Anf�hrungszeichen. Dies kann manchmal
�nderungen in Debug-Skripten f�r MS-DOS DEBUG erfordern. Die Debug-
Skripte hei�en bei Novell DOS �brigens meistens .SCR, bei MS-DOS
meist .DEB, die Namenswahl ist allerdings in keiner Weise einge-
schr�nkt, sondern lediglich eine Konvention in den Dokumentationen.
- Die derzeitige Implementation (getestet bis 1.42, Update 15) hat einen
kleinen, aber schwerwiegenden Bug: Versuchen Sie niemals Ausdr�cke
wie die folgenden einzugeben:
A
DB 0A, 0D, "$"
oder
A
DW 3FF, 2000, "Teststring"
Sobald eine Zeichenkette und eine normale Angabe in dieser Reihenfolge
zusammen in einer Zeile definiert werden, kann es zu einem tiefen
Absturz kommen. Dies l��t sich vermeiden, wenn diese Angaben in
getrennten Zeilen erfolgen. Eine Zeichenkette vor einer Zahl wird
hingegen akzeptiert.
- Mit der urspr�nglich ausgelieferten Version 1.40 kann man nicht in
Interrupts tracen (-T) (es wurde stattdessen Proceed (-P) ausgef�hrt),
dies ist aber wohl mit der Version 1.41 von Update 12 m�glich
(prinzipielle Ausnahmen siehe unten). (Mit Update 13-15 (diverse
Unterversionen von 1.42) habe ich dies nochmals �berpr�ft, und es
klappt seltsamerweise nicht mehr. Ob der Fix versehentlich wieder
entfernt wurde oder ob mir ein Fehler unterlaufen ist? Leider habe
ich die Version 1.41 nicht mehr zur Verf�gung...)
- Die EMS-Funktionen von MS-DOS DEBUG (-XA, -XD, -XM und -XS) werden
nicht unterst�tzt, werden aber auch so gut wie nie ben�tigt. Daf�r
bietet Novells DEBUG eine Unzahl anderer Erweiterungen.
Nat�rlich kann man die fehlenden Funktionen nachbilden, in dem man
sich im Assemble-Modus 'online' ein paar Interrupt-Aufrufe f�r die
EMS-Funktionen schreibt.
- W�hrend des Assembler-Modus (-A) sind keine Kommentare erlaubt
(dies ist bei MS-DOS DEBUG m�glich, wenn auch undokumentiert).
Kommen solche Kommentare allerdings in Debug-Skripten vor, st�rt
das deren Abarbeitung nicht. Novells DEBUG gibt lediglich eine
Fehlermeldung aus, arbeitet aber normal weiter. Zus�tzlich sind
bei Novell jedoch Kommentare direkt am Prompt erlaubt (was aller-
dings bei MS-DOS zur�ckgewiesen wird).
- Die Syntax der Mnemos ist bei Novells DEBUG gegen�ber MS-DOS
in einigen Punkten leicht eingeschr�nkt (daf�r werden aber viele
andere Erweiterungen geboten). So sind z.B. keine Ausdr�cke wie
MOVAX,1
oder
D,1,1
erlaubt, aber diese Einschr�nkungen sich eigentlich nur konsequent,
anderenfalls k�nnte es mit zuk�nftigen neuen Assemblerbefehlen
Doppeldeutigkeiten in Debug-Skripten geben. Da all dies MS-DOS DEBUG
sowieso fremd ist, konnte man dort auch auf solche Vorsorgema�nahmen
verzichten.
ii. Grunds�tzliche Verbesserungen:
----------------------------------
- Im allgemeinen stabiler (mit MS-DOS DEBUG habe ich schon die
seltsamsten Ph�nomene erlebt, etwa Abst�rze an Segmentgrenzen
etc., so etwas ist Novells Implementation fremd)...
- Umschalten auf Benutzerschirm (Kommando 'Video' -V), d.h. die
Debug-Sitzung �berschreibt nicht die Ausgabe des getesteten
Programms und umgekehrt. Dieser Parameter ist nur in der ein-
gebauten Hilfe von DEBUG dokumentiert.
- Im Gegensatz zu MS-DOS 6.22 DEBUG wird der komplette (!!!) Befehlssatz
vom Intel 8088 bis zum Intel Pentium sowie alle Befehle der Intel
Coprozessoren voll unterst�tzt. Die zus�tzlchen Opcodes der V20/V30
(und damit auch 8080) Opcodes und Erweiterungen der Cyrix- und IIT-
Prozessoren und Coprozessoren werden allerdings nicht erkannt. Einige
undokumentierte Opcodes werden nicht f�r alle Prozessoren unterst�tzt,
aber eine ganze Reihe undokumentierter Opcodes (und Aliase) werden
wenigstens richtig decodiert.
- Der Debugger bietet einen erweiterten /X-Modus an, in dem die Kommando-
zeilen-Syntax mancher Befehle m�chtiger wird und in dem man von der
Default-Vorgabe BYTE abweichen kann. Neben einigen Bemerkungen im
weiteren Verlauf mehr dazu im DOSBOOK. F�r die Bearbeitung von Debug-
Skripten von MS-DOS DEBUG sollte man den /X-Modus nicht verwenden, da
es hier durch die Erweiterungen zu Fehlinterpretationen kommen kann.
- Der Debugger erlaubt symbolisches Debuggen durch spezielle Symbol-
dateien und Makros. Neben Erkennungsmechanismen f�r verschiedene CPUs
sind auch eine gro�e Anzahl symbolischer Namen der g�ngigen DOS-,
NetWare- und BIOS-APIs direkt intern kodiert.
- Novell DOS DEBUG erlaubt die Verwendung von bedingungsabh�ngigen
Breakpoints.
- Es gibt M�glichkeiten zum Remote-Debuggen.
iii. Undokumentierte Kommandos und Optionen:
--------------------------------------------
(Sowie einige spezielle Anmerkungen zu teilweise dokumentierten
Funktionen.)
-A [address] 'Assemble' ist im DOSBOOK dokumentiert.
W�hrend dieses Kommandos beziehen sich Register-
ausdr�cke aus verst�ndlichen Gr�nden auf die Namen,
nicht auf die gerade darin enthaltenen Werte (wie
ansonsten bei Novells DEBUG und SID �blich).
Im Gegensatz zu MS-DOS DEBUG sind keine einge-
betteten Kommentare erlaubt, allerdings werden
entsprechende Debug-Skripte auch nicht zur�ck-
gewiesen, da durch die auftretende Fehlermeldung
weder der Assemble-Modus beendet, noch die je-
weilige Codezeile verlassen wird, d.h. das Er-
gebnis ist das Gleiche.
Weitere Hinweise siehe oben.
-B [breakpoint[, count[, condition]]
'Breakpoint' - Dieser undokumentierte Parameter
erlaubt das flexible Setzen von permanenten
Ansprungpunkten (im Gegensatz zu den bis zu 3
tempor�ren Haltepunkten, die man bei G 'Go'
optional angeben kann). Im Gegensatz zu Halte-
punkten ist bei Ansprungpunkten die Anweisung an
der spezifizierten Stelle noch nicht ausgef�hrt.
-B
Gibt Liste der derzeit definierten Ansprungpunkte
und der Haltebedingungen an. Es k�nnen maximal
4 Ansprungpunkte angegeben werden.
-Bbreakpoint[, count[, condition]
Definiert einen Ansprungpunkt. Ohne Angabe von
count und condition ist dies ein unbedingter
Ansprungpunkt, der beim (nach dem?) ersten Mal
aktiv wird (d.h. count=1 und condition=always
wird implizit angenommen). Gibt man count an,
so wird der Ansprungpunkt erst beim Durchlauf
count durch diesen Haltepunkt aktiv (der Z�hler
wird mit jedem Durchlauf um eins erniedrigt, bis
er 1 erreicht. Bei 1 bleibt er dann stehen).
Dabei sind f�r count beliebige Werte von 0 bis
xxxx m�glich. Die zus�tzliche Angabe von condition
erlaubt es, auch noch ein CPU-Register auf einen
bestimmten Wert hin zu �berpr�fen. Nur in diesem
Fall wird der Ansprungpunkt aktiv (und der Z�hler
z�hlt).
Beispiel:
B100, 2, AX=05
setzt einen Haltepunkt an Offset 100h, der nach zwei
Durchl�ufen mit Bedingung AX=05 aktiv wird. F�r die
Registerangabe sind alle m�glichen 8- und 16-bittige
Register und jeweils g�ltige Werte erlaubt.
Die Angabe einer condition ist nur gleichzeitig mit
den anderen Angaben m�glich. Es ist zu beachten, da�
beim zweiten Parameter durch die Angabe eines Textes
wie AX noch der aktuelle Inhalt dieses Registers
(f�r den Durchlaufz�hler) verwendet wird, wohingegen
im dritten Parameter der Eintrag vor dem Gleichheits-
zeichen die symbolische Bedeutung f�r Register XY
hat, nach dem Gleichheitszeichen jedoch auch der Wert
des evtl. angegebenen Register gemeint ist.
B100, 0, BL=CH
setzt also die Bedingung BL=03 falls CH=3 ist.
Wof�r die Einstellung count=0 gut ist, ist noch nicht
klar, man kann aber vermuten, da� dieser Ansprung-
punkt dann immer gilt und nicht erst nach einer
gewissen Anzahl von Durchl�ufen aktiv wird.
(SID erlaubte in einer sehr �hnlichen Funktion bis
zu 16 Ansprungpunkte auf der Basis von eingef�gten
INT03h-Anweisungen, d.h. es konnte kein ROM-Code
debuggt werden und die Angabe von Bedingungen war
nicht m�glich. Novells DEBUG arbeitet hier aber
wahrscheinlich auf der Basis der Debug-Features des
386er (und h�her) (deshalb auch nur 4 Breakpoints).
Allerdings ist diese Funktion auch auf 286ern,
wahrscheinlich sogar auf 8088-Systemen verf�gbar.
Vielleicht wird das Verhalten intern umgeschaltet -
nicht �berpr�ft...)
Die obigen Funktionen sind auch im /S-Modus ver-
f�gbar, die folgenden Optionen werden im /X-Modus
zus�tzlich freigeschaltet:
--B l�scht alle Ansprungpunkte
--Bbreakpoint l�scht nur den spezifizierten
Breakpoint.
-C range address 'Compare' ist im DOSBOOK dokumentiert.
-CLS Dieser undokumentierte Befehl l�scht den Bildschirm
der Debug-Sitzung (nicht den 'Benutzerschirm').
Dabei wird im Gegensatz zur Novell DOS' und DR DOS'
Kommandozeile die eventuell in der Umgebungsvariable
%$Cls% definierte Sequenz ignoriert (siehe auch
Kapitel II.11., III.1. und IV.7.).
-CPU Dieser undokumentierte Befehl gibt die vorhandene
CPU und ihren aktuellen Betriebsmodus aus.
Erkannt werden alle Intel CPU-Generationen (bis
zum Pentium) sowie die NEC V20/V30 Prozessoren.
An Prozessormodi werden Real Mode und V86-Modus
angegeben (DOS l�uft nicht im Protected Mode).
-D [range] 'Dump' - Im /X-Modus gibt es die erweiterten Modi
(jeweils mit einem Leerfeld abgeschlossen!), die
jeweils entsprechende Gr��en oder Objekte zur Anzeige
bringen.
-DB [range] Dump BYTE
-DW [range] Dump WORD (von SID bekannt)
-DD [range] Dump DWORD (auch auf 286ern)
-DP [range] Dump POINTER
-DI [range] Dump INTERRUPTS
Die Angabe von -DP und -DI gibt Pointer-Strukturen
(Segment:Offset) aus. Die einfache Angabe von -D
benutzt den zuletzt eingestellten Modus weiter.
Hinter diesen Spezialbefehlen k�nnen auch die
�blichen Parameter angegeben werden. Bei -DI werden
diese nicht als Adre�angaben interpretiert, sondern
als Interrupt-Nummern im Bereich von 0 bis FF. Trotz-
dem ist sowohl die Angabe des Start- und Endwertes
als "-DP start end", als auch die Angabe der Anzahl
mit "-DP start L count" m�glich.
Ebenfalls nur im /X-Modus kann auch die Default-
L�nge f�r die Dump-Ausgaben angezeigt und umge-
�ndert werden:
--D [count] stellt Format nicht um
(diese Funktion ist von
SID bekannt)
--DB [count] identisch, stellt aber
gleichzeitig das Format
auf BYTE zur�ck.
Eine ver�nderte Standardl�nge arbeitet auch in
Verbindung mit sp�terem -DI, hier wird die Standard-
l�nge durch 4 dividiert und daraufhin werden ent-
sprechend viele Interrupt-Vektoren aufgelistet.
Es erscheint eine Meldung, die die aktuelle Ein-
stellung f�r die Standardl�nge und das -format
(BYTE, WORD, DWORD, POINTERS, INTERRUPTS) des
Dump-Kommandos ausgibt. Gibt man count an, so wird
die Einstellung der Standardl�nge entsprechend
umge�ndert. Ein anderes Standardformat (au�er BYTE)
kann man jedoch nur �ber die oben aufgef�hrten
Einzelkommandos �ndern:
-DB
-DW
-DD (auch auf 286ern!!!)
-DP
-DI
Die Einstellung f�r die Standardl�nge bleibt auch
nach dem Zur�ckschalten in den /S-Modus erhalten,
das Format wird dabei allerdings auf BYTE zur�ck-
gestellt.
Eine ver�nderte Standardl�nge wie z.B. --DB 017F
oder --D 17F f�hrt dazu, da� beim n�chsten -D
Kommando ein kompletter Bildschirm vollgeschrieben
wird.
Besonders praktisch ist die Ver�nderung der Standard-
l�nge, wenn man eine bestimmte Struktur (etwa ein
Feld mit Tabellenwerten) untersuchen will. Hier
gibt man mit --D die L�nge eines Feldelements an,
und kann damit eine automatisch richtig formatierte
Ausgabe der einzelnen Elemente bekommen. Bei MS-DOS
w�rde ohne explizite L�ngenangabe jedesmal der halbe
Bildschirm mit Daten vollgeschrieben, die meist gar
nicht interessieren und nur dazu f�hren, da� die
relevanten Daten viel zu fr�h vom Bildschirm ge-
scrollt werden.
In diesem Zusammenhang bleibt zu erw�hnen, da�
Novells DEBUG seine Auflistung immer an der
angegebenen Position beginnt und nicht - wie bei
MS-DOS - die Ausgabe auf die vorherige Paragraphen-
grenze ausrichtet.
Auch dies f�hrt normalerweise zu �bersichtlicheren
Ausgaben, denn man wird freiwillig nur dann von
den �blicherweise verwendeten Paragraphengrenzen
(letzte Ziffer 0) abweichen, wenn man dadurch eine
Struktur besser betrachten kann. Bei MS-DOS wird
diese Ausgabe dann trotzdem unvorteilhaft ausgegeben.
Einen Vorteil hat MS-DOS Methode: Die Offsets +0..+F
in einer Dump-Zeile entsprechen immer der letzten
Ziffer des Gesamt-Offsets, bei dem man mit dem Dump
begonnen hat. Bei Novells DEBUG kann sich dies
verschieben. M�chte man eine Ausgabe im Stil von
MS-DOS, sollte man also darauf achten, da� die
Adre�angabe eine 0 in der letzten Stelle hat.
-E [address [data]]
'Enter' - Im /X-Modus existieren die folgenden
erweiterten Modi (f�r die normale Bedeutung von
-EB ohne /X mu� man B nach einem Leerfeld angeben,
f�r -EA, -EC..-EF ist dies nicht notwendig.):
-EB [address [data]] Enter BYTE
-EW [address [data]] Enter WORD
-ED [address [data]] Enter DWORD
Au�erdem kann man (wie bei MS-DOS DEBUG) im Enter-
Eingabemodus mit der Minustaste jeweils einen
Eintrag zur�ckgehen.
SID gab eine Fehlermeldung aus, wenn z.B. wegen
fehlerhaftem RAM die Daten nicht korrekt geschrieben
werden konnten. Dies ist im Gegensatz zu MS-DOS DEBUG
mit Novells DEBUG nicht mehr der Fall.
-F range data 'Fill' ist im DOSBOOK dokumentiert.
Im /X-Modus gibt es allerdings noch eine weitere
undokumentierte Syntax, die analog arbeitet, jedoch
16 Bit breit ist:
-FW range data
Dieser Befehl war auch schon bei SID vorhanden.
Eine interessante Eigenschaft von SID bietet
Novells DEBUG nicht mehr: SID gab eine Fehler-
meldung aus, wenn die geschriebenen Daten nicht
wieder gelesen werden konnten, z.B. weil sich
kein RAM an der Zieladresse befand.
-G [=address] [breakpoint]
'Go' ist im DOSBOOK dokumentiert.
Nach der Ausf�hrung eines Programms wird angezeigt,
auf welche Art und Weise das Programm beendet wurde,
z.B. normaler Abbruch oder als TSR. Au�erdem wird
der Fehlercode angegeben (siehe Kapitel II.11.).
Bei MS-DOS DEBUG lassen sich 10 Breakpoints angeben,
hier sind es maximal 3 St�ck.
Diese Breakpoints werden mit INT03h-Opcodes gesetzt.
Wenn eine solche Stelle erreicht wird, wird der
Original-Opcode wieder eingesetzt. Wenn das Programm
aber beendet wird, ohne die Breakpoints erreicht zu
haben, sind die Breakpoints immer noch vorhanden.
Daher sollte die Datei nicht abgespeichert werden
und ggf. neu geladen werden. Diese Verhalten
unterscheidet sich allerdings nicht von MS-DOS
DEBUG. Auf dem Anwenderstack werden �brigens 6 Bytes
belegt, da die Ausf�hrung des Go-Befehls mit einer
IRET-Anweisung arbeitet.
'Go' arbeitet mit der n�chsten Anweisung nach
einem Haltepunkt weiter, wenn er erreicht wurde.
'Go' stoppt nicht nur bei den tempor�ren Halte-
punkten, sondern auch bei Haltepunkten, die per-
manent im Code vorhanden sind (d.h. eingebaute
INT03h-Opcodes). Hier wird nat�rlich kein Opcode
ersetzt.
-H value1 [value2]
'Hex' ist teilweise im DOSBOOK dokumentiert.
Diese Funktion stellt praktische Rechenoperationen
im Hex-System zur Verf�gung. Die zwei angegebenen
Argumente werden der Einfachheit halber in allen
vier Grundrechenarten miteinander verkn�pft und
das Ergebnis aller vier Berechnungen in einer Zeile
angezeigt (jeweils eingeleitet von der zugeh�rigen
Operation).
Bei der Division wird auch der Rest angegeben.
(Bei MS-DOS DEBUG wird nur Addition und Subtraktion
ausgef�hrt).
Neben dieser offiziellen Variante gibt es noch eine
weitere Funktion. Gibt man nur einen Parameter an,
so ist verst�ndlicherweise eine Verkn�pfung mit
einem anderen Wert nicht m�glich. Stattdessen wird
der angegebene Wert im Hexadezimalsystem, im Dezimal-
system und - falls darstellbar - als ASCII-Zeichen
ausgegeben. (Diese Funktion war bereits bei SID in
voller Bl�te vorhanden.)
Besonders flexibel ist dieses Kommando, wenn man
wei�, da� man nahezu beliebige Ausdr�cke f�r value1
und value2 verwenden kann, z.B. Rechenoperationen
oder Buchstaben, mehr dazu siehe unten.
-I port 'Input' ist teilweise im DOSBOOK dokumentiert.
Ab Update 13 (DEBUG 1.42) arbeiten die folgenden
Erweiterungen nun korrekt. Es werden jetzt auch
Ports oberhalb 400h unterst�tzt, da neuere Systeme
auch diese Adressen nutzen.
Im /X-Modus gibt es au�erdem noch die Kommandos
-IB port Input BYTE
-IW port Input WORD
-ID port Input DWORD (ab 386ern,
ergibt auf 286ern eine
Syntax-Fehler)
Das Kommando -I bleibt dabei aber immer in der BYTE
Einstellung, egal was man vorher f�r Kommandos ver-
wendet hat.
Die syntaktischen Varianten
--I port
--IB port
--IW port
--ID port (ab 386ern, ergibt auf
286ern einen Syntax-Fehler)
bewirken augenscheinlich das Gleiche wie ohne die
Angabe eines f�hrenden Bindestrichs.
Achtung: -IB im /S-Modus liest den Port 0Bh als
Byte ein. Ein Leerfeld ist nicht notwendig.
-IB erfordert im /X-Modus einen weiteren Parameter,
dieser wird dann byte-weise eingelesen.
-L [address]
-L address drive start count
'Load' ist im DOSBOOK dokumentiert. Soll angeblich
auch .HEX-Hexadezimal-Dateien direkt laden k�nnen
(mit dem daf�r �blichen Intel-Hex-Format konnte
ich das jedoch bisher nicht nachvollziehen). Beim
Laden einer .EXE-Datei wird der Dateikopf direkt
ausgewertet und ist nicht mehr verf�gbar. Wenn man
den .EXE-Header anschauen m�chte, mu� man die Datei
vor dem Laden umbenennen, so da� sie als Bin�rdatei
geladen wird (siehe -N). Andere Dateien werden als
bin�re Dateien geladen.
Die optionale Angabe -L address l�dt die (bin�re)
Datei an die entsprechende Adresse, wodurch speziell
auf bestimmte Adre�lagen zugeschnittener Code
ausf�hrbar wird. Au�erdem ist es m�glich, auf diese
Weise mehrere Programme gleichzeitig in den
Speicher zu laden (wenn man als Startpunkt des
jeweils n�chsten Programms das Ende des vorherigen
angibt - den Registern zu entnehmen) und diese dann
gemeinsam in einer Datei abzuspeichern.
Bei SID war f�r Sektor start auch die Angabe eines
32Bit-Wertes m�glich. Es ist wahrscheinlich, da�
dies auch f�r Novells DEBUG gilt. Die Syntax f�r
Sektor w�re dann nnnn:nnnn, d.h. 0003:FFFF f�r
Sektor 3FFFF.
Falls mit -N spezifiziert, l�dt dieser Befehl auch
die Symbolinformationen aus einer Datei .SYM.
-M range address 'Move' ist im DOSBOOK dokumentiert.
Im Gegensatz zu SID versucht DEBUG, da� die Speicher-
bereiche nicht �berschrieben werden, auch wenn sie
sich �berlappen.
-N [drive:][path]file
'Name' ist teilweise im DOSBOOK dokumentiert. Benennt
einen Dateinamen f�r die Dateioperationen 'Load' und
'Write' (-L und -W).
Undokumentiert ist dabei die spezielle Syntax
-N?
die Informationen �ber den eingestellten Namen der
Programm- und/oder Symboldatei sowie - falls
bereits geladen - �ber den Dateityp (bin�r/.EXE)
ausgibt. Au�erdem werden evtl. angegebene Parameter
f�r das Programm angezeigt.
DEBUG unterscheidet den Dateityp nicht allein
anhand der Dateiendung, sondern auch anhand des
Headers. So kommt es, da� eine .EXE-Datei, die
die Dateiendung .COM hat, trotzdem als .EXE
interpretiert wird und dementsprechend sp�ter
auch nicht wieder mit -W zur�ckgeschrieben werden
kann. M�chte man also eine .EXE-Datei - etwa nach
einem Patch - wieder zur�ckschreiben, mu� man
vorher die Dateiendung auf eine nicht ausf�hrbare
Endung �ndern (REN TEST.EXE TEST.BIN). Solche
Dateien werden dann trotz .EXE-Headers nicht als
.EXE-Dateien interpretiert sondern ab Offset 0000h
geladen. Dateien vom .COM-Typ werden wie �blich an
Offset 0100h geladen (dabei ist - wie gesagt -
die Dateiendung .COM nicht allein ausschlaggebend).
Au�erdem kann man nach dem Dateinamen auch noch die
zu dem Programm geh�rigen Aufrufparameter angeben,
etwa:
-N TEST.COM /parameter
Nachdem eine ausf�hrbare Datei mit -L geladen
wurde, kann man mit diesem Befehl ohne Angabe des
Programmnamens neue Programmparameter angeben:
-N /parameter
Dabei werden alle Zeichenketten akzeptiert; insofern
kann es Probleme bereiten, wenn Sie einen neuen
Programmnamen spezifizieren wollen. Im Zweifelsfall
sollten Sie DEBUG einfach kurz beenden und neu
starten.
Es gibt noch eine weitere Syntax f�r die Angabe
einer Symboldatei .SYM (die runden Klammern sind
hier syntaktisches Merkmal):
-N prgfile (symfile) parameter
Die Angabe von Parametern ist optional.
Eine Programmdatei kann weiterhin angegeben werden,
Parameter sind allerdings anscheinend nicht m�glich.
-N()
L�scht den Namen der Symboldatei.
Im /X-Modus l�scht das folgende Kommando
alle Eintr�ge:
--N
-O port, value 'Output' ist teilweise im DOSBOOK dokumentiert.
Ab Update 13 (DEBUG 1.42) arbeiten die folgenden
Erweiterungen nun korrekt. Es werden jetzt auch
Ports oberhalb 400h unterst�tzt, da neuere Systeme
auch diese Adressen nutzen.
Im /X-Modus gibt es au�erdem noch die Kommandos
-OB port, value Output BYTE
-OW port, value Output WORD
-OD port, value Output DWORD (ab 386ern)
Das Kommando -O bleibt dabei aber immer in der BYTE
Einstellung, egal was man vorher f�r Kommandos ver-
wendet hat.
Die Varianten
--O port, value
--OB port, value
--OW port, value
--OD port, value (ab 386ern)
arbeiten anscheinend genauso wie ohne voran-
gestellten Bindestrich.
Achtung: -OB schreibt im /S-Modus den Port 0Bh als
Byte (Ein Leerfeld ist nicht notwendig). -OB im /X
Modus erfordert einen weiteren Parameter (also ins-
gesamt zwei), dieser wird dann byteweise geschrieben.
-P [=address] [count]
'Proceed' ist teilweise im DOSBOOK dokumentiert.
Neben der normalen Funktion gibt es noch eine un-
dokumentierte Variante.
-PU
-PU [=address] [count]
Hierbei wird die Ausgabe der Registerwerte und
Ansprungpunkte mit Z�hlern gr��er als 1 unter-
dr�ckt (vgl. -TU). L��t man die Parameter weg,
wird ein einzelnes 'Proceed' ohne Ausgabe aus-
gef�hrt.
'Proceed' arbeitet sehr �hnlich wie 'Trace',
allerdings werden auch CALLs, INTs und REP, REPcond
als einzelne Anweisungen behandelt und nicht in
sie hinein getract (Ist man mit 'Trace' innerhalb
einer REP oder REPcond Anweisung, kann man mit
'Proceed' sofort bis zu ihrem Ende weiterarbeiten).
Wenn eine einzelne Anweisung getract wird, werden
f�r die Ablaufdauer die Interrupts gesperrt, damit
man nicht versehentlich in einen auftretenden
Interrupt hineintract.
Ein echter INT03h im Code kann derzeit (Update 15)
weder mit 'Proceed' noch mit 'Trace' �bersprungen
werden und mu� manuell durch Patchen des Codes
(Option -E) mit NOP (Opcode 90h) �berschrieben
werden, damit man weitertracen kann.
Im /X-Modus wird auch die Syntax mit vorangestelltem
Bindestrich akzeptiert.
--P [=address] [count]
--PU [=address] [count]
Ob sich dabei allerdings etwas gegen�ber der
normalen Ausf�hrung �ndert ist noch unbekannt.
-Q 'Quit' ist im DOSBOOK dokumentiert.
-R [regname] 'Register' ist zu einem geringen Teil im DOSBOOK
dokumentiert. Anzeige und Eingabe von Register-
werten. Zeigt auch die Registerwerte bei den Halte-
punkten an. Im /X-Modus �ndert sich die Anzeige der
Register.
-RF die Flags werden ausgegeben (die Angabe unter-
scheidet sich im /S-Modus von der im /X-Modus).
-R=16 schaltet die Registerausgabe in den 16Bit-
Modus. (--R=16 bewirkt das Gleiche)
-R=32 schaltet die Registerausgabe in den 32Bit-
Modus. (--R=32 bewirkt das Gleiche)
(erst ab 386ern)
-R= zeigt den jeweils eingestellten Modus
(16 Bit/32 Bit) an (--R= bewirkt das Gleiche).
Folgende Registerbezeichnungen sind zul�ssig (je nach
Prozessortyp sind nicht alle Bezeichnungen g�ltig):
AL AH AX EAX CR0? TR3?
BL BH BX EBX CR1? TR4?
CL CH CX ECX CR2? TR5?
DL DH DX EDX CR3? TR6?
SI ESI CR4? TR7?
DI EDI
ES DR0?
DS DR1?
SS DR2?
CS DR3?
FS
GS DR6?
SP ESP DR7?
BP EBP
IP (=PC)
F
(PC als Alias f�r IP wird nur von MS-DOS DEBUG,
nicht jedoch von Novells DEBUG akzeptiert. Die
Bezeichnungen CRx, DRx und TRx sind intern codiert,
ich konnte sie allerdings bisher noch nicht mit
DEBUG auslesen.)
Folgende Flag-Bezeichnungen sind erlaubt:
Set: Clear:
Overflow OV NV
Direction DN UP
Interrupt EI DI
Sign NG PL
Zero ZR NZ
Auxillary Carry AC NA
Parity PE PO
Carry CY NC
Bez�glich der Syntax zur Eingabe von Registerwerten
und Flags siehe DOSBOOK (auch erweiterte 386er-
Register k�nnen direkt angegeben und ver�ndert
werden, nat�rlich nur, wenn sie auch vorhanden sind).
-S range data 'Search' ist im DOSBOOK dokumentiert.
-T [=address] [count]
'Trace' ist teilweise im DOSBOOK dokumentiert.
Neben den �blichen M�glichkeiten zum Tracen wird
das Kommando hier sogar symbolisch behandelt, d.h.
es werden nicht nur die jeweiligen Register ange-
zeigt, sondern auch, ob Spr�nge, Schleifen etc.
erf�llte Bedingungen haben oder Flaggen effektiv
gesetzt wurden (JUMP, NO JUMP, LOOP, NO LOOP, INT,
NO INT, SET 0, SET 1) und die Inhalte der effektiv
adressierten Speicherstellen werden auch ausgegeben
(so da� man sich ein Speicher-Dump meist sparen
kann). Diese in Klammern angegebenen Angaben sind
das Ergebnis des Calls und Erleichtern das Ver-
st�ndnis dessen, was beim Weiter-Tracen als N�chstes
passieren wird. Die Ausgabe von Speicherinhalten
bezieht sich auf den Inhalt der Speicherstelle
*vor* der Ausf�hrung der gerade angegebenen An-
weisung (die diesen Wert ja ver�ndern kann).
Auch symbolische Bez�ge zu den meisten DOS, NetWare,
GEM APIs und BIOS Interrupts, einigen FarCalls sowie
auf PC-Hardware (IO-Bereich) werden aufgel�st und in
ihrer Bedeutung angezeigt (Bsp: DOS: Get Int Vector).
Dadurch bekommt man einen sehr guten �berblick �ber
den Ablauf eines Programms, auch ohne, da� man jede
einzelne Interrupt-Funktion in der Literatur nach-
schauen mu�. 'Trace' kann auch ROM-Code tracen.
Trace arbeitet normalerweise als Single-Step,
allerdings gibt es einige wenige Ausnahmen:
DOS Interrupts werden nicht getract, sondern wie mit
Proceed �bersprungen (dies mu� so sein, da DOS nicht
reenterant ist).
DEBUG von MS-DOS f�ngt diese Gefahrenquelle aller-
dings nicht ab und 'erlaubt' damit auch das Tracen
in DOS-Interrupts hinein (was manchmal ganz inter-
essant sein kann), auf die Gefahr hin, da� man eine
nicht reenterante Funktion tract, was meist zum
Absturz f�hrt. Sollten Sie diese Trace-M�glichkeit
wirklich ben�tigen, k�nnen Sie auch MS-DOS' DEBUG
unter Novell DOS laufen lassen, eine korrekt 'ge-
t�rkte' DOS-Version mittels SETVER vorausgesetzt.
Bestimmte Assembleranweisungen sperren die Interrupts
(einschlie�lich des Single-Step-Interrupts) direkt
nachdem mit MOV oder POP Segmentregister geladen
wurden. Eine solche Anweisungsfolge wird (und mu�)
als ein Programmschritt behandelt werden.
Der folgende Hinweis beziehen sich auf MS-DOS DEBUG,
d�rften aber f�r Novells Gegenst�ck genauso gelten:
Das Programm sollte die Interrupt-Maske des
Interrupt-Controllers nicht ver�ndern, da beim
Tracen vor der Ausf�hrung eines Befehls alle
Hardware-Interrupts gesperrt werden. Wird dies
nicht befolgt, kann es zu unvorhergesehenem
Verhalten kommen. Wird ein INT03h im Code verwendet,
so wird dieser durch einen Breakpoint ersetzt.
M�chte man den Code begutachten, der als n�chstes
ausgef�hrt wird, gen�gt es, w�hrend des 'Trace' oder
'Proceed' -U ('Unassemble') einzugeben, das so vor-
eingestellt ist, da� der richtige Code disassembliert
wird.
Neben der offiziellen Syntax gibt es noch eine
undokumentierte Variante, die die sonst �bliche
Ausgabe nach jedem Schritt unterdr�ckt:
-TU
-TU [=address] [count]
Vermutlich gilt dies (analog zu SID) auch f�r
Ansprungpunkte, deren Durchlaufz�hler noch gr��er
als 1 ist. Diese werden erst angezeigt, wenn der
Z�hler 1 erreicht.
Im /X-Modus wird auch die Syntax mit
--T [=address] [count]
--TU [=address] [count]
akzeptiert, ob sich hierbei aber etwas gegen�ber dem
normalen Ablauf �ndert, ist noch nicht klar.
-U [range] 'Unassemble' ist im DOSBOOK weitestgehend dokumen-
tiert. Allerdings gibt es eine spezielle Syntax,
mit der man die Standardl�nge von Disassemblier-
ausgaben ohne explizite Angaben voreinstellen kann.
--U [count]
Ohne Angabe von count wird die aktuelle Einstellung
(standardm��ig 12 Befehle) ausgegeben; die Angabe
von count ver�ndert diese Einstellung auf die ge-
w�nschte Anzahl (dies ist vom Prinzip her noch von
SID bekannt). Beim Zur�ckschalten in den /S-Modus
bleibt eine evtl. ge�nderte Standardl�nge erhalten.
-W [address]
-W address drive start count
'Write' ist im DOSBOOK dokumentiert. Dieser Befehl
kann nur bin�re Dateien speichern (also .COM-Typ).
.EXE- oder .HEX-Dateien lassen sich nicht wieder
zur�ckschreiben (dies gilt auch f�r MS-DOS DEBUG).
Bei SID war f�r Sektor auch die Angabe eines 32Bit-
Wertes m�glich. Es ist wahrscheinlich, da� dies auch
f�r DEBUG gilt. Die Syntax f�r Sektor w�re dann
nnnn:nnnn, d.h. 0003:FFFF f�r Sektor 3FFFF.
-= Definieren und Abfragen von Makros:
-:
-=
Gibt eine Liste der derzeit definierten Makros aus.
Auf diese Art und Weise lassen sich die Makros �ber
Ein/Ausgabenumleitungen wohl auch speichern.
Zwei Makros sind immer vordefiniert:
DRDOS: und DEVICE:
Genaueres kann man der Auflistung selbst entnehmen.
-=macroname
F�hrt ein definiertes Makro aus. Ob dabei noch
Parameter �bergeben werden k�nnen, ist noch unklar,
scheint aber wahrscheinlich zu sein.
-:macroname
Makro definieren, �ndern oder l�schen. Der Prompt
wechselt zu :. Jetzt kann man das Makro eingeben.
Alle �blichen DEBUG-Befehle sind erlaubt, ein-
schlie�lich Makrokommandos, die allerdings nicht
sinnvoll einsetzbar sind. Die Abarbeitung von
verschachtelten Makros ist nicht m�glich.
Makronamen k�nnen auch syntaktische Zeichen und
Leerfelder enthalten und werden als Ganzes textuell
ausgewertet. Nachdem man alle Zeilen des Makros
eingegeben hat, kann man mit dem Gleichheitszeichen
('=') am Prompt ':' die Makroaufzeichnung beenden
(das ist auch der Grund, warum verschachtelte Makros
nicht m�glich sind). Der Prompt wechselt wieder zu
'-'. Nun kann man mit -= das Makro in der Auflistung
ansehen.
M�chte man ein Makro l�schen, so reicht es, die
Makroaufzeichnung direkt mit '=' wieder zu beenden.
Im /X-Modus kann man die Makros auch wieder l�schen:
--:
--:macroname
L�scht alle Makros (einschlie�lich der intern
definierten) oder nur das Makro mit dem Namen
macroname.
Die Syntax --:macroname wird auch unterst�tzt,
arbeitet allerdings genauso wie -:macroname.
Die Angabe von symbolischen Parametern ist noch
unklar, immerhin werden weitere Parameter aber nicht
zur�ckgewiesen.
-; comment Kommentar, wenn in der ersten Spalte geschrieben
(ist allerdings im DOSBOOK dokumentiert). Diese
Funktion war auch schon bei SID vorhanden.
-? Gibt Hilfeseite aus. (Im /X-Modus --? ebenso.)
-/X Schaltet in den erweitertem Modus (/X) oder wieder
-/S zur�ck zur Default-Einstellung (/S).
Dr�ckt man einfach nur <Return> so wird praktischerweise das letzte
Kommando (mit Folgewerte) wiederholt (unter MS-DOS DEBUG ist das nicht
m�glich, oder zumindest nicht bei allen Kommandos).
iv. Weitere Hinweise und spezielle M�glichkeiten:
-------------------------------------------------
Schl�sselw�rter:
Sollte es Doppeldeutigkeiten bei der Angabe von Mnemos geben, kann man
mit folgenden Schl�sselw�rtern f�r Klarheit sorgen:
BYTE WORD DWORD QWORD PWORD FWORD TBYTE NEAR FAR PTR INT
Die meisten dieser Schl�sselw�rter d�rfen mit den ersten beiden
Buchstaben abgek�rzt werden:
BY WO DW QW PW FW TB NE
Statt 'BYTE PTR' kann man also 'BY', statt 'WORD PTR' 'WO' schreiben.
Einige Versionen (1.40 und 1.41) von DEBUG haben allerdings wohl
Probleme mit den Langformen.
Pr�fixe:
Die drei m�glichen Pr�fixe (LOCK, REP, REPcond und Segment-Overrides)
eines Ausdrucks m�ssen w�hrend des Assemblierens nicht in der gleichen
Zeile stehen, sondern k�nnen auf mehrere Zeilen aufgeteilt werden.
(Das LOCK Pr�fix kann anscheinend nicht mit einem anderen Pr�fix
zusammen in einer Zeile angegeben werden).
Zahlenangaben:
Im DOSBOOK gibt es eine wage Beschreibung dessen, welche Ausdr�cke
bei Zahlenangaben erlaubt sind. Es entsteht der Eindruck, da� man an
manchen Stellen im Assembler symbolische Registerwerte verwenden kann
und da� die Kommandozeilen-Syntax sonst recht lax ist (Kommata zwischen
den Werten sind optional).
In Wirklichkeit bestehen jedoch sehr viel weiterreichende M�glichkeiten:
S�mtliche Zahlenangaben erfolgen default-m��ig auf der Basis des
Hexadezimalsystems. Trotzdem kann man z.B. auch Zahlen im Dezimal-
system angeben, wenn man ein '#' voranstellt oder auch Buchstaben
verwenden, wenn diese in Hochkommata eingeschlossen werden. Diese
werden entsprechend dem ASCII-Code automatisch umgewandelt in die
zugeh�rigen Hexzahlen.
Es ist jederzeit erlaubt, die Grundrechenarten '+', '-', '*' und '/'
zu verwenden (bei SID waren nur '+' und '-' erlaubt), z.B. statt 18
kann man auch schreiben 10+8 oder 1A-2 oder statt 200 auch 100*2 usw.
Dies gilt ganz allgemein an jeder Stelle, auch mehrfach in einem
Ausdruck. Dabei werden in begrenztem Umfang sogar die Priorit�ten
von Punkt- vor Strichrechnung beachtet. Allerdings sollte man vor-
sichtig sein, wenn man mehrere Punktrechnungen aufeinander folgen
l��t: In diesem Fall wird nur die erste Rechnung ausgef�hrt und
alles weitere ignoriert.
Abhelfen kann man dem durch Angabe von Klammerp�rchen '(', ')'. Die
Klammerpaare '[' und ']' haben dagegen eine besondere Bedeutung:
Sie spezifizieren nicht den Wert, sondern den Inhalt dessen, was durch
den angegebenen Wert adressiert wird. Jederzeit sind statt direkter
Zahlenwerte auch Registerbezeichnungen erlaubt (nur 16 Bit breite
Register), wobei alle Kombinationen unterst�tzt werden:
Hier ein paar Beispiele f�r das -D Kommando:
-D (10+5)*2 L 10
-D SI:DX
-D [100]
-D [ES:AX], [ES:AX]+10
-D SI:100 L 5+3
-D 5+4:SI L AX
-D 'A', 'Z'-1
-D 'A' L 10
-D #10 L #15
Leerfelder sind innerhalb eines Ausdrucks i. allg. nicht erlaubt.
Die Angabe von Bereichen kann auf zweierlei Art und Weise erfolgen:
Entweder man gibt den Startpunkt und Endpunkt an, oder man gibt den
Startpunkt und nach dem Buchstaben 'L' die Anzahl an. Gibt man keine
Anzahl an, wird die Default-Anzahl verwendet. Gibt man �berhaupt nichts
an, so wird die Bearbeitung mit der letzten Einstellung fortgesetzt.
Es mu� definitiv M�glichkeiten geben, Makro- und Symboldateien zu laden:
Die Aufruf-Syntax
DEBUG =macrofile
scheint eine Makrodatei als Eingabe zu erwarten.
Wahrscheinlich gibt es auch eine M�glichkeit Symbole innerhalb des
Debuggers zu definieren und wieder abzuspeichern (evtl. mit '(', ')').
Leider habe ich bisher noch nicht genau herausfinden k�nnen, wie dies
vonstatten gehen k�nnte.
Insbesondere das Datenformat der Symboldateien ist noch v�llig unklar,
es scheint aber Hexzahlen zu enthalten, au�erdem die Schl�sselworte
LABELS, VARIABLES, NUMBERS, evtl. noch VECTORS (bei SID auch noch CODE,
DATA, EXTRA, STACK, X1, X2, X3, X4).
Es gibt zwei sinnvolle M�glichkeiten:
- Das Format k�nnte auf dem Format von alten CP/M-Assemblern basieren,
die .SYM-Dateien erzeugt haben:
Allerdings haben Versuche mit einigen alten Original-CP/M .SYM-
Dateien bisher weder mit SID noch mit Novells DEBUG zum Erfolg
gef�hrt: SID hat jedoch nach dem Laden (und einer Fehlermeldung)
versucht, die Symbole w�hrend des Disassemblierens und in der -H
Auflistung (ohne Parameter) anzuzeigen; DEBUG hat sein Verhalten
in keiner Weise ge�ndert, was aber auch daran liegen kann, da�
eben das Format fehlerhaft war, und SID dies nur nicht abfing.
- Die andere M�glichkeit besteht darin, da� das Format von Microsofts
SYMDEB �bernommen wurde. Diese Dateien konnte man aus den .MAP-Dateien
des Linkers mit Hilfe des Utility MAPSYM (bei Microsoft) oder TMAPSYM
(bei Borland) in .SYM-Dateien konvertieren. Es sieht aber nach einigen
Tests wohl so aus, als wenn zumindest Borlands .SYM-Format von SID und
Novells DEBUG nichts akzeptiert wird. (Der Nachfolger von SYMDEB,
CodeView CV, scheint einen anderen Weg zu gehen: Hier werden mit der
Option MASM /ZD und LINK /CO Symbolinformationen direkt in die .OBJ-
und .EXE-Dateien eingebunden.
DEBUG versucht Begriffe als Symbole zu interpretieren, wenn diese u.a.
mit einem Punkt oder einem @ beginnen (z.B. -D.P, wobei das -D hier f�r
den Dump-Befehl steht). N�heres ist noch unklar, dies deutet aber auf
eine Verwandtschaft mit dem ZAP-Patch-Utility von Multiuser DOS hin.
Vielleicht kennt ja jemand anders des R�tsels L�sung und kann mir dies
mitteilen (schlie�lich w�re doch gerade das symbolische Debuggen eigener
Programme �u�erst interessant)...
Remote-Debugging:
Au�erdem enth�lt Novells DEBUG eindeutig Unterst�tzung zum Remote-
Debuggen �ber eine der seriellen Schnittstellen COM1: bis COM4:, d.h.
die Steuereingaben des Debuggers kommen nicht von der lokalen Tastatur,
sondern von einem Terminalprogramm auf einem entfernten Rechner, der
�ber eine serielle Schnittstelle an den Debug-Rechner angeschlossen
ist (9600 Baud, 8 Daten-Bit, 1 Stopp-Bit, keine Parit�t). Dabei wird in
irgendeiner Weise eine Syntax wie ':x' mit x=1..4 ausgewertet, und im
Zweifelsfall die Schnittstelle bei 3F8h gew�hlt. Leider ist es mir
bisher noch nicht gelungen, herauszufinden, wie dieser Modus aktiviert
wird...
---------------------------------------------------------------------------
II.6. STACKER beim Booten nicht laden:
======================================
Stichworte: STACKER, Booten, <Ctrl>+<Alt>
Um zu verhindern, da� trotz eingerichteten STACKER-Laufwerken beim Booten
die entsprechenden Treiber geladen werden, mu� man am Anfang des Bootens
die Tasten <Ctrl>+<Alt> gedr�ckt halten, bis DOS bootet.
H�chstwahrscheinlich kann man auch <Ctrl>+<F5> und <Ctrl>+<F8> benutzen,
um das Laden von STACKER zu �bergehen, jedenfalls besitzt IBMBIO.COM
die entsprechende Funktionalit�t, siehe Kapitel II.2.
---------------------------------------------------------------------------
II.7. STACKER auf Version 4 updaten: [97-02-28]
===============================================
Stichworte: STACKER Update, CHKDSK, INSTALL/SETUP
Novell DOS 7 liegt eine angepa�te STACKER-Version 3.12 bei (die nicht
unter anderen Betriebssystemen verwendet werden sollte). Zu den beson-
deren F�higkeiten geh�rt die Unterst�tzung von DPMS und in Verbindung
mit NetWare- oder PNW-Servern, die ebenfalls STACKER-komprimierte Lauf-
werke haben, sogar der Austausch der komprimierten Daten �ber das Netz.
Dadurch entf�llt weitestgehend das zeitaufwendige Entpacken der Daten
auf dem einen und Neupacken der Daten auf dem anderen Rechner und
zus�tzlich wird die effektive Netzbelastung durch die kleineren Pakete
reduziert. STACKER unterst�tzt auch MS Windows' permanente Auslagerungs-
dateien, allerdings ist dies verst�ndlicherweise in den meisten F�llen
mit starken Performance-Einbr�chen verbunden (ausgenommen sehr langsame
Festplatten auf relativ schnellen Rechnern).
Wer (trotzdem) auf das eigenst�ndige Produkt STACKER Version 4 updaten
will (etwa weil er MS Windows95 installieren will), mu� sich - sofern
er auch weiterhin Novell DOS 7 benutzen will - unbedingt ein aktuelles
Update zu Novell DOS 7 besorgen, da u.a. CHKDSK �berarbeitet wurde, um
mit STACKER 4 zurechtzukommen (indem die STACKER-�berpr�fung mit einer
neuen Option umgangen werden kann). Auch die Installationsprogramme
INSTALL/SETUP (nur bei Update 11) sind �berarbeitet und sollen daher
mit bereits installiertem STACKER 4 zurechtkommen. Inwieweit die
speziellen Novell DOS Anpassungen auch in STACKER 4 wiederzufinden
sind, bzw. umgekehrt, inwieweit es wirklich gef�hrlich ist, Novells
STACKER-Version unter anderen Betriebssystemen zu verwenden, ist mir
leider unbekannt (ger�chteweise soll es - zumindest partiell -
funktionieren). Zumindest DPMS wird auch von STACKER 4 unterst�tzt.
Um Doppeldeutigkeiten und seltsames Systemverhalten zu vermeiden, sollte
man alle zu STACKER 3.12 geh�renden Dateien aus dem c:\nwdos\ Verzeichnis
entfernen:
DCONVERT.COM, DCONVRT2.EXE, SCONVERT.EXE, SCREATE.SYS, SDEFRAG.COM,
SDEFRAG2.EXE, SCREXEC.EXE, STACFM.DLL, STACFM.HLP, STACHIGH.SYS,
STACKER.COM, STACKER.EXE, STACLOAD.BIN, UNSTACK.COM, UNSTACK2.EXE,
WINSWAP2.EXE.
Noch ein Hinweis am Rande:
Derzeit (Update 15) unterst�tzt der Kernel von Novell DOS 7 bez�glich der
Preload-Schnittstelle wohl nur STACKER.BIN bzw. DBLSPACE.BIN und nicht
das mit MS-DOS 6.22 eingef�hrte DRVSPACE.BIN. Da sich DRVSPACE und das
vorherige DBLSPACE aber so gut wie gar nicht unterscheiden (die gr��ten
Unterschiede bestehen in den Meldungen...), sollte Novell DOS 7 auch
problemlos mit DRVSPACE zurechtkommen, nachdem man den Novell DOS Kernel
so gepatcht hat, da� er nach DRVSPACE.BIN statt nach DBLSPACE.BIN sucht.
---------------------------------------------------------------------------
II.8. Rechnerkopplung �ber Punkt-zu-Punkt-Verbindungen: [97-02-04]
==================================================================
Stichworte: MS-DOS, INTERLNK, INTERSRV, Datenverluste, FILELINK, Remote,
TASKMGR, CTTY, FASTLYNX, LAPLINK, NC, IPX, PNW, SERVER,
virtuelle Maschine, DOS-Box
Zun�chst ein kurzer �berblick �ber die m�glichen Transfer-Arten der
bekanntesten Programme, die eine Rechnerkopplung �ber Punkt-zu-Punkt-
Verbindungen erlauben:
Seriell Parallel IPX
Novell DOS FILELINK ja ja nein
MS-DOS INTERSRV/INTERLNK ja ja nein
Norton Commander 3.0 [NC] ja nein (nein)
Norton Commander 4.0+ [NC] ja ja (nein)
LAPLINK 3.xx [LL] ja nein (nein)
LAPLINK PRO 4.0 [LLPRO] ja ja (nein)
FASTLYNX 1.xx [FX] ja, auto ja, auto (nein)
FASTLYNX 2.0+ [FX] ja, auto ja, auto ja, auto
F�r serielle Verbindungen werden �bliche 3-, 5- oder 7-adrige Nullmodem-
kabel oder eine Modemverbindung ben�tigt, mit jeweils unterschiedlicher
Datensicherheit und maximaler Geschwindigkeit (Maximum ist 110 kBd).
F�r Verbindungen �ber die parallele Schnittstelle wird gl�cklicherweise
vom Norton Commander, LAPLINK, FASTLYNX, FILELINK und INTERSRV/INTERLNK
das gleiche Parallel-Nibble-Transfer-Kabel (oft als 'Laplink'-Kabel
bezeichnet) ben�tigt, das mittlerweile auch in PC-L�den zu kaufen ist
und nicht mehr nach der Programmdokumentation selbstgebastelt werden
mu� (siehe z.B. im DOSBOOK bei FILELINK).
Die �bertragungsrate h�ngt von der Rechnergeschwindigkeit und der Aus-
legung des Ports ab, ist normalerweise aber mindestens einer seriellen
Verbindung mit 110 kBd ebenb�rtig, mit starker Tendenz nach oben (bis
ca. 1 MByte/s). Eventuell wird mit Druckerports von uralten Original-PCs
(1. Serie) sowie mit modernen ECP/EPP-Ports auch ein bidirektionaler
Transfer erm�glicht, wof�r aber ein anderes Kabel notwendig w�re (mangels
zweier solcher Schnittstellen habe ich das noch nicht �berpr�fen k�nnen).
Interessant ist, da� FASTLYNX 2.0+ sogar Verbindungen durch ein auf
den zugeh�rigen Rechnern geladenes IPX tunneln kann (wie heutige, hier
nicht verzeichnete Versionen von LAPLINK auch). Daf�r m�ssen lediglich
die Netztreiber der IPX-Schicht (bei Personal NetWare also der Hardware-
Treiber wie NE2000.COM sowie LSL.COM und IPXODI.COM) geladen sein,
SERVER.EXE oder VLM.EXE sind nicht notwendig! Manchmal reichen die
M�glichkeiten einer Punkt-zu-Punkt-Verbindung ja durchaus aus und die
komplette Netzankopplung eines Rechners wird gar nicht ben�tigt. In
diesem Fall kann man sich so das Laden der restlichen Client- (VLM.EXE
oder NETX.EXE) oder Server-Software (SERVER.EXE) sparen und so wertvollen
Speicherplatz gewinnen.
Diese Methode hat auch den Vorteil, da� zwischen den beiden Rechnern
keine 1:1-Verkabelung bestehen mu�; ein installiertes Ethernet tut's
auch. FASTLYNX fragt in diesem Fall nach, welchen Rechner es als
Gegenstelle annehmen soll. Da VLM.EXE (und SERVER.EXE) nicht geladen
werden mu�, funktioniert eine solche Verbindung (bei geeigneter Ein-
stellung) sogar dann, wenn man die IPX-Treiber unter dem multitaskenden
TASKMGR nur innerhalb eines Tasks l�dt! In den anderen Tasks hat man
dann zwar keine IPX-Verbindung, daf�r aber mehr Speicherplatz zur
Verf�gung...
Ein interessanter Einschub f�r PNW:
Ja, das geht wirklich! - W�rde man f�r eine vollst�ndige Netzankopplung
hingegen auch VLM.EXE (und SERVER.EXE) laden wollen, so m��te dies vor
dem Start des TASKMGR geschehen, oder - mit Einschr�nkungen - in einer
DOS-Box einer unter Novell DOS 7 laufenden Windows 3.1x Session im
Erweiterten 386er-Modus. Im ersteren Fall h�tten dann sp�ter alle Tasks
entsprechend viel Speicher weniger, im zweiten Fall stehen nicht alle
M�glichkeiten (NMR.VLM, FIO.VLM) zur Verf�gung und SERVER.EXE kann DPMS
nicht nutzen (Verlust ca. 28 KByte), wodurch zumindest dieser Task nur
noch sehr wenig freien Speicher �brig lie�e. Umgekehrt k�nnte man
nat�rlich in unterschiedlichen Tasks auch unabh�ngig voneinander f�r
unterschiedliche Netzadapterkarten gleichzeitig IPX-Stacks aufbauen.
Aber bitte nicht in mehreren Tasks die Treiber f�r die gleiche Netz-
adapterkarte laden oder Benutzerdaten �ndern, denn aufgrund mangelnder
Kommunikation zwischen den virtuellen Maschinen w�rde das zum Daten-
chaos f�hren (Windows f�ngt das aber �blicherweise auch ab)...
(unbedingt: siehe Kapitel VI.2.)
�blicherweise sind �ber die Netzverbindung noch gr��ere Transferraten
erzielbar als �ber parallele Verbindungen, d.h. theoretisch bis hin zu
maximal 10MBit/s.
Das Programm INTERSRV von MS-DOS soll v�llig inkompatibel zu Novell DOS 7
sein und schwere Datenverluste auf der Festplatte verursachen (nicht
�berpr�ft ;-) ). Das Gegenst�ck INTERLNK kann aber problemlos unter
Novell DOS 7 ausgef�hrt werden, so da� man trotzdem die Verbindung zu
einem MS-DOS System aufnehmen kann.
Stabilen Ersatz liefert Novell selbst in Form des recht komfortablen
Programms FILELINK mit (das in weniger leistungsf�higer Version auch
schon bei DR DOS 6.0 beilag).
F�r viele ist jedoch die in den Norton Commander (NC) integrierte
Link-Funktion die einfachste Alternative zu letzten beiden Programmen,
weil man sich nicht an eine andere Umgebung gew�hnen mu� und (fast)
alles genauso funktioniert, als wenn man zwischen zwei Verzeichnissen
des gleichen Rechners Dateien hin und her kopiert.
Lediglich die bei MS-DOS INTERSRV/INTERLNK gegebene M�glichkeit
der Ausf�hrung von Kommandos auf dem Fremdrechner bietet FILELINK
nicht, aber daf�r gibt es sowieso wesentlich bessere Alternativen
wie etwa obiges FASTLYNX (FX). (Die mir bekannten, �lteren und
ehemals standardsetzenden Versionen von LAPLINK k�nnen weder von
der Funktionalit�t, noch von der Flexibilit�t mit FASTLYNX oder
auch nur dem NC konkurrieren.)
Wenn auch etwas bodenst�ndiger, daf�r aber auch flexibler, braucht
man auch unter ausschlie�licher Verwendung von Novell DOS 7 Bord-
mitteln nicht auf eine M�glichkeit zur Fernsteuerung verzichten:
Die diesbez�glich Alternative ist eine Terminal-Emulation (etwa
CTTY COM1:), die bei Novell DOS 7 nat�rlich besonders in Verbindung
mit dem TASKMGR Sinn ergibt. Dieselbe serielle Verbindung kann auf
beiden Rechnern jedoch nicht gleichzeitig von mehreren Programmen
benutzt werden. Multitasking-Betrieb mit Zugriff auf die gleiche
Schnittstelle ist daher nicht angebracht. Stehen mehrere serielle
Kan�le zur Verf�gung, ist das Ganze jedoch kein Problem. N�heres
hierzu in Kapitel VII.5.
---------------------------------------------------------------------------
II.9. Erweiterte Kommandozeilen-Syntax am Prompt: [97-03-23]
============================================================
Stichworte: Kommandozeile, Prompt, Syntax, COMMAND.COM, 4DOS, Pa�w�rter,
Listendateien, Dateilisten, Gruppen, UNC
Obwohl es auch f�r Novells COMMAND.COM noch besseren Ersatz gibt (4DOS),
ist die Syntax der Kommandozeile (auch bei den externen Kommandos) in
einigen interessanten Punkten erweitert (dies ist zwar teilweise seit
DR DOS 3.41 dokumentiert, da aber immer noch MS-DOS als 'Standard' gilt,
weitestgehend unbekannt), siehe auch Kapitel II.11. Auch die meisten
externen Novell Kommandos erlauben diese Erweiterungen.
- Pa�w�rter: Nach der Dateispezifikation kann ein Datei-/Pfadpa�wort
mittels Semikolon angeh�ngt werden (ab DR DOS 3.41):
DIR file;password
(Achtung: Unter 4DOS mu� das Semikolon i. allg. verdoppelt
werden! Allerdings kann man dies leider nicht auf alle
Befehlen �bertragen: Befehle, die keine 4DOS-Include-
Listen erlauben (wie MD, CD) und deshalb auch ein ein-
faches Semikolon nicht mi�verstehen w�rden, akzeptieren
leider auch kein verdoppeltes Semikolon, und das, obwohl
ein Semikolon kein g�ltiges Zeichen f�r ein Pa�wort ist,
und daher eigentlich beides zugelassen werden k�nnte,
siehe auch Kapitel II.20.)
Mit dieser Syntax werden nicht nur bereits mit PASSWORD
gesetzte Pa�w�rter angegeben, sondern es k�nnen implizit
auch neue Pa�w�rter gesetzt werden. Problematisch daran
ist, da� die Angabe eines Pa�wortes unter MS-DOS und
PC-DOS nicht erlaubt ist. N�heres zu diesem Themenkomplex
in Kapitel II.4. unter PASSWORD.
Die Angabe eines Pa�wortes (auch unter 4DOS nur mit einem
Semikolon getrennt) ist auch innerhalb der Eingabemasken
beliebiger Fremdprogramme m�glich und notwendig, falls die
jeweiligen Programme mit diesen Dateien trotz gesetzter
Pa�w�rter arbeiten sollen). Voraussetzung daf�r ist aller-
dings, da� das Programm das Semikolon und eine mehr als
8 Zeichen lange Eingabe in Unkenntnis dieses Novell DOS/
DR DOS Features nicht als ung�ltig zur�ckweist (wie leider
h�ufig der Fall). Dies funktioniert deshalb, weil die
Pa�wortunterst�tzung von DR DOS/Novell DOS direkt im
Betriebssystem-Kernel untergebracht und nicht etwa
- wie oft vermutet - eine Eigenschaft der jeweiligen
Kommandos ist! (Dies bedeutet �brigens auch, da� auch auf
API-Ebene in Dateispezifikationen mit Semikolon getrennte
Pa�w�rter angegeben werden k�nnen.) Nat�rlich besitzen
unabh�ngig von diesem Sachverhalt die meisten Novell/
DR DOS Programme *zus�tzliche* Sonderbehandlungen f�r
Pa�w�rter, die den Komfort noch steigern; der grund-
s�tzliche Mechanismus ist jedoch Bestandteil des Kernels
und kann daher prinzipiell aus jeder Anwendung heraus
verwendet werden (auch wenn diese nicht das geringste
von Pa�w�rtern ahnt).
Und was machen Sie, wenn sowohl �bergeordnete Ver-
zeichnisse, als auch die Dateien selbst mit einem
(unterschiedlichen) Pa�wort versehen sind?
Wenn Sie sich schon im pa�wortgesch�tzten Verzeichnis
befinden, brauchen Sie normalerweise nur das Pa�wort der
Datei angeben, da Sie �ber einen relativen Pfad (den Sie
sich bereits 'freigeschaltet' haben) auf die Datei zu-
greifen. In Ausnahmef�llen (z.B. beim Aufruf von Programm-
dateien in solchen Verzeichnissen) wird jedoch intern �ber
den vollen Pfad auf die Datei zugegriffen: In solchen
F�llen m��te man eigentlich *beide* Pa�w�rter angeben,
so als ob Sie sich noch au�erhalb des pa�wortgesch�tzten
Verzeichnisses bef�nden. Dies scheint auf den ersten Blick
unm�glich, d.h. man m��te immer erst in das jeweilige
Verzeichnis wechseln.
Es gibt aber eine v�llig undokumentierte M�glichkeit, die
leider derzeit nur mit Novells COMMAND.COM funktioniert:
c:\testdir sei pa�wortgesch�tzt mit
Pa�wort "hello" und
c:\testdir\dummy.txt sei pa�wortgesch�tzt mit
Pa�wort "world"
TYPE c:\testdir;hello\dummy.txt;world funktioniert!!!
Das Prinzip l��t sich bei weiter verschachtelten Unter-
verzeichnissen auch auf mehr als zwei Pa�w�rter verallge-
meinern. Die Angabe mehrerer Pa�w�rter in einer Datei-
spezifikation wird von 4DOS 5.51/5.52a (und fr�her) leider
als Fehler zur�ckgewiesen.
Pa�wortgesch�tzte Verzeichnisse stellen unter 4DOS sowieso
ein gewisses Problem dar, denn der Novell DOS Kernel will
nat�rlich in einem Fall wie dem obigen beide Pa�w�rter
wissen, und da 4DOS intern offenbar immer �ber absolute
Pfade auf Dateien zugreift, auch dann, wenn man sich
bereits im Verzeichnis C:\TESTDIR befindet, trifft diese
Situation hier st�ndig auf...
Um aber wenigstens bez�glich der anderen Unterschiede
in der Pa�wortbehandlung Kompatibilit�t unter 4DOS und
Novell DOS bzw. DR DOS COMMAND.COM zu erreichen, sollte
man in Batchjobs generell folgenden Trick anwenden:
DIR file%;%;password
wobei die Umgebungsvariable %;% unter Novell DOS' und
DR DOS' COMMAND nicht definiert ist (und mit SET aufgrund
ung�ltiger Syntax auch nicht definiert werden kann; es sei
denn auf Seitenwegen �ber direkte Manipulation der System-
Umgebung), unter 4DOS jedoch ganz normal belegt werden
kann. Irgendwo vorher (z.B. in AUTOEXEC.BAT) f�gt man dann
folgende Zeile in die Batch-Bearbeitung ein:
IF "4"=="%@Eval[2 + 2]%" SET ;=;
In obigem Beispiel wird nun unter 4DOS die Variable %;%
durch ';' ersetzt und das Pa�wort wird von zwei Semikolon
eingeleitet. Unter COMMAND.COM ist die Variable %;% nicht
definiert und wird durch eine Null-Zeichenkette ersetzt.
Dadurch erscheint nur ein Semikolon in der Kommandozeile.
Es ist �brigens wichtig, da� das erste Semikolon durch %;%
ersetzt wird, denn ansonsten m��te man vor dem Pa�wort
noch ein f�r die Dateibearbeitung nicht akzeptiertes
Leerfeld angeben. Dieser Trick kann auch unter der
4DOS-Kommandozeile angewendet werden, nicht aber in der
COMMAND.COM-Kommandozeile, da hier keine Ersetzung von
Umgebungsvariablen stattfindet. Innerhalb von Datei-
eingabemasken von Programmen ist diese Angabe ebenfalls
nur in den seltensten F�llen erlaubt, da auch hier so
gut wie nie Ersetzungen von mit % eingerahmten Variablen
stattfinden (Ausnahmen sind aber vorhanden und sollten
f�r eigene Programme ber�cksichtigt werden).
Ein Problem besteht allerdings immer noch:
Batchjobs, in denen entsprechend dieser erweiterten Syntax
explizit Pa�w�rter angegeben werden, arbeiten unter
Novell DOS/DR DOS als auch unter 4DOS/NDOS, nicht aber
unter MS-DOS/PC-DOS.
Normalerweise werden hier auch keine Pa�w�rter gesetzt
sein, aber es besteht ja die M�glichkeit, da� unter
Novell DOS Pa�w�rter gesetzt wurden und danach der Rechner
unter MS-DOS gebootet wird. Noch komplizierter wird es,
da bei aktiviertem Long-Filename-Support mit MS-DOS 7
unter MS Windows95 sogar das Semikolon zum g�ltigen
Zeichen einer Dateispezifikation avanchiert.
Wenn man Batchjobs schreiben m�chte, die auch unter
diesen Voraussetzungen noch sauber arbeiten, mu� man
einen weiteren Trick anwenden, indem man auch die
Pa�w�rter nicht direkt, sondern �ber Umgebungsvariablen
angibt: Diese Umgebungsvariablen d�rfen dann nur belegt
werden, wenn unter Novell DOS/DR DOS gebootet wurde
(siehe Kapitel IV.7.).
Das folgende Beispiel verdeutlicht dies:
...
SET envpassword=
IF NOT "NWDOS"=="%Os%" IF NOT "DRDOS"=="%Os%" ...
... IF NOT "OPENDOS"=="%Os%" GOTO skip
IF "4"=="%@Eval[2 + 2]%" SET ;=;
SET envpassword=password
:skip
DIR file%;%;%envpassword%
SET envpassword=
...
Diese Syntax mu� genau eingehalten werden, damit sie unter
allen Versionen von COMMAND.COM sowie 4DOS/NDOS arbeitet.
Dabei
wird die Angabe des Pa�wortes unter den einzelnen
Betriebssystemen recht unterschiedlich ausgewertet,
das Resultat ist jedoch immer, da� die Funktion bereit-
gestellt wird, die jeweils notwendig ist:
Unter anderen Systemen als DR DOS und Novell DOS werden
die Variablen %envpassword% und %;% nicht belegt, daher
wird nur "DIR file" ausgef�hrt. Unter DR DOS/Novell DOS
COMMAND.COM wird %envpassword% belegt und damit
"DIR file;password" ausgef�hrt. L�uft 4DOS/NDOS unter
DR DOS/Novell DOS, so werden beide Variablen belegt, das
Ergebnis ist "DIR file;;password".
Voraussetzung f�r die Funktion dieses Beispiels ist es,
da� die Variable %Os% auch unter 4DOS/NDOS gesetzt wird,
was �blicherweise *nicht* der Fall ist (mu� z.B. in
AUTOEXEC.BAT manuell geschehen, wenn ein DR DOS/Novell DOS
Kernel erkannt wurde, siehe Kapitel IV.7.). Wie dies
sicher bewerkstelligt werden kann, wird an anderer Stelle
in dieser Datei beschrieben.
- Listendatei: Bei vielen Kommandos kann statt einer direkten Datei-
auflistung mit direkt vorangestelltem @ eine Datei
angegeben werden, die eine Liste von zu bearbeitenden
Dateien enth�lt (ab DR DOS 5.0).
(Hinweis: Ich unterscheide in diesem Dokument zwischen
Listendateien, d.h. Dateien, die eine Liste von Dateien
enthalten, und letzten Dateilisten, die eine Liste
mehrerer Dateispezifikationen enthalten, siehe unten.)
Die Dateien innerhalb der Listendatei k�nnen selbst auch
wieder Wildcards enthalten, wohingegen als Datei-
spezifikation f�r eine @Listendatei keine Wildcards und
damit mehrere Dateien angegeben werden d�rfen. Au�erdem
darf eine Listendatei keine Verweise auf weitere Listen-
dateien enthalten (sicher, um Rekursionen zu vermeiden);
auf diese Weise sind also auch Dateien mit einem '@'
als ersten Buchstaben (z.B. alte Backup-Dateien) innerhalb
der Listendatei problemlos ansprechbar.
Wegen der m�glichen Fehlinterpretation als Listendatei ist
es sonst notwendig, ein paar Tricks anzuwenden, um eine
Datei, die tats�chlich mit dem Zeichen '@' beginnt,
anzusprechen (siehe auch Kapitel II.20.):
- �ber relative Pfadangaben, d.h. voranstellen von '.\'
oder 'd:' (mit d: als dem aktuellen Laufwerk), z.B.
statt "@backup.dat" nun ".\@backup.dat"
- �ber Wildcards, die nicht mit '@' beginnen (z.B. ist
"@*.*" nicht m�glich)
- (tempor�res) Umbenennen der Datei (mit REN)
- Verwendung eines Ersatz-Kommandos, das keine Listen-
dateien unterst�tzt (z.B. interne Kommandos)
Eine Listendatei kann z.B. mit XDIR /B erzeugt werden:
XDIR *.txt /B > filelist.lst
um dann wie folgt verwendet zu werden:
XDIR @filelist.lst
In der Digital Research Literatur wird f�r Listendateien
h�ufig die Dateiendung .FL (File-List) verwendet (wie
gesagt, bitte im Deutschen nicht mit Dateilisten ver-
wechseln, die in diesem Dokument meist als mehrfache
Dateispezifikationen, manchmal auch als Einschlu�liste
und bei 4DOS auch als 'inclusion list' bezeichnet werden).
Normalerweise mu� jede Dateispezifikation einer Listen-
datei in einer neuen Zeile anfangen. Allerdings ist dies
- undokumentiert - nicht notwendigerweise so: Einzelne
Dateien k�nnen auch mit Leerfelder, Tab oder Komma
voneinander getrennt werden. M�chten Sie Pa�w�rter in
einer solchen Listendatei angeben, so m�ssen Sie diese
wie gewohnt mit Semikolon von der jeweiligen Datei-
spezifikation trennen, dazwischen werden keine Leerfelder
akzeptiert.
Liste der Kommandos, die Listendateien akzeptieren
(noch unvollst�ndig):
ATTRIB, FC, FILELINK, FIND, MOVE, PASSWORD, PNUNPACK,
REPLACE, STACKER, TOUCH, XCOPY, XDEL, XDIR.
(Bei CCI Multiuser DOS 7.22 COMP statt FC, au�erdem
noch XATTRIB.)
Es gibt auch eine Reihe Fremdprogramme, die Listendateien
unterst�tzen, etwa alle Programme von PKWare (PKPAK,
PKUNPAK, PKZIP, PKUNZIP, usw.). Einige dieser Fremd-
programme erlauben jedoch auch Kommentare in Listen-
dateien, die meist einfach mit Semikolon eingeleitet
werden (nicht unbedingt am Anfang der Zeile). Hier gibt
es u.U. Probleme, wenn DR DOS oder Novell DOS solche
Kommentare als Pa�w�rter zu interpretieren versucht.
Wenn Sie das Semikolon nur jeweils unmittelbar hinter
einer normalen Dateispezifikation verwenden, gibt es
zwar keine Syntaxfehler und solange Sie die Listendatei
nicht zum Erzeugen oder Ver�ndern von Dateien verwenden
auch keine Probleme: Der Kernel interpretiert zwar die
Kommentare als Pa�w�rter, was aber solange ohne Folgen
bleibt, wie die Datien keinen Pa�wortschutz besitzen
und nicht schreibend auf sie zugegriffen wird (mit
XDIR und bedingt XDEL klappt's also prima). Mit XCOPY
erhalten die neuen Dateien aber die Kommentare als
Pa�w�rter, sicherlich nicht das, was gew�nscht wurde...
- Mehrere Dateispezifikationen in einer Zeile (Dateilisten):
�hnlich wie bei 4DOS k�nnen in vielen F�llen (meist bei
externen Kommandos, wo die Syntax dabei eindeutig bleibt)
direkt mehrere Dateispezifikationen in einer Zeile an-
gegeben werden (ab DR DOS 5.0); diese k�nnen sogar Wild-
cards enthalten. Darauf wird in den Hilfe�bersichten (/?)
der entsprechenden Kommandos hingewiesen:
XDIR *.TXT *.DOC
Anstelle der Dateispezifikationen k�nnen Sie nat�rlich
auch hier Listendateien angeben, auch mehrere gleich-
zeitig. Die einzelnen Spezifikationen m�ssen bei DR DOS
und Novell DOS mit Leerfeldern oder Tabs voneinander
getrennt werden, Kommata werden zur�ckgewiesen, Semikoli
als Einleitung f�r Pa�w�rter interpetiert. Dies ist
wichtig zu wissen, da die unter 4DOS/NDOS �blichen
Dateilisten (inclusion lists) hier meist ein Komma er-
warten (oft reicht aber auch hier ein Leerfeld oder Tab).
Die einzelnen Dateien oder Masken werden zusammengefa�t
und gemeinsam bearbeitet (also nicht der Reihe nach ge-
trennt bearbeitet). Auf diese Weise wird sichergestellt,
da� jede Datei auch wirklich nur einmal bearbeitet wird,
obwohl sie vielleicht auf mehrere Masken pa�t. (Achtung:
Einige Nach-Implementationen dieser Funktion, etwa in
meiner CUI_LIB, bearbeiten die einzelnen Masken der
Reihe nach, so da� eine Datei u.U. auch mehrfach benutzt
wird.)
Kommando�bersicht, die dies unterst�tzen
(noch unvollst�ndig):
ATTRIB, FIND, PASSWORD, TOUCH, XDEL, XDIR.
Die Dateispezifikation bei XDIR darf auch mit doppelten
Anf�hrungszeichen (") eingerahmt werden (sinnvoll f�r
Spezialf�lle, vgl. FIND).
- Gruppen: Diese undokumentierte M�glichkeit vieler Kommandos
erlaubt die Angabe von Benutzeranmelde (also Account-Name)
oder Gruppennamen in der Syntax /U:name (auch schon bei
einigen Kommandos von DR DOS 6.0).
Bekommt in Verbindung mit Novell DOS/DR DOS Multiuser-
Varianten, von denen Novell DOS genauso abstammt wie von
DR DOS 6.0, eine Bedeutung, sofern die Systemabsicherung
aktiviert ist (die bei DR Multiuser DOS beiliegenden
zus�tzlichen Kommandos kennen jedenfalls auch die Option
/U, etwa SHOW oder XATTRIB). Ob die Option auch in Ver-
bindung mit NetWare, lokaler Absicherung etc. eine
Bedeutung hat, ist eher fraglich, auch wenn es dort auch
Gruppen- und Benutzernamen gibt.
Die entsprechenden Programme pr�fen auf Multiuser-Eigen-
schaften des Betriebssystems, nicht auf Netzanbindung,
siehe auch Kapitel VII.5.
Kommando�bersicht, die /U:name unterst�tzen:
- Novell DOS 7, OpenDOS, CCI Multiuser DOS 7.22 Gold:
ATTRIB, BACKUP, MOVE, TOUCH, TREE, XCOPY, XDEL, XDIR
- DR DOS 6.0+, Novell DOS 7, OpenDOS:
DELPURGE, UNDELETE
- nur Multiuser-Varianten wie CCI Multiuser DOS 7:
XATTRIB, SHOW???
Falls jemand ein Concurrent DOS oder DR Multiuser DOS
besitzt, w�re es nett, wenn er mir entsprechende
Informationen �bermitteln k�nnte. Denn mit einem
kleinen selbstgeschriebenen Treiber lie�e sich auch
f�r ein 'normales' Novell DOS eine sinnvolle Funktion
f�r dieses Feature nachkonstruieren.
- Optionskombinationen:
Statt der �blichen Variante, jeden Parameter einzeln
mit einem SwitChar einzuleiten, kann man bei den meisten
externen (und allen internen) Kommandos Parameter auch
zusammenfassen:
XDIR *.* /C /L /P /S -> XDIR /CLPS
Getestet (noch nicht vollst�ndig): XDIR, XCOPY, XDEL, MOVE
Das Kommando ATTRIB erlaubt dies auch f�r die '+'/'-'-
Optionen.
- Hilfeparameter:
Normalerweise mu� ein Hilfeparameter (/? oder /H) der
erste Parameter eines Kommandos sein, damit er generell
akzeptiert wird (so zum Beispiel bei allen internen
Kommandos). Bei den externen Kommandos gilt dies im
Prinzip auch, weil es z.B. bei XDIR und XCOPY mit dem
/H Parameter zu Doppeldeutigkeiten kommen k�nnte. Ein
hinten angegebenes /H bedeutet dann also nicht /HELP,
sondern steht f�r die entsprechend zugeordnete Funktion.
Nichtsdestotrotz funktioniert /? (meist) auch am Ende
einer Befehlszeile, und auch in Optionskombinationen.
Ist der SwitChar (siehe Kapitel II.1.) auf '-' statt des
�blichen '/' verstellt, so bekommen Sie Probleme mit
Programmen, die die Angabe von ausschlie�enden Datei-
attributen �ber die Syntax -H erlauben (XDIR), da diese
dann als Aufforderung zur Hilfe mi�verstanden werden.
Abhilfe ist nur m�glich, indem Sie den SwitChar -
zumindest vor�bergehend - auf ein anderes Zeichen als
'-' (bzw. '+' bei Einschlu�listen) einstellen.
Achtung: ? ist gleichzeitig auch ein DOS-Wildcard.
Achten Sie darauf, da� Sie den /? Parameter nicht dort
verwenden, wo er als Dateimaske fehlinterpretiert werden
k�nnte (wie dies manchmal am Ende von Optionskombinationen
m�glich ist).
Vielleicht ist es f�r Sie bei der automatischen Auswertung
von Hilfsschirmen (etwa innerhalb von Batchjobs) von Be-
deutung zu wissen, da� die Hilfeschirme von DR DOS und
Novell DOS 7 ein bestimmtes Format haben:
Zun�chst folgt eine Zeile mit dem Namen des Kommandos,
bei externen Kommandos der Versionsnummer und einer Kurz-
beschreibung seiner Funktion, danach folgt bei den ex-
ternen Kommandos eine Zeile mit dem Copyright-Hinweis.
Nach einer Leerzeile folgt ein Syntax-�berblick, eine
weitere Leerzeile und danach die Erkl�rung der einzelnen
Parameter. Optional folgt (oder ist vor der Parameter-
erkl�rung eingef�gt) eine weitere Leerzeile und zus�tz-
liche Benutzungshinweise und Beispiele.
Au�erdem ist es bei Novell DOS m�glich, Pfad- und Dateispezifikationen
in der normalen 'DOS-Syntax', und auf Netzlaufwerken auch in der
NetWare-Syntax und UNC-Notation anzugeben, siehe Kapitel VI.10.
Weitere Hinweise zu COMMAND.COM Interna in der Datei NWDOS7UN.TXT.
---------------------------------------------------------------------------
II.10. Gemischte DOS-Systeme:
=============================
Stichworte: DR DOS, MS-DOS, PC-DOS, NWDOS
Im Gegensatz zur verkrampften Situation bei MS-DOS ist es bei
Novell DOS (wie schon bei DR DOS) meist m�glich, die externen
Kommandos auch unter anderen DOS-Versionen auszuf�hren. (Bei MS-DOS
sind noch nicht einmal die Kommandos von 6.21 unter 6.22
einsetzbar, von ganz wenigen Ausnahmen, wohl eher Versehen,
abgesehen.)
Die Novell DOS Kommandos melden nur dann 'Falsche DOS-Version' oder
'Falsche Version des Betriebssystems', wenn sie wirklich irgendeine
interne Funktionalit�t des Systems ben�tigen, die eben nicht
unterst�tzt wird. Meist erlauben sie einfach nicht den Zugriff auf
Optionen, die das jeweilige System nicht unterst�tzt. Diese
Austauschm�glichkeiten macht sogar vor den Speichermanagern nicht
halt, die (unter bestimmten Umst�nden) miteinander vermischt werden
k�nnen. Programme wie TASKMAX bzw. TASKMGR k�nnen nat�rlich nicht
unter anderen Betriebssystemen arbeiten. Da� Microsoft hier eine v�llig
andere Taktik verfolgt, sieht man allein schon daran, da� man die meisten
(aber nicht alle) dieser MS-DOS Programme mit SETVER doch zum einwand-
freien Lauf �berreden kann.
Dadurch ist das Mischen verschiedener DR DOS und Novell DOS
Versionen (in beiden Richtungen), als auch die Vermischung mit MS-DOS
und PC-DOS Systemen zu gro�en Teilen m�glich (praktisch in Netzen).
Da die Novell DOS Kommandos i. allg. mehr Optionen anbieten, stellen sie
oft einen besseren Ersatz f�r MS-DOS Systeme dar. Insofern k�nnen auch
MS-DOS Benutzer (aus welchen Gr�nden auch immer) von einigen der
Verbesserungen durch Novell profitieren.
Lediglich bei speziellen Programmen wie Ger�tetreibern ist der Betrieb
unter fremden DOS'en nicht m�glich. Dies liegt daran, da� diese Treiber
von vornherein f�r Novell DOS 7 optimiert wurden und nur bei 'intimer'
Ausnutzung der Novell DOS Interna ihre besonderen F�higkeiten entfalten
k�nnen.
Besonders interessant ist die M�glichkeit, DPMS unter MS-DOS oder
PC-DOS zu nutzen und so mit den entsprechenden Fremdprogrammen seine
DOS-Konfiguration zu optimieren. Mit PC-DOS 7 wird sogar ein eigener
DPMS-Treiber mitgeliefert, der allerdings durch eine aktuellere
Version von Novell (aus einem Update) ersetzt werden sollte.
Einige Hinweise zur Kombination wurden 1995 in c't dargestellt,
speziell zu IBM PC-DOS 7 und NWDOS 7 sei auf c't 09/1995 S. 210
verwiesen.
---------------------------------------------------------------------------
II.11. Interne Kommandos und Optionen von COMMAND.COM: [97-04-23]
=================================================================
Stichworte: COMMAND.COM, NWDOS7UN.TXT, DIR, %DirCMD%, COPY, EXIT, ., ..,
CLS, PROMPT, Region-Support
i. Aufrufoptionen:
------------------
Sp�testens mit Update 15 wurden auch die noch fehlenden, zum Teil auch
bei MS-DOS noch undokumentierten Aufrufoptionen f�r COMMAND.COM
implementiert:
c:\nwdos Dokumentiert
Angabe des Home-Verzeichnisses f�r Novell DOS
Programme. Diese Angabe sollte man nicht
vergessen, da sie die grundlegende %Path% Ein-
stellung bewirkt, so da� die Novell DOS Programme
immer gefunden werden k�nnen.
device Teilweise dokumentiert.
Angabe eines Ger�tes f�r Ein- und Ausgabe (z.B.
AUX), wie Kommando CTTY.
Manchmal ist es wichtig, sicherzustellen, da�
die Boot-Bearbeitung von AUTOEXEC.BAT nicht
unterbrochen wird (ist ja in Grenzen auch mit
BREAK off m�glich). Oder die Bildschirmausgaben
von AUTOEXEC.BAT sollen unterdr�ckt/umgeleitet
werden. Man k�nnte dann hier z.B. NUL angeben,
was die Konsole an das Null-Device koppeln w�rde.
Gegen Ende der AUTOEXEC.BAT mu� dann aber mit
CTTY CON: wieder auf die Standard-Ein-/Ausgabe
umgeschaltet werden, sonst l��t sich der Rechner
nicht mehr bedienen. Halten Sie eine Boot-Diskette
in Reichweite!!!
/? und /H Dokumentiert
Ausgabe der Hilfeseite (unvollst�ndig)
/C command Dokumentiert
/Ccommand Startet tempor�re Kopie und f�hrt dort das bel.
/C=command Kommando command aus (auch Batchjobs), vgl. /K
und EXIT weiter unten in diesem Kapitel.
Das Leerfeld zwischen der Option /C und dem
Kommando ist optional und kann auch durch ein
Gleichheitszeichen '=' ersetzt werden. Ein Doppel-
punkt ':' ist hingegen leider nicht erlaubt.
/D Undokumentiert bei Novell DOS
Unterdr�ckt die Abarbeitung von AUTOEXEC.BAT und
der Frage nach Datum und Uhrzeit (wie bei MS-DOS/
PC-DOS 5.0+)
/E:nnnnn Dokumentiert
Stellt die Gr��e des Master-Environment ein, d.h.
die Umgebung des prim�ren Kommandoprozessors.
Der g�ltige Wertebereich ist 129..32751, wird dies
�ber- oder unterschritten, so wird der Default-Wert
256 angenommen (anscheinend ist der effektiv mini-
male Wert jedoch 160 und die Angaben werden in
Paragraphen aufgerundet). Gibt man /E:value bei
sekund�ren Kopien an, so wird entweder diese
Gr��e bereitgestellt oder die Gr��e der bereits
existierenden Umgebung (je nachdem, welcher Wert
gr��er ist).
Wie kommt diese ungerade Zahl 32751 f�r die maxi-
male Umgebungsgr��e zustande? Nun, dies ist genau
16 Bytes weniger als ein halbes 64 KByte-Segment,
und diese 16 Bytes werden f�r den MCB-Header be-
n�tigt, mit dem alle allozierten Speicherbl�cke
beginnen.
�brigens mu� hinter der eigentlichen mit SET und
%% sichtbaren Umgebung auch noch Platz f�r m�gliche
zus�tzliche Zeichenketten (wie den Pfadnamen der
ausgef�hrten Programmdatei, zu der diese Umgebung
geh�rt) sein.
Diese Gr��e der Umgebung wird auch bei sekund�ren
Kopien des Kommandoprozessors bereitgestellt
(nicht bei DR DOS, von DR DOS 6.0 Updates ab 1992
abgesehen).
/K command Undokumentiert bei Novell DOS.
/Kcommand �hnlich wie /C, allerdings erscheint danach der
/K=command Prompt. Sinnvoll z.B. zur Aufnahme in DOSPRMPT.PIF
von MS Windows (analog zu 4DOS' 4START.BAT
Dateien). Die gestartete Shell kann mit EXIT
verlassen werden.
Der Unterschied zu /C besteht insbesondere darin,
da� mit /K 'im Prinzip' eine permanente Kopie
von COMMAND.COM geladen wird (wie mit /P), aller-
dings trotzdem die M�glichkeit zum EXIT besteht,
vgl. Beschreibung zu EXIT weiter unten in diesem
Kapitel.
M�chte man sich mit der CONFIG.SYS SHELL= Direktive
die M�glichkeit f�r EXIT nicht verbauen, kann man
statt der �blichen Option /P auf die Option /K aus-
weichen (siehe auch bei EXIT etwas weiter unten in
diesem Kapitel sowie bei SHELL= in Kapitel III.1.),
etwa:
SHELL=c:\nwdos\command.com c:\nwdos /E:512 /P:autoexec.bat
ersetzen durch:
SHELL=c:\nwdos\command.com c:\nwdos /E:512 /K autoexec.bat
Jetzt kann man auch die erste (also 'prim�re')
Kopie von COMMAND.COM beenden! Das darunterliegende
IBMBIO.COM wei� sich dann nicht anders zu helfen,
als nach Pfad und Namen eines g�ltigen Kommando-
prozessors zu fragen, der dann wieder geladen wird.
(Leider ist dabei die Angabe neuer Parametern nicht
m�glich, so da� die ehemalige SHELL= Zeile erneut
ausgef�hrt wird, i. allg. also wieder AUTOEXEC.BAT
geladen wird, obwohl alle bereits geladenen Treiber
und TSRs aus CONFIG.SYS und AUTOEXEC.BAT ja bereits
komplett zur Verf�gung stehen.)
F�r den einen oder anderen mag es dennoch sinnvoll
sein, ohne Booten den Kommandoprozessor zu wechseln
(das �berladen kostet ja zus�tzlichen Speicher).
Interessant ist das bei der Betriebssystem- und
Treiberentwicklung, beim Laden unterschiedlicher
COMMAND.COM Versionen (i. allg. des gleichen Her-
stellers). Wichtig ist ja erst einmal zu wissen,
da� es diese M�glichkeit �berhaupt gibt.
/Mx als /ML /MU /MH, dokumentiert, (nur Novell DOS und
DR DOS)
Angabe der Lage von COMMAND.COM im Speicher.
�blicherweise wird /MH zum Laden in die HMA
empfohlen.
Hieraus ist auch ersichtlich, da� es es hierbei um
eine Option von COMMAND.COM, und nicht - wie oft
vermutet - von CONFIG.SYS SHELL= handelt und da�
man damit keine Fremd-Kommandoprozessoren hoch-
laden kann (die diese M�glichkeit aber u.U. auch
bieten).
/MSG (Nur MS-DOS und PC-DOS, obsolet bei Novell DOS)
/P[:autoexec.bat] Dokumentiert
Macht zu startende Kopie permanent (EXIT wird de-
aktiviert) und bearbeitet normalerweise automatisch
die Datei AUTOEXEC.BAT. Erlaubt optional die Angabe
einer anderen Datei als AUTOEXEC.BAT. Siehe auch /K
bez�glich nicht offensichtlicher M�glichkeiten.
�brigens: Haben Sie sich schon einmal Gedanken
dar�ber gemacht, welche Werte die Batch-Variablen
%0 bis %9 innerhalb von AUTOEXEC.BAT w�hrend des
Bootens haben?
Leider ist hier eine sch�ne Kommunikationsm�glich-
keit zwischen CONFIG.SYS und AUTOEXEC.BAT bisher
nicht ausgenutzt worden: Bei Novells COMMAND.COM
sind %1 bis %9 in diesem Fall immer unbelegt, und
%0 enth�lt mit /P den Wert "autoexec.bat", bzw.
mit Angabe eines Dateinamens den Namen dieser Kon-
figurationsdatei, allerdings umgewandelt in Gro�-
schrift. An den Dateiparameter /P:[autoexec.bat]
angeh�ngte Pa�w�rter erf�llen zwar die gew�nschte
Funktion, erscheinen aber ebenfalls nicht im Para-
meter %0.
Bei 4DOS waren %1 bis %9 ebenfalls leer, und %0
enthielt den Wert der 4START.BAT-Datei.
/T Undokumentiert (ab Novell DOS 7, sowie bei
Concurrent DOS), und bedeutet 'TSR' und wird
evtl. vom TASKMGR verwendet.
Dieser Parameter ist ein gewisses Kuriosum, ist
doch auf den ersten Blick kein Unterschied zum
normalen Verhalten auszumachen.
Bisher wurde nur das Verhalten in Verbindung mit
der Option /C untersucht, es k�nnte also sein,
da� dieser Parameter mit anderen Parametern noch
weitere Auswirkungen hat. Wichtig: Verwenden Sie
/T nur, wenn der gerade aktive Kommandoprozessor
COMMAND.COM ist, da der Rechner sonst in einer
Endlosschleife h�ngenbleibt!
Bei Verwendung der Option /C wird eine neue
Kopie von COMMAND.COM geladen, der dann die
Ausf�hrung des Parameters "/C cmd" �berlassen,
d.h. 'vererbt' wird. Nach der Ausf�hrung wird
COMMAND.COM wieder beendet.
Gibt man nun zus�tzlich die Option /T an (vor der
Option /C, die als letzte Option stehen sollte,
da sie weitere Parameter erwarten kann), so wird
zwar ebenfalls eine neue Kopie von COMMAND.COM
geladen, die Bearbeitung der Kommandos jedoch
umgedreht: Die neue Kopie �bernimmt nun die Ein-
gaben vom Prompt entgegen (und arbeitet z.B. den
Batchjob weiter ab, der von der darunterliegenden
Kopie noch nicht beendet wurde). Die darunter-
liegende Kopie bekommt jedoch die Aufgabe, das
mit "/C cmd" angegebene Kommando auszuf�hren, was
sich nat�rlich verz�gert, bis die tempor�re Kopie
wieder beendet wird. Auf diese Weise kann innerhalb
von Batchjobs ein regelrechter Kommandostapel
aufgebaut werden, der dann *nach* Beendigung des
Batchjobs, der die oberste Kopie des Kommando-
prozessors beendet, in umgekehrter Reihenfolge
abgearbeitet wird!
(Mit diesem Wissen kann man auch verstehen, warum
die Option /T zum H�ngen des Rechners f�hrt, wenn
die alte Kopie des Kommandoprozessors nicht
COMMAND.COM ist. Offensichtlich geschieht dieser
Aufgabenwechsel �ber eine undokumentierte Schnitt-
stelle, die z.B. 4DOS nicht unterst�tzt, auch nicht
mit der 4DOS.INI Direktive FullInt2E=Yes. Mit Hilfe
von K3PLUS'/FreeKEYBs Break-To-DOS-Funktion k�nnen
Sie derart h�ngende COMMAND.COM Kopien aber ab-
brechen, ohne das System neu starten zu m�ssen.)
Verwendet man die Option /T ohne auch die Option
"/C cmd" zu benutzen, so wird ebenfalls ein neuer
Kommandoprozessor geladen, ganz als h�tten Sie die
Option nicht angegeben. Allerdings ist die Vorein-
stellung des Prompts dann "ECHO off", d.h. es ist
kein Prompt zu sehen (kann nat�rlich durch Eingabe
von "ECHO on" ge�ndert werden).
Achtung: Bei der Verwendung dieser Option sollten
Sie sehr vorsichtig mit den Batch-Parametern %1 %2
%3 %4 %5 %6 %7 %8 und %9 sein und diese nur bei
der ersten Instanz verwenden. Durch die umgekehrte
Reihenfolge bei der Bearbeitung ist es m�glich,
da� diese Variablen in anderen Instanzen nur
undefinierten Datenm�ll enthalten. Ein Beispiel:
test.bat:
@ ECHO off> \dev\nul
REM Nur von COMMAND.COM aus starten!!!
ECHO Start!
@ COMMAND.COM /T /CECHO Marke 1!
@ COMMAND.COM /T /CECHO Marke 2!
@ COMMAND.COM /T /CECHO Marke 3!
@ COMMAND.COM /T /CECHO Marke 4!
@ COMMAND.COM /T /CECHO Marke 5!
ECHO Ende!
Die Ausgabe dieses Batchjobs ist nicht, wie sie
vielleicht erwarten w�rden, chronologisch, sondern:
Start! Hier wird der Batchjob abgearbeitet,
Ende! die weitere Ausf�hrung des Batchjobs
aber an die tempor�re Kopie vererbt,
das "/C cmd" jedoch aufbewahrt, um
bei Beendigung der dar�berliegenden
Kopie ausgef�hrt zu werden, also ein
Art Ende-Prozess, den man auch zum
Aufr�umen oder Reinitialisieren des
Systems verwenden k�nnte.
Marke 5! Nach der Bearbeitung des Batchjobs
Marke 4! wird eine nach der anderen Kopie des
Marke 3! Kommandoprozessors wieder verlassen,
Marke 2! die dann jeweils ihren Ende-Prozess
Marke 1! ausf�hren, und danach die Kontrolle
an den darunterliegenden Kommando-
prozessor zur�ckgeben.
/Y Undokumentiert bei Novell DOS (neu mit Update 15)
(wie bei MS-DOS/PC-DOS 5.0+). Wird von Caldera
OpenDOS 7.01 noch nicht unterst�tzt.
Der angegebene Batchjob wird im Einzelschritt-
betrieb durchgesteppt (mit jeweiligen Fragen
"(J/N) ?"), vgl. <F8>-Einzelschrittbetrieb in
Kapitel II.2. Leider wird die YESCHAR= Einstellung
nicht �bernommen (getestet bis Update 15).
/N Diese undokumentierte Option ist bei Caldera
OpenDOS 7.01 Beta 4 (mit der Source-Pre-Release
vom 1997-04-21) hinzugekommen und unterdr�ckt die
Einbindung einer Behandlungsroutine f�r kritische
Fehler (INT24h).
ii. Hinweise f�r Kommando-Syntax interner Kommandos:
----------------------------------------------------
Wie in CONFIG.SYS, so akzeptiert Novell DOS COMMAND.COM bei (fast) allen
internen Kommandos (nicht COPY, CD, ...) auch an der Kommandozeile und
in Batchjobs direkt nach dem Befehl ein optionales Gleichheitszeichen.
Bei Kommandos, wo dies nicht mehrdeutig wird (wie z.B. bei ECHO) wird
das Gleichheitszeichen auch akzeptiert, wenn es nicht direkt nach dem
Befehl folgt, sondern nur das erste sichtbare Zeichen ist.
Beispiel:
...
ECHO=Dieses Gleichheitszeichen wird nicht mit ausgegeben!!!
ECHO = Dieses Gleichheitzeichen wird mit ausgegeben!!!
ECHO==Hier wird das erste Gleichheitszeichen unterdr�ckt!!!
REM Bei GOTO mu� das Gleichheitszeichen nicht *direkt* folgen:
GOTO=label1
ECHO Test1
:label1
GOTO = label2
ECHO Test2
:label2
...
Achtung:
4DOS/NDOS weist dieses Gleichheitszeichen als ung�ltig zur�ck (MS-DOS
COMMAND.COM wurde diesbez�glich noch nicht getestet). Weitere Hinweise
in Kapitel III.1.
Teilweise ist direkt nach dem internen Kommando auch noch ein Zeichen
aus ';', '.', '+', '=' erlaubt, aber h�ufig wird ein solches Zeichen
auch als ung�ltig zur�ckgewiesen oder hat gar eine Spezialbedeutung.
Von der unachtsamen Verwendung sei abgeraten.
Au�erdem wird von COMMAND.COM vor allen Befehlen eine beliebige Anzahl
Leerfelder sowie vor allen internen Befehlen ein Zeichen aus '.', ';',
'+', '=' akzeptiert (4DOS (5.52a) akzeptiert hier nur ';' und '='.)
Steht eines dieser Sonderzeichen unmittelbar vor dem Kommando, so wird
es ignoriert, ansonsten versucht COMMAND.COM offenbar, das Zeichen als
Argument f�r das *dahinterstehende* Kommando zu verstehen, was normaler-
weise zur�ckgewiesen wird. Der Sinn sei dahingestellt, wird aber durch
ein weiteres Feature, das in Kapitel IV.6. erl�utert wird, wenigstens
etwas erhellt...
Je nachdem, ob das Kommando (plus optionales Zeichen) zu Beginn der Zeile
steht oder weiter einger�ckt wurde, �ndert sich die Behandlung, falls ein
gleichnamiges Makro mit DOSKEY definiert wurde. Einger�ckte Kommandos
werden i. allg. nicht als Makros, sondern als Originale interpretiert.
Eine Ausnahme stellt in der derzeitigen DOSKEY-Implementation (Update 15)
die Ersetzung interner Kommandos direkt am Prompt dar, denn hier werden
auch bei Einr�ckung die Makros gew�hlt. Dem kann man wiederum durch
Voranstellen eines der obigen Zeichen begegnen (es sei denn, ein
gleichnamiges Makro existiert inklusive dieses Zeichens)... N�heres
hierzu in Kapitel II.4.
Ein einem Kommando vorangestelltes '@'-Zeichen mu� immer in der ersten
Spalte stehenbleiben!
Wie aufgrund mangelnder Dokumentation nahezu unbekannt, haben auch
doppelte Anf�hrungszeichen (") eine besondere Bedeutung f�r COMMAND.COM
(auch MS-DOS und 4DOS/NDOS). Passagen, die in doppelte Anf�hrungszeichen
eingeschlossen werden, werden bez�glich der Auswertung von Umleitungen
('>', '<' und '|') �bergangen (die Ersetzung von Umgebungsvariablen
findet allerdings statt). Die Anf�hrungszeichen selbst werden nicht
unterdr�ckt, so da� die Nutzung recht eingeschr�nkt ist, da Anf�hrungs-
zeichen nur bei ECHO, PAUSE etc. oder bei FIND sinnvoll verwendet werden
k�nnen. Die Anf�hrungszeichen haben (zumindest bei COMMAND.COM) keine
anderweitig klammernde Wirkung, d.h. es ist damit nicht m�glich,
Parameter, die Leerfelder enthalten, zusammenzuziehen. Stattdessen mu�
man sich die Funktion wie ein Toggle vorstellen:
@ECHO "Hallo! Bitte <ESC> dr�cken!" >dummy.lst "Ende der Durchsage..."
TYPE dummy.lst
DUMMY.LST enth�lt jetzt (4DOS f�gt ein Leerfeld mehr ein):
"Hallo! Bitte <ESC> dr�cken!" "Ende der Durchsage..."
Bei MS-DOS/PC-DOS COMMAND.COM (mit MS-DOS 6.2 und PC-DOS 7 getestet)
gibt es eine M�glichkeit, mit <Ctrl>+<t> (ASCII-20 "Pi", vgl. auch
Kapitel lI.4. bei DOSKEY) mehrere Kommandos in einer Zeile anzugeben
(bei 4DOS funktioniert ^ alias %+), mit Novells COMMAND.COM (getestet
bis Update 15) funktioniert dies nicht. Definitiv auch unter Novells
COMMAND.COM und unter 4DOS k�nnen Sie aus der Sicht vieler Betrachter
oder Editore mehrere Kommandos 'in einer Zeile' aber auch mit einem
einzelnen ASCII-10 (LF ^M) oder ASCII-13 (CR ^J) trennen. Das liegt
einfach daran, da� diese Zeichen als P�rchen sowieso einen Zeilen-
umbruch markieren und aufgrund unterschiedlicher Konventionen unter
DOS und Unix sicherheitshalber alle m�glichen Kombinationen dieser
Zeichen vom Kommandointerpreter als Zeilenumbruch verstanden werden
(siehe auch Kapitel II.4. bei DOSKEY). Sofern die Umleitung nicht
st�rt, kann man auch das Pipe-Symbol f�r solche Zwecke verwenden, etwa:
XDIR *.* | IF ERRORLEVEL 1 ECHO Fehler beim Dateizugriff!
In diesem Fall sollte man aber die Hinweise in Kapitel IV.6. beachten.
Eine andere Erleichterung ist, da� man nicht jede Option mit einem
eigenen SwitChar einleiten mu�, sondern sie kombinieren kann.
DIR *.* /S /W -> DIR /SW
Wichtig ist, da� ein Hilfeparameter (/H oder /?) generell nur dann
akzeptiert wird, wenn er als erster Parameter steht. Bei den externen
Kommandos w�rde es sonst teilweise Doppeldeutigkeiten geben k�nnen.
Dies gilt �brigens auch bei 4DOS/NDOS und bei Novell DOS f�r die meisten
externen Kommandos (XDIR, XCOPY, XDEL, MOVE).
Novells COMMAND.COM akzeptiert - wie allgemein �blich - eine maximale
Zeilenl�nge von 128 Zeichen (obwohl intern noch etwas l�ngere Zeichen-
ketten unterst�tzt werden), dieses Limit gilt auch f�r interne Kommandos
und w�hrend der Evaluierung von Umgebungsvariablen (4DOS stellt hier
eine absolute Besonderheit dar, indem es wesentlich l�ngere Zeilen
akzeptiert). Zum Vergleich: Die Zeilenl�nge in CONFIG.SYS kann bei
Novell DOS 255 Zeichen betragen, bei MS-DOS sind/waren nur 31 - 128
Zeichen erlaubt.
iii. Hinweise zu internen Kommandos:
------------------------------------
Eine �bersicht �ber die dokumentierten und undokumentierten
M�glichkeiten der COMMAND.COM internen Kommandos von Novell DOS 7
findet sich in der Extradatei NWDOS7UN.TXT.
Seit Update 15 unterst�tzt nun auch Novell DOS 7 in den Ausgaben von
DIR etc. die Tausenderseparatoren.
Im folgenden sollen lediglich relativ zusammenhangslos noch einige
zus�tzliche Hinweise zu einzelnen Funktionen verschiedener Kommandos
gegeben werden, soweit nicht offensichtlich:
/? /H Funktioniert nicht nur als Hilfeoption zu anderen Kommandos
sondern auch direkt am Prompt (d.h. ohne, da� ein Befehl
angegeben werden m��te). Liefert dann eine �bersicht �ber
alle m�glichen Befehle, die in COMMAND.COM implementiert
sind. (4DOS/NDOS bietet die gleiche Funktion, allerdings
mit einem einzelnen Fragezeichen: ?) Kann z.B. in gene-
rellen DR DOS/Novell DOS Batchjobs verwendet werden, um
herauszufinden, ob ein gew�nschter Befehl unterst�tzt wird:
/? | FIND "befehl" > %tmp%\tempfile.$$$
REM Nun die erzeugte Datei auf L�nge Null �berpr�fen...
Kann nicht als "COMMAND /C /?" angegeben werden, da dies
als Hilfe *�ber* COMMAND.COM und nicht als Wunsch nach der
Ausf�hrung des internen Kommandos /? interpretiert w�rde.
Alle bei /? aufgelisteten Kommandos besitzen eigene Hilfe-
seiten mit "befehl /?" (bis auf das sp�testens mit Update 8
hinzugef�gte TRUENAME und /? selbst...)
? als Frage, ob der folgende Befehl ausgef�hrt werden soll,
?"fragetext" darf - im Gegensatz zu CONFIG.SYS - nicht nach dem Befehl,
sondern mu� vor dem Befehl stehen (Was nat�rlich nicht aus-
schlie�t, da� ein weiteres Fragezeichen die optionale
Meldung abschlie�en darf). Dies gilt auch f�r 4DOS/NDOS
und MS-DOS COMMAND.COM. In beiden F�llen wird ein
optionales Gleichheitszeichen auch nach der Frage
akzeptiert (nicht bei 4DOS/NDOS und MS-DOS).
Klappt auch als einfaches Fragezeichen in Batchjobs,
daraufhin erscheint eine Dummy-Frage "(J/N)?", bei Druck
auf <J> aber keine Fehlermeldung. Ist bei Novells
COMMAND.COM direkt am Prompt nicht erlaubt.
Ein Meldungstext mu� in doppelte Anf�hrungszeichen ('"')
eingerahmt werden mu�. In diesem Fall unterdr�ckt
COMMAND.COM auch die Ausgabe der eigentlichen Aufrufzeile.
(In der Sekund�rliteratur konnte ich einen Hinweis finden,
da� Novell DOS einen Meldungstext auch ohne Anf�hrungs-
zeichen akzeptiert, wenn man die Frage mit einem Frage-
zeichen abschlie�t. Mit Update 15/2 konnte ich diese
Behauptung nicht best�tigen, weder in CONFIG.SYS noch
in Batchjobs.)
Kommt sowohl ein '?' als auch ein '@' als Pr�fix vor, so
mu� bei Novells COMMAND.COM (getestet bis Update 15) das
'?' vor dem '@' stehen, dummerweise ist es bei 4DOS genau
umgekehrt. Hier wird es hoffentlich in Zukunft einen Fix
in beiden Produkten geben, so da� beide Varianten akzep-
tiert werden.
@ Ein einem Befehl vorangestellter Klammeraffe (oder "at")
unterdr�ckt f�r diese Zeile das ECHO. Bei 4DOS/NDOS wird
au�erdem die Belegung der Umgebungsvariable %CmdLine%
unterdr�ckt, was Speicherplatz sparen kann. Wichtig ist,
da� das '@' bei Novells COMMAND.COM (getestet mit Update
15) immer in der ersten Spalte stehen mu�, auch wenn der
Rest des Befehls einger�ckt ist. Einzige Ausnahme ist ein
'?', das noch vor dem '@' stehen mu�.
Direkt am Prompt ist ein vorangestelltes '@'-Zeichen nicht
erlaubt.
BREAK Bei jeder R�ckkehr zum Prompt (mal von BREAK selbst abge-
sehen) und nach dem EXIT Kommando restauriert Novells
COMMAND.COM die letzte Einstellung von BREAK. Einstel-
lungen, die innerhalb einer Applikation vorgenommen
wurden, bleiben also nur f�r die Laufzeit dieser
Applikation erhalten. Da dieses Verhalten bei anderen
DOS'en nicht vorkommt, sei hier extra darauf hingewiesen.
Bez�glich der CONFIG.SYS Direktive BREAK= siehe auch
Kapitel III.1. Zumindest w�hrend der Bearbeitung von
Batchjobs sollte man nach der Testphase BREAK off setzen,
denn die Ausf�hrungsgeschwindigkeit erh�ht sich damit
dramatisch. Ansonsten ist der Geschwindigkeitsunterschied
nur recht gering:
Beispiel f�r den Anfang eines Batchjobs:
@ECHO off > \dev\nul
ECHO off > \dev\nul
IF NOT ""=="%batdbg%" ECHO %batdbg%
IF NOT "off"=="%batdbg%" IF NOT "on"=="%batdbg%" GOTO skip
BREAK %batdbg% > \dev\nul
:skip
...
Auch in Warteschleifen beim Semaphoren-Austausch
mehrerer Batchjobs unter Multitaskern sollten Sie,
um einen Benutzerabbruch zu verhindern, BREAK off
setzen.
Ohne Angabe von Parametern gibt BREAK, wie auch ECHO und
VERIFY den aktuellen Status in einer bestimmten Syntax
aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
speichern des Status verwenden kann:
BREAK = on
BREAK = off
Dies entspricht n�mlich genau der Eingabe, die man machen
mu�, um diesen Zustand nach einer Ver�nderung wieder zu
restaurieren (das Gleichheitszeichen ist optional).
@ECHO> %tmp%\echo_.bat
@ECHO off> \dev\nul
BREAK> %tmp%\break_.bat
VERIFY> %tmp%\verify_.bat
REM Nun die geforderten Einstellungen f�r diesen Batchjob
REM �ndern, z.B.:
BREAK off> \dev\nul
VERIFY on> \dev\nul
REM Hier die gew�nschte Aktion ausf�hren:
...
REM Am Ende des Batchjobs alte Einstellungen restaurieren:
@%tmp%\break_.bat > \dev\nul
@%tmp%\verify_.bat> \dev\nul
DEL %tmp%\break_.bat > \dev\nul
DEL %tmp%\verify_.bat > \dev\nul
@%tmp%\echo_.bat > \dev\nul
DEL %tmp%\echo_.bat > \dev\nul
Eine verwandte M�glichkeit bietet sich durch Speichern
des aktuellen Wertes in einer Umgebungsvariablen an, dazu
ben�tigt man allerdings eine Datei, die die Zeichenkette
"SET " (ohne die Anf�hrungszeichen und) ohne den ab-
schlie�enden Zeilenvorschub enth�lt. Damit sind Konstrukte
wie
Anweisungen: Inhalt von settmp.bat:
COPY setfile.dat settmp.bat "SET "
BREAK>>settmp.bat "SET BREAK = on"
...
Leider gilt dies nicht f�r die anderen ON|OFF-Schalter
(hier wird in der deutschen Ausgabe "ist" statt "=" und
teilweise "eingeschaltet/ausgeschaltet" statt "ON|OFF"
gesetzt) und auch nicht f�r andere Kommandoprozessoren
anderer DOS-Hersteller.
CD/CHDIR Schlecht dokumentiert ist die folgende M�glichkeit dieses
Kommandos:
Die Angabe eines Laufwerksbuchstabens gefolgt von einem
Doppelpunkt zeigt die aktuelle Pfadeinstellung f�r dieses
Laufwerk an. Wird kein Laufwerk angegeben, so wird das
aktuelle Verzeichnis verwendet.
Eine interessante Eigenschaft des CD/CHDIR Befehls (nur
bei Novell DOS 7 COMMAND.COM) erlaubt die automatische
Erkennung (aus Batchjobs heraus), ob der SwitChar ver�ndert
wurde:
Bei verstelltem SwitChar (anders als '/') wird der erste
'\' in der Pfadangabe des CD Befehls durch ein '/' ersetzt.
CD | FIND "/" > %tmp%\tempfile.$$$
REM Nun die erzeugte Datei auf L�nge Null �berpr�fen.
REM Falls sie gr��er Null ist, dann wurde der SwitChar
REM ver�ndert und d�rfte in den meisten F�llen gleich
REM '-' sein.
N�heres hierzu in Kapitel II.1.
Eine abschlie�ende Bemerkung zu Verzeichnissen:
Bei allen Versionen von DR DOS 3.4-6.0, die keine CDS im
Stil von MS-DOS hatten (also bis DR DOS 6.0 Update 11/1992)
konnten Pfadangaben beliebig lang sein. Eine Beschr�nkung
auf 67 Zeichen, wie bei MS-DOS/PC-DOS und nun auch bei
Novell DOS 7 gab es damals nicht!
Dabei wurden die Pfadangaben lediglich vorne am jeweils
m�glichen Backslash so abgeschnitten, da� Ausgaben auf
67 Zeichen formatiert wurden. Leider kamen die wenigsten
Applikationen mit dieser sehr viel flexibleren Methode
zurecht (es waren dadurch noch allerhand andere Dinge
m�glich, wie eine History der zuletzt durchlaufenen
Verzeichnisse, wurden allerdings meines Wissens nie
ausgenutzt). In eigenen Programmen sollten Sie aber nicht
davon ausgehen, da� eine Pfadangabe nur 67 Zeichen lang
sein kann (d.h. *nicht* die Routinen verwenden, die die
meisten Hochsprachen-Compiler mitbringen). Existieren
Verzeichnisse mit solchen �berl�ngen, so k�nnen sie unter
Novell DOS 7, MS-DOS und PC-DOS nicht darauf zugreifen,
und um die Pfade zu k�rzen, m�ssen Sie unter DR DOS booten.
CD /A Au�erdem bietet CD/CHDIR seit DR DOS 3.41 noch eine Option
/A an, die allerdings seit DR DOS 6.0 komplett undokumen-
tiert ist. Durch Angabe von /A wird eine Liste der aktuel-
len Pfadeinstellungen aller Laufwerke ausgegeben
(leider unterst�tzt selbst 4DOS 5.52a diese M�glichkeit
noch nicht).
Die Option CD /B, die der Ausgabe ein CHDIR voranstellt
und damit f�r den Betrieb in Batchjobs mit Umleitung
pr�destiniert ist, sowie die zum SUBST �quivalente
M�glichkeit f�r CD, etwa "CD d:=c:\path" an Stelle von
"SUBST d:=c:\path" bietet bisher leider nur Multiuser DOS
(getestet CCI Multiuser DOS 7.22 Gold), nicht aber
Novell DOS 7 oder Caldera OpenDOS 7.01, was man in Zukunft
leicht �ndern k�nnte.
COPY Ein Pa�wortschutz wird bei COPY (und XCOPY) nicht auf die
Zieldatei �bertragen (im Gegensatz zu REN). Die neue Datei
hat keinen Schutz und das Hidden-Attribut wurde gel�scht.
Das externe Kommando MOVE arbeitet demgegen�ber anders,
siehe Kapitel II.4.
Die MS-DOS 6 Variable %CopyCMD% wird nicht unterst�tzt und
es gibt auch keine hundertprozentige Methode, dieses Ver-
halten zu simulieren.
COPY /C und /Z werden von 4DOS 5.52a noch nicht unterst�tzt
und COPY /S hat bei 4DOS eine v�llig andere Bedeutung. /C
kann bei 4DOS mit /P, und /S mit /A: nachgebildet werden.
Die beiden mit MS-DOS 6.2 eingef�hrten Parameter /Y und /-Y
zur Best�tigung vor dem �berschreiben unterst�tzt
Novell DOS 7 COMMAND.COM (getestet bis Update 15) noch
nicht, da es viel fr�her eingef�hrt wurde.
Novells COPY kopiert keine Dateien mit der L�nge Null
(wie bei MS-DOS/PC-DOS), DR DOS kopierte jedoch auch diese
(ausgenommen DR DOS 6.0 Updates nach 1992).
Bei dieser Gelegenheit ein kleines praktisches Beispiel
f�r Novells COPY /Z:
IS7BIT.BAT:
@ ECHO off > \dev\nul
REM Reports "Files are equal" if file is in 7Bit-ASCII
REM Runs with Novell DOS 7 COMMAND.COM, only!!!
IF NOT EXIST %1 GOTO end
@ CALL swc.bat
@ c:\nwdos\COMMAND.COM %switch%C COPY %switch%Z ...
... %1 %tmp%\is7bit.$$$ > \dev\nul
@ CALL FC %1 %tmp%\is7bit.$$$
DEL %tmp%\is7bit.$$$ > \dev\nul
:end
COPY A:. Wie allgemein bekannt, kann man '.' und '..' nicht nur f�r
COPY A: den CD/CHDIR Befehl verwenden, sondern auch sonst.
u.a.
. steht f�r 'aktuelles Verzeichnis'
.. steht f�r das dem aktuellen Verzeichnis �bergeordnete
Verzeichnis
Dabei kann man h�ufig eine Dateispezifikation "*.*" auch
mit '.' abk�rzen, da dies ja ebenfalls 'gesamtes aktuelles
Verzeichnis' ausdr�ckt
DIR *.* bewirken also das Gleiche
DIR . (�brigens auch bei MS-DOS)
DIR
Das funktioniert z.B. auch beim COPY Befehl COPY A:. , der
den Inhalt von A:*.* ins aktuelle Verzeichnis kopiert.
COPY A: ist nun bei Novell DOS eine weitere m�gliche
Abk�rzung f�r die Abk�rzung, bezieht sich also ebenfalls
auf das jeweils aktuelle Verzeichnis und nicht auch das
gesamte Laufwerk.
COPY ...+... Interessant und besonders in Batchjobs praktisch ist
auch, da� der COPY-Befehl auch mehr als zwei Dateien in
eine Zieldatei kopieren kann, selbst wenn einige der
aufgez�hlten Dateien nicht existieren:
COPY src1+src2+src3+src4 target
kopiert die Dateien src1 bis src4 in target. Sollte z.B.
src2 nicht existieren, wird diese Datei dabei einfach
�bersprungen. Dabei sind auch in dieser Syntax-Variante
Wildcards erlaubt, etwa:
COPY *.lst+*.prn *.res
Im Gegensatz zu MS-DOS COMMAND.COM ist es bei Novell DOS
auch m�glich, ohne tempor�re Zwischendatei mehrere Dateien
zu einer Datei zusammenzuf�hren, die genauso hei�t, wie
die erste der Quelldateien, etwa:
COPY src1+src2 src1
Bei MS-DOS geht dabei der Inhalt der Datei src1 verloren!
COPY file+,, Diese undokumentierte Syntax-Variante stellt eine
Besonderheit von Novells COMMAND.COM dar, die gut mit
dem externen TOUCH-Befehl verglichen werden kann:
COPY file+,,
*simuliert* das Kopieren die Datei file auf sich selbst
und aktualisiert damit den Datums- und Zeitstempel auf das
aktuelle Datum. Die Datei file wird nicht ver�ndert, egal
ob es sich um eine ASCII- oder um eine Bin�rdatei handelt.
Im Gegensatz dazu arbeitet die Variante
COPY file+,
mit wirklichem Kopieren der Datei auf sich selbst und ist
entsprechend langsamer. Daher wird hier nicht nur der
Datums- und Zeitstempel aktualisiert, sondern es erfolgt
auch die �bliche Behandlung von ASCII- oder Bin�rdateien
(die nicht vom Dateinamen abh�ngt). Einer vornehmlichen
ASCII-Datei wird u.U. ein zus�tzliches ^Z (CP/M-Dateiende-
Zeichen) angeh�ngt, wodurch die Datei ggf. ein Byte l�nger
wird. Bin�rdateien bleiben bis auf das aktualisierte
Datum unver�ndert.
CLS Dieses Kommando l�scht normalerweise den Bildschirm durch
direkten Aufruf der entsprechenden Funktion. Ist ein ANSI-
Treiber installiert, wird jedoch stattdessen die ANSI-
ED-Sequenz "Esc [2J" ausgegeben, die den Bildschirm
l�scht. Mit der undokumentierten Umgebungsvariable %$Cls%
kann man die Sequenz �bersteuern, die an die Konsole CON:
geschickt wird. Ist diese Variable nicht belegt, tritt
das oben beschriebene Verhalten in Kraft.
Sinnvollerweise wird diese Variable bei Bedarf mit der
Steuersequenz zum L�schen des Bildschirms belegt, wie
von den g�ngigen Terminaltreibern angeboten. F�r die
Benutzung von ANSI kann man die passende Sequenz im DOSBOOK
bei der Beschreibung der ANSI-Sequenzen finden (ANSI kommt
aber i. allg. auch ohne diese Speziall�sung aus).
Sinnvoll wird diese M�glichkeit dann, wenn man mit speziel-
len Bildschirmtreibern oder v�llig abweichender Grafik-
Hardware arbeitet oder Terminalsessions f�hrt. Au�erdem
ist es auf diese Weise auch m�glich, den Bildschirm einer
"remote console" zu l�schen, etwa wenn mittels CTTY die
Konsole an eine serielle Schnittstelle gekoppelt wurde.
Dies er�ffnet wiederum neue M�glichkeiten f�r TASKMGR...
Auch Farbeinstellungen sind auf diese Weise m�glich.
Da die Eingabe von beliebigen Zeichencodes nicht in
jedem Editor m�glich ist und es zu Problemen bei der
Bearbeitung von Batchjobs kommen k�nnte, ist optional
die folgende Syntax erlaubt, die die Angabe eines
dreistelligen Oktalwertes f�r den Zeichencode erlaubt:
Da etwa die ASCII-CRT-Terminals die �bliche Escape-
Sequenz nicht verstehen, kann man stattdessen auch
SET $Cls=\033+
f�r "Esc +" eingeben (die von dem bei Novell DOS mitge-
lieferten ANSI.SYS-Treiber nicht verstanden wird). Die
Folge \033 erzeugt das Zeichen 33o=1Bh=27d.
Eine andere Anwendung besteht darin, neben der Funktion
zum L�schen des Bildschirms auch andere Einstellungen oder
Bildschirmanzeigen �ber CLS auszul�sen oder durch Belegen
von %$Cls% mit einer Dummysequenz die Funktion von CLS
sogar zu unterbinden. 4DOS 5.52a und MS-DOS COMMAND.COM
kennen die Sonderbehandlung der Variablen %$Cls% nicht.
Ist diese Variable nicht belegt (was i. allg. der Fall
ist) oder kein ANSI-Treiber installiert, wird der Bild-
schirm - wie bei MS-DOS - auf dem �blichen direkten Weg
(�ber BIOS-Funktionen) gel�scht, oder - falls ein ANSI-
Treiber vorhanden ist - durch Ausgabe der ANSI ED-Sequenz
"Esc [2J". Weitere Infos bei TYPE und in Kapitel IV.7.
CTTY Eine selten bekannte M�glichkeit dieses Kommandos ist es,
eine dauerhafte 'Umleitung' der Ein-/Ausgabe f�r Batchjobs
zu programmieren. Achtung: Halten Sie eine Boot-Diskette
bereit, da Sie bei falscher Verwendung die Eingabe von der
Tastatur abkoppeln! Siehe auch weiter vorne in diesem
Kapitel.
DATE In Verbindung mit Umleitungen siehe auch Kapitel IV.6.,
sowie Kapitel IV.1.
Die zus�tzlichen Optionen von CCI Multiuser DOS 7.22 Gold
/B (f�r Betrieb in Batchjobs) und /E (zum Setzen der Um-
gebungsvariablen %DATE%, %DOW%, %DOM% und %DOY%) bieten
Novell DOS 7 und Caldera OpenDOS 7.01 COMMAND.COM noch
nicht, dies lie�e sich aber leicht implementieren.
DEL *.* In Verbindung mit Umleitungen siehe auch Kapitel IV.6.
DEL *.* unterscheidet sich insofern von anderen DEL Auf-
rufen, als da� der Kommandoprozessor bei dieser speziellen
Maske nachfragt "Sind Sie sicher (J/N)". Ansonsten wird,
ohne Angabe spezieller Optionen ohne R�ckfrage gel�scht.
DEL, ERASE, DEL und die �lteren CP/M-Kommandos ERASE und ERA sind
ERA identisch. (Die Kurzform ERA, die seit CP/M existiert,
wird selbst von 4DOS 5.52a noch nicht unterst�tzt. Statt
der Option /C, die �brigens (wie DELQ und ERAQ) vor *jeder*
zu l�schenden Datei nachfragt, m�ssen Sie unter 4DOS die
gleichwertige Option /P verwenden, die gl�cklicherweise
auch unter Novells COMMAND.COM funktioniert.)
DELQ, ERAQ DELQ und ERAQ sind identisch (ERAQ existiert seit CP/M).
(Da selbst 4DOS 5.52a diese Kommandos nicht nachbildet,
m�ssen Sie ggf. auf dessen Option DEL /P ausweichen.)
DIR Pa�wortgesch�tzte Dateien werden trotz i. allg. gesetztem
Hidden-Attribut angezeigt (wie auch bei XDIR).
(4DOS und MS-DOS 6.20+ bietet bei DIR derma�en viele Er-
weiterungen, da� alle Erweiterungen von Novell DOS/DR DOS
gegen�ber dem alten Standard von MS-DOS hier mit den Er-
weiterungen von 4DOS/MS-DOS kollidieren. Die einzigen
Optionen von Novells DIR, die Sie ohne '�bersetzung' auch
bei 4DOS verwenden k�nnen, sind die alten Parameter /2 und
/W. Alle M�glichkeiten lassen sich unter 4DOS aber mehr als
gut nachbilden.)
DIR /C Zum Speichern der (anderen) angegebenen Parameter als
DIR /R zuk�nftige Default-Einstellung. Damit kann man MS-DOS'
Verhalten mit der Umgebungsvariable %DirCMD% in etwa
nachbilden. Nach einem Booten ist die neue Default-
Einstellung wieder gel�scht, d.h. es empfiehlt sich die
Aufnahme einer entsprechenden Zeile in AUTOEXEC.BAT.
Aus diesem Grund gibt es auch zwei verschiedene Optionen:
Mit /C wird die aktuell angegebene Einstellung nur f�r
die weitere Verwendung abgespeichert, ohne das Kommando
auch auszuf�hren (praktisch f�r AUTOEXEC.BAT und andere
Batchjobs), mit /R wird zus�tzlich das Kommando auch
direkt ausgef�hrt (praktisch f�r die Kommandozeile).
Beide Varianten existieren �brigens schon seit DR DOS
3.41+, waren allerdings bis vor DR DOS 6.0+ undokumentiert.
DIR *. Zeigt (zumeist) die Unterverzeichnisse des aktuellen
Verzeichnisses an.
Voraussetzung daf�r ist allerdings, da� alle Unterver-
zeichnisnamen keine Erweiterung haben (was durchaus erlaubt
ist und in letzter Zeit immer h�ufiger z.B. f�r Versions-
nummern von Software-Paketen etc. verwendet wird) und da�
umgekehrt alle 'normalen' Dateien eine Erweiterung haben
(das mu� auch nicht so sein).
Andere M�glichkeiten, Unterverzeichnisse abzutesten, werden
in Kapitel IV.6. und IV.3 vorgestellt.
ECHO [on|off] Die �blichen Funktionen von ECHO als Kommando (nicht
CONFIG.SYS) d�rften hinreichend bekannt sein und machen
normalerweise nur in Batchjobs Sinn. Beachten Sie, da�
unter Verwendung von doppelten Anf�hrungszeichen auch die
Zeichen '>', '<' und '|' ausgegeben werden k�nnen.
Bei DR DOS 3.41+ und Novell DOS 7 COMMAND.COM kann man
jedoch durch Eingabe von "ECHO on" oder "ECHO off" am
DOS-Prompt die Ausgabe des DOS-Prompts ein- oder aus-
schalten. Mit "ECHO off" erscheint einfach kein Prompt
mehr, unabh�ngig von "PROMPT $-". Nat�rlich lassen sich
Eingabe wie bisher vornehmen. COMMAND.COM von MS-DOS 7
reagiert genauso (das Verhalten von fr�heren MS-DOS
Versionen wurde noch nicht untersucht).
4DOS reagiert in diesem Fall anders, denn es wird nur die
zuk�nftige Einstellung von ECHO f�r Batchjobs ver�ndert.
Ohne Angabe von Parametern gibt ECHO, wie auch BREAK und
VERIFY den aktuellen Status in einer bestimmten Syntax
aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
speichern des Status verwenden kann.
N�heres hierzu bei BREAK.
EXIT [errorlevel] Mit EXIT beendet man normalerweise eine tempor�re
Kopie eines Kommandoprozessors (z.B. COMMAND.COM). Aller-
dings ist EXIT auch ein Spezialbefehl innerhalb von Batch-
jobs, der die Ausf�hrung des Batchjobs beendet. Normaler-
weise erscheint danach wieder der DOS-Prompt f�r weitere
Eingaben. Arbeitet man aber in einer tempor�ren Kopie des
Kommandoprozessors (z.B. unter dem TASKMGR bei bestimmten
Einstellungen oder in Windows DOS-Boxen (siehe SYSTEM.INI
[386Enh] DOSPromptExitInstr=Yes/No)), so wird dabei der
gesamte Task geschlossen, sofern der aktuelle Kommando-
prozessor der unterste innerhalb des jeweiligen Fensters/
Tasks ist. Beim TASKMGR und z.B. mit 4DOS h�ngt das exakte
Verhalten davon ab, ob f�r die Bearbeitung des Batchjobs
eine neue Kopie des Kommandoprozessors gestartet wurde
(sog. 'Shellen') oder �ber eine interne Software-
Schnittstelle die alte Kopie mitbenutzt wird. In
TASKMGR.INI ist diesbez�glich die Einstellung [Shell]
Exec=True/False interessant, in 4DOS.INI sollte man auf
die Einstellung von FullInt2E=Yes/No und die 4START.BAT
Dateien achten. Leider ist es aus Kompatibilit�tsgr�nden
nicht immer m�glich, einfach diese Einstellung zu ver-
�ndern (siehe z.B. Kapitel VII.3.), deshalb sollte man
EXIT in Batchjobs nur im Notfall verwenden (Es gibt
schlie�lich auch Ersatz mit "GOTO end" und einer Marke
:end am Ende des Batchjobs).
Weitere Hinweise zu EXIT siehe etwas weiter oben bei /K
und in Kapitel III.1. bei SHELL=.
Undokumentiert ist die M�glichkeit, bei EXIT einen
Errorlevel im Bereich 0..255 anzugeben, der von dem
Programm ausgewertet werden kann, in das nach EXIT
zur�ckgekehrt wird. Dies ist besonders f�r verschachtelte
Batchjobs interessant. Leider funktioniert dies nicht f�r
"COMMAND.COM /C EXIT errorcode" (liefert immer
Errorlevel 0, getestet mit Update 15), sondern nur f�r
Batchjobs wie "COMMAND /C batchjob.bat" (in diesem
Fall wird der letzte Errorlevel des Batchjobs zur�ck-
geliefert, der entweder aus dem Programmlauf oder
durch explizites Beenden via EXIT resultiert) oder
"COMMAND.COM /K batchjob.bat" (der Batchjob mu� in
diesem Fall mit EXIT beendet werden). Gibt man direkt
am Prompt EXIT mit einem Errorlevel an, so wird dieser
Wert ebenfalls an die darunterliegende Kopie des
Kommandoprozessors zur�ckgeliefert (diese M�glichkeiten
sind wahrscheinlich auch schon in DR DOS 6.0 Updates ab
1992 vorhanden, definitiv aber auch in CCI Multiuser DOS
7.22). Achtung: Werden neben dem Errorlevel noch andere
Parameter angegeben, so mu� der Zahlenwert als letzter
Parameter stehen. Es d�rfen auch nicht mehr als eine
Zahl als Parameter angegeben werden.
Die unter CCI Multiuser DOS 7.22 verf�gbare EXIT-Option
/T zum L�schen aller nach der Shell geladenen Programme
bietet Novells COMMAND.COM nicht, zur�ckgewiesen wird sie
aber auch nicht.
Auf diesem Weg gibt es also eine M�glichkeit, auch ohne
bestimmte Zusatzprogramme den Errorlevel auf einen be-
stimmten Wert zu setzen (leider etwas komplizierter, als
wenn EXIT auch direkt bei "COMMAND.COM /C EXIT code"
funktionieren w�rde):
SETERROR.BAT:
@ECHO off
REM Dieser Batchjob funktioniert nur wie gew�nscht,
REM wenn Novells COMMAND.COM verwendet wird...
REM Allerdings kann der Batchjob sehr wohl auch von
REM 4DOS/NDOS aus gestartet werden, wenn Novells
REM COMMAND.COM im Zugriff liegt...
IF "%1"=="_SETERRLVL_" GOTO errlvl
...
REM Nun soll ein bestimmter Errorlevel (hier 13) gesetzt
REM werden...
COMMAND.COM /C %0 _SETERRLVL_ 13
REM Nun gilt Errorlevel 13...
IF ERRORLEVEL 13 IF NOT ERRORLEVEL 14 ECHO Ok!
GOTO end
:errlvl
EXIT %2
:end
Eine spezielle Anwendung daf�r besteht in der M�glichkeit,
w�hrend der Abarbeitung der CONFIG.SYS Datei Batchjobs als
Makros oder Unterroutinen f�r Probleml�sungen zu benutzen,
die innerhalb der CONFIG.SYS-Sprache nicht l�sbar w�ren!
Dazu l�dt man
CONFIG.SYS:
...
INSTALL=c:\nwdos\command.com /C batchjob.bat
REM Errorlevel-Auswertung, hier als Demo:
ONERROR = 0 ECHO Kein Fehler!
ONERROR = 1 ECHO Bedingung 1 ist eingetreten...
ONERROR = 2 ECHO Bedingung 2 ist eingetreten...
...
wobei batchjob.bat beliebige Befehlsfolgen ausf�hren kann
und am Ende mit "EXIT errorlevel" einen Code an CONFIG.SYS
zur�ckliefert, der dort die weitere Bearbeitung beeinflus-
sen kann (siehe Kapitel III.1. und III.5.)! Leider ist der
Aufruf von COMMAND.COM nicht ganz r�ckwirkungsfrei, z.B.
wird damit die CONFIG.SYS Vorab-Umgebung vor der weiteren
Verwendung geschlossen.
FOR %%x IN (list) DO cmd params
Entgegen der Beschreibung im DOSBOOK sind in der Liste list
nicht nur Dateispezifikationen erlaubt, sondern beliebige
Texte, die der Reihe nach f�r die Schleifenvariable einge-
setzt werden. Achtung: Die Zeichen '?' und '*' nehmen die
�bliche Sonderstellung f�r Datei-Wildcards ein, d.h. werden
auf alle in Frage kommenden Dateien expandiert und der
Reihe nach f�r %%x eingesetzt (aus *.* wird also ein Aufruf
des Anwendungsblocks mit *jeder* einzelnen Datei, die auf
die Maske *.* pa�t, und nicht *ein* Aufruf mit '*.*'). Alle
anderen Zeichenketten werden nicht besonders ausgewertet
und werden ohne �berpr�fung, ob es sich um einen g�ltigen
Dateinamen handelt, in die Schleifenvariable eingesetzt).
Eine praktische Beispielanwendung f�r die Verwendung von
FOR abseits seiner �blichen Funktion zur Dateiexpandierung-
und -auflistung findet sich in MEM.BAT in Kapitel IV.5.
In der Dokumentation zu CCI Multiuser DOS 7.22 Gold hei�t
es, da� in der Liste keine Dateien mit Pfadangaben erlaubt
sind, zumindest auf Novell DOS 7 COMMAND.COM kann man diese
Aussage nicht �bertragen.
Manchmal kann man FOR auch verwenden, um mehrere Kommandos
in einer Zeile unterzubringen, was die Bearbeitung eines
Batchjobs beschleunigt:
FOR %%x (DIR TYPE) DO %%x test.txt
�brigens: Die Verwendung des FOR-Befehls ist auch direkt
an der Kommandozeile erlaubt, wenn man die verdoppelten
%% Zeichen durch einfache % ersetzt. Umgebungsvariablen
werden bei COMMAND.COM nicht ersetzt, 4DOS/NDOS erlaubt
auch dies (siehe auch BATTIPS.TXT).
GOSUB label [comments]
Erlaubt maximal vier Verschachtelungsstufen (getestet
mit DR DOS 6.0, Novell DOS 7 und CCI Multiuser DOS 7.22
Gold).
GOTO label [comments]
Interessant ist, da� hinter der Angabe des Sprungziels
label noch weitere 'Parameter' erlaubt sind, die allerdings
ignoriert werden. Wird GOTO direkt am Prompt von Novells
COMMAND.COM angegeben, so wird das Kommando ignoriert
(wie auch bei GOSUB, RETURN, SWITCH).
HILOAD | LH | LOADHIGH
[/L:region[,minsize[;region2[,minsize[;...]]]]][/S]
cmd params
Aus Kompatibilit�tsgr�nden unterst�tzten diese Kommandos
bei Novell DOS schon immer undokumentiert die MS-DOS
MEMMAKER Optionen /L: und /S, allerdings waren diese
funktionslos, da Novell DOS 7 keinen Region-Support besa�.
Mit Update 14 (sicher jedoch Update 15) hat sich dies ge-
�ndert: Novell DOS 7 unterst�tzt jetzt in vollem Umfang
UMB-Memory-Regions. Eine genaue Beschreibung dieser Para-
meter findet sich bei DEVICEHIGH= in Kapitel III.4. (und
Kapitel III.1., V.7.).
Zu beachten ist lediglich, da� bei HILOAD/LH/LOADHIGH,
die im �brigen untereinander identisch sind, kein Gleich-
heitszeichen vor dem eigentlichen Kommando gegeben werden
darf.
Ein Beispiel:
LH /l:2 DOSKEY /insert
Achtung: 4DOS 5.5c bis 5.52a gehen offenbar davon aus, da�
Novell DOS 7 keinen Region-Support bietet, insofern wird
eine Fehlermeldung ausgegeben: "No UMB-regions defined.
Switches ignored."
Dies wird wohl in einem zuk�nftigen Update gefixt. Auf die
gleichwertigen Parameter w�hrend der CONFIG.SYS-Bearbeitung
hat dieses Problem nat�rlich keinen Einflu�. F�r das Laden
in UMBs (nur hierf�r, da sonst die tempor�re Kopie von
COMMAND den Speicher fragmentieren w�rde) bietet sich - in
obigem Beispiel - folgendes Workaround an:
COMMAND /c LH /l:2 DOSKEY /insert
Noch ein Hinweis: Jedes Programm, das installiert wird,
bekommt vom System eine Umgebung zugewiesen. Die meisten
residenten Programme ben�tigen diese Umgebung jedoch
nach der Installation �berhaupt nicht mehr. Daher geben
umsichtig programmierte TSRs den Umgebungsblock auch
wieder frei (viele TSRs machen aber noch nicht einmal das).
Das Ganze hat trotzdem den Nachteil, da� der Speicher durch
kleine ungenutzte Speicherbereiche fragmentiert wird.
Daher sollte man beim Laden aller TSR-Programme, die nicht
in der Lage sind, Programmcode in ihren Umgebungsbereich
zu relozieren (das k�nnen leider nur sehr wenige) die
folgenden Tricks zur Optimierung des Speicherverbrauchs
beherzigen (dies ist nat�rlich nicht nur an LH etc. ge-
bunden):
Die Umgebung m�glichst klein halten, solange
residente Programme geladen werden. D.h. die SET
Anweisungen m�glichst erst am Schlu� der AUTOEXEC.BAT
einsetzen (ist leider nicht f�r alle Umgebungsvariablen
praktikabel). 4DOS/NDOS bieten mit dem SETLOCAL und
UNSET * Kommando eine M�glichkeit, die Umgebung tempor�r
zu l�schen (siehe 4DOSTIP.TXT). F�r CONFIG.SYS gibt es
mit SETENV.COM eine �quivalente M�glichkeit, siehe
INSTALL= etc. in Kapitel III.1 und im Archiv SETENV.ZIP.
In seltenen Einzelf�llen mag auch das Gegenteil sinnvoll
sein: Eine sehr gro� 'aufgeblasene' Dummy-Umgebung,
die vom TSR wieder freigegeben wird, erzeugt auch ein
'gro�es Loch' im Speicher, in das u.U. wieder ein neues
TSR hineinpa�t. Diese Optimierung erfordert allerdings
gro�en Aufwand (und einige Berechnungen anhand der MEM-
Ausgaben) und lohnt sich nur, wenn ein TSR ganz knapp
nicht mehr hochgeladen werden kann, und mehrere kleine
freie Bereiche ehemaliger Umgebungen anderer TSRs
existieren, die mindestens diese Gr��e aufwiegen.
Die Aufrufpfade von TSR-Programmen sollten m�glichst
kurz sein, da an die �bergebene Umgebung ab DOS 3.1+
auch der Aufrufpfad des Programms angeh�ngt wird. Da
diese Funktion innerhalb des Kernels ausgef�hrt wird,
kann man von au�en wenig ausrichten (man m��te schon die
Exec-Funktion INT21h/4B00h ersetzen oder �ndern). Die
tempor�re Aktivierung von SUBST-Laufwerken (um den
Aufrufpfad zu verk�rzen) ist eine m�gliche L�sung,
dabei kann man bei Novell DOS 7 (mit LASTDRIVE=32,
siehe Kapitel III.1. und III.2) auch die Laufwerke [:
bis `: verwenden, um die Belegung der anderen Laufwerke
nicht zu st�ren.
Beispiel f�r "c:\dir1\dir2\dir3\dir4\dir5\tsr.com":
SUBST z: c:\dir1\dir2\dir3\dir4\dir5
LH z:tsr.com ...
SUBST z: /D
In diesem Beispiel w�rde der Aufruf 26 Bytes (f�r
"\dir1\dir2\dir3\dir4\dir5\" gegen�ber dem direkten
Aufruf einsparen. �brigens: Die auf den ersten Blick
offensichtliche Alternative, einfach nur den Pfad des
aktuellen Laufwerks auf das Verzeichnis, in dem das
TSR liegt, zu wechseln und es dann als "c:tsr.com"
aufzurufen, n�tzt leider nichts, da der Pfad intern
normalisiert wird und wieder die volle L�nge bekommt.
Das Weglassen der Dateiendung bringt keine zus�tzliche
Ersparnis, denn diese wird immer angeh�ngt.
Dieser Trick l��t sich nat�rlich auch auf CONFIG.SYS
und INSTALLHIGH= etc. anwenden:
Beispiel f�r "c:\dir1\dir2\dir3\dir4\dir5\tsr.com":
INSTALL=c:\nwdos\subst.exe b: ...
... c:\dir1\dir2\dir3\dir4\dir5
INSTALLHIGH=b:tsr.com ...
INSTALL=c:\nwdos\subst.exe b: /D
In diesem Fall kann man nat�rlich nicht auf Laufwerke
ausweichen, die mit LASTDRIVE= definiert werden.
SUBST arbeitet jedoch auch mit bereits belegten Lauf-
werken, so da� sich hier Laufwerk B: anbietet (da Lauf-
werk A: und C: sowie andere Laufwerke oberhalb von C:
in der Boot-Phase zum Laden von Programmen referenziert
werden k�nnten).
IF Dieser Befehl ist inklusive vieler seiner Erweiterungen
im DOSBOOK beschrieben. Hinzuzuf�gen ist, da� man die
Konstruktionen mit AND durch IF und die Konstruktionen
mit OR durch eine andere Logik im Batchjob ersetzen
sollte, damit Batchjobs auch unter MS-DOS und 4DOS/NDOS
laufen (Genausowenig sollte man 4DOS .AND. und .OR.
anwenden, die ansonsten mit AND, OR identisch ist).
Neben den im DOSBOOK beschriebenen Vergleichsoperationen
"=", "==" (f�r 'gleich'), "<>" und "!=" (f�r 'ungleich')
kann man allerdings auch noch die nur in der COMMAND.COM
internen Hilfe (IF /?) aufgelisteten Vergleichsoperationen
">" ('gr��er'), "<" ('kleiner'), ">=" ('gr��er-gleich')
und "<=" ('kleiner-gleich') verwenden! Um m�glichst hohe
Kompatibilit�t zu anderen Kommandoprozessoren herzustellen,
sollte man jedoch stattdessen in der Praxis die Ungleich-
heit durch ein vorangestelltes NOT ausdr�cken und entweder
auf alle Vergleichsoperationen, die '>' oder '<' enthalten,
verzichten oder wenigstens vorher sicherstellen, da�
diese nur unter Novell DOS 7 COMMAND.COM ausgef�hrt
werden. Andere Kommandozeileninterpreter werten diese
Zeichen als Umleitung und dies kann zu schweren Fehlern
bis hin zum Datenverlust durch �berschriebene Dateien
f�hren. Eine partielle Abhilfe (bei ver�nderter Funktion)
ist aber evtl. durch geschickte Verwendung von doppelten
Anf�hrungszeichen m�glich (nicht ausprobiert).
Die gleichwertigen Vergleichsoperationen EQ, NE, LT, GT,
LE und GE, die CCI Multiuser DOS und 4DOS/NDOS bieten,
unterst�tzt Novell DOS 7 nicht. Ebenfalls fehlen die von
CCI Multiuser DOS bekannten Erweiterungen wie
IF KEY ["message"] == char
oder gar die Kurzschreibweise f�r IF ERRORLEVEL mittels
ON in der Form "ON [ERRORLEVEL] code [GOTO] label".
Multiuser DOS bietet hier noch einige weitere Erg�nzungen,
die hier nicht n�her aufgelistet werden.
Die Syntax zum Vergleich zweier Zahlenwerten beginnt
auf beiden Seiten des Vergleichs mit einem Doppelkreuz
'#'. Interessant daran ist, da� die hier behandelten
Werte offenbar immer erst auf ganze Zahlen gerundet
werden, d.h. #7,1 oder #7.1 wird wie #7 behandelt.
Nachkommastellen fallen einfach unter den Tisch.
Die obigen Vergleichsoperationen (auch die Relationen)
k�nnen nicht nur auf derartige Werte, sondern auch auf
Zeichenketten angewendet werden! In diesem Fall werden
die beiden Zeichenketten entsprechend der landes-
spezifischen Sortierreihenfolge miteinander verglichen.
Ein paar Beispiele: Ausgabe:
IF #7 >= #7.1 ECHO Achtung!!! Achtung!!!
IF #7,1 = #7.1 ECHO Richtig!!! Richtig!!!
IF "A" >= "B" ECHO Falsch!!! --
IF "BA" >= "BB" ECHO Falsch!!! --
IF "A" >= "AB" ECHO Falsch!!! --
Achtung: Normalerweise ist die Auswertung der Argumente
case-sensitiv, d.h. Gro�- und Kleinschreibung werden
unterschieden. Dies ist wichtig zu wissen, da der IF-
Befehl gerade oft zur Auswertung von Umgebungsvariablen
herangezogen wird (hierzu siehe SET= in Kapitel III.1.).
Bei CCI Multiuser DOS gibt es ein internes Kommando
namens CASE [<ON>|OFF], mit dem man w�hlen kann, ob die
Auswertung keine Fallunterscheidung machen soll.
Zu IF ERRORLEVEL ist anzumerken, da� durch die Abfrage des
Errorlevels der Errorlevel *nicht* auf Null zur�ckgesetzt
wird, wie dies h�ufig vermutet wird. Diese Annahme liegt
deshalb nahe, weil die betriebssysteminterne Variable des
Exitcodes INT21h/4Dh (und damit auch dessen Realisierung
in Programmiersprachen) sehr wohl mit der Abfrage zur�ck-
gesetzt wird. COMMAND.COM (als auch 4DOS) speichern diesen
Wert jedoch vorher in eine eigene Variable um, daher ist
IF ERRORLEVEL nicht betroffen.
Bei Novells (und DR DOS 6.0) COMMAND.COM kann - wie nur
teilweise dokumentiert - eine beliebige Anzahl von Gleich-
heitszeichen auch bei
IF ERRORLEVEL [=|==] errlvl
IF EXIST [=|==] filespec
IF DIREXIST [=|==] dirspec
verwendet werden. Zumindest unter einigen MS-DOS/PC-DOS
und DR DOS COMMAND.COM Versionen ist dies ebenfalls m�glich
(DIREXIST nur bei Novell DOS und DR DOS 6.0). "IF EXIST"
arbeitet bei Novell DOS (wie auch MS-DOS/PC-DOS) auch mit
versteckten Dateien, hingegen wurden bei DR DOS (ausge-
nommen die DR DOS 6.0 Updates ab 1992) versteckte Dateien
ignoriert. Trotzdem wird auch bei "IF ERRORLEVEL ==" auf
">=" ('gr��er-gleich') getestet! Dieser Unterschied in der
Semantik ist meistens nicht tragisch, sollte aber trotzdem
bei der Programmierung von Batchjobs ber�cksichtigt werden
(denn 4DOS/NDOS unterscheidet hier sehr wohl...).
IF ERRORLEVEL 0 ist eine immer erf�llte Bedingung.
Novells COMMAND.COM akzeptiert auch negative Zahlen-
angaben, dabei entspricht
-1=255, -2=254, -3=253 ... -255=1.
Und Errorlevel-Angaben oberhalb 255 werden modulo 256 auf
den Bereich von 0..255 zur�ckgefaltet, so da� die Angabe
999 als 231 interpretiert wird.
Und wie bekommt man die Errorlevel heraus?
Siehe BATTIPS.TXT und ERRORLVL.BAT
Das Programm unter Kontrolle von DEBUG aufrufen:
DEBUG program parameter
und dann am Prompt das Kommando -G absetzen, damit
DEBUG das Programm wie normal abarbeitet. Bei der
Beendigung wird der Errorlevel angezeigt. Bez�glich
DEBUG siehe auch Kapitel II.5.
�brigens: Novells COMMAND.COM erlaubt, wie 4DOS/NDOS, die
Verwendung des IF Befehls auch direkt am Prompt. Normaler-
weise ist dieser Befehl nur in Batchjobs verf�gbar und wird
z.B. am Prompt von MS-DOS als ung�ltig zur�ckgewiesen.
MD/MKDIR Nicht offensichtlich sind zwei Eigenschaften dieses
Befehls:
- Der Befehl kann nur ein Verzeichnis auf einmal er-
zeugen, d.h. wenn man einen l�ngeren Pfad zu einem zu
erstellenden Verzeichnis angibt, mu� der gesamte Ast
bis dahin bereits existieren. (Dies lie�e sich bei
OpenDOS noch verbessern.)
- Da der Befehl - im Gegensatz zu 4DOS/NDOS - bei
COMMAND.COM nur einen Parameter erwartet, er�ffnet
sich die M�glichkeit, auch mehrere angegebene Parameter
als einen Parameter zu interpretieren und auf diese
Weise sogar Verzeichnisse erzeugen zu k�nnen, die
Leerfelder enthalten. Unter MS-DOS k�nnen solche
Verzeichnisse auf legale Weise nicht erstellt werden,
deshalb sollten Sie auch hier auf diese M�glichkeit
verzichten. Beispiel:
MD c:\a b c
erzeugt ein Verzeichnis namens "c:\a b c", d.h. mit
zwei Leerfeldern! Derartige Verzeichnisse lassen sich
zwar mit RD/RMDIR wieder l�schen und sind im Prinzip
ganz normal ansprechbar, das Problem ist nur, das die
anderen Kommandos Leerfelder als Trenner zwischen
Parametern auffassen und Sie gro�e Schwierigkeiten
bekommen werden, von au�en auf dieses Verzeichnis oder
seinen Inhalt zuzugreifen (was man nat�rlich in Einzel-
f�llen als Feature auffassen k�nnte). Mit dem Norton
Commander (NC) k�nnen Sie dieses Problem jedoch �ber-
br�cken und danach innerhalb des Verzeichnisses mit
relativen Pfadangaben ganz normal operieren.
PATH Die Verwendung des Befehls PATH d�rfte bekannt sein (siehe
DOSBOOK). Ben�tigen Sie l�ngere %Path%-Angaben, als �ber
die Kommandozeile m�glich sind, k�nnen Sie die Umgebungs-
variable %Path% auch (direkt) an PATH vorbei mit einer
Suchliste belegen. Dazu m�ssen Sie lediglich ein kleines
Programm schreiben, das den Eintrag des *Master*-Environ-
ment ver�ndert. Aber Vorsicht: Es gibt (gl�cklicherweise
nur wenige) Programme, die mit PATH-Angaben �ber 128
Zeichen nicht zurechtkommen (etwa Windows 3.0 oder
Checkit). Ab einer gewissen L�nge sollten Sie aus
Performance-Gr�nden die Suche �ber %Path% um Substitut-
Laufwerke und Programmaufrufe �ber Batchjobs in einem
Batch-Verzeichnis (C:\BAT etc.) erweitern (welches
nat�rlich in %Path% vorkommt, am besten sogar noch vor
dem DOS-Verzeichnis).
Mit Pa�w�rtern gesch�tzte Verzeichnisse k�nnen nicht in der
Pfadauflistung vorkommen, da die Angabe eines Pa�wortes
mit Semikolon bei PATH anders interpretiert w�rde.
PROMPT Der Befehl PROMPT, der auch �ber die Variable %Prompt%
eingestellt werden kann, ist bei Novell DOS teilweise
undokumentiert erweitert. Hier folgt die fehlende Be-
schreibung:
$x Wenig bekannt ist, da� durch die Angabe von $x im
Prompt vor jeder R�ckkehr von *externen* Kommandos
und Programmen zum Prompt ein Kommando abgearbeitet
wird, da� in der Variable %PExec% definiert ist (in
der Online-Hilfe wird f�lschlicherweise %Exec% ange-
geben und es wird behauptet, da� der Befehl jedesmal
vor der Anzeige des Prompts ausgef�hrt wird, z.B.
DISKMAP wie in Kapitel II.4. beschrieben).
F�r dieses Kommando kann nat�rlich auch ein Batchjob
verwendet werden. (Leider bietet selbst 4DOS 5.52a
diese M�glichkeit noch nicht; ein partielles Work-
around ist mit der %@Exec[]% Funktion von 4DOS m�glich.
$x und $X haben dort eine andere Funktion.)
$- Teilweise undokumentiert sind die beiden Token $- und
$_: Gibt man nur PROMPT (ohne Parameter) an, so er-
scheint der Default-Prompt wie mit $n$g, d.h. es ist
nicht m�glich, den Prompt ganz verschwinden zu lassen.
Gibt man nun als ersten und einzigen Parameter PROMPT
$- an, so wird der Prompt ganz abgeschaltet (siehe
auch bei ECHO in diesem Kapitel).
Ist $- einer von mehreren Parametern, so wird er
ignoriert, d.h. durch eine leere Zeichenkette ersetzt.
(Mit 4DOS 5.52a wurde diese M�glichkeit offenbar ein-
gebaut, wenn sie auch noch nicht dokumentiert ist.)
$_ Die Angabe von $_ bewirkt hingegen, da� in eine neue
Zeile gesprungen wird (CR/LF). Dies ist besonders hilf-
reich, wenn es als erster Token f�r PROMPT angegeben
wird, hat allerdings auch den Nachteil, da� die oberste
Zeile von Bildschirmausgaben, die genau auf eine Seite
formatiert sind, weggescrollt wird.
$u Ausschlie�lich in der Hilfe von SETUP ist der Parameter
$u dokumentiert, der den Benutzeranmeldenamen ausgibt.
Wie dies dann allerdings vonstatten gehen soll, findet
der geneigte Leser nirgendwo - au�er hier:
Der Inhalt der reservierten und undokumentierten Umge-
bungsvariable %LoginName% wird online an Stelle des
$u eingebaut, d.h. wenn sich dieser Wert w�hrend einer
Session �ndert, pa�t sich auch der PROMPT bei der
n�chsten Zeile sofort daran an. Da man diese M�glich-
keit nicht hat, wenn man Umgebungsvariablen bei der
Definition des PROMPT-Befehls benutzt (der PROMPT
bleibt dann fix auf die zu diesem Zeitpunkt g�ltigen
Werte eingestellt), bietet sich hier - auch f�r ganz
andere Zwecke - eine interessante Option. (4DOS erlaubt
ganz regul�r, Umgebungsvariablen im Prompt zu ver-
wenden, aber unter Novells COMMAND geht es �ber die
Definition von %LoginName% nun auch.)
%LoginName% darf keinesfalls mit der verwandten Pseudo-
Umgebungsvariable %Login_Name% verwechselt werden!
Wenn man sich ins Netz einloggt, wird %Login_Name%
im Rahmen der M�glichkeiten darauf eingestellt,
%LoginName% bleibt jedoch davon v�llig unbeeinflu�t.
(4DOS 5.52a bietet diese spezielle M�glichkeit noch
nicht.) Siehe auch Kapitel IV.7.
$g Wie in Kapitel II.1. ausf�hrlich erl�utert, �ndert
PROMPT den ersten '\' in der Verzeichnisausgabe in
ein '/', wenn der SwitChar nicht auf '/' eingestellt
ist. Siehe auch bei CD/CHDIR.
$h (Unter 4DOS (getestet mit 5.52a) gibt es eine Ein-
schr�nkung, die bei Novells COMMAND.COM nicht zum
Tragen kommt, da Variablen w�hrend des PROMPTs sowieso
nicht erg�nzt werden. Bei 4DOS kann $h nur bis zur
n�chstr�ckw�rtigen Grenze einer expandierten Variable
oder Funktion r�ckw�rts gehen.)
$m (Multiuser DOS verwendet dies in Verbindung mit der
Variable %MAIL% f�r die Anzeige von Post.)
REM Der REM-Befehl funktioniert, wie auch der Doppelpunkt,
: direkt am Prompt und wird einfach ignoriert. (Das Semi-
kolon hat in diesem Zusammenhang eine *andere* Funktion
und ist hier kein Alias f�r REM. Siehe oben.)
Enth�lt eine Pseudo-Kommentarzeile mit Doppelpunkt eine
Umleitung, so wird diese ignoriert, d.h. es gibt nicht
die �blicherweise damit auftretenden Probleme (auch nicht
unter MS-DOS), f�r solche Zwecke hat sich ein verdoppeltes
:: eingeb�rgert, ist aber nicht vorgeschrieben.
Achtung: Da der Kommandoprozessor �berlange Zeilen mit
mehr als 123 Zeichen abschneidet und den Rest als neue
Zeile betrachtet, m�ssen Sie bei �berlangen Kommentaren
entweder ein weiteres REM oder einen Doppelpunkt einf�gen
oder von vornherein den Kommentartext auf mehrere Zeilen
aufteilen. Dieses Verhalten ist ein dokumentiertes Ver-
halten von CCI Multiuser DOS 7, also kein Fehler. Angeblich
mu� ein Doppelpunkt, der eine Marke einleitet, immer in
der ersten Spalte stehen (laut CCI Multiuser DOS Dokumenta-
tion), die Praxis zeigt aber, da� dies nicht zwingend
notwendig ist.
�brigens gibt es einen weiteren Unterschied zwischen REM
und dem Doppelpunkt. Da der Doppelpunkt eigentlich f�r
Marken gedacht ist, werden solche Zeilen auch mit "ECHO on"
oder im Einzelschrittbetrieb nicht ausgegeben, REM-Zeilen
jedoch sehr wohl.
(MS-DOS 2.xx und 3.xx erlaubten (angeblich) die Verwendung
eines Punktes als Alias f�r REM, dies funktioniert unter
Novells COMMAND.COM und unter 4DOS/NDOS jedenfalls nicht.)
Es gibt noch eine Besonderheit zu beachten: Aus Kompatibi-
lit�t zu MS-DOS wertet auch Novells COMMAND.COM Umleitungen
(mit '>', '>>', '<' oder '|') auch in REM-Zeilen aus, etwa:
REM | DIR *.*
wird also nicht etwa ignoriert, sondern f�hrt DIR *.*
aus (siehe auch Kapitel IV.6.), was mit 4DOS/NDOS nicht
funktioniert.
RD/RMDIR Nicht offensichtlich sind zwei Eigenschaften dieses
Befehls:
- Der Befehl kann nur ein Verzeichnis auf einmal l�schen,
d.h. wenn man einen l�ngeren Pfad zu einem leeren
Verzeichnis angibt, so wird nur der letzte Ast des
Baums gekappt und nicht der gesammte angegebene Pfad,
selbst wenn dieser leer sein sollte und keine weiteren
Verzeichnisse einh�lt. Dieses Verhalten ist auch
w�nschenswert, da die gew�nschte Aktion sonst nicht
eindeutig anhand des Parameters festgelegt werden
k�nnte.
- Da der Befehl - im Gegensatz zu 4DOS/NDOS - bei
COMMAND.COM nur einen Parameter erwartet, er�ffnet
sich die M�glichkeit, mehrere angegebene Parameter
als einen Parameter zu interpretieren und auf diese
Weise auch Verzeichnisse l�schen zu k�nnen, die
Leerfelder enthalten. Unter MS-DOS k�nnen solche
Verzeichnisse auf legale Weise gar nicht erst erstellt
werden, unter DR DOS und Novell DOS ist dies jedoch
mit dem Befehl MD/MKDIR durchaus erlaubt, wenn auch
undokumentiert:
RD c:\a b c
w�rde z.B. das Verzeichnis namens "c:\a b c" l�schen,
das oben (bei MD/MKDIR) erstellt wurde.
REN/RENAME Der Rename-Befehl kann auch �ber die Verzeichnisgrenzen
hinweg ausgef�hrt werden, solange es sich bei Quelle und
Ziel physikalisch um dasselbe Laufwerk handelt (d.h. auch
Substitut-Laufwerke etc. werden korrekt ber�cksichtigt).
In diesem Fall mu� nur eine �nderung der Verzeichnis-
struktur bewerkstelligt werden, die Datei selbst bleibt
aber an der gleichen physikalischen Stelle auf der Fest-
platte. Dadurch ist dieses Kommando sehr schnell.
Ein gesetzter Pa�wortschutz wird wie die Attribute auf die
neue Datei �bertragen (auch bei 4DOS).
Im Vergleich dazu wirkt der externe MOVE Befehl anders,
siehe Kapitel II.4.
REN/RENAME bietet noch eine undokumentierte Option /C
'Confirm', die von CCI Multiuser DOS her bekannt ist.
Gibt man sie an (im Zweifelsfall nach den beiden Datei-
spezifikationen), so fragt der Befehl vor dem Ausf�hren
jeweils nach, ob dies auch wirklich gew�nscht ist.
SWITCH Leider ist COMMAND.COMs SWITCH nicht genauso erweitert,
wie die Realisierung in CONFIG.SYS. Es gibt keine Zeit-
schranke, dementsprechend auch keinen Default-Wert, und
es werden wirklich nur maximal 9 Sprungziele akzeptiert.
Achtung: Mit 4DOS 5.95/6.00 wurde ein neues Kommando
namens SWITCH eingef�hrt, das leider nicht das geringste
mit dem seit DR DOS bekannten SWITCH Befehl zu tun hat!
TIME In Verbindung mit Umleitungen siehe auch Kapitel IV.6. und
Kapitel IV.1.
Die zus�tzlichen Optionen von CCI Multiuser DOS 7.22 Gold
/B (f�r Betrieb in Batchjobs), /E (zum Setzen der Umge-
bungsvariablen %TIME% und %ELAPSED%) und /G (f�r sek�nd-
liche Piepser in Verbindung mit /C) bieten Novell DOS 7
und Caldera OpenDOS 7.01 COMMAND.COM noch nicht, dies
lie�e sich aber leicht implementieren.
TRUENAME Undokumentiert (das Kommando fehlte in den urspr�nglichen
Ausgaben von DR DOS 6.0 und Novell DOS 7; wurde aber sowohl
bei DR DOS, als auch sp�testens mit Novell DOS Update 8
nachtr�glich eingebaut). Entspricht direkt dem Ergebnis der
zugeh�rigen API-Funktion, die auch schon in fr�hen Ausgaben
von Novell DOS 7 implementiert war, die den TRUENAME-Befehl
selbst noch nicht kannten.
Gibt den komplett expandierten, physikalischen Pfad zu
einer Datei an, um damit Doppeldeutigkeiten aufzul�sen
(etwa bei SUBST, JOIN, ASSIGN, MAP). Dateimasken werden auf
"?"-Masken expandiert.
Siehe auch MSDOSTIP.TXT. Das TRUENAME-Verhalten hat sich
im Laufe der Zeit (im Zuge von Updates) leicht ver�ndert,
siehe HISTORY.TXT.
Netzlaufwerke werden normalerweise in UNC-Notation (siehe
Kapitel VI.10.) ausgegeben und CD-ROM-Laufwerke entweder
als "\\X.\A.\filename" (wobei der zugeordnete Laufwerks-
buchstabe hier durch X und die Nummer des CD-ROM-Laufwerks
mit A dargestellt wird, bei MSCDEX und neueren Versionen
von NWCDEX) oder "Cdex. X:\filename" bei �lteren Ausgabe
von NWCDEX. L�dt man MSCDEX mit der Option /S, so �ndert
sich zwar in der CDS (Current Directory Structure) nichts
an diesem Eintrag, bei TRUENAME wird aber jetzt eine
normale Pfadangabe zur�ckgeliefert "X:\filename".
TYPE Bei vielen Kommandoprozessoren erlaubt der TYPE-Befehl
nicht die Angabe von Wildcards, stattdessen mu� man auf
COPY ausweichen, z.B.:
COPY *.bat CON
COPY *.txt CON | MORE
Entgegen der Dokumentation und manchen Fremdpublikationen
akzeptiert COMMAND.COM von DR DOS 6.0 und Novell DOS 7
auch bei TYPE Wildcards:
TYPE *.bat
TYPE *.txt /P
Gibt man Wildcards an, so wird vor der Ausgabe jeder
Datei der entsprechende Dateiname ausgegeben. In diesem
Zusammenhang gibt es eine interessante Besonderheit:
Unter Singleuser-Varianten ist standardm��ig zun�chst
nichts besonderes zu erkennen, unter Multiuser-Varianten
werden die angegebenen Dateinamen jedoch invertiert an-
gezeigt. Und zwar existieren unter Multiuser DOS zwei
Variablen namens %$On% (RevOn) und %$Off% (RevOff), die
�blicherweise mit den Werten "Esc p" und "Esc q" belegt
sind. (Diese beiden Sequenzen werden von dem stark
erweiterten ANSI-Treiber ausgewertet, der unter
Multiuser DOS ein fester Bestandteil des Systems ist.
Der bei Novell DOS mitgelieferte ANSI.SYS-Treiber versteht
diese Sequenzen nicht!) Der Wert von %$On% wird unmittelbar
vor jedem Dateinamen auf der Konsole ausgegeben, der Wert
von %$Off% unmittelbar danach. Auf diese Weise ist eine
Steuerung der Farbe und der Attribute m�glich.
Hat man jedoch in der Singleuser-Variante ebenfalls einen
ANSI-Treiber geladen, so kann man diese beiden Variablen
manuell mit passenden Steuersequenzen belegen (%$On% und
%$Off% existieren seit DR DOS 3.41 COMMAND.COM). Da die
Eingabe von beliebigen Zeichencodes nicht in jedem Editor
m�glich ist und es zu Problemen bei der Bearbeitung von
Batchjobs kommen k�nnte, die Codes au�erhalb des
Repertoires f�r normale W�rter enthalten, gibt es eine
optionale Syntax, die die Angabe eines dreistelligen
Oktalwertes f�r den Zeichencode erlaubt:
SET $On=\033[1m
SET $Off=\033[0m
TYPE *.*
Dieses Beispiel sorgt daf�r, da� die Dateinamen hervor-
gehoben dargestellt werden. Nat�rlich k�nnen Sie diese
Variable auch verwenden, um einen Banner auszugeben oder
einen Seitenvorschub auszul�sen... Dies funktioniert
auch dann noch, wenn Sie die Ausgabe des TYPE-Befehls
in eine Datei oder auf ein Ger�t umleiten! Siehe auch
bei CLS und in Kapitel IV.7.
VER Der Befehl VER von Novell DOS 7 (und DR DOS) gibt die
Novell DOS/DR DOS Versionsnummer aus. Dabei h�ngt das
Ergebnis vom Inhalt der Umgebungsvariable %Ver% ab.
Dieser Wert wird bei Start von COMMAND.COM auf "7" (bei
Novell DOS) gesetzt (7.01 bei Caldera OpenDOS 7.01 trotz
%Ver%=7; das .01 wird festverdrahtet angeh�ngt). �ndert
man diesen Wert, so wird eine entsprechend andere Angabe
angezeigt. Ist %Ver% nicht definiert (wie z.B., wenn man
COMMAND.COM durch 4DOS.COM ersetzt - also nicht nur
�berl�dt), so gibt VER (von COMMAND.COM) gar nur
"Novell DOS" aus. Weitere Hinweise zur Belegung der
Variable %Ver% unter den einzelnen Versionen finden sich
in Kapitel IV.7.
Die Pseudo-Umgebungsvariable %OS_Version% �bernimmt
�brigens ebenfalls den Wert von %Ver% (falls definiert),
wenn auch nicht umgekehrt, siehe Kapitel IV.7.
VERIFY Ohne Angabe von Parametern gibt VERIFY, wie auch BREAK
und ECHO den aktuellen Status in einer bestimmten Syntax
aus, die man sehr vorteilhaft in Batchjobs zum Zwischen-
speichern des Status verwenden kann.
N�heres hierzu bei BREAK.
---------------------------------------------------------------------------
II.12. Hinweise zu Editieren am COMMAND.COM Prompt: [97-02-21]
==============================================================
Stichworte: COMMAND.COM, HISTORY=, PROMPT, �berlange Eingabezeile
Besonders mit l�ngeren Anzeigen des Prompts (�ber PROMPT), etwa bei
tief verschachtelten Unterverzeichnissen kommt es �fters vor, da� man
die Zeilenl�nge von z.B. 80 Zeichen �berschreitet und die Eingabe in der
n�chsten Zeile fortsetzen mu�. Dies ist im Prinzip kein Problem, aller-
dings kann man den Cursor unter COMMAND.COM selbst in Verbindung mit
HISTORY= nur soweit wieder zur�ck bewegen, bis man den Anfang der
aktuellen Zeile erreicht. Damit ist es nicht m�glich, Tippfehler in
dem Teil der Eingabe zu korrigieren, die noch in der vorherigen Zeile
stehen. Abhilfe schafft die Bet�tigung von <Up> gefolgt von <Down>:
Danach steht die komplette aktuelle Eingabezeile (sofern nicht l�nger
als 80 Zeichen) in der aktuellen Zeile und kann wieder komplett editiert
werden.
Falls Sie die CONFIG.SYS Direktive HISTORY=ON gesetzt haben, wirkt
sowohl am COMMAND.COM Prompt, als auch im Eingabe-Interface von
kommandozeilenorientierten Applikationen (z.B. DEBUG) eine HISTORY-
Funktion.
Diese normalerweise recht praktische Funktion kann allerdings manchmal
auch st�rend sein, wenn man die automatische Suchfunktion aktiviert hat
(ebenfalls �ber HISTORY=... oder mittels <Ctrl>+<_> bei Novell DOS bzw.
<F8> bei DR DOS): Da diese Funktion, falls aktiviert, auch innerhalb
von Eingabeleitungen funktioniert, f�hrt dies oft zur Verf�lschung
des Eingabestroms aus der Umleitung. Begrenzt kann man dem entgegen-
wirken, indem man an das Ende jeder Zeile eine gro�e Anzahl Leerfelder
(oder anderer syntaktisch korrekter Zeilen ohne Funktion) setzt (sofern
der Editor das erlaubt), aber es ist besser, die Suchfunktion vor
Eingabeumleitungen abzuschalten (bei DEBUG innerhalb des -E Kommandos
ein zus�tzliches Komma am Schlu�, z.B. "-Exxxx:yyyy,zz,").
Weitere Hinweise zur Editierung auch bei HISTORY= (Kapitel III.1.)
und DOSKEY (Kapitel II.4.).
Unter 4DOS/NDOS ergibt sich dieses Problem erst gar nicht, da man
problemlos die gesamte Zeile editieren kann.
Weitere Hinweise zur Kommandozeilen-Syntax siehe Kapitel II.11.
---------------------------------------------------------------------------
II.13. Patchen der US-Version auf deutsche Ja/Nein-Abfragen: [96-05-30]
=======================================================================
Stichworte: IBMBIO.COM, IBMDOS.COM, YESCHAR=, J/N, Y/N, O/N, S/N, DEBUG
H�ufig stellt sich das Problem, da� nach einem US-Update die deutsche
Grundversion nach Y/N statt nach J/N fragt. Innerhalb von CONFIG.SYS
kann man dem mit der undokumentierten Direktive YESCHAR= abhelfen, deren
Einstellung aber leider nicht in das System �bernommen wird (k�nnte sich
in Zukunft evtl. �ndern).
Stattdessen gibt es die M�glichkeit, die Kerneldateien direkt umzu-
patchen, dazu ist eigentlich nur eine �nderung n�tig, aber in dem
folgenden Beispiel werden direkt N�gel mit K�pfen gemacht und zwei (von
drei) Vorkommnisse von 'Yy' zu 'Jj' umgepatcht. Dieser Patch sollte mit
jedem US-Update f�r Novell DOS 7 funktionieren.
Leider werten die Novell DOS eigenen Kommandos (etwa DEL *.*, DEL /C,
ERASE /C, ERA/C, DELQ, ERAQ, COPY /C, <Del> im TASKMGR und viele andere
) die zugeh�rige DOS-Funktion �berhaupt nicht aus, so da� hier weiterhin
Y/N erscheint...
K�nnte sich ebenfalls in Zukunft �ndern (bez�glich externer Kommandos
sei auch Kapitel II.16. verwiesen).
Falls nicht, m��ten COMMAND.COM und die betreffenden externen Programme
auch gepatcht werden (wozu sie meistens mit "PKLITE filespec -x" ent-
packt werden m�ssen, dann mit DEBUG an den passenden Stellen ge�ndert
und danach mit "PKLITE filespec" wieder gepackt werden m��ten).
Im folgenden wird der Patchvorgang nur f�r IBMBIO.COM und IBMDOS.COM
geschildert:
Achtung: Diesen Patch nicht auf die Originale, sondern auf Kopien
anwenden. Vorher m�ssen die Dateiattribute HRS gel�scht werden.
>DEBUG Eingaben (au�er '-' Prompt-Eingaben)
-Nibmbio.com <RET>
-L <RET>
-Scs:100 cx+100 59 79 <RET>
????:<xxxx>
-E<xxxx> <RET> (xxxx �bernehmen)
????:<xxxx> 59. 4A <SPACE>
????:<xxxx>+1 79. 6A <RET>
-W
-Nibmbio.com <RET>
-L
-Scs:100 cx+100 59 79 <RET>
????:<yyyy>
????:<zzzz>
; Achtung! Das erste Vorkommnis in dieser Datei nicht verwenden. F�hrt
; aus ungekl�rten Ursachen zu Problemen beim Booten.
-E<zzzz> <RET>
????:<zzzz> 59. 4A <SPACE> (zzzz �bernehmen)
????:<zzzz>+1 79. 6A <RET>
-W
-Q
Nun k�nnen - nach einer �berpr�fung und mit einer Boot-Diskette in
Reichweite - die Originaldateien �berschrieben werden und die Attribute
HRS wieder gesetzt werden. YESCHAR= ist nun auch nicht mehr notwendig.
---------------------------------------------------------------------------
II.14. Hinweise zu VERIFY: [96-04-01]
=====================================
Stichworte: VERIFY, NWCACHE
Es gibt verschiedentlich Hinweise, da� die Einstellung VERIFY ON|OFF
bei MS-DOS f�r den DOS-Kernel selbst keinen Einflu� hat, sondern optional
nur durch externe Ger�tetreiber verwendet wird. Da die Daten zumindest
auf Festplatten sowieso durch Pr�fsummen gesichert werden, wird h�ufig
empfohlen, VERIFY OFF zu setzen (Ich arbeite pers�nlich allerdings lieber
mit VERIFY ON).
Bei MS-DOS sind (ohne Platten-Cache) mit VERIFY ON|OFF gewisse Unter-
schiede in der Performance festzustellen, die bei Novell DOS nicht so
stark ausfallen, aber dort generell eher langsam sind (also wie mit
VERIFY ON). �ber den im Vergleich zu MS-DOS relativ z�gerlichen Fest-
platten- und Floppy-Zugriff unter DR DOS und Novell DOS hat es schon
viel Murren und eine Reihe Spekulationen gegeben. H�ufig wird ins Feld
gef�hrt, da� DR DOS/Novell DOS offensichtlich auch bei VERIFY OFF
gewisse �berpr�fungen vornimmt, die zus�tzliche Zeit beanspruchen.
Ich kann in dieser Diskussion bez�glich VERIFY weder in der einen noch
in der anderen Richtung etwas beisteuern (�ber die Interna m��te sich
mal ein Novellaner �u�ern...), sicher ist jedoch, da� NWCACHE offenbar
mit VERIFY ON nicht in der Lage ist, Schreibzugriffe zu cachen, auch
wenn diese Option enabled ist (jedenfalls gibt die Statistik�bersicht
immer 0% gesparte Zugriffe aus - siehe Kapitel II.3. und II.4.). Daher
empfiehlt Novell VERIFY OFF bei Verwendung von NWCACHE oder NetWare-
Anbindung.
Ich empfehle das konservative VERIFY ON (Sicherheit �ber Geschwindigkeit)
zu setzen, solange nicht spezielle Gr�nde dagegen sprechen, wie etwa der
Zugriff auf manche Netze oder extrem langsame Ger�te wie Tape-Streamer.
NWCACHE ist durchaus in der Lage, auch mit VERIFY ON zu cachen, aller-
dings bei stark reduzierter Performance. VERIFY OFF kann dazu f�hren, da�
Diskettenwechsel nicht richtig erkannt werden, solange man das Laufwerk
nicht explizit neu betritt (was sich in seltenen F�llen z.B. im NC
unsch�n bemerkbar machen kann, in j�ngsten Updates ist dieses Verhalten
aber offenbar verbessert worden).
Hinweise zu anderen performance-fressenden Einstellungen wie Doppel-
pufferung und Disk-Deblocking siehe Kapitel II.17.
---------------------------------------------------------------------------
II.15. Unter Novell DOS 7 lauff�hige MS-DOS 6.22 Kommandos:
===========================================================
Stichworte: MS-DOS 6.22, Kompatibilit�t, Versionsabh�ngigkeiten
Die folgenden externen Kommandos von MS-DOS 6.22 laufen auch
unter Novell DOS 7. Leider sind das nur relativ wenige, was an der
�bertrieben pingeligen Versionsabfrage in MS-DOS Kommandos liegt.
Die meisten Kommandos sind unter Novell DOS 7 sowieso unn�tz, da
die eigenen namensgleichen oder -verwandten Kommandos meist mehr
M�glichkeiten bieten und - wie meine Erfahrung immer wieder zeigt -
umsichtiger programmiert wurden.
ADOS (AddOn), CHOICE, COMP, EDIT (QBASIC), DEFRAG (Zukauf),
DELTREE, DOSSHELL, EXPAND (allg.), FAKEMOUS (AddOn), FASTHELP (unn�tz),
GRAFTABL, LABEL, LOADFIX (besser MEMMAX -L), MIRROR (Zukauf: Central
Point PC-Tools), MOVE, MSAV (Zukauf), MSCDEX (allg.), MSD (allg.),
MSHERC (allg.), POWER (allg.), PRINTFIX, QBASIC (EDIT), SCANDISK
(Zukauf), SETNAME (Netz), SETVER (wohl sinnvoll), SMARTDRV (allg.),
UNDELETE (Zukauf: Central Point PC-Tools), UNFORMAT (Zukauf), VSAFE
(Zukauf), evtl. noch ein paar mehr.
---------------------------------------------------------------------------
II.16. Landessprachliche Unterst�tzung: [97-03-25]
==================================================
Stichworte: COUNTRY=, DISPLAY.SYS, MODE, KEYB, Codeseiten, Landescodes,
Keyboardcodes, Keyboard-IDs, .CPI-Dateien, FONT, DRFONT
i. Einrichtung von Codeseiten:
------------------------------
Im folgenden Beispiel wird neben der immer verf�gbaren Hardware-
Codeseite (entspricht i. allg. zumindest bez�glich der Zeichenzuordnung
f�r jedes Ger�t der Codeseite 437) eine Software-Codeseite (hier 850)
eingerichtet.
Auch wenn in der Dokumentation immer nur von zwei Codeseiten pro Land
die Rede ist (dies bezieht sich auf die Angaben in COUNTRY.SYS),
k�nnen jeweils bis zu 12 Codeseiten (bei MS-DOS nur 6) vorbereitet
werden. Bez�glich der Details bei der Einrichtung von DISPLAY.SYS und
PRINTER.SYS sei auf Kapitel II.4. verwiesen. Noch einmal: Die Angaben
der Codeseiten bei den CONFIG.SYS-Treiber DISPLAY.SYS und PRINTER.SYS
beziehen sich auf die jeweilige Hardware-Codeseiten (wie �blicherweise
auch bei COUNTRY=, siehe Kapitel III.1.).
Erst die Codeseiten-Angaben bei MODE PREPARE (in AUTOEXEC.BAT) gelten
f�r die vorzubereitenden Codeseiten, d.h. die Codeseiten, mit denen man
�ber die Hardware-Codeseiten hinaus arbeiten m�chte.
Das Vorbereiten *einer* Codeseite erlaubt bereits das Arbeiten mit
*zwei* Codeseiten:
Mit der Hardware-Codeseite und mit der vorbereiteten Codeseite,
zwischen denen man mit CHCP oder MODE SELECT wechseln kann (deshalb
ist auch die korrekte Angabe der Hardware-Codeseite so wichtig).
Analoges gilt f�r mehr als eine vorbereitete Codeseite.
Nat�rlich ist es m�glich, auch die Codeseite, die bereits von der
Hardware-Codeseite benutzt wird, mit einer erst vorzubereitenden
Codeseite zu �berladen. In diesem Fall stammen die Informationen zum
Umschalten auf diese Codeseite (Fonts, Escape-Sequenzen) nicht mehr
aus dem Grafikkarten-BIOS (Hardware) oder - bei Druckern - aus dem
Treiber PRINTER.SYS, sondern aus der mit MODE zugeordneten .CPI-Datei.
Dies ist besonders dann wichtig zu wissen, wenn Sie eine spezielle
.CPI-Datei besitzen, die z.B. einen artfremden Drucker ansteuern oder
in allen Codeseiten eine andere Bildschirm-Schriftart erzeugen soll.
In diesem Fall d�rfen Sie nicht vergessen, auch die Codeseite 437
mittels MODE CODEPAGE PREPARE vorzubereiten und bei DISPLAY.SYS und
PRINTER.SYS eine Codeseite mehr zu reservieren. N�heres zu diesem
Themenkomplex findet sich in Kapitel II.4. bei DISPLAY.SYS und
PRINTER.SYS.
F�r Details bei der Einrichtung von mehr als einer zus�tzlichen
Codeseite oder der Auswahl der Anzahl der unterst�tzten Fonts sei
auf das Handbuch und das DOSBOOK verwiesen!
Hier soll nur einmal anschaulich dargestellt werden, was man in der
�blichen Praxis alles f�r Codeseitenunterst�tzung ben�tigt (h�ufig
dr�cken sich die Dokumentatoren gerade um dieses aberwitzig kompli-
zierte Thema ;-) ):
CONFIG.SYS:
...
YESCHAR=J
REM -----------------------------------------------------------------
REM Hier Codeseite 437 angeben, auch wenn Sie sp�ter mit einer
REM anderen Codeseite arbeiten wollen, siehe Kapitel III.1. ...
COUNTRY=49,437,c:\nwdos\country.sys
REM -----------------------------------------------------------------
REM F�r EGA-/MCGA-/VGA-Systeme: Wenn Sie ein Zweimonitorsystem be-
REM sitzen (also zus�tzlich noch MDA oder HGC), d�rfen Sie hier keine
REM Codeseite angeben! Dann wird implizit die Hardware-Codeseite 437
REM �bernommen. Andernfalls erscheint hier eine Fehlermeldung, weil
REM MDA-/HGC-Karten keine Codeseitenunterst�tzung bieten...
DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,(1,3))
REM oder einfacher: DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,1)
REM Statt CON kann man (undokumentiert) auch CON: schreiben.
REM An die DISPLAY.SYS Zeile kann man (undokumentiert) einen mit
REM Semikolon abgetrennten Kommentar anh�ngen.
REM -----------------------------------------------------------------
REM Falls Sie (noch) einen Matrixdrucker angeschlossen haben, wird
REM meist die Epson-FX850/1050 Emulation auch mit Ihrem Drucker
REM funktionieren (wohingegen die anderen angebotenen Drucker der-
REM ma�en selten sind, da� man sie getrost h�tte weglassen k�nnen).
REM Gl�ck f�r Novell DOS Benutzer, denn bei MS-DOS gibt es �berhaupt
REM keine Unterst�tzung f�r Epson-Drucker (bei PC-DOS 6.1 wurde dies
REM nachgeholt, um dann mit MS-DOS 7 und PC-DOS 7 den Treiber
REM PRINTER.SYS ganz wegfallen zu lassen...). Auch hier:
REM Codeseite 437 w�hlen, wenn Ihr Drucker auf die �blichen US-
REM amerikanischen Einstellungen konfiguriert ist. Folgendes Beispiel
REM f�r einen Epson-kompatiblen Farbdrucker:
DEVICEHIGH=c:\nwdos\printer.sys prn=(1050,437,1)
INSTALLHIGH=c:\nwdos\graphics.com color
...
AUTOEXEC.BAT:
...
REM Hier nun die Codeseiten w�hlen, mit denen man (optional) arbeiten
REM m�chte (hier 850)... (Bei mehr als einer vorzubereitenden Code-
REM seite wird die Syntax etwas komplizierter...)
@MODE con: CODEPAGE PREPARE=((850) c:\nwdos\ega.cpi)
@MODE prn: CODEPAGE PREPARE=((850) c:\nwdos\1050.cpi)
REM NLSFUNC l�dt sich selbst hoch, sogar in die HMA!
@NLSFUNC c:\nwdos\country.sys
REM Wird nur f�r echte CGA-Karten ben�tigt (nicht bei Emulationen
REM durch EGA-/VGA-Karten). Ist nicht (direkt) f�r HGC-Grafiken
REM geeignet, daf�r gibt es allerdings andere Treiber auf dem Markt.
REM @LH GRAFTABL
REM Auf Standard-Codeseite umschalten...
CHCP 437
REM Tastaturtreiber laden (lagert sich normalerweise in HMA aus):
REM (Eine Alternative zu KEYB ist K3PLUS/FreeKEYB, zu beziehen �ber
REM mich.)
@KEYB GR+
...
ii. Tips zum 'Nachr�sten' fehlender Ger�te oder Codeseiten:
-----------------------------------------------------------
Der Treiberdatei PRINTER.SYS scheint noch Eintr�ge f�r 3 zus�tzliche
Drucker ("anyother") zu besitzt. Durch Vergleich der Dateien aus
DR DOS 3.40 bis Novell DOS 7 kann man feststellen, da� die Unter-
schiede nur minimal sind. Mit etwas �bung sollte es m�glich sein,
den Treiber so zu patchen, da� er auch andere Namen als "1050",
"4201", "4208" oder "5201" akzeptiert.
Danach k�nnte man sich eigene .CPI-Dateien f�r ganz pers�nliche
Drucker erstellen.
Eine Sache steht dem allerdings (zumindest f�r einige Kombinations-
m�glichkeiten) entgegen: In einigen F�llen (wohl in erster Linie
f�r die Hardware-Codeseite) werden die Escape-Sequenzen f�r den
Drucker direkt aus dem Treiber PRINTER.SYS und nicht aus einer
.CPI-Datei entnommen. Hier hilft es nur, auch die Hardware-Codeseite
zu �berladen. Aber auch dann, werden - zumindest bei Novell DOS und
abh�ngig von gew�hlten Druckertyp - offenbar immer noch Teile der
Sequenzen aus den treiberinternen Tabellen entnommen.
Gute Erfahrungen mit Novell DOS 7 habe ich mit dem Erstellen von
.CPI-Dateien gemacht, die den Druckertyp 1050 ersetzen. Das Format
der .CPI-Datei ist f�r diesen Typ zwar nicht ganz so �bersichtlich
wie f�r die anderen drei Typen (jeweils noch mit Untertypen), aber
ist hier definitiv eine 100%ige Ersetzung aller Escape-Sequenzen
durch Sequenzen aus der .CPI-Datei m�glich, eine Grundvoraussetzung
f�r eigene Experimente, wenn die .CPI-Datei nicht nur mit einer
DOS-Version funktionieren soll. Nachteilig am Typ "1050" ist es,
da� MS-DOS/PC-DOS diesen Typ evtl. nicht kennt. Dort m��te man auf
"4201" ausweichen, was aber unter Novell DOS 7 zu Problemen f�hrt.
Wer eine .CPI-Datei f�r die NEC Pinwriter Serie (P6plus (P5200),
P7plus (P5300), P20/P30, P60/P70, P90, P22Q/P32Q, P62/P72, P42/P52,
P42Q/P52Q und andere) sucht, kann eine solche Datei von mir anfordern
(NECPINW.ZIP).
Bei meinen Untersuchungen habe ich herausgefunden, da� das .CPI-
Format von Novell DOS im Gro�en und Ganzen eine Erweiterung des
.CPI-Formates von MS-DOS darstellt: Das Format der Druckerdateien
ist quasi identisch. Die Display-Fonts ab DR DOS 6.0 sind in einem
neuen Format abgelegt, das zwar �u�erlich dem bisherigen Format
�hnelt, aber durch Kompression wesentlich effizienter ist. Bis
DR DOS 5.0 war das Datenformat sowohl der Drucker- als auch der
Display-Fonts fast identisch zum MS-DOS "FONT" Format (au�er einer
'falschen' Typkennung in den Drucker-Fonts). Die neuen komprimierten
Display-Fonts ("DRFONT") von DR DOS 6.0 und Novell DOS 7 sind so
angelegt, da� die .CPI-Dateien nur etwa halb so gro� wie die ent-
sprechenden Dateien von MS-DOS sind, obwohl im Gegensatz zu
MS-DOS/PC-DOS statt f�nf oder sechs Codeseiten mit jeweils drei
Fonts (8x8, 14x8 und 16x8) neun (!) Codeseiten mit jeweils vier (!)
Fonts (6x8, 8x8, 14x8 und 16x8) unterst�tzt werden! Der Font 6x8
ist undokumentiert und l��t sich offenbar auch nicht ohne Patchen
von DISPLAY.SYS freischalten, obwohl er innerhalb der .CPI-Dateien
in vollem Umfang definiert wird. Jedenfalls f�hren Versuche wie
DEVICEHIGH=c:\nwdos\display.sys con=(EGA,,(1,4))
^----!!!
zu einer Fehlermeldung. Der Font 6x8 w�re - entsprechende Unter-
st�tzung durch das Grafikkarten-BIOS vorausgesetzt - f�r Textdar-
stellung in Grafikmodi und f�r Textmodi mit mehr als 43 Zeilen auf
Super-EGAs, mehr als 60 Zeilen auf Super-VGAs oder auch - mit Blick
auf DR PalmDOS - f�r spezielle reduzierte LCD-Anzeigen von PalmTops
interessant.
Trotzdem akzeptiert Novell DOS auch alte DR DOS .CPI-Dateien, und
- als Clo� - sogar .CPI-Dateien von MS-DOS oder PC-DOS (LCD.CPI
nur nach einem Patch, s.u.)! (Umgekehrt d�rfte dies generell nicht
m�glich sein.)
Da MS-DOS/PC-DOS in einigen Punkten mehr oder andere Codeseiten
unterst�tzt, sollte es m�glich sein, bei Bedarf die Codeseitendatei
von MS-DOS/PC-DOS auszuleihen. Allerdings:
Wird eine Codeseite bei Novell DOS (und DR DOS) bis auf wenige Aus-
nahmen f�r alle m�glichen Ger�te unterst�tzt, sieht die Situation bei
MS-DOS/PC-DOS wesentlich schlechter aus. Hier beschr�nkt sich der
Support mancher seltener Codeseiten teilweise auf nur ein Ger�t
(was die Frage nach dem Sinn des ganzen Aufwands aufkommen l��t, den
Microsoft in diesem Bereich getrieben hat, wenn man es dann doch nur
halb nutzen kann...). Abgesehen davon enthalten die .CPI-Dateien
von MS-DOS/PC-DOS (speziell die f�r Drucker) etliche Unstimmigkeiten,
die u.U. sogar zum H�ngen des Rechners f�hren k�nnten, wenn nicht
explizit darauf eingegangen wird. Wenn nicht alle Ger�te auf die
gleiche Codeseite umgeschaltet werden k�nnen (eben z.B. weil eine
Codeseite nicht f�r alle Ger�te verf�gbar ist), kann man statt
CHCP codepage
(das f�r seine Hauptfunktion, Codeseiten umzuschalten, auch noch
NLSFUNC ben�tigt) den Befehl
MODE device CODEPAGE SELECT=codepage
(mit device=con:, prn:, lpt1:, lpt2:, lpt3:)
verwenden, der die Codeseite nur selektiv f�r das jeweilige Ger�t
umschaltet. Das klappt auch dann, wenn bei CHCP nur Fehlermeldungen
erscheinen, weil NLSFUNC nicht geladen ist oder die Codeseite �ber-
haupt nicht f�r das eingestellte Land gedacht ist (das h�ngt von
COUNTRY.SYS ab). Ansonsten (z.B. bei MS-DOS) mu� man entweder jedes-
mal die CONFIG.SYS COUNTRY= Einstellung �ndern und neu booten oder
mit meinem FreeWare-Utility COUNTRY.EXE (�ber die entsprechende
API-Funktion) die Landeseinstellung �ndern. Obwohl nach dem Laden
von NLSFUNC f�r Programme Zugriff auf die landesspezifischen Daten
aller in COUNTRY.SYS unterst�tzten L�nder gew�hrleistet ist, k�nnen
Sie bei eingerichtetem Codeseitensupport nicht wahlfrei auf ein
anderes Land umschalten, wenn Sie eine Codeseite aktivieren, die
f�r das gew�nschte Land nicht gedacht ist (d.h. nicht alle Ger�te
mit aktivierter Codeseitenunterst�tzung dieses Land unterst�tzen).
Dies f�hrt manchmal zu recht paradoxen Situationen, in denen zwar
voller Support (inkl. Codeseitenunterst�tzung) f�r ein bestimmtes
Land vorhanden ist, Sie aber trotzdem zur Laufzeit nicht umschalten
k�nnen, weil eine 'fremde' Codeseite aktiviert ist. In diesen
F�llen gelingt die Umschaltung �ber eine Zwischenstufe, indem Sie
mit CHCP auf Codeseite 850 (manchmal 437) zur�ckschalten, danach
mit COUNTRY.EXE z.B. auf 1 (USA) wechseln, dort die gew�nschte
neue Codeseite mit CHCP w�hlen und dann mit COUNTRY.EXE auf das
neue Land umschalten. Dies ist aber kein Fehler, sondern nur eine
Nachahmung des 'ganz normalen Verhaltens', das MS-DOS in diesen
Situationen auch zeigt. Mit COUNTRY.EXE k�nnen Sie auch heraus-
finden, welche L�nder f�r jeweils welche Codeseiten in Ihrer
Systemkonfiguration unterst�tzt werden.
Ohne, da� ich dies auch unter MS-DOS ausprobiert habe, m�chte
ich darauf hinweisen, da� die Codeseitenumschaltung auch in
hohen Textmodi funktioniert (sofern die Fonts 8x8, 14x8 und 16x8
installiert sind): Mit meiner ET4000-Karte arbeiten die Textmodi
40x25, 80x25/43/50/60 und 132x25/28/60 als auch die Grafikmodi.
Bei den Modi 80x43/50 wurde allerdings jeweils auf 80x25 zur�ck-
geschaltet, was man nachtr�glich wieder �ndern kann (um dies zu
verhindern, m��te man einige Erg�nzungen im residenten Code von
DISPLAY.SYS implementieren). Die Textmodi 100x40 und 132x44 f�hrten
allerdings aus noch ungekl�rter Ursache zu EMM386-Schutzfehlern.
Reduziert man die Anzahl der installierten Fonts, kommt es auch
beim Umschalten von Codeseiten in anderen h�heren Textmodi zu
Schutzfehlern. Offenbar gibt es hier einen Bug in DISPLAY.SYS.
M�chten Sie die einzelnen Zeichens�tze simultan miteinander ver-
gleichen, k�nnen Sie z.B. einen Grafikmodus aktivieren und sich
danach mit einem kleinen Public-Domain-Utility (wie ASCII.COM) alle
ASCII-Zeichen ausgeben lassen. Danach schalten Sie mit CHCP auf eine
andere Codeseite um, und wiederholen die Anzeige aller Zeichen. Da
im Grafikmodus die Zeichen als Pixel abgelegt werden, werden Sie
nicht mit jedem Codeseitenwechsel umgeschaltet, so da� die Simultan-
darstellung m�glich wird.
Leider unterst�tzt Novells DISPLAY.SYS als Ger�tetyp nur "EGA",
nicht aber "LCD" (die anderen von MS-DOS unterst�tzten Typen "MONO",
"CGA", "EGA 8", "EGA 14", "EGA 14M" sind nur Dummies bzw. einiger-
ma�en obsolet. Die MS-DOS-Datei ISO.CPI enth�lt einen "EGA" Typ,
der von Novell DOS problemlos akzeptiert wird). Das Laden von MS-DOS
LCD.CPI unter Novell DOS scheitert am Typ "LCD". Trotzdem kann man
sich nach einer kleinen Modifikation auch die LCD.CPI Datei von
MS-DOS ausleihen:
COPY LCD.CPI NW7LCD.CPI
DEBUG
-Nnw7lcd.cpi
-L
-S0 cx+0100 "LCD"
cs:<aaaa> (�blicherweise 5 Vorkommen, wobei man die
cs:<bbbb> letzte Angabe normalerweise nicht patchen
cs:<cccc> mu�, da sie sich in einem Kommentarfeld
cs:<dddd> befindet!)
cs:<eeee>
cs:<ffff>
-E<aaaa> "EGA"
-E<bbbb> "EGA"
-E<cccc> "EGA"
-E<dddd> "EGA"
-E<eeee> "EGA"
-W
-Q
Nun kann die Datei NWLCD.CPI ganz normal wie EGA.CPI geladen werden,
mit dem Unterschied, da� sie nur den Font 8x8 unterst�tzt.
Vergessen Sie nicht, auch die Hardware-Codeseite (meist 437) mit
einer vorzubereitenden Codeseite 437 zu �berladen, sonst �ndert
sich die Darstellung nur in allen anderen Codeseiten (vgl.
DISPLAY.SYS in Kapitel II.4.).
M�chten Sie MS-DOS/PC-DOS ISO.CPI Datei verwenden, sollten Sie
zus�tzlich zu den normalerweise einzurichtenden Codeseiten noch 437
einrichten, denn der Hardware-Font 437 unterscheidet sich eklatant
vom Font 437 aus ISO.CPI (dies gilt f�r jedes DOS).
Auch hier gilt das bei LCD.CPI bez�glich der Codeseite 437 Gesagte.
Sollten Sie f�r die Erstellung neuer Codeseiten/Fonts das "DRFONT"
oder "FONT" .CPI-Dateiformat ben�tigen oder .CPI-Dateien analysieren
und auseinandernehmen wollen, k�nnen Sie �ber mich das Programm
CPI.EXE, meinen FreeWare-Analyser und -Decompiler f�r Codeseiten-
Dateien (im Archiv CPI???.ZIP) anfordern (z.B. auf meiner Web-Seite).
Im Groben ist das Dateiformat auch in Ralf Browns Interrupt-Liste
INTER50+ dokumentiert.
Bei der Erstellung eigener .CPI-Dateien d�rften EGA-/VGA-Font-Editore
(wie bei nahezu allen SuperVGA-Karten mitgeliefert) eine praktische
Hilfe sein. Die dort mitgelieferten .FNT-Dateien haben i. allg. das
gleiche Format (als Zeichen-Bitmaps) wie die internen Font-Daten
innerhalb der .CPI-Dateien, so da� Konvertierprogramme relativ
einfach zu schreiben sind (teilweise ist noch ein kurzer Info-Header
vorangestellt).
Sollten Sie spezielle FreeWare oder Public-Domain .CPI-, .CP- oder
.FNT-Dateien besitzen oder erstellen, w�re es nett, wenn Sie sie
auch mir zuschicken k�nnten: Ich m�chte in Zukunft ein kostenloses
Sammelpaket f�r neue und erweiterte .CPI-Dateien einrichten, so da�
f�r jedes DOS zus�tzliche Ger�te, Codeseiten und Fonts zur Verf�gung
stehen.
iii. Landescodes und Keyboard-K�rzel:
-------------------------------------
Die folgende Tabelle enth�lt die wichtigsten L�ndercodes, die von DOS
unterst�tzt werden. Grunds�tzlich ist zu sagen, da� Keyboard-IDs nur
von MS-DOS/PC-DOS 4.0+ unterst�tzt werden, Novell DOS 7 und DR DOS 6.0
verwenden teilweise andere Keyboard-Layout-K�rzel um das Gleiche zu er-
reichen. Novell DOS 7 unterst�tzt auch nicht alle Layout-K�rzel (siehe
Kapitel II.4. bei KEYB). Ein Plus ('+') hinter dem K�rzel bedeutet, da�
seit MS-DOS 6.2? mehr als eine Einstellung unter dem gleichen Namen
existiert. Diese erweiterten M�glichkeiten sind Novell DOS 7 fremd.
Normalerweise ist Novell DOS' KEYB besser als das Gegenst�ck von
MS-DOS, da der Treiber sich selbst�ndig in die HMA auslagert und den
darunterliegenden BIOS-Treiber teilweise mitbenutzt. Ein Stern ('*')
bedeutet, da� PNW 1.0 (und NetWare 3.xx) entsprechende Unterst�tzung
besitzt. Zwei Sterne ('**') bedeuten, da� mittlerweile Unterst�tzung
f�r jede NetWare (mit ODI/VLM) vorliegt, die z.B. in Novells Client-
Kit zu finden ist. Sollten Sie jedoch F�higkeiten vermissen, die bei
MS-DOS 6.2? KEYB neu hinzugekommen sind, k�nnen Sie mittels SETVER
auch diesen Treiber verwenden oder auf den erweiterten Tastaturtreiber
K3PLUS 6.50+ bzw. FreeKEYB (zu beziehen �ber mich) ausweichen.
Novell DOS' Direktive COUNTRY= akzeptiert leider auch nicht die
COUNTRY.SYS Datei von MS-DOS, so da� die M�glichkeit des 'Ausleihens'
in diesem Fall ausscheidet (was besonders �rgerlich ist, da dadurch
auch das Ausleihen von MS-DOS .CPI-Dateien f�r exotische L�nder
schwieriger wird). �ltere COUNTRY.SYS Dateien von DR DOS 5.0 und 6.0
als auch die von Caldera OpenDOS k�nnen aber verwendet werden (wichtig
zu wissen, falls Sie eine fremdsprachige DR DOS COUNTRY.SYS Datei
besitzen, die Einstellungen unterst�tzt, die Novell DOS 7 in der
deutschen Distribution fremd sind (w�rde mich �brigens sehr interes-
sieren)). Das Format der COUNTRY.SYS Datei von DR DOS/Novell DOS
findet sich ebenfalls in Ralf Browns Interrupt-Liste. Das Format
von MS-DOS/PC-DOS/OS/2 COUNTRY.SYS wird wahrscheinlich ab INTER54+
ebenfalls dort dokumentiert sein und ist auch in meinem Archiv
COUNTRY.ZIP zu finden.
Die deutsche Ausgabe von Novell DOS 7 enth�lt in der COUNTRY.SYS Datei
zus�tzlich zu den in der Dokumentation erw�hnten L�ndern Support f�r
die ehem. Tschechoslowakei (Tschechien und teilweise Slowakei) (42),
�sterreich (43), Japan (81), Korea (82), Saudi Arabien (785) und Israel
(972), obwohl f�r Fern-Ost wohl eine andere .CPI-Datei ben�tigt wird,
da die deutschen .CPI-Dateien keine Unterst�tzung f�r die Codeseite
932 etc. bietet. Vermutlich liegen auch allen anderen Ausgaben von
Novell DOS 7 (au�er der Japan-Version, falls diese wirklich existiert)
die gleichen COUNTRY.SYS und .CPI-Dateien bei.
Das ehem. Jugoslawien (38) sowie die Nachfolgestaaten und Brasilien
(55) werden von COUNTRY.SYS nicht unterst�tzt, wohl aber vom Keyboard-
Treiber ('~'). Achtung: Versuchen Sie niemals unter Novell DOS 7 das
Land 0 zu *setzen* (welches sowieso nicht definiert ist), in diesem
Fall wird der Rechner abst�rzen (getestet mit Update 15).
�brigens: Wie schon angedeutet, h�ngen die beiden Gr��en Country-Codes
und Codeseiten �ber ein recht verwirrendes Regelwerk zusammen und die
landesspezifischen Daten eines Landes k�nnen sich - einmal vor den
offensichtlichen �nderungen in der Repr�sentation der Daten - auch
beim �ndern der Codeseite �ndern! Z.B. �ndert sich jeweils zwischen
den beiden von Ru�land und Spanien unterst�tzten Codeseiten die
Darstellung von W�hrungen, zwischen den beiden von Italien und
Deutschland unterst�tzten Codeseiten die Darstellung des Zeitformates:
"hh:mm" bei 437 und "hh.mm" bei 850, allerdings nur bei Novell DOS 7
und DR DOS, nicht bei MS-DOS/PC-DOS. Dies ist allerdings zumindest
f�r Deutschland kein Fehler (mehr), da hier seit kurzem (Mai 1996)
neue Normen f�r Gesch�ftsbriefe eingef�hrt wurden und Daten jetzt
"yy-mm-dd" und Zeiten "hh:mm" geschrieben werden.
Einschub: Das 'japanische' Datumsformat hat zwei Vorteile gegen�ber
den beiden anderen Formaten:
1. Es kann wegen der f�hrenden Jahreszahl nicht mit den
beiden anderen Formaten verwechselt werden (zumindest
nicht bis zum Jahr 2001).
Beispiel:
Ist "10.11.96" der Zehnte des Monats November oder
der Elfte des Monats Oktober? Ohne Zusatzinformation
l��t sich dies nicht immer eindeutig entschl�sseln,
denn das verwendete Separator-Zeichen ist international
gesehen kein generelles Unterscheidungsmerkmal.
2. Wegen der absteigenden Priorit�t der Gr��en Jahr,
Monat, Tag entsteht im Datum ohne zus�tzliche Ma�nahmen
von selbst eine eindeutige Sortierreihenfolge.
Beispiel:
Benennt man Dateien, die Briefe (EMails) enthalten, nach
dem Erstellungsdatum, so werden diese bei alphabetisch
sortierten Inhaltsverzeichnisausgaben automatisch
chronologisch angeordnet, auch wenn man die Briefe �ber
mehrere Jahre hinweg in einem Verzeichnis ablegt. Dies
ist bei den beiden anderen Datumsformaten nicht der Fall.
Entgegen der Dokumentation bereitet bei Novell DOS die Aktivierung
der Codeseite 437 f�r Kanada (engl.) (2) und der Codeseite 850 f�r
Australien (Internationales Englisch) (61) Probleme (evtl. liegen
hier Fehler in der COUNTRY.SYS Datei vor; n�heres ist noch nicht
untersucht). Speziell auf Deutschland bezogen gibt es auch Unterschiede
in den landesspezifischen Daten, die von Novell DOS bzw. MS-DOS
geliefert werden (z.B. im W�hrungs- und Zeitformat).
Sollte Sie dies st�ren, k�nnen Sie die COUNTRY.SYS Datei von Novell DOS
auch so patchen, da� die gleichen Daten wie bei MS-DOS zur�ckgeliefert
werden. Beispielhaft wird dies f�r die deutschen Landeseinstellungen in
der COUNTRY.SYS Datei, die bei der deutschen Novell DOS 7 Ausgabe bei-
liegt (13312 Bytes) erl�utert. Das Byte an Offset +08E9h ausschlag-
gebend. Hier steht normalerweise ein 2Eh '.', das in ein 3Ah ':' ge-
�ndert werden kann (nach der Norm bis Anfang 1996 war dies jedoch
eigentlich bei MS-DOS falsch). Der Vorgang mit DEBUG:
COPY COUNTRY.SYS COUNTRY1.SYS
DEBUG
-Ncountry1.sys
-L Der Wert f�r CX (die Dateil�nge) sollte hier
3400h betragen! Sonst nicht fortfahren!
F�r Codeseite 850:
-Ecs:09E9 2E. 3Ah Falls dort ein Zeitseparator 2Eh '.' steht,
diesen durch 3Ah ':' <RET> ersetzen.
Ansonsten nur <RET> dr�cken, denn Sie haben
-W wahrscheinlich etwas falsch gemacht, oder die
-Q Datei ist bereits angepa�t.
M�chten Sie die deutschen Landeseinstellungen von Novell DOS 7 hingegen
*komplett* an die neue Norm f�r Gesch�ftsbriefe anpassen, k�nnen Sie
COUNTRY.SYS stattdessen folgenderma�en patchen (in diesem Beispiel
werden die Einstellungen f�r Codeseiten 437 und 850 ge�ndert):
COPY COUNTRY.SYS COUNTRY2.SYS
DEBUG
-Ncountry2.sys
-L Der Wert f�r CX (die Dateil�nge) sollte hier
3400h betragen! Sonst nicht fortfahren!
F�r Codeseite 437:
-Ecs:09C0 01. 02h Falls dort 01h steht, dies mit 02h <RET>
f�r 'Japanisches' Datumsformat �berschreiben.
Ansonsten nur <RET> dr�cken.
-Ecs:09CB 2E. 2Dh Falls dort ein Datumsseparator 2Eh '.' steht,
diesen mit 2Dh '-' <RET> �berschreiben.
F�r Codeseite 850:
-Ecs:09DC 01. 02h Falls dort 01h steht, dies mit 02h <RET>
f�r 'Japanisches' Datumsformat �berschreiben.
Ansonsten nur <RET> dr�cken.
-Ecs:09E7 2E. 2Dh Falls dort ein Datumsseparator 2Eh '.' steht,
diesen mit 2Dh '-' <RET> �berschreiben.
-Ecs:09E9 2E. 3Ah Falls dort ein Zeitseparator 2Eh '.' steht,
diesen mit 3Ah ':' <RET> �berschreiben.
Ansonsten nur <RET> dr�cken.
-W
-Q
(F�r dieses Unterfangen steht auf meiner Web-Seite und auf einigen
FTP-Servern unter dem Namen JPDATE49.ZIP auch ein automatisierter
Patch zur Verf�gung.)
Die allermeisten L�nder unterst�tzen wenigstens Codeseite 850 (und
�ber die Hardware 437, allerdings nicht unbedingt auf der Ebene von
COUNTRY.SYS), dies wird aber nur kritisch, wenn Sie Codeseitenunter-
st�tzung eingerichtet haben.
Land Name Codeseiten Keyboard MS-DOS/ Caldera OpenDOS/
Layout PC-DOS Novell DOS
(3.3+) (3.0+) DR DOS
000 undefiniert 7Bit-ASCII -- -- --! **
001 Vereinigte Staaten 437,850 US (103) 2.00+ 3.40+ *
DV (Dvorak) 6.20+ --
RH (Rechts) 6.20+ --
LH (Links) 6.20+ --
002 Kanada (Franz�sisch) 850,863 CF + (058) 2.00+ 3.40+ *
"" (Englisch) 850,863 CF + -- 3.40+ *
003 Lateinamerika 850,437 LA (171) 2.00+ 3.40+ *
004 Kanada (Englisch) 850,863 CF + 6.2?+ --
007 Ru�land 866,855,852,850,437 RU 441,443,341 6.2?+ 6.0+ **
027 S�dafrika 437,850 US 6.2?+ --
030 Griechenland 869,737,850 GK 319 6.2?+ --
031 Niederlande 850,437 NL (143) 2.00+ 3.40+ *
032 Belgien 850,437 BE (120) 2.00+ 3.40+ *
033 Frankreich 850,437 FR 120,189 2.00+ 3.40+ *
034 Spanien 850,437 SP (172) 2.00+ 3.40+ *
035 undokumentiert??? (offenbar wie Bulgarien) 6.22/95 --
036 Ungarn 852,850 HU 208 2.00+/5.0+ 6.0+ **
038 ehem. Jugoslawien 852,850 YU 234 2.00+/5.0+ ~6.0-7
"" (Kyrillisch) 855,850 YC 118 6.2?+ --
039 Italien 850,437 IT 141,142 2.00+ 3.40+ *
040 Rum�nien 852,850 RO 333,446 6.2?+ --
041 Schweiz (Deutsch) 850,437 SF (Franz., 150) 2.00+ 3.40+ *
SG (Deutsch, 000) 2.00+ 3.40+ *
042 ehem. Tschechoslowakei **
"" (Tschechien) 852,850 CZ 243 5.0+ 6.0+
"" (Slowakei) 852,850 SL 5.0
043 �sterreich 850,437 GR + 6.2?+ 5.0+
044 Gro�britannien 850,437 UK 166,168 2.00+ 3.40+ *
045 D�nemark 850,865 DK (159) 2.00+ 3.40+ *
046 Schweden 850,437 SV (153) 2.00+ 3.40+ *
047 Norwegen 850,865 NO (155) 2.00+ 3.40+ *
048 Polen 852,850 PL (214) 5.0+ 6.0+ **
(zus�tzlich 667 und 668 bei PTS/DOS 6.51 und S/DOS 1.x)
049 Deutschland 850,437 GR + (129,453) 2.00+ 3.40+ *
052 Mexiko 850,437 LA 6.2?+ --
054 Argentinien 850,437 LA 6.2?+ --
055 Brasilien 850,437 BR 274,275 5.0+ ~6.0+
056 Chil� 850,437 LA 6.2?+ --
057 Kolumbien 850,437 LA 6.2?+ --
058 Venezuela 850,437 LA 6.2?+ --
060 Malaysia 437,??? -- 6.2?+ --
061 Internat. Englisch 437,850 -- 2.00+ *
Australien 437,850 US 6.2?+ 3.41+ *
064 Neuseeland 437,850 US 6.2?+ --
065 Singapur 437,??? -- 6.2?+ --
066 Tailand 874 -- --
081 Japan 437,932 JP (194) ~5.0+ 3.40+ *
JA 4.0 --
082 Korea 437,934 (KO) ~4.0/~6.2? 5.0+
086 VR China 437,936 (CH) ~4.0/~5+
088 Taiwan (China trad.) 437,938 (TN) ~4.0/~5+
090 T�rkei 857,850 TR 440,179 5.0?+ -- **
TF (FDDIOD) -- 6.0+
TQ (QWERTY) -- 6.0+
091 Indien 437,??? -- 6.2?+ --
099 Asien (Englisch) -- -- --
351 Portugal 850,860 PO (163) 2.00+ 3.40+ *
353 Irland 850,437 UK 6.2?+ --
354 Island 850,861 IS 161,197 6.0+ --
355 Albanien 852,850 AL (452) 6.2?+ --
358 Finnland 850,437 SU (153) 2.00+ 3.40+ *
359 Bulgarien 855,850 BG 442,(241) 6.2?+ --
370 Litauen (1257) -- --
371 Lettland (1257) -- --
372 Estland (1257) -- --
381 Serbien/Montenegro 855,850,915 YC 118,450 6.2?+ --
384 Kroatien 852,850 YU 234 6.2?+ --
385 Kroatien 852,912 HR 234 PC 7.0 --
386 Slowenien 852,850,912 YU,SI 234 6.2?+ --
387 Boznien/Herzegowina 852,850 YU 234 6.2?+ --
388 Boznien/Herzegowina 855,915 BC 450,118 PC 7.0 --
389 Mazedonien 855,850 YC 118 6.2?+ --
421 Slowakei 852,850 SL 245 6.2?+ --
Tschechien 852,912 CZ 243 PC 7.0 --
422 Slowakei 852,912 SK 245 PC 7.0 --
593 �quador 850,437 LA 6.2?+ --
711 undokumentiert??? (W�hrung ist EA$) 6.22/95 --
785 Mittlerer Osten/
Saudi Arabien 850,864 -- ~2.00+/5.0+ 3.40+ **
852 Hongkong 437,??? -- 6.22+
886 Taiwan 6.22+
972 Israel (Hebr�isch) 850,862 -- ~2.00+/5.0+ 3.40+ **
Normalerweise kann man die Einstellung des aktuellen Landes nur �ber
die COUNTRY= Direktive beim Booten des Rechners �ndern (siehe Kapitel
III.1.). Gibt man keine COUNTRY= Direktive an, so werden �blicherweise
die US-amerikanischen Landeseinstellung angenommen (manchmal auch die
Einstellung der Landesanpassung, allerdings nicht bei allen mir be-
kannten Ausgaben von DR DOS und Novell DOS). Mit entsprechenden
Utilities kann man die Landeseinstellungen jedoch auch zur Laufzeit
�ndern, siehe z.B. mein FreeWare-Utility COUNTRY.EXE (aus COUNTRY.ZIP).
�brigens werden sie dabei gleichzeitig f�r alle Tasks des evtl.
laufenden Multitaskers wie TASKMGR oder Windows ge�ndert, was manchmal
w�nschenswert, manchmal aber auch unpassend ist. Solange man bei
COUNTRY= nicht den Namen zur Datei COUNTRY.SYS angegeben hat, kann
man offenbar in einigen DOS-Versionen nur zwischen den US- und den
bei COUNTRY= gew�hlten Einstellungen wechseln (da diese immer im
Speicher liegen), sonst (zumindest bei installiertem NLSFUNC) zwischen
allen L�ndern, die von COUNTRY.SYS unterst�tzt werden.
iv. Codeseiten:
---------------
Die folgende Tabelle enth�lt eine kurze Zusammenfassung der Codeseiten-
Unterst�tzung in den verschiedenen DOS-Versionen. Anhand dieser Tabelle
k�nnen Sie schnell feststellen, ob die ben�tigte Codeseite von
Novell DOS 7 unterst�tzt wird oder ggf. von einer DR DOS, MS-DOS
oder PC-DOS Version entliehen werden kann (wobei bei Letzteren bei
weniger �blichen Codeseiten zumindest in den westeurop�ischen und
amerikanischen Versionen i. allg. nicht alle Ger�te unterst�tzt
werden). Es ist m�glich, da� die aufgef�hrten Codeseiten nicht in
allen landessprachlichen Versionen unterst�tzt werden (falls mir dies
bekannt ist, habe ich den entsprechenden Eintrag mit '~' versehen).
Im Zweifelsfall wenden Sie sich am besten an Novell bzw. Caldera.
Soweit eindeutig bekannt, habe ich DBCS-Codeseiten (double byte
character sets) extra erw�hnt, jedoch sind auch noch einige der
restlichen Codeseiten DBCS-Codeseiten. (Ein '*' bedeutet, da� die
Codeseite von PNW 1.0 und NetWare 3.xx unterst�tzt wird, '**' bedeutet,
da� sie standardm��ig nur von NetWare 3.xx unterst�tzt wird, nicht
von PNW 1.0. Nat�rlich ist es m�glich, sich die entsprechenden
Dateien des \NLS\ Verzeichnisses von einer gro�en NetWare auszuleihen.
Ein '!' bedeutet, da� diese Codeseitennummer von Novell NetWare f�r
einen reduzierten 7Bit-ASCII Zeichensatz reserviert ist, um f�r L�nder,
f�r die noch keine Codeseitenunterst�tzung existiert, �berhaupt ein
Arbeiten zu erm�glichen. Diese 'Codeseite' unterst�tzt nur die Zeichen
ASCII-32 bis ASCII-127 mit Ausnahme von ASCII-92.)
(Die zus�tzlichen Angaben zu OS/2 und MS Windows95 haben nur
informativen Charakter, da die interne Organisation anders realisiert
ist; ein Austausch d�rfte nicht m�glich sein. F�r den MS-DOS 7 Anteil
von MS Windows95 und PC-DOS 7 hat sich nicht sonderlich viel getan,
au�er da� die beiden bisher undokumentierten Printer-Codeseiten durch
generellen Verzicht auf Printer-Codeseiten-Dateien flachgefallen sind
und, da� - bei MS-DOS 7 - die Display-Codeseiten aufgrund des neu
eingef�hrten Long-Filename-Supports nun nur noch zum Installations-
zeitpunkt umgeschaltet werden k�nnen (Ausnahme CHANGECP). Benutzt man
CHCP in einer DOS-Box, so t�uscht es das Umschalten der Codeseite vor,
ohne die Umschaltung wirklich vorzunehmen. Allerdings hatte auch schon
unter MS Windows 3.xx die Umschaltung der Codeseite f�r DOS-Boxen im
Fenster keine sichtbare Wirkung, solange nicht entsprechende Fonts
installiert waren. All diese Gr�nde sprechen daf�r, auch heute noch
die Codeseite 437 als Standard unter Windows zu w�hlen, d.h. Windows95
sofort nach der Installation mit CHANGECP auf diese Codeseite zur�ck-
zuschalten.)
Codeseite Name MS-DOS/ Novell DOS/
PC-DOS DR DOS
0 Reduziertes 7Bit-ASCII -- --!
37 EBCDIC: Englisch (US/Kanada) (CECP) -- --
38 EBCDIC: International (alt) -- --
111 Griechisch [AST Premium Exec DOS 5.0] -- --
112 T�rkisch [AST Premium Exec DOS 5.0] -- --
113 Jugoslawisch [AST Premium Exec DOS 5.0] -- --
161 Arabisch [Linux] -- --
162 Arabisch [Linux] -- --
163 Arabisch [Linux] -- --
164 Arabisch [Linux] -- --
165 Arabisch [Linux] -- --
237 EBCDIC: Deutschland (CECP) -- --
273 EBCDIC: unbekannt (CECP) -- --
274 EBCDIC: Belgien -- --
275 EBCDIC: Brasilien -- --
277 EBCDIC: D�nemark, Norwegen (CECP) -- --
278 EBCDIC: Finnland, Schweden (CECP) -- --
280 EBCDIC: Italien (CECP) -- --
281 EBCDIC: Japan (E) -- --
284 EBCDIC: Latein-Amerika/Spanien (CECP) -- --
285 EBCDIC: Englisch (UK) (CECP) -- --
290 EBCDIC: Japan (Kana) -- --
297 EBCDIC: Franz�sisch (CECP) -- --
367 US-ASCII (ISO 646-US 7Bit) -- --
420 EBCDIC: Arabisch 1 -- --
423 EBCDIC: Griechisch -- --
424 EBCDIC: Hebr�isch -- --
437 Englisch/West-Europa (World Trade) 3.30+ 3.40+ *
500 EBCDIC: Belgien, Schweiz (International) (CECP) -- --
646 (reserviert f�r ISO 646 7Bit-Codeseiten) -- --
667 Ost-Europa (Polnisch) [PTS/DOS u. S/DOS] -- --
668 Ost-Europa (Slawisch) [PTS/DOS u. S/DOS] -- --
708 Arabien/Mittlerer Osten ~95 --
737 Griechenland (2) 6.2?+ --
775 Baltische Staaten (BaltRim) ~95 --
819 Latein 1 (ISO 8859-1) -- --
850 International/Multilingual (Latein 1) 3.30+ 3.40+ *
851 Griechenland (undok., siehe 8510) [AST, WP] 4.00-6.22 --
852 Slawisch/Ost-Europa (Latein 2) 5.0+ 6.0+
853 T�rkisch (Latein 2) (undok.) [AST] 4.00-6.22 6.0+
854 Spanisch (obsolet)??? -- --
855 Kyrillisch (1) 4.00+ --
857 T�rkisch 6.1+ 6.0+
860 Portugal (siehe 8600) 3.30+ 3.40+ **
861 Island 6.0+ --
862 Israel (Hebr�isch) 4.00+/~95 3.40-5.0/~6.0
863 Kanada (Franz�sisch) 3.30+ 3.40+ **
864 Arabien/Mittlerer Osten 4.00+ 3.40+
865 Nordisch (Norwegen/D�nemark) 3.30+ 3.40+ **
866 Ru�land (Kyrillisch 2) 6.1/6.22+ 6.0+
867 Tschechisch [NEC Pinwriter P20/P30/P60/P70/P90] -- --
868 Arabisch -- --
869 Griechenland (1) 6.1+ --
870 EBCDIC: Jugoslawien (Roece) -- --
871 EBCDIC: Isl�ndisch -- --
874 Thailand ~95 --
875 EBCDIC: Griechenland -- --
880 Ru�land (Kyrillisch GOST und EBCDIC) -- --
881 Latein 1 [AST Premium Exec DOS 5.0] -- --
882 Latein 2 [AST Premium Exec DOS 5.0] -- --
883 Latein 3 [AST Premium Exec DOS 5.0] -- --
884 Latein 4 [AST Premium Exec DOS 5.0] -- --
885 Latein 5 [AST Premium Exec DOS 5.0] -- --
891 unbekannt -- --
895 Tschechisch (Kamenicky) [WP] -- --
897 Japan etc. (Shift-JIS) -- -- **
899 Kyrillisch [WP] (siehe 8990) -- --
903 unbekannt -- --
904 unbekannt -- --
905 EBCDIC: T�rkisch -- --
912 Lateinisch 2 (ISO 8859-2) PC 7.0 --
915 Latein/Kyrillisch (ISO 8859-5) PC 7.0 --
918 EBCDIC: Arabisch 2 -- --
928 reserviert f�r Griechenland (ELOT 928, ISO 8859-7)
932 DBCS: Japan (Shift-JIS) ~4.00+ ~6.0+ **
934 DBCS: Korea ~4.00+ ~6.0+
936 DBCS: VR-China (vereinfacht, erw. GB) ~4.00+ --
938 DBCS: Taiwan (trad. China) ~4.00+ --
942 DBCS: Japan SAA (~OS/2) --
944 DBCS: Korea SAA (~OS/2) --
948 DBCS: VR-China SAA (~OS/2) --
949 Korea (Unified Hangul, erw. Wansung) ~95 --
950 China trad., Taiwan, Hong Kong (Big5) ~95 --
966 Saudi Arabien ~95 --
972 Hebr�isch (Israelisches VT100 Terminal) -- --
999 reserviert -- 5.0+ KEYB
1002 unbekannt [NT4] -- --
1004 Desktop Publishing (OS/2, DAPIE, Open32) --
1026 EBCDIC: T�rkei (Latein 5) -- --
1047 EBCDIC: Internat. (US, defacto EBCDIC) (CECP) -- --
1250 WIN: Ost-Europa (Latein 2) (95) -- **
1251 WIN: Kyrillisch (95) -- **
1252 WIN: Englisch/West-Europa (Latein 1) (3.xx,95) (PNW 1.0) *
1253 WIN: Griechenland (GRC) (95) --
1254 WIN: T�rkei (95) --
1255 WIN: Israel/Hebr�isch (95) --
1256 WIN: Arabien (95) -- **
1257 WIN: Baltische Staaten (95) --
1258 WIN: Vietnam -- --
1361 ANSI???: Korea (Johab) (95) --
8510 Griechenland (Alternativ zu 851) [WP] -- --
8600 Portugal (Brasilianisch) [WP] -- --
8990 Kyrillisch (Akzentuierte russische Vokale) [WP] -- --
10000 MAC: International/Standard -- --
10001 MAC: unbekannt -- --
10006 MAC: Griechenland -- --
10007 MAC: Kyrillisch -- --
10010 MAC: unbekannt -- --
10017 MAC: unbekannt -- --
10029 MAC: Latein 2 -- --
10079 MAC: Island -- --
10081 MAC: T�rkei -- --
10082 MAC: unbekannt -- --
10646 (reserviert f�r ISO 10646 32Bit-Codeseite) -- --
20261 unbekannt [NT4] -- --
20866 unbekannt [NT4] -- --
28592 unbekannt [NT4] -- --
65400 erste 256 Glyphen des aktuellen Fonts (OS/2 3+) --
65534 intern reserviert f�r DR DOS -- --
65535 intern von DOS und DR DOS reserviert -- --
Die meisten Taschencomputer (z.B. von SHARP) und einige andere Computer
benutzen �blicherweise ebenfalls die Hardware-Codeseite 437 (auch wenn
sie dort meist nicht so hei�t), lediglich neuere sog. PDAs (pers�nliche
digitale Assistenten) folgen zunehmend dem Trend hin zu Codeseite 850.
Eine Reihe anderer Computer (Amiga, Acorn) verwenden eine der Codeseite
1252 (ab Windows 3.0+) entsprechende Zuordnung, die an die ANSI-Code-
seite nach ISO-8859-1 angelehnt ist, ihr aber nicht zu 100% Prozent
entspricht. Von DOS selbst wird diese Seite nicht angeboten.
Aus Gr�nden der besseren Austauschbarkeit von Dateien empfehle ich -
wenn nicht spezielle Gr�nde dagegen sprechen - weiterhin die Codeseite
437 als Standard zu verwenden und die Codeseite 850 lediglich f�r alle
F�lle vorzubereiten, aber nicht als permanente Einstellung zu benutzen
(auch wenn in den letzten Jahren die meisten Microsoft SETUP-Programme
die Codeseite 850 eigenm�chtig als Standard aktivieren). (Benutzer von
MS Windows95 m�ssen sich direkt nach der Installation f�r eine Code-
seite entscheiden, d.h. ggf. sofort mit CHANGECP auf 437 umkonfigu-
rieren. Eine sp�tere �nderung kann zu nicht mehr �ber ihren Namen
erreichbaren Dateien f�hren, da die neuen Long-Filenames in Unicode
abgelegt werden und die Zuordnung zwischen Unicode und den jeweiligen
Zeichens�tzen nat�rlich nicht beliebig umkehrbar ist.)
v. Internationale Batchjobs:
----------------------------
Beim Schreiben von Batchjobs, die in jedem Land funktionieren sollen,
mu� man besonders aufpassen, wenn innerhalb der Batchjobs Situationen
auftreten k�nnen, die eine Benutzerinteraktion erfordern. In solchen
F�llen m�chte man die notwendigen Eingaben h�ufig aus einer Eingabe-
umleitung holen, oder umgekehrt, die Ausgabe bestimmter Kommandos mit
Filtern wie FIND oder SORT auswerten, um dann im weiteren Verlauf des
Batchjobs entsprechend zu reagieren.
Ein h�ufiges Problem ist z.B. die Ja/Nein-Abfrage, die viele Kommandos
stellen k�nnen. Verwendet man die deutsche Kernel-Version, wird man
nach (J/N) gefragt (au�er in CONFIG.SYS, wo man YESCHAR= einsetzen
kann); mit der englischen Version lautet die Frage jedoch (Y/N), usw.
Das Problem liegt nun darin, da� eine Befehlszeile wie
ECHO J | DEL *.*
nur mit der deutschen Kernelversion funktioniert. Solange wenigstens
der Buchstabe f�r 'Nein' bei allen Kernel-Versionen gleich bleibt,
d.h. auch nicht mit dem Buchstaben f�r 'Ja' irgendeiner Kernel-
Version �bereinstimmt, hilft manchmal folgender Trick, der die 'Ja'-
Buchstaben aller Versionen hintereinander ausgibt (siehe bei FDISK
in Kapitel II.4.). (Leider ist das global gesehen keine L�sung, denn
z.B. in Ru�land ist der Buchstabe f�r Ja ein 'L' und f�r Nein ein 'Y',
was obendrein noch mit 'Yes' kollidiert. Allerdings gibt es keine
speziell russische Version von Novell DOS.)
ECHO YOSJ | DEL *.* > \nul\dev
(was aber leider so pauschal nur bei 4DOS funktioniert, da hier
explizit auf 'Ja' oder 'Nein' gewartet wird und nicht alles, was
nicht 'Ja' ist, als 'Nein' interpretiert wird. Diese Methode kann
man auch bei Novells MOVE sowie mit FDISK aus Update 15 anwenden,
siehe Kapitel II.4.).
ECHO FEAD | MOVE c:\source.tmp c:\dest.tmp
F�r Kommandos, wo diese gl�ckliche F�gung nicht zutrifft (oder in
anderen DOS-Versionen anders implementiert ist), bietet sich die
folgende, recht holprige, aber auch mit Novells COMMAND.COM lauf-
f�hige Alternative an (Achtung: Keine Bedingung voranstellen, siehe
Kapitel IV.6.):
FOR %%x IN (Y O S J) DO ECHO %%x | DEL *.* > \dev\nul
oder - bei Verwendung einer Variable %yeschar%, die z.B. in
AUTOEXEC.BAT belegt wird - auch eine L�sung wie folgt:
ECHO %yeschar% | DEL *.*
Damit man in Batchjobs vorsorgen kann, im folgenden eine �bersicht
�ber externe Kommandos, die in bestimmten Situationen interaktive
Best�tigungen erwarten (noch sehr unvollst�ndig, bezieht sich auf
deutsche Version, f�r interne Kommandos sei auf Kapitel II.13.
verwiesen):
Ja/Nein Datei/Verzeichnis Frage nach Pa�wort
COMP J/N -
MOVE J/N D/V
LABEL J/N? -
UNDELETE J/N -
DELTREE (MS-DOS) J/N -
Sonderzeichen�bersicht:
Bedeutung: Zeichen in Novell DOS 7 Kernel-Version:
U F S I G J
Ja-Zeichen <Y> <O> <S> <S> <J> ?
Nein-Zeichen <N> <N> <N> <N> <N> ?
Datei-Zeichen <F> <F> <A> <F> <D> ?
Verzeichnis-Zeichen <D> <R> <D> <D> <V> ?
Abbruch <A> <A> <A> <A> <A> ?
Wiederholen <R> <R> <R> <R> <W> ?
Ignorieren <I> <I> <I> <I> <I> ?
Fehler <F> <T> <F> <F> <F> ?
"nicht" not ? no non nicht ?
"Frei" Free Libre Libre Libera Frei ?
"aktiviert" enabled activ�e activada attivata aktiviert ?
"deaktiviert" disabled d�sactiv�e desactivada disattivata inaktiviert
%NWLanguage% ENGLISH FRANCAIS ESPANOL ITALIANO DEUTSCH \ ?
\ NIHON[GO]
(au�er Konkurrenz: %NWLanguage% PORTUGUE[SE])
Wie findet man die passenden Schl�sselworte heraus? Einfach die
landessprachlichen Updates besorgen (siehe Kapitel I.2.) und die
Dateien (insb. COMMAND.COM) unter sprachlichen Gesichtspunkten
miteinander vergleichen. Dabei kann ein Batchjob wie im folgenden
Beispiel n�tzlich sein:
GETD70.BAT:
@ECHO off
ECHO GETD70 V1.01 - Get file from all Novell DOS 7 localized updates
ECHO Syntax: GETD70 file_from_all_updates
ECHO Each floppy may only contain one update release!
REM 96-04-03 -mp
IF ""=="%1" GOTO end
PAUSE Insert US update in floppy drive A:
FOR %%x IN (A:D70U*.*) DO %%x -x -s %1
REN %1 U%1
PAUSE Insert German update in floppy drive A:
FOR %%x IN (A:D70G*.*) DO %%x -x -s %1
REN %1 G%1
PAUSE Insert French update in floppy drive A:
FOR %%x IN (A:D70F*.*) DO %%x -x -s %1
REN %1 F%1
PAUSE Insert Italian update in floppy drive A:
FOR %%x IN (A:D70I*.*) DO %%x -x -s %1
REN %1 I%1
PAUSE Insert Spanish update in floppy drive A:
FOR %%x IN (A:D70S*.*) DO %%x -x -s %1
REN %1 S%1
:end
Bez�glich der Realisierung von Batchjobs, die bestimmte Schl�sselworte
in Bildschirmmeldungen erkennen m�ssen und trotzdem auf landessprach-
liche Besonderheiten eingehen, sei auf MEM.BAT aus Kapitel IV.5. ver-
wiesen.
Ungl�cklicherweise gibt es bei den landessprachlich unterschiedlichen
Buchstaben einige �berschneidungen, wie etwa bei der Unterscheidung
zwischen Datei oder Verzeichnis (Im Deutschen steht D f�r <D>atei, im
Englischen f�r Verzeichnis=<D>irectory). U.U. ist es m�glich, die
Reihenfolge der umgeleiteten Sequenzen so anzuordnen, da� trotzdem
immer der richtige Buchstabe akzeptiert wird (siehe bei MOVE.EXE in
Kapitel II.4.), aber manchmal hilft nur die explizite Unterscheidung
der Kernel-Version. Achtung: Der Alternativ-Kommandoprozessor 4DOS.COM
existiert meines Wissens nur in einer englischen Version und verwendet
demnach ausschlie�lich die Buchstaben der US-Version, die Lizenz-
version NDOS.COM von den Norton Utilities ist jedoch der jeweiligen
Sprache angepa�t (d.h. die deutsche Version verwendet die gleichen
Buchstaben, wie die deutsche COMMAND.COM Version)!
Daf�r verwendet man am besten einen Batchjob, der f�r jedes in Frage
kommende Zeichen eine entsprechende Umgebungsvariable mit dem
passenden Buchstaben belegt. Weiterhin darf man in allen Batchjobs nur
mit diesen Variablen statt der konkreten Werte arbeiten. In Anlehnung
an Novell DOS YESCHAR= Direktive schlage ich daf�r die folgenden
Namen vor (je mehr sich daran halten, desto eher kann etwas wie ein
globaler Standard etabliert werden):
%yeschar%, %nochar%, %filechar%, %dirchar%, %abortchar%, %retrychar%,
%ignorechar%, %failchar%, %switchar% (siehe SWC.BAT und MEM.BAT).
Das Problem besteht nun noch darin, die installierte Kernel-Version
herauszufinden. Das folgende Beispiel zeigt die einfachste L�sung, die
nur mit Mitteln der Batch-Sprache auskommt, siehe auch Kapitel IV.7.
Erweiterungen dieser Methode k�nnen in einem Praxisbeispiel in Kapitel
IV.5. beim Batchjob MEM.BAT studiert werden.
Die in den einzelnen Kernel-Versionen m�glichen Werte f�r die Pseudo-
Umgebungsvariablen (Systeminformationskonstanten) %Greeting_Time%,
%Month_Name% und %Day_Of_Week% sind in Kapitel IV.7. zu finden.
Achtung:
Falls Sie 4DOS/NDOS.COM verwenden, m�ssen Sie dieses Beispiel noch
passend erweitern, denn einerseits mu� dann bez�glich der Sprache
zwischen internen und externen Kommandos unterschieden werden und
andererseits existieren von 4DOS.COM nur englische, von NDOS.COM aber
landessprachlich angepa�te Varianten.
U.U. k�nnen Sie - wie in MEM.BAT - den Hilfsschirm eines externen
Kommandos per FIND nach bestimmten W�rtern durchsuchen lassen, um die
Sprache der externen DOS-Utilities festzustellen. Die Sprache der
COMMAND.COM internen Befehle kann auf die gleiche Weise z.B. mit
COMMAND /? ermittelt werden, bez�glich der Sprachbestimmung von
4DOS/NDOS.COM sei auf 4DOSTIP.TXT verwiesen.
Ein unvollst�ndiges Beispiel:
...
REM Check for Novell DOS 7 kernel localization (not with 4DOS/NDOS)...
FOR %%x IN (morning afternoon evening) DO IF ...
..."%%x"=="%Greeting_Time%" GOTO U
FOR %%x IN (Bonjour Bonsoir) DO IF "%%x"=="%Greeting_Time%" GOTO F
FOR %%x IN (ma�ana tarde noche) DO IF "%%x"=="%Greeting_Time%" GOTO S
FOR %%x IN (giorno pomeriggio sera) DO ...
... IF "%%x"=="%Greeting_Time%" GOTO I
FOR %%x IN (Morgen Tag Abend) DO IF "%%x"=="%Greeting_Time%" GOTO G
REM FOR %%x IN (xxxx xxxx xxxx) DO IF "%%x"=="%Greeting_Time%" GOTO J
REM [insert other decisions here]
IF "4"=="%@Eval[2 + 2]%" IF NOT ""=="%_4Ver%" GOTO U
REM IF "4"=="%@Eval[2 + 2]%" IF NOT ""=="%_NVer%" GOTO ...
...
:U
SET yeschar=Y
SET nochar=N
SET filechar=F
SET dirchar=D
GOTO continue
:F
...
GOTO continue
:S
...
GOTO continue
:I
...
GOTO continue
:G
SET yeschar=J
SET nochar=N
SET filechar=D
SET dirchar=V
GOTO continue
REM :J ...
:continue
...
Weitere Probleme in internationalen Batchjobs k�nnen deshalb auf-
treten, weil sich bei Novell DOS nat�rlich die Datums- und Zeit-
formate aller DOS-Kommandos (DATE, TIME, UNDELETE, DELPURGE, um nur
einige Beispiele zu nennen) an das per COUNTRY= eingestellte Land
anpassen, wobei hier zwar die Separatoren in Grenzen wahlfrei bleiben,
das Datumsformat (Reihenfolge von Tag, Monat und Jahr) aber jeweils
korrekt angegeben werden mu�. �hnliches gilt f�r die Sortierreihen-
folge von Zeichen, etwa bei SORT.
---------------------------------------------------------------------------
II.17. Z�gerlicher Platten-/Diskettenzugriff unter Novell DOS/DR DOS:
========================================================[97-04-06]===
Stichworte: Disk-Deblocking, DEBLOCK=, SCSI, Busmaster-DMA, DBLBUF.SYS,
Floppy-Zugriff, PROMPT.
Warum Novell DOS/DR DOS beim Festplattenzugriff (ohne Cache-Programme
wie NWCACHE und ohne gro�e BUFFERS= Einstellungen) z�gerlicher als MS-DOS
erscheint, kann verschiedene Gr�nde haben.
F�r DR DOS 6.0 galt (laut einem Infopaper 1205.TXT) jedenfalls, da�
jeder Laufwerkszugriff, der von einem hochgeladenen Programm stammte,
�ber einen Zwischenpuffer im konventionellen Speicher gepuffert wurde.
Diese zus�tzliche Kopierma�nahme kostete nat�rlich Zeit, allerdings gab
es daf�r auch keine Probleme mit Busmaster-DMA-Zugriffen (etwa bei den
meisten PS/2) und einigen �lteren SCSI-Festplatten (die noch kein VDS -
Virtual DMA Specification unterst�tzten). F�r Novell DOS 7 gilt diese
Tatsache ebenfalls. Allerdings wurden verschiedene M�glichkeiten
geschaffen, diesen vermeintlichen Geschwindigkeitsnachteil auszub�geln:
Einerseits kann jetzt offenbar mit der undokumentierten CONFIG.SYS
Direktive DEBLOCK= ein Grenzwert f�r das direkte oder gepufferte
Schreiben eingestellt werden (der fr�her bei A000h, in aktuellen
Novell DOS Versionen aber bei FFFFh liegt, d.h. 'au�er Kraft' gesetzt
ist), oder zumindest die Art und Weise dieses Zugriffs beeinflu�t werden.
Niedrigere Werte gehen zu Lasten der Performance. N�heres zu dieser
Direktive in Kapitel III.1.
Andererseits gibt es f�r problematische Kombinationen von Mainboard/Bus/
BIOS/Festplatte/Online-Festplattenkompressor einen speziellen Doppel-
pufferungstreiber DBLBUF.SYS, der bei Bedarf explizit geladen werden
kann (dieser Treiber existierte auch schon bei DR DOS 6.0). Dies geht
nat�rlich zu Lasten der Performance. DBLBUF.SYS mu� in CONFIG.SYS nach
jedem in Frage kommenden Laufwerk geladen werden, darf nat�rlich nicht
hochgeladen werden und belegt ca. 2 KByte. (Allerdings ist mir ein Fall
bekannt, wo NWCACHE auf einem 286 mit lediglich 640KByte mit STACKER
trotz gefordertem und installiertem DBLBUF.SYS nicht aktiviert werden
konnte.)
Um den Floppy-Zugriff - besonders auf langsamen Rechnern - zu beschleu-
nigen, sollten Sie den Wert f�r Look-ahead-Buffer (der undokumentierte
zweite Parameter ss der CONFIG.SYS Direktiven BUFFERS=nn,ss bzw.
HIBUFFERS=nn,ss) erh�hen, siehe Kapitel III.1.
Auch ist der Floppy-Zugriff bei Novell DOS/DR DOS nur scheinbar
langsamer, da im Gegensatz zu MS-DOS beim ersten Zugriff auf das
Medium diverse Daten (Verzeichnis und FAT) direkt eingelesen werden,
die den sp�teren Zugriff dann schneller machen (diesen Unterschied
zwischen MS-DOS und Novell DOS/DR DOS wird der eine oder andere
sicherlich schon an den Prompt-Ausgaben bemerkt haben, wenn er mit
einem PROMPT $p$g Pfad auf Floppies gearbeitet hat).
In Verbindung mit alten Rechnern/BIOSen kann auch der Lesezugriff auf ein
oder mehrere Laufwerke sehr langsam sein. Dies liegt dann daran, da� das
BIOS veraltet ist und nicht alle heute �blichen Funktionen unterst�tzt.
In diesem Fall hilft es (sowohl bei Novell DOS 7, als auch bei DR DOS,
vielleicht auch bei MS-DOS) f�r das jeweilige Laufwerk in CONFIG.SYS den
BIOS-Treiber mit
DEVICE[HIGH]=DRIVER.SYS parameter
zu �berladen (bzw. zu erg�nzen, evtl. reicht daf�r auch schon DRIVPARM=).
Da das alte Laufwerk <old_drive> mit neuen Parametern nun aber �ber
einen neuen Laufwerksbuchstaben <new_drive> bereitgestellt wird (nicht
bei DRIVPARAM=), kann man die Zuordnung danach mit
ASSIGN old_drive=new_drive
wieder auf den alten Laufwerksbuchstaben zur�ckbiegen.
Statt DRIVER.SYS kann evtl. auch ein anderer Fremdtreiber wie Ciriaco
Gar�a de Celis' 2M-XBIOS.EXE, 2M-ABIOS.EXE oder Ontracks Drive-Rocket
oder Disk-Manager ausreichen, die ebenfalls das System-BIOS erg�nzen
oder ersetzen k�nnen.
Bzgl. weiterer Hinweise in Verbindung mit der ebenfalls (stark)
performance-fressenden VERIFY ON Einstellung siehe Kapitel II.14.
Hinweise zu Performance-Problemen bei CD-ROMs siehe Kapitel II.3.
---------------------------------------------------------------------------
II.18. Mit STACKER Hauptspeicher 'virtuell' verdoppeln... [96-04-14]
====================================================================
Stichworte: STACKER, NWCACHE, VDISK, RAM-Disk
Im letzten Jahr (1995-1996) ist viel �ber sog. RAM-Verdoppler-Software
geschrieben worden. Dabei wurde deutlich, da� nichts �ber wirklich
vorhandenen Hauptspeicher geht und da� 'RAM-Verdopplung' durch Online-
Kompression immer nur eine Notl�sung bleiben wird (die unter MS Windows
3.xx manchmal etwas bringt, meist aber nicht effizient ist). Besonders
hervorgehoben sei der unglaubliche weltweite Skandal um das inzwischen
wohl wieder vom Markt verschwundene 'Produkt' SoftRAM, das - nach c't und
anderen Informationsquellen - in erster Linie ein teurer Dummy ist/war.
In Einzelf�llen kann sich der Einsatz eines RAM-Verdopplers trotzdem
lohnen, besonders wenn die folgenden Voraussetzungen gelten:
- Die Software mu� man nicht mehr extra bezahlen ;-)
- F�r die Einrichtung wird kein (oder nur minimal mehr) Speicher
im ersten MegaByte ben�tigt.
- Es geht nicht um Ausf�hrungsgeschwindigkeit, sondern um:
"Trotz akuter Speichernot an allen Ecken und Enden �berhaupt noch
einigerma�en arbeiten k�nnen".
Wenn Sie Novell DOS 7 einsetzen, STACKER bereits installiert haben,
eine RAM-Disk (wie z.B. VDISK) oder einen STACKER-kompatiblen Cache wie
NWCACHE eingerichtet haben, k�nnten sich die folgenden �berlegungen
lohnen. Wenn Sie STACKER nur zu diesem Zweck installieren, lohnt sich
das Ganze mit Sicherheit nicht...
STACKER komprimiert Laufwerke durchschnittlich auf 1:2, d.h. im Mittel
passen doppelt soviele Daten auf ein STACKER-Volume, wie auf ein
normales unkomprimiertes Laufwerk. Dadurch wird 'virtuell' auch der auf
ein komprimiertes Volume verwendete Cache (mit NWCACHE ist das m�glich)
verdoppelt (nicht der f�r das Host-Laufwerk).
Da RAM-Disks wie VDISK, RAMDRIVE oder TDSK ebenfalls von STACKER
komprimiert werden k�nnen, kann auf diese Weise auch die theoretische
Gr��e von RAM-Disks verdoppelt werden (oder mit anderen Worten: Es
wird nur halb soviel XMS-Speicher f�r die RAM-Disk ben�tigt, wie an Daten
drauf pa�t). Nat�rlich lohnt sich die ganze Sache erst, wenn dies den
Verlust, STACKER nun auch noch im Speicher unterbringen zu m�ssen, auf-
wiegt. Bei Computern ist es jedoch h�ufig m�glich, mit viel Flei� und
durch Opfern einiger kleiner Heiligt�mer an anderer Stelle enorm viel
herauszukitzeln.
Da RAM-Disks per s� extrem schnell sind, macht sich der Geschwindigkeits-
verlust f�r die Kompression zwar stark bemerkbar, die Gesamtzeit ist aber
generell noch kurz; bei langsamen (Harddisk-)Laufwerken kann auf recht
schnellen Rechnern sogar ein Geschwindigkeitszuwachs entstehen, wenn die
Kompressionszeit k�rzer ist als die Zeit, die f�r die Speicherung der
Mehrdaten ben�tigt w�rde.
---------------------------------------------------------------------------
II.19. Einstellungen in Novell DOS 7 .INI-Dateien [97-02-24]
============================================================
Stichworte: NWDOS.INI, [COLORS]
In Zukunft wird diese Rubrik die Einstellungsm�glichkeiten der
einzelnen .INI- und .CFG-Konfigurationsdateien von Novell DOS 7 be-
handeln. Dabei wird in erster Linie nur auf Besonderheiten eingegangen,
die nicht offensichtlich sind oder nicht dokumentiert wurden.
Derzeit ist hier nur die [COLORS] Rubrik beschrieben, wie sie in
%NWDOSCFG%\NWDOS.INI vorkommen kann. Die gleichen Einstellungen sind
auch in den undokumentierten Konfigurationsdateien %NWDOSCFG%\COLORS.INI
(bei PNW NET.EXE, falls %NWDOSCFG%\NWDOS.INI nicht existiert) oder
C:\NWDOS\DOS.INI (f�r LOCK.EXE) m�glich. Siehe auch Kapitel II.4.
%NWDOSCFG%\NWDOS.INI:
[COLORS]
# Enth�lt globale Einstellungen, soweit nicht von anderen Gruppen
# �bersteuert.
# Die hier definierten Farben sind Werte von IBM PC Video-Attributen.
# Auf EGA oder VGA im Farbmodus k�nnen alle Farben (0-F) f�r den
# Hintergrund verwendet werden. Mit anderen Video-Karten k�nnen nur 0-7
# verwendet werden.
#
# 0 = Schwarz 8 = Dunkelgrau
# 1 = Blau 9 = Hellblau
# 2 = Gr�n 10 = Hellgr�n
# 3 = Zyan (T�rkis) 11 = Hellzyan (Hellt�rkis)
# 4 = Rot 12 = Hellrot
# 5 = Magenta (Lila) 13 = Hellmagenta (Rosa)
# 6 = Braun 14 = Gelb
# 7 = Wei� (Hellgrau) 15 = Intensives Wei�
#
# Es k�nnen maximal 10 Farbpaletten definiert werden (ColorSet0= bis
# ColorSet9=). Die Default-Farbpalette kann mit CurrentColor= angegeben
# werden. [COLORS] CurrentColor= kann (bei fast allen Programmen mit
# eigenen Gruppen) durch eine lokale CurrentColor= Einstellung �ber-
# steuert werden.
#
# Die Definition der Farbpaletten unterscheidet sich erheblich zwischen
# den einzelnen .INI-Dateien (TASKMGR.INI, TASKMAX.INI und VIEWMAX.INI
# verwenden eine v�llig andere Syntax innerhalb der ColorSetX=
# Direktiven, das Prinzip bleibt jedoch gleich). Hier, in NWDOS.INI,
# werden die Paletten jeweils mit einer Definition des Namens (in
# Anf�hrungszeichen) plus 13 jeweils geklammerten Sets mit (Vordergrund-
# farbe, Hintergrundfarbe) definiert.
# Dabei sind offenbar nur Dezimalzahlen erlaubt. Bei Syntax-Fehlern wird
# entweder der Rest der Zeile ignoriert oder es wird die interne
# Default-Palette gew�hlt (die der "Standard"-Definition entspricht).
# Werden nicht alle Sets angegeben, wird f�r die restlichen offenbar
# die interne Default-Einstellung (entspr. "Standard" belassen).
# Kommanta und Leerfelder zwischen den Sets sind optional, sollten aber
# bis auf die Kommata in den Sets weggelassen werden, da es sein kann,
# da� das SETUP-Programm sonst nicht damit zurecht kommt.
#
# Die Sets im Einzelnen:
#
# SetNr: Bedeutung:
# 1 = Farbe des Haupttextes, auch in eingeblendeten Fenstern
# 2 = Titelleiste des aktiven Fensters
# 3 = Titelleiste eines nicht aktiven Fensters
# 4 = Farbe der Men�texte und Statuszeile und des seitlichen
# Scroll-Balkens, Warnungen
# 5 = Vordergrund=Farbe des Button-Randes und Schatten,
# Hintergrund=Farbe des Button-Umrandungsfeld
# 6 = Eingaben in Men�s, Farbe der Angaben in Auswahlmasken,
# Verbatim-Texte in Hilfe (Beispiele)
# 7 = Gew�hlter, hervorgehobener Men�punkt
# 8 = Nicht aktives Men� im Hintergrund
# 9 = Hotkey-Buchstaben in den Men�s (f�r <Alt>+Buchstabe)
# 10 = Links im Hilfetext (Querverweise)
# 11 = PopUps im Hilfetext (f�r Kurzerl�uterungen)
# 12 = Highlights im Hilfetext (ohne sonstige Funktion)
# 13 = DOSBOOK Kommando
NewUI=On # Pseudographische Oberfl�che (ON|OFF)
# Default ist On, solange die Dar-
# stellung m�glich ist (EGA, VGA, kein
# MEMMAX +V).
# Falls dies nicht m�glich ist, wird Off
# gew�hlt, auch wenn hier On angegeben
# wurde.
# Einige Cirrus-VGA-Adapter haben
# Probleme mit der pseudographischen
# Darstellung. In diesem Fall sollten
# Sie global NewUI=Off w�hlen.
MaxColors = 10 # Anzahl definierter Farbsets
CurrentColor = 0 # Aktuelle Palettennummer aus ColorSetX
# Falls nicht definiert, wird die
# applikationsinterne Einstellung ge-
# w�hlt, die "Standard" entspricht.
ColorSet0 = "Standard" (0,15)(15,1)(15,8)(15,4)(0,15)(0,7) ...
... (15,3)(3,7)(4,7)(12,15)(3,15)(9,15)(2,15)
ColorSet1 = "Monochrom" ...
ColorSet2 = "LCD" ...
ColorSet3 = "Meer" ...
ColorSet4 = "Wiese" ...
ColorSet5 = "Sonnig" ...
ColorSet6 = "Rosa" ...
ColorSet7 = "Kohle" ...
#ColorSet8 = "Plasma" ...
# Zwei selbstdefinierte ergonomische, da flimmerfreie Farbpaletten
# (nicht geeignet f�r Graustufenmonitore):
# "EditMP" empfindet die Einstellungen der Borland IDE-Editore nach
# und ist damit z.B. f�r die EDIT-Gruppe [EDITOR] gut geeignet.
# "HelpMP" empfindet die Farben des 4DOS/NDOS-Hilfemen�s nach
# und ist eine sehr angenehme Einstellung f�r [DOSBOOK]
ColorSet8 = "EditMP" (14,1)(15,8)(15,1)(15,4)(0,1)(0,7) ...
... (15,3)(3,7)(4,7)(15,1)(10,1)(12,1)(2,15)
ColorSet9 = "HelpMP" (0,2)(15,7)(15,8)(15,4)(0,2)(0,7) ...
... (15,0)(8,7)(4,7)(14,2)(6,2)(15,2)(2,15)
# Nun folgen Einstellungen, die nur f�r die einzelnen Anwendungen
# gelten. Meist hei�t die Gruppe genauso wie das jeweilige Programm,
# es gibt aber Ausnahmen. Innerhalb der Rubriken ist fast immer
# CurrentColor= und NewUI= m�glich (undokumentiert). Siehe Kapitel II.4.
...
---------------------------------------------------------------------------
II.20. Nicht erlaubte Zeichen in Dateinamen: [97-05-13]
=======================================================
Stichworte: Semikolon, Klammeraffe, Ausrufezeichen, Bindestrich, Umlaute
Wie Sie sicherlich wissen, sind nicht alle Zeichen in Dateinamen
erlaubt. Die jeweils erlaubten Zeichen h�ngen auch von der DOS-Version
ab. Hier soll - zun�chst noch unvollst�ndig - auf einige Besonderheiten
eingegangen werden:
Zeichen: Name: Bemerkung:
; Semikolon Dieses Zeichen ist grunds�tzlich in
keiner DOS-Version innerhalb von Datei-
namen erlaubt (im FAT-Dateisystem). Bei
den Betriebssystemen der DR-Familie wird
es von jeher zur Einleitung von Pa�w�rtern,
bei 4DOS/NDOS f�r Einschlu�listen ver-
wendet, siehe Kapitel II.9.
@ Klammeraffe, 'at' Dieses Zeichen ist zwar auch innerhalb
von Dateinamen g�ltig, die Benutzung
sollte aber vermieden werden, weil es
sonst zu unn�tigen Schwierigkeiten mit
Kommandos kommen k�nnte, die Listendateien
unterst�tzen, siehe Kapitel II.9.
! Ausrufezeichen Dieses Zeichen ist �blicherweise als
g�ltiges Zeichen in Dateinamen erlaubt,
sollte aber trotzdem vermieden werden,
weil es unter CCI Multiuser DOS nicht
erlaubt ist. Dort dient es dem Kommando-
zeileninterpreter als Trenner zwischen
mehreren Kommandos in einer Zeile, wie
dies intern auch bei Novells COMMAND.COM
realisiert ist, siehe Kapitel II.4. bei
DOSKEY.EXE.
- Bindestrich Der Bindestrich '-' ist zwar auch ein
g�ltiges und recht h�ufig verwendetes
Zeichen, sollte aber m�glichst nicht
verwendet werden, da er mit dem ISO-9660
Standard (von CD-ROMs) kollidiert, weshalb
er von CD-Writer-Software oft durch einen
Unterstrich '_' ersetzt wird.
������� Umlaute und 'sz' Viele Sonderzeichen und Umlaute sind zwar
g�ltige Zeichen f�r Dateinamen, sollten
aber aus verschiedenen Gr�nden vermieden
werden, weil es beim Betrieb im Netz,
bei der Umstellung auf lange Dateinamen
(VFAT) oder bei falschen Landeseinstel-
lungen Probleme mit dem Zugriff auf be-
stimmte Zeichen geben kann, die z.B. in
anderen L�ndern nicht direkt �ber die
Tastatur erreichbar sind, die in anderen
Zeichens�tzen durch v�llig kryptische
Zeichen ersetzt werden, usw. Siehe auch in
Kapitel VI.7.
' ' Leerfeld Zwar waren Leerfelder (auch schon lange vor
Einf�hrung von MS Windows95 Long-Filenames)
auf API-Ebene durchaus g�ltige Zeichen in
Dateinamen (wie Novells COMMAND.COM mit MD
und RD beweist, siehe Kapitel II.11.), sie
sollten aber trotzdem nicht verwendet
werden, da die meisten Anwendungsprogramme
und auch der Kommandointerpreter in der
Regel nicht damit klar kommen.
---------------------------------------------------------------------------
II.21. Physik der Verzeichniseintr�ge unter Novell DOS: [97-04-29]
==================================================================
Stichworte: DELWATCH, UNDELETE, PASSWORD, DR DOS 6.0 Owner-IDs,
IBM OS/2 EA-Handles, MS Chicago, MS Windows95 LFN-Support
Entgegen landl�ufiger Meinung ist Microsofts LFN-Support keineswegs
so ganz kompatibel in das bisherige FAT-Konzept integriert worden,
wie dies in der Literatur gerne beschrieben wird. Nicht zuletzt solche
Punkte aus meiner Sicht unfairer Machenschaften haben im Endeffekt
zur Einstellung der Weiterentwicklung von Novell DOS 7 gef�hrt.
Gl�cklicherweise sinnt man bei Caldera schon �ber L�sungen f�r
diese Probleme.
Zum Beispiel existieren seit MS Windows95 einige Inkompatibilit�ten
mit speziellen, in das FAT-System integrierten F�higkeiten, die die
ehemalige Konkurrenz "DR DOS" sp�testens seit Version 3.40 (von 1987)
bot, und die jetzt zu unn�tigen Schwierigkeiten bei der Weiterentwicklung
von Calderas OpenDOS f�hren. Wie man unschwer aus der unten aufgef�hrten
Abbildung ableiten kann, h�tte Microsoft durchaus - und das ohne
Performance-Einbu�en - mit einem etwas besseren Design bei der
Verwendung dieser bereits anderweitig belegten Bereiche eine Koexistenz
der Funktionen der "DR DOS"-Familie mit denen von MS Windows95 erreichen
k�nnen. Zur eindeutigen Unterscheidung der unterschiedlichen Belegungs-
varianten h�tte man z.B. eine andere Bit-Belegung der LFN-Sequenznummer
in Verbindung mit dem Typ-Info-Byte benutzen k�nnen, schlie�lich mu�ten
ja f�r Windows95 die Festplatten-Utilities sowieso angepa�t werden;
stattdessen mu� jetzt ein alternatives Betriebssystem ge�ndert werden,
um weiterhin kompatibel zu FAT zu bleiben. Oder man h�tte die neuen
Informationen auch ganz in den ja sowieso zus�tzlich ben�tigten Ver-
zeichniseintr�gen f�r LFNs unterbringen k�nnen.
Um Programmierer, die Microsofts LFN-Features ausnutzen wollen und
trotzdem - soweit wie dies jetzt �berhaupt noch m�glich ist -
Kompatibilit�t zur DR DOS Familie wahren wollen, von der wirklichen
Belegung dieser Strukturen in Kenntnis zu setzen, hier eine �bersicht
der Belegung der Verzeichniseintr�ge. Weitere Detailinformationen
zur L�schverfolgung (DELWATCH.EXE, UNDELETE.EXE) sowie zum Pa�wort-
schutz (PASSWORD.EXE) finden sich in den jeweiligen Abschnitten in
Kapitel II.4.
Ernsthaft kollidierende Doppelbelegungen sind mit '!!!' bei dem
jeweils zuletzt ver�ffentlichten Betriebssystem gekennzeichnet.
+-------------------------------+-----------+---+---+---+-------+
| | | | |Del| |
| | | | |Chr|Pa�wort|
| Name |Erweiterung|Att|Typ| / | / |
| (8 Zeichen) |(3 Zeichen)| | |Mil|Create-|
| | | | |Sek| Zeit |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh
| | | | |
| In der DELWATCH-L�schverfolgung --+ | | |
| stehende Dateien haben zus�tzlich | | | |
| das Volume-Attribut gesetzt, was mit | | | |
| Windows95 LFN-Eintr�gen kollidiert. | | | |
| | | | |
| Pa�wortgesch�tzte Dateien oder Ver- --+ | | |
| zeichnisse haben ein gesetztes Hidden- | | | |
| Attribut, werden aber ganz normal an- | | | |
| gezeigt. Nat�rlich hat das Hidden- | | | |
| Attribut keinen Einflu� auf den | | | |
| Pa�wortschutz. | | | |
| | | | |
| !!! MS Windows95: Die Attribut- --+ | | |
| Kombination 0Fh (Read-Only + Hidden + | | |
| System + Volume) von nun auch zur | | |
| Kennzeichnung von LFN-Eintr�gen benutzt. | | |
| | | |
| MS Windows95: Reserviert zur Kennzeichung -+ | |
| des Typs von LFN-Eintr�gen, f�r Chicago | | |
| waren zwei Typen definiert: LONG_NAME_COMP | | |
| (00h) und LONG_CLASS (??h). Im letzten | | |
| Fall enth�lt der LFN-Eintrag Klassen- | | |
| informationen in einem anderen Format | | |
| (16 Bytes), ob er aber auch von Windows95 | | |
| benutzt wird, ist nicht gekl�rt. �blich | | |
| ist jedenfalls 00h. | | |
| | | |
| !!! Dieses Byte wird wahrscheinlich in -+ | |
| Zukunft von OpenDOS benutzt werden werden, | |
| um trotz der jetzt bestehenden Konfusion | |
| in Zukunft wieder Kompatibilit�t inklusive | |
| eigenem LFN-Support (und mehr) zu integrieren. | |
| Default ist 00h. | |
| | |
| Normalerweise 00h. Ab Novell DOS 7 enth�lt --+ |
| dieses Feld den ersten Buchstaben eines Datei- | |
| namens nach dem L�schen, der so von UNDELETE | |
| automatisch wiederhergestellt werden kann. | |
| Wurde eine Datei mit DELPURGE aus der | |
| L�schverfolgung entfernt, so steht hier der | |
| Wert E5h, der UNDELETE daran hindert, die | |
| Datei auf herk�mmliche Art wieder zu ent- | |
| l�schen. Setzt man dies manuell auf 00h zur�ck,| |
| ist die konventionelle Entl�schmethode m�glich.| |
| | |
| !!! MS Windows95: Millisekunden der Datei- --+ |
| erzeugung (10 Millisekunden-Raster). Bei |
| LFN-Eintr�gen enth�lt dieses Feld die Pr�f- |
| summe f�r den Eintrag des alten Dateinamens. |
| |
| Bei DR DOS, Multiuser DOS, Novell DOS und Caldera --+
| OpenDOS steht hier 0000h f�r ungesch�tzte Eintr�ge |
| bzw. ein unidirektional verschl�sseltes Datei- bzw. |
| Verzeichnispa�wort. |
| |
| !!! MS Windows95: Zeit der Dateierzeugung --+
|
+--- Erstes Zeichen einer gel�schten Datei, normalerweise E5h,
| bei DELWATCH von DR DOS 6.0, Novell DOS 7 und Caldera
| OpenDOS 7.01 jedoch 05h, solange die Datei in der L�sch-
| verfolgung steht.
|
+--- !!! MS Windows95: Enth�lt bei LFN-Eintr�gen die
Sequenz-Nummer des Verzeichniseintrags in Bits 0-4 (Eins-basiert)
und im letzten Eintrag ist Bit 6 als Endmarke gesetzt.
Damit ergeben sich die Kombinationen 01h..1Fh und 41h..5Fh,
die sich leider nicht eindeutig von den anderen bisher
verwendeten Werten unterscheiden lassen.
+-------+-------+-------+-------+-------+-------+---------------+
|Org-Del|OwnerID|Pa�wort| Std- | Std- | | |
| Zeit |Org-Del|Rechte | Zeit | Datum |Start- | Dateil�nge |
|RecSiz/|Datum /| / | o. | o. |Cluster| in Bytes |
|Create-|Zugriff| EA- | Del- | Del- | | |
| Datum | Datum |Handle | Zeit | Datum | | |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh
| | | | | |
| | | +-------+ +-- MS Windows95:
| | | | Bei LFN-Eintr�gen 0000h.
| | | |
| | | +-- Befindet sich eine Datei in der
| | | DELWATCH L�schverfolgung von Novell DOS
| | | oder Caldera OpenDOS 7.01 (nicht jedoch
| | | DR DOS 6.0), so steht hier das Datum
| | | und die Zeit des L�schzeitpunktes,
| | | nicht der Stempel der letzten �nderung.
| | |
| | +-- DR DOS, CP/M, Multiuser DOS, Novell DOS, Caldera
| | | OpenDOS: Zugriffssperren f�r pa�wortgesch�tzte
| | | Dateien oder Verzeichnisse. In drei Klassen
| | | 'World', 'Group' und 'Owner' gibt es jeweils
| | | vier Zugriffssperren 'Read' (01h), 'Write'
| | | (02h), 'Delete' (04h) und 'Execute' (08h).
| | | 'Execute' wird derzeit nur von FlexOS verwendet
| | | und sonst wie 'Read' behandelt. Singleuser-
| | | Varianten dieser Betriebssysteme benutzen alle
| | | drei Klassen simultan (d.h. hier sind 0000h,
| | | 0111h, 0555h, und 0DDDh �blich), Multiuser-
| | | Varianten je nach Ebene.
| | |
| | +-- CP/M: Zus�tzlich werden noch die Attribute
| | | F1 'Modify default open rules' (80h),
| | | F2 'Partial close default' (40h),
| | | F3 'Ignore Close Checksum Error' (20h) und
| | | F4 'Disable Checksums' (10h) benutzt
| | |
| | +-- !!! (MS)/IBM OS/2: Extended-Attribut Handle
| | |
| | +-- ??? MS Windows95b FAT32-Partitionen: High-Word
| | des Start-Clusters (reine Spekulation!!!)
| |
| +-- DR DOS 6.0, FlexOS (und Multiuser DOS???): Owner-IDs;
| | dabei in 12h den Wert der User-ID, und in 13h den
| | Wert der Group-ID.
| |
| +-- Novell DOS 7, Caldera OpenDOS 7.01 DELWATCH: Zwischen-
| | gespeichertes Datum der letzten �nderung bei gel�schten,
| | aber in der L�schverfolgung stehenden Dateien oder
| | Verzeichnissen.
| |
| +-- MS Windows95: Mit ACCDATE= Last-Access-Datum
| Datum des letzten Zugriffs
|
+-- FlexOS: Record-Gr��e
|
+-- Novell DOS 7, Caldera OpenDOS 7.01 DELWATCH: Zwischen-
| gespeicherte Zeit der letzten �nderung bei gel�schten, aber
| in der L�schverfolgung stehenden Dateien/Verzeichnissen.
|
+-- !!! MS Windows95: Datum der Dateierzeugung
MS Chicago/Windows95 LFN-Eintr�ge mit langen Dateinamen in Unicode
(Typ LONG_NAME_COMP=00h)
+---+---------------------------------------+---+---+---+-------+
| | | | | | |
| | | | | | Langer|
|LFN| Langer Dateiname (1/3) |Att|Typ|CRC| Datei-|
|SNo| |0Fh|00h| | name |
| | | | | | | | | | (2/3) |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh
+---------------------------------------+-------+---------------+
| | | |
| | | Langer |
| Langer Dateiname (Fortsetzung 2/3) | 0000h | Dateiname |
| | | (3/3) |
| | | | | | | | |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh
MS Chicago LFN-Eintr�ge mit Klasseninformationen (Typ LONG_CLASS=??h)
(ob diese auch von MS Windows95 verwendet werden, ist nicht gekl�rt)
+---+---------------------------------------+---+---+---+-------+
| | | | | | |
| | | | | |Klassen|
|LFN| Klasseninformation (1/2) |Att|Typ|CRC| info |
|SNo| |0Fh|??h| | (2/2) |
| | | | | | |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+00h 01h 02h 03h 04h 05h 06h 07h 08h 09h 0Ah 0Bh 0Ch 0Dh 0Eh 0Fh
+---------------+-----------------------+-------+---------------+
| | | | |
| Klasseninfo | | | |
| (Forts. 2/2) | Reserviert | 0000h | Reserviert |
| | | | |
| | | | |
| | | | | | | | | | | | | | | | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
+10h 11h 12h 13h 14h 15h 16h 17h 18h 19h 1Ah 1Bh 1Ch 1Dh 1Eh 1Fh
Einige Beta-Versionen von MS-DOS 4 benutzten ein (unbekanntes) Wort
innerhalb dieser Strukturen, um die gew�nschte Codeseite zur Anzeige
der jeweiligen Datei unterzubringen (im Prinzip keine schlechte Idee,
siehe INT21h/3303h, INT21h/3304h, INT21h/5703h und INT21h/5704h). In
Release-Versionen wurde dieses Feld jedoch nie zu diesem Zweck genutzt.
Die f�r den Pa�wortschutz verwendeten Bereiche werden wahrscheinlich
auch noch von heutigen Multiuser DOS-Betriebssystemen, etwa von
CCI Multiuser DOS 7.22 oder von IMS Multiuser DOS und IMS REAL/32
verwendet. �berpr�ft habe ich dies jedoch noch nicht.
Achtung: Die inkompatibilen FAT32-Partitionen von MS Windows95b ver-
wenden zumindest noch zwei weitere Bytes f�r das High-Word des Start-
Clusters. Leider ist mir noch unbekannt, welche Bytes das sind...
###########################################################################
###########################################################################
III. CONFIG.SYS:
================
---------------------------------------------------------------------------
III.1. Undokumentierte Direktiven und Eigenschaften: [97-05-21]
===============================================================
Stichworte: CONFIG.SYS, Reihenfolge, maximale Zeilenl�nge, alle
dokumentierten und undokumentierten Direktiven, besonders:
SWITCHES=/N, NUMLOCK, YESCHAR, [COMMON], TIMEOUT, GETKEY,
ERROR, ONERROR, BBB.
DR DOS 6.0, Novell DOS und Caldera OpenDOS suchen vor einer evtl.
auszuwertenden CONFIG.SYS Datei nach einer Datei namens DCONFIG.SYS
(der Name stammt von 'Laufwerk D:', da diese Funktion in erster Linie
f�r Online-Festplattenkompressoren wie STACKER etc. gedacht ist, wo
die urspr�ngliche CONFIG.SYS Datei auf Laufwerk D: statt auf Laufwerk
C: zu finden ist). Wird eine solche Datei gefunden, so wird eine
evtl. ebenfalls vorhandene CONFIG.SYS Datei ignoriert. (Andere
M�glichkeiten, die Konfiguration aus einer alternativen Datei zu laden,
finden sich bei CHAIN= oder in Kapitel II.4. bei SYS /DR:ext.)
Bez�glich der Namenswahl ist �brigens interessant, da� Multiuser DOS
statt CONFIG.SYS generell verwandte Datei CCONFIG.INI auswertet.
Im Gegensatz zu MS-DOS ist bei Novell DOS die Reihenfolge der Anweisun-
gen in der Datei CONFIG.SYS sehr wichtig. Der Parser arbeitet die Datei
(bis auf wenige Ausnahmen wie etwa SWITCHES=) streng nach dem vorgege-
benen Verlauf durch, d.h. beginnt in der ersten Zeile und verzweigt
entsprechend evtl. GOSUB=, SWITCH=, CHAIN= etc. Anweisungen. (Bei MS-DOS
gilt das im Prinzip zwar auch, aber es gibt sehr viele undokumentierte
Ausnahmen von dieser Regel, so da� manchmal sehr seltsame Dinge pas-
sieren, z.B. werden dort DEVICE= Befehle immer vor INSTALL= Befehlen
ausgef�hrt, vgl. Kapitel III.7. und V.7.).
Nat�rlich gibt es viele Direktiven, die nicht sofort wirksam werden,
sondern erst in dem Moment, wenn der Kommandoprozessor geladen wird
(teilweise aber auch schon bei INSTALL[HIGH]=).
Um den generellen Unterschied zusammengefa�t zu erkl�ren, l��t sich
sagen, da� DR DOS und Novell DOS zur Auswertung der CONFIG.SYS einen
echten Interpreter verwenden, MS-DOS und PC-DOS hingegen eine Art
Pre-Compiler, wobei beides Vor- und Nachteile hat.
Die CONFIG.SYS Datei, die auch gr��er als 64 KByte lang sein kann, wird
�brigens nicht komplett auf einmal in den Speicher geladen und dort
abgearbeitet, sondern nach und nach in einen internen 8 KByte gro�en
Zwischenpuffer geladen, aus dem dann Zeile f�r Zeile herausgelesen wird
(nach GOTO= und GOSUB= wird die Datei offenbar neu eingeladen). Da die
Behandlung aber als Ganzes nicht streng zeilenweise funktioniert, ist
trotzdem eine Art Online-Editierung (etwa INSTALL=c:\nwdos\edit.com
c:\config.sys) ausgeschlossen. (Bei MS-DOS/PC-DOS wird die CONFIG.SYS
Datei komplett in den Speicher geladen, andernfalls w�ren MS-DOS-konforme
Boot-Men�s trotz obiger Besonderheiten in der Bearbeitungsreihenfolge
nicht realisierbar, vgl. Kapitel III.7. und V.7.)
�brigens gibt es von Bert Sch�nw�lder eine interessante Erg�nzung zu
Novells eigenen Boot-Men�s: 'Bert's Boot Box' (BBB v1.0 von 1995-1996)
erlaubt eine �bergreifende Men�auswahl mit Check-Boxen, Radiobuttons,
etc. sowie das Auswerten von Bedingungen und das Setzen von Vorab-
Umgebungsvariablen. Dieses Utility arbeitet als eine Art Pre-Prozessor
f�r die von Novell DOS in den Speicher geladene CONFIG.SYS Datei und
wertet zur Gestaltung seiner Men�s u.a. eine Meta-Sprache (versteckt
in CONFIG.SYS Kommentaren) aus. Trotz der trickreichen Einbettung ins
System ist die Benutzung leider nicht ganz frei von Einschr�nkungen und
Inkompatibilit�ten, z.B. darf die CONFIG.SYS nicht gr��er als 8 KByte
sein, und Sprungziele d�rfen nur Vorw�rtsreferenzen enthalten.
Die maximale Zeilenl�nge f�r CONFIG.SYS Anweisungen betr�gt bei
Novell DOS 255 Zeichen, statt der sonst meist �blichen 128 oder noch
weniger Zeichen (�ltere MS-DOS Ausgaben akzeptierten nur 31 Zeichen).
Ob alle Ihre Treiber (per DEVICE= etc.) allerdings mit solchen �ber-
l�ngen zurecht kommen, ist fraglich. Bei der �bergabe an Treiber durch
diese Begrenzung abgeschnittene Parameter werden ignoriert, genauso wie
auch generell eventuell �berstehende Reste von Zeilen, die selbst die
Maximall�nge von 255 Zeichen noch �berschreiten.
Nat�rlich werden per INSTALL= etc. geladenen Treibern nach wie vor
maximal 127 Zeichen als Kommandozeile �bergeben, ansonsten w�rde ja
der Programmkopf solcher Treiber �berschrieben.
Gegen�ber der Vorg�ngerversion (als auch gegen�ber der Konkurrenz MS-DOS)
gibt es eine Vielzahl von Verbesserungen, die unverst�ndlicherweise zum
gr��ten Teil nicht oder nur sehr oberfl�chlich dokumentiert sind. Diese
Erweiterungen erlauben eine �u�erst flexible Handhabung von Mehrfach-
konfigurationen und ein effektives Fehlermanagement. Auf den ersten Blick
erscheint die Methode, mit der bei DR DOS und Novell DOS Boot-Men�s
behandelt werden, etwas schwerf�llig. Allerdings kann man schon mit den
offiziellen Direktiven - bei entsprechender Strukturierung - mehr als nur
alle M�glichkeiten von MS-DOS so nachbilden, da� eine AUTOEXEC.BAT f�r
beide Systeme identisch aussehen k�nnte (besonders bez�glich der Variable
%CONFIG%). Trotzdem hat man bei Novell DOS noch wesentlich mehr
Flexibilit�t (das Sprachniveau kann man fast mit BASIC gleichsetzen
und geht teilweise �ber die M�glichkeiten der Batch-Sprache hinaus!).
Die folgenden Abschnitte werden nun alle CONFIG.SYS Direktiven be-
leuchten, wobei allerdings nur dann ausf�hrlich auf Besonderheiten
eingegangen wird, wenn die Dokumentation mi�verst�ndlich, unvollst�ndig
oder schlichtweg nicht vorhanden ist. Ansonsten wird nur kurz die
vollst�ndige Syntax dargestellt.
Fr�here Versionen von DR DOS unterst�tzten auch noch verschiedene
andere undokumentierte Direktiven. Mehr hierzu siehe DRDOS6UN.TXT.
Traditionell werden CONFIG.SYS Direktiven mit einem Gleichheitszeichen
von ihrem Wert getrennt. Mittlerweile sind aber viele Direktiven hinzu-
gekommen, die eine bestimmte Funktion ausf�hren, anstatt eine Einstellung
vorzunehmen. Das Gleichheitszeichen ist hier nicht besonders intuitiv
und kann in Ausnahmef�llen sogar kleinere Probleme bereiten (etwa bei
ECHO[=] (Kapitel III.3.) oder YESCHAR[=]). Deshalb ist die Angabe des
Gleichheitszeichen bei Novell DOS zwar �berall m�glich, aber optional.
Dies gilt �brigens auch f�r die Kommandozeile und Batchjobs mit Novells
COMMAND.COM, siehe Kapitel II.11.
Die einzelnen Werte d�rfen mit Leerfeldern, TABs oder Komma getrennt
werden. Vor einem Wert, der ein bestimmtes ASCII-Zeichen spezifizieren
soll, d�rfen nach einem Komma keine Leerfelder folgen, sonst werden
diese Leerfelder als das anzugebende ASCII-Zeichen interpretiert (z.B.
bei TIMEOUT=).
Bei Parametern, die Zeichenketten (z.B. Dateinamen oder Marken) als
Argument erwarten, ist zus�tzlich noch '/' als Trennzeichen zwischen
den Parametern erlaubt. Normale Werte zu Parametern m�ssen mit ':'
zwischen Parameter und Wert getrennt werden (etwa bei DRIVPARM=).
Au�erdem haben die Zeichen '>', '<', '|' und andere in CONFIG.SYS noch
keine Bedeutung f�r Umleitungen, und k�nnen daher problemlos z.B. f�r
die Gestaltung von Men�s mittels ECHO= herangezogen werden. Das gilt
auch f�r die meisten anderen Zeichen. Ung�ltige Zeichen werden jedenfalls
einfach ignoriert.
Mu� auf Dateien zugegriffen werden, die mit Pa�w�rtern gesch�tzt sind,
mu� auch hier das Pa�wort mit Semikolon getrennt angegeben werden.
Sofern es nicht zu Mi�deutung kommen kann, sind am Ende jeder Zeile
jeweils beliebige Kommentare erlaubt, solange sie wie normale Parameter
von den echten Argumenten getrennt werden.
i. Allgemeine Einstellungen:
----------------------------
Direktiven, die Werte erwarten, die aber nicht angegeben werden, melden
sich mit einer Fehlermeldung. L��t man die Direktive jedoch komplett
weg, arbeitet Novell DOS mit internen Default-Einstellungen. Liegt ein
Wert au�erhalb des zul�ssigen Wertebereichs, so wird der Wert normaler-
weise stillschweigend auf- oder abgerundet. Nur in Einzelf�llen kommt
es zu einer Fehlermeldung. Nicht erkannte Direktiven f�hren ebenfalls
zu einer Fehlermeldung. Im Verlauf der CONFIG.SYS Bearbeitung d�rfen
Direktiven durchaus auch mehrfach vorkommen, die jeweils letzte Ein-
stellung gilt dann. Wurden dabei bei Direktiven, die die Angabe mehrerer
Parameter erlauben, zun�chst zus�tzliche Parameter angegeben, bei
sp�teren Vorkommen der Direktive jedoch weggelassen, bleiben die
hierf�r bereits eingestellten Werte erhalten und werden nicht wieder
auf Default-Einstellungen zur�ckgesetzt.
BREAK [=] [ON|OFF] <ON>
BREAK=ON macht das System geringf�gig langsamer (wirklich
minimal, au�er bei Batchjobs), ist aber trotzdem zu
empfehlen, damit man Programme im Fehlerfall mit
<Ctrl>+<c> abbrechen. Das klappt aber nicht bei allen
Programmen und hat noch den Nachteil, da� das Programm
daf�r sorgen mu�, da� das System wieder aufger�umt wird.
Geschieht dies nicht und dr�ckt man im falschen Moment
<Ctrl>+<c>, so kann es zu Abst�rzen und Datenverlust
kommen (z.B. AUTOCAD R11). (Viele Editore etc. unter-
st�tzen die alte WordStar-Belegung aus CP/M Zeiten, dort
ist <Ctrl>+<c> mit <PageDown> belegt.)
Wenn Sie den erweiterten Tastaturtreiber K3PLUS bzw.
FreeKEYB (zu beziehen �ber mich) einsetzen, k�nnen Sie
problemlos "BREAK off" verwenden, denn K3PLUS bietet
eine M�glichkeit (sog. versch�rftes <Ctrl>+<Break>),
diese Einstellung bei Bedarf �ber eine spezielle Tasten-
kombination umzuschalten.
Bez�glich des COMMAND.COM Kommandos BREAK und einer
Beispiell�sung f�r Batchjobs siehe auch Kapitel II.11.
BUFFERS [=] nn[,ss] [comments] nn=3..99, <3, 5 oder 15>
HIBUFFERS [=] nn[,ss] [comments] ss=1..99, <0>
Die Dokumentation erw�hnt nur die M�glichkeit, Puffer nn
mit BUFFERS= einzurichten. Trotzdem ist es auch bei
Novell DOS m�glich, zus�tzlich noch 'Look-Ahead-Buffer',
d.h. die Anzahl der Sektoren ss pro Schreib/Lesean-
forderung anzugeben (wie von MS-DOS gewohnt). Dies wird
nicht nur syntaktisch akzeptiert, sondern ist auch mit
der entsprechenden Funktionalit�t versehen. Diese Angabe
ist optional. Standardm��ig werden werden keine 'Look-
Ahead-Buffer' eingerichtet, was der Einstellung ss=0
entsprechen w�rde, die allerdings syntaktisch nicht
akzeptiert wird. Auf langsamen Rechnern k�nnen Sie durch
Angabe eines Wertes f�r ss eine starke Beschleunigung
insbesondere der Floppies erreichen, auf schnelleren
Rechnern ist ein echter Cache wie NWCHACHE allemal
effektiver. Andere als die erlaubten Werte werden zur�ck-
gewiesen. (Evtl. spielt die ss Angabe auch im Zusammen-
hang mit DBLBUF.SYS eine Rolle???)
Die Default-Angabe h�ngt auch vom verf�gbaren Speicher-
platz ab: Sollte Ihr System weniger als 128 KByte RAM
besitzen, werden nur drei Puffer eingerichtet, sonst
f�nf, f�r gro�e Platten offenbar auch 15. Puffer werden
nach M�glichkeit automatisch in die HMA oder den oberen
Speicher verlagert (DOS=HIGH,UMB), die Verwendung der
alten DR DOS Direktive HIBUFFERS= ist daher auf den
ersten Blick obsolet. Trotzdem wird diese mit gleicher
Syntax weiterhin unterst�tzt (ist allerdings nun
undokumentiert); die interne Bearbeitung weicht leicht
von BUFFERS= ab, weil hier nur 'Hi'-Puffer eingerichtet
werden (nach M�glichkeit in der HMA, sonst in UMBs bei
DOS=HIGH,UMB bzw. HIDOS=ON).
Ein Puffer belegt 528 Bytes (plus einige Bytes f�r die
Verwaltungsstrukturen) und kann darin 512 Bytes Daten
speichern. W�hrend der CONFIG.SYS sind die vordefinierten
Puffer alle einzeln allokiert. Bei �nderung der Sektor-
zahl kann sich der Speicherbedarf jedoch vervielfachen.
Daher sollte man diese Angabe stark reduzieren (etwa 3
oder 4), sobald man mit einem Platten-Cache wie NWCACHE
arbeitet. Ein Cache ist nicht nur effektiver, sondern
die Performance wird durch zu hohe BUFFERS= Werte sogar
wieder gedrosselt, da erstens weniger freier Arbeits-
speicher verf�gbar ist und zweitens eine doppelte
Pufferung stattfindet. Ohne Cache sind meist Werte
zwischen 20 und 30 angebracht.
Es mag einige wenige, unsauber programmierte Programme
geben, die die Puffer direkt ansprechen. Liegen die
Puffer dann in der HMA, so f�hrt dies h�chstwahrschein-
lich zum Absturz des Rechners, wenn die Adre�leitung A20
abgeschaltet sein sollte (was allerdings sehr unwahr-
scheinlich ist). Manche Harddisk-Controller erfordern
ebenfalls einen Puffer im nicht gemappten, konventio-
nellen Speicher, siehe auch bei DEBLOCK=. Normalerweise
sind keine Probleme zu erwarten.
Ab DR DOS 6.0 werden bei BUFFERS= zwei Parameter ausge-
wertet, bei DR DOS 3.4x und 5.0 wurde nur ein Parameter
verwendet.
Die mit HIBUFFERS= vergleichbare bei MS-DOS 7
(MS Windows95/Chicago) eingef�hrte Direktive BUFFERSHIGH=
wird von Novell DOS 7 (Update 15) nicht unterst�tzt, ist
aber - wie ersichtlich - auch �berfl�ssig.
COUNTRY [=] phonecode, codepage, [d:\[path]]\COUNTRY.SYS
Die Default-Einstellung ohne diese Angabe ist vom je-
weiligen Rechner und DOS abh�ngig, i. allg. werden
dann jedoch amerikanische Einstellungen gew�hlt
(was COUNTRY=1,437,C:\COUNTRY.SYS entspr�che).
F�r Deutschland sollte man deshalb
COUNTRY=049,437,c:\nwdos\country.sys
nicht vergessen. Die Angabe der beiden Codes sollte
dreistellig erfolgen (obwohl das bei Novell DOS nicht
notwendig ist). Mehr zum Thema landessprachliche
Unterst�tzung in Kapitel II.16.
Achtung:
Die Angabe der Codeseite ist im Rahmen der Auswahl der
in COUNTRY.SYS f�r das jeweilige Land zugeordneten
Codeseiten (�blicherweise zwei) zwar wahlfrei, sollte
aber die tats�chlichen Gegebenheiten zum Zeitpunkt der
Bearbeitung von COUNTRY= wiederspiegeln.
Da dies �blicherweise der Hardware-Codeseite f�r Anzeige
(Main-BIOS und Grafikkarten-BIOS) und Drucker entspricht
(die DOS beide nicht �berpr�fen kann), mu� diese Angabe
�berhaupt erst vorgenommen werden und sollte - in den
allermeisten F�llen (USA, West-Europa) - Codeseite 437
entsprechen. Sollten sich die Codeseiten von Bildschirm
und Drucker unterscheiden, m�ssen Sie sich f�r das be-
vorzugte Medium (i. allg. die Anzeige) entscheiden.
DOS w�hlt auf der Grundlage dieser Einstellung die
landesspezifischen Informationen aus der COUNTRY.SYS
Datei aus.
Wenn Sie sp�ter keine Codeseitenunterst�tzung einrichten
oder verwenden wollen (DISPLAY.SYS, PRINTER.SYS, MODE),
kann DOS f�r diese Ger�te auch keine andere Codeseite
forcieren, und nimmt die mit COUNTRY= eingestellte
Codeseite einfach global an (z.B. auch bei CHCP), auch
wenn dies nicht den wirklichen Tatsachen entspricht!
Wenn Sie hier eine andere Codeseite als die tats�chlich
aktive Codeseite angeben, wird eine Synchronisation mit
den wirklichen Verh�ltnissen erst dadurch erreicht, da�
Sie bei aktivierter Codeseitenunterst�tzung mit CHCP auf
eine *andere* Codeseite umschalten, denn dabei werden
die aktivierten Ger�te mit den neuen und nun stimmigen
Font- und Zeichensatz-Informationen versorgt.
Bis dahin zeigt z.B. auch MODE CODEPAGE /STATUS an,
da� noch keine Codeseite f�r das jeweilige Ger�t geladen
wurde.
Die Angaben f�r die Hardware- und vorbereiteten Code-
seiten basieren hingegen auf den Einstellungen bei der
Installation von DISPLAY.SYS, PRINTER.SYS, MODE CODEPAGE
PREPARE oder werden zu 437 angenommen.
Dieser Sachverhalt wird in vielen B�chern falsch
geschildert und auch einige modernere Setup-Programme
(von Microsoft) installieren hier immer wieder die
Codeseite 850, was �blicherweise nicht korrekt oder
zumindest unsauber ist!
Viele Applikationen gestalten Ihre Ausgaben in Ab-
h�ngigkeit von der vom System zur�ckgelieferten
Codeseite, mit der Folge von unsch�nen Ergebnissen,
wenn diese Information nicht mit den Tatsachen �ber-
einstimmt.
Daher sollten Sie - von speziellen bewu�ten T�uschungs-
ma�nahmen abgesehen - hier unbedingt die korrekte
Einstellung �berpr�fen und ggf. auf 437 um�ndern
(wenn dies der Hardware-Codeseite entspricht), auch
wenn Sie sp�ter mit Codeseite 850 arbeiten wollen!
Es gibt eigentlich keinen Grund, hier Codeseite 850
vorzugeben, nur weil Sie sp�ter - nach Einrichtung
der Codeseitenunterst�tzung - mit dieser Codeseite
arbeiten wollen. Das System bekommt diese �nderung
schlie�lich sowieso in dem Moment mit, wo Sie mit
CHCP auf diese Codeseite umschalten; also genau zu
dem Zeitpunkt, ab dem eine falsche Einstellung durch
Neusynchronisation korrigiert w�rde. Ohne aktivierte
Codeseitenunterst�tzung w�rde diese Diskrepanz bestehen
bleiben.
(Lediglich f�r den Long-Filename-Support von MS-DOS 7
mag es - rein theoretisch - annehmbar sein, bis zu
diesem Zeitpunkt quasi unter falscher Flagge zu laufen,
daf�r aber schon w�hrend der CONFIG.SYS korrekte
Zuordnungstabellen zu UniCode eingestellt zu haben
(ob dies �berhaupt daran gekoppelt ist, ist nicht
gesichert). Da dort aber die Codeseitenunterst�tzung
(unter dem GUI) sowieso funktionslos ist, w�re dies
aber auch wieder nur ein Grund mehr, bei diesem Betriebs-
system sofort mit CHANGECP auf die Codeseite 437 umzu-
konfigurieren. F�r Novell DOS 7 ist diese �berlegung
jedenfalls ohne Belang. Bei KEYB k�nnen Sie ebenfalls
explizit eine Codeseite angeben.)
Die Angabe dieser Direktive kostet keinen zus�tzlichen
Speicherplatz, da das System die Landesinformationen
sowieso bereitstellt (nur m�glicherweise f�r das falsche
Land).
FCBS [=] [mm [, nn]] [comments] mm=0..255 <1 oder 4>,
0<=nn=<=mm <0??? oder 1>
Diese Direktive erlaubt es, die Anzahl der System-
Dateisteuerbl�cke (System FCBs) anzugeben, die das
System zur Wahrung der Kompatibilit�t mit Applikationen,
die FCBs (File Control Blocks) benutzen, reserviert.
FCBs werden in erster Linie f�r alte Programme ben�tigt,
die noch die CP/M-Dateioperationen verwenden. Trotzdem
sind auch heute FCBs keineswegs �berfl�ssig und werden
von mehr Programmen verwendet, als man glaubt...
Fr�her stand durch die Benutzung von FCBs, die ja
bekannterma�en innerhalb der sie benutzenden Anwendung
selbst alloziert werden, eine M�glichkeit offen, beliebig
viele Dateien gleichzeitig zu �ffnen (genug Speicherplatz
vorausgesetzt). Allerdings waren bei diesem Konzept die
Verwaltungsstrukturen von DOS den Applikationen zu-
g�nglich, was sp�tere Erweiterungen aus Kompatibilit�ts-
gr�nden schwer bis unm�glich machte. Aus diesem Grunde
wurde mit DOS 2.0 eine Dateiverwaltung auf der Basis von
Handles eingef�hrt, die die Behandlung �ber FCBs abl�ste.
Die internen Verwaltungsstrukturen sind damit vor den
Applikationen, die nur noch die Handles zu Gesicht
bekommen, gekapselt, was Raum f�r Erweiterungen schafft.
Nachteilig an der neuen Methode ist, da� das Betriebs-
system von vornherein Speicherplatz f�r diese Ver-
waltungsstrukturen (SFT-Eintr�ge) reservieren mu�
(siehe FILES=), was die maximale Anzahl gleichzeitig
offener Dateien einschr�nkt. Um trotzdem die Kompatibi-
lit�t mit FCBs-nutzenden Programmen zu wahren, die
nat�rlich von den n�tigen Erweiterungen der Verwaltungs-
strukturen auf der Basis von Handles nichts wissen
k�nnen und FCBs daher immer noch wie anno-dazumal
benutzen, war die Einf�hrung sog. System-FCBs n�tig (eben
vom System reserviert mit FCBS=), die der Kernel bei
CP/M-Dateioperationen jedesmal mit den wirklichen FCBs
synchronisiert, die die alte Applikation zu verwenden
glaubt. Das System arbeitet hingegen intern mit nur mit
diesen System-FCBs, die im Prinzip genauso aussehen, wie
die internen Verwaltungsstrukturen, die auch f�r Datei-
operationen via Handles benutzt werden. Um den Synchron-
isationsaufwand soweit wie m�glich zu reduzieren, war
bei FCBS= auch die Angabe gesch�tzter System-FCBs
(Protected FCBs) m�glich, die das System zwischen-
puffert (s.u.).
Die Angabe des Wertes 0 ist zwar m�glich, sollte aber
vermieden werden. Laut meiner Erfahrung ist die Default-
Einstellung <1,0> (Update 15), laut Dokumentation jedoch
<4,4>, wobei jeder Steuerblock 50 Bytes im konventio-
nellen Speicher ben�tigt (die auch mit DOS=HIGH,UMB nicht
ins Upper Memory verlagert werden k�nnen). W�hrend der
CONFIG.SYS gilt - unabh�ngig von der gew�hlten FCBS=
Einstellung, die zun�chst nur aufgezeichnet wird, um
erst nach Beendigung der CONFIG.SYS aktiv zu werden -
eine Einstellung, die effektiv FCBS=1,0 entspricht.
Bei Novell DOS ist FCBS= allerdings nur dann wirklich
effektiv, wenn SHARE.EXE oder eine Netzwerk-Software ge-
laden wird. Obwohl die Angabe nn f�r die gesch�tzten FCBs
(Protected FCBs) optional ist, wird sie - entgegen der
Dokumentation - zumindest bis zur derzeitigen IBMBIO.COM
Version (Update 15 und Caldera OpenDOS 7.01) definitiv
nicht ausgewertet (und wahrscheinlich deshalb auch nicht
von SHARE etc.), es gibt aber in der Literatur immer
wieder Hinweise, da� die zweite Angabe bei DR DOS im
Netzbetrieb eine Auswirkung hatte (allerdings enth�lt
auch der Kernel von DR DOS 3.41-6.0 nur Code zur Aus-
wertung des ersten Parameters, so da� mir dies recht
unwahrscheinlich erscheint).
Die gesch�tzten FCBs sind auch bei MS-DOS 5.0+ wegge-
fallen, so da� die fehlende Auswertung bei Novell DOS 7
nur kompatibel w�re...
Gesch�tzte FCBs kosten (vermutlich) jeweils 16 Bytes
Speicherplatz.
Da die Verwaltungsstrukturen f�r System-FCBs und FILES=
intern sowieso gleich sind (s.o.), benutzen DR DOS und
Novell DOS FCBS= und FILES= konsequenterweise auch gleich
als 'Handles' und verwalten sie aus einem gemeinsamen
Pool, was eine effektivere Speicherauslastung zur Folge
hat (siehe auch MEM /A). FILES= und FCBS= k�nnen zusammen
maximal 255 ergeben. Diese Beschr�nkung ist systemgegeben
f�r DOS, kann allerdings mit einigen Tricks von NetWare-
Shells wie NETX, VLM umgangen werden, wenn auch nur f�r
Dateien im Netz.
Wegen der Zusammenfassung von FCBS= und FILES= geben
einige Analyseprogramme (wie etwa Quarterdecks MFT)
mehr FILES an, als eingestellt, daf�r aber nur einen FCB.
Im Zusammenhang mit dem FCB-Management wurden im Laufe
der Zeit eine Menge Anpassungen vorgenommen, so da� sich
die Verwendung eines aktuellen Updates empfiehlt, falls
Ihre Programme FCBs benutzen. (Leider gibt es selbst mit
Update 15/2 noch ein paar Einschr�nkungen, etwa unter-
st�tzt INT21h/13h erweiterten FCBs nicht f�r alle
m�glichen Attribute, so da� "PKZIP -&w" unter Novell DOS
und OpenDOS fehlschl�gt, da PKZIP bis 2.04g �rgerlicher-
weise diese obsolete Methode verwendet, um ein Medium zu
entleeren - was auf diese Weise sowieso nur zum Teil
gelingen kann...).
Die mit MS-DOS 7 (MS Windows95/Chicago) sp�ter einge-
f�hrte Direktive FCBSHIGH= wird von Novell DOS 7 (Update
15) nicht unterst�tzt. Bei Novell DOS 7 bleiben die FCBs
auch bei DOS=HIGH,UMB im konventionellen Speicher, was
bei �blichen Konfigurationen f�r FCBS= und FILES= ge-
meinsam einen 'Verlust' von 0,5 - 3,5 KByte konventio-
nellen Speicher bedeutet, der durch die anderen Hochlade-
m�glichkeiten aber mehr als wett gemacht wird.
Andererseits besteht die M�glichkeit, sich die Utilities
FILES.COM und FCBS.COM von QEMM 7.50+ 'auszuleihen'
(funktionieren problemlos mit Novells Speichermanagern,
getestet mit Update 15), und damit die Datenstrukturen
wenigstens in UMBs abzulegen... Daf�r sollten Sie einen
sehr kleinen FCBS= und FILES= Wert in CONFIG.SYS ein-
stellen (z.B. die effektive Minimaleinstellung FCBS=1,0
und FILES=5) und per INSTALLHIGH= oder LH diese beiden
Utilities mit den entsprechenden Parametern aufrufen,
die Sie sonst bei FILES= und FCBS= angeben w�rden.
Beispiel:
CONFIG.SYS:
DEVICE=EMM386 ...
DOS=HIGH,UMB
...
REM Statt wie vorher 60 Handles im konventionellen
REM Speicher, nun dort nur noch 5 Handles (Minimum),
REM daf�r aber 55 Handles in UMBs. Spart ca. 3,5KB
REM konventionellen Speicher ein! Also:
REM Statt FILES=60 nun:
FILES=5
INSTALLHIGH=c:\sys\qemm\files.com 60
REM Statt FCBS=4,4 nun:
FCBS=1,0
INSTALLHIGH=c:\sys\qemm\fcbs.com 4,4
Manche Programme arbeiten allerdings nicht sauber, wenn
die Eintr�ge in UMBs verlagert wurden. In diesem Fall
sollten Sie eine etwas gr��ere Anzahl im konventionellen
Speicher belassen.
Zum Beispiel erwartet MS Windows 3.xx mindestens acht
Handles im konventionellen Speicher, sonst bricht Windows
sofort mit der Meldung 'MS-DOS Version nicht unterst�tzt'
ab. Da aber unter Novell DOS w�hrend der CONFIG.SYS immer
die internen Einstellungen von FILES= und FCBS= gelten
(und die sind kleiner, als Windows es sp�ter erwartet)
und Utilities wie FILES.COM, FCBS.COM Puffer in Abh�ngig-
keit von diesen Werten nur die dar�ber hinausgehenden
Handles neu einrichten, mu� man hier etwas tricksen:
Die CONFIG.SYS Einstellung wird auf das Minimum ver-
ringert, das MS Windows zul��t und erst in AUTOEXEC.BAT
werden die restlichen Handles mit FILES.COM und FCBS.COM
eingerichtet:
Beispiel:
CONFIG.SYS:
DEVICE=EMM386 ...
DOS=HIGH,UMB
...
REM Minimaleinstellung, die im konventionellen Speicher
REM bleiben mu�, damit MS Windows noch startet:
FILES=8
FCBS=0,0
AUTOEXEC.BAT:
REM Nun *gilt* die in CONFIG.SYS gew�hlte Einstellung,
REM wir k�nnen den gew�nschten Rest in UMBs anlegen:
LH c:\sys\qemm\files.com 60
LH c:\sys\qemm\fcbs.com 4,4
REM Nun k�nnen Programme folgen, die die h�here Ein-
REM stellung f�r Handles ben�tigen, daher sollten
REM obige Aufrufe m�glichst am Anfang der AUTOEXEC.BAT
REM stehen, sonst werden einige Programme und DOS-
REM Dienstprogramme nicht ordnungsgem�� funktionieren.
Der Grund f�r MS Windows' Verhalten ist �brigens sehr
kurios und zugleich ein Beispiel daf�r, wie man es
*nicht* machen sollte: MS Windows' DOSMGR ben�tigt f�r
seine Arbeit nicht nur einen Zeiger auf die SFT-Kette,
sondern auch die Gr��e ihrer Eintr�ge, die sich leider
im Laufe der DOS-Versionen ver�ndert hat. Statt nun die
jeweile Gr��e entsprechend der DOS-Version aus einer
Tabelle zu holen, �ffnet DOSMGR f�nfmal hintereinander
das Ger�t CON:, sucht dann die ersten 512 KByte des
Hauptspeichers nach Zeichenketten wie "CON" ab und
ermittelt die Gr��e der SFT-Eintr�ge durch Abstands-
berechnungen zwischen diesen Fundstellen. Nat�rlich ist
dieses Verfahren im wahrsten Sinne des Wortes lebens-
gef�hrlich, denn findet DOSMGR f�lschlicherweise andere
"CON"-Zeichenketten als die, die wirklich zu den SFT-
Eintr�gen geh�ren, ist das Chaos auf Ihrer Festplatte
vorprogrammiert...
Damit DOSMGR diese Zeichenketten �berhaupt finden kann,
d�rfen sie halt nicht hochgeladen werden. (Es gibt
allerdings die - gef�hrliche - M�glichkeit, trotzdem
alle SFTs hochzuladen und vor dem Start von MS Windows
die seit DOS 4.0 geltende SFT-Gr��e von 3Bh Bytes
dadurch vorzut�uschen, da� man einen nicht allozierten
Bereich des Hauptspeichers unterhalb von 512 KByte mit
"CON"-Zeichenketten im richtigen Abstand beschreibt,
so da� DOSMGR �berlistet wird. Dieses Verfahren k�nnte
man nat�rlich auch direkt in einen Speichermanager wie
EMM386 einbauen...)
FILES [=] nnn [comments] nnn=8..255 <12 oder 20>
Entgegen den Angaben im Handbuch sind hier auch Werte
kleiner 20 m�glich. Sinnvolle Einstellung h�ngen von
den verwendeten Anwendungen ab. Normalerweise ist der
Default-Wert FILES=20 ausreichend. F�r Netz- und Multi-
tasking-Betrieb sollte man den Wert jedoch mindestens
auf 40 erh�hen. Mit FILES=60 bis FILES=80 liegen Sie
fast immer auf der sicheren Seite, allerdings kostet
die Bereitstellung von File-Handles pro Datei 64 Bytes
Arbeitsspeicher (laut Dokumentation 52 Bytes), die immer
im konventionellen Speicher liegen. Zu hohe Werte f�r
FILES= (etwa FILES=250) k�nnen auch wieder Probleme
bereiten, wenn etwa eine Shell wie NETX darauf angewiesen
ist, mehr als 255 Files zu �ffnen (in diesem Fall werden
n�mlich negative Werte, d.h. die freien Werte von oben
nach unten benutzt).
Zu beachten ist au�erdem, da� DOS einige File-Handles
f�r die Standard-Ger�te immer in Benutzung hat (die
Anzahl liegt bei 4 bis 6 und h�ngt auch von Ihrer
Hardware ab). Sie sollten keine Angaben kleiner 8
machen (laut Doku sind minimal 5 m�glich, fr�here
DOS-Versionen hatten auch diese Default-Einstellung),
weil diese Werte offenbar nicht korrekt ausgewertet
werden!!!
W�hrend der CONFIG.SYS gilt - unabh�ngig von der FILES=
Einstellung, die zun�chst nur aufgezeichnet wird, um
erst nach Beendigung der CONFIG.SYS aktiviert zu werden -
eine Einstellung, die effektiv FILES=5 entspricht.
FILES= und FCBS= zusammen d�rfen maximal 255 betragen,
ansonsten wird intern abgerundet (siehe FCBS=).
Durch die sinnvolle Zusammenfassung von FCBS= und FILES=
(hierzu siehe bei FCBS=) geben einige Analyseprogramme
(wie etwa Quarterdecks MFT) mehr FILES an, als einge-
stellt, daf�r aber nur einen FCB.
GEOWORKS ENSEMBLE 1.2+ und GEO PRO ben�tigten mindestens
FILES=120, um unter DR DOS 6.0 und Novell DOS 7 laufen
zu k�nnen.
Microsofts WIN32S-Spiel FREECELL ben�tigt, bezogen auf
seine Funktion, ebenfalls eine sehr hohe Anzahl FILES,
so da� FILES=60 hier nur knapp hinkommt.
Die mit MS-DOS 7 (MS Windows95/Chicago) sp�ter einge-
f�hrte Direktive FILESHIGH= wird von Novell DOS 7
(Update 15) nicht unterst�tzt. Soweit mir bekannt,
bleiben die Dateieintr�ge bei Novell DOS 7 auch bei
DOS=HIGH,UMB im konventionellen Speicher, was bei
�blichen Konfigurationen f�r FCBS= und FILES= gemeinsam
einen 'Verlust' von 0,5 - 3,5 KByte konventionellen
Speicher bedeutet, der durch die anderen Hochlade-
m�glichkeiten aber mehr als wett gemacht wird.
Andererseits besteht die M�glichkeit, sich die Utilities
FILES.COM und FCBS.COM von QEMM 7.50+ 'auszuleihen'
(funktionieren problemlos mit Novells Speichermanagern,
getestet mit Update 15), und damit die Datenstrukturen
wenigstens in UMBs abzulegen... Daf�r sollten Sie einen
sehr kleinen FCBS= und FILES= Wert in CONFIG.SYS ein-
stellen (z.B. die effektive Minimaleinstellung FCBS=1,0
und FILES=5) und per INSTALLHIGH= oder LH diese beiden
Utilities mit den entsprechenden Parametern aufrufen, die
Sie sonst bei FILES= und FCBS= angeben w�rden.
(Zwei Beispiele, die auch auf disbez�gliche Absonder-
heiten von MS Windows eingehen, finden Sie etwas weiter
oben bei FCBS=...)
Manche Programme arbeiten allerdings nicht sauber, wenn
die Eintr�ge in UMBs verlagert wurden. In diesem Fall
sollten Sie eine etwas gr��ere Anzahl im konventionellen
Speicher belassen (z.B. FILES=8 f�r 4DOS.COM oder
MS Windows).
FASTOPEN [=] hashbufsize [comments] hashbufsize=0..32768
<0, 512 oder 4096>
FASTOPEN merkt sich in einer Verweistabelle Einsprung-
zeiger zu bereits einmal ge�ffneten Dateien, und kann
bei Programmen, die h�ufig Dateien �ffnen und wieder
schlie�en (Datenbanken, manche Compiler) einen starken
Performance-Gewinn bringen. Allerdings ist FASTOPEN nicht
ungef�hrlich, wenn Sie Festplattenpflegeprogramme
einsetzen (COMPRESS, OPTIMIZR, DEFRAG, DISKOPT, SPEEDISK,
etc.), die an FASTOPEN vorbei die Position der Dateien
neu anordnen. Wird dann �ber DOS wieder auf eine solche
Datei zugegriffen, ist ein Datenchaos vorprogrammiert,
wenn der Rechner nicht neu gestartet wird. Die Tabelle
von FASTOPEN kann nicht in der HMA liegen.
Die interne Realisierungen unterscheidet sich grundlegend
zwischen MS-DOS/PC-DOS und DR DOS/Novell DOS, was sich
einerseits in den m�glichen Parametern niederschl�gt,
andererseits auch im Speicherbedarf. Bei MS-DOS/PC-DOS
werden *pro* Dateieintrag 48 Bytes belegt, bei
DR DOS/Novell DOS durch eine effiziente Hash-Tabelle nur
2 Bytes. Dadurch, da� bei MS-DOS/PC-DOS die Anzahl und
bei DR DOS/Novell DOS die Gr��e angegeben werden mu�,
sind die Zahlenwerte bei Novell DOS etwa doppelt so gro�
wie bei MS-DOS, nur da� Novell DOS hier offenbar mit
1/24 des Speicherbedarfs auskommt, was sich bei �blichen
Werten wie FASTOPEN=512 schon in �ber 11 KByte Speicher-
platzersparnis niederschl�gt... Nicht ohne Grund ist
deshalb die Default-Einstellung bei MS-DOS sehr viel
niedriger (unter 50).
Im Gegensatz zur Dokumentation sind bei Novells FASTOPEN
auch Angaben unterhalb von 128 m�glich (und zwar offen-
sichtlich stufenlos bis herab zu Null). Angaben f�r
spezifische Laufwerke (wie bei MS-DOS) sind nicht
m�glich. In Verbindung mit NWCACHE wird FASTOPEN = 0
empfohlen, da FASTOPEN durch den h�heren Verwaltungs-
aufwand sonst nur die Performance des NWCACHE bremst.
Mit Update 13 wurde die Default-Einstellung auf 0 ge-
setzt. Auch wegen der oben genannten Problematik mit
der Datenkonsistenz und einem auf heutigen Rechnern nur
geringen Geschwindigkeitszuwachs (nur sofern kein Cache
installiert ist), empfehle ich dringend FASTOPEN = 0
einzusetzen, wenn nichts gegen die Verwendung eines
Cache-Programms spricht.
Die erweitere Syntax mancher MS-DOS Versionen (Laufwerks-
angaben, Zahl zusammenh�ngender Bereiche, EMS mit /X)
wird nicht unterst�tzt (aber auch nicht zur�ckgewiesen).
Angesichts der bereits optimalen Speicherbilanz w�re
derartiger Aufwand auch kontraproduktiv.
Das *Kommando* FASTOPEN.EXE (bei DR DOS 6.0) bzw.
FASTOPEN.COM (bei Novell DOS 7) ist hingegen ein
funktionsloses Kompatibilit�ts-Dummy, da die FASTOPEN-
Funktionalit�t bei Novell DOS 7/DR DOS 6.0 schon
intern realisiert ist (bei manchen MS-DOS Ausgaben
wurde FASTOPEN via
INSTALL=FASTOPEN.EXE
(oder gar erst in AUTOEXEC.BAT) geladen, daher mu�te auch
bei Novell DOS eine gleichnamige Dummy-Datei existieren).
Manchmal ben�tigt man ein Dummy-Befehl, der einfach nur
als Platzhalter aufgerufen wird und keinen Schaden an-
richtet. Mit FASTOPEN.COM liegt Novell DOS 7 ein solches
'Programm' bei; es tut wirklich nichts anderes, als eine
entsprechende Meldung auszugeben und mit Errorcode 0
zu DOS zur�ckzukehren. Das gleiche gilt auch f�r
FASTOPEN.EXE von DR DOS 6.0, au�er da� Novells
FASTOPEN.COM in der Meldung zus�tzlich auf CONFIG.SYS
verweist, wenn es vom Prompt aus aufgerufen wird.
(�ltere Ausgaben von FASTOPEN.EXE von DR DOS 5.0 besa�en
wahrscheinlich noch eigene Funktionalit�t und kehrten bei
falschen Parametern mit Errorcode 1 zur�ck. Dies gilt
mit Sicherheit f�r FASTOPEN von MS-DOS/PC-DOS 4.0+.)
DOS [=] [LOW|HIGH] [, [UMB|NOUMB]]
HIDOS [=] [ON|OFF]
Wie von MS-DOS bekannt (Naja, eigentlich gab es die
Hochladem�glichkeit *zuerst* bei DR DOS 5.0, allerdings
noch mit der alten Direktive HIDOS=).
Novell DOS akzeptiert die m�glichen Parameter in
beliebiger Reihenfolge. Auch der Token NOUMB ist vor-
handen, in der Doku wird er allerdings nicht erw�hnt.
Die DR DOS Direktive HIDOS= ist auch bei Novell DOS noch
vorhanden und wird - undokumentiert - voll unterst�tzt.
Dabei entspricht HIDOS=ON dem DOS=HIGH. Bei DR DOS 6.0
war es noch genau umgekehrt: Die Direktive DOS=HIGH
(nicht aber die anderen Token) existierte auch dort
schon, war allerdings noch undokumentiert.
Default-Wert f�r DOS= ist LOW,NOUMB.
Mit DOS=HIGH,UMB werden nach M�glichkeit auch die DOS-
Datenbereiche verschoben (au�er FILES und FCBS).
MS-DOS 7 (MS Windows95/Chicago) unterst�tzt einige
zus�tzliche Optionen (AUTO, NOAUTO und bei Chicago
ENHANCED), die Novell DOS 7 (Update 15) fremd sind,
aber auch nicht vermi�t werden, da sie lediglich die
Handhabung unter MS Windows95 etwas vereinfachen
(Default ist AUTO), indem bestimmte notwendige Treiber
nicht explizit angegeben werden m�ssen, sondern auto-
matisch geladen werden. Au�erdem bewirkt diese Ein-
stellung, da� die Direktiven BUFFERS, FILES, FCBS,
STACKS und LASTDRIVE automatisch in ihrer neuen -HIGH-
Variante verwendet werden. Bei Novell DOS werden bei
entsprechender Einstellung von DOS=HIGH,UMB die Puffer
automatisch in die HMA verlegt und die LASTDRIVE-
Tabelle in den oberen Speicher.
DEBLOCK [=] hexvalue hexvalue=0000..FFFF <FFFF>
Diese undokumentierte Direktive von Novell DOS 7 erlaubt
die explizite Einstellung der Adresse, ab der IBMBIO.COM
beim 'Disk-Deblocking' nur noch einzelne Sektoren benutzt
(im Prinzip gibt es das seit CP/M).
In ganz fr�hen Novell DOS 7 Versionen (und bei DR DOS)
war die Default-Einstellung A000, was der 640 KByte-
Grenze entsprach. Dar�ber wurde auf den Single-Sektor-
Betrieb ausgewichen. Diese Einstellung war sicherer als
die heutige Einstellung, aber auch langsamer.
Um die Kompatibilit�t mit MS-DOS zu verbessern und
die Performance f�r in UMBs geladene Programme (wie
STACKER.EXE oder SERVER.EXE) zu erh�hen, wurde die
Default-Einstellung auf FFFF ver�ndert (was effektiv
auch bei MS-DOS gilt, obwohl es dort diese Direktive
�berhaupt nicht gibt, denn MS-DOS 5.0+ MULTITRACK=ON|OFF
ist hierzu fast identisch: DEBLOCK=FFFF entspricht wohl
weitestgehend MULTITRACK=ON und DEBLOCK=0000 demnach
MULTITRACK=OFF. Wie man sieht, sind Novells Einstellungs-
m�glichkeiten hier flexibler. Die Einstellung FFFF ist
schneller, aber auch gef�hrlicher. �ber die DEBLOCK=
Direktive hat der Anwender die M�glichkeit, die
Einstellung bei Bedarf zu ver�ndern. Probleme k�nnten
wohl in Verbindung mit (hochgeladenem) NWCACHE,
DBLBUF.SYS oder bei Floppy- oder Harddisk-DMA (ohne
VDS) auftreten.
Solange es keine Probleme gibt, sollte man DEBLOCK=
nicht angeben, um die automatische Hardware-Erkennung
und Konfiguration je nach System zu aktivieren. In diesem
Fall entscheidet nach der Beendigung von CONFIG.SYS ein
dynamischer Test dar�ber, ob die Default-Einstellung
FFFF bestehen bleibt, oder ob die Einstellung sicher-
heitshalber auf A000 zur�ckgesetzt wird (der Test be-
steht darin, den ersten Sektor sowohl in den konventio-
nellen Speicher als auch in UMBs zu laden und dann mit-
einander zu vergleichen). Ist man sicher, da� es keine
Probleme gibt, kann man die Einstellung auch explizit
auf einen Wert, hier also DEBLOCK=FFFF setzen und damit
die automatische Konfiguration �bersteuern.
N�heres kann dem FaxBack-Infopaper 14926.TXT aus
ND7TID.EXE entnommen werden. N�heres siehe auch in
Kapitel II.17.
DRIVPARM [=] /D:n [/C] [/F:n] [/H:nn] [/I] [/N] [/S:nn] [/T:nn]
/D:driveno driveno=0..31 (d.h. auch LASTDRIVE=32
wird voll unterst�tzt)
/F:drivetype drivetype=0..255 <0..9>
/S:sectors sectors=1..99 <h�ngt von drivetype ab>
/T:cylinder cylinder=1..999 <"">
Der in der Dokumentation erw�hnte Parameter /I wird
wahrscheinlich nicht unterst�tzt (da obsolet).
Wird der Parameter /C f�r die Change-Disk-Detection
nicht angegeben, so versucht Novell DOS zwar trotzdem,
diese Statusanzeige auszuwerten, im Fall des Scheiterns
wird jedoch nach einer Wartezeit von 3 Sekunden still-
schweigend ein Medienwechsel angenommen.
Bei /F:n kann eine beliebige Zahl angegeben werden,
es sind jedoch nur 0..9 vordefiniert. Die Default-
Einstellungen der restlichen Parameter h�ngen davon
ab, welche anderen Parameter in welchen Kombinationen
angegeben wurden. Sollte die DRIVPARM= Direktive mehr-
fach pro Laufwerk angegeben werden, so werden (bis
auf Ausnahmen) nur die Werte neu belegt, die auch neu
definiert wurden.
�bliche Zuordnungen f�r /F: sind:
0 = 320/360 KByte, double density [DD] (5,25")
1 = 1,2 MByte, high density [HD] (5,25")
2 = 720 KByte, double density [DD] (3,5")
3 = ??? KByte, single density [SD] (8")
(wird wie 360 KByte Floppy eingebunden)
4 = ??? KByte, double density [DD] (8")
(wird wie 360 KByte Floppy eingebunden)
5 = (Festplatte, sonst wie 360 KB Floppy eingebunden)
6 = (Bandlaufwerk, sonst wie 360 KB Floppy eingebunden)
7 = 1,44 MByte, high density [HD] (3,5")
8 = (optisches Laufwerk, z.B. CD-ROM, CD-WO, CD-RW,
wird allerdings wie 1,44 MByte Floppy eingebunden)
9 = 2,88 MByte, extra density [ED] (3,5")
Einige �bliche Diskettenformate:
Gr��e 8"------+
5,25"-+ | Typ Seiten Sektoren Spuren
3,5"+ | | /F: /H: /S: /T:
160 KByte, SS/SD - x - 0 1 8 40
180 KByte, SS/SD - x - 0 1 9 40
243 KByte, SS/SD - - x 0 1 26 77
320 KByte, DS/DD - x - 0 2 8 40
320 KByte, SS/HD x - - ? 1 8 80
360 KByte, DS/DD - x - 0 2 9 40
600 KByte, DS/DD - x - ? 2 15 40
1,20 MByte, DS/HD x x - 1 2 15 80
720 KByte, DS/DD x x - 2 2 9 80
1,44 MByte, DS/HD x x - 7 2 18 80
2,88 MByte, DS/ED x - - 9 2 36 80
Einige weniger �bliche Diskettenformate:
200 KByte, SS/SD - x ?? 1 10 40
205 KByte, SS/SD - x ?? 1 10 41
210 KByte, SS/SD - x ?? 1 10 42
361 KByte, SS/DD - x ?? 1 9 80
389 KByte, DS/DD x - 2 (0) 2 9 43
400 KByte, DS/DD x - ?? 2 10 40
410 KByte, DS/DD x - ?? 2 10 41
420 KByte, DS/DD x - ?? 2 10 42
640 KByte, DS/DD x x - 1 2 8 80
719 KByte, DS/DD x x - ?? 2 9 80
785 KByte, DS/DD x - 2 2 9 86
800 KByte, DS/DD x - ?? 2 10 80
810 KByte, DS/DD x - ?? 2 10 81
820 KByte, DS/DD x - ?? 2 10 82
830 KByte, DS/DD x - ?? 2 10 83
880 KByte, DS/DD x - ?? 2 11 80
1,04 MByte, DS/DD x - ?? 2 13 80
1,12 MByte, DS/DD x - ?? 2 14 80
1,23 MByte, DS/HD x x - 1 2 15 82
1,31 MByte, DS/HD x x - ?? 2 16 82
1,48 MByte, DS/HD x x - 7 2 18 82
1,49 MByte, DS/HD x - ?? 2 18 83
1,60 MByte, DS/HD x x - ?? (7) 2 20 80
1,64 MByte, DS/HD x - ?? (7) 2 20 82
1,68 MByte, DS/HD x - ?? 2 21 80
1,71?MByte, DS/HD x - ?? (7) 2 21 82
1,73?MByte, DS/HD x - ?? (7) 2 21 83
1,79 MByte, DS/HD x - ?? (7) 2 21 85
1,76 MByte, DS/HD x - ?? 2 22 80
1,84 MByte, DS/HD x - ?? 2 23 80
1,92 MByte, DS/HD x - ?? 2 24 80
3,20 MByte, DS/ED x - - ?? 2 40 80
3,52 MByte, DS/ED x - - ?? 2 44 80
3,84 MByte, DS/ED x - - ?? 2 48 80
Mit einem der letzten Updates (11-15) zu Novell DOS
gab es verschiedene Bugfixes, DRIVPARM= betreffend:
Einerseits konnten 2,88 MByte Laufwerke bisher nicht
entsprechend der Dokumentation angemeldet werden, und
andererseits werden sie jetzt auch korrekt erkannt, wenn
das BIOS sie falsch meldet (in der Einf�hrungsphase
dieser Laufwerke - dauert die nicht eigentlich immer
noch an? ;-) - gab es hier noch keinen sauberen Standard,
und einige BIOSe melden solche Laufwerke als Typ 3 oder
4 statt 5 oder 6). 1,44 MByte Floppies k�nnen jetzt
auch korrekt formatiert werden, wenn sie �ber DRIVPARM=
eingebunden worden sind.
Nachbemerkung: Angeblich unterst�tzt DR DOS 6.0
DRIVER.SYS /D:0..127. Diese d�rfte auch f�r Novells
DRIVER.SYS zutreffen, aber ob Laufwerke oberhalb 31
vom System unterst�tzt werden, ist nicht gekl�rt
(MS-DOS 2.xx unterst�tzte 64 Laufwerke).
Sollten Sie die obige Tabelle verwenden wollen, um
Diskettensonderformate einzustellen, sollten Sie hierzu
am besten mit DRIVER.SYS statt DRIVPARM= arbeiten, weil
Sie dann unter dem alten Laufwerksbuchstaben weiterhin
problemlos auf Normalformatdisketten zugreifen k�nnen.
Wichtig: Ich habe die meisten der obigen Sonderformate
nicht selbst ausprobiert! Die Angaben bez�glich des
Laufwerkstyps beziehen sich auf Laufwerke entsprechender
Kapazit�t. Nicht alle Laufwerke unterst�tzen mehr als
40/80 Spuren und die Anzahl der zuverl�ssig ansprech-
baren Sonderspuren variiert von Fabrikat zu Fabrikat
und kann sogar gewissen Exemplarstreuungen unterliegen.
Auch bei Disketten gibt es Unterschiede. Nicht jedes
Diskettenfabrikat eines Typs ist in der Lage, �berformate
(zuverl�ssig) zu verkraften, dies gilt besonders f�r
Formate au�erhalb der vorgesehenen Dichte. Unter Um-
st�nden ben�tigen Sie auch zus�tzliche Treiber, um diese
Formate zu unterst�tzen. Obwohl einige der �berformate
auch �ber lange Zeitr�ume sehr zuverl�ssig verwendet
werden k�nnen (siehe Ciriaco Gar�a de Celis' 2M-Paket
und andere) empfehle ich dringend ausf�hrliche Tests,
ehe Sie wichtige Daten auf solchen Disketten ablegen!
Ich �bernehme selbstredend keine Gew�hr!!!
HISTORY [=] OFF|[ON [, bufsize][[, ON|OFF][, ON|OFF[, ON|OFF]]]]]
bufsize=128..4096 <512>
In der w�hrend des Bootens ausgegebenen Hilfe sind nicht
alle m�glichen Parameter angegeben; das DOSBOOK gibt aber
ersch�pfende Hinweise. Das erste ON in Verbindung mit dem
optionalen Wert value (128..4096, Default ist <512>)
gibt die Gr��e des Puffers an, die weiteren optionalen
ON|OFF-Parameter stehen jeweils f�r Einf�gemodus ein/aus
(<Ins>), Kommandozeilensuchmodus ein/aus (<Ctrl>+<r>),
erweiterte Kommandozeilensuche ein/aus (<Ctrl>+<_>) und
werden nur ausgewertet, wenn der erste Parameter ON ist
(siehe auch Kapitel II.12.). Jeder Puffereintrag kostet
zwei Bytes, die immer im konventionellen Speicher
bleiben, bei 512 Puffern also 1 KByte.
Wird diese Direktive innerhalb der CONFIG.SYS mehrfach
wiederholt, so werden dabei nur die jeweils zuletzt
angegebenen Werte aktualisiert.
Offenbar wird erst mit dem Laden von COMMAND.COM Speicher
f�r den HISTORY-Puffer reserviert, jedenfalls konnte ich
bei beliebigen Einstellungen von HISTORY= keinerlei
Unterschiede im statischen Speicherverbrauch feststellen,
wenn mit SHELL=4DOS gearbeitet wurde. Trotzdem ist die
History-Funktion innerhalb von COMMAND.COM wohl
funktionsf�hig, was mir noch R�tsel aufgibt... ???
Meine Empfehlung, wenn Sie (zumindest zeitweise) mit
COMMAND.COM arbeiten:
HISTORY=ON,512,ON,OFF,OFF
Meine Empfehlung, wenn Sie ausschlie�lich mit einem
Alternativ-Kommandoprozessor wie 4DOS/NDOS arbeiten:
HISTORY=OFF
Bei HISTORY=OFF sollten Sie nicht mit DOSKEY /H arbeiten
(offenbar gibt es hier einen kleinen Bug, der dazu f�hrt,
da� bei Verwendung von 4DOS der History-Puffer zerst�rt
wird, getestet bis Update 15).
Das mit MS-DOS/PC-DOS 5 eingef�hrte DOSKEY besitzt
recht �hnliche Funktionalit�t, die meisten Tasten sind
identisch belegt, aber leider nicht alle. Unterschiede:
Taste DR DOS Novell DOS 7 MS-DOS/PC-DOS 5.0
<F7> ^Z ^@ listet Makros
<F8> ^@ durchsucht History
<F9> ?? l�scht akt. Zeile aktiviert Makro Nr.
<F10> ?? l�scht akt. Zeile
<Alt>+<F7>
<Alt>+<F10>
Novell DOS 7 DOSKEY stellt zwar die gleichen Optionen
wie das Original bereit (auch die Funktionen, die sich
auf die History-Funktion beziehen), dennoch ist die
History-Funktionalit�t bei Novell DOS weiterhin via
HISTORY= realisiert und nur die zus�tzlichen Makro-
funktionen sind Bestandteil des residenten DOSKEY
(siehe auch Kapitel II.4.). Dadurch k�nnen beide
Funktionen unabh�ngig voneinander aktiviert werden.
Im Vergleich zu MS-DOS DOSKEY, das bei 512 Bytes
Puffergr��e 4 KByte Speicher f�r den residenten
Code ben�tigt, schl�gt Novells DOSKEY nur mit ca.
1,5 KByte zu Buche, plus ca. 1,5 KByte f�r HISTORY=
mit 512 Bytes Puffer.
HISTORY= akzeptierte bei DR DOS 3.41 und 5.0 drei
Parameter, bei DR DOS 6.0 bereits vier, und nun noch
einen f�nften. Offenbar hinkte die Dokumentations-
abteilung immer eine DOS-Release hinterher, denn es
wurde in jeder DR DOS Ausgabe vergessen, die jeweils
letzte Option komplett zu dokumentieren.
LASTDRIVE [=] [A..Z]|[1..32] [comments] <F oder G>
Hinter dem Laufwerksbuchstaben sind weitere Zeichen
m�glich, d.h. eine Angabe wie LASTDRIVE=Z: wird also
auch akzeptiert. Jedes eingerichtete Laufwerk kostet 88
Bytes Speicherplatz. Die Default-Einstellung h�ngt offen-
bar von der Festplatteneinrichtung des Rechners ab: Mit
zwei Festplatten mit jeweils zwei Partitionen ist die
Einstellung offensichtlich G:, obwohl es laut Handbuch in
dieser Konfiguration F: sein m��te (bei MS-DOS ist die
Normaleinstellung E:). Eine andere Erkl�rung w�rde darin
bestehen, da� die Laufwerksbuchstaben, die von echten
Ger�tetreibern (DEVICE=) ben�tigt werden, erst nach der
Abarbeitung der CONFIG.SYS wirklich eingebunden werden
(dies ist aber zumindest bei Novell DOS 7 definitiv nicht
der Fall).
Erweiterte undokumentierte Syntax zur Unterst�tzung von
bis zu 32 Laufwerken (wird nun auch von MS-DOS 7 aus
Windows95 unterst�tzt). N�heres siehe Abschnitt III.2.
Die mit LASTDRIVE= vorgenommene Einstellung wird bei
Novell DOS und MS-DOS/PC-DOS (abgesehen von MS-DOS 7)
erst beim Laden des Kommandoprozessors wirksam. Inner-
halb der CONFIG.SYS gilt weiterhin die interne LastDrive-
Einstellung, die vor der Bearbeitung der CONFIG.SYS
ermittelt wurde (s.o.), d.h. es ist zwar m�glich,
Blockger�tetreiber zu laden (ist nicht abh�ngig von
LASTDRIVE=), aber es ist nicht m�glich, die Lastdrive-
Einstellung zu erh�hen, wenn das Laden von Laufwerks-
treibern per INSTALL= aufgrund fehlender freier Lauf-
werksbuchstaben fehlschl�gt, weil diese als Umadressierer
implementiert sind (NWCDEX, MSCDEX, Netztreiber wie VLM),
siehe auch Kapitel II.4. bei NWCDEX.
Intern wird bei Novell DOS 7 im Gegensatz zu MS-DOS/
PC-DOS bis 6.2x jedoch bereits eine auf 26 Laufwerke
erweiterte Vorab-CDS verwendet, dadurch kann mein Utility
INSTCDEX mittels der speziellen /LASTDRIVE Option auch
dazu verwendet werden, die LASTDRIVE= Einstellung des
Systems w�hrend der CONFIG.SYS zu ver�ndern (mehr dazu
bei NWCDEX). Diese Vorab-CDS wird nach der Bearbeitung
der CONFIG.SYS auf die wirklich geforderte Gr��e gestutzt
(oder mit LASTDRIVE=27..32 vergr��ert) und dabei nach
M�glichkeit auch in den UMBs angeordnet. Bei MS-DOS bis
einschlie�lich 6.22 ist das Handling wesentlich un-
flexibler: Die CDS, die immer im Basisspeicher bleibt,
enth�lt nur soviele Eintr�ge, wie Laufwerke vor der
Bearbeitung der CONFIG.SYS Datei erkannt wurden plus die
Eintr�ge von geladenen Blockger�tetreibern. Bei MS-DOS 7
haben die Entwickler einen weiteren langen Blick �ber den
Zaun geworfen, denn bei MS-DOS 7
- kann die LASTDRIVE=/LASTDRIVEHIGH= Angabe nun auch �ber
eine Zahl erfolgen,
- es werden auch bis zu 32 Laufwerke unterst�tzt,
(wobei sinnvollerweise wie bei sp�ten Ausgaben von
Novell DOS auch Zahlenwerte von 1..32 und nicht - wie
bei fr�hen Ausgaben von Novell DOS 7 - nur von 27..32
erlaubt sind. Die externen Utilities von MS-DOS 7
arbeiten im Gegensatz zu den Programmen von
Novell DOS 7 allerdings nicht mit diesen neuen
Buchstaben),
- die Vorab-CDS enth�lt ebenfalls 26 komplett initiali-
sierte Laufwerkseintr�ge (die sinnvollerweise auch
nach au�en dokumentiert werden, und nicht - wie bei
Novell DOS 7 - nur intern vorbereitet sind, wodurch
INSTCDEX unter Novell DOS 7 trotzdem ben�tigt wird,
bei MS-DOS 7 hingegen nicht mehr).
- und die CDS kann (automatisch) hochgeladen werden.
(Zus�tzlich wirkt bei MS-DOS 7 die LASTDRIVE= Direktive
nun schon w�hrend der CONFIG.SYS und auch das Verschieben
der CDS findet vorher statt, so da� die Probleme, zu
deren Umgehung ich f�r �ltere DOS-Versionen INSTCDEX.EXE
geschrieben habe, unter MS-DOS 7 nicht mehr auftreten.)
�brigens kann man mit dem Wissen dieses Verhaltens auch
verstehen, warum man f�r PNW und NetWare VLMs (�blicher-
weise nicht in CONFIG.SYS geladen) LASTDRIVE=Z setzen
sollte/mu�, wohingegen man bei der alten NetWare Shell
(NETX) den LASTDRIVE= Wert nur leicht erh�hen mu�te,
siehe auch Kapitel III.2. (VLM.EXE kann �brigens auch
unter Zuhilfenahme von INSTCDEX nicht in CONFIG.SYS
geladen werden.)
Die mit MS-DOS 7 (MS Windows95/Chicago) sp�ter einge-
f�hrte Direktive LASTDRIVEHIGH= wird von Novell DOS 7
(Update 15) nicht unterst�tzt. Wie bekannt, kann man
das Gleiche auch mit DOS=HIGH,UMB und 'normalem'
LASTDRIVE= erreichen.
NUMLOCK [=] [ON|OFF]
Diese undokumentierte Direktive schaltet NumLock ein oder
aus; allerdings wird die Einstellung normalerweise erst
�bernommen, wenn eine Taste gedr�ckt wird. Auf XTs bzw.
PC-Tastaturen kann es dazu kommen, da� die NumLock-LED
durch die Umstellung ab sofort genau umgekehrt reagiert.
Dieses systembedingte Verhalten ist kein Fehler und l��t
sich korrigieren, wenn zu einem sp�tereren Zeitpunkt mit
einem Utility der NumLock-Zustand erneut ver�ndert wird.
(Bei DR DOS 6.0 gab es diese Direktive noch nicht.)
SET [=] preenvvar = [value]
Die w�hrend CONFIG.SYS aufgezeichneten Umgebungsvariablen
werden sp�ter in COMMAND.COMs Systemumgebung �bernommen.
Standardm��ig ist diese Vorab-Umgebung leer, wird jedoch
beim Starten von COMMAND.COM um die Variable %ComSpec%
erweitert. COMMAMD.COM seinerseits f�gt noch %Ver% und
%Os% ein, siehe Kapitel IV.7. (Weitere Variablen w�rden
dann in AUTOEXEC.BAT belegt.) Maximal kann die Vorab-
Umgebung ca. 5760 Zeichen aufnehmen.
Wenn man Programme mit INSTALL[HIGH]= bzw. HIINSTALL=
l�dt, wird ihnen die bis zum jeweiligen Zeitpunkt aufge-
baute Vorab-Umgebung (unbearbeitet) �bergeben, daher
sollte man gerade in CONFIG.SYS mit dem SET= Befehl
umsichtig umgehen. An diesen eigentlichen Umgebungsblock
wird - wie �blich - noch eine Zeichenkette angeh�ngt,
die Pfad und Namen der ausgef�hrten Programmdatei
spezifiziert. Kurze Aufrufpfade f�hren also auch zu
eingespartem Speicherplatz (siehe Kapitel II.11.)!
Gegen�ber dem �blichen Verhalten von SET arbeitet die
CONFIG.SYS Direktive SET= etwas unterschiedlich: In
der Vorab-Umgebung werden *alle* mit SET= definierten
Variablen abgelegt (auch Leerdefinitionen wie SET=
ohne Wert nach dem =). Wenn man Variablen innerhalb
der CONFIG.SYS mit neuen Werten �berschreibt, so wird
der alte Eintrag *nicht* gel�scht, sondern die neue
Belegung an das Ende der Liste angeh�ngt. Au�erdem ist
zu beachten, da� bei den Variablen der Vorab-Umgebung
Gro�- und Kleinbuchstaben unterschieden werden, wohin-
gegen bei COMMAND.COM (und 4DOS.COM) die Variablen der
sp�teren Umgebung als Gro�buchstaben abgelegt sind
(wobei der SET-Befehl und die %var%-Ersetzung des
Kommandoprozessors nur auf die Variablen mit Gro�buch-
staben zugreifen, obwohl die Referenzen in Batchjobs
durchaus auch klein geschrieben werden k�nnen; wie dies
der besseren �bersicht auch in dieser Datei in ge-
mischter Gro�-/Kleinschreibung angewendet wird). Auf
diese Art und Weise k�nnen innerhalb der CONFIG.SYS
mehrere Definitionen *gleichzeitig* unter demselben
Namen existieren. M�chten Sie auf Nummer sicher gehen,
sollten Sie die Variablennamen f�r CONFIG.SYS SET=
generell in Gro�buchstaben schreiben.
Da diese Vorab-Umgebung allen per INSTALL[HIGH] ge-
ladenen Programmen �bergeben wird, ist dieses Detail
durchaus wichtig, denn von deren internen Auswerte-
routinen f�r die Umgebung h�ngt es ab, wie solche
Vorab-Umgebungen bearbeitet werden (viele GETENV()-
Routinen aus den Laufzeitbibliotheken Hochsprachen-
Compilern erkennen nur die Variablen, die in Block-
schrift geschrieben wurden, weil sie einfach davon
ausgehen, da� die Variablennamen in der Umgebung in
Gro�schrift repr�sentiert werden). Sofern man auf
diese Besonderheiten eingeht, er�ffnen sich durchaus
sinnvolle M�glichkeiten, z.B. kann man eine Art
History-Funktion der CONFIG.SYS Abarbeitung erm�glichen,
wenn man an allen relevanten Stellen eine spezielle
Variable (z.B. %hit_me%) mit dem Namen/Marke der
Position belegt. Die Reihenfolge der %hit_me%= Werte in
der Vorab-Umgebung entspricht dann der Reihenfolge, in
der die CONFIG.SYS bearbeitet wurde.
Ein Beispiel:
CONFIG.SYS:
SET test=wert1
SET test=wert2
SET test=
SET test=wert3
REM Die Vorab-Umgebung sieht jetzt folgenderma�en aus
REM (von anderen Variablen abgesehen):
REM "test=wert1 test=wert2 test= test=wert3"
INSTALL=c:\nwdos\command.com /C SET
REM Die Umgebungsauflistung von COMMAND.COM (neben
REM anderen Variablen wie %ComSpec%):
REM "test=wert1 test=wert2 test= test=wert3 TEST=wert3"
REM Gleichzeitig schlie�t der Aufruf von COMMAND.COM
REM aber auch Vorab-Umgebung (Update 15).
Dieses Beispiel zeigt ein weiteres Detail: Der Kommando-
prozessor COMMAND.COM (hier f�r Testzwecke auf un�blichem
Wege geladen), enth�lt neben der Vorab-Umgebung auch
die 'richtige' Umgebung "TEST=wert3". Diese spezielle
Ausnahme liegt an der internen Behandlung w�hrend der
Installation von COMMAND.COM; andere per INSTALL[HIGH]=
geladene Programme besitzen nur die Vorab-Umgebung!
Zu beachten ist, da� man dieses Ph�nomen nur zu Gesicht
bekommt, wenn man COMMAND.COM �ber INSTALL= l�dt. Bei der
normalen Ladeprozedur am Ende der CONFIG.SYS (und unter
Verwendung von SHELL=), wertet COMMAND.COM die Vorab-
Umgebung aus und baut das Master-Environment mit den
daraus resultierenden Belegungen auf. Dabei wird die
jeweils letzte Definition einer Variablen �bernommen.
Leerdefinitionen werden allerdings ignoriert, so da�
eine Vorab-Umgebung "test=wert1 test=" in "TEST=wert1"
umgewandelt wird.
Variablennamen werden in Gro�buchstaben abgelegt (bei
4DOS.COM bleibt die Gro�-/Kleinschreibung erhalten),
siehe Kapitel III.6. und 4DOSTIP.TXT.
Je weniger Variablen man belegt (und desto weniger h�ufig
man gleichnamige Variablen umdefiniert), desto weniger
Speicher wird f�r *jedes* per INSTALL[HIGH]= zu ladende
Programm ben�tigt. Die jeweils letzten Belegungen werden
beim regul�ren Laden des Kommandoprozessors (am Ende der
CONFIG.SYS Bearbeitung) �bernommen und werden von da an
jedem geladenen Programm �bergeben. Braucht man den SET=
Befehl exzessiv, so sollte man aus Gr�nden der Speicher-
platzersparnis - soweit m�glich - die Variablen erst
*nach* dem Laden der Programme definieren (dies gilt also
sowohl f�r CONFIG.SYS, als auch AUTOEXEC.BAT).
Leider kann der Anwender nicht schon innerhalb der
CONFIG.SYS auf die Variablen zugreifen (au�er �ber
interne Datenstukturen INT21h/4458h). Dabei ist aber
unbedingt darauf zu achten, da� ein Wert ungleich 0 bei
Offset +12h nicht unbedingt bedeutet, da� der Pointer
auf die Vorab-Umgebung auch wirklich g�ltig ist (unter
4DOS wird dieser Pointer n�mlich nicht zur�ckgesetzt).
Ein Workaround findet sich in Kapitel III.6. und
4DOSTIP.TXT.
Um die Vorab-Umgebung benutzen zu k�nnen, ohne gleich-
zeitig mit jedem geladenen TSR (die diese Variablen meist
gar nicht ben�tigen) einen gewissen Speicherverlust in
Kauf zu nehmen, habe ich f�r DR DOS 6.0/Novell DOS 7 ein
kleines Utility namens SETENV.COM geschrieben, das die
Vorab-Umgebung tempor�r versteckt. Dadurch kann bei
mit INSTALL=/INSTALLHIGH=/HIINSTALL= geladenen Programmen
etwas Speicher eingespart werden und einer unn�tigen
Fragmentierung vorgebeugt werden.
(Obwohl der Sachverhalt genauso auch f�r MS-DOS/PC-DOS
6.0+ Vorab-Umgebung gilt, besteht diese praktische
M�glichkeit f�r MS-DOS/PC-DOS Benutzer leider nicht.
Eine �hnliche M�glichkeit gibt es auch bei PTS/DOS und
S/DOS mit dem INSTALL= Parameter /E.)
Dazu mu� man jedes zu ladende TSR, dem nur eine Dummy-
Umgebung �bergeben werden soll, mit Aufrufen von
SETENV.COM einrahmen:
SET test=wert
REM Versteckt die Vorab-Umgebung
INSTALL=SETENV.COM
INSTALL=TSR ...
REM Restauriert die Vorab-Umgebung
INSTALL=SETENV.COM
Derzeit hat SETENV.COM noch einen sehr rudiment�ren
Status und toggelt bei jedem Aufruf den Zustand der
Vorab-Umgebung. Ist die Umgebung versteckt und verwendet
man zwischenzeitlich den SET= Befehl, so baut dieser
eine neue Umgebung auf, gleichzeitig wird diese wieder
sichtbar. Auf diese Weise ist es auch m�glich, eine
bereits aufgebaute Umgebung wieder komplett zu l�schen:
SET test=wert
REM Versteckt die Vorab-Umgebung
INSTALL=SETENV.COM
SET test2=wert2
REM SET l�scht die bisherige Vorab-Umgebung und
REM �berschreibt sie mit dem neuen Wert! Auf diese
REM Weise kann man den einzelnen TSRs auch v�llig
REM unterschiedliche Umgebungen �bergeben...
INSTALL=SETENV.COM
REM Da die alte Vorab-Umgebung nicht mehr existiert
REM und eine neue sichtbar ist, versteckt SETENV die
REM neue Umgebung, statt - wie in obigem Beispiel -
REM die alte wieder sichtbar zu machen...
Damit SETENV.COM (und SET=) arbeiten kann, darf aller-
dings im vorherigen Boot-Verlauf niemals COMMAND.COM
aufgerufen worden sein, auch nicht tempor�r etwa als:
INSTALL=c:\nwdos\command.com /C DIR *.*
Denn durch den Aufruf von COMMAND.COM wird die Vorab-
Umgebung geschlossen und weitere Variablen k�nnen
nicht mehr definiert werden. Au�erdem sind alle bis-
herigen Variablen auch f�r den sp�ter per SHELL= ge-
ladenen Kommandoprozessor nicht mehr verf�gbar!
SHELL [=] [d:[\path]]\COMMAND.COM d:\path /P[:autoexecfile] [/E:n] [/Mx]
Angabe des Kommandoprozessors (i. allg. COMMAND.COM).
N�heres zu dokumentierten COMMAND.COM Aufrufoptionen
siehe COMMAND.COM /? und zus�tzlich auch undokumentierten
Optionen siehe in Kapitel II.11!
Der Aufrufpfad f�r den Kommandoprozessor wird bei allen
�blichen Kommando-Interpretern (wie COMMAND.COM, 4DOS,
NDOS) auch f�r die Variable %ComSpec% benutzt, siehe
Kapitel IV.7.
Gibt man hier (f�r COMMAND.COM) die Option /P nicht
an, so wird keine AUTOEXEC.BAT Datei abgearbeitet,
nachdem COMMAND.COM geladen ist. Au�erdem ist dessen
EXIT Kommando in diesem Fall nicht gesperrt, d.h. man
kann die Prim�rversion des Kommandoprozessors verlassen
ohne zu Booten! Das darunterliegende IBMBIO.COM wei�
sich daraufhin nicht anders zu helfen, als die Eingabe-
behandlung selbst in die Hand zu nehmen, beschr�nkt sich
aber darauf, nach dem Pfad und Namen eines g�ltigen
Kommandoprozessors zu fragen. Leider kann man in diesem
Fall dem Kommandoprozessor keine Optionen (eben z.B. /P)
angeben. Alle w�hrend der CONFIG.SYS und AUTOEXEC.BAT
geladenen Treiber stehen �brigens in diesem Moment schon
zur Verf�gung.
Achtung: Die Angabe des Pfades zu den Systemdateien
(C:\NWDOS\) sollte nicht vergessen werden: Sie sorgt
auch ohne sp�tere Verwendung des PATH-Kommandos oder der
%Path% Variable daf�r, da� %Path% wenigstens das System-
verzeichnis einschlie�t, damit man auf einem jung-
fr�ulichen System �berhaupt erst mal loslegen kann.
Diese Direktive wird erst beim Verlassen der CONFIG.SYS
wirksam, wenn der Kommandoprozessor (COMMAND.COM) geladen
werden soll. L�dt man den Kommandoprozessor COMMAND.COM
schon vorher per INSTALL= (dauerhaft oder tempor�r), so
hat SHELL= keinen Einflu� darauf.
Achtung: Wurde COMMAND.COM einmal geladen (auch, falls
nur tempor�r), ist die Gr��e der Umgebung damit festge-
legt und gilt auch f�r den Kommandoprozessor, der beim
Verlassen der CONFIG.SYS geladen wird (was in den aller-
meisten F�llen dazu f�hrt, da� bei sp�teren SET-Befehlen
�berlauffehler auftreten.)
STACKS [=] n [, s] [comments] n=<0> | 8..64,
s=<0> | 32..512 <128>
F�r Original IBM-PC und PC/XT reicht 0,0, ansonsten
sollte man z.B. 9,128 angeben (h�ufig funktioniert aber
auch 0,0). In Verbindung mit MS Windows wird h�ufig 9,256
empfohlen, womit man in jedem Fall genug Sicherheits-
reserven hat.
Obwohl DR DOS 6.0 ebenfalls eine STACKS= Direktive (und
DR DOS 3.41 und 5.0 eine vergleichbare STACK= Direktive)
kannte, waren diese (zumindest bis zur Originalausgabe
von DR DOS 6.0 von 1991) nur ein Kompatibilit�ts-Dummy
und wurden exakt wie REM= behandelt. Der Grund lag
einfach darin begr�ndet, da� DR DOS zu gro�en Teilen
reenterant programmiert ist. Bei einigen Programmen
(z.B. Ventura Publisher), die mit dieser M�glichkeit
nicht rechneten und in inkompatibler Weise Stacks in
Eigenregie einrichteten, konnte aber diese eigentlich
so positive Eigenschaft Probleme bereiten. Diese Probleme
sind ist jedenfalls mit Novell DOS 7 durch explizite
Angabe von STACKS= weggefallen.
Die mit MS-DOS 7 (MS Windows95/Chicago) sp�ter einge-
f�hrte Direktive STACKSHIGH= wird von Novell DOS 7
(Update 15) nicht unterst�tzt. Wie bekannt, kann man
das Gleiche auch mit DOS=HIGH,UMB und 'normalem'
STACKS= erreichen.
SWITCHES [=] [/N] ([/F] [/K])
/N Dieser bei Novell DOS undokumentierte Parameter unter-
bindet die <F5>- und <F8>-M�glichkeit w�hrend des
Bootens. Diese Tasten werden w�hrend der Startmeldung
'Starten von DOS' abgefragt und zur sp�teren Verwendung
aufgezeichnet.
Da innerhalb von IBMBIO.COM <Ctrl>+<F5> bzw. <Shift> wie
<F5> und <Ctrl>+<F8> wie <F8> behandelt werden, gilt f�r
diese Tasten in diesem Zusammenhang das Gleiche. Aller-
dings ist es �ber die sog. Preload-Schnittstelle m�glich,
da� bereits vor der Bearbeitung der CONFIG.SYS weitere
Spezialtreiber wie DBLSPACE, DRVSPACE oder STACKER ge-
laden werden. Zumindest f�r DBLSPACE und DRVSPACE ist
gesichert, da� diese Online-Kompressoren die Tasten-
kombination (mit <Ctrl>) f�r sich als Hinweis auswerten,
sich nicht zu installieren (wahrscheinlich gilt das auch
f�r STACKER). N�heres in Kapitel II.2.
Die Einstellung der SWITCHES= Direktive wird in dem
Moment wirksam, in dem sie vom Parser bearbeitet wird.
Wurde also bereits vorher eine der obigen Tasten aufge-
zeichnet, so wird diese Aufzeichnung ab sofort f�r
ung�ltig erkl�rt.
Dieses Verhalten hat seine Vor- und Nachteile, in jedem
Fall ist es flexibler als das von MS-DOS:
Dieser Schalter stellt z.B. eine Ausnahme von der obigen
Regel dar, da� die CONFIG.SYS Datei entsprechend der
logischen Abfolge bearbeitet wird: Novell DOS sucht
zuerst einmal (unbeachtet von Verzweigungen) die gesamte
Datei nach dieser Direktive ab.
Wenn Sie SWITCHES= /N in die erste Zeile setzen,
passiert das Gleiche wie bei MS-DOS, weil dann eine
evtl. gedr�ckte Funktionstaste sofort wieder gel�scht
wird. Auf den ersten Blick gibt es hier eine Sicher-
heitsl�cke, da� bei <F8> auch eine Frage der Art
"SWITCHES=/N (J/N)?" erscheint, allerdings wird dies
intern abgefangen, solange die SWITCHES= Direktive
nicht ?SWITCHES=/N hei�t.
Steht diese Anweisung aber nicht in der ersten Zeile,
weicht das Verhalten signifikant ab:
Solange weder <F5> noch <F8> gedr�ckt werden, bleibt das
Verhalten logischerweise ganz normal. Wurde jedoch eine
der beiden Funktionstasten gedr�ckt, spielt nun die beim
Vorab-Scan der Datei gefundene Position der Direktive
SWITCHES=/N eine gro�e Rolle.
Wurde <F5> oder <F8> gedr�ckt, wird die CONFIG.SYS Datei
trotz /N bis zum Vorkommen der SWITCHES=/N Direktive ent-
sprechend <F5> oder <F8> �bersprungen oder im Einzel-
schrittbetrieb durchlaufen. Erst nachdem die SWITCHES=/N
Zeile passiert wurde (was im <F8>-Betrieb nicht unbedingt
mehr der Fall sein mu�), wird <F5> oder <F8> ignoriert
und die restliche Datei ganz normal bearbeitet.
H�chstwahrscheinlich handelt es sich bei diesem Verhalten
um einen Bug (getestet bis Update 14) und weniger um ein
verstecktes Feature, daher sollte man sich nicht darauf
verlassen, da� dieses Verhalten auch in Zukunft so
bleibt.
Bei trickreicher Verwendung kann das seltsame Verhalten
aber auch ein echtes Feature sein, indem man einen
Sonderfall anspringen l��t (n�mlich dann, wenn Sie die
SWITCHES= Anweisung an einer Stelle platzieren, die durch
den normalen Ablauf nie erreicht w�rde. Sie k�nnen dann
in der Zeile nach der SWITCHES= Anweisung einen Sprung-
befehl schreiben, der in den Sonderfall verzweigt).
Leider kann das auch Verwirrung stiften, indem nun alle
Fallunterscheidungen durchgearbeitet werden, da
Novell DOS von der Existenz eines Boot-Men�s nichts
mitbekommen hat.
Achtung: Wegen der fehlenden �berbr�ckungsm�glichkeit
besteht mit SWITCHES=/N die Gefahr, da� der Rechner in
einer Endlosschleife h�ngenbleibt, falls die GOTO=,
GOSUB=, SWITCH= oder RETURN= Anweisungen so verkn�pft
werden, da� die Bearbeitung immer wiederholt wird.
Hier w�re ein CONFIG.SYS Pre-Compiler wie bei MS-DOS
sinnvoller, denn damit k�nnte eine derartige Situation
verhindert werden.
(/F) Unterdr�ckt bei MS-DOS die 2 Sekunden Pause w�hrend der
Anzeige der Meldung 'Starten von DOS...'. Novell DOS 7
wartet immer 2 Sekunden, falls nicht schon vorher eine
Taste gedr�ckt wurde. Hat bei Novell DOS (zumindest bis
Update 15) keine Funktion, k�nnte sich aber in Zukunft
�ndern, denn intern sind alle Voraussetzungen daf�r
bereits vorbereitet und k�nnten mit einem minimalen
Patch realisiert werden.
(/K) Dieser MS-DOS Schalter zum Unterdr�cken erweiterter
Tastaturen wird bei Novell DOS ebenfalls nicht unter-
st�tzt. Novell DOS 7 entscheidet bei Laden von
IBMBIO.COM anhand der BIOS-Flagge 'erweiterte Tastatur',
ob erweiterte INT16h Calls verwendet werden oder nicht.
Sollte es Ihnen gelingen, diese Flagge vorher zu l�schen,
arbeitet Novell DOS nur mit den Calls f�r Standard-
tastaturen. (Bei DR DOS 6.0 war SWITCHES= noch nicht
vorhanden.) Auch dieser Schalter w�re mit einem minimalen
Patch bei Novell DOS 7 (Update 15) implementierbar, da
alle Voraussetzungen daf�r bereits erf�llt sind.
MS-DOS 7 (MS Windows95/Chicago) unterst�tzt einen neuen
/E:value Schalter, den Novell DOS 7 (Update 15) nicht
unterst�tzt, der dort aber auch �berfl�ssig ist.
YESCHAR [=] x [comments] x=<J|Y|O|S> je nach 'Land der Kernelfassung'>
Diese undokumentierte Direktive stellt das Zeichen x als
Best�tigung f�r 'Ja' in den [J/N] Abfragen bei IBMBIO.COM
ein. Wenn Sie mit amerikanischen Updates arbeiten, er-
scheint sonst [Y/N].
Dies kann mit YESCHAR=J f�r deutsche Rechner kompensiert
werden. (Wird leider derzeit nur innerhalb von CONFIG.SYS
ausgewertet. War bei DR DOS noch nicht vorhanden.)
Die Gro�- und Kleinschreibung von Buchstaben ist uner-
heblich. Das optionale Gleichheitszeichen erfordert hier
meistens, da� das Zeichen verdoppelt wird, wenn man ein
Gleichheitszeichen als 'Ja' angeben wollte.
Abhilfe f�r das Gesamtsystem ist nur durch Patchen des
Kernels m�glich, siehe Kapitel II.13.
Die impliziten Auswirkungen dieser Direktive werden be-
sonders im Zusammenhang mit den undokumentierten M�glich-
keiten von ?= und TIMEOUT= deutlich. Bei entsprechender
Konfiguration ist es quasi m�glich, das Verhalten aus der
Sicht des Anwenders zu invertieren.
ii. Laden von Ger�tetreibern und TSR-Programmen:
------------------------------------------------
Kann ein Treiber nicht geladen werden, tritt w�hrend des Ladens ein
Fehler auf (erweiterter Errorcode). Ansonsten setzt das geladene
Programm einen Exitcode (meist wird '0' f�r 'Alles ok' verwendet).
Diese Codes kann man innerhalb der CONFIG.SYS Datei verarbeiten.
Novell DOS (und teilweise auch schon DR DOS 6) stellt eine Reihe
undokumentierter Direktiven (etwa ONERROR=, ERROR=) zur Verf�gung,
mit denen man damit flexibel auf solche Zust�nde reagieren kann.
Sowohl bei den DEVICE...= als auch bei den INSTALL...= Direktiven mu�
der komplette Pfad inkl. der Dateiendung angegeben werden, ansonsten
wird das Programm nicht geladen (ohne, da� eine Fehlermeldung angezeigt
w�rde). Dies gilt auch, wenn die angegebene Datei nicht existiert (in
diesem Fall gibt MS-DOS meines Wissens eine Fehlermeldung aus). Dieses
Verhalten kann von Vorteil sein, wenn man eine Datei laden m�chte, die
nicht immer vorhanden/erreichbar ist. In den "Aus"-Phasen wird dann
keine st�rende Meldung ausgegeben. Dies funktioniert praktischerweise
auch bei Zugriffen auf die Floppy-Laufwerke, auch wenn keine Diskette
eingelegt ist. Mit einem Trick (Verwendung von INSTCDEX.EXE) k�nnen
Sie sogar Treiber direkt von CD-ROMs laden, was normalerweise nicht
m�glich ist, da ein CD-ROM-Umadressierer (wie NWCDEX) sonst erst in
AUTOEXEC.BAT geladen werden kann.
Die Dateiendung spielt bei den DEVICE...= Direktiven keine Rolle (Sie
k�nnen also auch ausf�hrbare Dateien laden, wenn diese z.B. die Endung
.BIN, .OVL, .EXE, .COM haben), entscheidend ist der Aufbau der Datei.
�blicherweise haben Ger�tetreiber aber die Dateiendung .SYS (aber es
gibt auch andere Dateien, die - obwohl sie keinen Bin�r-Code enthalten -
die Endung .SYS haben, etwa CONFIG.SYS, COUNTRY.SYS, usw.)
Wenn Sie Treiber mit anderen Endungen als .SYS per DEVICE= laden
wollen, sollten Sie dies nur tun, wenn die Dokumentation dies aus-
dr�cklich erlaubt. Wenn z.B. eine .EXE- oder .COM-Datei nicht einen
speziellen Dateikopf, wie er f�r Ger�tetreiber �blich ist, integriert
hat, wird der Rechner abst�rzen. Es gibt aber (wenige) Treiber und
Programme, die einen dualen Dateikopf haben und in beiden F�llen
geladen werden k�nnen. Manchmal unterscheidet sich sogar das Verhalten
des Treibers zwischen beiden Ladevarianten (z.B. EMM386.EXE).
Bei Novell DOS/DR DOS werden die Treiber in der Reihenfolge geladen,
in der sie im Rahmen ihrer CONFIG.SYS Abarbeitung vorkommen (MS-DOS/
PC-DOS arbeitet hier anders und l�dt Treiber per DEVICE= etc. vor
denen, die per INSTALL= geladen werden.) Dies ist wichtig, da dadurch
die Reihenfolge der geladenen Programme total differieren kann.
Allerdings lassen sich mit Novells L�sung einige Tricks bewerk-
stelligen, die unter MS-DOS/PC-DOS v�llig unm�glich sind.
DEVICE[=] driver [params]
HIDEVICE[=] [SIZE=hexsize] [=] driver [params]
DEVICEHIGH[=] [SIZE=hexsize] [=] driver [params]
DEVICEHIGH[=] [/L:reg[,minsize][;reg[,minsize][;...]]] [/S]] ...
... [=]driver [params]
Die alte DR DOS Direktive HIDEVICE= wird weiterhin un-
dokumentiert unterst�tzt und identisch zu DEVICEHIGH=
behandelt. F�r die optionale Angabe hexsize (in Bytes)
sind Werte von 00000..FFFFF erlaubt, intern wird dies
jedoch auf Paragraphen (� 16 Bytes) aufgerundet.
N�heres zu DEVICE= und DEVICEHIGH= in Kapitel III.4.
Kann ein Ger�tetreiber nicht geladen werden, so wird die
interne Fehlervariable (siehe ONERROR=) auf den Fehler-
code der Funktionen INT21h/3D00h, INT21h/4202h bzw.
INT21h/3Eh gesetzt. Diese Fehlercodes entsprechen in
ihrer Nummerierung den sog. erweiterten Fehlercodes,
die man auch �ber INT21h/59h erhalten k�nnte.
Tritt ein Fehler *w�hrend* der Initialisierung des
Treibers (d.h. unter der Kontrolle des bereits geladenen
Treibers) auf, so bekommt die Fehlervariable einen Wert
mit gesetztem Bit15 und dem Inhalt der Bits7-0 des
Statuswortes (Offset +03h im Device Request Header),
das der Ger�tetreiber zur�ckliefert, zugewiesen. Das
bedeutet, da� die Treiber-Returncodes 0..255 auf
32768..33023 umgemappt werden. Da diese Fehlercodes
�blicherweise als erweiterte DOS-Fehlercodes nicht
belegt sind, kann man bei ONERROR= zwischen Fehlern
vor oder w�hrend der Treiberinitialisierung unter-
scheiden.
Beispiele f�r erweiterte Fehlercodes (vor der Init):
(im Bereich 0..65535, jedoch �blicherweise kleiner 256,
weitere Codes wie bei INT21h/59h.)
0 = kein Fehler
1 = Ung�ltige Funktion
2 = Datei nicht gefunden
3 = Pfad nicht gefunden
4 = Zu viele offene Dateien (keine Handles frei)
5 = Zugriff verweigert
6 = Ung�ltiges Handle
12 = Ung�ltige Zugriffsrechte
86 = Ung�ltiges Pa�wort
Beispiele f�r Returncodes des Treibers nach der Init
(Codes 0..255 umgemappt auf 32768..33023):
32768 (0) = Medium schreibgesch�tzt
32769 (1) = Ger�tenummer unbekannt
32770 (2) = Ger�t nicht bereit
32771 (3) = Funktion ist nicht definiert
32772 (4) = CRC-Fehler
32773 (5) = ung�ltiger Parameterblock
32774 (6) = Spur nicht gefunden
32775 (7) = unbekanntes Speichermedium
32775 (7) = Sektor nicht gefunden
32776 (8) = kein Papier im Drucker
32777 (9) = Schreibfehler
32778 (10) = Lesefehler
32779 (11) = allgemeiner Fehler
32780 (12) = reserviert
32781 (13) = reserviert
32782 (14) = unerlaubter Diskettenwechsel
Da die Fehlervariable, die innerhalb von CONFIG.SYS ver-
wendet wird, zweier Herren Diener ist, kann man Doppel-
deutigkeiten nicht ganz ausschlie�en; trotzdem kann
aufgrund einer gl�cklichen F�gung �blicherweise doch sehr
einfach zwischen den Fehlercodes (aus der Sicht von
IBMBIO.COM) unterhalb 32768 und den Fehlerr�ckgabewerten
(aus der Sicht des Treibers) von 32768..33023 unter-
schieden werden. Eine dritte M�glichkeit w�re zwar theo-
retisch m�glich, n�mlich die R�ckgabe eines von Null ver-
schiedenen Codes bei fehlerfreier Initialisierung des
Treibers, aber da dies in den DOS-Standards undefiniert
ist, wird es folgerichtig auch nicht angeboten (es w�rde
in den meisten F�llen nur Zufallsresultate liefern). Zu
beachten ist, da� Fehlercodes, die in der Dokumentation
eines Treibers angegeben werden (�blicherweise 0..255),
in *dieser* �bersicht als Returncodes des Treibers zu
verstehen sind. Diese Codes finden Sie daher innerhalb
der CONFIG.SYS an den Codes 32768..33023 (+32768) wieder.
INSTALL[=] program [params]
HIINSTALL[=] program [params]
INSTALLHIGH[=] program [params]
INSTALL= wurde urspr�nglich nur vorgesehen, um bestimmte
Programme des Betriebssystems fr�her als sonst m�glich
zu laden. An eine praktische M�glichkeit zur generellen
Verwendung f�r Fremdtreiber hatten die Entwickler offen-
bar zun�chst nicht gedacht. Dies ist auch nicht ver-
wunderlich, denn in fr�hen DOS-Versionen war das System
w�hrend der Bearbeitung der CONFIG.SYS Datei noch
so minimal funktionsf�hig, da� viele der Interrupt-
Funktionen, die TSRs und andere Programme normalerweise
aufrufen, offiziell noch nicht definiert waren (vgl.
Spezifikation f�r Programmierung von Ger�tetreibern).
In der Praxis waren (insbesondere bei DR DOS gegen�ber
MS-DOS) viele der kritischen Funktionsausrufe auch schon
innerhalb von CONFIG.SYS problemlos m�glich, so da� im
Endeffekt fast alle Programme schon in CONFIG.SYS geladen
werden konnten. Es gibt wirklich nur sehr wenige Pro-
gramme, die aus verschiedenen Gr�nden noch *nicht* in
CONFIG.SYS geladen werden k�nnen.
Au�erdem werden die per INSTALL= etc. geladenen Treiber
bei MS-DOS/PC-DOS sowieso nach den per DEVICE= etc.
geladenen Treibern geladen, so da� der Vorteil von
INSTALL= sich darauf reduziert, Programme vor der Shell
(COMMAND.COM) zu laden, was - f�r sich genommen - nur
selten wirklich notwendig ist. Bei DR DOS und Novell DOS
sieht die Sache allerdings v�llig anders aus: Dadurch,
da� Sie hier - aus Sicht des Betriebssystems - v�llige
Wahlfreiheit in der Ladereihenfolge haben, k�nnen Sie
INSTALL= auch f�r viele andere Dinge 'mi�brauchen':
N�heres zu INSTALL= in Kapitel III.5 (z.B., da� man nicht
unbedingt residente Software laden mu�, sogar die Ab-
arbeitung von Batchjobs als Unterroutinen von CONFIG.SYS
ist problemlos m�glich. INSTALL= taugt auch prima zum
Debuggen von erst sp�ter per DEVICE= zu ladenden Ger�te-
treibern.).
Bez�glich der Umgebung und M�glichkeiten, Speicherplatz
zu sparen, siehe auch bei SET=, insbesondere bez�glich
des Utilities SETENV.COM, auch bei LH in Kapitel II.11.
Die alte DR DOS Direktive HIINSTALL= wird weiterhin un-
dokumentiert unterst�tzt und dabei seltsamerweise nicht
wie INSTALLHIGH=, sondern wie INSTALL= behandelt
(getestet bis Novell DOS 7 Update 14, sp�testens bei
Caldera OpenDOS 7.01 wurde dies jedoch korrigiert).
INSTALL= und HIINSTALL= werden auch von CCI Multiuser DOS
7.22 unterst�tzt, dort kann man angeblich bei HIINSTALL=
auch die von HIDEVICE= bekannte Option SIZE=hhhh angeben,
die DR DOS und Novell DOS *hier* nicht kennen.
INSTALLHIGH= wird nun auch von MS-DOS 7 (MS Windows95/
Chicago) unterst�tzt. MS-DOS 6.22 bot diese M�glichkeit
noch nicht.
Nach der Ausf�hrung der INSTALL= etc. Direktive ermittelt
IBMBIO.COM im Falle eines signalisierten Fehlers (aus der
Sicht von IBMBIO.COM) �ber INT21h/59h den "erweiterten
Fehlercode" (0..65535), oder andernfalls �ber INT21h/4Dh
den "erweiterten" Returncode des Treibers, dessen Low-
Byte exakt dem Code entspricht, den auch ERRORLEVEL
zur�ckliefern w�rde. Dieser Wert wird in beiden F�llen
16-bittig in die CONFIG.SYS Fehlervariable eingetragen,
die mittels ONERROR= in CONFIG.SYS abgefragt werden kann.
F�r den �blichen Fall, n�mlich, da� in CONFIG.SYS per
INSTALL= etc. nur residente Treiber geladen werden,
ergibt sich hier - �hnlich wie bei DEVICE= - trotz
Doppelnutzung einer Variablen eine gute Unterscheidungs-
m�glichkeit, nur nicht mit einer Grenze bei 32768
(Bit15 gesetzt), sondern mit einer 'flie�enden' Grenze,
die bei 256 (Bit8 gesetzt) beginnt. F�r den Fall, da�
man mit INSTALL= Programme aufruft, die nicht resident
bleiben, ergibt sich allerdings das Problem, da� dann
beide Kategorien von Fehlercodes bei 0 beginnen und
nicht mehr voneinander unterschieden werden k�nnen.
In diesem Fall empfehle ich, die Auswertung in erster
Linie auf die Returncodes des Treibers auszurichten,
da diese sehr viel wahrscheinlicher andere Werte als 0
liefern und sinnvoller verwendbar ist, als die meist
nur sporadisch auftretenden erweiterten Fehlercodes des
Betriebssystems. Die ERRORLEVEL Werte finden Sie
(manchmal) in der Dokumentation des jeweiligen Pro-
gramms; einige Werte werden auch in dieser Datei bei
der Beschreibung des jeweiligen Kommandos aufgelistet.
Andererseits hat diese Methode auch den Vorteil, da�
Sie die Returncodes im Fall ordnungsgem��er Ausf�hrung
exakt so f�r die Auswertung per ONERROR= �bernehmen
k�nnen, wie sie in der Dokumentation des jeweiligen
Treibers (�blicherweise f�r den COMMAND.COM Prompt)
angegeben wurden.
Beispiele f�r erweiterte Fehlercodes:
(im Bereich 0..65535, jedoch �blicherweise kleiner 256,
weitere Codes wie bei INT21h/59h.)
0 = kein Fehler
sonst = (siehe weiter oben bei DEVICE=)
Beispiele f�r Returncodes des Treibers (High-Byte):
0 = normale Ausf�hrung (-> 0 .. 255)
1 = Abbruch durch <Ctrl>+<c> (-> 256 .. 511)
2 = Kritischer Abbruch (-> 512 .. 767)
3 = Resident installiert (-> 768 ..1023)
Beispiele f�r Returncodes des Treibers (Low-Byte):
Wie ERRORLEVEL im Bereich 0..255, werden bei Fehler-
zust�nden oder (�blicher) residenter Installation je-
doch auf 256..511, 511..767 oder 768..1023 umgemappt.
iii. Kommentare, Meldungen, Bildschirmsteuerung:
------------------------------------------------
:label [=] [comments]
Labels (Sprungmarken) m�ssen mit einem Doppelpunkt in der
ersten Spalte eingeleitet werden. Nach der Angabe des
Label-Namens (maximal 8 Zeichen werden unterschieden, bis
zum ersten Leerfeld), k�nnen dann noch weitere Kommentare
folgen, die bei der Bearbeitung einfach ignoriert werden.
Damit kann eine Marke im Prinzip genauso aussehen wie ein
Kommentar, und in der Tat: Fr�here DOS-Versionen kannten
noch keine REM[=] etc. Direktive. Hier konnte man sich
dadurch behelfen, da� man die Kommentare in Marken-Zeilen
geschrieben hat, deren Namen niemals als Sprungziele
benutzt wurden.
; [=] [comments]
REM [=] [comments]
[COMMON] [=] [comments]
Kommentare k�nnen, wie gewohnt, mit REM[=] oder ;[=] an-
gegeben werden. Bez�glich [COMMON] (mit eckigen Klammern)
siehe auch den folgenden Abschnitt. Die von MS-DOS 6.0+
undokumentiert unterst�tzte Direktive COMMENT=, die
identisch mit REM ist, wird von Novell DOS 7 nicht unter-
st�tzt.
Hinweis: Das Semikolon ';' wird von "Bert's Boot Box"
(s.o.) als Einleitung f�r Meta-Befehle zur Gestaltung
seiner Boot-Men�s verwendet, wodurch sich die Benutzung
f�r normale Kommentare ausschlie�t.
ECHO [=] [message]
Diese Direktive dient der Ausgabe von Meldungen (via
BIOS-Funktionen) und zur Gestaltung von Konfigurations-
men�s. "ECHO ON|OFF" und "ECHO." arbeiten nicht in
CONFIG.SYS.
Leerzeilen erzeugt man einfach dadurch, da� man keinen
Meldungstext angibt. Es sind beliebige Zeichen erlaubt,
'>', '<' und '|' haben noch nicht ihre sp�tere Bedeutung.
N�heres siehe in Kapitel III.3.
CLS [=] [comments]
Diese Direktive l�scht den Bildschirm, indem sie den
aktuellen Bildschirmmodus holt und sofort wieder setzt
(dabei wird bei Modi unterhalb 128 der Bildschirm ge-
l�scht). Das Verhalten unterscheidet sich insofern vom
*Befehl* CLS (der von COMMAND.COM zur Verf�gung gestellt
wird), als da� in der CONFIG.SYS noch keine andere
M�glichkeit zum Bildschirml�schen besteht. Die er-
weiterten M�glichkeiten des COMMAND.COM Befehls CLS
(z.B. mit %$Cls%) sind in Kapitel II.11., IV.7. und
in DRDOS6UN.TXT beschrieben. Au�erdem wird alles nach
dem CLS= Befehl ignoriert, kann also f�r Kommentarzwecke
verwendet werden.
CPOS [=] [line[, column]] line=0, <1>..255, column=0, <1>..255
Die Direktive setzt ohne Angabe von Parametern den
Cursor auf die Position (1,1) (obere linke Ecke).
Es gibt jedoch die M�glichkeit, zus�tzlich noch ein oder
zwei Parameter f�r die gew�nschten Koordinaten der neuen
Cursor-Position anzugeben. Wird ein Wert nicht angegeben,
wird jeweils 1 angenommen.
Entgegen der Anleitung sind Werteangaben von 1..255
m�glich.
Die jeweiligen Maximalwerte h�ngen vom eingestellten
Textmodus ab und sollten nicht �berschritten werden
(je nach BIOS kann der Cursor sonst an einer v�llig
falschen Position erscheinen).
Gibt man den Wert 0 f�r einen Parameter an, so wird der
Cursor au�erhalb des sichtbaren Bereichs an die
'Position 256' gesetzt. Mit (0,0) kann man den Cursor
meist ganz verschwinden lassen. Das exakte Verhalten
h�ngt jedoch auch vom BIOS ab, das den Wert au�erhalb
des g�ltigen Bereichs u.U. auf den Maximalwert reduziert
(damit w�re (0,0) dann die rechte untere Ecke).
iv. Benutzereingaben, Zeitsteuerung, Default-Verhalten:
-------------------------------------------------------
TIMEOUT [=] seconds [,query_answer [,switch_answer [comments]]]
seconds=<0>, 1..65535
query_answer=ASCII-char <'N'> (au�er 0Ah und 0Dh)
switch_answer=ASCII-char <'1'> (au�er 0Ah und 0Dh)
Diese Direktive zur Einstellung der Zeitschranke f�r
?=, SWITCH= und GETKEY= Direktiven bietet offiziell nur
die M�glichkeit, die Wartezeit seconds anzugeben. Wird
eine Zeitschranke von 0 angegeben, so wird die Zeit-
schrankenautomatik deaktiviert, d.h. es wird effektiv
auf einen Tastendruck gewartet.
Undokumentiert ist jedoch, da� TIMEOUT= dar�ber hinaus
noch zwei weitere Angaben zul��t:
Die erste Angabe query_answer spezifiziert die anzu-
nehmende Default-Antwort auf die Ja/Nein-Fragen bei ?=
oder w�hrend des <F8>-Einzelschrittmodus. Als Default
gilt hier 'N', d.h. nach Ablauf der Zeitschranke wird
eine ?= Frage automatisch mit 'N' beantwortet, d.h.
die entsprechende Direktive ignoriert. Dies entspricht
i. allg. dem gew�nschten Verhalten. (Hierzu siehe auch
Kapitel II.2.)
Grunds�tzlich kann hier aber jeder beliebige andere Wert
angegeben werden. M�chte man, da� nach Ablauf des Time-
outs eine ?= Frage automatisch mit 'Ja' beantwortet wird,
so mu� man hier als Default-Wert ein 'J', bzw. den ent-
sprechenden YESCHAR= Wert angeben (in der Ausgabe der
entsprechenden Ja/Nein-Frage wird allerdings nur das 'J'
durch das per YESCHAR= gesetzte Zeichen ersetzt, das 'N'
bleibt hingegen auch erhalten, wenn man query_answer
�ndert).
Der dritte Parameter switch_answer erlaubt - analog zum
zweiten Parameter - die Vorgabe einer Default-Antwort f�r
SWITCH= Eingaben. Normalerweise wird hier '1' angenommen,
was bewirkt, da� nach Ablauf der Zeitschranke automatisch
zur ersten Marke von SWITCH= gesprungen wird (und damit
z.B. den ersten Men�punkt w�hlt). Als grunds�tzlich
g�ltige Eingaben werden bei SWITCH= nur '0'..'9' akzep-
tiert, trotzdem kann man *hier* durchaus auch andere
Werte angeben.
Durch �bersteuern des Default-Wertes l��t sich etwa
das von MS-DOS her bekannte Verhalten MENUDEFAULT=
simulieren, indem nach Ablauf der Zeitschranke standard-
m��ig ein anderer Men�punkt gew�hlt wird. Aber die
Implikationen, die eine ver�nderte Einstellung mit
sich bringt, werden besonders deutlich, wenn man sich
das genaue Verhalten von SWITCH= n�her betrachtet.
Es ist m�glich, die Zeitschrankenfunktion f�r SWITCH=
zu unterbinden (gleichzeitig aber f�r ?= aktiv zu
lassen), indem ein f�r die jeweilige SWITCH= Zeile
ung�ltiger Wert als Default-Antwort gew�hlt wird
(z.B. 'X'). Ist diese Verhalten nicht gew�nscht,
sollte man darauf achten, da� die Zahl, die der
SWITCH= Eingabe entspricht, auch wirklich mit einem
existierenden Sprungmarke verkn�pft ist.
Um die M�glichkeiten von TIMEOUT= auszunutzen, mu�
diese Direktive u.U. relativ h�ufig dicht hintereinander
aufgerufen werden. Dabei ist zu beachten, da� nur die
Werte mit den neuen Einstellungen belegt werden, die in
der TIMEOUT= Zeile auch angegeben werden. Auf diese
Weise kann man z.B. den Default-Wert f�r ?= Fragen
oder die Verz�gerung der Zeitschranke �ndern, ohne den
Default-Wert f�r SWITCH= angeben zu m�ssen. In manchen
F�llen ist es wichtig, da� man eben diese Angaben nicht
jedesmal wiederholen mu�.
Gibt man TIMEOUT= ohne Parameter an, so wird die Warte-
zeit wieder auf unendlich zur�ckgestellt.
Achtung: Das trennende Komma zwischen den einzelnen
Werten von TIMEOUT= ist optional, wird es aber angegeben,
so darf nach dem Komma kein weiteres Leerzeichen folgen,
sonst wird dieses Leerzeichen f�lschlicherweise als das
gew�nschte ASCII-Zeichen f�r die Default-Antworten
interpretiert.
? [=] ["message"] directive [params]
Diese Frage - bei DR DOS und Novell DOS 7 steht das
Fragezeichen �blicherweise vor dem Befehl, bei MS-DOS/
PC-DOS wird dies zur�ckgewiesen - erlaubt es, die Aus-
f�hrung der angegebenen beliebigen Direktive abh�ngig
von der Antwort auf eine Frage zu machen. Typischerweise
handelt es sich dabei um eine Ja/Nein-Frage ohne Zeit-
beschr�nkung (abh�ngig von TIMEOUT=). Wird die Frage
mit der Taste f�r 'Ja' (YESCHAR=) beantwortet, so wird
die angegebene Direktive ausgef�hrt, andernfalls wird
die Zeile �bersprungen (es ist also nicht notwendig,
explizit mit 'Nein' zu antworten). Sobald aber mit
TIMEOUT= eine Zeitschranke definiert wurde, wird nach
deren Ablauf automatisch die dort angegebene Default-
Antwort (query_answer) gew�hlt (normalerweise 'N').
Praktisch an der ?= Direktive ist, da� sie automatisch
die zugeh�rige Zeile mit "(J/N) ?"-Frage anzeigt, wenn
man nicht explizit ein Meldung angegeben hat. Interessant
ist diese Variante deshalb, weil sie automatisch die
richtigen Zeichen f�r (J/N) darstellt (abh�ngig von
der Landesversion von IBMBIO.COM). Der 'Ja'-Buchstabe
kann mit der Direktive YESCHAR= �bersteuert werden.
Zwar wird man meist die Einstellung YESCHAR=J w�hlen,
aber in Einzelf�llen lassen sich �ber �nderungen von
YESCHAR= auch ganz andere Fragen verwirklichen.
Es mu� n�mlich nicht so sein, da� man in einer Situation
eine typische Ja/Nein-Entscheidung m�chte. Da aber der
'Nein'-Wert nicht verstellt werden kann, st�rt in diesem
Fall die automatisch generierte Frage. Sobald man aber
selbst einen Meldungstext definiert ("message" in G�nse-
f��chen), erscheint dieser Text anstelle der Frage.
Nat�rlich kann man hier auch wieder eine Frage formu-
lieren, aber es w�re z.B. auch eine Simulation einer
'PAUSE'-Funktion mit Abbruch durch Druck auf 'C' denkbar,
etwa:
TIMEOUT=10,N
YESCHAR=C
? "Bitte warten... (Abbruch mit '<C>ontinue')."
YESCHAR=J
Wird ein Text angegeben, kann man trotzdem die automa-
tische Meldung "(J/N) ?" an diese Meldung anh�ngen,
indem man nach der Meldung ein Fragezeichen schreibt
(w�rde hier "(C/N) ?" ergeben).
Da man bei TIMEOUT= auch den Default-Wert f�r den
Timeout-Fall einstellen kann, ist es 'fast' m�glich,
auch den 'Nein'-Fall umzudefinieren und zumindest aus
der Sicht des Anwenders die Bedingung logisch umzudrehen.
Nur, um Mal ein Beispiel daf�r zu geben:
TIMEOUT=10,J
YESCHAR=N
? "Heute <n>icht den Viren-Scanner starten?" GOTO skip
INSTALL=virusscan...
:skip
TIMEOUT=10,N
YESCHAR=J
Das 'Nein' in der Ja/Nein-Frage wird allerdings nicht
zum bei TIMEOUT= angegebenen Wert umge�ndert (die automa-
tisch generierte Frage w�rde also "(N/N)? " fragen, wenn
keine "message" angegeben w�rde...).
Sollte man beim Booten <F8> f�r Singlestepping gedr�ckt
haben (falls nicht mit SWITCHES=/N deaktiviert), so
werden bei den damit implizierten Fragen (d.h. auch ohne
explizites ?=) alle Kommentare (REM=, ;=, :=) und
SWITCHES= �bersprungen. Seltsamerweise gilt dies nicht
f�r [COMMON], das doch bei Novell DOS ebenfalls keine
Funktion hat (Update 14). Enth�lt eine Zeile bereits
eine ?= Direktive, so wird auch mit zus�tzlichem <F8>
nur einmal gefragt.
Eine syntaktische Alternative (wie bei MS-DOS/PC-DOS
6.xx) besteht darin, das Fragezeichen erst nach einem
Befehl (aber noch vor evtl. weiteren Schaltern wie z.B.
bei DEVICEHIGH=/HIDEVICE= m�glich (/L: und /S) und
ebenso vor dem optionalen Gleichheitszeichen) zu setzen.
Ein paar Beispiele:
?ECHO Soll dies angezeigt werden (nur DR DOS/Novell DOS)
ECHO? Soll dies angezeigt werden (auch MS-DOS/PC-DOS)
?DEVICEHIGH=driver parameter (nur DR DOS/Novell DOS)
DEVICEHIGH?=driver parameter (auch MS-DOS/PC-DOS)
DEVICEHIGH?/L:2=driver parameter
Wie kann man sich dies merken? Einfach so: Denken Sie
sich, ?= w�re eine eigenst�ndige und verschachtelbare
Direktive wie ONERROR= (s.u.) und nicht einfach eine
spezielle Option der normalen Direktiven. Das Gleich-
heitszeichen ist auch hier optional.
Achtung: Auch sp�ter unter COMMAND.COM haben Sie eine
M�glichkeit, die Befehlsausf�hrung mit ? variabel zu
gestalten. Die Syntax weicht aber in einigen Details
leicht ab, siehe Kapitel II.11.
SWITCH [=] [label1[[,] label2[[,] label3[[,] label4[[,] label5
[[,] label6[[,] label7[[,] label8[[,] label9[[,] label10
[[,] label11 [[,] comments]]]]]]]]]]]]
SWITCH= ist eine Mischung zwischen GOSUB=, ?= und
GETKEY=. Nur ein kleiner Teil der M�glichkeiten dieses
Kommandos ist dokumentiert.
Normalerweise wird bei SWITCH= kein Errorlevel gesetzt
(dies geschieht erst mit dem RETURN=), aber falls eine
Marke nicht existiert (und deshalb die Bearbeitung mit
der n�chsten Zeile fortgesetzt wird), wird ein
Errorlevel 0 gesetzt.
SWITCH= erlaubt auf den ersten Blick normalerweise die
Eingabe einer Zahl, die zwischen <1> und der Anzahl der
angegebenen Sprungziele liegt (offiziell nicht mehr als
neun: label1..label9). Die m�glichen Tastendr�cke m�ssen
vorher durch entsprechende ECHO= Ausgaben dem Benutzer
mitgeteilt werden. Wird die entsprechende Taste gedr�ckt,
verzweigt SWITCH= per 'GOSUB=' zu der entsprechenden
Marke und f�hrt das Unterprogramm aus. Normalerweise
wird dies irgendwann einmal mit RETURN= abgeschlossen
und es wird in die Zeile nach der SWITCH= Anweisung
zur�ckgesprungen. Dabei ist es - wie wir noch sehen
werden - mit RETURN= m�glich, einen 'Resultat' zur�ck-
zuliefern, das dann im weiteren Verlauf entsprechend
ausgewertet werden kann. Man kann aber auch auf den
R�cksprung aus den Unterprogrammen verzichten, wenn man
darauf achtet, da� evtl. an anderer Stelle ben�tigte
RETURN= Direktiven nicht versehentlich bearbeitet
werden.
Wird eine falsche Taste gedr�ckt, wird diese auf den
ersten Blick nicht akzeptiert, d.h. man darf die Eingabe
solange wiederholen, bis eine g�ltige Taste gedr�ckt ist.
Ist mittels TIMEOUT= eine Zeitschranke vereinbart, so
�ndert sich das Verhalten insofern, als da� diese
Schranke mit jedem falschen Tastendruck wieder zur�ck-
gesetzt wird. Wenn aber der Timeout abgelaufen ist,
wird als Default-Antwort switch_answer gew�hlt (das
ist normalerweise <1> und daher wird die erste Marke
angesprungen).
Nun wird es kompliziert:
Angenommen, switch_answer ist per TIMEOUT= umdefiniert
worden: Liegt nach Ablauf des Timeouts die Default-
Antwort im Rahmen der g�ltigen Zahlen (aus '0'..'9'),
so wird die der Zahl entsprechende Marke angesprungen
(womit man MS-DOS MENUDEFAULT= simulieren kann).
Entspricht die Default-Antwort nicht den g�ltigen
Werten, so wird die Default-Antwort genauso zur�ck-
gewiesen, wie echte Tastendr�cke (weil die entsprechenden
Marken nicht angegeben wurden). Der Effekt ist, da� man
trotz Timeout gezwungen ist, die richtige Taste zur
Fortsetzung zu dr�cken.
Hat man bei der SWITCH= Anweisung �berhaupt keine Marken
angegeben, so kommt man nur weiter, indem man <1> dr�ckt
(oder eine <1> als switch_answer nach einem abgelaufenen
Timeout simuliert wird). Nun wird dieses nicht existente
'Label1' angesprungen, im Endeffekt wird die SWITCH=
Zeile �bersprungen. Dies gilt auch f�r andere Sprung-
ziele, die zwar bei SWITCH= definiert sind, aber in der
Datei nicht existieren (auf diese Weise kann man z.B.
Dummy-Sprungziele einf�gen, die wir sp�ter noch ben�tigen
werden).
Dr�ckt man einfach <RET>, so wird automatisch die
switch_answer gew�hlt, also z.B. der per TIMEOUT=
definierte Default-Men�punkt angesprungen.
Damit sind auf den ersten und zweiten Blick alle
M�glichkeiten sinnvoll ausgesch�pft...
Es kommt aber noch besser:
SWITCH= akzeptiert n�mlich eigentlich grunds�tzlich als
Eingaben die Zahlen <0> bis <9>. Dr�ckt man <0>, so wird
dies derzeit intern zu 11 umgesetzt, da aber diese Marke
normalerweise nicht angegeben wird, wird dieser Wert
zur�ckgewiesen. Genauso mit den anderen Tasten.
W�rden jedoch bis zu elf Marken angegeben werden, so
w�rden diese auch tats�chlich angesprungen werden (und
wenn die Marke dann innerhalb der Datei nicht existieren
w�rde, w�rde die Bearbeitung stattdessen mit der Zeile
nach SWITCH= fortgesetzt). Bei diesem Verhalten, da� <0>
zu Label 11, statt zu Label 10 verzweigt, handelt es sich
mit Sicherheit um einen Bug (getestet bis Update 15), der
vielleicht in zuk�nftigen Versionen behoben ist, so da�
die Eingabe von <0> dann die zehnte Marke anspringt.
Aus diesem Grund sollte man sicherheitshalber die zehnte
und elfte Marke immer mit dem gleichen Sprungziel be-
legen.
Marken d�rfen auch mit '/' als Trennzeichen eingeleitet
werden.
M�chte man die Z�hlung der Men�punkte bei 0 statt bei
1 beginnen lassen, ben�tigt aber weniger als 10 Sprung-
ziele, so ergibt sich das Problem, was mit den da-
zwischenliegenden Marken zu tun ist, so da� die Eingaben
oberhalb des gew�nschten Maximums wie gewohnt zur�ck-
gewiesen werden. Hierzu gibt es verschiedene M�glich-
keiten, die jedoch alle nicht besonders sauber sind.
Schlie�lich bedeutet dies in jedem Fall, da� man 11
Marken angeben mu�. Dadurch werden aber <0> sowie
<1>..<9> als Eingaben akzeptiert.
ECHO Men�: Dr�cken Sie <0>..<2>!
:start
SWITCH= l1, l2, d3, d4, d5, d6, d7, d8, d9, l0, l0
GOTO start
:l0
...
EXIT
:l1
...
EXIT
:l2
...
EXIT
GETKEY [=] [comments]
Diese undokumentierte Direktive wartet auf einen Tasten-
druck und setzt daraufhin den Errorlevel auf den Wert
des zugeh�rigen ASCII-Code der Taste (0..255). Um z.B.
den Errorlevel auf 1 zu setzen, mu� man nicht etwa <1>
dr�cken (hat Scan-/ASCII-Code 0231h und damit 31h = 49),
sondern eine <Alt>-NumPad Eingabe vornehmen, hier z.B.
<Alt>=<Alt>+<NumPad1>.
�ber diese M�glichkeit ist es m�glich, auf jede beliebige
Taste (f�r die der Tastaturtreiber ein Zeichen generiert)
unterschiedlich zu reagieren (d.h. die Ebenen mit <Shift>
und <AltGr> werden i. allg. unterst�tzt).
Sofern keine Zeitschranke mittels TIMEOUT= gesetzt wurde
(0), wird effektiv auf den n�chsten Tastendruck gewartet.
Bei laufendem Countdown wird jedoch die Verz�gerung nach
Ablauf der Zeitschranke abgebrochen und stattdessen als
Default-Errorlevel der Wert 0400h = 1024 gesetzt und
nicht etwa eine der mit TIMEOUT= spezifizierten Default-
Antworten. (Ab DR DOS 6.0).
v. Konfigurationsmen�s, Verzweigungen, Blockbildung:
----------------------------------------------------
GOTO [=] [label] [comments]
Gibt man hier ein enicht existierende Marke an, so
springt GOTO= an das Dateiende der CONFIG.SYS, d.h.
die Bearbeitung wird umgehend abgebrochen und ggf.
AUTOEXEC.BAT bearbeitet. Fehlt die Angabe einer Marke
komplett, springt GOTO= zur letzten Marke, die innerhalb
der CONFIG.SYS gefunden werden kann, bzw. falls �berhaupt
keine Marke existiert, wird die Bearbeitung einfach mit
dem n�chsten Befehl fortgesetzt. Es besteht die Gefahr
von Endlosschleifen, die nicht abgebrochen werden k�nnen,
au�er im Single-Stepping <F8> (falls SWITCHES=/N nicht
gesetzt wurde).
GOSUB [=] [label] [comments]
Normalerweise wird bei GOSUB= kein Errorlevel gesetzt,
aber falls keine Marke angegeben wurde oder die ange-
gebene Marke nicht existiert, wird ein Errorlevel 0
gesetzt. In diesem Fall wird die Bearbeitung mit der
n�chsten Anweisung fortgesetzt. GOSUB=/RETURN= wirkt
nicht bis in die Verzweigung in andere Dateien (CHAIN=)
hinein.
RETURN [=] [errorlevel] [comments] errorlevel=<0>..65535
Nimmt die Bearbeitung mit der Zeile nach dem letzten
GOSUB= bzw. SWITCH= wieder auf (kann auch verschachtelt
werden).
Allerdings bietet die Direktive noch einige undokumen-
tierte Spezialit�ten, die neue M�glichkeiten er�ffnen:
Es ist m�glich, einen optionalen Errorlevel anzugeben,
der als R�ckgabewert des Unterprogrammblocks angesehen
werden kann.
Gibt man keinen Wert an, so wird der Errorlevel auf 0
zur�ckgesetzt. Dadurch ist eine unbeabsichtigte Beein-
flussung von auf Errorlevel basierenden Verzweigungen
�ber die Grenzen eines Unterprogrammblocks hinaus ausge-
schlossen. Wenn man aber genau diese Funktion ben�tigt,
hat man daf�r die M�glichkeit, explizit einen Wert an-
zugeben. Durch diese Methode werden auch die vielen
m�glichen Errorlevel, die innerhalb eines Unterprogramms
auftreten k�nnen, auf einen Wert, der dann nach au�en
zur�ckgeliefert wird, reduziert. Nur durch diese Re-
duktion ist es auf der n�chsth�heren Ebene m�glich, da�
Doppelbelegungen bewu�t eingeplant oder ausgeschlossen
werden.
Fehlt zu einem RETURN= das vorherige GOSUB= bzw. SWITCH=,
so wird RETURN einfach ignoriert.
CHAIN [=] filespec [comments]
Falls die angegebene Datei existiert, wird die Bear-
beitung der aktuellen 'CONFIG.SYS'-Datei beendet und
in die neue Datei verzweigt. Die diesbez�glichen
M�glichkeiten sind besonders gut f�r schreibgesch�tzte
oder ROM- oder CD-ROM-Laufwerke geeignet (zur Ein-
bindung von CD-ROM-Treibern in CONFIG.SYS siehe auch
Kapitel II.4. bei NWCDEX). Bei Wechsellaufwerken oder
-medien mu� man besonders auf Pfadangaben in DEVICE...=
und INSTALL...= Direktiven achten. Existiert die Datei
nicht, wird die Bearbeitung in der n�chsten Zeile
fortgesetzt.
Mit der Verzweigung in die neue Datei werden alle noch
ausstehenden RETURN= R�cksprungadressen von GOSUB= oder
SWITCH= zur�ckgesetzt.
EXIT [=] [comments]
Die Bearbeitung der aktuellen CONFIG.SYS wird beendet
(auch bei noch ausstehenden RETURN= Anweisungen) und
der via SHELL= spezifizierte Kommandoprozessor mit
dort definierten Parametern geladen. Ein evtl. ange-
gebener Kommentar wird ignoriert; die Angabe eines
Errorlevel ist hier nicht m�glich (vgl. Kommando EXIT
in Kapitel II.11.).
[COMMON] [=] [comments]
Die Gruppen�berschrift [COMMON] f�r allgemeine
CONFIG.SYS Eintr�ge entsprechend MS-DOS Boot-Men�s
(die von Novell DOS nicht akzeptiert werden). Man
sollte diese �berschrift an das Ende seiner CONFIG.SYS
Datei plazieren, damit Installationsprogramme hier ihre
notwendigen Einstellungen eintragen, die man dann leicht
an die entsprechenden Stellen in den Novell DOS Boot-
Men�s platzieren kann. Novell DOS behandelt diese
Direktive exakt wie einen Kommentar.
vi. Fehlermanagement:
---------------------
ERROR [=] [errorlevel] [comments] errorlevel=0..65535
Diese undokumentierte Direktive setzt - sofern ange-
geben - den Errorlevel auf den angegebenen Wert. Damit
ist die bewu�te Beeinflu�ung nachfolgender ONERROR= etc.
Befehle m�glich (ab DR DOS 6.0) und in Kombination mit
ONERROR= ist es ebenfalls m�glich, die vielen unter-
schiedlichen m�glichen Codes durch gezielte Fallunter-
scheidungen auf wenige Codes zu reduzieren.
(In Batchjobs kann man mit einer undokumentierten
Option des EXIT-Kommandos ebenfalls explizit Errorlevel
setzen, allerdings nur im Bereich von 0..255, vgl.
Kapitel II.11.)
ONERROR [=|>|<|<>|>=|<=|=>|=<|==] value directive [params]
relation= <=>
value = 0..65535 <no default>
Diese leistungsf�hige undokumentierte Direktive erlaubt
das Ausf�hren beliebiger Direktiven in Abh�ngigkeit vom
aktuell eingestellten Errorlevel (analog zu ?=).
Dabei sind beliebige Relationen (mit den Zeichen = > <)
zwischen dem Errorlevel und dem angegebenen Wert value
auswertbar. Wenn die Bedingung erf�llt ist, wird die
angegebene Direktive ausgef�hrt (dies k�nnte z.B. eine
weitere ONERROR= Anweisung (die Bedingungen werden dann
mit einem 'logischen AND' verkn�pft), ein GOTO= oder
eine beliebige andere Anweisung sein), sonst wird die
Bearbeitung in der n�chsten Zeile fortgesetzt.
Ist keine Relation angegeben, so wird '=' angenommen,
ist kein Wert angegeben, so wird die Bearbeitung mit
der n�chsten Anweisung fortgesetzt. Ist die auszu-
f�hrende Direktive nicht definiert, wird die Bearbeitung
ebenfalls in der n�chsten Zeile fortgesetzt (bzw. eine
Fehlermeldung ausgegeben).
Auf diese Weise sind z.B. Abfragen der folgenden Form
m�glich:
YESCHAR=J
TIMEOUT=10,N
:start
INSTALL=myprog.exe
ONERROR=0 GOTO skip
ONERROR>10 ONERROR<>17 ONERROR<=30 GOTO skip
ECHO Fehler aus 1..10, 17, 31..65535 ist aufgetreten!
? "Nochmal versuchen?" GOTO start
:skip
Wie die Fehlercodes bei den einzelnen CONFIG.SYS Direk-
tiven im Detail gesetzt werden, ist in diesem Kapitel
bei den jeweiligen Direktiven beschrieben.
(In Batchjobs sind �hnliche, wenn auch lange nicht so
flexible Abfragen von Errorleveln �ber das altherge-
brachte IF ERRORLEVEL m�glich, vgl. Kapitel II.11.)
---------------------------------------------------------------------------
III.2. Undokumentierte M�glichkeiten von LASTDRIVE= : [97-05-01]
================================================================
Stichworte: CONFIG.SYS, LASTDRIVE=, DR DOS, 27-32 Laufwerke, MAP,
IPX/NETX, ODI, NCP, UNC, SUBST, 4DOS
Wahrscheinlich schon l�nger (definitiv aber mit dem Update 11 von
Novell DOS 7, definitiv noch nicht mit der Originalausgabe von DR DOS
6.0 von 1991) ist es m�glich, mehr als 26 Laufwerke entsprechend den
Buchstaben A: bis Z: zu definieren. Dies wurde vor allem deshalb
implementiert, um den Engpa� bei der Verwendung zus�tzlicher Netz-
laufwerke (MAP) zu mildern.
Eine derartige M�glichkeit war schon immer (undokumentiert) gegeben,
wenn die Novell Netz-Client-Software IPX/NETX geladen wurde. Die Netz-
Shell NETX legte sich dabei wie eine Schale um den DOS-Kern (insbe-
sondere INT21h). Da so alle Calls erst durch diese Shell gefiltert
wurden (Front-End-Hooks), war es m�glich, f�r Netzlaufwerke auf die
'Buchstaben' [ bis ` auszuweichen (und dort - weil nicht alle Programme
derartige Eingaben �berhaupt unterst�tzen - wenigstens die Search-
Mappings zu verstauen).
Seit einiger Zeit versucht Novell massiv als Ersatz f�r die v�llig
veraltete IPX/NETX Kombination ODI-Treiber mit einem auf der VLM-Technik
(von NetWare 4.0 und PNW 1.0) basierenden Net-Requester durchzusetzen.
Dadurch wird nun der Umadressierer (INT2Fh/AH=11h) bedient (und die Shell
und das propriet�re Interface via INT21h (NCP - Novell Core Protocol)
wird �berfl�ssig) und mu� ggf. nur noch aus Kompatibilit�tsgr�nden f�r
alte Programme mittels NETX.VLM geladen werden. (Der Umadressierer, auch
Redirektor genannt, ist ein Back-End-Device.)
Hierf�r wird normalerweise eine Einstellung LASTDRIVE=Z in der
CONFIG.SYS erforderlich, siehe Kapitel III.1 und II.4. bei NWCDEX.
Soweit die Theorie.
In der Praxis bedeutet dies, da� - wenn man diese zus�tzlichen Lauf-
werke vorher genutzt hat - man nach der Umstellung mit weniger Lauf-
werken auskommen mu�. Dies kann bei gro�en Netzen mit vielen Mappings
oder komplexen Konfigurationen mit vielen Substitut-Laufwerken etc.
zu Engp�ssen f�hren, da nicht genug Buchstaben bereitstehen.
Aus diesem Grund hat Novell die Syntax der Direktive LASTDRIVE so er-
weitert, da� dort f�r noch gr��ere Laufwerksbuchstaben als Z auch Zahlen
angegeben werden k�nnen. (Und mit MS-DOS 7 hat auch Microsoft diese und
alle weiteren pfiffigen Erg�nzungen im CDS-Support von Novell DOS 7
�bernommen, allerdings auch dort undokumentiert.)
Die vollst�ndige Syntax lautet:
LASTDRIVE [=] A..Z | 1..32
(auch bei MS-DOS 7; bei fr�hen Ausgaben von Novell DOS 7 - irgendwo
vor Update 14 - war hingegen als Zahlenangabe nur 27..32 erlaubt!)
Beispiele: ABCDEFGHIJKLMNOPQRSTUVWXYZ[\]^_`
LASTDRIVE=Z -> 26 Laufwerke A: ... Z:
LASTDRIVE=32 -> 32 "" A: ... `:
Interessanterweise ist die Verwendung dieser Laufwerke nicht auf
NetWare-Anwendungen beschr�nkt, man kann auch ganz normal unter DOS
damit arbeiten, und zwar auch ohne, da� daf�r die Netzwerk-Software
geladen werden m��te!
(Hinter der Angabe es Laufwerksbuchstabens k�nnen weitere Zeichen folgen,
so da� auch eine Angabe A: erlaubt ist.)
Ein funktionierendes Beispiel (unter COMMAND.COM):
SUBST [: c:\dos
[:
DIR
In der Auflistung mit SUBST erscheinen diese Laufwerke allerdings nicht,
�hnliche Beschr�nkungen d�rften auch einige andere Tools und Programme
haben, die solche Buchstaben als 'Fehler' abfangen.
Leider gibt es bei 4DOS Probleme mit diesen Laufwerken (besonders
^: und `:), da die Buchstaben '^' und '`' hier besondere Bedeutung haben.
Zwar kann man dies bei 4DOS mit SUBST %=`: c:\dos umgehen, aber diese
Schreibweise ist nicht mit der Syntax von COMMAND.COM kompatibel.
Egal wie man auch versucht, die Beschr�nkung zu umgehen, es ist mit 4DOS
nicht m�glich, auf diese Laufwerke zu wechseln. Hierzu mu� man - wenn
auch nur tempor�r - Novells COMMAND.COM verwenden. Auch intern kommt
4DOS nicht mit dem Laufwerk `: zurecht (getestet mit 4DOS 5.5c).
Offenbar hat sich das Verhalten von Novells COMMAND.COM bez�glich der
Laufwerke oberhalb von 26 mit Update 15 (Januar 1996) leicht ver�ndert:
Wurden diese Laufwerke vorher exakt wie die anderen Laufwerke behandelt,
d.h. ohne eine Belegung mit SUBST oder MAP wurden sie in jedem Fall mit
"Ung�ltiger Laufwerksbuchstabe" zur�ckgewiesen, so sieht die Situation
jetzt etwas anders aus:
Nicht 'belegte' Laufwerke oberhalb von Z: werden zwar normalerweise
immer noch zur�ckgewiesen (etwa bei DIR [:), das 'Wechseln' auf ein
solches Laufwerk ist hingegen m�glich. In diesem Fall erscheint dann
statt der Pfadangabe eines $p Prompts die Zeichenkette "Aktuelles
Laufwerk ist nicht mehr g�ltig", und das ehemals aktuelle Laufwerk
'schimmert' sozusagen durch (DIR, CD auch mit Unterverzeichnissen,
aber ohne die Angabe eines Wurzellaufwerks etc.), d.h. alle Pfad-
ver�nderungen etc. beziehen sich auf das zuletzt g�ltige aktuelle
Laufwerk, obwohl der Laufwerksbuchstabe selbst nicht mehr aktuell ist.
Bei einigen Befehlen springt der Laufwerksbuchstabe aber auch wieder
auf das alte aktuelle Laufwerk um.
Es gibt aber - nur nebenbei erw�hnt - auch noch zwei M�glichkeiten,
Netzlaufwerke direkt anzusprechen: Die NetWare-Ressourcen-Syntax und
die Universal Naming Convention (UNC), die in Kapitel VI.10. erl�utert
werden.
---------------------------------------------------------------------------
III.3. Verhalten von ECHO= :
============================
Stichworte: CONFIG.SYS, ECHO=, Boot-Men�s, Direktiven
Der Befehl ECHO kann - wie schon lange bei DR DOS gewohnt - auch in
CONFIG.SYS verwendet werden. Allerdings funktioniert er hier etwas
anders, siehe auch Kapitel III.1. (und IV.1.).
a) Normalerweise schreibt die Syntax f�r CONFIG.SYS Direktiven ein
Gleichheitszeichen vor: Direktive=Wert.
Dieses Gleichheitzeichen kann allerdings h�ufig weggelassen werden,
solange ein Leerfeld f�r eine Abgrenzung sorgt. Daraus entsteht aber
eine kleine Einschr�nkung. Die Direktive 'ECHO' erwartet n�mlich
(entgegen der Gewohnheit) optional auch ein Gleichheitszeichen,
d.h. soll die Ausgabezeichenkette mit einem Gleichheitszeichen
beginnen, so wird dieses als syntaktisches Element interpretiert
und weggelassen, d.h. man mu� dieses Zeichen verdoppeln:
Statt Ausgabe:
ECHO Hallo Benutzer! Hallo Benutzer!
ECHO =============== ==============
mu� man also schreiben: um zu erhalten:
ECHO Hallo Benutzer! Hallo Benutzer!
ECHO ================ ===============
weil die Zeile eigentlich so interpretiert wird:
ECHO [=] Hallo Benutzer!
ECHO [=] ==============
Dies mu� man insbesondere bei der Gestaltung von Boot-Men�s beachten.
b) 'ECHO.' zur Ausgabe einer Leerzeile funktioniert nicht.
Stattdessen kann man einfach 'ECHO' oder (s.o.) 'ECHO=' schreiben.
---------------------------------------------------------------------------
III.4. Hinweise zu DEVICE=/DEVICEHIGH= : [96-06-11]
===================================================
Stichworte: CONFIG.SYS, DEVICE, .SYS/.COM/.EXE, INSTALL, Region-Support
Die CONFIG.SYS-Befehle DEVICE=/DEVICEHIGH= sind eigentlich daf�r vorge-
sehen, .SYS-Treiber zu laden. Da sich das Format aber nur gering von
.COM/.EXE-Programmen (die als TSR ebenfalls Treiber sein k�nnen) unter-
scheidet, lassen sich auch solche Programme ohne R�ckfrage hochladen.
Dies sollte man jedoch nur dann mit DEVICE=/DEVICEHIGH= durchf�hren,
wenn dies ausdr�cklich vom Treiberhersteller erlaubt wird (der Treiber
mu� einen 'dualen' Header haben), ansonsten wird das System abst�rzen.
Ausweichm�glichkeit:
- .SYS-Version des Treibers verwenden, oder falls nicht vorhanden:
- Mit INSTALL=/INSTALLHIGH= hochladen!!!
Besonders zu beachten ist, da� Novell DOS DEVICE[HIGH]=/INSTALL[HIGH]=
Direktiven in der Reihenfolge abarbeitet, in der sie in der CONFIG.SYS
vorkommen. Dies ist �u�erst praktisch, da man so auch TSR-Treiber (per
INSTALL[HIGH]=) vor Ger�tetreibern (per DEVICE[HIGH]=) laden kann. Bei
MS-DOS werden zuerst die DEVICE[HIGH]= und erst danach die INSTALL=
Direktiven abgearbeitet, was h�ufiger zu ziemlichen Schwierigkeiten
bei der Bestimmung der optimalen Ladereihenfolge mit sich bringt.
Die Direktive DEVICEHIGH= unterst�tzt (undokumentiert) noch zus�tzliche
Parameter, die das Hochladen steuern.
SIZE=size Teilweise undokumentierte Option f�r DEVICEHIGH= analog zu
der Option von MS-DOS 5.0, die auch bei MS-DOS 6.x (dort
allerdings wieder undokumentiert) noch vorhanden ist.
Diese Option erlaubt die Angabe einer Gr��e size (hexa-
dezimal), die minimal in UMBs vorhanden sein mu�, damit
DOS den Treiber hochl�dt. Ist soviel Speicher in den UMBs
nicht (mehr) vorhanden, wird der Treiber automatisch in den
Basisspeicher geladen. Diese Option ist dann wichtig, wenn
ein Treiber w�hrend seiner Initialisierung mehr Speicher
ben�tigt, als die Dateigr��e oder die Headerinformationen
vermuten lassen (Ger�tetreiber k�nnen nicht ohne Weiteres
nachtr�glich mehr Speicher allozieren). Ist der Treiber dann
n�mlich bereits in die UMBs geladen und steht der zus�tzliche
Speicher nicht zur Verf�gung, kann die Initialisierung des
Treibers eventuell ganz versagen.
Achtung: Die Angabe der Gr��e ist willk�rlich (00000..FFFFF
in Bytes), d.h. mu� nicht der tats�chlich vom Treiber be-
n�tigten Menge entsprechen (sinnvolle Anwendung setzt aller-
dings voraus, da� man hier den wirklichen Bedarf angibt).
Wird vom Treiberhersteller keine Angabe gemacht, kann man
meistens mit DEVICE= und anschlie�endem MEM den n�tigen
Speicherbedarf f�r DEVICEHIGH= ermitteln. Der angegebene
Wert wird intern auf Paragraphen aufgerundet (1 Paragraph =
16 Bytes). Die Syntax lautet:
DEVICEHIGH [SIZE=xxxx] =driver [driverparameter]
/L:region[,minsize][;[...]]
/S
Diese MS-DOS MEMMAKER-Optionen werden aus Kompatibilit�ts-
gr�nden akzeptiert und ausgewertet, hatten aber bei Novell DOS
7 bis vor Update 14 keine Funktion, da Novell DOS keinen
Region-Support bot. Mit Update 14 (sicher jedoch Update 15)
wurde diese Funktionalit�t nachger�stet und arbeitet genauso
wie bei MS-DOS (siehe Kapitel V.7.).
Besonders tragisch ist die vorher fehlende Unterst�tzung
nicht, da die Speicherverwaltung auch ohne MEMMAKER, SIZER
und CHKSTATE erheblich komfortabler (mit SETUP, MEM und
MEMMAX) arbeitete und unabh�ngig von Region-Support schon
gleiche oder bessere Bilanzen brachte.
Ist der UMB-Speicher in mehrere getrennte Bl�cke fragmentiert
(z.B. bei Verwendung des Video-Speichers als UMB-Bereich), so
wird ein Programm normalerweise in den Block mit dem gr��ten
verf�gbaren Speicher geladen, um dem Programm m�glichst viel
Speicher zur Verf�gung zu stellen und einer Fragmentierung der
einzelnen Bl�cke vorzubeugen. In Einzelf�llen ist dies aber
nicht die optimale Wahl. In solche F�llen ist es m�glich, �ber
die Angabe der Option /L: mit einer Bereichsnummer x als
Parameter genau einen UMB-Bereich zu definieren (/L:x), in den
das Programm geladen werden soll. Kann das Programm mehrere
getrennte Bl�cke (y,z) verwenden, ist auch die Angabe weiterer
Bereiche m�glich, die dann f�r das Programm freigeschaltet
werden (/L:x;y;z). Fehlt die Angabe zus�tzlicher Bereiche,
kann das Programm nur den angegebenen Bereich verwenden.
Sich selbst hochladende Programme k�nnen diese Sperrung von
UMB-Bereichen allerdings umgehen (getestet mit Update 15).
Die Nummerierung der UMB-Bereiche (sog. Regions) beginnt von
unten nach oben. Die Z�hlung beginnt bei 1. Jeder Bereich
endet immer dort, wo ein Bereich ausgeschlossen wird
(/EXCLUDE) oder aus anderen Gr�nden nicht zur Verf�gung
steht (etwa BIOS-ROM). Der konventionelle Speicher und die
HMA werden nicht mitgez�hlt. Die Bereichsnamen und Gr��en
kann man mit MEM /A herausfinden, allerdings werden sie dort
nicht explizit angegeben, siehe auch bei MEM.BAT /FREE in
Kapitel IV.5.
Ist der UMB-Speicher nicht fragmentiert (d.h. existiert nur
ein zusammenh�ngender erlaubter Bereich unabh�ngig von evtl.
fragmentierten freien Bereichen innerhalb dieses Bereichs),
so hat dieser logischerweise die Nummer 1.
Gibt man eine Zahl an, die gr��er als die tats�chliche Anzahl
der UMB-Regions ist, so wird das Programm trotz DEVICEHIGH=
in den konventionellen Speicher geladen.
Der Bereich 0 entspricht dem konventionellen Speicher. Bis vor
Update 14 wurde ein Programm bei Angabe der Option /L:0 trotz
DEVICEHIGH= auch tats�chlich in den konventionellen Speicher
geladen, ab Update 14 wird die Angabe /L:0 offenbar ignoriert,
so da� der Treiber so in UMBs geladen wird, als h�tte man die
Option nicht angegeben (bei DEVICEHIGH=, nicht aber bei LH).
Optional kann f�r jeden der Bereiche auch eine minimal
freie Gr��e angegeben werden, die verf�gbar sein mu�, um
diesen Bereich auch tats�chlich zu verwenden. Die Angabe
der Gr��e minsize mu� dabei dezimal erfolgen (im Gegensatz
zu SIZE=size).
M�chte man ausschlie�en, da� ein Treiber mehr als eine
minimale Gr��e an Speicher verwendet, kann man zus�tzlich
die Option /S benutzen, die OHNE Leerfeld an die /L:...
Anweisung angeh�ngt werden mu� (sonst wird die Zeile von
Novell DOS nicht akzeptiert). Dadurch wird der erste der
angegebenen Bereiche f�r die Dauer des Ladevorgangs des
Treibers auf die Gr��e minsize verkleinert, so da� der
Treiber keine Chance bekommt, mehr Speicher zu verwenden.
(In gewisser Weise arbeiten /S und SIZE= also gegenl�ufig.)
Syntax:
DEVICEHIGH= [/L:region[,minsize][;region[,minsize][;...]]]
[/S]] =driver [driverparameter]
Die Optionen /L: und /S stehen auch beim Kommando HILOAD/LH/LOADHIGH,
(nicht aber bei INSTALLHIGH) zur Verf�gung. Im Gegensatz zu DEVICEHIGH=
kann man hier auch Memory-Region 0 angeben, die entspricht dem kon-
ventionellen Speicher. Das Gleichheitszeichen nach dem Hochladekommando
und vor dem Programmnamen ist nicht zul�ssig.
---------------------------------------------------------------------------
III.5. M�glichkeiten von INSTALL= : [96-12-23]
==============================================
Stichworte: CONFIG.SYS, TSR, Tempor�res Laden nicht residenter Programme
Neben der �blichen Funktion zum Laden von TSR-Programmen bereits inner-
halb der CONFIG.SYS kann man dieses Kommando auch benutzen, um nicht-
residente Programme zu laden (sofern diese mit dem noch nicht komplett
hochgezogenen System bereits zurechtkommen). Damit ist es m�glich, �ber
solche Programme bereits sehr fr�h bestimmte Systemeinstellungen vor-
zunehmen, die andere residente Treiber/Programme in CONFIG.SYS schon
brauchen. (Au�erdem l��t sich so - nat�rlich nur im Notfall - mancher
Installations- oder Kopierschutz von widerspenstigen Programmen aus-
hebeln. Die Realisierung bleibt der eigenen Phantasie �berlassen... ;-) )
Das Besondere an dieser M�glichkeit ist, da� ein mit INSTALL= geladenes,
nicht residentes Programm danach den belegten Speicher wieder zur Ver-
f�gung stellt. Da� dies der Fall ist, ist leider kaum bekannt, so da�
viele Leute vor scheinbar unvermeidlichen Problemen stehen (oder ver-
suchen, alle Programme erst in AUTOEXEC.BAT zu laden, was mit einer
Reihe von Nachteilen verbunden sein kann).
Zu beachten ist lediglich, da� zum dem Zeitpunkt, wo CONFIG.SYS abge-
arbeitet wird, das System noch nicht komplett steht. Das bedeutet,
da� bestimmte Programme nicht auf diese Art und Weise geladen oder
ausgef�hrt werden k�nnen (etwa NWCDEX, sofern Sie nicht das Utility
INSTCDEX.EXE einsetzen, siehe Kapitel II.4.). Bei DR DOS und Novell DOS
ist das System aber (im Gegensatz zu fr�heren Versionen von MS-DOS)
bereits sehr weit hochgezogen und die meisten internen Schnittstellen
stehen Programmen schon zur Verf�gung.
Zur Verdeutlichung ein triviales Beispiel:
CONFIG.SYS:
REM Der folgende Befehl wird w�hrend der Abarbeitung von CONFIG.SYS
REM ausgef�hrt (d.h. bevor mittels SHELL= ein Kommandoprozessor wie
REM COMMAND.COM geladen wurde), ohne da� der hier tempor�r geladene
REM COMMAND.COM resident bleibt!
INSTALL=c:\nwdos\command.com /c dir c:\*.*
REM Auch der Aufruf von Batchjobs etc. ist m�glich, so da� alle Ein-
REM schr�nkungen der CONFIG.SYS Sprache umgangen werden k�nnen.
INSTALL=c:\nwdos\command.com /c machwas.bat
ONERROR = 1 GOTO routine1
ONERROR = 2 GOTO routine2
�ber undokumentierte CONFIG.SYS Direktiven (siehe z.B. ONERROR= in
Kapitel III.1.) ist auch die Abfrage des erweiterten Fehlercodes oder
Exitcodes nach der Beendigung m�glich, womit flexibel auf Sonderzust�nde
eingegangen werden kann. Und da COMMAND.COM beim Befehl EXIT die Angabe
von Errorleveln erlaubt (siehe Kapitel II.11.), er�ffnen sich ungeahnte
M�glichkeiten.
Es sind sogar Aufrufe wie
INSTALL=c:\nwdos\mem.exe [parameter]
INSTALL=c:\nwdos\debug.exe [parameter]
INSTALL=c:\nwdos\command.com [parameter]
m�glich. Im letzteren Fall wird ein Kommandoprozessor geladen, mit
dem man ganz normal arbeiten kann. Z.B. ist es hierdurch bedingt
m�glich, das System w�hrend der CONFIG.SYS zu untersuchen. Beendet
man den Kommandoprozessor mit EXIT, wird die CONFIG.SYS Datei weiter-
bearbeitet. Allerdings ist zu beachten, da� das Ganze bei COMMAND.COM
nicht r�ckwirkungsfrei funktioniert (wohl aber mit 4DOS). CONFIG.SYS
Einstellungen wie SHELL= oder SET= werden offenbar durch COMMAND.COM
modifiziert, siehe Kapitel III.1.
Da per INSTALL= etc. geladene Programme von der Definition her keine
Ger�tetreiber sind (auch wenn sie vielleicht gleichwertige Funktionen
zur Verf�gung stellen), bekommen die bis dahin definierte Vorab-Umgebung
als Umgebung. Wie man hier Speicher sparen kann, ist bei SET= in
Kapitel III.1. beschrieben.
Dadurch, da� bei DR DOS und Novell DOS die Reihenfolge von INSTALL= etc.
und DEVICE= etc. Direktiven v�llig wahlfrei ist, k�nnen Sie z.B. auch
bestimmte Programme *vor* Ger�tetreibern laden, was unter MS-DOS/PC-DOS
- zumindest mit Bordmitteln des Betriebssystems - schlichtweg unm�glich
ist. Eine prima L�sung zum Debuggen von Ger�tetreibern ist es daher,
im Ger�tetreiber INT 3 Anweisungen einzustreuen, und vor der DEVICE=
Zeile einen Debugger wie z.B. Borlands Turbo-Debugger TD.EXE per
INSTALL= zu laden. Sie k�nnen dann 'online' durch den Ger�tetreiber
tracen, sogar w�hrend dessen Installationsprozedur...
---------------------------------------------------------------------------
III.6. Hinweise zur Vorab-Umgebung in Verbindung mit 4DOS: [96-06-14]
=====================================================================
Stichworte: SET=, COMMAND.COM, 4DOS.COM, SET
Novell DOS 7 (und DR DOS 6.0) wandeln Vorab-Umgebungsvariablen, die
innerhalb der CONFIG.SYS mit SET= belegt wurden, nicht in Gro�buchstaben
um, d.h. sie werden so in der Vorab-Umgebung repr�sentiert, wie sie
geschrieben wurden. Au�erdem werden s�mtliche Zeichenketten, die per SET=
definiert werden, an das Ende der Vorab-Umgebung aufgenommen, auch
wenn diese keinen Wert enthalten oder bereits belegte Variablen ersetzen
w�rden.
Wird am Ende der CONFIG.SYS Behandlung COMMAND.COM geladen, so wertet
der Kommandointerpreter die Vorab-Umgebung aus und baut dabei sein
Master-Environment auf (siehe Kapitel III.1.). Dabei werden die
Variablennamen auch in Gro�buchstaben umgewandelt. Letzteres geschieht
bei 4DOS (zumindest bis 5.52a) nicht.
Normalerweise ist das unkritisch, weil 4DOS bei Variablenexpansionen
sowohl die Variablennamen in der Umgebung, als auch in der Referenz
in Gro�buchstaben umwandelt, d.h. innerhalb von Batchjobs erkennt man
keinen Unterschied (die Auflistung per SET zeigt aber sehr wohl den
Unterschied in der Schreibweise).
Wenn Programme aber direkt auf die Umgebung zugreifen und dabei nicht
auch beide Seiten des Vergleichs in Gro�buchstaben umwandeln, kann es
sein, da� in CONFIG.SYS definierte Variablen auf DR DOS/Novell DOS-
Systemen, auf denen 4DOS.COM ohne COMMAND.COM l�uft, nicht gefunden
werden.
Es gibt noch einen weiteren Unterschied: 4DOS (getestet bis 5.52a)
tastet bez�glich der Vorab-Umgebung die DR DOS/Novell DOS internen
Datenstrukturen nicht an. Sobald COMMAND.COM geladen wird, wird nach
der Auswertung und �bernahme in das Master-Environment die Vorab-
Umgebung in INT21h/4458h, Offset +12h durch den Wert 0 f�r ung�ltig
erkl�rt. 4DOS l��t hier den alten Wert stehen, der aber nun ins Leere
zeigt! Wenn Utilities einen Wert ungleich 0 als Erkennung f�r einen
g�ltigen Pointer auf eine Vorab-Umgebung auswerten, so wird dies
meistens zum Absturz des Rechners f�hren, wenn 4DOS geladen wurde.
Solange 4DOS f�r dieses Problem noch keinen Fix implementiert hat,
hilft folgendes Workaround:
Nachdem 4DOS (ohne zus�tzliches COMMAND.COM) geladen wurde, sollten Sie
an den Anfang der AUTOEXEC.BAT folgende Zeile aufnehmen (siehe auch
Kapitel VII.3.):
@C:\NWDOS\COMMAND.COM /C EXIT> \dev\nul
Dadurch wird kurzzeitig COMMAND.COM geladen und patcht einige interne
Datenstrukturen so, wie dies unter DR DOS/Novell DOS g�ltig w�re. Danach
geh�ren diese Probleme unter 4DOS der Vergangenheit an. Mir ist dies
bisher nur in Verbindung mit der Vorab-Umgebung aufgefallen, es k�nnte
aber gut sein, da� ein solcher unkritischer Aufruf von COMMAND.COM auch
einige andere Dinge gerader�cken kann, die 4DOS aufgrund der Unkenntnis
der internen Datenstrukturen von Novell DOS/DR DOS nicht korrekt anpa�t.
---------------------------------------------------------------------------
III.7. Novell DOS Boot-Men�s aus der Sicht von MS-DOS: [96-05-31]
=================================================================
Stichworte: MENUITEM=, MENUDEFAULT=, INCLUDE=, SUBMENU=, MENUCOLOR=,
[MENU], [COMMON], DEVICE=, INSTALL=, SWITCH=
In Kapitel III.1 wurden die bei Novell DOS (und DR DOS 6) m�glichen
CONFIG.SYS Direktiven zur Konstruktion von Boot-Men�s bereits ausf�hrlich
beschrieben. (Leider unterst�tzt Novell DOS 7 selbst mit Update 15 noch
nicht optional die Boot-Men�s im Stil von MS-DOS 6.)
Zwar sind die M�glichkeiten, die sich �ber Novells Boot-Men�s bieten, um
Gr��enordnungen flexibler als die M�glichkeiten, die MS-DOS hier bietet,
aber leider ergibt sich auch ein Problem mit vielen Setup-Programmen von
Anwendungsprogrammen, die diese Boot-Men�s ignorieren. Im einfachsten
Fall wird die CONFIG.SYS einfach nur falsch ausgewertet oder unpassend
modifiziert, im schlimmsten Fall st�rzen solche Setup-Programme ab (z.B.
das Setup-Programm von GMOUSE 10.20...).
Die sicherste Methode f�r solche F�lle ist es, eine tempor�r zu verwen-
dende CONFIG.SYS Version ohne Boot-Men�s bereitzuhalten. Sofern CHAIN=
mit Ihren Setup-Programmen keine Probleme bereitet, k�nnen Sie die
eigentliche Bearbeitung inkl. der Boot-Men�s auch auf eine andere
'CONFIG.SYS' Datei auslagern. H�ufig hilft es auch, die [COMMON] Gruppe
an geeigneter Stelle in der CONFIG.SYS unterzubringen. Im allgemeinen
halte ich [COMMON] am Ende der CONFIG.SYS f�r die beste Wahl.
Um einen Rechner multibootf�hig zu machen, sollte man aber die Struktur
der Boot-Men�s von Novell DOS und MS-DOS m�glichst stark angleichen, um
eine einfache Wartung der beiden 'parallelen' CONFIG.SYS Dateien zu er-
m�glichen. (Dies wird gerade im Zeitalter von MS Windows95 noch wichti-
ger, damit Novell DOS �ber Boot-Manager wie die von OS/2 oder Linux
(LILO) weiterhin als Alternative neben dem MS-DOS 7 und einem evtl.
anderen MS-DOS ab 5 bestehen bleiben kann.)
Dabei geht nat�rlich ein Gro�teil der Flexibilit�t unter Novell DOS/
DR DOS verloren, aber h�ufig ist dies nicht besonders tragisch.
Zun�chst ist anzumerken, da� bei MS-DOS/PC-DOS einzelne Abschnitte in
CONFIG.SYS mit [name] getrennt werden. Findet MS-DOS beim Start keine
Gruppe mit dem reservierten Namen [MENU] (als Einstiegspunkt), so werden
die �brigen [name] Direktiven ignoriert. Bei Novell DOS ist nur [COMMON]
vorhanden, andere Gruppennamen mit [name] sind nicht erlaubt.
Kann man f�r Ihre Anwendungsf�lle alle Men�abfragen von Novell DOS an
den Anfang der CONFIG.SYS-Bearbeitung verschieben (nur dies ist bei
MS-DOS/PC-DOS m�glich), so kann man eine echte Parallelkonstruktion
vornehmen. Au�erdem ist zu beachten, da� bei MS-DOS/PC-DOS die Treiber
per DEVICE= etc. vor denen per INSTALL= etc. geladen werden, auch wenn
sie in anderer Reihenfolge in CONFIG.SYS stehen (inkl. aller Ver-
schachtelungsebenen in den einzelnen Gruppen). Wollen Sie hier v�llige
�bereinstimmung herstellen, sollten Sie bei Novell DOS zuerst alle
DEVICE= etc. und dann erst die INSTALL= etc. Direktiven auff�hren.
(Dies ist allerdings eine ziemliche Einschr�nkung und bei komplexen
Konfigurationen sehr un�bersichtlich und meistens nicht n�tig.)
Im folgenden werden die Novell DOS M�glichkeiten aus der Sicht von
MS-DOS/PC-DOS Boot-Men�s beleuchtet:
i. [MENU], [COMMON], MENUITEM=, MENUDEFAULT= :
----------------------------------------------
Ein MS-DOS 6 CONFIG.SYS Boot-Men� wie
[MENU]
MENUITEM=def, Basiskonfiguration
MENUITEM=std, Standardkonfiguration
MENUITEM=min, Minimalkonfiguration
MENUDEFAULT=def, 10
[def]
...
[std]
...
[min]
...
[COMMON]
kann man unter Novell DOS fast 1:1 umsetzen (sollte in beiden F�llen
direkt am Anfang der CONFIG.SYS stehen, wenn man wirklich die gleichen
Implikationen nachbilden will, abgesehen von SWITCHES=):
:[MENU] ist hier nur ein Kommentar...
CLS
TIMEOUT=10,N,1
ECHO = Novell DOS 7 Boot-Konfiguration:
ECHO = ================================
ECHO
ECHO 1 - Default-Konfiguration
ECHO 2 - Standardkonfiguration
ECHO 3 - Minimalkonfiguration
ECHO
ECHO Bitte dr�cken Sie die entsprechende Taste (Default-Timeout ...
... 10sec) ...
SWITCH [def], [std], [min]
GOTO common
:[def]
SET CONFIG=DEF
...
RETURN
:[std]
SET CONFIG=STD
...
RETURN
:[min]
SET CONFIG=MIN
...
RETURN
[COMMON]
Wie man sieht, wird MENUDEFAULT= mit TIMEOUT= und SWITCH= nachgebildet,
MENUITEM= entspricht einer Mischung aus ECHO= und SWITCH=. Eine
Gruppe [name] kann man prinzipiell durch eine Kombination aus RETURN mit
einer anschlie�enden Marke :name oder - je nach Geschmack - :[name]
nachbilden.
Die %CONFIG% Variable kann man bei Novell DOS explizit setzen.
Marken bzw. Gruppennamen sollten �brigens nicht l�nger als 8 Zeichen
lang sein, um hier Fehlinterpretationen auszuschlie�en.
Die Gruppe [COMMON] sollte aus verschiedenen Gr�nden leer bleiben
und ganz am Ende stehen. Dadurch werden eine Reihe Probleme abgewendet,
die manche Setup-Programme haben, wenn sie keine Novell DOS Boot-Men�s
verstehen. F�r gemeinsam genutzte Einstellungen bietet sich mit
INCLUDE= alias GOSUB= eine andere M�glichkeit an, nur sollte die
Gruppe [COMMON] hierf�r nicht verwendet werden (in folgendem Beispiel
z.B. [basic]).
ii. INCLUDE= :
--------------
Ein INCLUDE= Block bei MS-DOS entspricht im wesentlichen einem GOSUB zu
einem Abschnitt; bei MS-DOS:
[name]
...
INCLUDE=basic
INCLUDE=extra
...
[extra]
...
[basic]
...
[COMMON]
wird bei Novell DOS zu:
:[name]
...
GOSUB [basic]
GOSUB [extra]
...
RETURN
:[extra]
...
RETURN
:[basic]
...
RETURN
[COMMON]
Ich empfehle, die diesbez�glichen Bl�cke erst *nach* den Bl�cken anzu-
ordnen, die sich mit der Verzweigung der Boot-Men�s befassen (s.u.), und
dabei Bl�cke wie Speichermanager, Festplattenkonfiguration, serielle
Schnittstellen, Video-Konfiguration zu unterscheiden.
iii. SUBMENU= :
---------------
Die Nachkonstruktion von SUBMENU= geschieht wie bei MENUITEM= durch ECHO=
und SWITCH=, nur da� der angesprungene Block selbst wieder ein neues Men�
mit CLS=, ECHO= und SWITCH= aufbaut. Dabei sollte dieses Men� unmittelbar
am Anfang dieses Blocks stehen, damit die Logik identisch zu MS-DOS ist.
Angenommen, in obigem Beispiel w�rde die Standardkonfiguration durch
ein Untermen� ersetzt werden, so w�rde dies bei MS-DOS wie folgt aus-
sehen:
[MENU]
MENUITEM=def, Basiskonfiguration
SUBMENU =std, Standardkonfigurationen
MENUITEM=min, Minimalkonfiguration
MENUDEFAULT=def, 10
[def]
...
[std]
MENUITEM=cfg1, Konfiguration 1
MENUITEM=cfg2, Konfiguration 2
[cfg1]
...
[cfg2]
...
[min]
...
[COMMON]
Bei Novell DOS w�rde daraus ein Men� wie folgt:
:[MENU] ist hier nur ein Kommentar...
CLS
TIMEOUT=10,N,1
ECHO = Novell DOS 7 Boot-Konfiguration:
ECHO = ================================
ECHO
ECHO 1 - Default-Konfiguration
ECHO 2 - Standardkonfigurationen
ECHO 3 - Minimalkonfiguration
ECHO
ECHO Bitte dr�cken Sie die entsprechende Taste (Default-Timeout ...
... 10sec) ...
SWITCH [def], [std], [min]
GOTO common
:[def]
SET CONFIG=DEF
...
RETURN
:[std]
CLS
ECHO = Novell DOS 7 Standard-Konfigurationen:
ECHO = ======================================
ECHO
ECHO 1 - Konfiguration 1
ECHO 2 - Konfiguration 2
ECHO
ECHO Bitte dr�cken Sie die entsprechende Taste (Default-Timeout ...
... 10sec) ...
SWITCH [cfg1], [cfg2]
RETURN
:[cfg1]
SET CONFIG=CFG1
...
RETURN
:[cfg2]
SET CONFIG=CFG2
...
RETURN
:[min]
SET CONFIG=MIN
...
RETURN
[COMMON]
iv. MENUCOLOR= :
----------------
MS-DOS/PC-DOS MENUCOLOR=x[,y] kann man nicht ohne weiteres nachbilden
(vielleicht mit einem per INSTALL= geladenen Utility, das die Farbe
umstellt), aber dies ist auch wirklich reiner Schnickschnack.
###########################################################################
###########################################################################
IV. AUTOEXEC.BAT UND BATCHJOBS:
===============================
---------------------------------------------------------------------------
IV.1. Bug in ECHO. (Bug behoben - getestet 11/1994):
====================================================
Stichworte: ECHO., Linefeed, Wagenr�cklauf, MS-DOS, DATE, Updates
Bei der Programmierung von Batchjobs ist bei fr�hen Versionen von
Novell DOS folgendes Problem aufgetaucht.
Der ECHO-Befehl erzeugt in der Spezial-Syntax 'ECHO.' eine Leerzeile.
Leider weicht das exakte Verhalten bei Novell DOS 7 in diesem Fall
geringf�gig vom Standard ab, was aber gro�e Auswirkungen haben kann:
Statt der Zeichenfolge $0A $0D (f�r Linefeed/Wagenr�cklauf), die bei
MS-DOS �blich ist (oder $0D $0A wie bei NDOS der Norton Utilities),
wird hier die Zeichenfolge $20 $0D $0A (d.h. ein zus�tzliches Leerfeld)
abgeschickt. (Nachbemerkung: Auf einem MS-DOS 6.22 System wurde ebenfalls
ein $20 vorangestellt - trotzdem ist dies wohl nicht repr�sentativ und
sollte nicht vorausgesetzt werden. N�heres wurde nicht untersucht.)
Dies f�hrt bei manchen Batchjobs, die 'ECHO.' als Eingabeumleitung in ein
Programm verwenden, zu Fehlverhalten oder sogar zum H�ngen des Prozesses:
Ein Beispiel f�r MS-DOS und NDOS (nicht NWDOS!):
...
ECHO. | DATE > protokol.dat
...
Der DATE-Befehl bekommt das gew�nschte RETURN und die Bearbeitung wird
ordnungsgem�� fortgesetzt. In PROTOKOL.DAT steht das aktuelle Datum.
Bei NWDOS f�hrt das obige Beispiel zum Aufh�ngen des Rechners, und kann
auf normale Weise auch nicht beendet werden: Der DATE-Befehl wertet das
zus�tzliche Leerzeichen als eine Fehleingabe und erwartet nun aus der
Umleitung (d.h. nicht von der Tastatur) ein g�ltiges Datum. Der DATE-
Befehl kommt �briges gleicherma�en mit der Zeichenfolge $0D $0A wie
auch $0A $0D zurecht, nur nicht mit dem zus�tzlichen $20. Bei NDOS
ergibt sich allerdings ein �hnliches Problem nicht, da hier der DATE-/
TIME-Befehl intern definiert ist und damit den internen Befehl eines
evtl. darunter geladenen COMMAND.COM ersetzt.
Abhilfe f�r NWDOS:
a) Eine Datei ECHO_.INP erzeugen, die NUR die Zeichenfolge $0A $0D
(also LineFeed/Carriage Return) enth�lt.
DATE < echo_.inp > protokoll.dat
b) Ein kleines Utility schreiben, das nur die Zeichenfolge $0A $0D
ausgibt und dieses statt ECHO. verwenden (z.B. ECHO_.EXE).
Ein Test mit dem Update 8 zu Novell DOS zeigte, da� dieser Bug mittler-
weile behoben wurde, Novell DOS verh�lt sich jetzt konform und liefert
nur noch die Folge $0D $0A. Ab welcher Update-Release dieser Bug behoben
wurde, wurde im nachhinein nicht mehr �berpr�ft.
---------------------------------------------------------------------------
IV.2. Fehler bei Abfrage von Variablen, die mehrere Parameter enthalten:
========================================================================
(Bug behoben - getestet 02/1995)
Stichworte: MS-DOS, Batchjobs, Updates, Parameter�bergabe
Bei MS-DOS sind in Batchjobs Abfragen der folgenden Form m�glich:
SET test=param1 param2 param3
IF NOT ""=="%test%" ECHO Test ist definiert!
Bei fr�hen Versionen von Novell DOS f�hrt diese Anweisung meistens zu
einem Syntax-Fehler:
Solange TEST nur einen Parameter (d.h. keine Leerfelder) enth�lt,
funktioniert alles wie gewohnt. Wenn der Wert aber aus mehreren W�rtern
besteht, erscheint der Syntax-Fehler oder die Meldung 'Kommando- oder
Dateiname nicht erkannt'. Novell DOS interpretiert diese Zeile anders
und wertet einen Teil des Wertes bereits als Anweisung aus.
Ein �hnliches Verhalten ist teilweise �brigens auch beim Batch-Prozessor
von MS-DOS 6.0/6.2 erkennbar, trotzdem ergibt sich dadurch keine sinn-
volle Anwendung (siehe MSDOSTIP.TXT).
Wenn paramX aus Zahlen besteht, so wird dies u.U. von Novell DOS
akzeptiert, wenn es auch zu einer falschen Funktion f�hrt.
Die einfachste Abhilfe ergibt sich durch Umstellen der Bedingung, so
da� kein NOT mehr vorkommt. Au�erdem mu� die Bedingung u.U. so gedreht
werden, da� '""==' vorne steht:
SET test=param1 param2 param3
IF ""=="%test%" GOTO skip
ECHO Test ist definiert!
:skip
Mit dem Update 11 zu Novell DOS (das alle bisherigen Fixes vereint)
wurde das Verhalten erneut untersucht. Mittlerweile hat sich die Aus-
wertung des SET-Kommandos diesbez�glich ge�ndert (siehe HISTORY.TXT
im Update), so da� die Probleme nun nicht mehr auftauchen.
---------------------------------------------------------------------------
IV.3. Abfrage von geladenen Ger�tetreibern aus Batchjobs: [96-10-30]
====================================================================
Stichworte: Batchjobs, Ger�tetreiber, Zeichentreiber, Blocktreiber,
IF EXIST, IF DIREXIST, AVAILDEV, \DEV\, Unix
H�ufig steht man in Batchjobs vor dem Problem, da� man bestimmte Ger�te-
treiber als Voraussetzung f�r eine Anwendung ben�tigt, z.B. Maustreiber,
Speichermanager oder Treiber f�r spezielle serielle Karten.
Bisher mu�te man dann einfach alle Treiber aufrufen, was verschiedene
Nachteile hat:
- evtl. werden bereits eingestellte Optionen wieder zur�ckgesetzt
- evtl. wird ein Treiber mehrfach geladen, wenn kein Schutzmechanismus
eingebaut ist
- es kann zu Treiberkonflikten aufgrund der Reihenfolge des Ladens kommen
- kostet Bearbeitungszeit
usw.
Zumindest bei Novell DOS 7 gibt es eine M�glichkeit, in einem Batchjob
die Existenz eines geladenen Ger�tetreibers abzufragen und davon abh�ngig
Entscheidungen zu treffen: Damit kann man die oben angedeuteten Probleme
komfortabel umgehen.
Man mu� zwei Sorten von Ger�tetreibern unterscheiden: Zeichentreiber und
Blocktreiber. Systemtreiber sind zwar keine Zeichentreiber, haben aber
ebenfalls ihr Format.
Zeichenger�tetreiber (ob f�r vordefinierte Ger�te wie CON, PRN, LPT1,
LPT2, LPT3, AUX, COM1, COM2, COM3, COM4) oder f�r spezielle Ger�te wie
M�use (PC$MOUSE) etc. und Blocktreiber (f�r zus�tzliche Laufwerke) werden
�hnlich wie Programme im Speicher verankert und von DOS verwaltet.
Allgemein bekannt ist auch, da� sich auf DOS-Kommandoebene logische
Ger�te vom Typ Zeichentreiber fast wie Dateien verwenden lassen, etwa
COPY a:\text.txt PRN: etc.
Aus diesen Gr�nden ist es auch naheliegend, solche Ger�te �hnlich wie
Dateien abzufragen.
F�r Dateien gilt:
IF EXIST path\filename ECHO Datei 'path\file' vorhanden!
F�r logische Ger�te vom Typ Zeichentreiber gilt:
IF EXIST device ECHO Ger�tetreiber f�r 'device' vorhanden!
wobei 'device' das zu �berpr�fende Ger�t angibt (dies funktioniert
auch unter 4DOS (zumindest auf einem Novell DOS 7 System), trotzdem
sollte man noch eine Sonderbehandlung einbauen, s.u.).
Das k�nnen z.B. folgende sein (\dev\ kann immer vorangestellt werden):
NUL Null-Device (liefert als Eingabe immer EOF und als Ausgabe
schluckt es alle Informationen auf Nimmerwiedersehen).
Im Gegensatz zu den anderen Ger�ten in IBMDOS.COM definiert.
CON Konsole (Ein- und Ausgabe, siehe CTTY Kommando in Kapitel
II.11.), in IBMBIO.COM definiert.
PRN Standarddrucker (i. allg. = LPT1), in IBMBIO.COM definiert.
LPT1 Drucker 1 (Ger�t an erstem parallelem Port).
�blicherweise in der sortierten Reihenfolge 3BCh, 378h und
278h, in IBMBIO.COM definiert.
LPT2 Drucker 2 (Ger�t an zweitem parallelen Port),
in IBMBIO.COM definiert.
LPT3 Drucker 3 (Ger�t an drittem parallelen Port),
in IBMBIO.COM definiert.
AUX Standard-Kommunikationsger�t (i. allg. = COM1),
in IBMBIO.COM definiert.
COM1 Serielle Schnittstelle 1 (�blich ist 3F8h),
in IBMBIO.COM definiert.
COM2 Serielle Schnittstelle 2 (�blich ist 2F8h)
in IBMBIO.COM definiert.
COM3 Serielle Schnittstelle 3 (�blich ist 3E8h),
in IBMBIO.COM definiert.
COM4 Serielle Schnittstelle 4 (�blich ist 2E8h),
in IBMBIO.COM definiert.
Aber es gibt noch viele andere logische Ger�te, die man abtesten kann.
Hier kommen insbesondere per DEVICE geladene Programme in Frage und vor
allem Systemtreiber, die sich i. allg. als Zeichentreiber ausgeben,
obwohl sie keine sind (auf sie kann nicht geschrieben, von ihnen nicht
gelesen werden, d.h. die DOS-Umleitung auf solche Ger�te funktioniert
nicht).
Ein paar relativ weitverbreitete Beispiele:
CLOCK$ Interne Uhr
IDLE$ Dynamische Wartezeiterkennung von TASKMGR (Novell DOS 7),
war auch schon bei DR DOS 5.0+ vorbereitet, wurde aber von
deren Speichermanagern und DR DOS 6.0 TASKMAX nicht
aktiviert. Wenn der TASKMGR als Multitasker l�uft, kann
die Idle-Erkennung mit dem COMMAND.COM internen Kommando
IDLE ON|OFF ein- oder ausgeschaltet werden.
$SECURE$ SECURITY.SYS bei Novell DOS 7
RPL Remote-Program-Loader f�r das Booten von einem NetWare-Server
(auch PNW), ohne da� der Client-Rechner mit eigenen Laufwerken
ausgestatten sein m��te. Die Netzadapterkarte ben�tigt daf�r
ein spezielles Boot-PROM.
LPT4 vierter Drucker, unterst�tzt von CCI Multiuser DOS 7.22 Gold
AUX? serielle Ports, unterst�tzt von CCI Multiuser DOS 7.22 Gold
XMSXXXX0 Extended Memory Manager (XMS) (HIMEM)
EMMXXXX0 Expanded Memory Manager (EMS/EMM) (EMM386/EMMXMA)
EMM$$$$$ ""
QMMXXXX0 Quarterdeck Memory Manager
QEXTXXX0 Quarterdeck Extended Memory Manager
QEMM386$ Quarterdeck 386 Memory Manager
$MMXXXX0 MM-Speichermanager
386MAX$$ 386Max-Speichermanager
EMMQXXX0 Expanded Memory Manager (EMS/EMM), nicht aktiv
EMMXXXQ0 Expanded Memory Manager (EMS/EMM), nicht aktiv
EXTXXX@ manchmal: 'rohes' Extended Memory �ber INT15h??? (NWCACHE)
VCPIXXX0 VCPI-Manager (EMM386/HIMEM/THREADS.SYS)
DPMIXXX0 DPMI-Server (EMM386/HIMEM/DPMI.SYS)
QDPMI$$$ DPMI-Server (QEMM 386)
DPMSXXX0 DPMS-Server, falls per DEVICE= geladen (Novell EMM386, DPMS)
(nicht, wenn durch CLOAKING.EXE bereitgestellt)
CLOAK$$$ Helix CLOAKING-Server (CLOAKING.EXE)
HMALDSYS Helix HMA-Lader
$SIZER$ Helix Treiber zur Ermittlung der Programmgr��e
VMXXXXX0 VM-Manager (MS Windows/TASKMGR ?)
HOOKROM$ Quarterdeck QEMM HOOKROM-Treiber
KSP$UMM Key Softwares Memory Manager
LA$TBYTE Key Softwares "The Last Byte"
SETVERX0
SETVERXX durch SETVER.EXE
PC$MOUSE Mouse Systems Maustreiber ("PC", 3-Tasten-Maus, etc.)
MS$MOUSE Microsoft Maustreiber (manchmal jedoch auch PC$MOUSE)
TC$MOUSE Logitech Maustreiber (meist jedoch auch PC$MOUSE)
gmouse Genius Maustreiber (meist jedoch auch PC$MOUSE)
IFS$HLP$ Installable File System Hilfstreiber (auch WfW)
(MS Windows95/MS-DOS 7 Long-Filename-Support: IFSHLP.SYS)
NET$HLP$ Diverse Netztreiber (TCP/IP, WfW, usw.)
@!NETW!@ Novell NetWare Treiber
PROTMAN$ Microsoft LAN Manager
MSCD001 Default-Name f�r erstes CD-ROM-Laufwerk
OEMCD001 Default-Name f�r einige CD-ROM-Treiber
CDROM Sony CD-ROM Erweiterungen
SMARTAAR SMARTDrive Disk-Cache
_doubleB SMARTDrive Double Buffer Treiber
CACHCMPQ Compaq Disk Disk-Cache
CACHE$$$ HyperDisk Disk-Cache
$$$CACHE IBM Disk-Cache
_Cache__ PC Chips Hard Disk-Cache
CACHE__Q Datamorphics Disk-Cache
@CACHE-X Norton Cache
@CACHE-F Norton Cache (Schnell)
@CACHE-S Norton Cache (Klein)
$ADDSTOR SuperStor Disk-Kompressor
DBLSSYS$ DoubleSpace Disk-Kompressor
DBLSYSH$ MS-DOS Doublespace/Drivespace Hilfstreiber
SCSITAPE Seagate ST-01 Treiber (Brian Antoine)
rocket Ontrack IDE-Festplattenbeschleuniger
VGA-Read Public-Domain-Treiber VGAREAD.EXE (falls per DEVICE=/
DEVICEHIGH= geladen) zum Lesen h�herer Diskettenformate
(VGACOPY)
EGA$ Microsofts EGA.SYS Treiber
MONODISP CON-Bildschirmtreiber f�r MDA-/HGC-Monitor
(Zweimonitorsysteme)
MONO (MONO.SYS/DUALMON.SYS)
CO80DISP CON-Bildschirmtreiber f�r Farbmonitor (Zweimonitorsysteme)
COLOR (COLOR.SYS/DUALMON.SYS)
KBD$BUF$ K3PLUS.SYS/.COM bzw. FreeKEYB-Tastaturtreiber mit erweitertem
Tastaturpuffer sowie MS-DOS Dummy: KBDBUF.SYS
K3PLUS$ �ltere K3PLUS.SYS Versionen
CPQKEYB Compaq Tastaturtreiber
4DOSSTAK 4DOS erweiterter Tastaturpuffer
NDOSSTAK NDOS erweiterter Tastaturpuffer
TDHDEBUG Borland Turbo Debugger
SOFTICE Debugger
NU-MEGA NuMega CodeView Magic
SYSLOAD Periscope Debugger
Um an die Ger�tenamen zu kommen (die von den Dateinamen der Ger�te-
treiber abweichen k�nnen), kann man z.B. MEM /I aufrufen.
Blocktreiber (z.B. RAMDRIVE, TurboDSK, MSCDEX, NWCDEX etc.) haben
i. allg. keinen Namen, ihnen wird stattdessen ein Laufwerk zugeordnet.
Zwei Beispiele f�r Zeichentreiber:
a) NWCDEX nur laden, wenn in CONFIG.SYS auch ein Hardware-Treiber f�r
CD-ROM eingebunden wurde.
REM Das \dev\ ist unter heutigen DOS-Versionen optional:
IF "%@Eval[2 + 2]%"=="4" IF "%@Device[\dev\MSCD001]%"=="0" GOTO no_cd
IF NOT EXIST \dev\MSCD001 GOTO no_cd
@LH NWCDEX /d:MSCD001 /m:32 /l:h
:no_cd
b) Eine Warnung ausgeben, wenn ein f�r eine Anwendung n�tiger Speicher-
manager nicht geladen ist (Pseudo-Zeichentreiber).
REM Das \dev\ ist unter heutigen DOS-Versionen optional:
IF "%@Eval[2 + 2]%"=="4" IF "%@Device[\dev\EMMXXXX0]%"=="0" GOTO error
IF NOT EXIST \dev\EMMXXXX0 GOTO error
REM Anwendung starten (Anwendung ben�tigt EMS-Speicher)
anwendung
GOTO end
:error
ECHO Leider kein EMM-Speichermanager geladen, daher kein EMS-Speicher
ECHO verf�gbar.
ECHO Verwenden Sie z.B. DEVICE=EMM386.EXE in CONFIG.SYS, um passenden
ECHO Treiber zu laden.
:end
Solange es um logische Laufwerke (Blocktreiber) geht, wird man die
Existenz h�ufig mit z.B.
IF DIREXIST f:\ ECHO Laufwerk vorhanden! (nur bei Novell DOS und
4DOS 5.5+) auch Netzlaufwerke!
IF EXIST f:\nul ECHO Laufwerk vorhanden! (auch bei MS/PC-DOS, sowie
nach meinen Erfahrungen auch
bei Novell DOS 7, jedoch nicht
bei sp�ten Versionen von
DR DOS 6.0)
abtesten, sollten jedoch unformatierte (aber vorhandene) Laufwerke auf
diese Art und Weise angesprochen nicht werden (z.B. TurboDSK mit
Laufwerksgr��e 0 oder Treiber, deren Spezialger�te noch nicht initia-
lisiert sind), w�rde eine Fehlermeldung erscheinen. Leider scheint es
in diesem Fall keine Ausweichm�glichkeit zu geben, au�er wenn man f�r
jeden solchen Blocktreiber zus�tzlich noch einen Zeichentreiber mit
einem entsprechenden Namen laden w�rde. Unter 4DOS kann man auch
IF ISDIR f:\ ... verwenden. Eine andere Methode, die Existenz von
Verzeichnissen abzutesten, wird in Kapitel IV.6. angedeutet.
In fr�heren DOS-Versionen gab es eine M�glichkeit, zwischen der
obigen laxen Form und einer sch�rferen Methode zu unterscheiden
(INT21h/3702h und INT21h/3703h 'AVAILDEV'). Heutzutage wird i. allg.
nur noch die laxe Form unterst�tzt, d.h. Ger�te liegen 'virtuell'
in jedem Verzeichnis. Ansonsten m�ssen Sie dem Ger�tenamen noch
\DEV\ (analog zu Unix) voranstellen, um darauf umzuleiten oder um
dessen Existenz zu �berpr�fen.
---------------------------------------------------------------------------
IV.4. Novell DOS Kompatibilit�t unter 4DOS erh�hen: [97-02-22]
==============================================================
Stichworte: Batchjobs, 4DOS, NDOS, Kompatibilit�t
Dieses Kapitel beschreibt verschiedene Tips und Tricks, die angebracht
sind, wenn man Batchjobs nicht nur f�r ein Betriebssystem schreiben
will, aber trotzdem nach M�glichkeit auch erweiterte F�higkeiten etwa
von Novell DOS oder 4DOS nutzen m�chte.
�hnliche Hinweise sind an den entsprechenden Stellen �ber das ganze
Dokument verstreut zu finden und werden dort im jeweiligen Zusammenhang
motiviert und diskutiert. Hier wird eine Zusammenfassung dieser M�glich-
keiten gegeben. Wird der folgende Beispiel-Batchjob (der an eigene Be-
d�rfnisse angepa�t werden mu�) in die Behandlung von AUTOEXEC.BAT ein-
gebunden, werden einige Umgebungsvariablen und Aliase gesetzt, die unter
4DOS fehlende Kommandos von Novells COMMAND.COM ersetzen, �bersetzen
oder zug�nglich machen. Gleichzeitig wird auch noch DR DOS und MS-DOS
supportet (%Ver% mu� manuell gesetzt werden, vgl. Kapitel IV.7.).
Beispiel:
4DOSCOMP.BAT:
@ ECHO off > \dev\nul
ECHO off > \dev\nul
IF NOT ""=="%batdbg%" ECHO %batdbg%
IF NOT "4"=="%@Eval[2 + 2]%" GOTO end
LOADBTM on
REM DR DOS compatibility: --------------------------------------------
IF "DRMDOS"=="%Os%" GOTO drmdos
IF "MDOS"=="%Os%" GOTO drmdos
IF NOT "DRDOS"=="%Os%" GOTO nwdos7
REM This check does not work, if %Ver% is not set manually!!
IF NOT "3.41"=="%Ver%" IF NOT "5.0"=="%Ver%" GOTO drdos6
ALIAS ASSIGN `c:\drdos\COMMAND.COM /C ASSIGN %&`
ALIAS JOIN `c:\drdos\COMMAND.COM /C JOIN %&`
ALIAS MORE `c:\drdos\COMMAND.COM /C MORE %&`
ALIAS SUBST `c:\drdos\COMMAND.COM /C SUBST %&`
ALIAS DRHELP `c:\drdos\DOSBOOK.EXE %&`
GOTO drdos
:drdos6
ALIAS DRHELP `c:\drdos\DOSBOOK.EXE %&`
GOTO drdos
:drmdos
REM Dummy for DR Multiuser DOS 5.1 (%Ver%=5.1, %Os%=DRMDOS) or
REM CCI Multiuser DOS 7 (%Ver%=7.xx, %Os%=MDOS), just to
REM show how to handle this...
:drdos
ALIAS DBG `c:\drdos\COMMAND.COM /C DBG %&`
ALIAS IDLE `c:\drdos\COMMAND.COM /C IDLE %&`
ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`
:nwdos7
REM Novell DOS compatibility: ----------------------------------------
IF NOT "NWDOS"=="%Os%" GOTO opendos
ALIAS NWHELP `c:\nwdos\DOSBOOK.EXE %&`
ALIAS TM `TASKMGR /F /C %ComSpec% /C %&`
ALIAS IDLE `c:\nwdos\command.com /C IDLE %&`
ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
IF NOT "%_4Ver%"=="5.51" IF NOT "%_4Ver%"=="5,51" GOTO no4dos551
REM Avoiding a bug with 4DOS 5.51 (not with 4DOS 5.5a/b/c nor ...
... 4DOS 5.52a):
REM Won't always work :-(
ALIAS MEMMAX `c:\nwdos\COMMAND.COM /C c:\nwdos\MEMMAX %&`
:no4dos551
ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`
:opendos
REM Caldera OpenDOS compatibility: -----------------------------------
IF NOT "OPENDOS"=="%Os%" GOTO msdos
ALIAS CAHELP `c:\nwdos\DOSBOOK.EXE %&`
ALIAS TM `TASKMGR /F /C %ComSpec% /C %&`
ALIAS IDLE `c:\opendos\command.com /C IDLE %&`
ALIAS DELTREE `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ *ECHOS ...
... "DEL /SX %&" %+ *DEL /? %& %+ ELSE %+ *DEL /SX %& %+ ENDIFF`
IF NOT "%_4Ver%"=="5.51" IF NOT "%_4Ver%"=="5,51" GOTO no4dos551
REM Avoiding a bug with 4DOS 5.51 (not with 4DOS 5.5a/b/c nor ...
... 4DOS 5.52a):
REM Won't always work :-(
ALIAS MEMMAX `c:\opendos\COMMAND.COM /C c:\opendos\MEMMAX %&`
:no4dos551
ALIAS LOADFIX `MEMMAX -L>& \dev\nul %+ %& %+ MEMMAX +L>& \dev\nul`
:msdos
REM MS-DOS compatibility aliases: ------------------------------------
IF "DRDOS"=="%Os%" GOTO all
IF "NWDOS"=="%Os%" GOTO all
IF "OPENDOS"=="%Os%" GOTO all
ALIAS MSHELP `c:\dos\help.com %&`
ALIAS SEL `c:\dos\select.exe %&`
ALIAS APP `c:\dos\command /C APPEND`
REM Simulate DR DOS/Novell DOS RENDIR
ALIAS RENDIR `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ ECHOS ...
... "REN /S %&" %+ *REN /? %& %+ ELSE %+ *REN /S %& %+ ENDIFF`
:all
REM For better access to help systems: -------------------------------
ALIAS 4DHELP *HELP
ALIAS NDHELP *HELP
REM For 1DIR+ compatibility: -----------------------------------------
ALIAS 1DIR `SETDOS /l1 %+ 1DIRPLUS`
ALIAS 1D 1DIR
ALIAS 1E `SETDOS /l0`
REM For generally DR DOS/Novell DOS batchjob backward compatibility: -
REM DR DOS 3.41 undocumented BATCH command (guess):
ALIAS BATCH = %%&
REM DR DOS 5.0+/Novell DOS Erase commands:
ALIAS ERA ERASE
ALIAS DELQ `*IFF NOT "%@Index[%&,/?]%" == "-1" THEN %+ ECHOS "DEL ...
... /P %&" %+ *DEL /? %& %+ ELSE %+ *DEL /P %& %+ ENDIFF`
ALIAS ERAQ DELQ
REM DR DOS 6.0 undocumented error output handling:
ALIAS ECHOERR `(ECHO %&)>&> \dev\con:`
ALIAS PAUSEERR `(PAUSE %&)>&> \dev\con:`
ALIAS HILOAD LH
REM Fix for Novell DOS/DR DOS "AND" (but may replace message ...
... strings, too)
ALIAS AND IF
REM No fix for Novell DOS/DR DOS "OR" possible.
ALIAS SWITCH `*INKEY /D %%choice %+ *GOSUB ...
... %@Word[%@Eval[%choice%-1]%,%&]% %+ *SET choice=`
REM Misc -------------------------------------------------------------
SET ;=;
REM Workaround for 4DOS 5.51/5.52a TYPE bug with passwords
IF "5.51"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
IF "5,51"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
IF "5.52"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
IF "5,52"=="%_4Ver%" ALIAS TYPE `COMMAND /C TYPE %&`
:end
---------------------------------------------------------------------------
IV.5. MEM /FREE und /MODULE bei Novell DOS nachr�sten: [96-07-14]
=================================================================
Stichworte: MEM, Internationale Batchjob, Greeting_Time
In Kapitel II.4. wird beschrieben, da� Novell DOS' MEM Befehl die
von MS-DOS bekannten Optionen /FREE und /MODULE=<name> fehlen, obwohl
Novell DOS 7 ab Update 14 UMB-Memory-Regions unterst�tzt. Die fehlenden
Parameter kann man aber mit dem beiliegenden Batchjob leicht nachr�sten
(lediglich die Syntax von /MODULE=<name> ist leicht eingeschr�nkt, denn
zwischen /MODULE und <name> mu� ein Leerfeld vorkommen).
Nebenbei bietet dieser Wrapper auch noch zwei neue Parameter, n�mlich
/REGION zum Auflisten der einzelnen UMB-Regionen und /VECTORS zum Auf-
listen der Interrupt-Belegung, wobei noch verschiedene Kriterien ange-
geben werden k�nnen. Gleichzeitig ist dieser Batchjob auch ein Beispiel
f�r die 'h�here Kunst der Programmierung von Batchjobs' und deshalb
nehmen viele Passagen in diesem Dokument auch aus anderen Gr�nden auf
bestimmte Features in diesem Beispiel Bezug, z.B. Erkennung des aktuellen
SwitChars, Erkennung des DOS-Kernels, Erkennung des Kommandoprozessors,
Erkennung der Landessprache...
MEM.BAT:
> Aufgrund der L�nge dieses Batchjobs wird dieser Batchjob nun nur <
> noch als eigenst�ndige Datei MEM.BAT im Paket mitgeliefert. <
---------------------------------------------------------------------------
IV.6. Batchjobs und Umleitungen: [97-04-23]
===========================================
Stichworte: MEM.BAT, FIND, SORT, MORE, DEL *.*, DATE, TIME, %Temp%,
spezielle Steuerzeichen, tempor�re Dateien
- Unter Novell DOS 7 COMMAND.COM ist es m�glich, die Ein- und Ausgabe-
umleitung nicht nur f�r einzelne Kommandos, sondern auch f�r ganze
Batchjobs zu verwenden (DR DOS 6.0 COMMAND.COM bot diese M�glichkeit
wohl noch nicht).
Ein Beispiel hierf�r gibt der Batchjob MEM.BAT aus dem Kapitel IV.5.
Allerdings mu� man beachten, da� dies nur solange funktioniert, wie
innerhalb des Batchjobs keine weiteren Umleitungen und Pipes ver-
wendet werden, da diese ignoriert werden (Wieso eine Umleitung auf
das Null-Device \dev\nul offenbar nicht st�rt, ist mir noch nicht
ganz klar). 4DOS.COM kann hier nat�rlich wesentlich mehr, denn dort
sind Umleitungen beliebig verschachtelbar...
Andererseits kann man f�r diese Zwecke manchmal auch das Kommando
CTTY verwenden (siehe Kapitel II.11.) und damit sogar die Ausgabe
von AUTOEXEC.BAT 'umleiten'.
- Novells COMMAND.COM (getestet mit Update 15) bietet in Verbindung
mit Umleitungen eine ganze Reihe undokumentierter M�glichkeiten, die
Parameter in der Kommandozeile anzuordnen. Normalerweise geht man
davon aus, da� die Parameter zu einem Kommando, evtl. gefolgt von
einer Umleitung, unmittelbar nach dem Kommando stehen m�ssen. Dem
ist aber nicht notwendigerweise so:
Ein- und Ausgabeumleitungen ('>', '>>' und '<') werden von einem
Dateinamen gefolgt (evtl. noch von einem Pa�wort) und sind damit
eindeutig bestimmt. Deshalb kann man dieses Konstrukt an beliebiger
Stelle anordnen, ohne da� es Probleme mit der Erkennung der Umleitung
geben w�rde, auch in gemischter Reihenfolge mit den Parametern des
Kommandos:
DIR > dummy.txt *.* /W
DIR *.* > dummy.txt /W
> dummy.txt DIR *.* /W
entsprechen also alle dem �blicheren
DIR *.* /W > dummy.txt
Das Pipe-Symbol ('|') kann hiermit allerdings nicht �berwunden
werden und dient (auch) als Trenner zwischen Kommandos (vgl. auch
Kapitel II.11.). Gl�cklicherweise akzeptiert auch 4DOS (5.52a)
diese gemischte Anordnung von Parametern und Umleitungen (und auch
MS-DOS und PC-DOS COMMAND.COM sollen diese Varianten unterst�tzen,
verifiziert habe ich das jedoch noch nicht). F�r OS/2 CMD ist diese
Syntax mit leicht erweiterter Semantik besonders in bedingungsab-
h�ngigen Anweisungen verwendbar.
- Es ist �brigens bei Novells COMMAND.COM (offenbar ebenfalls aus
Gr�nden syntaktischer Kompatibilit�t zu OS/2 CMD) m�glich, eine
Dummy-Umleitung zu verwenden:
DIR *.* > dummy1.lst > dummy2.lst
DIR *.* >> dummy1.lst > dummy2.lst
DIR *.* > dummy1.lst | MORE
Die in diesen Beispielen verwendete Datei DUMMY1.LST wird ignoriert,
d.h. sie wird weder angetastet noch erzeugt, auch nicht als tempor�re
Zwischendatei (der Name f�r diese Zwischendatei w�rde vom Betriebs-
system selbst gew�hlt)! In Wahrheit kann hier ein beliebiger Text
stehen, der �berlesen wird. Diese doppelte Umleitung wird von 4DOS
(5.52a) als Fehler zur�ckgewiesen.
Von Novells COMMAND.COM wird innerhalb eines Blocks nur die jeweils
letzte gleichartige Umleitung benutzt (gilt f�r '>', '>>' und '<').
- Wird das '>'-Zeichen f�r die Ausgabeumleitung bei Novells COMMAND.COM
verdoppelt, wird - wie allgemein bekannt - die Zieldatei nicht ge-
l�scht, sondern der neue Inhalt hinten angeh�ngt. Verdreifacht man das
Zeichen, so wird dies wieder wie *ein* '>'-Zeichen ausgewertet. Ein
vierfaches '>>>>' wirkt wieder wie ein '>>', usw..
Im letzten Punkt unterscheidet sich 4DOS wieder, mehr als ein
verdoppeltes '>'-Zeichen (">>") werden immer als einfaches '>'
gewertet.
- Bei der Programmierung von Batchjobs mu� man beachten, da� Novell DOS
COMMAND.COM (im Gegensatz zu 4DOS/NDOS.COM) die Umleitung einer Zeile
eines Batchjobs auch dann auswertet, wenn am Anfang der Zeile eine
Bedingung steht, die nicht erf�llt ist. Dies kann, besonders in Ver-
bindung mit FIND.EXE, SORT.EXE oder MORE.COM (aber auch DEL *.*, TIME,
DATE etc.), zu schwer auffindbaren Fehlern f�hren.
Zur Verdeutlichung ein Beispiel (Auszug aus einem Batchjob):
...
IF "Bytes"=="%1" DIR *.* | FIND "Bytes"
IF NOT "Bytes"=="%1" DIR *.* | SORT
...
Enth�lt %1 den Wert "Bytes", so wird der erste DIR Befehl problemlos
ausgef�hrt (und FIND extrahiert die Zeilen mit %1). Die zweite Be-
dingung ist allerdings nicht erf�llt, sollte also �bersprungen werden.
Trotzdem h�ngt der Batchjob beim zweiten DIR. Dies liegt daran, da�
zwar die Bedingung nicht erf�llt ist, d.h. das zweite DIR *.* nicht
ausgef�hrt wird, aber die Pipe f�r SORT wird davon nicht beeinflu�t.
COMMAND.COM f�hrt also '| SORT' aus, d.h. SORT wartet ewig auf eine
Eingabe und ein abschlie�endes ^Z aus der Eingabeumleitung. Normaler-
weise l��t sich der Batchjob mit <Ctrl>+<c> abbrechen.
Enth�lt %1 nicht den Wert "Bytes", tritt der gleiche Fehler in der
ersten Bedingung auf. COMMAND.COM f�hrt dann '| FIND "Bytes"' aus,
d.h. FIND wartet ewig auf eine Eingabe.
Abhilfe besteht darin, da� derartige Zeilen mit Umleitungen so
umkonstruiert werden, da� entweder sichergestellt wird, da� Filter
wie FIND, SORT, MORE etc. auf irgendeine Weise ein abschlie�endes ^Z
erhalten oder da� die Zeile, die die Umleitung enth�lt, nicht ausge-
f�hrt wird, wenn dadurch dieser Fehler auftreten kann. Ein Beispiel:
...
IF "Bytes"=="%1" GOTO dir1
IF NOT "Bytes"=="%1" GOTO dir2
GOTO skip
:dir1
DIR *.* | FIND "Bytes"
GOTO skip
:dir2
DIR *.* | SORT
:skip
...
Die gleichen Probleme treten z.B. auch bei Befehlen wie
...
IF "German"=="%1" ECHO J | DEL *.*
...
auf (und sind in diesem Beispiel besonders gef�hrlich). Abhilfe
ist mit folgender Umkonstruktion m�glich:
...
IF NOT "German"=="%1" GOTO skip
ECHO J | DEL *.*
:skip
...
Umleitungen auf z.B. \dev\nul sind aus diesen Gr�nden unkritisch.
- Ein �hnlich gelagerter Fall ist der REM-Befehl. Auch hier wertet
Novells COMMAND.COM aus Kompatibilit�t zu MS-DOS Umleitungen aus,
d.h.
REM | DIR *.*
f�hrt durchaus das DIR *.* aus (siehe Kaptitel II.11.).
- Novell DOS behandelt auch (exotische) Anweisungen wie "DIR /P | MORE"
problemlos (dies galt nicht f�r DR DOS, abgesehen von DR DOS 6.0
Updates nach 1992).
- Ein anderes Problem mit Umleitungen bei Novells COMMAND.COM (nicht
bei 4DOS/NDOS) in Verbindung mit SHARE:
...
ECHO Report something to file > %tmp%\report.$$$
REM If "applic is a batchjob, "applic" shall be called by "CALL" to
REM avoid exiting this batchjob. But: As a result of redirection, a
REM sharing violation occurs here, if "applic" actually is a batchjob.
@CALL applic >> %tmp%\report.$$$
...
Dieses Problem kann umgangen werden, indem man "CALL" durch
"%ComSpec% /C" ersetzt:
...
ECHO Report > %tmp%\report.$$$
REM To avoid sharing violation with COMMAND.COM, call via
@%ComSpec% /C applic >> %tmp%\report.$$$
...
Achtung: Nach dem "/C" ist kein '@'-Zeichen erlaubt, wie man es sonst
(in einem Batchjob oder unter 4DOS/NDOS) einem Kommando vielleicht
voranstellen w�rde! Das '@'-Zeichen vor dem %ComSpec% ist im Prinzip
�berfl�ssig, hat aber unter 4DOS/NDOS eine besondere Funktion.
Ein sehr �hnliches Problem mit Umleitungen, CALL und SHARE existiert
auch bei MS-DOS COMMAND.COM, wenn auch unter leicht anderen Voraus-
setzungen (siehe MSDOSTIP.TXT). Gl�cklicherweise kann man beide
Probleme auf identische Art und Weise aus dem Weg r�umen, so da�
hier keine weitere Fallunterscheidung zwischen MS-DOS und Novells
COMMAND.COM notwendig ist.
- Die Zeichen ">", "<" und "|" sind - abgesehen von der Verwendung in
Umleitungen - verst�ndlicherweise nicht erlaubt.
Es gibt zwei Ausnahmen:
a) Novells erweiterte Syntax des IF Befehls l��t die Zeichen ">" und
"<" auch als 'Gr��er' und 'Kleiner' (auch in allen Kombinationen mit
"=") zu, ohne da� sie dabei als Umleitung interpretiert werden. Da
diese Syntax aber von anderen Kommandoprozessoren nicht unterst�tzt,
sondern fehlinterpretiert wird, sollte man auf diese M�glichkeit
verzichten.
b) Einige Befehle erlauben/erfordern es, die Argumente in doppelte
Anf�hrungszeichen (") einzuschlie�en (z.B. FIND). Innerhalb eines
solchen Blocks werden Umleitungen nicht ausgewertet, d.h.
Konstruktionen wie
DIR *.* | FIND "<DIR>" > dirlist.lst
sind problemlos m�glich (auch bei MS-DOS, und 4DOS/NDOS).
N�heres zu dieser Klammerungsm�glichkeit in Kapitel II.11. und
anderen Methoden zur Verzeichnisabfrage in Kapitel IV.3.
- Das Zeichen "%" ist ebenfalls f�r Variablen (Parameter, Umgebungs-
variablen und Systeminformationskonstanten) reserviert. M�chte man
das Zeichen dennoch ausgeben, mu� man es verdoppeln:
IF ""=="%tmp%" ECHO Die Variable %%tmp%% ist nicht belegt!
Achtung: Unter anderen Kommandoprozessoren kann dies zu Fehlinter-
pretationen f�hren. Weitere Hinweise bez�glich der Ver-
doppelung von % siehe BATTIPS.TXT.
- Manchmal ist es bei Problemen mit Batchjobs, die Umleitungen ver-
wenden, hilfreich, sich im Nachhinein die tempor�ren Dateien mit
UNDELETE zur�ckzuholen und danach zu begutachten.
Die tempor�ren Zwischendateien, die COMMAND.COM bei Umleitungen
automatisch anlegt und nach Gebrauch wieder l�scht, werden im %Temp%\
Verzeichnis abgelegt. Da hierf�r die DOS-API-Funktion zum Erzeugen
tempor�rer Dateien mit eindeutigem Namen verwendet wird, haben diese
Dateien beim Novell DOS (und MS-DOS) Kernel 8 Zeichen lange Namen,
die ausschlie�lich Buchstaben enthalten, und keine Endung. Au�erdem
besitzen sie das System-Attribut. DR DOS hingegen erzeugte Dateien,
die nur Ziffern enthielten. 4DOS benutzt nicht diese API-Funktion und
erzeugt Namen, die sowohl Ziffern, als auch Buchstaben enthalten und
die Endung entspricht als Ziffer offenbar der Verschachtelungstiefe(?).
- Obwohl man �blicherweise Ger�ten, auf die man umleiten m�chte, ein
\dev\ oder jedes beliebige andere Verzeichnis voransetzen kann, gilt
dies unter �lteren DOS-Versionen und Netz-Treibern nicht f�r Netz-
laufwerke. Hier tritt n�mlich das Problem auf, da� keiner sich f�r
derartige Bezeichnungen zust�ndig f�hlt. Ein Beispiel:
Ein Text soll �ber N:\TMP\LPT1 ausgedruckt werden, wobei N:\ ein
Netzlaufwerk sei, etwa:
TYPE text.txt > n:\tmp\lpt1
DOS erkennt nun, da� es sich um ein Netzlaufwerk handelt und gibt
daher die Anfrage an den Netztreiber weiter. Dieser erkennt jedoch,
da� es sich um ein Ger�t handelt und gibt die Anfrage zur�ck an DOS,
das daraufhin eine Fehlermeldung ausgibt.
Im Zuge der VLM-Updates wurde hier eine L�sung geschaffen, insofern,
als da� die Netz-Treiber jetzt nur noch "lpt1" an DOS zur�ckliefern,
und DOS dann im zweiten Anlauf damit zurecht kommt. Auf diese Weise
werden auch die anderen Standard-Ger�te behandelt.
---------------------------------------------------------------------------
IV.7. Spezielle Umgebungsvariablen von Novell DOS/DR DOS: [97-03-26]
====================================================================
Stichworte: Environment, Systeminformationskonstanten
Der Platz f�r Umgebungsvariablen wird w�hrend der Initialisierung von
COMMAND.COM reserviert (Mutterbereich), dazu allerdings vorher der
Parameter /E:xxxx des Kommandoprozessors bei CONFIG.SYS SHELL= heran-
gezogen. Das Setzen und L�schen geschieht z.B. �ber den COMMAND.COM-
internen Befehl SET.
- Vordefinierte Umgebungsvariablen:
Die folgenden ansonsten v�llig 'normalen' Variablen werden automatisch
mit bestimmten Werten belegt, wenn nach der Bearbeitung von CONFIG.SYS
der Kommando-Interpreter COMMAND.COM geladen wird. Einige dieser
Variablen werden nur von DR DOS und Novell DOS unterst�tzt.
%ComSpec% Wie allgemein bei allen DOS-Kommandoprozessoren �blich:
Vollst�ndiger Pfad+Name des aktuellen Kommando-Inter-
preters (COMMAND.COM), z.B. C:\NWDOS\COMMAND.COM.
Der Inhalt dieser Variable h�ngt �blicherweise von dem
Pfad ab, denn man bei der Initialisierung des ersten
Kommandoprozessors angibt (normalerweise C:\, wenn
nicht mittels CONFIG.SYS SHELL= umdefiniert, siehe
Kapitel II.11. und III.1.)
Kann COMMAND.COM nicht gefunden werden, fragt
Novell DOS nach Pfad und Namen zu einer g�ltigen Datei.
Der Pfad dieser Variable wird bei Novell DOS 7 und
sp�ten Updates (ab 1992) von DR DOS 6.0 nicht auf
einen vollen Netz-Pfad erweitert, was verschiedene
diesbez�gliche Probleme l�st.
%Os% Gibt (ausschlie�lich) bei den Kommandoprozessoren
der ehem. Digital Research Betriebssystemfamilie
(COMMAND.COM) den Typ des Betriebssystems (eigentlich
besser: des Kommandoprozessors) aus der 'Digital
Research'-Familie an (f�r DR DOS und Novell DOS sind
die Werte dokumentiert):
- Caldera OpenDOS 7.01 : %Os%="OPENDOS"
- Novell DOS 7 : %Os%="NWDOS"
- DR PalmDOS : ???
- DR DOS 3.40-6.0 : %Os%="DRDOS"
- IMS REAL/32 : ???
- IMS Multiuser DOS : ???
- CCI Multiuser DOS : %Os%="MDOS"
- DR Multiuser DOS : %Os%="DRMDOS"
- Concurrent DOS : %Os%="CDOS"
- Concurrent DOS/386 : %Os%="CDOS386"
- Concurrent PC-DOS : %Os%="CPCDOS"
- DOSPlus : ???
- MS-DOS/PC-DOS : -- (nicht belegt)
- FreeDOS, DOS-C : -- (nicht belegt)
- PTS/DOS, S/DOS : -- (nicht belegt)
W�hrend NetWare-Loginskripten gibt es eine vergleich-
bare System-Informationsfunktion namens %OS, die
mit der Einstellung NET.CFG: NETWARE DOS REQUESTER
DOS NAME=<MSDOS>
(siehe Kapitel VI.12.) korrespondiert und z.B. dazu
dient, unterschiedlichen Laufwerke in Anh�ngigkeit
von der DOS-Version der Arbeitsstation zu mappen.
%Ver% Gibt (ausschlie�lich) bei den Kommandoprozessoren
der ehem. Digital Research Betriebssystemfamilie
(COMMAND.COM) die Versionsnummer des Betriebssystems
(eigentlich besser: die Stufe des Kommandoprozessors
an:
- Caldera OpenDOS 7.01 : %Ver%="7" (das 7.01 bei VER
wird festverdrahtet angeh�ngt)
- Novell DOS 7 : %Ver%="7" (alle Updates,
keine Nachkommastelle!)
- DR PalmDOS : ???
- DR DOS 6.0 : %Ver%="6.0" (alle Updates)
- DR DOS 5.0 : %Ver%="5.0"
- DR DOS 3.41 : %Ver%="3.41"
- IMS REAL/32 : ???
- IMS Multiuser DOS : ???
- CCI Multiuser DOS : %Ver%="7.00", "7.21", "7.22"
- DR Multiuser DOS : %Ver%="5.0", "5.1"
- DOSPlus : ???
- MS-DOS/PC-DOS : -- (nicht belegt)
- FreeDOS, DOS-C : -- (nicht belegt)
- PTS/DOS, S/DOS : -- (nicht belegt)
Ver�ndert man den Inhalt dieser Variable, �ndert sich
auch der Wert der Novell DOS 7 Systeminformations-
konstante %OS_Version% (s.u.), aber umgekehrt �ndert
sich der Wert der in der Umgebung repr�sentierten
Variable %Ver% nicht, wenn man die obige System-
informationskonstante mit einer gleichnamigen 'echten'
Variable �berdeckt.
Achtung: %OS_Version% wird auch von NetWare-Clients
unterst�tzt und liefert dann auch bei *anderen*
Kommandoprozessoren Versionswerte (s.u.)!!!
Die Versionsausgabe des internen Kommandos VER h�ngt
vom Inhalt der Variable %Ver% ab, selbst, wenn man hier
keine Zahl angibt, siehe Kapitel II.11. bei VER!
%Beta% Undokumentiert und nur bei DR DOS 3.41 (vielleicht
noch bei DR DOS 3.40 und 3.42???): Erscheint als
zus�tzlicher Text beim Laden einer tempor�ren Kopie
von COMMAND.COM, und war wohl urspr�nglich f�r zu-
s�tzliche Ausgaben in der Beta-Testphase gedacht,
siehe auch DRDOSTIP.TXT.
- Reservierte Umgebungsvariablen:
Die folgenden Variablen haben keine vordefinierten Werte, m�ssen also
explizit gesetzt werden. Einige dieser Variablen sind allgemeing�ltig
f�r DOS, andere werden (oder wurden) ausschlie�lich von ehem. Digital
Research Betriebssystemen benutzt.
%Path% Allg. Standard; (bei MS-DOS 6.0 - und nur dort -
ausschlie�lich in Verbindung mit "PATH /E");
siehe bei PATH in Kapitel II.11.
%Append% Allg. Standard, "APPEND /E"
%Prompt% Allg. Standard, meist $p$g.
Allerdings bei Kommandoprozessoren von DR DOS 6.0 und
Novell DOS 7 mit allerhand eigenen Erg�nzungen, siehe
bei PROMPT in Kapitel II.1. und II.11.
%Temp% Allg. Standard f�r ein Tempor�rverzeichnis
%HomeDir% Nur bei DR DOS 5.0/6.0: undokumentiert.
%$Cls% Nur bei DR DOS 3.41+ und Novell DOS 7+ COMMAND.COM,
aber undokumentiert. Bei CCI Multiuser DOS 7.22 Gold
f�r MDOS.COM/TMP.EXE dokumentiert:
Kann mit Escape-Sequenz f�r ANSI.SYS f�r den Befehl
CLS belegt werden, �blicherweise leer, dann wird
je nach dem, ob ein ANSI-Treiber installiert ist,
die Sequenz "Esc [2J" ausgegeben oder der Bildschirm
durch Aufruf von BIOS-Funktionen gel�scht. Siehe auch
Kapitel II.11 bei CLS.
%$On% 'RevOn', nur bei DR DOS 3.41+, Novell DOS 7+
COMMAND.COM, aber undokumentiert und standardm��ig
nicht belegt. Bei CCI Multiuser DOS 7.22 Gold f�r
MDOS.COM/TMP.EXE dokumentiert und enth�lt dort
�blicherweise die ANSI-Sequenz "Esc p".
Hat man einen ANSI-Treiber installiert, kann man die
Variable jedoch auch in Singleuser-Varianten verwenden:
Sie spezifiziert eine Sequenz, die vor der Ausgabe
von Dateinamen in TYPE-Auflistungen bei Verwendung von
Wildcards ausgegeben wird. Auf diese Weise kann man
die Dateinamen z.B. farblich hervorheben, einen Seiten-
vorschub ausl�sen, etc. Erlaubt auch die Angabe von
Sonderzeichen �ber die Spezialsyntax \ooo, wobei ooo
f�r die dreistellige Angabe des Zeichencodes als Oktal-
zahl steht (mit f�hrender Null). Siehe auch in Kapitel
II.11. bei TYPE.
%$Off% 'RevOff', nur bei DR DOS 3.41+, Novell DOS 7+
COMMAND.COM, aber undokumentiert und standardm��ig
nicht belegt. Bei CCI Multiuser DOS 7.22 Gold f�r
MDOS.COM/TMP.EXE dokumentiert und enth�lt dort
�blicherweise die ANSI-Sequenz "Esc q".
Hat man einen ANSI-Treiber installiert, kann man die
Variable jedoch auch in Singleuser-Varianten verwenden:
Sie spezifiziert eine Sequenz, die nach der Ausgabe
von Dateinamen in TYPE-Auflistungen bei Verwendung von
Wildcards ausgegeben wird. Auf diese Weise kann z.B.
eine farbliche Hervorhebung (siehe bei %$On%) wieder
aufgeben, etc. Erlaubt auch die Angabe von Sonder-
zeichen �ber die Spezialsyntax \ooo, wobei ooo f�r
die dreistellige Angabe des Zeichencodes als Oktalzahl
steht (mit f�hrender Null). Siehe auch in Kapitel
II.11. bei TYPE.
%PExec% Nur bei DR DOS 6.0 und Novell DOS 7 COMMAND.COM:
Erweiterung f�r PROMPT-Execution $x), siehe auch
Kapitel II.11. bei PROMPT. Im Hilfeschirm der
deutschen Version von PROMPT /? wird der Name der
Variablen f�lschlicherweise als %Exec% angegeben!
%DRDOSCFG% Nur bei DR DOS: Ablagepfad f�r .CFG- und .INI-Dateien
f�r DR DOS Tools z.B. DRDOS.INI usw.
Sollte bei Verwendung von DR VIEWMAX unter Novell DOS
auf den gleichen Wert wie %NWDOSCFG% gesetzt werden,
wo dann auch die alten TASKMAX.INI und VIEWMAX.INI
Dateien liegen sollten.
%NWDOSCFG% Novell DOS 7, analog zu %DRDOSCFG%.
Ablagepfad f�r .CFG- und .INI-Dateien f�r Novell DOS
Tools z.B. NWDOS.INI usw.
%OPENDOSCFG% Caldera OpenDOS (7.01), analog zu %NWDOSCFG%.
Ablagepfad f�r .CFG- und .INI-Dateien f�r Caldera
OpenDOS Tools z.B. OPENDOS.INI usw.
Beim Mischen von Novell DOS 7 und Caldera OpenDOS 7.01
Systemen (z.B. im Rahmen von Updates) sollten sie beide
Variablen entsprechend belegen und beide Konfigura-
tionsdateien NWDOS.INI und OPENDOS.INI im gleichen
Verzeichnis ablegen.
%87% Nur bei DR DOS, nicht bei Novell DOS:
G�ltige Werte: "Y" f�r Ja.
Aktiviert Unterst�tzung f�r Coprozessor und wird
von vielen externen Kommandos unterst�tzt, die mit
Borland C programmiert wurden (z.B. REPLACE.EXE,
SSTORCHR.EXE). Wahrscheinlich nur eine Abfrage der
Borland RunTime-Library und ohne echte Funktion in
den Programmen.
%FBP_User% F�r Novell DOS 7 FastBackup FBX: Name des Benutzers
%NWLanguage% PNW, NetWare: Sprache f�r das \NLS\%NWLanguage%\
Verzeichnis und .MSG-Dateien, z.B. in Gro�buchstaben:
"DEUTSCH", "ENGLISH", usw., siehe auch Kapitel II.16.
Diese Variable kann nicht nur den Namen des Unter-
verzeichnisses von \NLS\ aufnehmen, sondern darf eine
g�ltige relative Pfadangabe enthalten. Angenommen, die
Dateien w�rden sich in Wirklichkeit nicht in
C:\NWCLIENT\NLS\ sondern in C:\NWCLIENT\TEST\ befinden,
k�nnte man %NWLanguage% mit ..\TEST\DEUTSCH belegen.
Siehe auch Kapitel VI.2.
Ist %NWLanguage% nicht definiert oder zeigt auf eine
falsche Position, so wird �blicherweise %Path% ausge-
wertet. Evtl. gab es fr�her einmal eine andere Variable
namens %Language%, jedenfalls taucht dieser Variablen-
name immer wieder in den Hilfemeldungen von PNW auf.
%LoginName% Nur bei Novell DOS 7 COMMAND.COM:
(nicht zu verwechseln mit %Login_Name%!!!).
Falls diese Variable mit einem Wert belegt wird,
wird der jeweils aktuelle Inhalt f�r den Spezial-
Token $u bei PROMPT eingesetzt, siehe Kapitel II.11.
Da die Variablenersetzung nicht bei der Definition des
PROMPTs, sondern jedesmal bei Ausgabe des PROMPTs
erfolgt, lassen sich damit nat�rlich auch andere recht
interessante 'Spielereien' treiben.
%TZ% Nur f�r Novells Personal NetWare 1.0 SNMP-Dienste
(speziell PNWTRAP.VLM):
Angabe der �rtlichen Zeitzone zur sauberen Synchro-
nisation mit entfernten Rechnern, z.B. die Einstel-
lungen der amerikanischen Ost-K�ste:
EST (Eastern Standard Time = Winterzeit) oder
EDT (Eastern DayTime = Sommerzeit).
%TASKMGRWinDir% Undokumentiert, nur vom Novell DOS 7 TASKMGR als
Multitasker verwendet, um SYSTEM.INI zu finden;
siehe Kapitel VII.2.
%WinDir% Von Novells UPDATEW.BAT verwendet (C:\WINDOWS)
(siehe automatisches PNW-Update f�r MS Windows,
Kapitel I.2.)
%PNWDir% Von Novells UPDATED.BAT verwendet (C:\NWCLIENT)
(siehe automatisches PNW-Update f�r DOS, Kapitel I.2.)
%DirCMD% MS-DOS 5.0+ (Default-Kommandos f�r DIR)
bei Novell DOS 7 nur von STACKERs DIR.COM/SDIR.COM,
nicht f�r das 'normale' DIR verwendet, daf�r kann man
aber ersatzweise die Novell DOS/DR DOS DIR-Optionen
/C bzw. /R verwenden, siehe Kapitel II.11.
%CopyCMD% MS-DOS (Default-Kommandos f�r COPY und XCOPY), nicht
bei DR DOS/Novell DOS.
Die Nachbildung mittels Batchjobs scheidet leider
von vornherein aus (nur XCOPY ist ein externes
Kommando), und auch mit DOSKEY-Makros d�rfte ein
Nachbildung schwer fallen, da dort keine aktuellen
Variablenwerte verwendet werden k�nnen. Au�erdem kann
das Parameterformat der Kommandos bei MS-DOS 6.2
leicht abweichen (/[-|+]opt), so da� keine 100%ige
Nachbildung m�glich ist.
%PathTmp% GEM 3.x, f�r temp. Speicherung des Original-Pfades
%Suspend% GEM 3.x, in Verbindung mit Multiuser-Varianten von
DR DOS Betriebssystemen, g�ltige Werte: "ON".
- Neue Systeminformationskonstanten bei Novell DOS 7 COMMAND.COM:
Die folgenden Pseudovariablen - die schon immer w�hrend Login-Skripten
zur Verf�gung standen (zumindest mit den englischen Werten) - lassen
sich unter Novells COMMAND.COM nun in Batchjobs genauso wie Umgebungs-
variablen ansprechen. Allerdings sind sie nicht im Umgebungsspeicher-
bereich repr�sentiert, d.h. die �blicherweise in Programmen verwendeten
Compiler-Bibliotheksroutinen zum Auslesen der Umgebung (wie GetEnv()
bei Borland Pascal) funktionieren hier nicht!
Wenn keine gleichnamige Umgebungsvariable die Systeminformations-
konstante �berdeckt, dann liefern solche Routinen eine leere Zeichen-
kette zur�ck. In Batchjobs lassen sich diese Pseudovariablen jedoch
genauso wie Umgebungsvariablen abfragen.
Novells Bezeichnung 'Konstante' ist auch mi�verst�ndlich, denn es
handelt sich vielmehr um Funktionen, als um Variablen oder Konstanten.
Die jeweiligen Werte werden innerhalb von COMMAND.COM in dem Moment
bestimmt, wann sie gebraucht werden. Da die �bersicht im DOSBOOK
recht fehlerbehaftet ist, folgt hier ein eigener Abschnitt:
%Second% "00".."59"
%Minute% "00".."59"
%Hour% "1".."12"
%Hour24% "00".."23"
%Am_Pm% "am" | "pm"
in allen landessprachlichen Versionen (D, U, S, F, I)
gleich; im DOSBOOK wird f�lschlicherweise f�r die
deutsche Version angegeben: "vorm." | "nachm.".
%Greeting_Time% Je nach landessprachlicher COMMAND.COM Version:
D: "Morgen", "Tag", "Abend"
U: "morning", "afternoon", "evening"
S: "ma�ana", "tarde", "noche"
F: "Bonjour", "Bonjour", "Bonsoir"
I: "giorno", "pomeriggio", "sera"
Diese Funktion ist - aufgrund der jeweils nur drei
m�glichen Werte - auch gut dazu geeignet, um in
internationalen Batchjobs landessprachliche Unter-
scheidungen zu treffen, siehe auch Kapitel II.17.
%Month% "01".."12"
%Month_Name% Je nach landessprachlicher COMMAND.COM Version:
D: "Januar", "Februar", "M�rz", "April", "Mai", "Juni",
"Juli", "August", "September", "Oktober", "Dezember"
U: "January", "February", "March", "April", "May",
"June", "July", "August", "September", "October",
"December"
S: "enero", "febrero", "marzo", "abril", "mayo",
"junio", "julio", "agosto", "septiembre", "octubre",
"noviembre", "diciembre"
F: "janvier", "f�vrier", "mars", "avril", "mai",
"juin", "juillet", "ao�t", "septembre", "octobre",
"novembre", "d�cembre"
I: "Gennaio", "Febbraio", "Marzo", "Aprile", "Maggio",
"Giugno", "Luglio", "Agosto", "Settembre",
"Ottobre", "Novembre", "Dicembre"
Siehe auch Kapitel II.16.
%Short_Year% "xx", z.B. "94", "95", "96", ...
%Year% "xxxx", z.B. "1994", "1995", "1996", ...
%Day% "01".."31"
%Day_Of_Week% Im Gegensatz zur Dokumentation im DOSBOOK werden
die folgenden Werte geliefert, je nach landes-
sprachlicher COMMAND.COM Version:
D: "Son", "Mon", "Die", "Mit", "Don", "Fre", "Sam"
U: "Sun", "Mon", "Tue", "Wed", "Thu", "Fri", "Sat"
S: "dom", "lun", "mar", "mi�", "jue", "vie", "s�b"
F: "Dim", "Lun", "Mar", "Mer", "Jeu", "Ven", "Sam"
I: "Dom", "Lun", "Mar", "Mer", "Gio", "Ven", "Sab"
Siehe auch Kapitel II.16.
%NDay_Of_Week% "1".."7" ("1"=Sonntag)
%Os_Version% �blicherweise "7" bei Novell DOS 7 und Caldera OpenDOS
7.01 COMMAND.COM, aber vgl. auch Variable %Ver% (s.o.)
und %Os_Version% bei NetWare-Clients (s.u.)!!!
Wird eine Variable %Ver% mit einem Wert belegt,
so gibt %Os_Version% den Wert dieser Variable an.
Falls Sie nicht mit COMMAND.COM als Master-Kommando-
prozessor arbeiten, sondern z.B. 4DOS direkt in
CONFIG.SYS SHELL= eintragen, wird die Umgebungs-
variable %Ver% niemals belegt und wenn Sie sie nicht
manuell mit einem Wert belegen, bekommt %Os_Version%
auch keinen internen Defaultwert zugewiesen.
Stattdessen erscheint dann "off", wenn Sie 4DOS
mit COMMAND.COM �berladen und dort %Os_Version%
abfragen...
%ErrorLevel% Laut Novell DOS 7 DOSBOOK, ist aber nicht implemen-
tiert; vermutlich war der Batch-Befehl IF ERRORLEVEL
gemeint (siehe Kapitel II.11.). CCI Multiuser DOS
bietet hingegeben eine Variable %ErrorLvl% an, die
immer dreistellige Werte, d.h. mit f�hrender Null
liefert (vgl. der beiliegende Batchjob ERRORLVL.BAT).
- NetWare-Systeminformationskonstanten bei Novell DOS 7 COMMAND.COM
(nur in Verbindung mit NetWare-Client):
%Login_Name% Login-Name. Funktionierte schon immer mit NETX,
seit Update 14 nun aber auch mit PNW, wenn das
aktuelle Laufwerk ein PNW-gemapptes Laufwerk ist.
Ansonsten erscheint eine leere Zeichenkette.
Siehe auch bei PROMPT in Kapitel II.11.
%P_Station% Physikalische Stationsnummer im Format "????????????".
Korrespondiert i. allg. mit der ID der Netzadapter-
karte und sollte weltweit eindeutig sein, kann aber
�bersteuert werden. Bemerkung siehe %Login_Name%.
%Station% Logische Stationsnummer, wahrscheinlich beginnend
mit 1 f�r den ersten Client-Rechner nach dem Laden
von ODI+VLM. Die Nummern werden vom File-Server ver-
geben und bleiben bis zum Trennen der IPX-Verbindung
bestehen, d.h. auch zwischen �blichen Ein-/Auslogg-
Vorg�ngen. Bemerkung siehe %Login_Name%.
%Full_Name% Undokumentiert (mit Update 14 nachtr�glich dokumen-
tiert). Enth�lt - falls vergeben - den vollst�ndigen
Benutzernamen des eingeloggten Benutzers.
Bemerkung wie bei %Login_Name%, allerdings funk-
tioniert %Full_Name% auch nach Update 14 nur mit
NETX (vielleicht auch mit NETX.VLM).
%Os_Version% Diese Variable wurde - gegen�ber den anderen - schon
vor Novell DOS 7 COMMAND.COM von NETX und innerhalb
von Login-Skripten (%OS_VERSION) unterst�tzt, und
konnte dabei z.B. f�r MS-DOS 5.0 und 6.00 die Werte
"5.00", "6.00" annehmen (zwei Nachkommastellen,
angeblich sogar mit einem 'V' davor, dies aber
definitiv nicht mit Novell DOS!!!). Siehe auch
%Os_Version% bei den Novell DOS 7 Systeminformations-
konstanten und bei %Ver% (s.o.).
Res�mee: Wollen Sie die NetWare-bezogenen Systeminformationskonstanten
nutzen, m�ssen Sie (zumindest tempor�r) Novell DOS 7 COMMAND.COM laden
(4DOS w�rde nur auf den Inhalt echter Umgebungsvariablen reagieren)
*und* (ebenfalls tempor�r) auf ein Netzlaufwerk �berwechseln.
Wieso eigentlich?
Nun, da es m�glich ist, auf mehreren Servern gleichzeitig eingeloggt zu
sein, mu� es irgendein Indiz daf�r geben, welcher Server gerade gemeint
ist, daher mu� - zumindest bei %Login_Name%, %Full_Name% und %Station% -
eine aktuelle 'Zuordnung' zu diesen Server bestehen. Genau zu diesem
Zweck wurden Laufwerksbuchstaben von Netzlaufwerken gew�hlt.
CCI Multiuser DOS Varianten bieten eine gro�e Anzahl �hnlicher
reservierter Variablen und f�hren noch eine weitere Variante von
Variablen ein, die von bestimmten Kommandos gesetzt werden (k�nnen),
dann aber statisch als ganz normale Umgebungsvariablen fungieren, bis
sie erneut aktualisiert oder manuell modifiziert oder gel�scht werden.
Die diesbez�glichen M�glichkeiten sind zu umfangreich, um sie hier
alle aufzulisten. Zur Information sollen hier lediglich die aller-
wichtigsten Variablennamen erw�hnt werden, teilweise anhand eines
Beispiels illustriert:
Alle Treiber:
%Verbose%=None|All|SignOn
%<drivername>Verbose%=None|All|SignOn|NoDetail|[No_Detail]|[AllPaged]
%IAmDebugging%=True|False
Andere Variablen:
%MDOS_Exec%=Off|On
%BootDrv%=c:
%TempDrv%=c:
%Security%=c:\mdos\security
%Spool%=c:\mdos\spool
%User%=001
%ErrorLvl%=000
%CCINet%=3.0
%DRNet%=x.x
%Node%=00
%MDOS<00>% - %MDOS<18>%
Von DATE bzw. TIME jeweils mit Option /E gesetzt:
%Date%=xx/yy/zz
%DOW%=SUN|MON|TUE|WED|THU|FRI|SAT
%DOM%=01..31
%DOY%=001..366
%Time%=hh:mm:ss
%Elapsed%
---------------------------------------------------------------------------
IV.8. Novell DOS aus Batchjobs heraus erkennen: [96-11-12]
==========================================================
Stichworte: COMMAND.COM; 4DOS/NDOS; prim�rer, sekund�rer Kommando-
prozessor; Master-Kommandoprozessor, SHELL=
Im folgenden werden einige Methoden beschrieben, wie man innerhalb von
Batchjobs zwischen prim�ren und sekund�ren Kopien eines Kommando-
prozessors, zwischen Novells COMMAND.COM und 4DOS/NDOS unterscheidet
und wie man unabh�ngig davon feststellen kann, ob 4DOS unter einem
Novell DOS 7 Kernel l�uft oder nicht. Die Beispiele sind in der ange-
gebenen Form nur unter bestimmten Randbedingungen wasserdicht und
sollten als Leitf�den, nicht als fertige Beispiele f�r eigene Implemen-
tierungen f�r die jeweils speziell ben�tigten Voraussetzungen dienen.
i. Novell DOS COMMAND.COM als Master-Kommandoprozessor:
-------------------------------------------------------
Wird der Kommandoprozessor COMMAND.COM direkt nach der Bearbeitung
der CONFIG.SYS Datei geladen (vgl. Direktive SHELL=), d.h. als
Master-Kommandoprozessor, so ist die Erkennung sehr einfach, denn
in diesem Fall definiert COMMAND.COM die zwei Umgebungsvariablen
%Os% und %Ver%, die sich in Batchjobs leicht abfragen lassen.
Solange man diese Variablen nicht explizit l�scht, bleiben sie
auch dann bestehen, wenn man tempor�r einen weiteren Kommandoprozessor
l�dt, egal, ob es sich hierbei um eine weitere Kopie von COMMAND.COM,
oder um eine Alternative wie 4DOS.COM/NDOS.COM handelt, denn beim Start
eines neuen Kommandoprozessors wird die Umgebung des darunterliegenden
Kommandoprozessors normalerweise �bernommen. Dies gilt auch f�r den
Kommandoprozessor von FreeDOS, nicht aber f�r COMMAND.COM von PTS/DOS
alias S/DOS.
Die richtigen Werte in %Os% und %Ver% weisen also auf einen DR DOS oder
Novell DOS Kernel und einen prim�ren COMMAND.COM Kommandoprozessor hin,
allerdings darf man sich nicht 100%ig auf das Vorhandensein spezieller
Funktionen des Kommandoprozessors verlassen, da dieser ja auch mit einem
anderen Prozessor �berladen worden sein kann (4DOS bietet zwar i. allg.
mehr, im Detail aber doch andere Funktionen als Novells COMMAND.COM).
Au�erdem w�re es immerhin m�glich, die Variablen %Os% und %Ver% auch
'per Hand' zu definieren... Bez�glich der m�glichen Werte von %Os% und
%Ver% sei auf Kapitel IV.7. verwiesen.
Beispiel:
IF "NWDOS"=="%Os%" IF "7"=="%Ver%" GOTO nwdos
GOTO skip
:nwdos
ECHO Running a Novell DOS 7 COMMAND.COM as master command processor
ECHO on top of a Novell DOS 7 system kernel!!!
REM (If variables weren't set manually... The currently active command
REM processor must not necessarily be the master command processor...)
IF NOT "4"=="%@Eval[2 + 2]%" ECHO Running Novell DOS 7 COMMAND.COM!!!
REM (Still, must not necessarily be a master command processor...)
:skip
ii. Novell DOS Kernel unter 4DOS 5.0+:
--------------------------------------
Wird als Master-Kommandoprozessor 4DOS oder NDOS (oder andere Alter-
nativen) geladen, werden die beiden Variablen %Os% und %Ver% nicht
automatisch belegt. Das Vorhandensein von 4DOS/NDOS kann man leicht
mit der Abfrage
IF "4"=="%@Eval[2 + 2]%" ECHO Running 4DOS/NDOS now!!!
checken, und im weiteren Verlauf auch ganz speziell auf deren Versions-
nummern etc. abtesten. Unter welchem Betriebssystem 4DOS/NDOS aber
l�uft, ist auf diese Weise nicht herauszufinden. Manchmal reicht es
jedoch nicht aus, den Kommandoprozessor zu identifizieren, sondern
man mu� �berpr�fen, auf welchem Kernel der Kommandoprozessor l�uft.
Ab 4DOS 5.0+ kann man hierzu den Befehl VER zweckentfremden, indem man
die umgeleitete Ausgabe dieses Befehls auswertet:
IF NOT "4"=="%@Eval[2 + 2]%" GOTO skip
REM Only 4DOS/NDOS come here...
IF ""=="%tmp%" SET tmp=%Temp%> \dev\nul
IF NOT ""=="%tmp%" IF NOT EXIST %tmp%\nul MD %tmp% > \dev\nul
IF "NWDOS"=="%Os%" GOTO nwdos
IF NOT ""=="%Os%" GOTO skip
IF EXIST %tmp%\tmp.sem ECHO Warning: "%tmp%\tmp.sem" is locked by ...
... another task. Waiting for release...
BREAK on > \dev\nul
:wait1
IF EXIST %tmp%\tmp.sem GOTO wait1
BREAK off > \dev\nul
REM 4DOS 5.0+ reports "Novell DOS 7" here, but older 4DOS/NDOS releases
REM report Novell DOS 7 as "DR DOS" or just as "DOS 6.0"...
VER | @ CALL FIND "Novell DOS 7" > %tmp%\tmp.sem
IF "0"=="%@FileSize[%tmp%\tmp.sem,b]%" GOTO skip2
:nwdos
ECHO Running 4DOS 5.0+ on top of a Novell DOS 7 system kernel, now!!!
REM (Must not necessarily be a master command processor...)
:skip2
IF EXIST %tmp%\tmp.sem DEL %tmp%\tmp.sem > \dev\nul
:skip
iii. Sekund�res 4DOS unter Novells COMMAND.COM:
------------------------------------------------
Geht man davon aus, da� der Master-Kommandoprozessor COMMAND.COM
die Variablen %Os% und %Ver% belegt hat, reicht f�r eine Abfrage
dieser Konstellation:
IF "NWDOS"=="%Os%" IF "7"=="%Ver%" IF "4"=="%@Eval[2 + 2]%" ECHO ...
... 4DOS/NDOS running as secondary command processor on top of ...
... Novell DOS 7 COMMAND.COM, now!!!
###########################################################################
###########################################################################
V. SPEICHER-MANAGEMENT:
=======================
---------------------------------------------------------------------------
V.1. Bessere Speicherausnutzung durch Option /USE bei HIMEM/EMM386:
======================================================[96-07-12]===
Stichworte: DPMS, EMM386, HIMEM, DPMI, Region-Support, Ein-MegaByte-XTs,
/CHIPSET, /USE, Optimierung, Shadow-RAM, EMS-Seitenrahmen,
Stealth, Speicher-Doppelnutzung
Die Speichermanager von Novell DOS sind sehr leistungsf�hig, insbesondere
in Verbindung mit DPMS (DOS Protected Mode Services).
Gegen�ber den Speichermanagern von MS-DOS und Kompatiblen fehlte bis vor
Update 14 lediglich der sog. Region-Support f�r UMBs und die 386er-
Emulation von EMS-Backfilling. Das erstere wird aber ab Update 14 (sicher
aber Update 15) auch unter st�tzt!
Die entsprechenden DEVICEHIGH= und LH etc. Optionen (/L: und /S),
die von MS-DOS bekannt sind, wurden aber auch vorher nicht als Fehler
abgewiesen, sondern lediglich ignoriert (siehe Kapitel III.4., Kapitel
V.5. und Kapitel V.7.). Auch ohne Region-Support kam Novell DOS bez�glich
des verf�gbaren Speichers schon bei Standard-Konfigurationen auf sehr
�hnliche bis bessere Werte. Mit dem nun verf�gbaren Region-Support
hat man hier jedoch erheblich mehr Flexibilit�t, wodurch die Speicher-
situation auch in Problemf�llen noch weiter verbessert werden kann.
Bereits bei �blicher Ausnutzung der M�glichkeiten des Speichermanagers
ergibt sich i. allg. eine erheblich bessere Speicherbilanz als bei
MS-DOS. �ber den EMM386-Schalter /DPMI=on ist es sogar m�glich, diesen
'DOS-Extender' direkt allen DPMI-nutzenden Programmen unter DOS zur
Verf�gung zu stellen (MS-DOS kann DPMI nur innerhalb von MS Windows
bereitstellen).
Dadurch entf�llt die Notwendigkeit, da� speicherhungrige Applikationen
ihren eigenen DPMI-Support mitbringen m�ssen. Allerdings kann man auch
etwas Extended Memory einsparen, wenn man /DPMI=off angibt, wenn man
den Support auf DOS-Betriebssystemebene nicht ben�tigt.
(Lediglich etwas Vergleichbares zur Stealth-Funktion von QEMM fehlt
(nicht nur) Novell DOS). Die Funktionalit�t von HIMEM ist weitestgehend
auch in EMM386 enthalten, daher mu� dieser Treiber auf 386ern (und h�her)
nicht mehr geladen werden. In Sonderf�llen ist dies aber dennoch m�glich,
sogar die Kombination von MS-DOS HIMEM mit Novell DOS 7 EMM386 und
umgekehrt ist machbar (wobei allerdings einige sch�ne Eigenschaften
von Novell DOS auf der Strecke bleiben).
Einen automatischen Optimizer bietet Novell DOS nicht und insofern bleibt
manches Potential dar�ber hinaus ungenutzt.
Bei Beachtung verschiedener Randbedingungen kann man jedoch auch unter
Novell DOS 7 mit MS-DOS MEMMAKER als Analysehilfsmittel f�r Region-
Support arbeiten, dabei mu� man aber f�r die Dauer der Analyse in
CONFIG.SYS und AUTOEXEC.BAT auf alle Novell DOS spezifischen Direktiven
und Batch-Kommandos verzichten (besonders die Boot-Men�s) und mu� zeit-
weise auch mit den Speichermanagern HIMEM+EMM386 von MS-DOS arbeiten,
weil deren Aufrufoptionen unterschiedlich sind. Wenigstens stehen nach
einer solchen Optimierung MEMMAKERs Analysedateien zur Verf�gung und
k�nnen praktische Anhaltspunkte f�r eine optimale Konfiguration unter
Novell DOS 7 liefern. Da Novell DOS' EMM386 jedoch eine ganze Reihe
M�glichkeiten mehr bietet, die bei einer MEMMAKER Optimierung nat�rlich
nicht ber�cksichtigt werden, ist mit manueller Nachbearbeitung meistens
noch wesentlich mehr herauszuholen.
Deshalb die folgenden Hinweise:
i. HIMEM.SYS:
-------------
Anders als noch bei DR DOS 6.0 und entgegen der Intention der Anleitung
arbeitet HIMEM von Novell DOS auch auf PC/XTs (8088/8086), die �ber
1 MByte Speicher verf�gen (zumindest auf einem V20-System getestet)!!!
Dies ist bei vielen sp�ten Rechnern dieser Generation der Fall, die in
Speicherb�nken 2 und 3 statt mit den eigentlich nur notwendigen 64er-
Chips mit 256er-Chips ausgestattet sind. Evtl. mu� der Adre�dekoder auf
dem Mainboard (PAL oder 'TTL-Grab') leicht modifiziert werden, um dies
zu erm�glichen. Eine andere M�glichkeit besteht darin, �ber spezielle
UMB-Karten (wie die Uni-RAM-Karte nach c't) permanentes oberes RAM zur
Verf�gung zu stellen. Auf diesen Rechnern k�nnen die UMBs ohne Zusatz-
programme verf�gbar gemacht werden, indem man die entsprechenden hohen
Speicherbereiche mit
DEVICE=c:\nwdos\HIMEM.SYS /CHIPSET=ram /USE=xxxx-xxxx
DOS=UMB
deklariert. So l��t sich noch mancher alte und wackere PC/XT trotz
vieler geladener TSR-Programme (STACKER etc.) mit gr��eren DOS-
Anwendungen fahren!
Viele fr�he ATs mit 286er besitzen mindestens ein MByte Speicher,
k�nnen im ersten MegaByte Speicher aber nur bis max. zur 640 KByte-
Grenze abbilden, die restlichen 384 KByte sind nur als Extended Memory
verf�gbar und werden daher meist nur f�r eine VDISK-RAM-Disk verwendet
(d.h. die Rechner-Hardware erlaubt nicht das Einblenden des Speichers
zwischen den Adaptern, also im oberen Speicherbereich).
Selbst die Angabe von /CHIPSET=RAM erschlie�t auf solchen Rechnern
nicht die HMA, die eigentlich dennoch f�r DOS genutzt werden
k�nnte. HIMEM bricht mit einer Fehlermeldung ab, und der optionale
DPMS-Server kann wegen des fehlenden XMS-Servers (durch HIMEM
bereitgestellt) ebenfalls nicht geladen werden.
Trotzdem ist es m�glich, die 384 KByte Extended Memory f�r DOS sinnvoll
zu nutzen (evtl. kann man auch /CHIPSET=none versuchen):
DEVICE=c:\nwdos\HIMEM.SYS /CHIPSET=ram /USE=FF00-FFFF
DEVICE=c:\nwdos\DPMS.EXE
DOS=HIGH
Diese Angaben (au�erhalb der Bereichsgrenzen von USE!!!) in CONFIG.SYS
erschlie�en die HMA (64 KByte) f�r DOS, au�erdem kann danach DPMS ge-
laden werden und verschiedene Systemprogramme (NWCACHE, STACKER,
DELWATCH, NWCDEX, etc.) k�nnen so das restliche Extended Memory f�r
DOS nutzen. So sind trotz nicht vorhandener UMBs recht stattliche
Speicherkonfigurationen m�glich!!!
Achtung: Die DPMS-Version 1.42 (aus Update 14) bereitete mir auf
zwei verschiedenen 286er-Rechnern (ohne UMBs, aber mit Extended
Memory) in dieser Kombination Probleme, die zum H�ngen des Rechners
w�hrend der Installation des DPMS-Treibers f�hrten. Es ist m�glich,
da� dies auf Ihrem System nicht auftritt, allerdings mu�te ich auf
die Version DPMS 1.41 (aus Update 13) zur�ckgreifen oder die neue
Version 1.43 (aus Update 15) verwenden, die hier problemlos arbeitete.
Sofern das Chipset des Mainboards von HIMEM unterst�tzt wird, sind
auch exotische Probleme l�sbar, wie etwa auf Rechnern mit 512 KByte
Basisspeicher 128 KByte umzumappen, um den Speicher bis 640 KByte auf-
zuf�llen. Auch die Nutzung des Video-Speicherbereichs ist m�glich
(aber offenbar nicht f�r /CHIPSET=RAM in Verbindung mit EGA/VGA).
ii. EMM386.EXE:
---------------
Auf 386ern wird i. allg. statt HIMEM der Speichermanager EMM386
verwendet, der durch Speichervirtualisierung (V86-Modus) erheblich
bessere M�glichkeiten erm�glicht (HIMEM ist im Gegensatz zu MS-DOS
hier i. allg. nicht notwendig und eher hinderlich; seine Funktionalit�t
wird bei Novell DOS von EMM386 bereitgestellt).
Der Standardaufruf d�rfte auf den meisten Systemen wie folgt aussehen:
DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=xxxx
DEVICE=c:\nwdos\DPMS.EXE
DOS=HIGH,UMB
Die Kombination /MULTI=on /DPMI=on, die sowohl den Multitasking-
Support, als auch einen DPMI-Server einrichtet, der auch von DOS-
Programmen ohne eigenen Extender genutzt werden kann, ohne daf�r
unter MS Windows laufen zu m�ssen, hat mir i. allg. noch keine
Probleme bereitet.
Mit fr�hen Versionen von Novell DOS soll es jedoch zu Problemen mit
4G-Applikationen gekommen sein: Hinweise bei den Updates beachten.
Lediglich SemWares TSE 2.0 produziert auch mit Update 15 noch
Schutzfehler, wenn er unter einem multitaskenden TASKMGR gestartet
wird und in riesigen Dokumenten schnell gebl�ttert wird. Hier reicht
es aber, TSE �ber einen Batchjob aufzurufen, der direkt vor dem Aufruf
"DPMI off" und direkt danach wieder "DPMI on" ausf�hrt (wirkt f�r
jedem Task lokal). Unter anderen Randbedingungen bereitet auch TSE bei
mir keine Probleme mit /MULTI=on /DPMI=on. Sollten wider Erwarten
dennoch Probleme auftreten, brauchen Sie deshalb noch lange nicht
auf Novell DOS verzichten. Richten Sie einfach im Boot-Men� eine
Konfiguration mit /MULTI=off /DPMI=off ein.
Damit schrauben Sie die Extraf�higkeiten des Speichermanagers zwar fast
auf das Niveau von MS-DOS 6.22 EMM386 zur�ck, aber es k�nnen auch keine
Probleme mehr mit DPMI auftreten. Sollte es sich um eine 4G-Applikation
handeln, k�nnen Sie auch den mit einem Update hinzugef�gten Parameter
/PIC=ON|OFF ausprobieren. Eine andere L�sung ist es, die Applikation
aus der DOS-Box von MS Windows 3.1x (im Erweiterten 386er Modus) aufzu-
rufen. MS Windows �berdeckt Novells DPMI-Server durch eigenen Support,
und der gilt schlie�lich f�r die meisten DPMI-nutzenden Programme als
Referenz...
Es gibt jedoch einige M�glichkeiten, den verf�gbaren Speicher zu
erh�hen:
a) BIOS-Shadowing:
Diese Option dient der Erh�hung der Zugriffsgeschwindigkeit auf die
ROMs (i. allg. 8 oder 16 Bit breit und mit vielen Waitstates versehen),
indem diese ins 16- oder 32-bittige RAM umkopiert, dort schreib-
gesch�tzt und an die urspr�ngliche Adresse (�ber die BIOSe) gemappt
werden. Das Shadowing kostet keinen Adre�raum, ben�tigt aber genau so
viel RAM-Speicher (der f�r anderweitige Nutzung wegf�llt), wie Segmente
als Schattenspeicher eingerichtet werden.
Das Shadowing ist theoretisch ab XTs mit 1 MByte m�glich, praktisch
alle ATs (ab 286er) bieten Shadow-M�glichkeiten ab Chipset unter
Kontrolle des BIOS-Setup-Programms an. Ab 386er-Prozessor ist mit
entsprechendem Speichermanager (EMM386) im V86-Modus auch das virtuelle
Shadowing m�glich. Die etwas geringere Ausf�hrungsgeschwindigkeit der
Programme im V86-Modus gegen�ber dem Real Mode (durch den Overhead
des st�ndigen Moduswechsels zwischen Protected Mode und V86-Modus)
ist meistens kein Problem, da man i. allg. erst durch die Features
des Speichermanagers die Freiheit bekommt, entsprechend viele Pro-
gramme zur Systemoptimierung zu laden, die dann diesen Geschwindig-
keitsnachteil bei Weitem wieder aufwiegen. Sollten Sie jedoch ein
Chipset haben, da� sehr flexible Einstellungen f�r BIOS-Shadowing und
EMS-Hardware-Emulation erm�glicht und sollten Sie weder VCPI, DPMI
noch die Multitasking-M�glichkeiten des TASKMGR ben�tigen, mag es
dennoch im Einzelfall sinnvoller sein, EMM386 nicht zu laden (und
evtl. auf HIMEM.SYS auszuweichen).
Es ist wichtig, zwischen zwei 'Ressourcen' zu unterscheiden:
Verf�gbarer RAM-Speicher
Verf�gbarer Adre�raum im ersten MegaByte
Da die meisten heutigen Rechner �ber mehrere MegaByte RAM-Speicher
verf�gen, DOS aber prinzipiell nur im ersten MegaByte laufen kann
(mal von speziellen Strategien wie DPMS (oder DOS-Extendern �ber DPMI)
abgesehen), ist der Adre�raum f�r DOS-Systeme eigentlich die kostbarere
Ressource. Die Gr��e des UMB-Speichers, den ein Speichermanager
f�r Ger�tetreiber, TSRs und den DOS-Kernel verf�gbar machen kann, ist
entscheidend daf�r, wie viel Basisspeicher (unterhalb 640 KByte) letzt-
endlich zur Verf�gung steht. U.U. ist es sinnvoller, einige hundert
KiloByte Extended Memory f�r einen Speichermanager wie EMM386 zu
opfern, um mit dessem virtuellen Speicherabbild einige zehn KiloByte
UMB-Speicher nutzbar zu machen. Dies gilt besonders f�r das virtuelle
Shadowing und f�r die EMS-Emulation, die im folgenden besprochen
werden:
Tip:
S�mtliches Shadow-RAM im BIOS-Setup abschalten, wenn EMM386 in den
V86-Modus schalten darf (d.h. wenn sich keine Anwendungen an dieser
Betriebsart st�ren). Diesen Speicher kann man im BIOS-Setup dem
Extended Memory zuschlagen (Memory-Relocation enabled). Au�erdem
sollten auch alle anderen Shadow-Programme (wie FASTBIOS.SYS von
manchen SuperVGA-Karten) entfernt werden.
Auch wenn dies auf den ersten Blick nicht sinnvoll erscheint (und von
fr�heren Rechnergenerationen und �lteren, weniger leistungsf�higeren
Versionen der Speichermanagern her anders gewohnt):
Das virtuelle Shadowing der BIOS-ROMs, das der Speichermanager EMM386
von Novell DOS im V86-Modus erm�glicht, kann erheblich besser dosiert
werden, als es die Rechner-Hardware �blicherweise erlaubt. Daher ist
diese Software-M�glichkeit der Hardware-Option vorzuziehen, wenn es um
optimale Speicherausnutzung geht.
�ber Anweisungen der Form
DEVICE=c:\nwdos\EMM386.EXE /RAM=xxxx-xxxx
ist es m�glich, einzelne BIOSe ganz gezielt als Schattenspeicher zu
konfigurieren, allerdings kann man hier (im Gegensatz zum Hardware-
Shadow des Rechners) die notwendigen Bereiche sehr genau angeben
(die Rechner-Hardware bietet meist nur Segmente mit 32 - 128 KByte
zur Auswahl).
Au�erdem kann man Bereiche aussparen, die nur w�hrend der
Initialisierung des BIOS ben�tigt werden, d.h. nur
einmal durchlaufen werden (also nur den zur Laufzeit wirklich aktiven
Code als Schattenspeicher aktivieren).
Ein 32 KByte Video-BIOS ist meist nur mit 20 - 30 KByte Code gef�llt,
davon werden weitere 5 KByte nur w�hrend der Init ben�tigt, ein
Shadowing der kompletten 32 KByte (oder mehr, wie allgemein �blich)
w�re also Speicher- und Adre�raumverschwendung, besonders wenn EMM386
sowieso verwendet wird.
Ein 64 KByte Main-BIOS besteht meist aus 32 KByte Setup- und Diagnose-
Programmen (die wohl nur beim Booten ben�tigt werden und insofern nicht
als Schattenspeicher eingerichtet werden m�ssen), der aktive Code
d�rfte sich meist auf ca. 25 - 30 KByte beschr�nken. Auch hier l��t
sich also einiges an Speicher und besonders Adre�raum sparen (und f�r
andere Dinge einsetzen), wenn man das Shadowing dem Speichermanager
�berl��t und nicht dem Mainboard.
Nebenbei werden dadurch auch manche Probleme vermieden, wenn etwa eine
Netzadapterkarte oder ein Spezialkontroller ein eigenes BIOS mitbringt,
dem ein Bereich eines Dual-Ported-RAMs (memory mapped IO) folgt
(wor�ber z.B. die Kommunikation mit der Karte stattfindet). Wenn der
Rechner hardware-m��ig nur sehr gro�e Bereiche als Schattenspeicher
einrichten kann, mu� man die Karte i. allg. so konfigurieren, da�
zumindest ihr RAM-Fenster au�erhalb des Shadow-Bereichs liegt (denn
in als Schattenspeicher eingerichtetes ROM kann man nicht schreiben).
Dadurch mu� man den UMB-Bereich fragmentieren, was wiederum bedeutet,
da� gr��ere Programme nur sehr schwer im UMB-Bereich untergebracht
werden k�nnen und obendrein an den �berg�ngen brachliegende Speicher-
bereiche entstehen.
Problematisch d�rfte es nur sein, die aktiven Bereiche der BIOS heraus-
zufinden, hier kann nur ein erfahrener Systemprofi weiterhelfen (Dies
hier auszuf�hren, w�rde den Umfang des Dokumentes sprengen; hilfreich
sind jedoch QEMM und MFT.)
Eine Steigerungm�glichkeit bietet sich an, wenn man BIOS-Bereiche, die
nur w�hrend der Initialisierung ben�tigt werden, nicht nur NICHT
als Schattenspeicher einrichtet, sondern als UMBs freigibt.
Da der Speichermanager hier jedoch ROM-Code erkannt hat, wird er sich
normalerweise weigern, diese Bereiche f�r Programme zu verwenden.
Mit der Option
EMM386 /USE=xxxx-xxxx
kann man jedoch auch kleinere Speicherbl�cke gezielt �ber ungenutzte
BIOS-Adressen mappen (da dies im virtuellen Modus geschieht, mu� man
auch nicht mit Hardware-Problemen durch aufeinander arbeitende Bus-
treiber rechnen) und so zum Hochladen von Programmen nutzen.
Auch hier ergibt sich lediglich das Problem, die Bereiche herauszu-
finden, die effektiv nicht benutzt werden (d.h. nur w�hrend der Init
oder w�hrend des Setups). Im Zweifel hilft Probieren und paragraphen-
weises (16 Bytes) Herantasten an die Grenzen (allerdings kann EMM386
Bereiche aufgrund der Hardware-Eigenschaften von 386ern immer nur �
4 KByte verwalten, so da� z.B. EXCLUDE=x000-x001 den Bereich x000-x100
ausschlie�t. Trotzdem ist es anscheinend m�glich, durch sich �ber-
lappende Angaben auch kleinere Bereiche f�r Programme zu verwenden.
MEM liefert hier nicht ganz eindeutige Aussagen. Siehe Kapitel V.2.).
Dabei sollte man bedenken, da� die Initialisierungsroutinen der BIOSe
meist an deren Anfang liegen, au�erdem meist am Ende von Zusatz-BIOSen
noch kleinere Bereiche frei sind (Inhalt FFh oder 00h); das Setup-
Programm liegt i. allg. bei F000-F7FF.
Achtung:
Eine Doppelnutzung mu� hier mit Sicherheit ausgeschlossen werden,
andernfalls wird der Rechner fr�her oder sp�ter (meist das erstere)
abst�rzen. EMM386 hat keine M�glichkeit, die Zul�ssigkeit eines
Zugriffs auf einen mit /USE freigeschalteten Speicherbereich zu
�berpr�fen. /USE mappt virtuell Speicher �ber die angegebenen
Bereiche; evtl. darunterliegender BIOS-Code etc. wird (zumindest
aus der Sicht von DOS) dauerhaft verdeckt.
Au�erdem sollte man beachten, da� logischerweise entsprechend der mit
/USE deklarierten Speichergr��e an anderer Stelle (im Extended Memory)
Speicher fehlt. Sollte die Rechner-Hardware also selbst�ndig RAM an
Stellen einblenden, f�r die auch /USE angegeben wurde, sollte man
entweder diesen Speicher �ber hardware-m��ige Memory-Relocation dem
Extended Memory zuschlagen oder diese Bereiche von /USE ausschlie�en.
Nur so kann man verhindern, da� sozusagen zwei Ebenen von Speicher
�bereinander liegen und der 'unten' liegende Speicher verst�ndlicher-
weise von jeglicher Nutzung ausgeschlossen ist.
Da man aber durchaus 30 - 50 KByte (!!!) wertvollen UMB-Platz gewinnen
kann, lohnt sich das etwas aufwendige Tuning.
b) EMS-Emulation:
Der Speichermanager EMM386 kann auch EMS-Speicher simulieren. Da der
Speicher (EMS, XMS) aus einem gemeinsamen Pool bedient wird und man
sich nicht auf eine exakte Verteilung festlegen mu�, bietet es sich
an, *immer* einen EMS-Seitenrahmen anzulegen, damit auch Programme,
die EMS-Speicher ben�tigen, ohne Sonderkonfiguration laufen k�nnen
(es sei denn, keines Ihrer Programme w�re auf EMS angewiesen).
Das einzige Argument, das noch gegen die Einrichtung eines Seiten-
rahmens bleibt, ist, da� durch den Seitenrahmen 64 KByte Adre�raum
(meist) im oberen Speicher 'verschwendet' werden, die man sonst als
UMBs nutzen k�nnte.
Diese Aussage l��t sich aber weitestgehend entsch�rfen, wenn man den
Rahmen an eine geschickte Position legt. Wie oben angesprochen, wird
das Setup-Programm des Main-BIOS i. allg. nur w�hrend der Init be-
n�tigt, daher k�nnte man den EMS-Seitenrahmen zur H�lfte �ber dieses
BIOS legen, und so weitere 32 KByte Adre�raum f�r UMBs gewinnen (dies
ist bei MS-DOS Speichermanagern nicht m�glich). Damit der Speicher-
manager diese Einstellung akzeptiert, ist es allerdings notwendig,
die Option /USE zu verwenden, etwa:
EMM386 /FRAME=E800 /USE=F000-F7FF
Au�erdem sollte man versuchen, evtl. vorhandene Adapter-ROMs (Netz-
adapterkarten u.�.) hinter diese Page-Frame zu legen, damit sie nicht
mehr anderweitig Adre�raum verbrauchen. Diese Doppelnutzung bereitet
normalerweise keine Probleme, solange nicht z.B. die Netzwerk-Software
EMS-Speicher ben�tigt. Ein Treiber f�r die Karte wird problemlos auf
das Adapter-ROM zugreifen k�nnen, ein Programm, das EMS verwendet,
mappt seine EMS-Seiten virtuell �ber dieses ROM und l��t sie bei
seiner Beendigung auch wieder verschwinden. Theoretisch kann diese
Doppelnutzung zu Deadlocks f�hren, wenn Anwendungen von unzul�ssigen
Annahmen ausgehen (etwa, da� sie ihre Speicherseiten eingeblendet
lassen k�nnen, oder wenn EMS-nutzende TSRs den aktuellen Zustand bei
Ein- und Auslagern nicht abspeichern), aber sauber und umsichtig
programmierte Software sollte damit in den meisten F�llen zurecht-
kommen. Sollten dennoch Probleme auftauchen, m�ssen EMS-nutzende
Programme �berpr�ft werden. Kritisch sind u.U. EMS nutzende Ger�te-
treiber, unkritisch sind TSRs, die sich einfach nur bis zur Aktivierung
irgendwo hin auslagern wollen (z.B. SDRes).
Dieses Verfahren kommt �brigens der Stealth-Funktion von QEMM schon
sehr nahe, nur da� ein �u�erer �berwachungsmechanismus fehlt.
Mit ein bi�chen T�ftelei l��t sich so das System stark optimieren
(meist mu� man ja erstmal wissen, da� solche Dinge �berhaupt m�glich
sind): Eigene Erfahrungen haben gezeigt, da� dieses Verfahren in sehr
vielen F�llen sehr gut und stabil funktioniert.
c) Ein Beispiel:
Ein Auszug aus einer CONFIG.SYS eines mit VGA (A000-AFFF,B800-BFFF) und
HGC (B000-B7FF/BFFF) best�ckten 386er mit Intel-Chipset und Ph�nix-BIOS
(F000-FFFF) und ET4000-BIOS (C000-C7FF):
DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=E800 /VIDEO
/ROM=C100-C7FF,F800-FFFF
/USE=C800-E7FF,F000-F7FF
/VERBOSE
DEVICE=c:\nwdos\DPMS.EXE
Es werden hier nur die im laufenden Betrieb notwendigen Teilbereiche
der BIOSe als Schattenspeicher eingerichtet (nur dort bringt es einen
Geschwindigkeitszuwachs), der EMS-Seitenrahmen liegt zur H�lfte �ber
dem Main-BIOS (genauer �ber dem gesamten Setup-Programm).
(Auf einem anderen �hnlichen Rechner liegt hinter dem EMS-Seitenrahmen
noch ein HP-IB-Streamer-ROM (E800-EBFF), und es funktioniert...)
Gegen�ber dem Standard (Shadowing durch Rechner-Chipset):
DEVICE=c:\nwdos\EMM386.EXE /MULTI=on /DPMI=on /FRAME=auto /VIDEO
/VERBOSE
DEVICE=c:\nwdos\DPMS.EXE
konnten bei gleicher Performance gegen�ber der Standardeinstellung
(deren Speicherbilanz schon besser als die von MS-DOS war) etlicher
sonst verschwendeter Speicher (ca. 64 KByte) gespart und obendrein
mehr UMBs (ca. 32 KByte) zur Verf�gung gestellt werden.
Was will man mehr...
d) Video-Speicher nutzen:
Mit einer Kombination aus den Optionen /USE und /VIDEO l��t sich
auf zwei grundverschiedene Art und Weisen noch mehr Speicher bereit-
stellen - sowohl als Erg�nzung f�r den konventionellen Speicher
(bis zu 96 KByte mehr) als auch als zus�tzlichen UMB-Speicher
(ebenfalls bis zu 96 KByte mehr). N�heres hierzu in Kapitel V.6.
---------------------------------------------------------------------------
V.2. Zus�tzliche Optionen von EMM386.EXE [97-03-24]:
====================================================
Stichworte: EMM386.EXE, /HANDLES, /PIC, /DMA, DTU, Optionen, Updates
Neben den im DOSBOOK und im Handbuch erw�hnten Optionen bietet der
Speichermanager noch einige zus�tzliche Aufrufparameter, die zum Teil
wenigstens in der eingebauten Hilfe aufgelistet werden (der einleitende
SwitChar ist optional):
EMM386 /HELPDEVICE Hilfe f�r CONFIG.SYS-Parameter
EMM386 /? Hilfe f�r Kommandozeilenparameter, akzeptiert
werden jedoch auch /H, /HELP bzw. /HILFE.
�brigens treten - ganz allgemein - auch bei den anderen Kommandos bei
Aufruf der jeweils eingebauten /? Hilfe teilweise zus�tzliche Optionen
'zu Tage', so da� bei der Suche nach m�glichen L�sungen f�r Probleme in
jedem Fall angeraten sei, nicht nur das Handbuch und das DOSBOOK zu
verwenden. Insbesondere Erweiterungen durch Updates finden nur in der
in die Kommandos eingebauten Hilfe Niederschlag.
Obwohl EMM386 in seinen /INCLUDE, /EXCLUDE, /USE, /VIDEO Parametern als
Bereichsangaben Werte mit einer Genauigkeit eines Paragraphen (16 Bytes)
akzeptiert (dies ist jeweils die letzte Stelle von xxxx-xxxx), arbeitet
das virtuelle Mappen (aufgrund von CPU-Gegebenheiten) nur mit Bereichs-
gr��en � 4 KByte. M�chten Sie z.B. einen kleinen Bereich ausschlie�en
(/EXCLUDE=xxx0-xxx1), so schlie�t EMM386 in Wirklichkeit den Bereich
xxx0-xxFF aus. Wenn solche Bereiche nicht genau auf einer 4 KByte-Grenze
liegen, so kann es vorkommen, da� der auszuschlie�ende Bereich sich nicht
ganz mit dem ausgeschlossenden Bereich deckt (zumindest wenn man MEM /A
trauen kann). Hier ist also bei Optimierungen auf's letzte Byte Vorsicht
geboten (siehe auch Kapitel V.1.).
Die zus�tzlichen Optionen sind:
(nur in der eingebauten Hilfe dokumentiert)
EMM386 /HANDLES=1..255 Anzahl EMS- (und XMS-) Handles
EMM386 /PIC=ON|OFF Virtualisierung der PICs (der beiden Inter-
rupt-Controller 8059) zur L�sung von Problemen
mit DOS-4G-Extender-Programmen (ab EMM386
3.05+), wie von vielen Spielen verwendet.
Mehr dazu wird in der Update HISTORY.TXT und
in der /HELPDEVICE Hilfe ausgegeben. Wenn
Sie den Parameterwert nicht angeben, wird OFF
angenommen. (Evtl. funktioniert auch PIC=Y???)
EMM386 /DMA=0..65535 DMA-Puffer
EMM386 /QUIET Unterdr�ckt Meldungen (funktioniert aber bei
mir nicht, stattdessen erscheint (bei Update
15) eine Fehlermeldung des internen Moduls
DPMI.SYS...)
EMM386 /VERBOSE Gibt (ausf�hrliche) Startmeldungen, offenbar
der Standard
EMM386 /NOVCPI siehe EMM386 /HELPDEVICE
EMM386 /NOEMS siehe ""
EMM386 /MULTITASKING=ON|OFF genauso wie /MULTI=ON|OFF
L�dt den internen Multitasking-Kernel
KRNL386.SYS des Systems (war in der Beta-
Phase ein externer Treiber). Wird u.a. f�r
den den TASKMGR als Multitasker ben�tigt.
EMM386 /ROM=xxxx Wird bei xxxx nur die Startadresse angegeben,
so versucht der Speichermanager, einen an
dieser Adresse liegenden ROM-Header 55h AAh
auszuwerten und daraus die L�nge des ROMs zu
ermitteln. Dies funktioniert aber nur dann,
wenn man wirklich die Startadresse des ROMs
angibt und nicht etwa nur die Adresse, ab der
Shadow-RAM eingeblendet werden soll, denn
dort mu� nicht unbedingt gerade ein ROM-Header
beginnen.
Undokumentierte Optionen:
EMM386 /GATEA20=AT|HP|INT15|MCA|PS2|XMS
ist bis auf die Einstellung PS2 dokumentiert.
Wo der Unterschied zwischen MCA und PS2
liegen mag, ist unklar (denn PS/2 Rechner
haben �blicherweise einen MCA-Bus). Der
Treiber besitzt interne Sonderbehandlungen f�r
ISA, EISA, MCA, PCI, CPQ und XMS; in wieweit
dies mit dieser Option zusammenh�ngt, ist mir
nicht bekannt.
EMM386 /DPMS[=ON|OFF] Dieser undokumentierte Parameter wird nicht
in der Hilfe aufgelistet, obwohl intern sogar
eine entsprechende Hilfemeldung implementiert
ist, die nur nicht angesprungen wird. Er wird
auch nicht - wie andere ung�ltige Optionen -
zur�ckgewiesen, ist aber dennoch in der
ausgelieferten Fassung von EMM386.EXE ohne
Funktion, d.h. DPMS-Support kann damit nicht
aktiviert werden. Im DPMS-SDK gibt es aber
eine spezielle Fassung von EMM386.EXE, die
DPMS.SYS enth�lt. Sie ist notwendig, um DPMS-
nutzende Programme zu debuggen - mit dem
Windows-Debugger WDEB386.EXE, der in
Microsofts Windows SDK/DDK ausgeliefert wird.
EMM386.EXE besteht aus einer Vielzahl
interner, aber dennoch eigenst�ndiger Treiber
(u.a. DPMI.SYS und THREADS.SYS), die von einer
LOADER genannten Routine w�hrend der Instal-
lation von EMM386 bei Bedarf mit eingebunden
werden (mit etwas Geschick kann man die
einzelnen Bestandteile auch wieder voneinander
trennen).
Schon in 10/1992 existierte eine Vorversion
von DPMS.EXE.
EMM386 /DEBUG ??? undokumentiert, wird i. allg. (wahrscheinlich
nur vom ummantelnden LOADER) zur�ckgewiesen
und EMM386 l�dt nicht. Trotzdem haben alle
internen Treiber entsprechende Parameter-
�berpr�fungen implementiert. Zwei Vermutungen:
Entweder es handelt sich um einen Parameter,
der (w�hrend der Entwicklung) das Debuggen
von EMM386 erm�glicht oder hiermit k�nnten
auch die recht umfangreichen Fehlermeldungen
von EMM386 unterdr�ckt werden (falls per
Default /DEBUG=ON w�re (dies k�nnte dann
evtl. etwas mehr XMS Speicher zur Verf�gung
stellen).
Aber: Beides ist reine Spekulation...
EMM386 /EMS ??? undokumentiert, wird zur�ckgewiesen. EMM386
l�dt nicht.
EMM386 /W[=ON|OFF] Der Parameter /WEITEK kann wahrscheinlich
mit /W abgek�rzt werden, im Gegensatz zum
Parameter /WEITEK, bei dem immer =ON oder
=OFF angegeben werden mu�, kann man bei /W
den Wert weglassen.
Weitere Parameter oder spezielle Schl�sselworte, die noch nicht genauer
zugeordnet werden k�nnen: HIMEM, GLOBAL, LOCAL, T3100SX und T4400SX.
Alte DR DOS Optionen, die nicht mehr unterst�tzt werden:
EMM386 /BDOS=AUTO|NONE|FFFF|xxxx Wird insofern aus Kompatibilit�t zu
DR DOS unterst�tzt, als da� eine Warnmeldung
erscheint, die die Verwendung reklamiert und
stattdessen die Verwendung der CONFIG.SYS
Direktive DOS=[HIGH,UMB] vorschreibt.
Die M�glichkeit, die Ladeadresse explizit
anzugeben, f�llt damit also weg.
EMM386 /AUTOSCAN Wird wie /BDOS nicht mehr unterst�tzt, aber
mit einer entsprechenden Warnung quittiert.
Verwenden Sie stattdessen /INCLUDE (was auch
direkt angenommen wird).
EMM386 /KB Wird ebenfalls nicht mehr unterst�tzt und
erzeugt eine Warnung. Stattdessen kann man
(in umgekehrter Logik) mit /INT15 einen
Speicherbereich von der Verwendung aus-
schlie�en.
EMM386 /LOWEMM Wird nicht mehr unterst�tzt, da obsolet.
EMM386 l�dt nicht.
Wie viele Benutzer anderer Speichermanager an Novell DOS' EMM386 be-
m�ngeln, unterbricht dieser Manager relativ h�ufig die Behandlung und
meldet verschiedene Arten von Schutzfehlern. Allerdings machen sich die
meisten Benutzer nicht klar, da� sich EMM386 nicht ohne Grund meldet.
Irgendein Programm (und zwar NICHT EMM386) hat eine unsaubere Aktion
ausgef�hrt, die, wenn sie durch den Schutz des Protected Modes nicht
abgefangen w�rde, fr�her oder sp�ter zu einem verdeckten Fehler f�hren
w�rde, der u.U. sehr schwerwiegende Fehlfunktionen oder Datenverluste
nach sich ziehen k�nnte. Derartige Schutzvorkehrungen sind insbesondere
beim Multitasking notwendig.
Statt den Speichermanager zu beschuldigen, sollte man sich die M�he
machen, und die genauen Umst�nde, die zu diesem Fehler f�hren, analy-
sieren und den Herstellern der Probleme bereitenden Programme einen
Bug-Report schicken. Das Verhalten des EMM386 von Novell DOS hat sich
bez�glich seiner Eingriffe �ber den Zeitraum der Updates schon stark
verbessert (oder ist etwas oberfl�chlicher geworden und anderen
Speichermanagern mehr angeglichen - wenn man es von der anderen Seite
sieht).
F�r Programmierer ist jedoch ein strenger Speichermanager ein wahrer
Segen, weil man verdeckte Fehler sehr schnell merkt... Der Novell DOS
Speichermanager ist besonders praktisch noch dazu, weil er nach seiner
ausf�hrlichen Fehlermeldung auch noch einen INT03h-Debugger-Interrupt
anwirft. Wenn man im Hintergrund einen Debugger laufen l��t, kann man
u.U. direkt nach der Ursache forschen. Sehr empfehlenswert zu diesem
Zweck ist zum Beispiel DTU 1.41+ (Downtown Utilities von Jeroen van
Disseldorp, <[email protected]>), weil dieses TSR nur 800 Bytes vom
DOS-Speicher abzweigt (wenn es sich ins EMS auslagern kann), und
trotzdem Online-ASCII-Tabellen, Taschenrechner, Dateibetrachter und
Interrupt-Viewer, Speicher-Dump, Disassembler und anderes bietet und
sich in diesem Fall automatisch aktiviert. Dieses Tool ist FreeWare
und arbeitet problemlos sogar unter dem Multitasker TASKMGR als auch
in DOS-Boxen von Windows (mit Novell DOS ab Update 13 reicht Aufruf-
option DTU /5, mit �lteren Novell DOS Speichermanagern ben�tigt man
DTU /7).
Falls Sie PKZIP (2.04g) unter dem multitaskenden TASKMGR (besonders
in Hintergrundtasks) oder in Verbindung mit exzessiver Harddisk-
Auslastung (NWCACHE /FLUSH=ON) w�hrend des Aufrufs aus Batchjobs (und
mit DOS-Umleitungen) einsetzen, kommt es schon man vor, da� scheinbar
zuf�llig sporadische EMM386-Schutzfehler auftreten (vielleicht auch nur
auf �lteren 386sx-Rechnern???). In einem solche Fall sollten Sie zuerst
versuchen, ob ein Druck auf <Return> nicht ohne Nachwirkungen die
Kontrolle an die Anwendung zur�ckgibt (wie dies bei meinem Testrechner
der Fall ist).
---------------------------------------------------------------------------
V.3. Zus�tzliche Optionen von HIMEM.SYS: [96-10-30]
===================================================
Stichworte: HIMEM.SYS, Ein-MegaByte-XTs, EEMS, EMS-Backfilling, DR DOS
Obwohl der Treiber HIMEM.SYS auf heutigen Maschinen (ab 386er an auf-
w�rts) unter Novell DOS 7 nur noch sehr selten ben�tigt wird (denn
EMM386 enth�lt im Prinzip auch die Funktionen von HIMEM), ist dieser
Treiber in Ausnahmesituationen dennoch wichtig. Besitzt Ihr Rechner
z.B. ein bestimmtes Chipset oder spezielle Zusatzkarten, die von
HIMEM.SYS unterst�tzt werden, kann es auch auf 386ern (und h�her)
sinnvoller sein, HIMEM.SYS vor EMM386 zu laden, da HIMEM.SYS dann
z.B. die Unterst�tzung f�r in der Hardware implementiertes EMS
(3.2 und 4.0) und EEMS bietet. Nat�rlich kann EMM386 (bis auf eine
Emulation von EEMS und EMS 4.0 Backfilling) das Ganze auch im V86-Modus
bereitstellen, aber erstens ist dies etwas langsamer, zweitens kann so
z.B. keine EMS-Hardware unterst�tzt werden, und drittens gibt es manche
Programme, die unbedingt im Real Mode oder sogar im Protected Mode
laufen wollen. Wenn EMM386 im V86-Modus arbeiten mu�, k�nnen solche
Programme nicht ausgef�hrt werden. 286er-Computer kommen normalerweise
ohne HIMEM.SYS nicht aus, wenn sie eine Speicherverwaltung ben�tigen
(auf ihnen arbeitet EMM386 nicht).
Achtung: Die HIMEM.SYS-Version 2.3x von Novell DOS 7 vertr�gt sich
auf COMPAQ-Rechner nicht mit Novells Client32 f�r DOS und
Windows 3.1x, wenn DOS nicht in die HMA geladen wurde. Also
entweder DOS=HIGH,UMB in CONFIG.SYS einf�gen, oder stattdessen
auf EMM386.EXE ausweichen.
Neben den im Handbuch und DOSBOOK beschriebenen Optionen kennt auch
dieser Treiber noch einige Einstellungen mehr, die im folgenden
aufgelistet werden.
/CHIPSET=EMSALL | EMSUMB | AM286ZX | HEDAKA | NEAT | SCAT | RAM | NONE
Diese Option ist zwar dokumentiert, seine
konkrete Verwendung ist allerdings den meisten
Benutzern nicht besonders klar. Deshalb sollen
hier ein paar nicht unbedingt offensichtliche
Details diskutiert werden:
Die Option RAM funktioniert auch auf XTs mit
1 MByte Speicher, die so UMBs zur Verf�gung
stellen k�nnen (siehe in Kapitel V.1.). Die
Option sagt aus, da� in dem angegebenen
Adre�bereich permanent RAM vorliegt (wie auch
immer es dort 'hingekommen' ist), HIMEM blendet
hier keinen Speicher ein. (Bei dem Versuch,
hier Video-Speicher einer EGA unterzuschieben,
mu�te ich allerdings feststellen, da� HIMEM
entweder doch auf die Existenz von RAM �ber-
pr�ft oder den Video-Speicherbereich generell
ausschlie�t...???)
Die M�glichkeit von EMS-Backfilling (von EMS
4.0/EEMS) kann die Leistung von Multitaskern
wie DESQview auf �lteren Rechnern erh�hen.
Allerdings mu� man sich entscheiden, wer
diese M�glichkeiten zum Einblenden von Speicher
au�erhalb der Page-Frame nutzen k�nnen soll.
EMM386 bietet zwar die M�glichkeit, EMS zu
emulieren; das, was man allgemein unter EMS-
Backfilling versteht, wird dabei aber nicht
nachgebildet (obwohl EMM386 auf gewissen Weise
nichts anderes macht, als virtuell Speicher an
bestimmte Adre�lagen abzubilden, aber eben
nicht �ber eine EMS-Schnittstelle). HIMEM kann
EMS-Hardware generell nicht nachbilden, sondern
nur darauf aufsetzen (bei bestimmten unter-
st�tzten Chips�tzen direkt auf der Chipsatz-
Hardware oder �ber einen vorher geladenen
herstellerspezifischen Treiber f�r eine EMS-
Hardware �ber dessen EMS-Software-Schnitt-
stelle). Dabei kann HIMEM von einer hardware-
m��ig angebotenen M�glichkeit f�r EMS-Back-
filling Gebrauch machen und so auch f�r
Novell DOS 7 ausnutzen:
Mit den Einstellungen EMSUMB und EMSALL kann
man HIMEM mitteilen, einen per zus�tzlichen
externen Treiber bereitgestellten EMS-Support
zur Einblendung von UMB-Speicher zu 'mi�-
brauchen'. EMS 4.0/EEMS Hardware kann �ber den
externen Treiber so programmiert werden, da�
sie bis zu 128 KByte gleichzeitig an nahezu
beliebiger Adre�lage einblenden kann (der hier
und im folgenden verwendete Wert von 128 KByte
wird in einer nachtr�glichen Dokumentation zu
DR DOS 6.0 HIDOS.SYS, dem Vorg�nger von
HIMEM.SYS erw�hnt, in der Novell DOS Dokumen-
tation ist immer von 'gesamtem Speicher' die
Rede, vielleicht ist also auch noch mehr
m�glich. R�ckmeldungen willkommen...).
Mit der Option EMSALL weist man HIMEM an,
diese M�glichkeit eines EMS-Treibers komplett
f�r sich in Anspruch zu nehmen. Auf diese Weise
kann HIMEM insgesamt 128 KByte UMB-Speicher zur
Verf�gung stellen, allerdings sind damit die
Paging-M�glichkeiten der EMS-Hardware ausge-
sch�pft und es kann kein EMS-Speicher f�r
EMS-nutzende Applikationen bereitgestellt
werden. �ber diese 128 KByte hinausgehender
Speicher auf der EMS-Karte ist in dieser
Konfiguration zwangsl�ufig nicht ansprechbar.
Allerdings besitzen viele EMS-Karten die
M�glichkeit, durch DIP-Schalter auf der Karte
zu w�hlen, ob der Speicher als EMS (Expanded)
oder Extended Memory zur Verf�gung gestellt
werden soll. Meistens kann man den hardware-
m��ig best�ckten Speicher auch auf beide
Methoden aufteilen. In diesem Fall sollten Sie
also nur 128 KByte als EMS-Speicher aktivieren
und den restlichen Speicher als Extended Memory
ab der Adre�lage einblenden, ab der der
physikalische Speicher auf dem Mainboard des
Rechners aufh�rt. Auf diese Weise k�nnen Sie
auch den restlichen Speicher der Zusatzkarte
nutzen, wenn auch nicht als EMS-Speicher.
Die zweite M�glichkeit besteht in der Angabe
der Option EMSUMB, die normalerweise auch von
selbst detektiert wird. In diesem Fall ben�tigt
HIMEM ebenfalls 128 KByte freien Adre�raum
(�blicherweise im UMB-Bereich des Rechners),
allerdings teilt HIMEM die Verwendung des
Speichers in 64 KByte fixierten Speicher als
UMB und 64 KByte f�r eine EMS-Page-Frame ein.
Auf diese Weise l��t sich der restliche als
EMS-Speicher reservierte Speicher auf der
Zusatzkarte ganz normal �ber die Page-Frame
benutzen, lediglich die M�glichkeiten, Seiten
an beliebigen Stellen einzublenden (Backfilling
ist eine der optionalen Erweiterungen von EMS
4.0 gegen�ber 3.2) bleiben anderen Applika-
tionen nat�rlich versperrt, da diese Ressource
jetzt von HIMEM ben�tigt wird, um UMB-Speicher
einzublenden.
Damit HIMEM die EMS-Funktionen nutzen kann,
mu� (und das wird h�ufig mi�verstanden) *vor*
HIMEM der entsprechende Hardware-Treiber des
Herstellers der Zusatzkarte geladen werden, der
das EMS-Interface auf die jeweilige Hardware
abbildet. Auf dieses Interface setzt dann HIMEM
mit seinen Funktionen auf. (Und auf 386ern und
Nachfolgern kann danach nat�rlich noch EMM386
geladen werden um weitere M�glichkeiten zu
bieten, normalerweise ist es jedoch in diesem
Fall sinnvoller, auf HIMEM zu verzichten.)
Dieser Treiber mu� so konfiguriert werden, da�
er auch die Funktionen bereitstellt, die HIMEM
ben�tigt (z.B. m�ssen bei bestimmten EMS-
Treibern die erlaubten Adre�bereich erst
explizit freigeschaltet werden). Viele EMS 3.x
Zusatzkarten entfalten mit einem EMS 4.0
Treiber auch die M�glichkeiten von EMS 4.0,
es gibt aber auch Karten, die die optionalen
Erweiterungen von 4.0 (wie Backfilling) nicht
unterst�tzen.
M�chten Sie verhindern, da� HIMEM f�r sich
selbst EMS-Speicher nutzt, k�nnen Sie z.B.
/CHIPSET=NONE angeben oder den EMS-Treiber
erst nach HIMEM laden.
/AUTOSCAN= dokumentiert
/INCLUDE= dokumentiert
/EXCLUDE= dokumentiert
/ROM=xxxx | AUTO | NONE dokumentiert
Wird bei xxxx nur die Startadresse angegeben,
so versucht der Speichermanager, einen an
dieser Adresse liegenden ROM-Header auszuwerten
und daraus die L�nge des ROMs zu ermitteln.
Dies funktioniert aber nur dann, wenn man
wirklich die Startadresse des ROMs angibt und
nicht etwa nur die Adresse, ab der Shadow-RAM
eingeblendet werden soll.
/VIDEO= dokumentiert
M�chten Sie den /VIDEO in Verbindung mit
/CHIPSET=EMSUMB verwenden, kann es notwendig
sein, dem EMS-Treiber, der von HIMEM geladen
wird, explizit mitzuteilen, im Video-Adre�-
bereich Speicher einblenden zu k�nnen, so z.B.
bei ASTs EEMS-Treibern.
(Nicht gekl�rt ist, ob diese Option bei EGA-
Karten auch in Verbindung mit CHIPSET=RAM
funktioniert. Auf einem Testsystem (286er,
640 KByte Basisspeicher, HMA und Extended
Memory, ATI EGA Wonder 800+) funktionierte
dies jedenfalls nicht. Erfahrungsberichte
willkommen.)
Siehe auch Kapitel V.6.
/XBDA dokumentiert
/USE= dokumentiert (siehe Hinweise f�r /CHIPSET=RAM)
/GATEA20=AT|HP|MCA|XMS zur �bersteuerung der automatischen Wahl der
Steuerung der Adre�leitung A20. Diese Leitung
dient auf 286ern (und h�her) zum Freischalten
der A20-Leitung, um z.B. im Real Mode noch die
ersten 64 KByte des zweiten MegaBytes Haupt-
speicher adressieren zu k�nnen. Dieser Bereich
hei�t HMA (high memory area) und kann nach der
XMS-Spezifikation nur von einer Anwendung
gleichzeitig benutzt werden. Ist DOS der
Eigent�mer, so steht die HMA anderen Programmen
wie Windows oder DESQview nicht mehr zur
Verf�gung. Der von DOS nicht selbst benutzte
Speicher kann allerdings �ber ein DOS-API auch
an andere DOS-Applikationen vergeben werden.
/NOXMS nicht dokumentiert. Schaltet XMS-Support ab.
/BDOS wird aus Kompatibilit�t zu DR DOS 'unter-
st�tzt', indem es abgefangen und mit einer
Fehlermeldung quittiert wird. Man soll statt-
dessen die CONFIG.SYS Direktive DOS=HIGH
verwenden.
---------------------------------------------------------------------------
V.4. Bessere Speicherausnutzung mit selbsthochladenden Programmen:
=====================================================[96-06-18]===
Stichworte: Selbsthochlader, UMB, MEMMAX, LH, KEYB, NLSFUNC, SHARE,
NWCDEX
Novell DOS bietet verschiedene M�glichkeiten, Programme hochzuladen und
damit kostbaren DOS-Speicher zu sparen.
Nachdem man entsprechende Speichermanager geladen hat, kann man bestimmte
Speicherbereiche gezielt sperren oder zur Verwendung freischalten. Alle
zu ladenden Programme werden dann automatisch ohne weitere Ma�nahmen in
die freigeschalteten Bereiche geladen.
Hierzu dient das Kommando MEMMAX, das die Verwendung der folgenden
Bereiche kontrolliert:
L Lower Memory: Standardm��ig gilt +L, d.h. die ersten 64 KByte (nicht
640 KByte!) sind f�r Programme verf�gbar. Wieso ist dies
abschaltbar?
Dies liegt in erster Linie an einem Segment-�berlauf-
fehler in dem Algorithmus einer fr�hen Version von
Microsofts EXEPACK (einem recht ineffizienten .EXE-
Packer) und Linker, mit dem fr�her viele Programme
gepackt wurden (aber auch Vorab-Versionen von MS-DOS
6.0). Zu Zeiten, wo sich DOS nicht hochladen konnte,
waren die ersten 64 KByte des Systems immer belegt,
daher trat dieser �berlauffehler nie auf. L�dt man
jedoch DOS hoch, wird der untere Speicher (um Ver-
wechselungen mit dem �blichen Low-Memory (0 - 640
KByte) vorzubeugen, besser: unterste Speicher) f�r
Programme frei und hier kam dann dieser Bug zu Tage.
MS-DOS bietet die gleiche Funktion mit dem Befehl
LOADFIX, der im Prinzip nichts weiter macht, als dem
Programm vorzut�uschen, die untersten 64 KByte w�ren
bereits belegt. Paradox...
V Video Memory: Nur mit EMM386.EXE/HIMEM.SYS Option /VIDEO, bei
MDA/HGC/CGA standardm��ig +V, bei EGA/VGA standardm��ig
-V, mu� also bei Bedarf erst freigeschaltet werden.
Das �ndern dieses Zustandes ist zumindest mittels
MEMMAX nicht unter dem TASKMAX/TASKMGR m�glich (wohl
aber �ber direkte API-Aufrufe, die aber die System-
stabilit�t beeintr�chtigen k�nnen).
Siehe auch Kapitel V.1. und V.6.
Achtung: Mit 4DOS 5.51 (nicht mit 4DOS 5.5c oder 4DOS
5.52a) kann diese Option zu Abst�rzen f�hren, siehe
Kapitel IV.4. und VII.3. sowie in 4DOSTIP.TXT.
U Upper Memory: Standardm��ig gilt -U. Siehe auch Kapitel V.1. und V.6.
(Per /USE aktivierte UMBs im Video-Speicherbereich
lassen sich mit diesem Schalter steuern, nicht mit +V.)
LOADHIGH etc. werden hierf�r nicht ben�tigt (bzw. diese Spezialkommandos
�bersteuern tempor�r die MEMMAX-Einstellungen). Da nicht alle Programme
in allen Bereichen arbeiten, wird man jedoch im allgemeinen die Default-
Einstellung beibehalten und LOADHIGH/LH/HILOAD zur gezielten Hochladen
einzelner Programme verwenden.
Eine Reihe Programme haben jedoch auch eigene Methoden implementiert,
sich selbst hochzuladen und sind dabei nicht auf LOADHIGH angewiesen.
Dies ist nicht etwa unn�tiger Luxus, sondern hat einige entscheidende
Vorteile:
Das jeweilige Programm 'wei�' �ber sich selbst am besten Bescheid,
dadurch ist es m�glich, da� es nur bestimmte Teile in L�cken im oberen
Speicher verlagert, da� es w�hrend seiner Initialisierung noch im gro�en
konventionellen Speicher arbeitet usw. Manche Programme sind zu gro�,
um mit LOADHIGH in UMBs verlagert zu werden, der sp�tere residente Kern
w�rde jedoch sehr wohl dort Platz finden, trotzdem wird das Programm
normalerweise nicht hochgeladen werden k�nnen. Dadurch, da� das Programm
seinen eigenen Hochlader mitbringt, kann der UMB-Speicher effizienter
ausgenutzt werden.
Neben zunehmend mehr Treiberprogrammen mit dieser F�higkeit (z.B.
K3PLUS 6.22+ bzw. FreeKEYB) besitzen die folgenden DOS-Programme
auch diese F�higkeit:
KEYB.COM (nicht nur UMB, sondern auch HMA)
NLSFUNC.EXE (nicht nur UMB, sondern auch HMA)
SHARE.EXE (nicht nur UMB, sondern auch HMA)
NWCDEX.EXE Obwohl der Treiber sich bis auf 7 KByte �ber DPMS ins
Extended Memory auslagern kann und diese restlichen 7 KByte
prinzipiell in UMBs hochgeladen werden k�nnen, stellt sich
dieses Unterfangen in der Praxis leider als sehr schwierig
dar, da w�hrend der Initialisierung zun�chst der gesamte
Code (ca. 85 KByte) in den UMBs Platz finden mu�. Dadurch
mu� der Treiber m�glichst fr�h geladen werden. Um NWCDEX
auch in CONFIG.SYS laden zu k�nnen, mu� man einige Griffe
in die Trickkiste anwenden (siehe Kapitel II.4.). All diese
Design-Beschr�nkungen gelten in versch�rftem Ma�e auch f�r
MSCDEX, das mit mindestens 16 KByte zu Buche schl�gt und
noch mehr Speicher w�hrend der Init braucht.
DELWATCH.EXE (kann sich via DPMS bis auf ca. 464 Bytes in den UMBs
komplett ins XMS auslagern)
NWCACHE.EXE
...
Diese Programme sollten *nicht* mit LOADHIGH hochgeladen werden (obwohl
das durchaus klappen mag), weil sie sich viel besser selbst hochladen
k�nnen.
Werden sie zus�tzlich erst mit LOADHIGH hochgeladen, stehen sie sich bei
den begrenzten Platzverh�ltnissen im Upper Memory nur selbst im Weg, u.U.
versagt sogar das gesamte Hochladen.
Noch ein Hinweis zum Hochladen via DEVICEHIGH= oder LOADHIGH:
Diese Direktiven unterst�tzen undokumentierte zus�tzliche Parameter, die
evtl. beim Optimieren der Konfiguration sinnvoll einsetzbar sind, siehe
Kapitel III.4. und V.5.
--------------------------------------------------------------------------
V.5. Hinweise zu LH/LOADHIGH/HILOAD: [96-06-16]
===============================================
Stichworte: Region-Support, Hochladen
Die Befehle LH/LOADHIGH von MS-DOS unterst�tzen die Parameter /L:...
und /S f�r spezielle MEMMAKER-Optimierungen.
Bei Novell DOS 7 sind diese Optionen undokumentiert, da sie bis vor
Update 14 hier - genau wie bei DEVICEHIGH= - keine nennenswerte Funktion
hatten (SIZE=size gibt es bei LH nicht).
Ab Update 14 (sicher aber Update 15) wird nun auch bei Novell DOS 7
Region-Support unterst�tzt, d.h. es ist m�glich, ganz gezielt anzugeben,
in welchen Speicherbereich ein Programm geladen werden soll und welche
Randbedingungen dabei bez�glich der UMB-Bereitstellung gelten sollen.
Bez�glich der Syntax und Funktion siehe Kapitel III.4., Kapitel II.11.
(Optimierungsm�glichkeiten) sowie Kapitel V.1. und Kapitel V.7.
--------------------------------------------------------------------------
V.6. Video-Speicher f�r Programme nutzen: [96-02-04]
====================================================
Stichworte: MEMMAX, EMM386.EXE, HIMEM.SYS, HIDOS.SYS, /VIDEO
i. Erweiterung des konventionellen Speichers (MEMMAX +V):
---------------------------------------------------------
Novell DOS 7 (sowie DR DOS 6.0, mit Einschr�nkungen auch schon DR DOS
5.0) bieten eine M�glichkeit, einen ungenutzten Video-Speicherbereich
als Erweiterung des konventionellen Speichers zu benutzen. Damit kann
der 640 KByte-Bereich (dauerhaft oder tempor�r) in Abh�ngigkeit von der
installierten Video-Hardware um bis zu 64 KByte (mit MDA/HGC) oder gar
96 KByte (falls keine MDA/HGC) erweitert werden. Dies wird im Detail
im DOSBOOK beschrieben. Hier sollen nur ein paar zus�tzliche Bemerkungen
zur dahintersteckenden Technologie gegeben werden:
- Wird der Video-Speicher per HIMEM.SYS (bzw. HIDOS.SYS) bereitgestellt,
mu� entweder im reservierten Video-Speicherbereich (A000-AFFF/B7FF)
permanentes RAM vorhanden sein (z.B. durch eine Zusatzkarte) oder der
Chipsatz des Rechners mu� M�glichkeiten bieten, dort RAM hinzumappen.
Unter Umst�nden mu� man hier mit der Optionen /USE, /RAM und /CHIPSET
dem Speichermanager auf die Spr�nge helfen.
Mir war es bisher allerdings nicht m�glich, den tats�chlich vorhandenen
Video-Speicher einer EGA-/VGA-Karte forciert als permanentes RAM zu
deklarieren, obwohl diese M�glichkeit auf den ersten Blick nahe-
liegend (wenn auch gef�hrlich) ist.
Daran kann man auch erkennen, da� der Speichermanager nur den Adre�raum
des Video-Speichers zum Einblenden von RAM ben�tigt, aber effektiv
den dort vorhandenen Speicher einer Grafikkarte nicht benutzt. Dies mag
verschiedene Gr�nde haben:
Zun�chst ist der Video-Speicher i. allg. erheblich langsamer im CPU-
Zugriff und kann (beim ISA-Bus) nur 8- oder 16-bittig angesprochen
werden, wohingegen Hauptspeicher 16 oder 32 Bit breit ist. Au�erdem
besitzt Video-RAM normalerweise kein Parity-Bit und ist meist von
minderer Qualit�t, was ebenfalls Probleme mit sich bringen kann.
Das gr��te Problem besteht aber darin, da� der wirkliche Video-Speicher
(so er denn vorhanden ist), von einer EGA-/VGA-Karte selbst ben�tigt
wird (hier liegen z.B. die Fonts). Au�erdem kann durch Umprogrammierung
der Register des Video-Controllers der Video-Speicher in v�llig anderer
St�ckelung in diesem Speicherbereich eingeblendet werden (was zu
absolutem Chaos f�hren w�rde, wenn ein Programm gerade diesen Bereich
nutzen w�rde). F�r einen Treiber wie HIMEM.SYS ist es kaum m�glich,
Zugriffe auf die Video-Register abzufangen. Der einzige Weg best�nde
darin, eine CGA-Karte zu emulieren, denn diese Karte benutzt den
Adre�bereich A000-AFFF wirklich nicht.
- Der Speichermanager EMM386.EXE bietet im Prinzip die M�glichkeit,
die Video-Hardware zu virtualisieren. Soll der Video-Speicherbereich
bei einer installierten EGA-/VGA-Karte benutzt werden, so emuliert
EMM386 eine CGA-Karte. Dies ist �brigens auch der Grund, warum
Bildschirmausgaben mit MEMMAX +V sehr viel langsamer sind als mit
MEMMAX -V. Au�erdem erkl�rt diese Emulation auch, wieso nahezu alle
Programme, die mit dynamisch umdefinierten Text-Fonts arbeiten
(z.B. pseudographische Darstellung von Maus-Cursor etc., etwa alle
Novell DOS 7 Programme mit NewUI=On .INI-Dateieinstellung) pl�tzlich
nur noch die 'einfache' Textausgabe zeigen und wieso die Farben
pl�tzlich ganz anders dargestellt werden (n�mlich mit der CGA-Farb-
palette).
Auch hier gilt: EMM386 mappt bei MEMMAX +V aus seinem eigenen Speicher-
Pool (der vorher mit /VIDEO reserviert wurde) RAM �ber den Bildschirm-
speicherbereich. Der wirkliche Bildschirmspeicher wird daf�r nicht
angetastet (obwohl dies theoretisch m�glich w�re, wenn die Hardware
entsprechend gut virtualisiert wird). Vielleicht ist es mit /RAM
m�glich, die wirkliche Nutzung des Bildschirmspeichers zu erzwingen
(dies habe ich bisher nicht ausprobiert). Vielleicht mu� man dazu eine
EGA-/VGA-Karte auch schon vor der Installation des Speichermanagers
manuell auf CGA-Emulation umschalten, etwa:
INSTALL=c:\sys\video\vmode.com cga
DEVICE=c:\nwdos\EMM386.EXE /VIDEO /RAM=A000-AFFF ...
Aber normalerweise blendet die Hardware-CGA-Emulation einer EGA-/VGA-
Karte dann auch genau den ben�tigten Speicher aus, so da� das Unter-
fangen h�chstwahrscheinlich zum Scheitern verurteilt ist.
(R�ckmeldungen willkommen.)
�brigens: Wird mit MEMMAX +V eine Anwendung aufgerufen, die in einen
Grafikmodus schalten will, so meldet sich EMM386 mit einer Fehler-
meldung, da� man das Programm abbrechen sollte, da Zugriffe auf den
Video-Speicher sowieso von EMM386 abgefangen werden. Dr�ckt man hier
nicht <ESC>, so arbeitet das Programm jedoch im Hintergrund weiter
(und merkt normalerweise auch nicht, da� es �berhaupt nicht auf dem
Bildschirm angezeigt wird - dort steht immer noch die Fehlermeldung
des EMM386).
Probleme k�nnte es dann geben, wenn das Programm den Bildschirmspeicher
zur Ablage von Informationen verwendet, denn es ist nicht gekl�rt, ob
EMM386 einfach nur alle Zugriffe auf den Video-Speicher verwirft oder
diese Zugriffe auf einen virtuellen Speicherbereich umlenkt, der auch
wieder ausgelesen werden kann. Ich vermute eher das Erstere, denn bei
Verwendung des TASKMGR auf Zweimonitorsystemen werden Zugriffe auf die
jeweils gerade nicht aktuelle Grafikkarte offenbar einfach verworfen.
Schaltet die Applikation wieder in den Textmodus, gibt EMM386 sofort
die Anzeige wieder frei.
- Wie man aus obigen �berlegungen ableiten kann, mu� keine EGA-/VGA-Karte
installiert sein, damit die /VIDEO Option funktioniert! Wenn keine
EGA-/VGA-Karte installiert ist (also A000-AFFF nicht belegt ist), wird
bei /VIDEO der Bereich von selbst zugeschaltet. Ist allerdings eine
EGA/VGA installiert (die diesen Adre�raum ja meist selbst nutzt), wird
der Speicher nur reserviert und mu� explizit mit MEMMAX +V aktiviert
werden. Dann emuliert EMM386.EXE softwarem��ig eine CGA-Karte.
(Und offenbar kann HIMEM.SYS dies nicht, so da� die /VIDEO Option in
diesem Fall versagt!?)
- M�chte man mit MEMMAX +V residente Programme installieren, ist Vorsicht
geboten. Da diese Programme nur eine CGA-Karte erkennen k�nnen, w�re
es denkbar, da� sie sich bei der Installation speziell an eine CGA-
Hardware anpassen - �brigens unabh�ngig davon, ob der Video-Speicher-
bereich nun wirklich von der Anwendung benutzt wird oder nicht.
Schaltet man dann sp�ter MEMMAX -V ab, um die M�glichkeiten einer
EGA-/VGA-Karte aussch�pfen, so ist es m�glich, da� das residente
Programm f�r EGA-/VGA-Karten keine Unterst�tzung installiert hat
und im schlimmsten Fall versagt. Daher sollte man nach M�glichkeit
MEMMAX -V lassen, solange man es nicht wirklich ben�tigt (und dann
explizit freischalten).
- Arbeitet man auf einem Zweimonitorsystem, h�ngt es vom gerade aktiven
Video-System ab, wieviel Speicher bei MEMMAX +V zus�tzlich eingeblendet
wird. Ben�tigt man besonders viel Speicher, sollte man vor MEMMAX +V
mit MODE CO80 auf den Farbadapter umschalten, so da� man 96 KByte statt
64 KByte Speicher erh�lt (Die konkreten Werte h�ngen nat�rlich auch von
/VIDEO=xxxx-yyyy ab). Diese Speichergr��e �ndert sich dann auch nicht
durch R�ckwechseln mit MODE MONO (falls m�glich) und bleibt bis zum
n�chsten MEMMAX -V bestehen.
ii. Erweiterung des UMB-Speichers (MEMMAX +U):
----------------------------------------------
Sp�testens ab Novell DOS 7 Update 14 ist es mit EMM386 auch m�glich,
Teile des Video-Speicherbereichs als UMB-Speicher zu deklarieren. Dazu
verwendet man die Option /USE in Bereichen des Bildschirmspeichers.
(Diese M�glichkeit existiert im Gegensatz zu i.) im Prinzip auch bei
MS-DOS, dort mu� allerdings die Option /INCLUDE verwendet werden.)
Der �u�ere Unterschied zur ersten Methode liegt darin, da� dieser
Speicher mit der MEMMAX +U Option gesteuert wird und nicht mit
MEMMAX +V, auch wenn der Speicher innerhalb des Video-Speicherbereichs
liegt.
Au�erdem bleibt ein einmal mit /USE deklarierter Speicherbereich
immer eingeblendet, auch wenn man Upper Memory mit MEMMAX -U de-
aktiviert (logisch :-) ). Insofern eignet sich diese Methode auch
zum Laden von Ger�tetreibern und TSRs. In der Praxis habe ich jedoch
herausgefunden, da� normalerweise nur TSRs (z.B. �ber INSTALL[HIGH]=
oder LH geladen) in diesen Bereich geladen werden, Ger�tetreiber
werden weiterhin oberhalb von C800 geladen (Dies gilt nat�rlich nicht
f�r selbsthochladende Treiber)! Ob dies repr�sentativ ist, kann ich
noch nicht sagen.
Es ist m�glich, da� Programme, die in den Video-Speicherbereich geladen
wurden, ein anderes Verhalten zeigen, als wenn sie in 'normale' UMBs
geladen w�rden. Dies kann daran liegen, da� die Verwendung des Video-
Speicherbereichs f�r ausf�hrbaren Code ansonsten un�blich ist und
Programmierer diesen Fall evtl. nicht mit eingeplant haben und dadurch
Bereichs�berl�ufe in den programminternen Algorithmen auftreten. Bei
meinen Tests hat sich aber herausgestellt, da� diese �berlegungen wohl
eher theoretischer Natur sind. Alle von mir bisher getesteten Treiber
funktionierten grunds�tzlich auch im Video-Speicherbereich. Einmal gab
es offenbar Probleme mit der Verwendung von Funktionen des Video-BIOS.
N�heres ist aber noch nicht gekl�rt.
M�chten Sie MS Windows im Erweiterten 386-Modus benutzen, so ist es
notwendig, einen speziellen Treiber namens MONOUMB.386 (von MS-DOS 6.2x)
in das \WINDOWS\-Verzeichnis zu kopieren (oder den bei MS Windows bei-
liegenden Treiber zu verwenden) und in der SYSTEM.INI im Abschnitt
[386Enh] die Zeile DEVICE=MONOUMB.386 einzuf�gen. Diese Anpassung ist
definitiv notwendig, ansonsten wird EMM386 eine Seitenzuweisungskonflikt
melden und f�lschlicherweise empfehlen, man solle im SYSTEM.INI Abschnitt
[386Enh] DualDisplay=No setzen. Damit funktionierte in meinem Fall (mit
B100-B7FF als UMB) sogar noch der Betrieb des zweiten Monitors im Text-
modus (und sogar Umleitungen via DUALMON.SYS). Was zu tun ist, wenn Sie
andere UMB-Bereiche als den Bereich B000-B7FF als UMBs benutzen wollen,
ist vorerst noch nicht gekl�rt (es gibt bei MS Windows noch einen
weiteren Treiber namens MONOUMB2.386...). Offenbar ist es nicht not-
wendig, den MONOUMB.386 Treiber auch beim multitaskenden TASKMGR zu
laden (siehe Kapitel VII.2.).
Theoretisch ist das Laden von Ger�tetreibern und TSRs auch im mit
MEMMAX +V freigeschalteten Speicherbereich m�glich, allerdings ist
dies aus zwei Gr�nden problematisch:
- Normalerweise werden die Speicherbereiche von unten nach oben
gef�llt. Solange man die Allokationsstrategie nicht ver�ndert,
d�rfte man daher kaum in die Verlegenheit kommen, den Speicherbereich
A000-BFFF (640 - 768 KByte!!!) mit residenten Programmen zu f�llen.
- MEMMAX -V ist danach nicht mehr m�glich.
Die Verwendung von Video-Speicheradre�raum mit der Option /USE
bedeutet aber auch, da� w�hrend der ganzen Session dieser Speicher-
bereich nicht mehr f�r die Grafikkarte verwendet werden kann. �ber
CONFIG.SYS Boot-Men�s kann man Fallunterscheidungen einrichten und
nur dann Bildschirmspeicherbereiche als UMB-Speicher verwenden, wenn
man bestimmte Eigenschaften der Grafikkarte f�r die Dauer der Session
nicht ben�tigt, daf�r aber soviel wie irgend m�glich Speicher
freir�umen mu�.
Achtung: EMM386 kann nicht �berpr�fen, ob mit /USE freigegebene
Speicherbereiche tats�chlich von Programmen oder als Video-Speicher
verwendet wird. Zugriffe auf diese Speicherbereiche als Video-Speicher
(z.B. MODE MONO) f�hren zwangsl�ufig zu Abst�rzen, da die dorthin
geladenen Programme einfach durch Bildschirmausgaben �berschrieben
werden... Dies mu� man beachten, wenn z.B. Programme auch im Textmodus
den Speicher der h�heren Textseiten oder gar Grafikbereich als Zwischen-
ablage verwenden, oder wenn Bildschirmtreiber direkt auf die Grafik-
Hardware zugreifen (z.B. MODE MONO/CO80 oder der FreeWare-Treiber
DUALMON.SYS (Ger�te MONO/COLOR oder MONODISP/CO80DISP) l�uft z.B. nur,
wenn mindestens die jeweils erste Seite von der Nutzung ausgeschlossen
wird). Es gibt auch manche SuperVGAs, die nicht mit einer zweiten
Grafikkarte im System kooperieren k�nnen (manche �lteren Trident-
Chips�tze geh�ren dazu). Da solche SuperVGAs im Grafikmodus auch den
f�r die andere Grafikkarte reservierten Adre�raum benutzen (B000-B7FF
oder B800-BFFF), ist von einer Verwendung als UMBs abzuraten.
Definitiv keine Probleme bereiten ET4000-Chips�tze (Info wanted!).
Die Option /USE akzeptiert mit Sicherheit Adressen bis hinab zu A000h
(640 KByte), evtl. sind aber auch Werte wie 8000h (512 KByte) zul�ssig
(nicht �berpr�ft), womit man 512 KByte-Rechner auf 640 KByte 'aufr�sten'
k�nnte...
iii. Kombinationen/Beispiele:
-----------------------------
Nat�rlich k�nnen die Methoden i.) und ii.) kombiniert werden, wobei man
hier aufgrund der vielen M�glichkeiten kaum noch generelle Empfehlungen
geben kann.
Mit der Methode i.) sollte ein m�glichst gro�er Speicherbereich f�r die
Doppelnutzung als Video-Speicher oder erweiterter konventioneller
Speicher deklariert werden (/VIDEO). Damit beh�lt man zur Laufzeit
gr��tm�gliche Freiheit in der Wahl des Speichers.
Mit der Methode ii.) k�nnen Bereiche, die mit der Methode a) nicht
erreichbar sind (z.B. weil sie oberhalb eines von der Grafikkarte
verwendeten Bereichs liegen) als UMBs eingebunden werden, sofern sie
definitiv nicht f�r die Bildschirmdarstellung ben�tigt werden (/USE).
Au�erdem ist hier die Angabe von mehr als einem Bereich m�glich.
Adapter: Benutzte Speicherbereiche: /VIDEO: /USE:
MDA/HGC B000-B200/B7FF/BFFF A000-AFFF B800-BFFF
CGA B800-BFFF A000-B7FF
EGA/VGA A000-AFFF,(B000-B7FF),B800-BFFF A000-B7FF (B000-B7FF)
MDA/HGC + CGA B000-B7FF + B800-BFFF A000-B000/B7FF
MDA/HGC + EGA/VGA B000-B7FF + A000-AFFF,B800-BFFF A000-B000/B7FF
Mono-EGA/VGA + CGA A000-AFFF,B000-B7FF + B800-BFFF A000-B7FF
Neben diesen Anhaltspunkten sollte man sich �berlegen, ob man z.B.
eine MDA-/HGC-Karte evtl. nur im Textmodus nutzt. Dann kann n�mlich
der Adre�raum oberhalb der Speichers f�r diese Textseite (normalerweise
eine Textseite � 4096 Zeichen (1000h) ebenfalls f�r UMBs verwendet
werden! Bei einer MDA/HGC mit B000-B7FF w�rde man dann zum Beispiel
/USE=B100-B7FF angeben k�nnen. Verwendet man eine HGC-Karte nicht im
Grafikmodus gilt hier i. allg. das Gleiche. Analoge �berlegungen kann
man f�r die zweite Grafikseite einer HGC (B800-BFFF) und f�r CGA-Karten,
aber auch f�r EGA/VGAs im Textmodus anstellen. Hier sollte man aber
beachten, da� diese Karten mehrere Bildschirmseiten unterst�tzen und
manche Anwendungen diese als Puffer verwenden. Kann man solche Umst�nde
ausschlie�en, sind auch diese Bereiche erlaubt. Bei richtiger Wahl der
Bereiche bleibt sogar die M�glichkeit erhalten, mit MODE CO80/MONO
zwischen beiden Adaptern zu wechseln, ohne damit Abst�rze zu riskieren!
Ein konkretes Beispiel f�r eine Kombination aus VGA+HGC, wobei die HGC
nur im Textmodus betrieben werden darf:
...
REM Mit MEMMAX +U (Standard) 28 KByte mehr UMB-Speicher aus dem
REM 'Nichts'. Mit MEMMAX +V je nach aktivem Bildschirm 64/96 KByte
REM mehr Basisspeicher...
DEVICE=EMM386.EXE /VIDEO /USE=B100-B7FF
...
Sie ben�tigen beide Systeme (VGA+HGC) nur im Textmodus und dort jeweils
nur in der ersten Textseite. Darf's auch etwas mehr sein?
...
REM Mit MEMMAX +U (Standard) 56 KByte mehr UMB-Speicher. Mit MEMMAX +V
REM je nach aktivem Bildschirm 64/96 KByte mehr Basisspeicher.
DEVICE=EMM386.EXE /VIDEO /USE=B100-B7FF,B900-BFFF
...
Es ist m�glich, da� fr�here Versionen von Novells EMM386 diese M�glich-
keiten nicht sauber unterst�tzten, mit Update 14 wurden jedenfalls gerade
diese M�glichkeiten �berarbeitet.
--------------------------------------------------------------------------
V.7. UMB-Region-Support: [96-05-31]
===================================
Stichworte: MEMMAX +U, DEVICEHIGH=, LH/LOADHIGH/HILOAD, MEM.BAT
Wie schon in Kapitel III.4. (DEVICEHIGH=) und V.5. (LH/LOADHIGH/HILOAD)
ausf�hrlich besprochen, unterst�tzt Novell DOS 7 ab Update 14 nun auch
Memory-Regions, wie sie von MS-DOS her bekannt sind (N�heres bitte den
entsprechenden Kapiteln entnehmen).
Es bleibt anzumerken, da� auch Novell DOS (sp�testens) ab Update 14
innerhalb der UMBs zwischen Ger�tetreibern (DEVICEHIGH=) und TSRs
(INSTALLHIGH=) unterscheidet. Wenn mehr als eine UMB-Region zur Verf�gung
stehen, werden die TSRs default-m��ig in die Memory-Region 1, die Ger�te-
treiber in die Region 2 jeweils von unten nach oben geladen. Mit dem
Parameter /L:region kann dies nat�rlich �bersteuert werden, au�erdem
weicht Novell DOS von diesem Prinzip ab, sobald in einer Region nicht
mehr gen�gend Speicher zur Verf�gung steht. Wof�r diese Unterscheidung
gut ist kann ich nicht genau sagen, ich vermute dreierlei Strategien,
die Speicherverteilung in den UMBs zu optimieren:
- Ger�tetreiber k�nnen praktisch nie zur Laufzeit deinstalliert werden,
so da� es sinnvoll ist, sie zusammenh�ngend anzuordnen, um einer Frag-
mentierung des Speichers vorzubeugen.
TSRs k�nnen manchmal deinstalliert werden, wodurch eine L�cke im
Speicher entsteht. Da unter solchen dynamisch geladenen und entladenen
TSRs eine gr��ere Fluktuation herrscht, ist die Wahrscheinlichkeit
gr��er, da� die Fragmentierung des Speichers hier h�ufiger wieder
aufgehoben wird. Novell DOS fa�t normalerweise auch hintereinander-
liegende freie Bl�cke zu einem gr��eren Block zusammen (allerdings
zumindest mit fr�heren Ausgaben nicht immer), MS-DOS kann dies nicht
(hier kann man mit einem kleinen Utility namens DEFRAGM von Herwig
Feichtinger aus c't 01/1996, S. 288 nachhelfen).
- TSRs besitzen normalerweise eine Umgebung, die aber nur in den
seltensten F�llen vom TSR ben�tigt wird. Deshalb geben umsichtig
programmierte TSRs ihre Umgebung wieder frei, so da� das Betriebs-
system sie wieder verwenden kann. Da die Umgebung h�ufig die gleiche
Gr��e beh�lt, pa�t die Umgebung des n�chsten TSRs h�ufig genau wieder
in diesen freien Block (noch besser programmierte TSRs verlagern einen
Teil ihres Codes in ihren Umgebungsblock, so da� die Fragmentierung
von vornherein nicht entsteht). Aus den gleichen Gr�nden wie beim
ersten Punkt ist es auch hierf�r sinnvoller, die TSRs in eine eigene
Region zu laden. (Siehe auch mein Utility SETENV.COM.)
- Ger�tetreiber (�blicherweise per DEVICE=/DEVICEHIGH=/HIDEVICE= geladen)
und TSRs (z.B. �ber INSTALL=/INSTALLHIGH=/HIINSTALL= zu laden) werden
bei Novell DOS/DR DOS innerhalb der CONFIG.SYS in genau der Reihenfolge
geladen, in der die Aufrufzeilen abgearbeitet werden. Bei MS-DOS/PC-DOS
ist dies nicht der Fall: Selbst unter Verwendung von Boot-Men�s werden
immer zuerst die Treiber per DEVICE= etc. geladen und danach die
Treiber per INSTALL=, jeweils entsprechend ihrer Reihenfolge des
Vorkommens (bei Boot-Men�s entsprechend verschachtelt), vgl. auch
Kapitel III.1. und III.7.
Dadurch werden �blicherweise bei MS-DOS/PC-DOS auch Ger�tetreiber und
TSRs jeweils in nahen Speicherbereichen angesiedelt. Durch die Auf-
teilung, die Novell DOS beim Laden in unterschiedliche Memory-Regions
vornimmt, werden die Treiber *�hnlich* im Speicher angeordnet, wie dies
unter MS-DOS/PC-DOS resultieren w�rde.
Der MEM Befehl unterscheidet zwar in seiner Ausgabe zwischen Ger�te-
treibern (rechtsb�ndig) und TSRs/Programmen/Daten (linksb�ndig), kann
aber (derzeit) noch nicht die Memory-Regions auflisten. Als Ersatz kann
der Batchjob MEM.BAT aus Kapitel IV.5. verwendet werden, der den MEM
Befehl unter Novell DOS 7 um die Parameter /FREE, /MODULE und zwei neue
Parameter /REGION und /VECTORS erweitert.
--------------------------------------------------------------------------
V.8. Tuning-Tips f�r 4DOS-Benutzer: [96-02-06]
==============================================
Stichworte: LH/LOADHIGH/HILOAD, SETLOCAL/ENDLOCAL, Hochladen,
Fragmentierung
Da *jedem* TSR eine eigene Umgebung, die die zum Startzeitpunkt
aktuellen Einstellungen aufnimmt, zugeordnet wird, ist es generell
ratsam, die Umgebung w�hrend des Ladens von TSRs m�glichst klein zu
halten (dies gilt f�r jedes DOS und jeden Kommandoprozessor).
4DOS bietet hier einige zus�tzliche M�glichkeiten, die h�ufig die
letzten Bytes aus dem System quetschen k�nnen (obwohl sie rein gar
nichts mit Speicherverwaltung im eigentlichen Sinne zu tun haben):
- TSR-Aufrufen sollte ein '@'-Zeichen vorangestellt werden. Dieses
Zeichen hat f�r 4DOS neben der �blichen noch eine spezielle Funktion:
Die Umgebungsvariable %CmdLine% (normalerweise mit der Aufrufzeile
des gerade aktuellen externen Programms belegt) wird gel�scht, wodurch
bis zu 128 Bytes in der Umgebung eingespart werden k�nnen.
Leider akzeptiert Novell DOS COMMAND.COM ein vorangestelltes @ nur beim
ersten Kommando einer Zeile, nicht jedoch bei Verkettungen via Piping.
- Wird ein Programm hochgeladen (egal auf welchem Wege) und ben�tigt das
Programm seine Umgebung nicht wirklich (die wenigsten TSRs tun
das), sollte man die Umgebung vor dem Laden freigeben und nachher
wieder einrichten. 4DOS bietet daf�r die SETLOCAL/ENDLOCAL und UNSET
Kommandos:
REM Umgebung tempor�r l�schen:
IF "4"=="%@Eval[2 + 2]%" SETLOCAL %+ UNSET *
REM Nun wird das TSR-Programm hochgeladen:
LH d:\path\tsr parameters
REM Umgebung wieder einrichten:
IF "4"=="%@Eval[2 + 2]%" ENDLOCAL
Werden innerhalb eines solchen Blocks einige Variablen (wie %Path%)
trotzdem ben�tigt, so kann man das Beispiel wie folgt erweitern:
IF "4"=="%@Eval[2 + 2]%" SETLOCAL %+ ALIAS tmpbuf = c:\_path_.tmp ...
... %+ PATH > tmpbuf %+ UNSET * %+ SET /R tmpbuf
LH tsr parameters
IF "4"=="%@Eval[2 + 2]%" DEL tmpbuf > \dev\nul %+ ENDLOCAL
Wichtig ist jedoch, da� Sie auf diese Art und Weise keine Programme
laden, die *nicht* oder nicht vollst�ndig hochgeladen werden (z.B.
SDRES bei EMS-Nutzung, siehe Kapitel II.4.). Denn in diesem Fall
sparen Sie zwar insgesamt den Platz f�r die Umgebung fast komplett
ein, aber dieser Vorteil wird mit dem um Gr��enordnungen verheerenden
Nachteil erkauft, da� der konventionelle Speicher fragmentiert wird.
4DOS speichert n�mlich bei SETLOCAL die alte Umgebung/Alias in einem
Puffer zwischen, der im konventionellen Speicher liegt (und je nach
Konfiguration einige KiloByte (bei mir 3 KByte) gro� ist). Dieser
Puffer wird zwar bei ENDLOCAL wieder freigegeben, aber dadurch, da�
das inzwischen in den konventionellen Speicher geladene TSR nun nicht
mehr dicht an dicht mit seinem Vorg�nger liegt, wird die maximale
zusammenh�ngende Gr��e des konventionellen Speichers um genau diesen
Betrag der zwischengespeicherten SETLOCAL Umgebung verringert. Zwar
kann auch dieser Speicherbereich wieder verwendet werden, aber der
Hauptspeicher bleibt fragmentiert.
###########################################################################
###########################################################################
VI. NETZWERK:
=============
---------------------------------------------------------------------------
VI.1. Netzwerk-Hardware: [96-10-30]
===================================
Stichworte: PNW, EtherNet-Hardware, NE2000, DMA, BNC
Mit Novell DOS 7 geb�ndelt (aber auch einzeln erh�ltlich) ist Personal
NetWare 1.0, der Nachfolger von NetWare Lite (der ehemals kleinste Spro�
in der Novell NetWare-Familie, war u.a. in sp�teren Ausgaben von DR DOS
6.0 beigepackt). Diese Netzwerk-Software ist eine ideale Erg�nzung zu
Novell DOS (aber auch anderen DOS-Versionen, die allerdings nicht schon
generisch integrierten Netzwerk-Support bieten), wenn man mehrere Rechner
miteinander verbinden will, aber sich die Anschaffung der gro�en NetWare
Produkte nicht lohnt. Dabei ist nicht nur der Preis des Produkts aus-
schlaggebend, sondern vor allem der Administrationsaufwand, der z.B.
bei NetWare 3.xx und erst recht bei NetWare 4.xx um ein Vielfaches h�her
liegt. Daher ist Personal NetWare auch f�r kleinere Firmen mit geringer
Infrastruktur interessant, wenn nicht mehr als vielleicht 10 - 40 Rechner
zu vernetzen sind.
Netzadapterkarten sind mittlerweile schon ab ca. DM 30,- zu haben, ein
10m Kabel kostet ca. DM 10,-, T-St�cke und Abschlu�widerst�nde jeweils
unter DM 5,-.
F�r den privaten Gebrauch empfehlen sich NE2000-kompatible Ethernet-
Karten (PNW ist nicht an Ethernet gebunden, dies stellt aber das am
weitesten verbreitetste Netzzugangsverfahren dar).
Diese Karten stellen zwar nicht das Non-Plus-Ultra an Leistung dar, aber
sie sind erstens sehr g�nstig, zweitens reicht die Performance f�r kleine
Netze allemal aus und gegen�ber vielen teureren Karten bieten sie noch
einen entscheidenden Vorteil:
Sie ben�tigen keinen Adre�raum im UMB-Bereich des Rechners, d.h. man hat
mehr Platz f�r Zusatzprogramme (und/oder die Netzwerk-Software) zwischen
den Adaptern und sie benutzen auch keine DMA-Transfers. (Die sonst h�ufig
verwendeten SMC-Ultra-Serien u.a. ben�tigen demgegen�ber ein 8 - 16 KByte
gro�es RAM-Fenster im UMB-Bereich, der f�r anderweitige Nutzung flach-
f�llt). Bei der NE2000 l�uft die gesamte Kommunikation interruptgesteuert
�ber Port-Zugriffe ab, heutige 16Bit-Karten lassen sich flexibel genug
einstellen, da� hier selbst mit vielen anderen Zusatzkarten im Rechner
kaum Adre�konflikte auftreten werden. Probleme mit Treiber-Updates und
anderen Betriebssystemen wird es bei dieser Karte aufgrund der weiten
Verbreitung quasi nie geben.
Als Default-Adresse hat sich 300h oder 240h (manchmal auch 280h)
eingeb�rgert, welche meist auch verwendet werden kann (300h ist der
Prototyp-Bereich); man sollte aber entgegen �blichen Standards eher
einen hohen Interrupt (z.B. IRQ 10) verwenden, um Konflikten mit
seriellen, parallelen Schnittstellen und EGA-/VGA-Karten aus dem Weg
zu gehen.
Als Netzwerkkabel kommt ein 50 Ohm BNC-Koaxialkabel in Frage, das sich
von Karte zu Karte schl�ngelt. An jede Netzadapterkarte kommt ein sog.
T-St�ck, an beiden �u�eren Enden des Stranges ein 50 Ohm-Terminations-
widerstand (wichtig!). Das Kabel sollte mindestens 10m lang sein (auch
wenn man diese L�nge nicht ben�tigt), darf aber nicht l�nger als ca.
170m lang werden, im privaten Bereich sicherlich kein Problem...
Das Kabel sollte nicht geknickt werden, die BNC-Stecker sollten
pfleglich behandelt werden, da sie h�ufig Ursache f�r schwer auffindbare
Fehler sind.
---------------------------------------------------------------------------
VI.2. PNW-Software-Einrichtung: [97-03-02]
==========================================
Stichworte: SETUP /FIRST, DPMS, SERVER, ODI, Frame 802.2, NetWare,
STARTNET.BAT, STOPNET.BAT, NET.CFG, VLM, NET ADMIN,
Ressourcen, Geteilte Verzeichnisse, Server nicht geladen,
Updates, %NWLanguage%, TASKMGR
Leider ist die Software-Installation von PNW nicht ganz einfach zu
bewerkstelligen (aber immer noch sehr viel einfacher, als bei der gro�en
NetWare). Bez�glich der Erstinstallation siehe DOSBOOK und SETUP /FIRST.
Hier k�nnen nur ein paar Einzelhinweise gegeben werden:
Um m�glichst viel Speicher zu sparen, ist es absolut empfehlenswert,
Novells DPMS zu laden. Dadurch wird ein Gro�teil der Netzwerk-Software
(SERVER) in den Zusatzspeicher verlagert und man kommt trotz geladenem
Server auf �hnliche Speichergr��en wie in typischen NetWare 3.xx Netzen
mit IPX/NETX-Treibern etc.
Der Server belegt ca. 30 - 60 KByte (bei DPMS Nutzung) im ersten Mega-
Byte, l��t sich nur selten hochladen, nutzt au�erdem jedoch Extended
Memory via DPMS. (Die Datei SERVER.EXE enth�lt f�r MS Windows auch den
virtuellen Ger�tetreiber VNWLSERV.386.) Die restlichen Netztreiber
ben�tigen weniger Speicher (Gr��enordnung 25 - 40 KByte).
(Mit einem undokumentierten SERVER.EXE Parameter "SERVER L" (wohl auch
"SERVER /L") kann verhindert werden, da� ein spezieller Fix f�r einen
falschen NCP-Call, den manche Datenbankapplikationen (DBase, Clipper)
ausf�hren, eingebunden wird. Dadurch kann man, wenn man bei SHARE keine
Extra-Handles ben�tigt und keine Datenbanken anwendet, ganze 192 Bytes
einsparen. ;-) )
PNW 1.0 verwendet ODI-Treiber und sollte auf FRAME 802.2 eingestellt
werden, wenn man die Anbindung an �ltere NetWare 2.xx, 3.xx Netze nicht
ben�tigt (dort braucht man FRAME 802.3). �hnlich wie bei NetWare 4.xx
arbeitet PNW 1.0 mit der VLM-Technik (virtual loadable module),
eine Parallelentwicklung zu den NLM (netware loadable module) von
NetWare 3.xx+, allerdings bis vor das neue Client32-Kit f�r die Clients.
F�r die Anbindung an NetWare 4.xx werden auch Verzeichnisdienste unter-
st�tzt.
Teilweise ist PNW also auf einem moderneren Stand der Software-Technik
als die weitverbreitete NetWare 3.xx (besonders, was die beiliegenden
Tools angeht), nat�rlich von den M�glichkeiten auf den Bedarf kleiner
Netze zur�ckgeschraubt. Trotzdem k�nnen bis zu 50 Accounts eingerichtet
werden (irgendwo in den Novell Foren gibt es auch einen Hinweis auf bis
zu 244 Accounts).
Eine typische STARTNET.BAT:
@ECHO off
SET NWLanguage=DEUTSCH
REM Diese Variable spezifiziert das Verzeichnis, in dem PNW nach landes-
REM sprachlichen Dateien sucht.
REM Unter DOS mu� das \NLS\%NWLanguage%\ Verzeichnis dort liegen, von wo
REM die Netzwerk-Software geladen wurde: C:\NWCLIENT\NLS\DEUTSCH.
REM Unter MS Windows mu� \nls\%NWLanguage%\ vom Ursprungsverzeichnis der
REM unter Windows geladenen Shell (i. allg. PROGMAN.EXE) ausgehen. In
REM dem Fall, da� die verwendete Shell in C:\WINDOWS\ liegt, resultiert
REM daraus C:\WINDOWS\NLS\DEUTSCH. %NWLanguage% mu� eine g�ltige
REM relative Pfadangabe enthalten, die aber nicht notwendigerweise auf
REM den Namen eines Unterverzeichnisses beschr�nkt sein mu� (siehe auch
REM Kapitel IV.7.). Um ein Beispiel zu geben:
REM Angaben wie ..\NLS\DEUTSCH sind durchaus g�ltig. Ist %NWLanguage%
REM nicht definiert oder ung�ltig, so wird %Path% ausgewertet.
REM %NWLanguage% selbst darf keine Pfadliste enthalten.
c:
CD c:\nwclient
LH LSL
REM LH RXMONSTK f�r manche Netz-Analyzer-/Management-Programme not-
REM wendig, sofern f�r den MLID-Treiber (hier NE2000.COM) das VLM-
REM Update 2+ eingearbeitet wurde, und die entsprechenden Programme
REM noch nicht daran angepa�t wurden.
REM Siehe Hinweise im Archiv VLMUPx.EXE.
LH NE2000
REM IPXODI /A kann auf Kosten der Funkionalit�t Speicher sparen.
LH IPXODI
REM Der Versuch SERVER und/oder VLM hochzuladen (LH), f�hrt bei manchen
REM Konfigurationen zu Abst�rzen und H�ngen, ausprobieren...
REM SERVER wird nat�rlich nur ben�tigt, wenn dieser Rechner Ressourcen
REM mit anderen Rechnern teilen soll.
[LH] SERVER
REM DEDICATE.COM
[LH] VLM /V4
CD \
NET LOGIN %1 %2 %3 %4 %5 %6 %7 %8 %9
(Es gibt noch 1001 Optimierungsm�glichkeiten, die aber hier den Rahmen
sprengen w�rden).
Zum Entladen des Netzwerks bietet sich das Umgekehrte an - STOPNET.BAT:
@ECHO off
IF ""=="%NWLanguage%" SET NWLanguage=DEUTSCH
c:
CD c:\nwclient
NET LOGOUT
VLM /U
SERVER /U
IPXODI /U
NE2000 /U
LSL /U
CD \
Die Datei NET.CFG (Beispiel f�r eine NE2000-Karte):
Link driver NE2000
INT 10
PORT 300
FRAME Ethernet_802.2
NetWare DOS Requester
PREFERRED WORKGROUP = PNWNET ; (offenbar statt WORKGROUP NAME=)
; F�r die Verwendung des TASKMGR (besonders im Proze�umschaltmodus)
; von SERVER.EXE verwendet
ALTERNATE CALLDOS = ON
; Diagnoseausgaben beim Start auf Maximum einstellen:
MESSAGE LEVEL = 4
FIRST NETWORK DRIVE = S
; Unterst�tzte Protokolle NetWare3 BIND, BIND PNW
NETWARE PROTOCOL = PNW
; Zeige Punkte . und .. in Verzeichnisauflistungen
SHOW DOTS = ON
; Message-Timeout (10000 entspricht 6 Stunden laut DOSBOOK,
; aber entspricht 9 Minuten laut c't 9/94???)
MESSAGE TIMEOUT = 10000
; Weniger Speicherbedarf bei geringerer Performance:
; CACHE BUFFERS = 2
; CACHE BUFFER SIZE = 512
; Maximale Namensl�nge verk�rzen (<48>):
AVERAGE NAME LENGTH = 16
; PNW-Responder abschalten:
; RESPONDER = OFF
; Folgende Module auch swappen:
; LOAD LOW CONN = OFF
; LOAD CONN TABLE LOW = OFF
; LOAD LOW IPXNCP = OFF
; Lade alle Standard-VLM und zus�tzlich die AUTO und NMR:
USE DEFAULTS = ON
VLM = AUTO.VLM
VLM = NMR.VLM
Mit den ausgeklammerten Parametern kann man etwas experimentieren, um
den Speicherbedarf zu dr�cken, aber leider damit auch teilweise stark
die Performance zu drosseln. U.U. kann es auch vorkommen, da� die
Konfiguration instabil wird, austesten...
Wichtig:
Am Ende der Datei NET.CFG mu� eine Leerzeile stehen (d.h. auch der
letzte Eintrag mu� mit <Return> abgeschlossen werden), ansonsten kann
es passieren, da� die letzte Zeile �berlesen wird!
Eine �bersicht �ber die derzeit g�ltigen NET.CFG Parametern (die sich
im Laufe der Zeit in einigen Dingen ge�ndert haben), findet sich in
den VLMUPx.EXE Updates in der Datei NET.CFG, in NETCFG.TXT u.a., siehe
auch Kapitel VI.12.
Weitere Server-Einstellungen kann man in NET ADMIN ('Server konfigu-
rieren') vornehmen, hier sollte man m�glichst alle Module laden (au�er
'lokale Best�tigung'), bei den 'erweiterten Einstellungen' mu� man
unbedingt darauf achten, da� man nicht weniger geteilte Ressourcen
angibt, als wirklich vorhanden sind, sonst kann es vorkommen, da� der
Server beim n�chsten Mal nicht mehr hochf�hrt und mit der irref�hrenden
Fehlermeldung
"Server konnte nicht geladen werden, da Konfigurationsdatei zu einer
anderen Version der Servers geh�rt, oder besch�digt ist."
abbricht.
H�ufig sucht man den Fehler dann erst wochenlang an v�llig anderen
Stellen. :-(
Entsprechend mu� man die Ressourcen auch hochsetzen, *ehe* man neue
Hardware einbaut, sonst kann man b�se �berraschungen �berleben und darf
u.U. alles wieder ausbauen.
Hinweis bez�glich 'geteilter Verzeichnisse':
Diese Angabe mu� gr��er oder gleich der Anzahl logischer Blockger�te-
treiber sein, die man in der DOS-Konfiguration l�dt. Dabei z�hlt z.B.
jede Floppy, jede DOS-Partition einer Harddisk, jeder Eintrag via
DRIVER.SYS, jede RAM-Disk (RAMDRIVE, VDISK, TurboDSK u.a.), jedes
komprimierte Laufwerk und Host-Laufwerk (STACKER, DBLSPACE, DRVSPACE
u.a.), jeder spezielle Treiber f�r Speziallaufwerke wie CD-ROMs,
CD-WOs, CD-MOs, spezielle Streamer, die wie Laufwerke angesprochen
werden.
Sollten also obige Fehlermeldung auftauchen, mu� der Rechner in einer
Minimal- oder Null-Konfiguration gestartet werden, in der nichts geladen
wird, was nicht unbedingt zum Booten des Rechners notwendig ist. Wenn
der Server dann ohne Fehlermeldung l�dt, m�ssen nach und nach alle
zus�tzlichen Programme wieder eingebunden werden, bis der Server nicht
mehr l�dt. Die Ressource, die der zuletzt eingebundene Treiber bereit-
stellt, mu� dann um die entsprechende Anzahl ihrer Bereitstellung hoch-
gesetzt werden (Auch, wenn es gar nicht gew�nscht ist, diese Ressource
zu teilen: sie ist aber vorhanden und mu� verwaltet werden). Wie, wenn
der Server nicht mehr l�dt?
Der Treiber mu� wieder entfernt, der Rechner neu gebootet, der Server
gestartet und mit NET ADMIN 'Server konfigurieren' der entsprechende
Eintrag erh�ht werden.
�brigens ist es sogar m�glich, da� dieses Problem bereits nach der Erst-
installation auftaucht, wenn das SETUP-Programm eine Ressource nicht
erkannt hat und Default-Einstellungen vornimmt. In so einem Fall n�tzt
es �berhaupt nichts, verzweifelt den Server neu (auf einem vielleicht
anderen Weg) installieren zu wollen. Der oben beschriebene Weg sollte
jedoch auch dann funktionieren.
Ich hatte lange Zeit auch ein Problem mit einem PNW-Server, auf dem
immer wieder EMM386-Schutzfehlern auftraten, sobald man Dateien vom
Server kopieren oder auch nur ansehen wollte. Es stellte sich auch
heraus, da� in vielen Dateien, die auf den Server kopiert worden waren,
ab einer immer gleichen Position in der Datei (bei mir Offset 2162) f�r
einige Bytes (516 - 520 Bytes) willk�rliche Daten eingestreut waren (die
Dateil�nge, Datumsstempel, der Anfang und der Rest der Datei waren v�llig
ok, so da� dies erst sp�t auffiel). Obwohl die Konfigurationsdateien den
anderer PNW-Server entsprachen, war das Problem erst zu l�sen, nachdem
ich mit NET ADMIN die Server-Konfiguration so ver�ndert hatte, da� die
Empfangspuffergr��e auf 1024 eingestellt war. Dies kann nat�rlich nicht
verallgemeinert werden, bei �hnlichen Problemen sollten Sie aber diese
Einstellungen sehr genau auf Plausibilit�t �berpr�fen und evtl. damit
experimentieren.
Eine Fehlermeldung der Art 'VLM xxx-47: Es konnte kein Server gefunden
werden. Vor dem Fortfahren Verkabelung und Server-Status �berpr�fen!',
scheint beim Hochfahren eines Servers 'normal' zu sein, jedenfalls konnte
ich diese Meldung bisher nicht umgehen (trotz PREFERRED WORKGROUP= und
PREFERRED SERVER=). Nachteile sind dadurch nicht aufgefallen, sofern der
Server vorher in Wahrheit doch korrekt geladen wurde (laut seiner eigenen
Startmeldung). Trotzdem, hat jemand eine L�sung?
�brigens: Wie oben schon angedeutet, ist das xxx in der ID der Fehler-
meldung variabel und entspricht der VLM-Versionsnummer.
Wenn Sie die entsprechenden Fehlermeldungen im DOSBOOK Anhang E suchen,
m�ssen Sie unter "modul-version-nummer" suchen (wobei hier modul=VLM,
version=1.00 und nummer=47 w�re). 1.00 entsprach dem Stand der VLMs in
den Beta-Versionen von Novell DOS 7 und PNW.
Die Netzwerk-Software, die mit PNW 1.0 und Novell DOS 7 mitgeliefert
wurde, entspricht der Ebene von VLM 1.10. Mittlerweile wurden manche
PNW-Dateien upgedated (P10G05.EXE) und insbesondere die allgemeine
Netzwerk-Software mit der Herausgabe von NetWare 4.10 stark aktualisiert.
Es empfiehlt sich daher dringend, die Dateien aus dem Archiv VLMUP4.EXE
in die PNW-Client- und Server-Konfiguration einzuarbeiten. Noch besser
und aktueller geht es mit VLMKT_1.EXE - VLMKT_6.EXE bzw. dem neueren
VLM121_1.EXE - VLM121_6.EXE, womit die VLMs auf die Software-Ebene 1.20B
bzw. 1.21 angehoben werden. Dabei sind allerdings einige Dinge zu be-
achten und es ist leider nicht in jedem Fall gew�hrleistet, da� man die
Updates einfach �ber die alten Dateien kopieren kann.
Trotzdem ist dies meistens dennoch m�glich, wenn man die dem Paket
beiliegenden ausf�hrlichen Hinweise beachtet (seit kurzem gibt es auch
ein speziell f�r PNW konfektioniertes Update-Paket von Novell, N�heres
siehe Kapitel I.2). Um die Fehlermeldung zu vermeiden, da� man eine alte
Version einer Message-Datei .MSG verwendet, kann man die entsprechende
Datei aus dem Unterverzeichnis \NWCLIENT\NLS\ENGLISH\ in das Verzeichnis
\NWCLIENT\NLS\DEUTSCH\ kopieren, bis deutsche Versionen dieser Dateien
erh�ltlich sind (ist mit dem VLM-Kit allerdings der Fall f�r Deutsch,
Englisch, Spanisch, Italienisch und Portugisisch).
Was die Benennung von Ressourcen im Netz angeht, sollte man sich vorher
Konventionen �berlegen, um so sp�ter eindeutig zwischen Servern,
Benutzern, Arbeitsgruppen, Laufwerken, Verzeichnisb�umen, Druckern,
Queues, Formularen usw. unterscheiden zu k�nnen.
Dazu k�nnen die Namen den Typ der Ressource enthalten, indem sie jeweils
auf einer bestimmten Buchstabenkombination enden, z.B.:
_PC f�r Server
_GRP f�r Arbeitsgruppen (oder _NET bei PNW)
_DRV f�r Laufwerke
_PRN f�r Drucker
Obwohl dabei mehr als 8 Zeichen erlaubt sind, empfiehlt sich dies aus
kosmetischen Gr�nden nicht, da f�r mehr als 8+3 Zeichen innerhalb des
versteckten Verzeichnisses \NWCNTL\ gleich mehrere ineinander ver-
schachtelte Unterverzeichnisse eingerichtet werden, um die �berl�nge im
Namen irgendwo unterzubringen (wegen der 8.3 Namenskonventionen von DOS).
Dies kann bei manuellen Wartungsarbeiten �u�erst st�rend sein.
M�chten Sie einen PNW-Server als 'Dedicated Workstation' betreiben?
In diesem Fall kann u.U. die Performance verbessert werden, wenn Sie
- am besten in STARTNET.BAT direkt nach dem Aufruf von SERVER - ein
kleines Tool von NetWare Lite laden: DEDICATE.COM.
Dieses Progr�mmchen macht nichts weiter, als in einer Schleife permanent
INT28h-Calls abzuschie�en (DOS IDLE) und dabei ab und zu die Tastatur
abzufragen, ob denn eine Taste zum Beenden des Programms gedr�ckt wurde.
Ich habe nicht �berpr�ft, ob dies bei PNW wirklich noch notwendig ist,
bei alten DOS-Versionen k�nnte es aber von Vorteil sein. Eines steht
jedenfalls fest: Schaden kann es nicht, wenn Sie den Rechner sowieso
nicht benutzen (au�er eben als PNW-Server). Wenn Sie in Besitz einer
NetWare Lite Lizenz sind, k�nnen Sie das Tool z.B. aus dem Update
NWL11G.EXE beziehen, andernfalls kann es in wenigen Minuten auch
selbst geschrieben werden.
Wird DEDICATE.COM direkt nach Server geladen, hat dies noch einen
weiteren Vorteil (den man aber auch anders erreichen kann). Solange
man den Rechner wirklich nur als Server ben�tigt, wird auch VLM.EXE
(inkl. seiner .VLMs) noch nicht geladen. Dadurch steht mehr Speicher
f�r den hoffentlich geladenen NWCACHE zur Verf�gung. Mu� man diesen
Rechner nun doch als 'Non-Dedicated Server' nutzen, braucht man nur
eine Taste zu dr�cken: DEDICATE wird beendet, VLM wird geladen und
man kann sich ins Netz einloggen.
F�r Netzwerk-Anf�nger: VLM wird nicht ben�tigt, wenn Sie den Rechner
nur als Server ben�tigen; SERVER wird nicht ben�tigt, wenn Sie den
Rechner w�hrend einer Session nur als Workstation nutzen! Da insb. der
SERVER die Performance sehr stark drosselt, sollte er in diesem Fall
tunlichst nicht geladen werden!
Arbeitet man immer im Netz und ben�tigt die Entladem�glichkeit der
Netztreiber nicht, kann man sowohl die Treiber der IPX-Schicht (bei
Personal NetWare also LSL.COM, MLID-Hardware-Treiber wie z.B. NE2000.COM,
sowie IPXODI.COM), als auch den SERVER.EXE per INSTALL[HIGH]= bereits in
CONFIG.SYS laden, was die Chance zum Hochladen erh�ht. VLM.EXE kann
leider nicht in CONFIG.SYS geladen werden (auch nicht mit INSTCDEX.EXE).
�brigens:
Es ist zwar nicht m�glich, VLM.EXE oder SERVER.EXE erst innerhalb eines
Task des multitaskenden TASKMGR zu laden, sehr wohl funktioniert dies
jedoch auf einem Novell DOS 7 System in einer DOS-Box im Erweiterten
386er-Modus von Windows 3.1x (die �blichen zu PNW geh�rigen Netztreiber
f�r Windowas waren geladen; wahrscheinlich sind sie aber gar nicht mal
notwendig - nicht �berpr�ft)! Bei meinen Experimenten konnte VLM.EXE
die Module NMR.VLM und FIO.VLM nicht laden und der SERVER.EXE kein DPMS
nutzen (was ein paar Probleme bereitet, z.B. st�rzt der Server w�hrend
der Ladephase schon mal ab, wenn DPMS durch CLOAKING bereit gestellt
wird, nicht aber, wenn man CLOAKING �ber DPMS l�dt, siehe Kapitel II.4.),
ansonsten arbeitete das System stabil. Nat�rlich ist dies nicht die von
Novell empfohlene Betriebsart und man ist verschiedenen Einschr�nkungen
unterworfen und sollte immer im Hinterkopf behalten, welche impliziten
Auswirkungen diese Konstallation hat.
Trotzdem er�ffnet sich dadurch eine ganz neue Perspektive:
Der Nachteil, da� die Netzverbindung ausschlie�lich in der einen
DOS-Box genutzt werden kann, wird dadurch aufgewogen, da� in den
anderen DOS-Boxen �berhaupt kein Speicher f�r die Netzverbindung
ben�tigt wird. In der Regel hat man also 50 - 150 KByte mehr freien
Speicher! Arbeitet man sowieso nicht mit Netzapplikationen (wie in
der Praxis beim Einsatz von Personal NetWare gerade h�ufig der Fall),
so wird die Netzverbindung in erster Linie nur zum schnellen Daten-
austausch genutzt. Daf�r reicht aber gerade auch die Verbindung in
*einer* DOS-Box prima aus... Da� der Server in dieser Konstellation
als ein Task unter mehreren nat�rlich eine wesentlich geringere
Performance hat, kann auch ein Vorteil sein. So l��t sich n�mlich
in anderen Tasks fast ohne Geschwindigkeitseinbu�en arbeiten. Wird
der Server global geladen, wird sonst die Weiterarbeit auf langsamen
Server-Rechnern (z.B. 386sx16) zur Qual...
Sollten Sie regelm��ig mit dieser Sonderl�sung arbeiten wollen,
ist es praktisch, sich daf�r eine spezielle DOS-Box vorzudefinieren,
die automatisch die Netztreiber l�dt, indem Sie im PIF-Editor als
Aufrufparameter z.B. f�r PNWPRMPT.PIF angeben:
Programm : %ComSpec%
Aufrufparameter: /K c:\nwclient\startnet.bat
Sogar das Problem mit DPMS und CLOAKING l��t sich hier abfangen,
wenn Sie STARTNET.BAT ein bi�chen erweitern (es wird eine �berpr�fung
ben�tigt, ob Windows gerade l�uft) und eine zus�tzliche Abfrage ein-
bauen, ob das Ger�t DPMS installiert ist:
IF NOT EXIST \dev\DPMSXXX0 GOTO error
oder - je nachdem -:
IF EXIST \dev\CLOAK$$$ GOTO error
Die Ikone f�r PNWPRMPT.PIF k�nnen Sie nat�rlich auch in die AutoStart-
Gruppe aufnehmen...
Noch etwas: Die Treiber der IPX-Schicht k�nnen sehr wohl unter dem
multitaskenden TASKMGR in einem Task geladen werden. F�r Programme
(wie FASTLYNX), die nur diese untere Protokollschicht nutzen, kann
man diesen Trick also auch unter dem multitaskenden TASKMGR nutzen,
siehe Kapitel II.8.
---------------------------------------------------------------------------
VI.3. Mehrere PNW-Server in einem Netz: [97-01-04]
==================================================
Stichworte: NetWare, PNW, Bindery, Arbeitsgruppe, NET ADMIN, Ressourcen
Es ist - im Gegensatz zu den gro�en NetWare-Versionen - bei PNW m�glich,
auch mit nur *einer* gekauften Version mehrere Server am gleichen Netz
und in der gleichen Arbeitsgruppe ans Laufen zu bringen (dies verletzt
allerdings wohl i. allg. die Lizenz - PNW sollte entsprechend h�ufig
lizensiert werden) (ein Server kann allerdings nur gleichzeitig in einer
Arbeitsgruppe angemeldet sein). Die 'Bindery' (oder eher Konfigurations-
datenbank, PNW besitzt diesbez�glich eine andere Organisationsform als
die gro�e NetWare: eine Distributed Object Database (DOD)) wird dabei
nicht zerschossen, wenn man wie folgt vorgeht:
Jeder Server wird einzeln installiert (ohne, da� eine Verbindung
zwischen den Rechner besteht) und f�r jeden Server wird die gleiche
Arbeitsgruppe eingerichtet (also *nicht* eine bereits auf einem anderen
Server vorhandene Arbeitsgruppe �bernehmen). Dann werden alle Server
'hochgefahren' und in ihrer Arbeitsgruppe angemeldet (PNW fragt nach,
welche Arbeitsgruppe gemeint ist, wenn mehrere Gruppen mit dem gleichen
Namen existieren, jede Arbeitsgruppe l��t sich jedoch trotzdem eindeutig
zuordnen). Danach loggt man sich ein und startet NET ADMIN, dort wird
dann die eigene Arbeitsgruppe gel�scht und der Server in die gleich-
namige Arbeitsgruppe eines anderen Servers verschoben. Die Ressourcen
sollte man dabei *nicht* �bernehmen! Schlie�lich hat man alle Server
in der gleichen und i. allg. auch einzigen Arbeitsgruppe versammelt.
Es ist gut m�glich, da� es auch andere M�glichkeiten f�r dieses Unter-
fangen gibt.
---------------------------------------------------------------------------
VI.4. PNW Login-Skripte in Multi-Konfigurationen:
=================================================
Stichworte: PNWLOGIN.SCR, NET, Umgebungsvariablen, 4DOS
Benutzer von Multi-Konfigurationen (auch �ber mehrere Rechner hinweg)
sollten beim Erstellen von Login-Skripten (Dateien im versteckten
Verzeichnis C:\NWCNTL\MAIL\xxxxxxxx\PNWLOGIN.SCR) sehr vorsichtig
sein!
Wenn man mit NET verschiedene Einstellungen vorgenommen hat und diese in
seiner Login-Skript speichern will, werden dabei nicht nur die Laufwerk-
Mappings und Druckerzuordnungen gespeichert, sondern auch die aktuelle
Umgebung. Arbeitet man nun mit einer anderen Konfiguration als der,
unter der das Login-Skript erstellt wurde, werden beim Einloggen die
Variableneinstellungen der falschen Konfiguration wiederhergestellt, was
je nach Raffinesse der Konfiguration sehr weitreichende Folgen haben
kann. Besonderen Augenmerk verdienen die Variablen %ComSpec%, %CONFIG%
und %Path% in den jeweiligen Dateien PNWLOGIN.SCR. Sie sollten vorher mit
einem REM markiert werden. F�r die meisten F�lle wird es am besten sein,
alle SET Eintr�ge aus den PNWLOGIN.SCR Dateien zu entfernen, damit keine
ungew�nschten Interferenzen auftreten k�nnen.
Beispiel:
Eine Multi-Konfiguration arbeitet wahlweise mit 4DOS.COM oder COMMAND.COM
als Kommandoprozessor. Hat man das Login-Skript unter der 4DOS-Konfigura-
tion erstellt, wird auch dann die Einstellung %ComSpec%=...\4DOS.COM beim
Login gesetzt, wenn man im Moment lediglich unter COMMAND.COM arbeitet.
Die Folge ist, da� der Rechner nach Beenden des ersten gr��eren Pro-
gramms, das nach dem Einloggen gestartet wurde, mit einer Fehlermeldung
stehen bleibt (weil der transiente Teil von COMMAND.COM - �ber %ComSpec%
referenziert - nicht mehr nachgeladen werden kann).
---------------------------------------------------------------------------
VI.5. NETWARS als Netzanalyse-Werkzeug: [96-05-09]
==================================================
Stichworte: Netzwerk-Hardware, NETWARS, ODI, VLM, SERVER, COMCHECK
H�ufig k�nnen schon bei der Hardware-Installation eines Netzes unent-
deckte Fehler auftauchen, die verhindern, da� die PNW-Software sauber
arbeiten kann. Ist bereits ein grundlegendes Netz hochgezogen (d.h. die
ODI-Treiber (ausgenommen VLM und SERVER) sollten geladen sein), kann man
versuchen, mit dem Spiel NETWARS �ber das Netz zu mehreren Spielern zu
spielen (alle Spieler m�ssen das gleiche 'Universum' w�hlen). Sollte dies
gelingen und man tats�chlich feindliche Schiffe - durch die anderen
Benutzer gesteuert - entdecken, liegt der Fehler mit ziemlicher Sicher-
heit nicht in der Hardware-Konfiguration, d.h. die Netzadapterkarten und
die Verkabelung arbeiten sauber, ebenso sind die ODI-Treiber �ber NET.CFG
richtig eingestellt.
Ebenfalls hilfreich f�r grundlegende Analysen am Netz ist das Utility
COMCHECK.EXE aus dem Archiv COMCHK.EXE.
---------------------------------------------------------------------------
VI.6. PNW und Dateiattribute: [96-05-05]
========================================
Stichworte: PNW, ATTRIB, Kopieren, System-Attribut, Read-Only-Attribut,
Client, Server
i. PNW und Dateiattribute von DOS:
----------------------------------
Gegen�ber der gro�en NetWare benutzt PNW das Dateisystem von DOS.
Entsprechend sind auch nur die vier �blichen Attribute auf Dateien
und (wie meist nicht bekannt) Pfade anwendbar: Archiv A, Read-Only R,
Hidden H und System S (f�r interne Zwecke gibt es noch zwei Bits mehr:
Volume V und Directory D). Mit PASSWORD gibt es offiziell noch drei
'Attribute' (hier Zugriffsrechte) mehr, Multiuser-Varianten verwenden
noch weitere 'Attribute' (siehe PASSWORD, Kapitel II.4.). Besitzt eine
Datei allerdings mit PASSWORD vergebene eingeschr�nkte Zugriffsrechte,
so kann von entfernten Rechnern nur soweit darauf zugegriffen werden,
wie daf�r kein Pa�wort erforderlich ist. Die �bermittlung von Datei-/
Verzeichnispa�w�rtern �ber das Netz ist nicht m�glich.
Daher sind die M�glichkeiten, den Zugriff auf Dateien zu steuern gegen-
�ber der gro�en NetWare ziemlich beschr�nkt, f�r kleinere Netze reichen
diese Optionen jedoch aus. Die Funktion der Attribute entspricht im
Prinzip der Funktion unter DOS, allerdings gibt es ein paar Besonder-
heiten:
- Read-Only-Attribut erlaubt Mehrfachzugriff:
By the way: Viele (vor allem �ltere) Programme benutzen Methoden, Dateien
zu �ffnen, die in Netzen dazu f�hren, da� die Datei auch im Lesezugriff
nur von einem Programm gleichzeitig ge�ffnet werden kann (gerade, wenn
ein Benutzer sowieso nur Read-Only-Rechte auf einem PNW-Server hat). In
diesem Fall hilft es meist, da� Read-Only-Attribut der Datei zu setzen,
sowohl bei ausf�hrbaren Dateien, als auch bei Datendateien (wenn diese
nicht ver�ndert werden m�ssen, z.B. wie diese Textdateien...) Hat der
Benutzer jedoch Lese- und Schreibrechte funktioniert dies nicht immer...
ii. Mit PNW Systemdateien �ber's Netz l�schen:
----------------------------------------------
Mit PNW ist es auf den ersten Blick nicht m�glich, Dateien zu l�schen,
die auf einem Server das System-Attribut gesetzt haben, bzw. vom Client
aus solche Dateien per Kopieraktion upzudaten. Wenn man das dennoch
m�chte, mu� man zuerst diese Attribute mit ATTRIB l�schen, danach k�nnen
die Dateien ganz normal bearbeitet werden.
Umgekehrt ist es aber sehr wohl m�glich, Dateien, die auf dem Client
mit dem System-Attribut versehen sind, mit Dateien eines Servers zu
�berschreiben.
---------------------------------------------------------------------------
VI.7. Tips f�r Pa�w�rter:
=========================
Stichworte: Pa�w�rter, Sicherheit, MS-DOS, PASSWORD, SECURITY, NetWare,
PNW
Unter Novell DOS kann man in vielen Situationen Pa�w�rter angeben.
Da die Datei-, Pfad- und globalen Pa�w�rter sich sehr leicht (durch
Booten unter MS-DOS) ausschalten lassen, sind sie - einzeln genommen -
eher sinnvoll, um das versehentliche L�schen, Umbenennen oder Modifi-
zieren wichtiger oder fremder Dateien zu verhindern (mehr dazu in
Kapitel II.4. bei PASSWORD und SECURITY.OVL). In Verbindung mit einem
Systempa�wort, das beim Booten abgefragt wird, wird jedoch der Schutz
vor unberechtigtem Zugriff schon wesentlich verbessert (allerdings
l��t sich auch dieser Schutz mit einigem Aufwand und evtl. partiellem
Datenverlust aushebeln).
Dadurch wird auch die sinnvolle Namenswahl f�r die Datei- und Ver-
zeichnispa�w�rtern und des globalen Pa�worts, das mit dem Anmelde-
pa�wort korrellieren kann, wichtig.
In Verbindung mit den Novell-Netzen (speziell PNW) wird die Angabe
von Pa�w�rtern besonders wichtig. Der hier gebotene Schutz ist sehr
umfassend (wenn der direkte Zugang zu einem Server verhindert wird,
etwa indem er in einem gesicherten Raum steht) und im Prinzip nicht
ausgehebelt werden (wenn bestimmte Voraussetzungen gelten). PNW stellt
insofern eine gewisse Ausnahme da, als da� durch die Eigenart eines
Peer-to-Peer-Netzes meist der direkte Zugang zum PC erlaubt ist, aber
grunds�tzlich sind die Pa�wortmechanismen genauso sicher bei der
'gro�en' NetWare.
Novell DOS erlaubt ein spezielles Feature der 'einmaligen Anmeldung'
(One-Time-Login), das nach Angabe des Benutzernamens und Pa�wortes den
Zugriff auf den lokalen Rechner und die zugeh�rigen Netzverbindungen
erlaubt.
Deshalb sollte man bei der Angabe von Pa�w�rtern verschiedene Grundregeln
beachten:
- Der Benutzer mu� sich auch nach l�ngerer Zeit an sein Pa�wort erinnern
k�nnen (diese Aussage ist besonders wichtig f�r den SUPERVISOR des
Netzes).
- Das Pa�wort sollte nirgendwo notiert werden (oder wenn, dann nur so,
da� der Zugriff durch andere Personen sicher verhindert wird (Tresor).
Also nicht in der Schreibtischschublade, neben dem Monitor, neben der
Tastatur!!!)
- Das Pa�wort sollte kein Wort sein, das jemand anderen leicht erraten
werden kann, also nicht der zweite Vorname, das Geburtsdatum, der Namen
von Verwandten, der Freundin...
- Das Pa�wort sollte nicht zu lang sein, da� man es sich nicht mehr
merken kann (und doch irgendwo notiert). Die maximale L�nge von Datei-,
Verzeichnis-, und globalen Pa�w�rtern betr�gt 8 Zeichen, die NetWare-
Pa�w�rter bis zu 12 Zeichen.
- Das Pa�wort sollte auch nicht zu kurz sein, da� es durch wenige Ver-
suche erraten werden kann (also mindestens 5 Zeichen lang).
- Bei wichtigen Accounts sollte das Pa�wort kein Wort sein, das in
einem Lexikon oder Duden vorkommt, da es sonst durch sukzessives
Ausprobieren geknackt werden kann (es gibt Programme, die soetwas
automatisch machen). Also stattdessen zusammengesetzte W�rter,
Phantasiew�rter oder Kombinationen von Buchstaben und Zahlen.
- In einem Pa�wort sollten normalerweise nur Ziffern und Buchstaben
vorkommen, keine Sonderzeichen oder Umlaute, da diese u.U. bei
zuk�nftigen Software-Versionen nicht mehr akzeptiert werden k�nnten
(und man sich dann nicht mehr einloggen kann).
- Manchmal problematisch sind Pa�w�rter, die 'Y' oder 'Z' enthalten,
da diese Buchstaben bei der deutschen Tastaturbelegung von der
amerikanischen Belegung abweichen und es durch eine Software-�nderung
oder Umkonfiguration vorkommen kann, da� zum Zeitpunkt der Pa�wort-
eingabe keine deutsche Tastatur unterst�tzt wird (etwa wenn kein
Tastaturtreiber geladen ist oder w�hrend der Systemanmeldung bei einem
amerikanischen Update f�r Novell DOS). In diesem Fall w�rden 'Y' und
'Z' vertauscht und man k�nnte sich nicht einloggen. Die Ursache einer
falschen Tastaturanpassung wird h�ufig �bersehen (weil sie so unwahr-
scheinlich ist und weil die Pa�worteingabe verdeckt erfolgt), gerade
mit dem Feature der einmaligen Anmeldung (und damit noch vor dem Laden
eines Tastaturtreibers) ist dies sehr wichtig, wenn man sich sp�ter
unter anderen Bedingungen einloggen m�chte.
- In gewissen Zeitabst�nden sollte man die Pa�w�rter (zumindest bei
NetWare) �ndern, damit die Wahrscheinlichkeit des Erratens minimiert
wird. NetWare (auch PNW) erlaubt hier recht umfangreiche Einstellungs-
m�glichkeiten: minimale Pa�wortl�nge, forcierter Pa�wortwechsel in
einstellbaren Zeitabst�nden oder bei einem definierbarem Datum,
automatisch ablaufende Accounts, die erst wieder freigeschaltet
werden m�ssen, Abwehr von Eindringversuche durch Zeitschranken
zwischen falschen Pa�worteingaben oder gesperrte Accounts nach einer
gewissen Anzahl von falschen Einlog-Versuchen. Au�erdem die Angabe,
zu welchen Zeiten man sich �berhaupt nur einloggen darf, usw.
---------------------------------------------------------------------------
VI.8. PNW ohne Novell DOS 7 installieren:
=========================================
Stichworte: PNW, SETUP, SETUP2, INSTALL
M�chten Sie nur den PNW-Teil von Novell DOS 7 installieren, reicht es
aus, die Novell DOS 7 Disketten auf die Festplatte zu kopieren und die
Datei SETUP2.EX_ mit PNUNPACK zu entpacken und in SETUP.EXE umzunennen.
Nach dem Aufruf kann man PNW ohne Novell DOS 7 installieren (denn SETUP2
�bernimmt die Feineinstellung und die Installation einzelner Features
wie PNW, Security etc. wohingegen INSTALL das Grundsystem bootf�hig
macht). Weitere Hinweise zu INSTALL/SETUP gibt es in Kapitel I.2. .
Bei Novell kann ein kostenloses Paket D72PNW.EXE (Lesart "DOS 7 'to'
PNW") bezogen werden, das aus den 3,5" Original-Installationsdisketten
ein einzeln installierbares PNW-System generiert. Diese L�sung ist
nat�rlich der obigen 'Do-it-Yourself'-Methode vorzuziehen.
---------------------------------------------------------------------------
VI.9. Hinweise zu NET.EXE: [97-01-04]
=====================================
Stichworte: PNW, NET.EXE
Die Benutzeroberfl�che von PNWs NET.EXE l��t sich genauso wie die
Novell DOS Programme konfigurieren.
Die folgenden M�glichkeiten sind undokumentiert:
Die Konfiguration des Benutzer-Interfaces wird der Datei
%NWDOSCFG%\NWDOS.INI entnommen. Nur wenn diese Datei nicht existiert,
wird alternativ die Datei %NWDOSCFG%\COLORS.INI (bzw. COLORS.INI)
ausgewertet. (Leider ist die Priorit�t nicht umgekehrt, was noch etwas
mehr Flexibilit�t erm�glichen w�rde.)
Innerhalb dieser Datei wird - falls vorhanden - die Gruppe [NET] nach
den Direktiven
NewUI=on|off
CurrentColor= (Palettennummer 0..9)
durchsucht, falls diese Gruppe nicht existiert, wird die Default-
Einstellung f�r NewUI= und CurrentColor= aus der Gruppe [COLORS]
gew�hlt. Dort sind auch die einzelnen Farbpaletten mit ColorSetX=
Direktiven definiert (X=<CurrentColor> aus 1..9, N�heres siehe Kapitel
II.4.).
Au�erdem wertet NET.EXE bei Bedarf f�r den integrierten Editor auch
noch die Gruppe [EDITOR] (Kapitel II.4.) aus und entnimmt ihr ebenfalls
NewUI= und CurrentColor=.
In der NET.CFG Datei werden von NET.EXE die folgenden Direktiven
NETWARE DOS REQUESTER
PREFERRED WORKGROUP=<workgroup name>; (offenbar statt WORKGROUP NAME=)
WORKGROUP NET=<workgroup net address>
BROADCAST RETRIES=<2> ; 0..255
BROADCAST TIMEOUT=<3> ; 1..255
BROADCAST SEND DELAY=<0> ; 0..255
ausgewertet (siehe Kapitel VI.12.).
Sollte der in NET.EXE integrierte DOS-Extender??? (RTLink/Plus) Probleme
mit der Speicherverwaltung bekommen, kann er mit verschiedenen
Umgebungsvariablen konfiguriert werden: Die Verwendung einer bestimmten
Speichersorte f�r ein bestimmtes Modul wird dabei durch den Wert 0 de-
aktiviert. M�gliche Variablen sind (vgl. bei SETUP.EXE in Kapitel II.4.):
VM-Manager: RTVMEXT, RTVMEXP, RTVMCONV
Overlay-Manager: RTOVEXT, RTOVEXP, RTOVCONV
NET.EXE kann man auch als SHELL f�r eine Reihe Dienstprogramme be-
trachten, die bei der gro�en NetWare als externe Tools vorliegen.
�ber Aufrufparameter lassen sich nahezu alle (und noch einige andere)
M�glichkeiten der Oberfl�che auch direkt aus Batchjobs heraus abwickeln,
z.B. in Login-Skripten oder f�r Wartungsjobs. Im Fehlerfall liefert
NET.EXE dabei Errorlevel gr��er 0 zur�ck, so da� man in Batchjobs mit
IF ERRORLEVEL 1 GOTO error
auf Fehlerzust�nde �berpr�fen kann.
NET.EXE unterst�tzt noch eine Reihe zus�tzlicher Parameter, die nicht
oder nur unvollst�ndig im DOSBOOK oder in der eingebauten Parameterhilfe
(NET /? oder NET /? thema) dokumentiert sind:
NET ATTACH wie NET CONNECT (d.h. siehe NET /? CONNECT)
NET CAPTURE nur im DOSBOOK dokumentiert sind die zwei Schalter:
S=name zur Angabe eines Initialisierungszeichenkette, die
vor einem Ausdruck an den Drucker gesendet wird.
Der Standard S=default schickt keine zus�tzliche
Sequenz ab.
W=time zur Angabe der Wartezeit, die einen abgeschickten
Druckjob auch ohne explizite Beendigung beendet,
so da� einzelne Druckjobs, die in gen�gend gro�en
zeitlichen Abst�nden eintreffen, automatisch von-
einander getrennt behandelt werden. Werden Druck-
auftr�ge zu fr�h abgeschnitten, mu� diese Wartezeit
erh�ht werden.
NET CASTON Diese beiden Schalter erlauben das Aktivieren oder Unter-
NET CASTOFF dr�cken von eintreffenden Meldungen. Falls aktiv, werden
eingehende Meldungen mit einer Message angek�ndigt. In
manchen F�llen kann dies sehr st�rend sein oder Probleme
verursachen, da die Abarbeitung der Applikation ohne
Timeout solange aussetzt (nachteilig bei unbemanntem
Betrieb, z.B. �ber Nacht). Auch nicht netztaugliche Grafik-
programme (z.B. PC DRAFT) bereiten schon 'mal Probleme,
weil die Meldung im Grafikmodus nicht angezeigt wird aber
trotzdem best�tigt werden mu�. Viele Benutzer kommen dann
nicht auf die Idee, 'blind' <Ctrl>+<Enter> zu dr�cken und
halten die Anwendung f�r abgest�rzt (siehe PCDTIPS.TXT).
NET DETACH Hiermit kann gezielt die Verbindung zu einem bestimmten
Server aufgehoben werden und wirkt damit gegenteilig wie
NET ATTACH alias NET CONNECT. Obwohl undokumentiert,
existiert eine eingebaute Hilfe: NET /? DETACH, auf die
man nur durch Zufall sto�en mu�...
NET MAP DEL Diese Option ist nur in der eingebauten Hilfe NET /? MAP
dokumentiert.
NET RIGHTS DEL kann statt NET RIGHTS DELETE verwendet werden.
NET USER wirkt exakt wie NET und startet die Benutzer-Oberfl�che.
Sollten Sie Probleme mit NET.EXE haben, ist f�r Sie vielleicht
interessant, da� das derzeitige Archiv PNWUPD.EXE (05/1996) eine
aktuellere Version (1.05), als das PNW-Update 5 P10G05.EXE enth�lt
(1.03).
Noch ein kleiner Hinweis am Rande (wenn auch etwas aus des dem
Zusammenhang):
.VLM-Dateien, die zu .EXE umbenannt und direkt, statt �ber VLM auf-
gerufen wurden, kehren sofort mit Fehlercode 6 zur�ck.
---------------------------------------------------------------------------
VI.10. Hinweise zur Universal Naming Convention (UNC): [96-03-26]
=================================================================
Stichworte: PNW, UNC, MAP, Capture
Die Universal Naming Convention gliedert die unterschiedlichsten Netz-
ressourcen in Form eines Verzeichnisbaums, bei der man am Anfang den
Server angibt, der die Ressource bereitstellt, und dann den Namen der
Ressource spezifiziert. Bei weiterer Unterteilung dieser Ressource
(bei Laufwerken etwa Unterverzeichnisse) ist auch die Angabe von
Pfaden m�glich.
Neben der �blichen Methode, entfernte Laufwerke �ber ihre Drive-Mappings
(MAP, NET MAP) anzusprechen, bietet die UNC also eine manchmal sinn-
vollere M�glichkeit, weil man die Ressource 'physikalisch' benennen kann
und nicht wie sonst �ber den Umweg einer 'relativen' Substitution.
Allerdings werden die Pfadangaben dadurch auch l�nger und manchmal ist
es gerade w�nschenswert, 'relative' Konfigurationen zu erstellen.
Laut Novell d�rfen die Pfade unter DR DOS 6.0 und Novell DOS 7 f�r
lokale Ressourcen bis zu 128 Zeichen lang sein, ansonsten gilt die
�bliche DOS-Beschr�nkung f�r maximale Pfadl�ngen von 67 Zeichen
(ausprobiert habe ich dies nicht).
Syntax: (SERVER ist der vergebene Name f�r die Netz-
ressource SERVER, und VOLUME der f�r ein Laufwerk,
d.h. nicht der Volume-Name, den man mit LABEL
einstellen kann.)
SERVER/VOLUME:DIR\ �ber MAP oder SUBST an ein logisches Laufwerk
gekoppelt. Statt des '/' kann auch '\' geschrieben
werden. Klappt immer!
SERVER\VOLUME:DIR\ direkte Angabe (klappt unter 4DOS und Novells
COMMAND.COM immer mit Laufwerken, offenbar aber
auch mit anderen Ressourcen wie Druckerports.
\\SERVER\VOLUME\DIR\ entsprechend UNC (klappt ebenfalls fast immer,
zumindest unter 4DOS und COMMAND.COM)
Beispiele: (PNWSRV1_DRV1 sei ein Netzlaufwerk)
DIR pnwsrv1_pc\pnwsrv1_drv1:\
DIR \\pnwsrv1_pc\pnwsrv1_drv1\
Wie angesprochen, kann statt des VOLUME bei UNC allgemein auch eine
andere Ressource genannt werden. DOS bietet hier vergleichsweise ein-
geschr�nkte M�glichkeiten, soweit diese Ressourcen aber auch unter DOS
quasi wie Dateinamen angegeben werden konnten (und k�nnen), sollte die
Angabe entsprechend UNC m�glich sein (Namen von Block-Devices werden bei
DOS bekanntlich fast wie Dateinamen behandelt).
Ist PNWPRN1_LPT1 eine Ressource, die einen Druckerport auf dem Server
PNWSRV1_PC darstellt, sollten also Angaben wie
DIR *.* > \\pnwsrv1_pc\pnwprn1_lpt1\
erlaubt sein, d.h. man k�nnte auf das Capturen des Ports auf dem lokalen
Rechner verzichten (allerdings funktionierte diese Methode bei meinen -
zugegeben bisher nur fl�chtigen - Tests mit einem separaten PNW-Netz
(VLMUP4) nicht. Es erschien die Fehlermeldung: Netzwerkfehler 071).
Ohne geladene Netzshell (NETX bzw. VLM) sind derartige Zugriffe ver-
st�ndlicherweise (prinzipiell) nicht zul�ssig.
Bez�glich Einschr�nkungen und �nderungen im Laufe der Versionsgeschichte
von COMMAND.COM und .VLM-Updates sei auch auf die HISTORY.TXT Datei aus
den Novell DOS 7 Updates verwiesen.
---------------------------------------------------------------------------
VI.11. PNW-Server und Sharing von Wechselmedien: [96-04-14]
===========================================================
Stichworte: Floppy-Sharing, CD-ROM-Sharing, Drucker-Sharing
Richtet man einen PC als PNW-Server ein, mu� man sich u.a. entscheiden,
welche Laufwerke man 'shareable' machen m�chte, d.h. anderen Client-
Rechnern zur Verf�gung stellen will.
Dabei sollte man - von Ausnahmen abgesehen - darauf achten, nur solche
Ressourcen zu teilen, die immer verf�gbar sind (oder es zumindest
bleiben, nachdem sich ein Benutzer eines Clients einloggen konnte).
Dazu z�hlen in erster Linie Festplatten, wo es nur selten Probleme gibt.
Kritisch ist das 'Teilen' von Floppies, da ein Client normalerweise
nicht sicherstellen kann, da� auf dem Server eine Diskette eingelegt ist.
Greift man trotz nicht eingelegter Diskette auf ein Floppy-Laufwerk zu,
so erscheint im g�nstigsten Fall nach kurzer Zeit eine Fehlermeldung auf
dem Client. Es ist aber auch m�glich, da� die DOS-Fehlermeldung "Abbruch,
Wiederholen, Ignorieren" auf dem Server erscheint, der vielleicht in
diesem Moment gar nicht besetzt ist oder wo jemand gerade eine wichtige
Berechnung in einer Applikation durchf�hrt...
Besonders unangenehm fallen hierbei die 5,25" Floppy-Laufwerke auf:
Aufgrund ihrer Mechanik ist es m�glich, eine Diskette zwar einzulegen,
die Laufwerksklappe aber nicht zu schlie�en. Die Mehrzahl der Laufwerke
(auch von Markenherstellern) k�nnen diese Situation nicht als "Keine
Diskette eingelegt" erkennen, sondern nur als "Diskette eingelegt,
Zugriff nicht m�glich". In diesem Fall ist mit extrem langen Wartezeiten
beim Zugriff auf ein solches Laufwerk zu rechnen, bis DOS oder die
Applikation es aufgibt, auf das Laufwerk zuzugreifen.
All dies w�re noch ertr�glich, wenn man sicherstellen k�nnte (und w�rde),
da� nur dann (bewu�t) auf ein Floppy-Laufwerk zugegriffen wird, wenn auch
ein Medium eingelegt ist. Leider ist dem nicht so: Sehr viele Programme
(z.B. viele Utilities der Norton Utilities oder der PC-Tools, aber auch
MS Windows und Netzanalyse-Programme) greifen beim Start auf jedes ver-
f�gbare Laufwerk zu, um den aktuellen Status einzuholen. Auf diese Weise
werden auch die entfernten Laufwerke 'durchgescannt'. Sind Floppy-
Laufwerke darunter, tritt das oben beschriebene Szenario in Kraft, und
zwar in den allermeisten F�llen, ohne da� man die M�glichkeit h�tte,
dies zu umgehen. Nur sehr wenige Programme (etwa PROSHELL) lassen es zu,
da� man in der Konfigurationsdatei angibt, ob und wenn welche Laufwerke
gescannt werden d�rfen.
�hnliche Situationen k�nnen sich auch mit CD-ROM-Laufwerken, Wechsel-
festplatten, bestimmten intelligenten Streamern oder zur Laufzeit in
der Gr��e verstellbaren RAM-Disks (wie etwa TDSK) ergeben. Teilweise
kann man per Software-Option (z.B. viele CD-ROM-Treiber) verhindern,
da� man das Medium wechseln kann. Auch Drucker (Papierstau, Papierende)
k�nnen von diesem Problem betroffen sein, in der Regel f�hrt dies aber
nicht zu langen H�ngern, sondern zu einer unmi�verst�ndlichen Meldung.
Au�erdem werden Drucker auch nur selten beim Start einer Applikation
initialisiert.
---------------------------------------------------------------------------
VI.12. NET.CFG Parameter: [97-02-13]
====================================
Stichworte: SERVER.EXE, VLM.EXE, VLMs, NET.EXE
Die folgende Auflistung beschreibt, welche NET.CFG Parameter von welchen
Netztreibern ausgewertet werden (und erhebt derzeit noch nicht den
Anspruch auf Vollst�ndigkeit, z.Z. werden hier lediglich die Gruppen
NETWARE DOS REQUESTER und DESKTOP SNMP behandelt).
Mit den VLM-Updates sind eine ganze Reihe neuer Parameter hinzugekommen
(besonders bei v1.10 und v1.21); es gibt aber auch noch etliche Para-
meter aus Zeiten lange vor dem VLM-Client, die heutzutage nicht mehr
ausgewertet werden und daher in dieser Auflistung auch nicht mehr
auftauchen. Teilweise durchsuchen die Programme (SERVER.EXE) die Datei
NET.CFG und wenn diese nicht auffindbar ist, die �ltere Datei SHELL.CFG
(aus IPX/NETX-Zeiten). Weitere Hinweise in NETCFG.TXT und SAMPLNET.CFG
aus den VLM-Kits und nat�rlich im DOSBOOK!
Die Auflistung geschieht hier - im Gegensatz zu anderen �bersichten -
anhand der jeweiligen Treiber, weil m.E. so ein besseres Verst�ndnis
f�r die Wirkung eines Treibers m�glich wird.
PNW-Server SERVER.EXE (getestet mit v1.23):
(sucht die Dateien C:\NWCLIENT\NET.CFG, C:\PNETWARE\NET.CFG,
NET.CFG, SHELL.CFG)
NETWARE DOS REQUESTER ;
ALTERNATE CALLDOS=on|<off> ; F�r Proze�umschalter
NETWARE SHARING MODE= ;
OS2=on|<off> ; F�r OS/2 Support
VLM.EXE (getestet mit v1.21):
NETWARE DOS REQUESTER ;
CONFIRM CRITICAL ERROR ACTION=<on>|off ; (erst ab v1.10+)
EXCLUDE VLM=<vlm> ; kann wiederholt werden
MESSAGE LEVEL=<1> ; 0..4
; 0 = V_LEVEL_STD always display message and critical errors
; 1 = V_LEVEL_WARNING display warning type messages
; 2 = V_LEVEL_PROG display the program load message
; 3 = V_LEVEL_CONFIG display configuration information
; 4 = V_LEVEL_DIAG display diagnostic information
NETWARE PROTOCOL=[NDS] [BIND] [PNW]; die nicht ben�tigten VLMs werden
; nicht geladen
; (nicht NETWARE PROTOCOLS= !!!)
SET STATION TIME=<on>|off ;
USE DEFAULTS=on|off ; lade Default-VLMs (erspart die meisten
; der VLM= Anweisungen)
VLM=<vlm> ; kann wiederholt werden
AUTO.VLM (setzt REDIR.VLM voraus) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
AUTO RECONNECT=<on>|off ;
AUTO RETRY=<0> ; 0..3640
AUTO LARGE TABLE=on|<off> ; Mit <off> ist die max. L�nge f�r Namen
; und Pa�w�rter auf 16 Zeichen beschr�nkt
BIND RECONNECT=on|<off> ;
CONNECTIONS=<8> ; 2..50
BIND.VLM (setzt TRAN.VLM voraus) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
BIND RECONNECT=on|<off> ;
;PREFERRED SERVER=<server name> (angeblich mit v1.10, nicht aber v1.21)
CONN.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
AVERAGE NAME LENGTH=<48> ; 2..48
CONNECTIONS=<8> ; 2..50
LOAD CONN TABLE LOW=on|<off> ;
LOAD LOW CONN=<on>|off ;
MAX TASKS=<31> ; 5..254
FIO.VLM (ben�tigt NWP.VLM) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
CACHE BUFFERS=<5> ; 0..64
CACHE BUFFER SIZE=<media dependent>; (nicht CACHE BUFFERS SIZE= !!!)
CACHE WRITES=<on>|off ;
CONNECTIONS=<8> ; 2..50
LOAD LOW FIO=on|<off> ; (erst ab v1.10+)
MAX IPG= ; <nichts>, 0..63, 257 (erst ab v1.20B+)
PB BUFFERS=<3> ; 0..10, 0=off, sonst=on
PBURST READ WINDOW SIZE=<16> ; 2..64
; (nicht PBURST READ WINDOWS SIZE= !!!)
PBURST WRITE WINDOW SIZE=<10> ; 2..64
; (nicht PBURST WRITE WINDOWS SIZE= !!!)
TRUE COMMIT=on|<off> ;
GENERAL.VLM (ben�tigt NWP.VLM) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
DOS NAME=<MSDOS> ; max. 5 Zeichen (vgl. Kapitel IV.7.)
FIRST NETWORK DRIVE=<1st avail>; A..Z
FORCE FIRST NETWORK DRIVE=on|<off>; (erst ab v1.10+)
LOCK DELAY=<1> ; 0..255 (vollst�ndig ab v1.20+)
LOCK RETRIES=<3> ; 0..255 (vollst�ndg ab v1.20+)
LONG MACHINE TYPE=<IBM_PC> ; max. 6 Zeichen
SEARCH MODE=<1> ; 0..7
SHORT MACHINE TYPE=<IBM> ; max. 4 Zeichen
IPXNCP.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
ALTERNATE SOCKETS= ; (erst ab v1.21+)
CHECKSUM=<1> ; 0..33
HANDLE NET ERRORS=<on>|off ;
LARGE INTERNET PACKETS=<on>|off
LIP START SIZE=<0> ; 0, 576..65536 (ab v1.20+)
LOAD LOW IPXNCP=<on>|off ;
MINIMUM TIME TO NET=<value> ; (erst ab v1.10+)
PB BUFFERS=<3> ; 0..10, 0=off, sonst=on
NDS.VLM (ben�tigt TRAN.VLM, RSA.VLM) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
; AUTO RECONNECT=<on>|off ; (angeblich bei v1.10, nicht be v1.21)
CONNECTIONS=<8> ; 2..50
NAME CONTEXT="<context>" ;
PREFERRED TREE=<tree> ;
NETX.VLM (ben�tigt REDIR.VLM, PRINT.VLM) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
DOS NAME=<MSDOS> ; max. 5 Zeichen (vgl. Kapitel IV.7.)
EOJ=<on>|off ; (erst ab v1.10+)
FIRST NETWORK DRIVE=<1st avail>; A..Z
LOAD LOW NETX=on|<off> ; (erst ab v1.10+)
;LOCK DELAY=<1> 0..255 (angeblich teilweise bei v1.10, voll-
;LOCK RETRIES=<3> 0..255 st�ndig bei v1.20, nicht bei 1.21)
LONG MACHINE TYPE=<IBM_PC> ; max. 6 Zeichen
SHORT MACHINE TYPE=<IBM> ; max. 4 Zeichen
NWP.VLM (ben�tigt BIND.VLM, PNW.VLM) (getestet mit v1.21):
NETWARE DOS REQUESTER ;
CHECKSUM=<1> ; 0..3
LARGE INTERNET PACKETS=off|<on>
;LIP START SIZE=<0> 0,576..65536 (angeblich bei v1.10, nicht bei 1.21)
MESSAGE TIMEOUT=<0> ; 0..10000
SIGNATURE LEVEL=<1> ; 0..3
PNW.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
BROADCAST RETRIES=<2> ; 0..255
BROADCAST SEND DELAY=<0> ; 0..255
BROADCAST TIMEOUT=<3> ; 1..255
PREFERRED WORKGROUP=<workgroup>; (offenbar statt des im DOSBOOK
; beschriebenen WORKGROUP NAME=)
RESPONDER=off|<on> ;
MOBILE MODE=<0> ; 0..65535
WORKGROUP NET= ;
PRINT.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
LOCAL PRINTERS=<3> ; 0..9
NETWORK PRINTERS=<3> ; 0..9 (0 l�dt PRINT.VLM nicht)
PRINT BUFFER SIZE=<64> ; 0..256
PRINT HEADER=<64> ; 0..1024
PRINT TAIL=<15> ; 0..1024
RESET PRINTER FLAGS= ; (erst ab v1.21+)
REDIR.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
EOJ=off|<on> ; (erst ab v1.10+)
FIRST NETWORK DRIVE=<1st avail>; A..Z (angeblich nicht mit v1.10...)
LOAD LOW REDIR=<off>|on ; (erst ab v1.10+)
READ ONLY COMPATIBILITY=<off>|on; (vor v1.10 war Default <on>)
SHOW DOTS=<off>|on ;
SECURITY.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
CONNECTIONS=<8> ; 2..50
SIGNATURE LEVEL=<1> ; 0..3
WSASN1.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
LOAD LOW WSASN1=off|on ; (nicht mit v1.00)
DESKTOP SNMP ;
ENABLE CONTROL COMMUNITY=off|any|specified|[ommitted]
ENABLE MONITOR COMMUNITY=off|any|specified|[ommitted]
MONITOR COMMUNITY="name|public|private"
CONTROL COMMUNITY="name|public|private"
WSREG.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
LOAD LOW WSREG=off|on ; (nicht mit v1.00)
WSSNMP.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
LOAD LOW WSSNMP=off|on ; (nicht mit v1.00)
DESKTOP SNMP ;
ASYNCHRONOUS TIMEOUT=<20> ;
SNMPENABLEAUTHENTRAPS=<off>|on
SYSCONTACT="<mail address>" ;
SYSLOCATION="<description system location>"
SYSNAME="<description system name>"
WSTRAP.VLM (getestet mit v1.21):
NETWARE DOS REQUESTER ;
LOAD LOW WSTRAP=off|on ;
DESKTOP SNMP ;
TRAP COMMUNITY="name|public|private"
ENABLE TRAP COMMUNITY=off|any|specified|[ommitted]; (auch 'any'!!!)
Die VLMs MIB2IF.VLM, MIB2PROT.VLM, NMR.VLM, PNWMIB.VLM, RSA.VLM,
TRAN.VLM, WSDRVPRN.VLM lesen selbst keine Konfigurationsparameter aus
der NET.CFG Datei (getestet mit v1.21). Der im DOSBOOK beschriebene
Parameter WORKGROUP NAME= innerhalb der NETWARE DOS REQUESTER Gruppe
wird von PNW.VLM offenbar nicht ausgewertet (und scheint durch den
sp�ter dokumentierten Parameter PREFERRED WORKGROUP= ersetzt worden
zu sein).
NET.EXE (getestet mit v1.05) (siehe Kapitel VI.9.):
NETWARE DOS REQUESTER
BROADCAST RETRIES=<2> ; 0..255
BROADCAST TIMEOUT=<3> ; 1..255
BROADCAST SEND DELAY=<0> ; 0..255
PREFERRED WORKGROUP=<workgroup name>; (offenbar statt WORKGROUP NAME=)
WORKGROUP NET=<workgroup net address>
###########################################################################
###########################################################################
VII. MULTITASKING UND PROZESSUMSCHALTUNG:
=========================================
---------------------------------------------------------------------------
VII.1. Fehlverhalten von TASKMGR mit �lteren Maustreibern: [97-01-13]
=====================================================================
(Bug behoben - getestet 01/1995)
Stichworte: TASKMGR, Multitasking, TASKMGR Men�, GMOUSE, MAUSALL,
Logitech-Maus, Updates, Microsoft Mouse
Der Task-Manager hatte im Multitasker-Modus Probleme mit verschiedenen
�lteren (und ganz neuen Microsoft) Maustreibern, insbesondere wenn
mehrere Applikationen gleichzeitig eine Maus verwenden oder wenn um-
programmierte Text-Fonts f�r VGA-Karten (Schlagwort: New User Interface,
Pseudo-Grafikmodus im Textmodus) verwendet werden.
M�gliche Symptome:
- die Maus wird in einer oder mehreren Applikationen 'abgeschossen'
- w�hrend des TASKMGR-Men�s erscheint kein eigener Maus-Cursor
- der Task-Manager schmiert w�hrend der Umschaltung zwischen den
Prozessen sogar ab, wenn man die Maus bewegt
- EMM386 meldet eine Schutzverletzung w�hrend der Programmumschaltung
zwischen Prozessen.
Ausgangslage f�r dieses Problem (mu� nicht repr�sentativ sein):
- In CONFIG.SYS: DEVICEHIGH=GMOUSE.SYS (V9.06/1991)
f�r Genius 3-Tasten-Maus (PC-/Mouse-Systems-Mouse-Mode)
- In AUTOEXEC.BAT hochgeladen: MAUSALL.COM
f�r Maussimulation �ber Cursor-Tasten f�r Nicht-Maus-Anwendungen
- TASKMGR mit und ohne /F Option.
Abhilfe:
Im vorliegenden Fall war der �ltere Maustreiber die Fehlerursache, der
allerdings ansonsten bisher keinerlei Probleme bereitete. Die Probleme
konnten jedoch auch mit anderen �lteren Maustreibern (Noname, Agiler-
Maus, Z-Mouse) reproduziert werden.
Nach verschiedenen Tests konnte der Fehler nur dadurch beseitigt werden,
da� kein Maustreiber installiert wurde.
Ein Logitech-Treiber (MouseWare 6.30+/1993) funktioniert jedoch
w�hrend der Umschaltung der Tasks einwandfrei (leider nicht im Mouse-
Systems-Mouse-Mode, also nur als 2-Tasten-Maus). Der verwendete Treiber
unterst�tzt u.a. die neue Software-Schnittstelle VESA-VCI (Video Cursor
Interface), daf�r aber keine CGA-Karten und macht zudem eine Reihe
anderer Probleme, u.a. auf Zwei-Monitor-Systemen mit der Umschaltung auf
den anderen Bildschirm, wenn zum Installationszeitpunkt die Monochrom-
Karte aktiv war, oder mit einem selbstdefinierten Maus-Cursor mancher
Anwendungen (z.B. st�rzt IOMegas QBACKUP 3.x bei mir immer ab); dies
ist aber f�r die Probleme nicht ausschlaggebend.
(Nebenbei: Um den Treiber auf Zweimonitor-Systemen zu benutzen, sollte
man vor derInstallation des Treibers (wenigstens tempor�r) auf die Farb-
Karte umschalten, z.B. mit INSTALL=c:\nwdos\mode.com CO80. Um dem Absturz
unter QBACKUP abzuhelfen, hilft es oft, solche Problemappikationen nur
unter einem anderen Maustreiber zu starten. In meinem Fall reichte es,
den Genius-Maustreiber GMOUSE 10.20 �ber den Logitech-Treiber zu laden
und nach der R�ckkehr zum Prompt mit /U wieder zu entladen.)
Falls nur im TASKMGR-Men� kein Maus-Cursor erscheint, reicht es, MAUSALL
wegzulassen.
Mittlerweile ist sowohl EMM386 als auch TASKMGR mehrfach aktualisiert
worden (Update 10+), die oben beschriebenen Probleme mit dem Genius-
Maustreiber sind mit der aktuellen Version komplett beseitigt worden
(jedenfalls bin ich wieder auf den in vielen anderen Belangen stabileren
Genius-Maustreiber 9.06 umgestiegen, wodurch z.B. MS Windows erheblich
stabiler arbeitet). Ein neuerer Maustreiber 10.20 (1993) ist mittlerweile
auf SimTel verf�gbar - leider auch nicht ganz unproblematisch - mehr dazu
in Kapitel VIII.2.
Novell weist in einem FaxBack-Infopaper aus ND7TID.EXE darauf hin, da�
es auch mit Microsoft Mousetreibern der Versionen 9.xx und 10.xx Probleme
gibt. Laut Novell funktionieren �ltere Microsoft-Maustreiber. Au�erdem
k�nnen Microsoft M�use auch mit den Maustreibern von Genius und vielen
anderen bedient werden.
---------------------------------------------------------------------------
VII.2. Undokumentierte Einstellungen f�r den TASKMGR: [97-02-26]
================================================================
Stichworte: TASKMGR, TASKMGR.INI, TCP/IP, VxD, MS Windows,
K3PLUS, FreeKEYB
Innerhalb des TASKMGR (und TASKMAX) Men�s haben neben den bekannten
Tasten noch die Tasten <F2> und <F4> besondere Bedeutung:
<F2> ist gleichwertig mit <Ins>
<F4> "" <Del>
Novells TASKMGR besteht im Prinzip aus zwei eigenst�ndigen Modulen
(f�r den Proze�umschalter und den Multitasker) und einem Lader, der
f�r beide Module gemeinsam gilt.
�brigens: Zumindest theoretisch kann TASKMGR mit INSTALL= etc. sogar
in CONFIG.SYS geladen werden, nachdem vorher der Speichermanager
EMM386.EXE und SHARE.EXE geladen wurden. In seltenen F�llen und bei
entsprechender Konfiguration mag diese Option sinnvoll sein, da alle
Programme/Treiber, die erst nach dem TASKMGR geladen werden, f�r den
jeweiligen Task lokal bleiben. Auf diese Weise sind nebeneinander
rudiment�re Tasks mit extrem viel Speicher und einem blank liegenden
Systemkern und andere mit viel Komfort m�glich. In der Praxis reicht es
dazu jedoch meist aus, den TASKMGR fr�h in AUTOEXEC.BAT zu laden, was
erheblich weniger Probleme bereitet und stabiles Arbeiten garantiert
(das Laden in CONFIG.SYS ist bisher von mir noch nicht genauer unter-
sucht worden). Besonders vorteilhaft ist die M�glichkeit, Treiber nur
in einem Task des Multitaskers zu laden, wenn Sie zwar Treiber f�r den
IPX-Stack, nicht aber die restliche Client- oder gar Server-Software
von Personal NetWare ben�tigen (etwa f�r FASTLYNX, das Punkt-zu-Punkt
Verbindungen auch �ber IPX aufbauen kann, siehe Kapitel II.8.)
Der TASKMGR wird sowohl in der Proze�umschalt- als auch in der Multi-
tasking-Version mit der Datei TASKMGR.INI (im Pfad %Path% oder im
Verzeichnis %NWDOSCFG%) konfiguriert. Wenn auch nicht im Handbuch oder
dem DOSBOOK, so sind wenigstens in dieser Datei alle wichtigen Parameter
erkl�rt (falls diese Erkl�rungen fehlen (DR DOS 6.0 VIEWMAX l�scht sie
zumindest in der verwandten Datei TASKMAX.INI), sollte man sich das
Original von den Installationsdisketten besorgen). Gro�- und Klein-
schreibung ist unerheblich (im Gegensatz zu VIEWMAX.INI). Es gibt hier
wirklich eine Menge Feintuning-M�glichkeiten, die besonders bei Problemen
nicht �bergangen werden sollten.
In der Gruppe [COLORS] sind normalerweise nur die Direktiven COLORSET0=
bis COLORSET7= vordefiniert. TASKMGR akzeptiert hier auch noch COLORSET8=
und COLORSET9=.
i. Multitasker:
---------------
Im Multitasking-Modus gibt es neben den dokumentierten Parametern noch
drei weitere Parameter in TASKMGR.INI:
Zwei davon befinden sich im Abschnitt
[KEYS]
# Die im Abschnitt [KEYS] verwendeten Zust�nde der Umschalttasten
# sind Dezimalwerte, die den Tasten UMSCHALT, STRG und ALT ent-
# sprechen. Deren numerische �quivalente sind: 1=UMSCHALT rechts,
# 2=UMSCHALT links, 4=STRG, 8=ALT. Der Tastenwert ist ein PC-
# Scancode. Der Standardwert von 1 ist die ESC-Taste.
# Bleibt zu erg�nzen:
# Es k�nnen mehrere Umschalttasten kombiniert werden. Soll z.B. der
# TASKMGR auf <Ctrl>+<Alt>+<Taste> reagieren, ersetzt man den Wert
# 4 (Default f�r <Ctrl>) durch 12. Hier ist jedoch <Ctrl>+<Alt>
# ungleich <AltGr>, wie dies sonst pauschal in Verbindung mit dem
# erweiterten deutschen Tastaturtreiber K3/K3PLUS/FreeKEYB gilt,
# d.h. <AltGr>+<Taste> aktiviert die gew�nschte Funktion nicht!
# Linke und rechte <Ctrl> bzw. <Alt> Taste werden nicht unter-
# schieden, daran �ndert auch Eintr�ge 'STANDARD' nichts, die sich
# nur auf die Taste, nicht aber auf den Umschaltstatus beziehen.
MAINNUMKEYS= # bezeichnet den PC-Scancode der Zifferntaste auf der
# Haupttastatur, analog zu den �brigen Eintr�gen 'KEYS'
NUMSTANDARD= # normalerweise bedeutet beim Eintrag 'STANDARD':
# 1=Tasten auf der Haupttastatur,
# 0=Tasten im erweiterten Tastaturbereich (Cursor-Block,
# NumPad), dies wird auch hier so sein,
# siehe Aufrufoption /M
und einer im Abschnitt
[DEBUG]
Level=0 # Weiteres ist unbekannt.
Im Multitasking-Modus wird in der Gruppe [MEMORY] nur LIMIT= ausgewertet,
die Gruppe [DISK] und die undokumentierte Gruppe [VIRTUAL] hingegen �ber-
haupt nicht.
Die Standardtastenkombination f�r das TASKMGR-Men� ist <Ctrl>+<Esc>. Will
man jedoch unter Windows gezielt das Men� des Windows' TaskMan und nicht
das des Novell TASKMGR w�hlen, mu� man das TASKMGR-Men� auf eine andere
Tastenkombination legen. Da unter der graphischen Oberfl�che GEOWORKS
[PRO] ENSEMBLE nur die Tastenkombination <Shift>+<Esc> (laut einer Quelle
bei Digital Research nur <Ctrl>+<Esc>???) f�r den TASKMGR verwendet
werden kann (alle anderen Tasten werden abgefangen), sollte man z.B.
auch f�r MS Windows diese Tastenkombination w�hlen.
Novell empfiehlt, Oberfl�chen, die im Hinblick auf DR DOS TASKMAX ge-
schrieben wurden (z.B. GEOWORKS ENSEMBLE 2.xx oder DR DOS 6.0 VIEWMAX),
nur unter dem TASKMGR als Proze�umschalter zu starten, oder - unter dem
Multitasker - die TASKMAX-Task-Steuer-Funktionen der Oberfl�che abzu-
schalten. Eigene Versuche haben ergeben, da� es durchaus m�glich ist,
auch den Multitasker zu verwenden (siehe NWDOS7UN.TXT), dies aber nicht
immer sicher funktioniert und au�erdem die �bersicht �ber die laufenden
Tasks zwischen der Oberfl�che und dem TASKMGR+Men� nicht unbedingt
synchronisiert wird (in Wahrheit unterst�tzt der neue TASKMGR im
Proze�umschaltmodus und Multitasking-Modus nahezu alle API-Funktionen
des alten TASKMAX, abgesehen von Copy/Paste). In einem amerikanischen
Buch habe ich �brigens die Behauptung gefunden, da� TASKMGR als Proze�-
Umschalter Copy/Paste unterst�tzt (auf dem TASKMGR-Men� nicht abge-
bildet). Ich kann das leider nicht best�tigen, da zumindest in der
deutschen Ausgabe auch die interne Unterst�tzung daf�r entfernt wurde.
Wenn TCP/IP-Anwendungen 'gefahren' werden oder mehrere Tasks parallel auf
das Netz zugreifen wollen, kann es notwendig sein, im Abschnitt [DRIVERS]
weitere Eintr�ge der Form 'GLOBALPAGES=2' einzubauen.
Au�erdem existiert im Abschnitt [Drivers] ein Eintrag f�r virtuelle
Ger�tetreiber (hier vIPX) in der Form 'VXD=laufwerk:pfad\vipx.386',
der meist auf das \WINDOWS\SYSTEM\ Verzeichnis verweist, in das die
Datei VIPX.386 w�hrend der Installation kopiert wird. Da diese Datei
auch im C:\NWDOS\ Verzeichnis vorkommt (oder notfalls dorthin kopiert
werden kann), sollte die dortige Datei verwendet werden, indem man den
Eintrag wie folgt �ndert:
VXD=c:\nwdos\vipx.386
Wenn das Netzwerk geladen ist und man den TASKMGR im Multitasking-Modus
startet, sollte der Treiber 'OK' melden, sonst ist etwas schief gelaufen.
Ohne geladenes Netzwerk wird der Treiber vIPX nicht 'OK' melden, was aber
dann auch nicht st�rt.
Der TASKMGR bildet in vielerlei Punkten die Mechanismen von MS Windows
nach. Das hat den Vorteil, da� z.B. evtl. notwendige virtuelle Ger�te-
treiber f�r Windows (VxD) auch f�r den TASKMGR verwendet werden k�nnen!
Leider funktioniert dies nicht mit allen MS Windows .386-Treibern. Wenn
der Treiber problemlos initialisiert worden ist, meldet TASKMGR dies mit
'OK' beim Start. Ansonsten wird nur der Name des Treibers angegeben. Mehr
oder weniger interessehalber habe ich eine ganze Reihe VxD-Treiber der
unterschiedlichsten Software-Pakete getestet. Bei den folgenden Treibern
meldet TASKMGR sogar 'OK': MS-DOS/MS Windows MONOUMB.386, Novells
FASTBACK.386, Logitech MouseWare 6.30 LVMD.386, Borlands WINDPMI.386,
Microsofts 32Bit-Erweiterung W32S.386). Durch diese M�glichkeit ver-
ringert sich nat�rlich der Entwicklungsaufwand und bei Problemen bestehen
gro�e Chancen, da� ein Treiber f�r Windows ein gleichartige Aufgabe auch
beim TASKMGR erf�llt.
Die eingebundenen Treiber sind jedenfalls aktiv, wie Versuche mit dem
virtuellen Maustreiber LVMD.386 zeigen. Nat�rlich macht das Ganze nicht
immer Sinn: W32S.386 kann zwar v�llig ohne Windows unter dem TASKMGR
geladen werden, eine Verwendungsm�glichkeit daf�r ist mir allerdings
noch nicht eingefallen... ;-)
Ein anderer Punkt ist, da� der TASKMGR auch die Start-/Exit-Broadcasts
von Windows nachbildet. Dies kann allerdings auch manche Anwendungen
leicht verwirren:
Dies gilt z.B. f�r K3PLUS/FreeKEYB in der derzeitigen Implementation.
Der Bildschirmschoner wird nur f�r die Dauer der TASKMGR-Session
abgeschaltet, so da� er innerhalb eines Tasks mit K3_ENZZ wieder
aktiviert werden mu�. Dies kann man bei Verwendung von Exec=True und
4DOS auch innerhalb der 4START.BAT Datei erledigen, wobei man eine
Sonderbehandlung f�r MS Windows einbauen mu�, damit dies dort nicht
geschieht.
Kann TASKMGR das Windows-Verzeichnis nicht ermitteln, sollten Sie die
undokumentierte Umgebungsvariable %TaskMgrWinDir% mit dem Pfad zur
SYSTEM.INI Datei angeben; siehe Kapitel IV.7.
Obwohl der Multitasker normalerweise ung�ltige Parameter beim Start
zur�ckweist, trifft dies f�r den Parameter /F (eigentlich nur f�r den
Proze�umschalter) nicht zu. Ob dieses Verhalten aber mehr als nur ein
Dummy zur Wahrung der Aufrufkompatibilit�t mit dem Proze�umschalter
ist, ist noch nicht gekl�rt.
Der Multitasker kann auch DPMI- oder VPCI-nutzende Applikationen
ausf�hren, allerdings werden Hintergrund-Tasks, die VCPI nutzen, wie
beim Taskswitcher ausgesetzt, bis sie wieder in den Vordergrund geholt
werden. Dies ist notwendig, da das VCPI-Protokoll per se keine Unter-
st�tzung f�r Multitasker erlaubt. Da auch MS Windows 3.0 bzw.
MS Windows 3.1x im Standardmodus (WIN /S) VCPI-Applikationen sind,
wird auch MS Windows als Hintergrund-Task unter dem TASKMGR ausgesetzt.
ii. Proze�umschalter:
---------------------
Im Proze�umschalt-Modus des TASKMGR werden eine ganze Reihe der im
Multitasking-Modus verwendeten Einstellungen nicht ben�tigt, im Einzelnen
sind dies die kompletten Gruppen [DRIVERS], [SLICE], [COM1] - [COM4],
[LPT1] - [LPT3], [MOUSE], [NETWORK], [SHELL], [WINFUNC], [POPUP] und
[DEBUG]. In der Gruppe [KEYS] werden MENUSTANDARD=, NEXTSTANDARD=,
PREVSTANDARD= und die undokumentierte Direktive NUMSTANDARD= nicht
ausgewertet. [KEYS] MAINNUMKEYS= wird wie im Multitasking-Modus unter-
st�tzt. In der Gruppe [MEMORY] wird alles au�er LIMIT= ausgewertet und
die Gruppe [DISK] mit der einzigen Einstellung SWAPDIR= wird sowieso
nur vom Proze�umschalter ben�tigt. Wird hier nichts angegeben, m�chte
TASKMGR die Auslagerungsdatei TASKMGR.SWP in C:\NWDOS\TMP anlegen.
Au�erdem existiert in der Gruppe [MEMORY] noch eine undokumentierte
Direktive
[MEMORY]
MINIMUM= # f�r die minimale Gr��e des Auslagerungsspeichers
und eine komplett undokumentierte Gruppe [VIRTUAL] mit den Direktiven:
[VIRTUAL] # Die Bedeutung im Einzelnen ist noch unklar:
DEVICE= # Da TASKMGR normalerweise nicht in CONFIG.SYS geladen
INSTALL= # wird, scheidet die Angabe von Treibernamen, die
TSR= # geladen werden m�ssen, eigentlich aus. Vermutlich
# handelt es sich hier um Schalter (TRUE/FALSE), die
TASK= # bestimmen, ob entsprechende Ressourcen virtualisiert
VIDEO= # werden oder nicht. Dies w�rde ungef�hr mit den
# speziellen Ger�tetreibereinstellungen des Multi-
# taskers einher gehen.
# Eine andere M�glichkeit w�re ein Analogon zu Windows
# [386Enh] LocalTSR= und Local= zum Instancing.
# VIDEO= k�nnte auch eine Default-Angabe des Parameters
# /V sein.
Im Proze�umschaltmodus gibt es eine ganze Reihe undokumentierter Aufruf-
parameter f�r TASKMGR (nur w�hrend der Initialisierung des Proze�um-
schalters). Die Funktionen sind noch nicht im Einzelnen gekl�rt, hier
aber schon mal ein paar Eigenschaften:
/Z Dient offenbar dazu, nur einen Dummy-TASKMGR zu laden.
Jedenfalls ist kein weiterer Task mehr startbar und die
Task-Liste enth�lt null (=Zero) Tasks (das Umbenennen des
ersten Tasks mittels /N wird allerdings nicht zur�ckge-
wiesen). Bei Druck auf den Aktivierungs-Hotkey des TASKMGR
ert�nt nur ein Piepser; es erscheint kein Men�. Auch unter
VIEWMAX (von DR DOS 6.0) sind in der Task-Liste keine Tasks
zu sehen (normalerweise wird wenigstens der Root-Task
angezeigt).
/U Unbekannt (User???)
/B Unbekannt. Ohne diese Option wird der Bildschirm normaler-
weise beim Start des TASKMGR f�r einen Augenblick dunkel,
mit /B wird dies unterdr�ckt. K�nnte daher etwas mit der
Hardware-Erkennung zu tun haben (aber sicher nicht f�r
B&W-Darstellung).
/T[=value] oder /T[:value]
Unbekannt, hat aber definitiv nichts mit der Task-Anzahl zu
tun. Da beliebige dezimale Werte akzeptiert werden, k�nnte
dies etwas mit einem Timeout zu tun haben. Allerdings konnte
ich bisher noch keinen Unterschied in den Umschaltzeiten beim
Starten neuer Tasks erkennen. Allerdings liefen nach Angabe
dieser Option Tasks nicht reproduzierbar sehr viel langsamer.
(Auch COMMAND.COM besitzt einen undokumentierten Parameter
/T, und unter Multiuser DOS gibt es eine EXIT /T Option.
Vielleicht haben beide etwas miteinander zu tun?)
Der folgende Parameter steht nur *nach* der bereits erfolgten
Installation des Proze�umschalters zur Verf�gung:
/R[=devicename] <Default-Wert ist CON>
Angabe eines logischen Ger�tes, an das die Standardein-
und -ausgabe (des Tasks???) gekoppelt werden (wird f�r
Remote-Zwecke benutzt). Gibt man nichts an, wird CON, die
Konsole gew�hlt und man kann Eingaben vornehmen (die man
auch sofort sieht). Die Eingabe von CON kann man bekanntlich
mit <Ctrl>+<z> abbrechen.
Der residente Teil des Novell DOS 7 TASKMGR als Proze�umschalter ist
weitestgehend identisch mit dem von DR DOS 6.0 bekannten TASKMAX (der
allerdings noch Copy & Paste Funktionen bot). Es werden auch alle hier
beschriebenen dokumentierten und undokumentierten TASKMGR.INI Direktiven
vom �lteren TASKMAX in TASKMAX.INI unterst�tzt.
TASKMAX unterst�tzte auch alle der hier beschriebenen Aufrufparameter
(logischerweise au�er /S), zus�tzlich aber (nach oder w�hrend der
Installation???) noch die undokumentierten Parameter /P (unbekannt,
vielleicht in Verbindung mit 'Paste' oder 'Permanent') und /M (f�r
'Main-Keyboard' statt Ziffernblock). Au�erdem existierte in TASKMAX.INI
noch eine Gruppe [COPY+PASTE] mit den Eintr�gen PASTESPEED=, NUMERIC=,
TEXT= und ENTER= (N�heres hierzu in DRDOS6UN.TXT).
Diese Einstellungen werden vom TASKMGR mangels Copy & Paste Funktionen
leider nicht mehr unterst�tzt (auch nicht auf API-Ebene). Leider ist es
mir bisher noch nicht gelungen, TASKMAX unter Novell DOS 7 zu starten,
obwohl dies evtl. nach ein paar Patches m�glich ist.
Offenbar bietet der TASKMGR im Proze�umschaltmodus (und TASKMAX) eine
M�glichkeit �ber Port 3F8h (normalerweise COM1:) gesteuert zu werden oder
dort Statusinformationen abzuliefern. Laut einer Quelle unterst�tzt der
TASKMGR zumindest als Proze�umschalter auch DR Multiuser DOS. Bisher
konnte dies nicht �berpr�ft werden. N�heres ist nicht bekannt.
---------------------------------------------------------------------------
VII.3. Novell DOS TASKMGR und 4DOS kombinieren: [96-12-03]
==========================================================
Stichworte: TASKMGR, 4DOS, NDOS, Updates, Kommandoprozessor, 4DOS.INI,
TASKMGR.INI, Exec=TRUE/FALSE, TASKMGR /C
Zuerst ein genereller Hinweis: Diese Beschreibung bezieht sich auf
TASKMGR 2.02+, Novell DOS 7 Update 15+ und 4DOS 5.5c/5.52a (mit Ab-
strichen 5.51). Sie sollten immer diese oder aktuellere Versionen
verwenden, da es mit �lteren Versionen verschiedene Probleme gab.
Achtung: 4DOS 5.51 (nicht 4DOS 5.5a/b/c und 4DOS 5.52a) brachte auf
meinen Testsystemen eher eine Verschlimmbesserung der Situation, zu-
mindest MEMMAX +V f�hrte auf mehreren Rechnern zum Totalabsturz mit
Verlust des CMOS-RAM-Inhalts.
Abhilfe war allerdings dadurch m�glich, da� man MEMMAX nur indirekt
�ber einen Batchjob/Alias aufruft, der vorher COMMAND.COM nachl�dt
(klappt nicht immer, siehe 4DOSTIP.TXT), z.B.:
MEMMAX.BAT:
COMMAND /C c:\nwdos\memmax.com %1 %2 %3 %4 %5 %6 %7 %8 %9
Nun jedoch die generellen L�sungsm�glichkeiten:
Es gibt verschiedene M�glichkeiten Novell DOS und 4DOS (JP Software)
bzw. NDOS (von den Norton Utilities) zu kombinieren.
Solange dabei weder die Netzkomponente Personal NetWare noch der
TASKMGR ins Spiel kommen, ist die Konfiguration denkbar einfach und
kann der Dokumentation zu 4DOS entnommen werden.
Es gibt zwei generelle Methoden der Kombination:
- 4DOS ersetzt COMMAND.COM komplett:
Diese Methode wird von JP Software empfohlen, da sie u.a. weniger
Speicher beansprucht und sehr einfach dadurch zu bewerkstelligen ist,
da� man die CONFIG.SYS-Zeile
SHELL=...\command.com /E:xxxx /P
durch
SHELL=...\4dos.com @...\4dos.ini /E:xxxx /P
ersetzt.
Diese Methode hat allerdings den Nachteil, da� alle erweiterten
Features des Kommandoprozessors COMMAND.COM von Novell DOS nicht
verf�gbar sind (damit nat�rlich auch nicht die erweiterten internen
Befehle und die zus�tzlichen Umgebungsvariablen). Au�erdem be-
handelt 4DOS (getestet bis 5.52a) nicht alle internen Datenstrukturen
von Novell DOS genauso wie COMMAND.COM das tun w�rde, was zu einigen
(normalerweise aber unkritischen) Unstimmigkeiten in den internen
Tabellen f�hren kann (siehe z.B. Kapitel III.6. und III.1. sowie
in 4DOSTIP.TXT). Bis diese Probleme bei 4DOS gel�st wurden, empfehle
ich das kurzzeitige Dummy-Laden von COMMAND.COM zu Beginn der Ab-
arbeitung der AUTOEXEC.BAT:
@c:\nwdos\command.com /c EXIT> \dev\nul
Dieser Befehl hinterl��t einige bleibende Auswirkungen in den internen
Strukturen, die durch diese Ma�nahme besser an DR DOS/Novell DOS ange-
pa�t sein sollten.
- 4DOS erg�nzt COMMAND.COM:
Diese Methode l�dt im Prinzip zwei Kommandoprozessoren, die beide
permanent bleiben. Der Nachteil ist, da� f�r den zus�tzlichen
COMMAND.COM ca. 3 KByte mehr Basisspeicher n�tig sind. Daf�r ergeben
sich aber einige Vorteile:
Alle COMMAND.COM Features bleiben erhalten (wenn sie auch durch 4DOS
verdeckt werden und zum Teil erst �ber ALIAS etc. zug�nglich gemacht
werden m�ssen). Alle Variablen (nicht aber Pseudovariablen) von
COMMAND.COM sind verf�gbar. Um Speicher zu sparen, sollte man den
COMMAMD.COM spezifizierenden SHELL= Eintrag in CONFIG.SYS so ver�ndern,
da� /E:129 nur noch den Minimalwert angibt.
Multi-Konfigurationen sind einfacher zu realisieren, da sich an den
Einstellungen der CONFIG.SYS nichts �ndert (in CONFIG.SYS m��te man
bei Mehrfachkonfigurationen nur eine Variable SET CONFIG=xxx setzen
(mit xxx=cfg_std oder cfg_4dos) und diese dann in einzelnen Bl�cken
der AUTOEXEC.BAT abfragen). Au�erdem erlaubt diese Methode auch mit
Updates vor 15 das <F8>-Tracen der AUTOEXEC.BAT Datei; mit neueren
Updates funktioniert dies nun auch mit Fremdkommandoprozessoren.
4DOS wird erst in der AUTOEXEC.BAT nachgeladen. Von JP Software wird
hier eine spezielle Methode empfohlen, die folgende Behandlung ist
meines Erachtens aber sinnvoller:
@ECHO off
REM Anfang der AUTOEXEC.BAT:
REM -- Abfangen von Endlosschleife beim Laden von 4DOS ----------------
IF "%@Eval[2 + 2]%"=="4" GOTO _4dos_done
IF NOT "cfg_4dos"=="%config%" GOTO _4dos_done
LH c:\sys\4dos\4dos.com c:\sys\4dos @c:\sys\4dos\4dos.ini /E:2048 /P
:_4dos_done
REM Rest der AUTOEXEC.BAT: --------------------------------------------
...
Nat�rlich k�nnen Sie auch die erste Methode anwenden und manuell die
fehlenden Umgebungsvariablen setzen. Ob bei Verwendung von ALIAS
mit nachgeladenem COMMAND.COM allerdings auch die Pseudo-Umgebungs-
variablen f�r NetWare funktionieren, wurde nicht �berpr�ft (allerdings
klappt das auch nicht, wenn 4DOS �ber COMMAND.COM geladen wird - nur
hat man hier evtl. etwas weniger Schwierigkeiten).
In der Datei 4DOS.INI sollten - unabh�ngig von der oben gew�hlten
Methode - einige spezielle Einstellungen gemacht werden, um optimal
mit Novell DOS zusammenzuarbeiten (nur diese Einstellungen werden hier
aufgelistet). Einige dieser Einstellungen weichen von Empfehlungen der
Software-H�user ab, arbeiten jedoch nach eigenen Erfahrungen besser:
[Primary]
; Basic Directives: ---------------------------------------------------
Environment = 1024 ; Beispielwerte
EnvFree = 512
Swapping = XMS, EMS, c:\tmp, None
4StartPath = c:\sys\4dos
LocalAliases = Yes
LocalHistory = Yes
LocalDirHistory = Yes
UMBAlias = Yes
UMBDirHistory = Yes
UMBHistory = Yes
UMBEnvironment = Yes
UMBLoad = No/Yes
; Yes klappt leider nur in einer speziellen Kombi-
; nation: TASKMGR im Multitasking-Modus mit der
; Einstellung EXEC=TRUE in TASKMGR.INI.
; N�heres siehe nachfolgende Erkl�rungen!!!
; Configuration Directives --------------------------------------------
BatchEcho = Yes
UpperCase = Yes
; Key Mapping Directives ----------------------------------------------
BackSpace = Ctrl-H ; mit diesen Einstellungen wird w�hrend der
BeginLine = Ctrl-Q ; Eingaben am 4DOS-Prompt die WordStar-
Del = Ctrl-G ; Belegung der Tastatur unter Novells
DelToBeginning = Ctrl-B ; COMMAND.COM nachgebildet.
DelToEnd = Ctrl-K ; Die folgenden Sonderfunktionen k�nnen
DelWordRight = Ctrl-T ; dabei nicht ber�cksichtigt werden:
Down = Ctrl-X ; Suchmodi mit <Ctrl>+<r> und <Ctrl>+<_>;
EndLine = Ctrl-W ; sowie erweiterte Belegung der Funktions-
EraseLine = Ctrl-Y ; tasten
ExecLine = Ctrl-M
Ins = Ctrl-V
Left = Ctrl-S
Right = Ctrl-D
Up = Ctrl-E
WordLeft = Ctrl-A
WordRight = Ctrl-F
; Advanced and Test Directives ----------------------------------------
FullInt2E = Yes ; f�r volle Unterst�tzung der undokumentierten
; Schnittstelle; besonders sinnvoll in Ver-
; bindung mit Novells TASKMGR (ist aber nicht
; unbedingt erforderlich)
UniqueSwapName = Yes ; f�r Multitasker (MS Windows, TASKMGR) und
; Multiuser-Umgebungen (Netzwerke)
SwapReOpen = Yes ; f�r Novell-Netze
SDFlush = No ; instruiert SMARTDRV (bzw. NWCACHE), seine
; Cache-Puffer vor der R�ckkehr zum Prompt
; nicht auszuschreiben. Das Resultat h�ngt
; davon ab, ob SMARTDRV (bzw. NWCACHE) darauf
; auch reagiert...
; In Verbindung mit NWCACHE /FLUSH=ON sollte
; man hier SDFlush=Yes einstellen, was sich
; aber negativ auf die Performance auswirkt.
DRSets = Yes ; Spezialparameter f�r DR DOS CONFIG.SYS SET=
; Befehl (ist nicht unbedingt erforderlich)
NetWareNames = Yes ; Spezialparameter f�r Novell-Netze
Sollen auch noch der TASKMGR und/oder PNW verwendet werden, sind noch
einige weitere Dinge zu beachten (die meisten Einstellungen der 4DOS.INI
sind schon f�r diese Zusammenarbeit gew�hlt).
JP Software und Novell geben verschiedene Hinweise bez�glich Einstel-
lungen der TASKMGR.INI Konfigurationsdatei. Eigene Erfahrungen m�nden
jedoch in der Erkenntnis, da� es derzeit nur 5 Kombinationen gibt, in
der 4DOS mit dem TASKMGR in seinen unterschiedlichen Betriebsarten
zurechtkommt, leider nur zwei, in den beide Modi des TASKMGR ohne
Umkonfiguration stabil arbeiten (nat�rlich mu� f�r den Multitasking-
Betrieb zus�tzlich die Voraussetzung via EMM386 /MULTI=on geschaffen
worden sein) und nur eine, die als wirklich stabil angesehen werden kann:
Eine �bersicht �ber die 5 Kombinationsm�glichkeiten:
TASKMGR.INI: 4DOS.INI: TASKMGR Multitasker Proze�umschalter
[Shell] [Primary]
1. Exec=True UMBLoad=Yes Ja (Nein) Ja mit Update 15
2. Exec=True UMBLoad=No Ja Ja
3. Exec=False UMBLoad=No Ja Ja
Jede dieser M�glichkeiten hat verschiedene Vor- und Nachteile:
Bei (1) m�ssen Sie darauf achten, da� der TASKMGR nur im Multitasking-
Modus startet (d.h. /MULTI=on bei EMM386 und genug freier Speicher und
noch kein anderer Multitasker - wie MS Windows - gestartet), ansonsten
wird Ihr Rechner abst�rzen (nach meinen Tests zumindest bis zur ersten
Version von Update 15).
Diese Kombination hat den Vorteil, da� man mit UMBLoad=Yes ca. 3 KByte
DOS-Speicher einsparen kann, aber wegen Exec=True Probleme mit auto-
matisch gestarteten Batchjobs bekommt (siehe unten) (und au�erdem den
gewonnenen Speicher wieder verliert). Diese Kombination kann als wirk-
lich stabil angesehen werden.
Mit Update 15 hat sich das Verhalten stark stabilisiert, ich habe jetzt
quasi keine Probleme mehr mit dem Multitasker und dem Proze�umschalter
unter 4DOS 5.5c und 4DOS 5.52 (mit Einschr�nkungen 4DOS 5.51). Beim
Proze�umschalter sollten neue Tasks allerdings nach wie vor nur �ber
TASKMGR /c %ComSpec% gestartet werden und nicht �ber <Ins>, JP Software
gibt dies nur f�r Exec=FALSE an.
Bei (2) und (3) brauchen Sie nicht darauf achten, in welchem Modus der
TASKMGR startet, aber mit UBMLoad=No haben Sie ca. 3 KByte weniger Basis-
speicher zur Verf�gung. Ob Sie dann Exec=True oder Exec=False w�hlen,
h�ngt von den Randbedingungen ab; solange nichts anderes gefordert ist,
sollten Sie Exec=False verwenden. Diese Kombinationen arbeiten mit
4DOS 5.5b ziemlich stabil, wenn man das System aber total ausreizt
und 'absichtlich an die Grenzen der M�glichkeiten des TASKMGR geht',
kommt es hier ab und zu zu reproduzierbaren Abst�rzen mit Speicher-
schutzfehlern, die aber leider nicht genauer zugeordnet werden k�nnen.
Die Variable %ComSpec% sollte auf 4DOS.COM weisen, wenn mit 4DOS ge-
arbeitet wird (aber nat�rlich nur dann, siehe andere Tips).
Zus�tzlich sind auch andere Empfehlungen f�r TASKMGR.INI und PNWLOGIN.SCR
(aus *diesem* Dokument) zu beachten.
Sofern man eine EGA-/VGA-Karte besitzt, ist es generell besser, TASKMGR
mit der Option /F zu starten (da dadurch Zeichens�tze f�r jeden Proze�
einzeln gesichert werden).
Beim Laden einzelner Prozesse des bereits aktiven TASKMGR (Proze�um-
schalter und Multitasker) wird empfohlen, diese nur �ber die Kommando-
zeile zu starten (dies scheint mittlerweile nicht mehr notwendig zu sein,
erst recht nicht mit Exec=True, ich starte mit Update 15 jedenfalls die
Tasks �blicherweise �ber das TASKMGR Men�):
TASKMGR /c %ComSpec%
Das Beenden geschieht dann �ber den DOS-Befehl EXIT (dies gilt auch f�r
die Direktive Exec=TRUE in TASKMGR.INI). EXIT klappt allerdings nicht,
wenn Exec=FALSE gesetzt ist.
Leider ergeben sich durch Exec=TRUE einige Schwierigkeiten, wenn man
TASKMGR aus einem Batchjob (AUTOEXEC.BAT) heraus mit diversen Hinter-
grundprozessen starten m�chte. Mit 4DOS lassen sich diese Probleme �ber
Tricks mittels automatischer Batchjobs 4START.BAT l�sen.
Leider scheint es derzeit keine M�glichkeit zu geben, TASKMGR direkt
dazu �berreden zu k�nnen, seinen Root-Proze� weiter zu bearbeiten (der
aufrufende Job wird erst mit Beenden des TASKMGR weiterbearbeitet).
Dadurch ist es mit Exec=TRUE z.Z. nicht m�glich, schon aus AUTOEXEC.BAT
heraus ein paar Hintergrund-Tasks f�r Serviceaufgaben zu starten
(Viren-Scanner, etc.) - ich habe bereits etliche erfolglose Versuche
unternommen :-(. Dies bezieht sich aber nur auf die Startphase von
TASKMGR, zus�tzliche Prozesse k�nnen sehr wohl aus einem Batchjob heraus
gestartet werden, nach wenigen Sekunden (Ladephase der Prozesse) schaltet
der TASKMGR jeweils wieder auf den alten Vordergrundtask um.
Ganz generell sollte man �brigens darauf achten, da� der Wechsel des
Vordergrundprozesses nicht in einem Moment vorkommt, wo ein anderer
Proze� geladen wird. Zumindest auf meinem System kommt es in solchen
F�llen immer wieder zu EMM386 Seitenausnahmefehlern im neu gestarteten
Task, sowohl mit COMMAND.COM als auch mit 4DOS.COM (Exec=True).
Normalerweise wartet der TASKMGR einige Sekunden mit der Umschaltung
zum aufrufenden Task, in Einzelf�llen kann aber diese Phase zu kurz
sein. Dann sollte man manuell eingreifen und *w�hrend* des Ladens des
neuen Prozesses das TASKMGR-Men� aktivieren und explizit auf den neuen
Task zur�ckschalten. Besonders kritisch scheinen Programme zu sein, die
XMS oder DPMI benutzen.
Es ist also noch keine generelle Entwarnung f�r das Problem der Kombi-
nation von 4DOS mit Novell DOS' TASKMGR gegeben.
Bei Beachtung der obigen Hinweise kann man jedoch NWDOS und 4DOS zu
stabil laufenden Multitasking-Systemen kombinieren. Sollte jemand andere
Erfahrungen gemacht haben, w�re ich f�r entsprechende Hinweise dankbar.
---------------------------------------------------------------------------
VII.4. TASKMGR Multitasker in Verbindung mit 4DOS aus Batchjobs aktivieren:
==============================================================[96-04-20]===
Stichworte: TASKMGR, 4DOS, Batchjobs, Background-Tasks, TASKMGR.INI,
Resynchronisation, Exec=TRUE, 4START.BAT, AUTOEXEC.BAT,
Viren-Scanner, AUTOEXEC.BAT, 4START.BAT
Im vorausgehenden Abschnitt wurden schon einige detaillierte Hinweise
f�r das stabile Zusammenspiel des TASKMGR mit 4DOS gegeben.
Dabei wurde auch angesprochen, da� mit der teilweise notwendigen
Direktive Exec=TRUE in der Datei TASKMGR.INI auch eine komfortable
M�glichkeit flachf�llt, z.B. direkt beim Booten des Rechners ein paar
Hintergrundtasks f�r Serviceaufgaben anzuwerfen, die etwa die Platte nach
Viren durchsuchen, Verzeichnisse �berpr�fen und reorganisieren (geht mit
Einschr�nkungen auch unter einem Multitasker) und und und...
Das Problem entsteht dadurch, da� der TASKMGR - aus einem Batchjob wie
AUTOEXEC.BAT gestartet - normalerweise nach wenigen Sekunden, die er dem
neuen Task f�r seine Initialisierung einr�umt, auf den alten Task zur�ck-
schaltet und z.B. den Batchjob fortsetzt - nicht so mit Exec=TRUE.
Auf der Kommandoebene von Novell DOS scheint es keine M�glichkeiten zu
geben, dieses Problem zu umgehen (Manipulationen der Variable %ComSpec%
f�hren wohl nicht zum Erfolg, evtl. w�rde es �ber simulierte Tastatur-
eingaben z.B. mit KEYSTACK/KSTACK oder K3PLUS/FreeKEYB funktionieren,
aber unter einem Multitasker, der sich gerade in der Umschaltphase
zwischen Tasks befindet, ist auch das auch nicht unbedingt sicher).
4DOS bietet jedoch eine M�glichkeit der Abhilfe in Form von optionalen
4START.BAT-Jobs, die beim Starten von 4DOS.COM (als prim�re oder
sekund�re Shell) noch vor AUTOEXEC.BAT und dem Erscheinen des Prompt-
zeichens abgearbeitet werden.
Eine einzelne 4START.BAT Datei ist allerdings viel zu unflexibel f�r
solche Aufgaben. Mit ein paar Tricks l��t sich aber ein Workaround
realisieren, das der fortgeschrittene 4DOS-Anwender leicht an seine
Bed�rfnisse anpassen kann (und mu�, denn es gibt hierbei einige
implizite Voraussetzungen, die aber der Anschaulichkeit halber nicht
aufgel�st wurden):
AUTOEXEC.BAT:
@ECHO off > \dev\nul
REM Flexibler Resychronisationssprung:
IF NOT ""=="%1" GOTO %1
...
REM @CALL c:\nwclient\startnet.bat
...
REM Erzeuge tempor�ren Resync-Job:
REM Erster ECHO Parameter bezeichnet d. Job, der von 4START.BAT
REM aufgerufen werden soll, der zweite Parameter die anzuspringende
REM Resync-Marke, weitere Parameter sind nat�rlich optional noch
REM m�glich.
ECHO @c:\autoexec.bat resync > %tmp%\4start_.bat
REM Starte TASKMGR Multitasker (Exec=TRUE) mit 4DOS:
REM 4DOS wird 4START.BAT automatisch aktivieren.
@CALL TASKMGR /f
REM Kommt hier erst nach Beenden aller Tasks hin zur�ck.
GOTO end
:resync
REM Sehr wichtig, um Rekursion und Task-�berl�ufe zu verhindern!
DEL %tmp%\4start_.bat > \dev\nul
REM Ein paar Beispiele:
@CALL TASKMGR /c vir_scan.bat
@CALL TASKMGR /c diskfix c: d: e: f: /test
GOTO end
:end
REM Ende der AUTOEXEC.BAT
4START.BAT:
@IF EXIST %tmp%\4start_.bat %tmp%\4start_.bat
Der Trick besteht darin, da� �ber einen tempor�r erzeugten Job wieder in
den alten Ablauf zur�ckgesprungen wird.
Wichtig:
- %ComSpec%, %tmp%, %NWDOSCFG% und %Path% m�ssen richtig gesetzt sein.
- Exec=TRUE in TASKMGR.INI (damit dieser Aufruf arbeitet, nach Kapitel
VII.3. nicht unbedingt erforderlich f�r den TASKMGR in Verbindung mit
4DOS, wohl aber f�r dieses Beispiel).
- Der TASKMGR mu� als Multitasker starten k�nnen (dazu mu� genug Speicher
vorhanden sein und EMM386 /MULTI=on mu� aktiviert sein).
- Die Datei 4START.BAT mu� f�r 4DOS auffindbar sein, notfalls mit einer
Direktive 4StartPath= in 4DOS.INI.
- Die Marke :end mu� am Ende der AUTOEXEC.BAT stehen, danach darf nichts
weiteres mehr kommen, sonst w�rde TASKMGR dies bearbeiten, nachdem alle
Tasks geschlossen wurden.
�ber solche Tricks ist es sogar m�glich, f�r komplizierte Verwaltungs-
aufgaben die Multitasking-F�higkeiten des Systems voll auszunutzen und
eine regelrechte Kommunikation der Batchjobs mittels 'Message-Dateien'
aufzubauen (allerdings ist dies f�r Laien kaum machbar, da Multitasking,
Proze�-Synchronisation und Parallelisierung eine ganze Vielzahl von
m�glichen Fallstricken (Deadlocks, Rekursionen u.a.) mit sich bringen,
die man sonst nicht beachten mu�, wenn man *nur* mehrere unabh�ngige
sequentielle Abl�ufe oder Applikationen anwendet, siehe Kapitel VII.5.).
Es ist �brigens aus diesen Gr�nden eben gerade nicht m�glich, diese
Minimalform der Kommunikation (wie im Beispiel) statt �ber eine Datei
�ber Umgebungsvariablen abzuwickeln (es w�re ja soviel komforta-
bler...), dies w�rde fast unweigerlich zu Rekursions�berl�ufen f�hren,
der TASKMGR w�rde permanent neue Tasks erzeugen.
---------------------------------------------------------------------------
VII.5. TASKMGR & Multiuser-Betrieb: [97-03-04]
==============================================
Stichworte: DR DOS, Multitasking, Ressourcen-Sharing, Server, Host, PNW,
TASKMGR, UART, FIFO, IRQ, CTTY, CON, PROCOMM
Digital Research (der Entwickler von DR DOS, dem Vorg�nger von
Novell DOS) bot schon immer spezielle DOS-Clones mit Multitasking-
und Multiuser-Funktionen an (Concurrent PC-DOS, Concurrent CP/M,
Concurrent DOS, DR Multiuser DOS, etc.). Soweit mir bekannt, brauchte
dazu z.B. bei DR Multiuser DOS 5 lediglich ein spezieller Treiber
geladen werden, der wohl auch mit DR DOS 6 arbeitete. Zu anderen
Multiuser-Betriebssystemen von Digital Research habe ich leider keine
Informationen (Info wanted!).
Fest steht, da� Novell DOS 7 einerseits im Bereich 'Multiuser' zugelegt
hat, indem wesentliche Funktionen eines solchen Systems, etwa im Bereich
Netzwerk - wenn auch mit anderer Auspr�gung - nun in Form der Personal
NetWare direkt mitgeliefert werden.
Au�erdem bieten viele der externen Novell DOS Programme - wenn auch
undokumentiert - definitiv spezielle Funktionen f�r DR Multiuser DOS an,
manche dieser Programme sogar schon bei DR DOS 6.0 (siehe Kapitel II.4.
und II.9.). Laut Insider-Aussagen stammt Novell DOS 7 sogar urspr�nglich
von DR Multiuser DOS und nicht - wie oft angenommen - von DR DOS 6.0 ab.
Es gibt einige Fakten, die dies best�tigen w�rden, allerdings besteht
auch eine gro�e �hnlichkeit zu DR DOS 6.0.
Dies deutet darauf hin, da� die zuk�nftige Entwicklung offenbar die
beiden Produktlinien Multiuser und Singleuser vereinen sollte, und das,
obwohl Novell 1993 den Support f�r DR Multiuser DOS 5.0 und 5.1 selbst
eingestellt und an Fremdfirmen abgegeben hat (siehe Kapitel IX.11.,
die Firma Concurrent Controls Inc. bietet derzeit (03/1997) ein
Multiuser DOS 7.22 Gold als kostenlose Demo an). Im April 1994 wurde die
Weiterentwicklung von Novell DOS 7 ebenfalls eingestellt (einmal von den
Updates und Support abgesehen, die erst Anfang 1996 eingestellt wurden).
Offenbar war bis zu diesem Zeitpunkt also eine Integration geplant.
Inwieweit die Novell DOS 7 Programme unter einem existierenden DR Multi-
user DOS arbeiten, kann ich in Ermangelung dieses Betriebssystems leider
nicht herausfinden. Andererseits wurden aber auch einige diesbez�gliche
API-Funktionen, die DR DOS 6.0 - ohne irgendwelche zus�tzlichen Treiber -
bereits ab Kernel anbot (etwa File-Owner) wieder entfernt und werden von
Novell DOS 7 nicht mehr unterst�tzt, siehe z.B. Ralf Browns Interrupt-
Liste (s.o.).
Eine dem Multiuser-Betrieb �hnliche Konstellation (aber ohne ent-
sprechende Verwaltungs- und Schutzmechanismen) kann man auf zweierlei
Weise auch unter Novell DOS erzeugen.
Die erste M�glichkeit besteht in der Verwendung der Personal NetWare,
mit der man allerdings nur Ressourcen (wie Laufwerke und Drucker) eines
anderen Rechners und nicht direkt Rechenleistung nutzen kann.
Die andere M�glichkeit besteht in der Verwendung des TASKMGR als Multi-
tasker und ist sehr einfach zu realisieren, indem man �ber serielle
Schnittstellen mehrere entfernte Rechner als Terminals an einen Haupt-
rechner anschlie�t.
Hierzu sind Nullmodem-Kabel und m�glichst schnelle UART-Chips notwendig
(allerdings kann man bei geringer Auslastung durchaus noch auf Chips mit
FIFO verzichten). Nach der Verkabelung und der Einstellung der Schnitt-
stellenparameter, die bei jedem Schnittstellenp�rchen �bereinstimmen
m�ssen, kann man loslegen. Achtung: Es sollte m�glichst keine IRQ-Doppel-
belegungen geben. Novell weist in ihren FaxBack-Dokumenten darauf hin,
da� ein Hintergrundbetrieb von seriellen Schnittstellen (auch) unter dem
(multitaskenden) TASKMGR offiziell nicht unterst�tzt wird (serielle
Schnittstellen werden nicht oder zumindest nur teilweise virtualisiert),
allerdings gibt es verschiedene Einstellungen, die eine solche Betriebs-
art u.U. trotzdem problemlos arbeiten lassen. Dazu sollte man in
TASKMGR.INI die folgenden Einstellungen vornehmen:
[Slice]
Foreground=1
# Das Verh�ltnis von Vordergrund- zu Hintergrund-Tasks, d.h. die Anzahl
# der 'Ticks', die der Vordergrund-Task am St�ck arbeiten darf, ehe der
# Scheduler/Dispatcher (es handelt sich um preemtives Multitasking)
# wieder zuschl�gt. Bei mir tat es auf einem 386sx18 auch das i. allg.
# sinnvollere Foreground=10.
# Granularit�t des Systemtakts in Einheiten von 1/18,2 Sekunden,
# mit denen der Scheduler/Dispatcher intern arbeitet.
# (sollte normalerweise sowieso 1 sein!!!)
TickRate=1
[COMx]
# Es werden COM1-COM4 bzw. LPT1-LPT3 unterst�tzt.
# Der Timeout-Wert erlaubt die folgenden Einstellungen:
# AUTO = Default-Einstellung, offenbar 5 Sekunden f�r COMx und
# 15 Sekunden f�r LPTx.
# 0 = Die Schnittstelle wird nicht virtualisiert, d.h. alle
# Task k�nnen ohne Overhead direkt auf der Hardware ar-
# beiten, was nat�rlich bei unkoordiertem, d.h. gleich-
# zeitigem Zugriff zum Chaos f�hrt.
# 1..65534 = Die Angabe eines Timeout-Wertes virtualisiert die
# Schnittstelle. Durch den Zugriff eines Tasks auf die
# Schnittstelle wird dieser Task der Eigent�mer der
# Schnittstelle. Der Zugriff f�r andere Tasks bleibt
# vorerst gesperrt. In der ersten Halbzeit des Timeouts
# hat der Task vollen Zugriff auf die Schnittstelle, danach
# klinkt sich der Multitasker wieder ein und �berpr�ft, ob
# der Task die Schnittstelle noch benutzt. Benutzt der
# Task die Schnittstelle innerhalb der zweiten H�lfte des
# Timeouts, so zieht sich der Multitasker sofort wieder
# zur�ck. Ansonsten wird die Schnittstelle nach Ablauf des
# Timeouts wieder f�r den allgemeinen Zugriff freigegeben,
# bzw. dem n�chsten wartenden Task zugeordnet.
# 65535 = -1 = Unbegrenzter Timeout, d.h. sobald ein Task die Schnitt-
# stelle angesprochen hat, bleibt sie bis zum Beenden des
# Tasks f�r alle anderen Tasks gesperrt.
TimeOut=65535
[Shell]
Idle=FALSE
# Schaltet die dynamische Wartezeiterkennung ab. Bei mir funktionierte
# auch das i. allg. sinnvollere Idle=TRUE.
[Mouse]
# MousePort=AUTO Hier sollte man die COM-Adresse der Maus,
# verringert um eins, angeben
# MouseIRQ=AUTO Hier sollte man den wirklichen IRQ der Schnittstelle
# angeben. (COM1 und COM3 �blicherweise 4, COM2 und
# COM4 meist 3.)
Der TASKMGR/TASKMAX als Proze�umschalter ist logischerweise nicht f�r
eine serielle Verbindung im 'Hintergrund' geeignet. Trotzdem ist es
auch hier oft praktisch, eine serielle Verbindung in einer Anwendung
aufzubauen und in �bertragungspausen auf eine andere Applikation
umschalten zu k�nnen. In diesem Fall ist es bei Telefonverbindungen
allerdings wichtig, da� sowohl das Modem, als auch das Kommunikations-
programm so konfiguriert werden, da� sie den Status der DTR-Leitung
(data terminal ready) ignorieren, sonst w�rde das Modem n�mlich beim
Umschalten in den Hintergrund die Telefonverbindung unterbrechen.
Auf dem Hauptrechner (dessen Rechenleistung genutzt werden soll) wird
der TASKMGR als Multitasker gestartet und in jedem Task, der durch ein
Host-Terminal genutzt werden soll, aktiviert man CTTY COMx (dies kann
man auch schon in der Aufrufzeile von COMMAND.COM sowie bei SHELL= an-
geben, siehe Kapitel II.11. und III.1.). (Der Proze�umschalter bietet
in diesem Zusammenhang die evtl. interessante undokumentierte Option
/R=devicename, der Multitasker bietet diese Option aber nicht.)
Auf dem jeweiligen Host-Rechner l�dt man ein Terminal-Programm wie z.B.
PROCOMM (dieser Rechner kann durchaus auch wieder unter dem TASKMGR als
Multitasker laufen, wodurch man in anderen Tasks auch lokal arbeiten
kann). Im Terminalbetrieb erscheinen alle Ausgaben an DOS-CON nun auf
dem Fremdrechner und alle Eingaben werden �bermittelt. Dabei kann der
TASKMGR des Hauptrechners in jedem laufenden Task andere Schnittstellen
bedienen.
Es ist sogar m�glich, gleichzeitig noch das Netzwerk zu laden und
den Hauptrechner auch zum File-Server zu machen, wodurch man auch den
direkten Dateizugriff auf dem Hauptrechner bekommt. Solange man die
Kommandozeile verwendet, kann man so auch den Netzwerk-Server fernbe-
dienen. Trotzdem ist diese Kombination etwas paradox, schlie�lich mu�
einerseits eine Netzwerkverkabelung (bei Ethernet meist Strang) und
eine sternf�rmige Verkabelung mit seriellen Kabeln installiert sein.
Theoretisch sollte es aber mit entsprechenden Treibern m�glich sein,
serielle Datenstr�me auf ein anderes Ger�t umzuleiten, etwa durch das
Netz zu 'tunneln' oder umgekehrt den Netzverkehr �ber serielle Schnitt-
stellen abzuwickeln: Sollte jemand mit solchen L�sungen (auch unabh�ngig
von der 'Multiuser'-Idee) Erfahrungen gesammelt haben, w�re ich f�r
Hinweise dankbar (ein paar Ideen finden sich in Kapitel II.8.).
Einziger Nachteil: Alle Programme m�ssen so konfiguriert werden, da� sie
f�r Ein- und Ausgaben ausschlie�lich DOS verwenden, ansonsten ist es
m�glich, da� man vom Host aus ein Programm auf dem Server aufruft, das
weitere Eingaben �ber das BIOS abwickelt oder seine Ausgaben �ber BIOS
oder direkten RAM-Zugriff auf dem Server und nicht auf dem Host anzeigt.
Dadurch verliert der Host die Kontrolle �ber seinen Task auf dem Haupt-
rechner und das Programm mu� dann direkt am Hauptrechner beendet werden
(der nat�rlich in lokalen Tasks auch anderweitig genutzt werden kann).
Auch das wechselseitige Nutzen von Rechenleistung ist m�glich, wenn
auf allen Rechner der TASKMGR als Multitasker geladen wird und in einem
Task immer ein Terminalprogramm mit der Verbindung zum anderen Rechner
l�uft. So lie�e sich zumindest theoretisch eine optimale Ausnutzung der
auf bestimmten Rechnern vorhandenen Ressourcen erreichen, in der Praxis
scheitert dies jedoch meistens daran, da� die Anzahl der ausschlie�lich
DOS verwendenden Programme beschr�nkt ist.
Nachbemerkung: Eine Anwendung f�r diese M�glichkeiten ist bei mir seit
einiger Zeit unter dem Projektnamen JOBMGR in Entwicklung. Die bisherigen
Ergebnisse sind recht erfolgversprechend. Am Horizont steht ein Steuer-
programm (selbst realisiert unter ausschlie�licher Verwendung der Batch-
Sprache!!!), das ein DOS-Netz (wie z.B. PNW oder NetWare) und/oder
einen multitaskenden Novell DOS 7 TASKMGR so nutzen k�nnen wird, da�
Unix-konform Auftr�ge (Batchjobs) abgeschickt werden k�nnen, die dann im
Hintergrund (in anderen lokalen Tasks oder - im Netzverbund - auf
anderen Rechnern) ausgef�hrt werden. Einerseits gibt es damit eine
M�glichkeit, Rechenleistung anderer DOS-Rechner zu nutzen (z.B. im
Netz einen 'Job-Server' einzurichten) und andererseits bietet das Konzept
den Komfort der sofort zur�ckkehrenden Kommandozeile und erweitert
Batchjobs um 'Multithreading' und 'Parallelprocessing'-Funktionen sowie
neue M�glichkeiten in der Zeitsteuerung (permanente Prozesse, AT, etc.).
Die Netzfunktionen sollen auch mit anderen DOS-Versionen als
Novell DOS 7 arbeiten, f�r den Multitasker ist Novell DOS 7 nat�rlich
notwendige Voraussetzung.
---------------------------------------------------------------------------
VII.6. TASKMGR und LOCK:
========================
Stichworte: LOCK, TASKMGR, permanenter Proze�
Die Verwendung der Zeitoption LOCK /T kann unter dem TASKMGR nicht
richtig arbeiten. LOCK sollte deshalb vor TASKMGR geladen werden.
Speziell f�r den TASKMGR gibt es eine M�glichkeit, LOCK als permanenten
Proze� zu laden:
TASKMGR /C LOCK password /P
wobei password das Pa�wort zum Entsperren des Systems darstellt.
Achtung: LOCK.EXE von Novell DOS 7 hat absolut nicht mit den bei MS-DOS 7
(MS Windows95/Chicago) neuen internen Befehlen LOCK und UNLOCK zu tun!!!
---------------------------------------------------------------------------
VII.7. Tastaturprobleme unter dem multitaskenden TASKMGR: [96-05-29]
====================================================================
Stichworte: Tastatur; 'klebende' Modifizierzust�nde
Auf langsamen Rechnern kommt es schon mal vor, da� beim Editieren von
Dateien unter dem multitaskenden TASKMGR unmotiviert Geistertastendr�cke
wie die Zahlen '2', '4', '6' oder '8' eingestreut werden oder die Shift-
Zust�nde (<Shift>, <Alt>, <Ctrl>) pl�tzlich ver�ndert sind. Dies ist kein
Problem oder Bug des TASKMGR, sondern liegt an der nicht gerade idealen
Realisierung des Tastatur-Interfaces AT-kompatibler Rechner, bzw. der
Programme, die dieses Interface bedienen. Ich m�chte an dieser Stelle
nicht auf Details eingehen (wer sich daf�r interessiert, kann z.B. im
Dokument IA.TEC von Quarterdeck oder der Anleitung zum erweiterten
Tastaturtreiber K3PLUS/FreeKEYB Hintergrundinformationen finden).
Das Problem ist auch nicht an den TASKMGR gebunden, sondern kann auch
sonst auftreten, das Auftreten ist aber mit Programmen wie dem TASKMGR,
EMM386-Treibern und bei hoher System-/Interrupt-Auslastung sehr viel
wahrscheinlicher, sobald der Fehler latent vorhanden ist.
Das Problem wird i. allg. durch ein altes Programm oder einen alten
Treiber verursacht, das/der den Tastatur-Interrupt INT09h statt
INT15h/4Fh etc. benutzt. Dabei mu� dies nicht notwendigerweise das
zuletzt installierte Programm sein. Abhilfe ist entweder ein Update
des betreffenden Programms (falls man tats�chlich den wahren �belt�ter
ermitteln kann, was aufgrund der Natur des Fehlers sehr schwer ist,
es sei denn, man kennt den Quellcode der Programme), oder als Workaround
eine verminderte Keyboard-Repeat-Rate (MODE), ein schnellerer Rechner,
weniger (interruptintensive) Hintergrund-Tasks, ein schnellerer Editor
(die BP IDE ist z.B. �u�erst tr�ge bei eingeschaltetem Syntax-High-
lighting), keinen PNW Server auf diesem Rechner laden...
Im konkreten Fall k�nnen Sie die Shift-Zust�nde (Blockmarkierungen
etc.) wieder normalisieren, indem Sie die drei linken Modifizierer-
tasten (<Shift>, <Ctrl>, <Alt>) jeweils nacheinander dr�cken und wieder
loslassen. Verwenden Sie m�glichst nicht die Cursor-Tasten und den grauen
Sechserblock einer MF2-Tastatur (viele Editore erlauben auch auf andere
Weise das Navigieren im Text, z.B. �ber die WordStar-Belegung mit
<Ctrl>+<s>, <Ctrl>+<d>, <Ctrl>+<e>, <Ctrl>+<x>).
Klemmt die Tastatur als Ganzes, hilft es h�ufig, kurz das TASKMGR-Men�
aufzurufen und wieder zu verlassen, denn dabei wird auch das Tastatur-
Interface neu initialisiert.
(Weitere Hinweise willkommen...)
###########################################################################
###########################################################################
VIII. NOVELL DOS 7 UND MS WINDOWS 3.xx:
=======================================
---------------------------------------------------------------------------
VIII.1. Novell DOS und MS Windows 3.xx kombinieren: [97-02-12]
==============================================================
Stichworte: Beta-Windows, DR DOS, AARD, Redirektor, Umadressierer, SETUP,
SYSTEM.INI, SHARE, NWCACHE, TBIM2.COM, VCPI, DPMI, PNW,
NETWARER.DRV, %NWLanguage%, WINA20.386, NWDOS.386, TASKMGR,
DOSPRMPT.PIF, %ComSpec%; VLM-Kit VLM121
Novell DOS ist mit MS Windows 3.xx kompatibel. Trotzdem kann es - wie
mit jedem DOS als Grundlage - eine Reihe Probleme geben, die man schnell
beseitigen kann, wenn man die Ursachen kennt. (Diese Beschreibung bezieht
sich haupts�chlich auf MS Windows 3.1 und 3.11.)
Deshalb hier einige Anmerkungen:
i. Der AARD-Code - eine peinliche 'Historie':
---------------------------------------------
Manche sp�ten Beta-Versionen von MS Windows 3.1 konnten unter DR DOS
(dem Vorg�nger von Novell DOS) nicht gestartet werden, es erschien eine
suspekte Fehlermeldung:
Nicht fataler Fehler: Nr: #2726
Bitte wenden Sie sich an den Beta-Support f�r Microsoft Windows.
Danach wurde die Ausf�hrung von WIN.COM abgebrochen. Nach genauen
Analysen konnte der Code, der dieses Verhalten erzeugt, isoliert
werden; er ist unter dem Namen AARD-Code bekannt geworden und in
diversen B�chern und Zeitschriften publiziert worden. Dieser ver-
schl�sselte und hochgradig selbstmodifizierende Code (der sogar
Debugger abh�ngt) �berpr�ft eine Reihe undokumentierter Eigenschaften
von DOS (dies ist auch einigerma�en legitim - ohne Unterst�tzung
dieser F�higkeiten w�rde Windows nicht arbeiten k�nnen), gegen Ende
aber noch eine wild aus dem Zusammenhang gerissene Bedingung
(Redirector/System FCB/Case Map Test), die in keiner Weise f�r die
ordnungsgem��e Funktion von Windows relevant war (dies wurde mittler-
weile ebenfalls nachgewiesen).
Bei dieser �berpr�fung fiel DR DOS (und fr�he Beta-Versionen von
Novell DOS) durch; MS-DOS, PC-DOS und OEMs wurden akzeptiert.
In der Final-Release von Windows 3.1 ist dieser Code weiterhin enthalten
(jeder braucht nur mit einem Hex-Editor nach der Fehlermeldung oder der
Zeichenkette 'AARD' in WIN.COM oder SETUP.COM und manchen anderen Dateien
zu suchen), allerdings vor�bergehend au�er Funktion gesetzt: Der Code
wurde so erweitert, da� eine zus�tzliche interne Variable �berpr�ft wird.
Wenn diese den Wert 0 hat, wird die Fehlermeldung �bersprungen, hat sie
einen anderen Wert, geschieht dasselbe wie bei der Windows Beta-Version.
D.h. durch gezieltes �ndern eines einzigen Bytes k�nnte dieser Pr�fcode
wieder aktiviert werden, und damit DR DOS abwehrt werden.
Microsoft hat die Existenz des AARD-Codes 'im Prinzip nicht dementiert'
(Microsoft Deutschland hat die Existenz dieses Codes sogar offen zuge-
geben) - jeder mag sich seinen Teil dabei denken...
Wenige Tage nach dem Erscheinen von MS Windows 3.1 hatte Digital Research
allerdings ein 'Business' Update f�r DR DOS 6.0 herausgegeben, da� neben
verschiedenen anderen Anpassungen und Bugfixes auch diese �berpr�fung
umging. Leider hat die �ffentlichkeit von diesem und einigen anderen
Updates zu wenig erfahren, deshalb wurde DR DOS oft als nicht mit
MS Windows 3.1 kompatibel abgestempelt (obwohl es ja zum Teil eher
umgekehrt war) - nach diesem Update gab es keine Probleme mit DR DOS
und MS Windows 3.1...
ii. Modifikationen am Windows-System durch Novell DOS SETUP:
------------------------------------------------------------
Bei der Installation von Novell DOS nimmt das Setup-Programm einige
Anpassungen des Windows-Systems vor. Sollten Sie MS Windows jedoch
erst sp�ter installieren oder updaten, m�ssen Sie diese Einstellungen
per Hand vornehmen (besonders wichtig, da oft vergessen: TASKMAN.EXE=).
Dies kann auch notwendig sein, wenn Sie eine Netzinstallation von
Windows vornehmen:
Folgende wichtige Modifikationen werden u.a. in SYSTEM.INI gemacht:
Im Abschnitt [boot]: network.drv= wird ersetzt durch
network.drv=netware.drv
(Dies l�dt die 'NetWare user'
Programme, evtl. in dieser Form nur
f�r PNW notwendig)
taskman.exe=taskman.exe
wird ersetzt durch
taskman.exe=c:\nwdos\TASKMGR.EXE
(oder ein entsprechendes anderes
Verzeichnis z.B. \WINDOWS\)
Sie sollten sicherstellen, da� die
Datei TASKMGR.EXE auch bei Novell DOS
Updates mit upgedatet wird. Die Kopie
in das Windows-Verzeichnis wird dabei
h�ufig vergessen.
Im Abschn. [boot.description]: network.drv= wird ersetzt durch
network.drv=Personal NetWare (V1.0)
(Dies definiert, welche Personal NetWare
Ger�teversion Sie verwenden, nat�rlich
nur bei PNW so notwendig.)
Im Abschnitt [386Enh]: network=dosnet wird ersetzt durch
network=*vnetbios;vipx.386;vnetware.386
(Dies legt den Typ des Netzes fest,
der mit dem Erweiterten 386er Modus von
MS Windows verwendet wird.)
Diese Einstellungen galten auch schon f�r
NetWare Lite:
TimerCriticalSection= wird ersetzt durch
TimerCriticalSection=10000
(Personal NetWare verwendet diese
Einstellung, um sicherzustellen, da�
der Netzverkehr auf Ihrem Computer
gleichm��ig verl�uft. Angeblich soll
notfalls auch noch 500 laufen.)
ReflectDOSInt2A=TRUE wird hinzugef�gt.
OverlappedIO=OFF wird hinzugef�gt.
PSPIncrement=5 wird hinzugef�gt.
UniqueDOSPSP=TRUE wird hinzugef�gt.
device=fastback.386 wird f�r FastBack-
Software hinzugef�gt, aber nur bei
Floppy-Backups (nicht lokale Festplatten
oder Netzlaufwerke) ben�tigt. Dieser
Treiber vertr�gt sich nicht mit QIC80-
Streamer-Software (z.B. QBACKUP-Win f�r
"IOMega insider 250") im Erweiterten
386er-Modus, mu� daher h�ufig wieder ent-
fernt werden. In Novells FaxBack-Doku-
menten wird auf Probleme beim Formatieren
von Cartridges mit IOMegas 250 MByte
Floppy-Streamer unter Novell DOS 7 be-
richtet; ich hatte allerdings (offen-
sichtlich mit genau diesem Streamer)
keinerlei Probleme. Bei dieser Gelegen-
heit noch ein Hinweis am Rande: IOMegas
QBACKUP 3.x vertr�gt sich offensichtlich
nicht (immer) mit Logitech-Maustreibern
(aufgefallen mit MouseWare 6.50). Hier
hilft es, den Logitech-Maustreiber f�r
die Dauer von QBACKUP mit einem anderen
Maustreiber (etwa GMOUSE 10.20) zu �ber-
laden.
Im Abschnitt [NetWare]: NWShareHandles=1 sofern gew�nscht
Im Abschnitt [VIPX]: (siehe auch in Novells VIPX.DOC)
; alle Parameter sind optional und nur selten erforderlich:
VipxMappingPages =[number of 4K pages] ; <16>
VipxFailOverSizedPackets =[ON|OFF|TRUE|FALSE] ; <OFF>
VpicdFix =[ON|OFF|TRUE|FALSE] ; <ON>
AutoIrqVirtualize =[ON|OFF|TRUE|FALSE] ; <ON>
VirtualizeIrq[0-F] =[ON|OFF|TRUE|FALSE] ; <OFF>
KeepLongLivedSocketsOpen =[ON|OFF|TRUE|FALSE] ; <OFF>
; Diese Parameter existieren nur in Beta-Versionen von VIPX.386:
VipxErrorMessages =[ON|OFF|TRUE|FALSE] ; <OFF>
VipxWarningMessages =[ON|OFF|TRUE|FALSE] ; <OFF>
VipxBreakOnErrors =[ON|OFF|TRUE|FALSE] ; <OFF>
VipxBreakOnWarnings =[ON|OFF|TRUE|FALSE] ; <OFF>
VipxOutDebugStrOnErrors =[ON|OFF|TRUE|FALSE] ; <OFF>
VipxOutDebugStrOnWarnings=[ON|OFF|TRUE|FALSE] ; <OFF>
Folgende Modifikationen werden in WIN.INI gemacht:
Im Abschnitt [Windows]: load= wird ersetzt durch
load=nwpopup.exe
(Dies erlaubt die Anzeige von
Netzmeldungen in MS Windows)
Netwarn=1 wird hinzugef�gt
(Wenn diese Einstellung aktiviert ist,
das Netzwerk jedoch nicht geladen ist,
zeigt MS Windows bei Start ein PopUp-
Fenster an, das meldet, da� das Netzwerk
nicht geladen ist.)
Bei der Einrichtung von STACKER wird in WINFILE.INI eingetragen:
Im Abschnitt [AddOns]: Stacker Extension=c:\nwdos\stacfm.dll
Bei dieser Gelegenheit k�nnen Sie - sofern Sie nicht mit dem L�sch-
schutz von MS-DOS arbeiten - im Abschnitt [AddOns] auch einen evtl.
vorhandenen Eintrag:
MS-DOS Tools Extentions=c:\msdos\mstools.dll
und im Abschnitt [Settings] einen Eintrag
UNDELETE.DLL=c:\msdos\mstools.dll
von einer vorherigen MS-DOS-Installation entfernen, die Sie nicht mehr
brauchen.
Von den Speichermanagern wird nur EMM386 ben�tigt. Die Parameter /DPMI
und /MULTI k�nnen aktiviert werden; VCPI braucht *nicht* mittels /NOVCPI
abgeschaltet werden. Der Schalter /WINSTD wird nicht ben�tigt und auch
nicht empfohlen, wenn Sie mit MS Windows 3.1 arbeiten. DPMS kann eben-
falls ohne Probleme genutzt werden.
Au�erdem wird dringend empfohlen, vor MS Windows 3.xx die Novell DOS 7
Programme SHARE und NWCACHE (notfalls SMARTDRV) zu laden (MS-DOS hat
SHARE intern realisiert, bei Novell DOS 7 mu� man f�r den gleichen
API-Umfang das TSR SHARE laden).
iii. Netzwerk (PNW) Einrichtung f�r Windows:
--------------------------------------------
Ein zu verwendendes Netzwerk (ob NetWare oder PNW) mu� vor MS Windows
geladen werden, wenn man es innerhalb von Windows global einsetzen
m�chte (Ausnahme: siehe Kapitel VI.2. und II.8.).
F�r PNW sind eine ganze Reihe von Dateien im Windows-Verzeichnis n�tig.
Dabei wird von einer lokalen Installation ausgegangen (f�r eine Windows
Netzinstallation siehe Kapitel VIII.3.).
Eine �bersicht gibt die folgende Auflistung:
c:\windows\taskmgr.exe Opt., �ber Pfad auch in C:\NWDOS m�glich
c:\windows\nwdos.grp Gruppendatei f�r Novell DOS und PNW
c:\windows\netware.ini Einstellungen der PNW-Tools
c:\windows\nwdrvwin.bmp Diese Netz-Treiber nur mit dem VLM-Kit
c:\windows\nwrcon.pif VLM121_1.EXE - VLM121_6.EXE...
c:\windows\loginw31.exe Diese Datei ist f�r PNW nicht unbedingt
erforderlich.
c:\windows\system\bwcc.dll F�r Search & Destroy Viren-Scanner,
siehe Kapitel II.4. bei WSDRES/WSDSCAN
c:\windows\system\fastback.386 F�r Fifth Generation FBWX
c:\windows\system\netware.hlp Hilfedatei f�r Netz-Tools wie NWUSER.EXE
Nur bei PNW *hier*, mit VLM121_1.EXE
bis VLM121_6.EXE dagegen in
C:\WINDOWS\NLS\DEUTSCH\
c:\windows\system\netwhelp.hlp nur bei PNW
c:\windows\system\netwpnw.dll nur bei PNW
c:\windows\system\nwnetapi.dll nur bei PNW (ersetzt durch NWCALLS.DLL)
c:\windows\system\pnwdiagw.dll nur bei PNW
Diverse gemeinsame Netz-Treiber:
c:\windows\system\netware.drv NetWare Client Windows Treiber
c:\windows\system\nwcalls.dll NCP Kommunikation zwischen Server/Client
c:\windows\system\nwgdi.dll NetWare Graphical Device Interface
c:\windows\system\nwipxspx.dll IPX/SPX Kommunikation
c:\windows\system\nwlocale.dll Lokalisierung/Internationalisierung
c:\windows\system\nwnet.dll Netzwerkunterst�tzung f�r NDS usw.
c:\windows\system\nwpopup.exe wird beim Start von Windows geladen...
c:\windows\system\nwpsrv.dll f�r Druckerserver (ersetzt NWPSERV.DLL)
c:\windows\system\pnw.dll f�r grafische PNW-Utilities
c:\windows\system\taskid.com f�r korrekte Task-Zuordnung unter Task-
switchern
c:\windows\system\tbmi2.com f�r Task-Switcher wie DOSSHELL, TASKMAX,
TASKMGR als Prozessumschalter, Windows
3.xx im Standardmodus
c:\windows\system\vipx.386 Virtueller IPX/SPX Treiber
c:\windows\system\vnetware.386 Virtueller NetWare-Treiber
sollten identischen mit den Dateien
in C:\NWDOS\ sein, die der TASKMGR.EXE
bei Bedarf verwendet.
c:\windows\system\audwin16.dll Diese Netz-Treiber nur mit dem VLM-Kit
c:\windows\system\calwin16.dll VLM121_1.EXE - VLM121_6.EXE, teilweise
c:\windows\system\clnwin16.dll auch schon mit dem �lteren VLM-Kit
c:\windows\system\clxwin16.dll VLMKT1.EXE - VLMKT6.EXE...
c:\windows\system\ctl3dv2.dll
c:\windows\system\lgnw3116.dll
c:\windows\system\locwin16.dll
c:\windows\system\loginw31.dll
c:\windows\system\ncpwin16.dll
c:\windows\system\netwin16.dll
c:\windows\system\nwuser.exe N�tzliches Tool
c:\windows\system\prtwin16.dll
c:\windows\system\tli_spx.dll
c:\windows\system\tli_tcp.dll
c:\windows\system\tli_win.dll
c:\windows\nls\1252_uni.001 Allgemeine Unicode-Dateien:
c:\windows\nls\1252_uni.002 Nicht alle dieser Dateien werden in
c:\windows\nls\1252_uni.003 Deutschland wirklich ben�tigt (nur
c:\windows\nls\1252_uni.031 .001, .049), aber der Einfachheit
c:\windows\nls\1252_uni.032 halber habe ich alle m�glichen der
c:\windows\nls\1252_uni.033 bei PNW mitgelieferten Dateien auf-
c:\windows\nls\1252_uni.034 gelistet. Die gro�en NetWare-Ausgaben
c:\windows\nls\1252_uni.039 unterst�tzen noch wesentlich mehr
c:\windows\nls\1252_uni.041 Codeseiten und L�nder; siehe auch
c:\windows\nls\1252_uni.044 Kapitel II.16.
c:\windows\nls\1252_uni.045 Sollten Sie Unterst�tzung f�r andere
c:\windows\nls\1252_uni.046 L�nder oder Codeseiten ben�tigen,
c:\windows\nls\1252_uni.047 finden Sie im 'Novell Client Kit for
c:\windows\nls\1252_uni.049 DOS & Windows 3.xx' sicherlich die
c:\windows\nls\1252_uni.061 n�tigen Dateien; siehe auch Kapitel I.2.
c:\windows\nls\1252_uni.081
c:\windows\nls\1252_uni.351
c:\windows\nls\1252_uni.358
c:\windows\nls\437_uni.001
c:\windows\nls\437_uni.003
c:\windows\nls\437_uni.031
c:\windows\nls\437_uni.032
c:\windows\nls\437_uni.033
c:\windows\nls\437_uni.034
c:\windows\nls\437_uni.039
c:\windows\nls\437_uni.041
c:\windows\nls\437_uni.044
c:\windows\nls\437_uni.046
c:\windows\nls\437_uni.049
c:\windows\nls\437_uni.061
c:\windows\nls\437_uni.358
c:\windows\nls\uni_1252.001
c:\windows\nls\uni_1252.002
c:\windows\nls\uni_1252.003
c:\windows\nls\uni_1252.031
c:\windows\nls\uni_1252.032
c:\windows\nls\uni_1252.033
c:\windows\nls\uni_1252.034
c:\windows\nls\uni_1252.039
c:\windows\nls\uni_1252.041
c:\windows\nls\uni_1252.044
c:\windows\nls\uni_1252.045
c:\windows\nls\uni_1252.046
c:\windows\nls\uni_1252.047
c:\windows\nls\uni_1252.049
c:\windows\nls\uni_1252.061
c:\windows\nls\uni_1252.081
c:\windows\nls\uni_1252.351
c:\windows\nls\uni_1252.358
c:\windows\nls\uni_437.001
c:\windows\nls\uni_437.003
c:\windows\nls\uni_437.031
c:\windows\nls\uni_437.032
c:\windows\nls\uni_437.033
c:\windows\nls\uni_437.034
c:\windows\nls\uni_437.039
c:\windows\nls\uni_437.041
c:\windows\nls\uni_437.044
c:\windows\nls\uni_437.046
c:\windows\nls\uni_437.049
c:\windows\nls\uni_437.061
c:\windows\nls\uni_437.358
c:\windows\nls\uni_col.001
c:\windows\nls\uni_col.002
c:\windows\nls\uni_col.003
c:\windows\nls\uni_col.031
c:\windows\nls\uni_col.032
c:\windows\nls\uni_col.033
c:\windows\nls\uni_col.034
c:\windows\nls\uni_col.039
c:\windows\nls\uni_col.041
c:\windows\nls\uni_col.044
c:\windows\nls\uni_col.045
c:\windows\nls\uni_col.046
c:\windows\nls\uni_col.047
c:\windows\nls\uni_col.049
c:\windows\nls\uni_col.061
c:\windows\nls\uni_col.081
c:\windows\nls\uni_col.351
c:\windows\nls\uni_col.358
c:\windows\nls\uni_mon.001
c:\windows\nls\uni_mon.002
c:\windows\nls\uni_mon.003
c:\windows\nls\uni_mon.031
c:\windows\nls\uni_mon.032
c:\windows\nls\uni_mon.033
c:\windows\nls\uni_mon.034
c:\windows\nls\uni_mon.039
c:\windows\nls\uni_mon.041
c:\windows\nls\uni_mon.044
c:\windows\nls\uni_mon.045
c:\windows\nls\uni_mon.046
c:\windows\nls\uni_mon.047
c:\windows\nls\uni_mon.049
c:\windows\nls\uni_mon.061
c:\windows\nls\uni_mon.081
c:\windows\nls\uni_mon.351
c:\windows\nls\uni_mon.358
c:\windows\nls\deutsch\netwarer.drv Referenziert �ber %NWLanguage%
c:\windows\nls\deutsch\netware.hlp Das VLM-Kit VLM121_1.EXE -
c:\windows\nls\deutsch\login.dat VLM121_6.EXE ben�tigt eine Reihe
c:\windows\nls\deutsch\login.msg weiterer Dateien, die hier aufge-
c:\windows\nls\deutsch\loginw31.hlp listet werden, aber nur bei Ver-
wendung von LOGINW31.EXE ben�tigt
werden.
c:\windows\nls\deutsch\taskid.msg Eventuell brauchen Sie auch noch
c:\windows\nls\deutsch\tbmi2.msg diese Dateien.
Sollten Sie einmal eine Fehlermeldung erhalten, da� die Datei
NETWARER.DRV ncht gefunden werden kann, sollten Sie �berpr�fen ob
1. die Variable %NWLanguage% z.B. in STARTNET.BAT korrekt gesetzt wird.
Sie mu� den Namen des Unterverzeichnisses von \WINDOWS\NLS\DEUTSCH
enthalten, hier also 'DEUTSCH' (siehe Kapitel II.16., IV.7., VI.2.),
als auch
2. ob Sie MS Windows �ber ein Substitut-Laufwerk o.�. aufgerufen haben.
Falls dies zutrifft, sollten Sie stattdessen MS Windows �ber einen
Batchjob aufrufen, der vorher auf das Windows-Laufwerk und Verzeichnis
wechselt. U.U. kann man auch auf den undokumentierten Befehl TRUENAME
ausweichen (nicht getestet).
iv. Weitere Hinweise:
---------------------
Es ist auch m�glich, MS Windows als einen Task des DOS-Task-Managers
TASKMGR auszuf�hren (allerdings arbeitet MS Windows dann nur im Standard
Modus /S), wenn Sie nach dem Netzwerk, aber noch vor MS Windows den
TASKMGR als Multitasker laden. Auf diese Weise k�nnen Sie - zumindest
theoretisch - z.B. MS Windows mit preemptivem Multitasking-F�higkeiten
ausr�sten und sogar mehrere Windows-Sessions nebeneinander laufen lassen,
in der Praxis ist der daf�r notwendige Aufwand meist viel zu gro�.
Wenn Sie stattdessen TASKMGR als Proze�umschalter laden, kann MS Windows
sogar im Erweiterten 386er Modus ausgef�hrt werden. Umgekehrt ist es auch
m�glich, den TASKMGR in einer Windows-DOS-Box als Proze�umschalter zu
starten - die Vielfalt kennt keine Grenzen. Wenn dabei immer der gleiche
TASKMGR (und nicht TASKMAN) zum Einsatz kommt, kann man sogar aus dem
Task-Men� von Windows die DOS-Tasks, die vor Windows gestartet wurden,
sowie auf die Tasks innerhalb einer DOS-Box umschalten, d.h. alle Tasks
des Systems �ber das TASKMGR-Men� steuern. Achten Sie in diesem Fall
besonders auf die f�r das TASKMGR-Men� gew�hlte Tastenkombination.
Wenn Sie MS Windows im Standard Modus in Verbindung mit dem Task-Manager
ausf�hren wollen, m�ssen Sie u.U. noch das Programm TBIM2 laden, das
Netzanforderungen in unterschiedlichen Tasks koordiniert.
Ein Beispiel f�r einen Batchjob dieser Art:
WIN.BAT:
@ECHO off > \dev\nul
REM Das Starten �ber ein Substitut-Laufwerk f�hrt dazu, da� der Treiber
REM NETWARER.DRV (Deutsch) nicht gefunden wird.
c:
CD c:\windows
REM Video-Speicher freigeben bei DR DOS/Novell DOS.
REM Achtung: Mit 4DOS 5.51 (only) kann dies Probleme verursachen, wenn
REM Video-Speicher aktiv war.
IF EXIST %dos%\MEMMAX.EXE CALL MEMMAX -v
REM Im Standard Modus wird ein spezieller Treiber f�r TASKMGR ben�tigt.
REM Warnt�ne (von TBMI2) werden ebenfalls ins Null-Device geschickt! ;-)
FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 > \dev\nul
REM In Verbindung mit �lteren Versionen von K3PLUS war K3_DISZZ/K3_ENZZ
REM evtl. erforderlich (mit neueren Versionen von K3PLUS/FreeKEYB nicht
REM mehr):
REM @CALL k3_diszz
@win.com %1 %2 %3 %4 %5 %6 %7 %8 %9
REM @CALL k3_enzz
FOR %%x IN (/s /S -s -S s S) DO IF "%%x"=="%1" CALL TBMI2 /u > \dev\nul
IF EXIST c:\nwdos\nwcache.exe CALL NWCACHE /size=max
Sollten Sie beim Start von MS Windows Fehlermeldungen der Art 'Konnte
wichtigen Ger�tetreiber, der evtl. f�r den Erweiterten 386er Modus not-
wendig ist, nicht finden' bekommen, sollten Sie versuchen, MS Windows
�ber einen Batchjob aufzurufen und vorher in das Windows-Verzeichnis zu
wechseln. Alternativ k�nnen Sie in der SYSTEM.INI auch die kompletten
Pfade auf die Treiber angeben oder Sie k�nnen dieses Verzeichnis auch
in die PATH-Anweisung aufnehmen, wodurch solche Probleme generell
vermieden werden.
Bei derartigen Problemen hilft es oft, WIN /B aufzurufen; dadurch
wird w�hrend des Starts von Windows in der Datei BOOTLOG.TXT ein
Startprotokoll aufgezeichnet.
�berpr�fen Sie, ob NWDOS.386 im Hauptverzeichnis liegt und sichtbar ist.
Ansonsten k�nnen Sie den Pfad zu dieser Datei in der CONFIG.SYS bei
EMM386 angeben oder eine Anweisung SWITCHES= entsprechend Microsofts
Konventionen verwenden.
WINA20.386 und NWDOS.386 werden nur f�r Windows 3.0 ben�tigt, ansonsten
k�nnen diese Dateien gel�scht werden. Allerdings mu� man dann auch den
entsprechenden Eintrag in der SYSTEM.INI entfernen, damit die Fehler-
meldung unterbleibt.
�berpr�fen Sie auch die Einstellungen in der %NWDOSCFG%\TASKMGR.INI
Datei. Bei richtiger Konfiguration wird statt MS Windows' TASKMAN
Novell DOS' TASKMGR als Manager f�r MS Windows geladen, deshalb sind
dessen Einstellungen u.U. nicht unrelevant.
Noch ein Tip zum Schlu�: Gerade auch im Zusammenspiel unterschiedlicher
Kommandoprozessoren in DOS-Boxen unter Windows ist es meist empfehlens-
wert, in der DOSPRMPT.PIF Datei nicht direkt COMMAND.COM (bzw. 4DOS.COM)
anzugeben, sondern %ComSpec%, das immer den richtigen Eintrag enthalten
sollte. Beim Speichern dieser Einstellung wird der PIF-Editor eine
Fehlermeldung bez�glich einer falschen Dateiendung ausgeben. Diese kann
getrost ignoriert werden, Windows macht nach dem Speichern genau das,
was es soll und ersetzt sp�ter die Variable durch ihre aktuelle Belegung.
(Beim ersten Speichern ist Windows unbarmherzig, hier mu� man also
zun�chst COMMAND.COM angeben, speichern, dann durch %ComSpec% ersetzen
und erneut speichern...)
Danach sollte MS Windows unter Novell DOS ebenso stabil wie unter
MS-DOS laufen (meine vielleicht paradoxe pers�nliche Erfahrung:
erstaunlicherweise stabiler!!!).
Haben Sie auf einem neuen Rechner zun�chst Novell DOS 7 und dann
MS Windows 3.xx installiert, wollen Sie sicherlich die Installation
der Windows-Tools von Novell DOS 7 nachholen (sehr empfehlenswert).
Daf�r m�ssen Sie u.U. Novells SETUP.INI (in %NWDOSCFG% alias C:\NWDOS\)
modifizieren:
WinPath=Pfad auf Windows-Verzeichnis (meist C:\WINDOWS\)
FirstTime=Yes
Element0Installed=Yes
Element1Installed=No
Element2Installed=Yes
NetCFGDir=Pfad auf die PNW (meist C:\NWCLIENT\)
WINDOWS=No
---------------------------------------------------------------------------
VIII.2. Novell DOS, MS Windows 3.xx und Genius-Maustreiber 10.20:
====================================================[96-02-05]===
Stichworte: Genius-Maus, 3-Tasten-Modus, GMOUSE.SYS/COM/DRV, SimTel,
TASKMGR, Windows, 4DOS
�ber SimTel ist ein neuer Genius-Maustreiber 10.20 (1993) verf�gbar,
den viele Benutzer von Genius-M�usen wohl schon lange vergeblich gesucht
haben, da die letzte weitverbreitete Version 9.06 (1991) schon etliche
Jahre zur�cklag und mit verschiedener Software Probleme bereitete (u.a.
auch mit dem TASKMGR aus fr�hen Versionen von Novell DOS 7, siehe
Kapitel VII.1.).
Der neue Treiber in seiner MS Windows Version GMOUSE.DRV erm�glicht
ruckfreies Arbeiten mit der Maus, auch im 3-Tasten-Modus. Die bisherigen
Treiber (die bei MS Windows beilagen) oder diverse andere Fremdtreiber
arbeiteten leider nicht v�llig problemlos mit MS Windows �ber Novell DOS:
der Zeiger sprang bei Diskettenzugriffen schon bei kleinsten Bewegungen
der Maus wild �ber den Bildschirm und beruhigte sich erst, wenn der
Cache NWCACHE nach der Startphase zur Ruhe gekommen ist (mit MS-DOS
und SMARTDRV zeigte sich dieses Verhalten nicht, aber repr�sentativ
mu� das nicht sein).
Leider st�rzt das SETUP-Programm zu diesem Genius-Maustreiber w�hrend
der Installation ab, da es u.a. nicht mit Novell DOS- (und DR DOS-)
spezifischen Eintr�gen in CONFIG.SYS (Boot-Men�s) zurechtkommt. Aber
auch ansonsten gibt es eine Reihe von Problemen mit diesem Programm
(beschr�nkte Verzeichniswahl, z.B. keine Verzeichnisse mit einem Punkt).
Es bleibt die manuelle Installation, bei der man f�r MS Windows in
SYSTEM.INI den MOUSE.DRV=\path\GMOUSE.DRV eintragen mu�.
---------------------------------------------------------------------------
VIII.3. Novell DOS und MS Windows 3.xx Netzinstallation: [96-06-13]
===================================================================
Stichworte: Netzinstallation, PNW, SYSTEM, SETUP.INI
Die Dateien NETWARE.DRV, FASTBACK.386 und VNETWARE.386 m�ssen ins
Windows-Netzverzeichnis kopiert werden, ins lokale Windows \SYSTEM\
Verzeichnis geh�ren NETWPNW.DLL, NW*.DLL, PNW.DLL und PNDDIAGW.DLL.
Die lokale SYSTEM.INI mu� die in Kapitel VIII.1. beschriebenen
Einstellungen vorweisen (nach c't 08/1994 S.195).
Bez�glich FASTBACK.386 und PNW siehe auch Kapitel VIII.1.
---------------------------------------------------------------------------
VIII.4. Windows-Maus in DOS-Boxen im Fenster benutzen: [96-12-19]
=================================================================
Stichworte: Logitech LVMD.386, SYSTEM.INI, Drag & Drop, Copy & Paste,
CLOAKING, DPMS
Dieser Tip funktioniert unabh�ngig von der installierten DOS-Version
(also auch mit MS-DOS/PC-DOS)!
Viele haben sich sicherlich schon dar�ber ge�rgert, da� man zwar
unter MS Windows 3.xx DOX-Boxen �ffnen kann, die Maussteuerung einer
dort gestarteten Applikation jedoch normalerweise nur dann funktioniert,
wenn man die Applikation im Vollbildmodus startet.
Schaltet man dann auf den Fensterbetrieb um, so ist die Maus pl�tzlich
verschwunden. Stattdessen kann man mit der Windows-Maus arbeiten,
auf die aber das DOS-Fenster nicht reagiert. Schaltet man zur�ck in den
Vollbildmodus, kommt es - abh�ngig von der jeweiligen Applikation - sogar
vor, da� nun auch hier die Maus verschwunden ist.
Startet man die Applikation jedoch im Fenster, erscheint die DOS-Maus
erst gar nicht und bleibt �blicherweise auch beim Umschalten in den
Vollbildmodus verschwunden.
Diese Probleme sind nur logisch, denn die Applikation wird nicht st�ndig
versuchen, eine evtl. beim Start nicht verf�gbare Maus nachtr�glich zu
aktivieren.
Allerdings gibt es eine M�glichkeit, dieses Problem sehr elegant
zu l�sen, und zwar unabh�ngig von den verwendeten DOS- und Windows-
Maustreibern:
Logitech und OEMs liefern zu ihren M�usen ein Treiberpaket namens
"MouseWare" mit. Dieses Paket ist aber auch an vielen Stellen in den
Datennetzen verf�gbar. In der Version 6.30 dieses Pakets befindet sich
u.a. ein virtueller Ger�tetreiber LVMD.386 f�r MS Windows 3.xx, der statt
des Standard-Treibers in der SYSTEM.INI [386Enh] Sektion eingetragen
werden mu� (falls der Treiber nicht im \WINDOWS\SYSTEM\ Verzeichnis
liegt, bei Bedarf mit Pfadangabe).
SYSTEM.INI:
[386Enh]
...
; z.B. einen Eintrag wie
; mouse=mscvmd.386
; ersetzen durch einen Logitech-Treiber
mouse=lvmd.386
...
Der 'normale' Windows-Maustreiber in SYSTEM.INI und der �blicherweise
in CONFIG.SYS oder AUTOEXEC.BAT geladene DOS-Maustreiber braucht nicht
ge�ndert zu werden (eine einigerma�en aktuelle API-Unterst�tzung des
Treibers vorausgesetzt: GMOUSE 10.20 und verschiedene Microsoft-Treiber
funktionierten jedenfalls).
Nach dieser �nderung kann man nun auch in DOS-Boxen, die im Fenster
laufen, den Windows-Mauszeiger benutzen:
Befindet sich der Mauszeiger �ber dem Fenster der DOS-Box, beziehen sich
alle Tastendr�cke, Drag & Drop-Operationen etc. auf die in der DOS-Box
laufende Applikation (besonders praktisch z.B. f�r den Norton Commander
NC 5.0x, der neuerdings �ber Drag & Drop M�glichkeiten verf�gt. Kleiner
Seitenhieb: Ob der NC eigentlich immer noch der meistgenutzte Datei-
manager unter Windows ist? ;-) ).
Au�erhalb des Fensters bezieht sich die Maus nat�rlich wie gewohnt auf
die Windows-Anwendungen.
Die einzige Einschr�nkung ist, da� Mausoperationen bei MS Windows 3.xx
nicht �ber die Grenzen eines Fensters hinweg m�glich sind, denn
schlie�lich l�uft jede DOS-Box in einer eigenen virtuellen Maschine und
bekommt ohne spezielle Kommunikation mit Windows nichts davon mit, da�
sie in einem Fenster unter Windows l�uft.
Mit Windows95 hat sich dies jedoch ge�ndert (und das unabh�ngig von
obigem Treiber); hier werden beschr�nkte Drag & Drop und Copy & Paste
Operationen zwischen DOS- und Windows-Applikationen geboten.
Eine Copy & Paste Funktion (und unter Zuhilfenahme dieses Tricks auch
mit kompletter Windows-Mausunterst�tzung f�r die DOS-Box) bietet aller-
dings auch schon MS Windows 3.xx:
L�uft eine DOS-Box im Fenster, so kann man �ber das Systemmen�
(links oben in der Fensterumrahmung) unter dem Punkt 'Bearbeiten'
auf 'Markieren' gehen und dann Bildschirmausschnitte des angezeigten
Fensters markieren. Bez�glich der genauen Arbeitsweise (und anderer
M�glichkeiten, etwa im Vollbildmodus) sei auf die Online-Hilfe von
NOTEPAD.EXE (der Zwischenablage) verwiesen.
Normalerweise kann man daf�r (im Fensterbetrieb) nur die Cursor-Tasten
in Verbindung mit <Shift> benutzen. Mit dem oben angesprochenen Logitech-
Treiber kann man jedoch nach Aktivierung des 'Markieren'-Men�punktes
(sonst bezieht sich die Maussteuerung ja wie oben erl�utert auf die
Applikation selbst) wie gewohnt den Windows-Mauszeiger benutzen
(linke Maustaste), um Bereiche zu markieren und dann mit 'Kopieren' in
die Zwischenablage zu kopieren. Von dort kann sie dann mit 'Bearbeiten'/
'Einf�gen' als simulierte Tastatureingabe in eine andere DOS-Anwendung
�bernommen werden oder aus der Zwischenablage auch in Windows-Anwendungen
eingebunden werden.
Nachbemerkung:
In der Logitech MouseWare 6.50+ befindet sich auch eine neue Version
des 'normalen' DOS-Maustreibers, der vielleicht f�r Sie interessant ist:
Diese neue Version unterst�tzt das CLOAKING-API, und kann sich, wenn
man vorher den beiliegenden Treiber CLOAKING.EXE geladen hat (kann auch
in CONFIG.SYS mit DEVICE=/DEVICEHIGH= geladen werden), bis auf 1 KByte
aus dem ersten MegaByte auslagern (statt sonst 27 KByte zu belegen)!
(Dies funktioniert sogar in CONFIG.SYS, wenn man auch MOUSE.EXE per
DEVICE=/DEVICEHIGH= l�dt...)
CLOAKING ist eine Entwicklung von Helix Software und kostet selbst nur
1 KByte Speicher. CLOAKING ist von seinem Einsatzzweck und der Funk-
tionalit�t Novells DPMS �u�erst �hnlich, in Wahrheit enth�lt der
CLOAKING-Treiber (undokumentiert) selbst einen 'Cloaked DPMS-Server',
d.h. das CLOAKING-API ist eine Obermenge von Novells DPMS-Standard!!!
Obwohl laut Logitech offiziell nicht unterst�tzt, arbeitet CLOAKING
nat�rlich nicht nur deswegen in praktisch allen Konfigurationen (mit
/MULTI=on) einwandfrei mit Novells Speichermanagern zusammen (getestet
mit Update 15, lediglich der TASKMGR st�rzte bei mir immer ab, sobald
CLOAKING geladen war :-( ). Weitere Hinweise zu CLOAKING und DPMS finden
sich in Kapitel II.5. bei DPMS.
###########################################################################
###########################################################################
IX. LITERATUR:
==============
---------------------------------------------------------------------------
IX.1. Novell DOS 7 Handbuch:
============================
Autoren : nicht bekannt (Novell)
(�bersetzung des DR DOS 6.0 Handbuchs: Monika F�rst, BD�)
Sonstiges: DOSBOOK
Gute Einf�hrung in Novell DOS 7 (auch einige didaktische Hinweise f�r
Anf�nger, allerdings war hier das DR DOS 6 Handbuch ausf�hrlicher),
enth�lt aber leider nicht die komplette Dokumentation des Systems. An
vielen Stellen wird auf die wesentlich ausf�hrlichere Online-Hilfe
DOSBOOK verwiesen. Diese Idee des elektronischen Handbuchs ist eigentlich
auch ganz praktisch, allerdings ist das DOSBOOK nicht ganz frei von
kleinen Fehlern und fehlerhaften Verkn�pfungen, die sich leider wegen
der komprimierten Form des Buches nicht selbst korrigieren lassen.
Auf einer Novell DOS 7 CD-ROM (BHV-Verlag) soll allerdings eine Text-
Version des DOSBOOKs existieren, die damit die nachtr�gliche Bearbeitung
durch den Benutzer (Kommentare etc.) erlauben w�rde (allerdings dann
wieder nicht die Einbindung in DOSBOOK bietet...).
---------------------------------------------------------------------------
IX.2. Das gro�e Buch zu Novell DOS 7 (Data Becker):
===================================================
Autoren : Klemens Mai, Dirk Larisch, H. Tronsdorf, M. Tronsdorf
ISBN : 3-8158-1030-2
Sonstiges: 1. Auflage 1994, 1086 Seiten, 3,5" Diskette, DM 69,-
F�r meine Begriffe die beste Fremddokumentation zu Novell DOS 7. Zwar
enth�lt auch dieses Buch einige kleinere Fehler, kann aber sowohl f�r
absolute Anf�nger als auch f�r DOS-Profis eine st�ndige Referenz neben
dem DOSBOOK sein. Erl�utert DOS-Grundlagen f�r Anwender verst�ndlich
und deckt - bis auf komplett ausgesparte undokumentierte Details und
ganz spezielle Kniffe und Workarounds f�r Freaks - eigentlich das ganze
System (auch PNW) geb�hrend ab. Viele Beispiele aus der Praxis und eine
komplette Kommando�bersicht. Viel Info, �bersichtliches Layout.
Wirkliche Problemf�lle, die auch DOS-Profis zum Verzweifeln bringen
k�nnen, deckt dieses Buch allerdings auch nur am Rande ab (vielleicht zu
viel verlangt von einem Buch). Beschr�nkt sich auf offizielle Eigen-
schaften des Systems, ist darin aber sehr gut.
Der auf der Diskette enthaltene Bildschirmschoner BLACKOUT ist so
unzureichend, da� man ihn getrost vergessen kann (Ersatz z.B. durch
den in den erweiterten Tastaturtreiber K3PLUS/FreeKEYB eingebauten
Bildschirmschoner - zu beziehen �ber mich). Die Oberfl�che TEMPEST 1.0
erinnert leicht an VIEWMAX von DR DOS 6, bietet aber leider nicht eine
direkte Unterst�tzung f�r TASKMAX/TASKMGR. Ob dies in sp�teren Versionen
nachgeholt wurde, ist mir nicht bekannt.
An einer Stelle werden sogar die fr�hen Updates zu Novell DOS erw�hnt
(allerdings mittlerweile v�llig veraltet), was aber darauf schlie�en
l��t, da� dieses Buch nicht ganz in der sonst �blichen Eile produziert
(am besten noch vor Erscheinen des Betriebssystems) publiziert wurde.
Kostet offiziell DM 69,-, wurde aber nach dem Abgang von Novell DOS 7
f�r DM 10,- bis 20,- verrammscht (die sich in jedem Fall lohnen).
---------------------------------------------------------------------------
IX.3. Novell DOS 7 - Das Kompendium (Markt & Technik):
======================================================
Autoren : Kai Hamann, Michael Kolberg
ISBN : 3-87791-556-6
Sonstiges: 10/1994, 750 Seiten, 3,5" Diskette, DM 69,-
Relativ gute Einf�hrung in Novell DOS, deckt die wichtigsten Themen und
alle Hauptbelange des Systems (auch PNW) aus Anwendersicht ab. Enth�lt
relativ wenig Fehler. Recht komplette Kommando�bersicht und einiger-
ma�en �bersichtliches Layout. Spezialthemen (wie z.B. Codeseiten-
Einrichtung) werden nicht behandelt bzw. nur auf das SETUP-Programm
verwiesen.
Enth�lt in einem Anhang auch Tips und Tricks zu Workarounds und un-
dokumentierten Eigenschaften des Systems. Diese Hinweise sind nicht
immer korrekt, nicht vollst�ndig oder gelten nur f�r fr�he Versionen
von Novell DOS. Trotzdem ist dieser Ansatz lobenswert, da durch Anwendung
der Tips teilweise mehr aus dem System herausgeholt werden kann (f�r
Leser *dieser* Datei aber nichts Neues mehr). Besonders lobenswert ist,
da� dieses Buch anscheinend nicht in der sonst �blichen Eile produziert
wurde, sondern tats�chlich einmal Praxiserfahrungen mit einer Final-
Release (und Updates) eingeflossen sind.
Die auf der Diskette mitgelieferten Treiber-Updates zu Novell DOS 7
(06/1994) sind mittlerweile hoffnungslos veraltet. Zus�tzlich enth�lt
die Diskette auch noch einige andere NetWare-Updates, und einige Screen-
shots von Novell DOS Utilities.
Kostet offiziell DM 69,-, wurde aber zuletzt f�r ca. DM 10,- bis 15,-
verrammscht, die sich durchaus lohnen.
---------------------------------------------------------------------------
IX.4. Novell DOS 7 und Personal NetWare (Addison Wesley): [96-05-29]
====================================================================
Autoren : Michael Gerding, Bj�rn Kibbel
ISBN : 3-89319-758-3
Sonstiges: 1. Auflage 1994, 919 Seiten, DM 79,-
Dieses Buch aus der Reihe Software-Klassiker hat bei mir leider keinen so
guten Eindruck hinterlassen.
Obwohl das Buch im Prinzip - wie die beiden anderen B�cher auch - fast
das gesamte System (auch PNW) aus Anwendersicht abdeckt, ist es von den
Beispielen eher f�r absolute Newcomer in DOS geeignet (Wer schon gewisse
Erfahrungen mit DOS hat, kommt sich bei vielen Beispielen und 'wichtigen'
Hinweisen teilweise eher hochgenommen vor). Trotzdem ist es f�r mich
fraglich, ob der absolute Newcomer hier das System in der didaktisch
geeignetsten Form dargeboten bekommt. Die Suche nach detaillierten
Informationen zu einem ganz speziellen Thema ist nahezu unm�glich, da
die Informationen im Rahmen der Einf�hrung weit gestreut sind.
Speziellere Themen wie z.B. Codeseitenunterst�tzung fehlen komplett.
Allerdings mu� man den Autoren zugute halten, da� der Ansatz hier im
Vergleich zu vielen anderen B�chern etwas anders liegt: Die Autoren
versuchen durch Einf�hrungen in die PC-Welt (Geschichte, Hardware,
Software, DOS allgemein, auch Windows-Einf�hrung) eine Allround-
Dokumentation f�r PC-Newcomer zu bieten. Sie gehen auch auf die
externe Version von PNW ein.
Das Layout ist teilweise �u�erst un�bersichtlich und verschwenderisch
zugleich, au�erdem enth�lt dieses Buch wirklich eine extreme Anzahl
von typographischen und sachlichen Fehlern. Vieles wurde anscheinend
ohne �berpr�fung von einem Buch �ber MS-DOS kopiert, viele Parameter
gelten f�r MS-DOS (teilweise sogar nur f�r ziemlich alte MS-DOS Ver-
sionen), nicht f�r Novell DOS. Die Kommando�bersicht ist relativ un-
vollst�ndig (verglichen mit den �bersichten der anderen B�cher), die
Parameter sind nicht alphabetisch sortiert.
Enth�lt auch einige Hinweise auf bei Novell DOS 7 neue oder undokumen-
tierte Eigenschaften und veranla�te mich nach der Suche von versteckten
Features (leider kam dabei nichts Neues heraus), entsprechende Andeu-
tungen im Buch galten also entweder f�r Beta-Versionen von Novell DOS
oder sind schlichtweg falsch.
Aufgrund der Vielzahl der negativen Kritikpunkte (die wohl so ziemlich
jedem Leser aufsto�en werden, sobald er sie bemerkt), stellt sich die
Frage, ob dieses Buch nicht eher ein unfertiges Manuskript war, das viel
zu fr�h in Druck gegangen ist. Mein normalerweise recht positiver Ein-
druck von diesem Verlag hat mich hier doch �u�erst arg entt�uscht.
Kostet offiziell DM 79,-, in Ausverkaufsaktionen f�r ca. DM 20,- zu
haben, die sich m.E. nach f�r etwas erfahrene DOS-Benutzer nicht lohnen.
---------------------------------------------------------------------------
IX.5. Novell DOS 7 - Networking, Multitasking, Systemoptimierung:
======(Addison-Wesley)==============================[97-01-14]===
Autoren : Frank Grieser, Andreas Winterer
ISBN : 3-89319-676-5
Sonstiges: 1. Auflage 1994, 386 Seiten, DM 60,-
Dieses vergleichsweise kompakte Buch besch�ftigt sich entsprechend seinem
Titel im Gegensatz zu den anderen B�chern weniger mit den Einsteiger-
problemen und setzt ein paar System- und Konfigurationskenntnisse voraus
(aber nicht allzu viel).
Die Zusammenstellung hat bei mir einen recht positiven Eindruck hinter-
lassen, und ich denke, das Buch kann in der Praxis gute Dienste erweisen.
Allerdings konnte ich in dem Buch und auf der beiliegenden Diskette -
von BACKUP, RESTORE, HIBUFFERS= und einigen NET.EXE-Optionen abgesehen -
keine Hinweise auf undokumentierte Systemeigenschaften und gr��ere
Fehlerkorrekturen bez�glich Novells eigener Dokumentation entdecken,
wie auf dem R�ckdeckel spektakul�r geworben wurde. Obwohl auch dieses
Buch eine ganze Reihe Fehler enth�lt (die dann allerdings im Novell-
Handbuch meist genauso falsch beschrieben werden), enthielt das Buch
gen�gend Novell DOS spezifische Hinweise, so da� bei mir hier nicht
der Eindruck eines �bereilten 'Updates' eines MS-DOS Buches entstand.
Die beiden auf der Diskette beiliegenden Hypertext-Online-Referenzen zu
Novell DOS Kommandos und NET.EXE (von den Autoren entwickelt auf der
Basis von Davids ReadMe-Compiler) haben mir - trotz der Fehler - gut
gefallen und k�nnen das DOSBOOK in manchen Punkten erg�nzen. Das Update 4
zu Novell DOS, das ebenfalls mitgeliefert wird, ist nat�rlich hoffnungs-
los veraltet...
Ich konnte das Werk k�rzlich als Restposten f�r ganze DM 5,- ergattern,
die sicherlich lohnen, denn auch f�r Leser dieser Datei sind darin
noch einige neue Tips, wenn auch keine neuen undokumentierten Details
enthalten.
---------------------------------------------------------------------------
IX.6. Undocumented DOS (Addison Wesley):
========================================
Autoren : Andrew Schulman, Ralf Brown, David Maxey, Raymond J. Michels,
Jim Kyle
ISBN : 0-201-63287-X
Sonstiges: 2. Auflage, US $44.95, ca. DM 118,-, 856 Seiten, 3,5" Diskette
Kein Buch f�r Anwender, stattdessen ein absolutes Mu� f�r ernsthafte DOS-
und Windows-Programmierer. Die zweite Ausgabe enth�lt auch erste Hinweise
zu Novell DOS 7 Features (war noch im Beta-Stadium), obwohl haupts�chlich
MS-DOS Interna beschrieben werden (die aber fast komplett auch f�r
Novell DOS 7 gelten). Sehr gut geschrieben, deckt viele Zusammenh�nge
�u�erst plastisch auf. Leicht verst�ndliches Englisch.
Viele Details der ersten Ausgabe sind in das leider mittlerweile
vergriffene, aber nach wie vor �u�erst empfehlenswerte Buch 'DOS 5 f�r
Programmierer - Die endg�ltige Referenz' von Arne Sch�pers eingeflossen
(der auch ausf�hrlich auf DR DOS 3.41 und 5.0 eingeht), die zweite
Ausgabe von 'Undocumented DOS' enth�lt aber wiederum viele Informationen
aus diesem Buch bez�glich der DR DOS Spezifika. Neben einer Vielzahl
sinnvoller Programmiertools ist auf der Diskette die Interrupt-Liste
von Ralf Brown enthalten, die aber mittlerweile in einer erheblich ver-
besserten und erweiterten Form �ber das Internet zu beziehen ist (siehe
Bezugshinweis am Beginn dieses Dokuments).
Wie gesagt, f�r Anwender v�llig ungeeignet, f�r Programmierer ein Mu�.
---------------------------------------------------------------------------
IX.7. DOS 5 f�r Programmierer - Die endg�ltige Referenz (Addison Wesley):
============================================================[97-01-03]===
Autor : Arne Sch�pers
ISBN : 3-89319-350-2
Sonstiges: 1. Nachdruck 1991, DM 99,-, 1123 Seiten, 360 KByte 5.25" Disk
Ebenfalls ein Buch 'for programmers only'. Auch wenn mittlerweile reich-
lich betagt (nach meinem Kenntnisstand ist auch keine Neuauflage mehr
zu erwarten (Wer interessiert sich schon noch f�r DOS??? Na, Sie - wenn
Sie tats�chlich dieses Dokument bis hierhin durchgelesen haben! ;-) ),
bleibt dieses Buch auch neben der 2. Auflage von Undocumented DOS ein
essentieller Fundus f�r DOS-Interna, der ausf�hrlich auf MS-DOS bis 5.0
und DR DOS 3.41 und 5.0 eingeht. Da vieles - wenn auch lange nicht
alles - DR DOS-Spezifische auch f�r Novell DOS 7 gilt, sehr empfehlens-
wert. Allerdings enth�lt auch dieses Buch einige massive sachliche Fehler
oder Fehlschl�sse (nun, wer im Glashaus sitzt, sollte nicht mit Steinen
werfen, sorry ;-) ), aber die Unzahl von Beispielprogrammen zu allen
DOS-Funktionen entsch�digen wirklich mehr als gut daf�r!
Als Restposten teilweise f�r gut angelegte DM 15,- zu ergattern.
---------------------------------------------------------------------------
IX.8. Weitere Literatur: [97-02-26]
===================================
Bemerkung: Der Vollst�ndigkeit halber eine einfache Auflistung...
Da mir die Mehrzahl der B�cher nicht vorliegt, meist
ohne irgendeine Wertung...
- "Einsteigerseminar - Novell DOS 7"
bhv, 1994, 427 Seiten, DM 20,-
ISBN 3-89360-735-8
- "Novell DOS 7" (H. Mehlig, J. Wa�ermann)
Rowohlt, 1994, 430 Seiten, DM 23,-
ISBN 3-499-19814-2
- "Novell DOS 7 und Personal NetWare optimal einsetzen"
(B. Kibbel, B. Kretschmer, Herausgeber: Haselier???, Fahnenstich)
Econ & Addison-Wesley, 1994, 363 Seiten, DM 20,-
ISBN 3-612-28047-3
Bemerkung: Wirkt teilweise wie eine Kurzfassung des Buches aus IX.4.
und enth�lt genauso falsche Informationen �ber angebliche
Aufrufoptionen bestimmter Novell DOS 7 Tools (ein paar
Beispiele FASTOPEN, NWCACHE etc.), die eigentlich eher f�r
MS-DOS gelten.
- "Novell DOS 7 Unleashed" (Jonathan Kamin)
Sams, 03/1994, 808 Seiten + 3,5" Disk, DM 95,- / f 79,- / $ 40,-
ISBN 0-672-30328-0
Bemerkung: Englischsprachiges Buch �ber die US-Version von Novell DOS
- "Using Novell DOS 7" (King, Harper, Langley)
Que Corp., 1994, 841 Seiten, f 65,-, $ 30,-
ISBN 1-56529-104-2
Bemerkung: Englischsprachiges Buch �ber die US-Version von Novell DOS
- "Inside Personal NetWare" (Dorothy Cady)
NRP, 1994, $ 25,-, DM 70,-
ISBN 1-56205-232-2
Bemerkung: Englischsprachiges Buch �ber die US-Version von Personal
NetWare in Verbindung mit Novell DOS 7, DR DOS, MS-DOS
Windows und OS/2 mit einem eindeutigen Schwerpunkt auf der
recht detaillierten Beschreibung von Personal NetWare.
Beschreibt auch viele Praxisl�sungen.
- "Novell DOS 7: Memory Management, Multi-Tasking, Networking,
and Data Protection" (Brian Underdahl)
John Wiley & Sons, 12/1993, $ 23,-, 326 pages
ISBN 0-471-01629-2
- "Bright Books: Novell DOS versie 7"
Addison Wesley NL, 1994, f 15,-
ISBN 90.6789-467.2
Bemerkung: In niederl�ndischer Sprache
- "Novell DOS 7 Handboek" (van Bedem)
Addison Wesley NL, 1994, f 60,-
ISBN 90.6789-400.1
Bemerkung: In niederl�ndischer Sprache
- "Werken met Novell DOS 7" (de Jong)
Sybex Nederland, 1993, f 70,-
ISBN 90.5160-633.8
Bemerkung: Dieses niederl�ndische Buch behandelt angeblich auch
Windows NT???
- "Das gro�e DR DOS 6.0 Buch" (H. Tornsdorf, M. Tornsdorf)
Data Becker, 1991, 1003 Seiten, DM 59,-
ISBN 3-89011-510-1
Bemerkung: Der Vorl�ufer von "Das gro�e Buch zu Novell DOS 7" (siehe
IX.2.) enthielt eine Reihe Hinweise zu DR DOS 6.0, die zwar
auch noch f�r Novell DOS 7 interessant sind, im Nachfolge-
band aber - wohl aus Platzgr�nden - nicht ber�cksichtigt
wurden. Enth�lt auch einige kleinere Fehler.
Das folgende englische Buch war angek�ndigt, wurde aber offenbar nie
ver�ffentlicht:
- "Novell DOS 7: Instant Reference", evtl. auch
"Novell's Guide to Novell DOS 7.0"
Novell Press/Sybex, 08/1995, $30,-
ISBN 0782114075
Bemerkung: Wahrscheinlich sollte es sich hierbei um eine gedruckte
Fassung der oben erw�hnten Tutorials zu Novell DOS 7
handeln.
---------------------------------------------------------------------------
IX.9. c't/iX Artikel: [97-02-12]
================================
Autoren : div.
Sonstiges: c't - magazin f�r computertechnik, Heise Verlag, Hannover
Dieser �berblick soll nur stichwortartig die mir bekannten c't-Artikel
zum Thema 'Novell DOS' (und Vorg�ngern) behandeln, und erhebt alles
andere als den Anspruch auf Vollst�ndigkeit. Trotzdem m�chte ich noch
einmal darauf hinweisen, da� die in diesem Dokument wiedergegebenen
Fakten nicht auf den genannten Artikeln basieren, sondern auf meinen
eigenen Erfahrungen. Nat�rlich habe ich die Informationen - wo immer
m�glich - gegeneinander abgeglichen.
- "Taskdynamik"
DESQview und Concurrent DOS unter Novell (Detlef Borchers)
iX 04/1989, S. 40
Stichworte: DR Concurrent DOS, 'review'
- "Sp�tlese"
Digital Researchs MS-DOS-Alternative (Marcus Gr�ber, Bert Ungerer)
c't 03/1990, S. 172
Stichworte: 'review', DR DOS 3.41
- "Neues altes DOS"
DR-DOS 5.0 steht vor der Markteinf�hrung (Bert Ungerer)
c't 07/1990, S. 31
- "Raum f�r DOS"
Vier virtuelle Speichermanager f�r 386er (Dr. Reinhard Ellinghaus)
c't 12/1990, S. 130
Stichworte: EMS, 386ToTheMAX, BlueMax, QEMM-386, DR-DOS 5.0, Turbo EMS
- "Belebende Konkurrenz"
DR DOS 6.0 mit neuen Features (Bert Ungerer)
c't 10/1991, S. 25
Stichworte: 'aktuell'
- "DOS to the max"
DR DOS 6.0 mit vielen Utilities (Marcus Gr�ber)
c't 11/1991, S. 96
Stichworte: 'review'
- "Die Alternativen"
PC-Betriebssysteme neben dem Standard (Detlef Borchers)
c't 06/1992, S. 58
Stichworte: Prologue, Theos, L3, PC-MOS, Multiuser-DOS, DESQview
- "Verstohlene Seitenblicke"
Der Interrupt 21h beim DOS-Bootvorgang (Harald Milz)
c't 07/1992, S. 198
Stichworte: TSR-Programme & Ger�tetreiber, CONFIG.SYS, Booten,
DRDOS, PCDOS, MSDOS
- "Just in Time"
Echtzeit-Betriebssysteme, Teil 2: Marktreport (Arno Keppke)
c't 09/1992, S. 202
Stichworte: u.a. FlexOS
- "Leichtnetz mit Anhang"
Netware Lite v1.1 im Paket mit DR DOS (Bert Ungerer)
c't 12/1992, S. 124f.
Stichworte: DR DOS 6.0, Netware Lite, Novell, 'kurz vorgestellt'
- "Die wahre DOS-Version"
DOS-Versionsermittlung im Detail (Matthias Wolf)
c't 02/1993, S. 106
Stichwort: reale DR DOS Versionen
- "Knackpunkt"
PCs contra Datensicherheit: Das Beispiel DR DOS (Mark Torben Rudolph)
c't 03/1993, S. 130ff.
Stichworte: DEL, FORMAT, PASSWORD, LOGIN, UNDELETE, DISKMAP, DELWATCH,
DELPURGE, LOCK, COMPRESS, SuperStor, DR DOS 6.0
- "Ableger im Aufwind"
Frankfurter NetWorld findet Anklang (Bert Ungerer)
c't 07/1993, S.20
Stichworte: Novell DOS 7 Ank�ndigung, 'aktuell'
- "Netz-DOS"
Novell DOS 7 kurz vor der Fertigstellung (Bert Ungerer)
c't 09/1993, S. 30f.
Stichworte: Beta, Multitasking, 'aktuell'
- "DOS novellieren?"
Novell DOS 7 fordert PC- und MS-DOS heraus (Bert Ungerer)
c't 03/1994, S. 74ff.
Stichworte: PC-DOS 6.1, MS-DOS 6.20, PNW, STACKER, DBLSPACE, SuperStor,
'report'
Bemerkung: Interessanter Vergleich der Funktionalit�t der drei
zu diesem Zeitpunkt aktuellen DOS Betriebssysteme. Das
Fazit ist ziemlich eindeutig...
- "Ziffernlifting"
IBMs PC-DOS 6.3: Fast alles beim alten (Bert Ungerer)
c't 04/1994, S. 28
Stichworte: Novell DOS 7, PC-DOS 6.3, MS-DOS 6.21 und 6.22, CeBIT,
'aktuell'
- "Nat�rlich undokumentiert"
Novells Personal Netware unter OS/2 (Dieter Brors)
c't 07/1994, S. 176f.
Stichworte: IBM OS/2 2.11, PNW, Peer-to-Peer, HPFS, DPMS, NWCACHE,
DOS-Box, NET.CFG: Netware DOS Requester OS2=on
Bemerkung: Da ich diesbez�glich noch keine Erfahrungen gesammelt habe,
verweise ich f�r Novell DOS 7 & PNW unter OS/2 auf diesen
Artikel, der sich allerdings mit dem mittlerweile
veralteten OS/2 2.11 besch�ftigt. Weitere Hinweise zu
Novell DOS 7 unter/mit OS/2 gibt es auch in den Dokumenten
von Novells FaxBack-Systems, das zusammengefa�t auch in
dem am Anfang erw�hnten Archiv ND7TID.EXE verf�gbar ist.
- "Licht und Schatten"
Ein kritischer Blick auf Novell DOS 7 (Arne Sch�pers)
c't 08/1994, S. 193ff.
Stichworte: DPMI, DPMS, �bertragungsraten, Windows, Updates, APIs,
Undokumentiertes, DR DOS, Probleme, DBLSPACE
Bemerkung: Die allermeisten der in diesem Artikel beschriebene Pro-
bleme (Update 4) geh�ren mittlerweile (Update 15) der
Vergangenheit an; Novell war trotz eingestellter Weiter-
entwicklung in den vergangenen 1,5 Jahren nicht unt�tig...
Trotzdem ist die Lekt�re (wie bei den meisten Artikeln
und B�chern von Arne Sch�pers) interessant, auch wenn
Novell DOS hier nicht besonders gut abschneidet, was
zwar in manchen Punkten gerechtfertigt ist, in anderen
Punkten jedoch eine klare Frage des Standpunktes ist
(meinen sollten Sie ja inzwischen auch kennen...).
- "Watteweicher Kompromi�"
Microsoft einigt sich mit Kartellbeh�rden (Ingo T. Storm, Sabine Dutz)
c't 09/1994, S. 16
- "Fertigserver"
Zeniths Z-Stor mit vorkonfigurierter Personal NetWare (Bert Ungerer)
c't 09/1994, S. 72
- "Virtuelle Einrichtung"
Konfigurationstips f�r Novells DOS-Requester (Bert Ungerer)
c't 09/1994, S. 194
Stichworte: Netze, VLMs, Novell DOS 7, NET.CFG, LAN, Personal NetWare
- "Novell kippt DOS 7"
Netz-Marktf�hrer konzentriert Aktivit�ten (Ralf H�skes)
c't 11/1994, S. 16
Stichworte: Novell DOS 7 & Personal Edition UnixWare eingestellt,
AppWare und WordPerfect, Super NOS, NetWorld+InterOp,
'Markt'
Bemerkung: No comment!
- "Vobis und Escom setzen auf OS/2"
MS Windows gibt es nur noch gegen Aufpreis (Christian Persson)
c't 12/1994, S. 16
Stichworte: OS/2 3.0 Warp, Microsoft Chicago/Windows95, Novell DOS 7
Bemerkung: Hat zwar nicht lange funktioniert (die Mark siegt), hat
aber mal wieder die Grundproblematik mit Microsoft als
Software-Monopolisten deutlich vor Augen gef�hrt. Ohne
'Abweichler' wird die Lage bestimmt nicht besser...
- "Novell DOS l�hmt CD-ROM"
c't 06/1995, S. 244
Stichworte: MS-DOS 6.2, CD-ROM, MSCDEX, NWCDEX, SMARTDRV, NWCACHE,
'Hotline'
- "Misch-DOS"
IBM PC-DOS profitiert von Novell DOS (Alexander Hoch)
c't 09/1995, S. 210f.
Stichworte: PC-DOS 7.0, Novell DOS 7, DPMS, STACKER, NWCACHE, NWCDEX
- Nachtrag zu "Misch-DOS"
c't 10/1995, S. 11
Stichworte: NWCACHE, Update 14, 'Erg�nzungen + Berichtigungen'
- "Windows95: altes DOS f�r neues Windows" (Peter Siering)
c't 05/1996, S. 284f.
Stichworte: Beschreibt das ge�nderte Boot-Verhalten von MS-DOS 7 und
wie man unter Windows95 ein altes MS-DOS/PC-DOS bootf�hig
macht und, da� dieses mit Novell DOS 7 nicht funktioniert
(w�re bei Microsoft ja auch nicht anders zu erwarten ge-
wesen). [Mit einigen kleinen Patches m��te es meiner
Meinung nach trotzdem funktionieren, allerdings tut's ja
auch der OS/2- oder PTS/Boot-Manager], 'Hotline'
- "Frontal gegen Microsoft"
DR-DOS-K�ufer reicht Antitrust-Klage ein (Christian Persson)
c't 09/1996, S. 16
Stichworte: �bernahme von Novells "DR DOS" durch Caldera Inc.,
Raymond J. Noorda, Bryan Sparks, Antitrust-Klage
- "Laokoons Enkel"
Windows NT 4.0 und die Konkurrenz im Netzwerk (J�rgen Kuri)
c't 09/1996, S. 148ff.
Stichworte: PNW
Bemerkung: Geht am Rande auf Novells Politik der letzten Jahre ein.
Hat nicht direkt etwas mit Novell DOS zu tun.
- "Der Kolo� von Provo"
Windows NT versus Novell NetWare (Axel Kossel)
c't 09/1996, S. 160
Bemerkung: Geht auf Novells Stellung im Markt ein. Hat nicht direkt
etwas mit Novell DOS zu tun.
- "Anschlu� gesucht"
30 PCI-SCSI-Hostadapter im Vergleich (Georg Schnurer)
c't 09/1996, S. 218ff.
Bemerkung: Beschreibt, da� die EMM386-Speichermanager von "DR-DOS 7.x"
(und PC-DOS 7) im Gegensatz zu MS-DOS bis 6.21 keine Pro-
bleme mit dem PCI-Bus (bei Speicher-Ressouren oberhalb des
ersten MegaByte) hatten (in Wahrheit hatten selbst einige
Versionen von 6.22 noch Probleme mit PCI-Boards, erst der
Treiber aus MS-DOS 7 half hier).
- "Dschungelbuch"
Novell stellt IntranetWare vor (J�rgen Kuri)
c't 11/1996, S. 98ff.
- "Des Kaisers neue Kleider"
Novell sucht Antworten auf die Fragen nach der Zukunft von NetWare
(Detlef Borchers)
c't 03/1997, S. 48ff.
Bemerkung: Beschreibt u.a. die Einf�hrung von IntranetWare FSB (for
Small Business), das als Nachfolger von Personal NetWare 1.0
und NetWare 3.xx angesehen werden kann. F�r Personal
NetWare, NetWare, Novell DOS u.a. gibt es relativ g�nstige
Upgrades. Au�erdem gibt der Artikel ein paar Hintergrund-
infos �ber die �ra Raymond Noorda und Novells neuen Kurs.
---------------------------------------------------------------------------
IX.10. Andere Zeitschriftenartikel: [96-09-04]
==============================================
[Weitere, hier noch nicht verzeichnete Artikel zum Thema sind, z.B. in
Form einer Kopie, sehr willkommen.]
- "Neue DOS-Betriebssysteme"
Markt, Macht und Betriebssysteme - Novell DOS 7.0 contra MS-DOS 6.2
DOS 03/1994, S. 130ff.
Stichworte: Multitasking, Netz, DPMS, Windows
Bemerkung: Interessanterweise stimmt das Fazit haargenau mit dem aus
c't 03/1994 �berein...
- "66 Tips f�r Novell DOS" (Kai Hamann, Michael Kolberg)
Computer Pers�nlich, 06/1994
Bemerkung: Ein Abdruck dieser Tips wurde auch mit IX.3. publiziert.
- "Novell DOS 7: Is It Time to Switch?" (Steve Kalman)
Unbekanntes Computermagazin??? 03-04/1994, S. 32-35
- "Novell: Kapitulation vor der Windows-Dominanz"
PC-Welt, 11/1994, S. 14
Rubrik : Aktuell; Windows, DOS und OS/2
Stichworte: "The war is over". Novell Mitarbeiter finden DOS nur noch
f�r PDA (pers�nliche digitale Assistenten) attraktiv...
- "Novell DOS - �bereifriger Cache"
PC-Welt, 11/1994, S. 31
Stichworte: Beschreibt den Sch�nheitsfehler in der Statistik von
NWCACHE /S, wenn "VERIFY on" ist. Wurde mit einem Update
behoben.
- "Wegen Windows: Novell DOS stirbt"
PC-Welt, 11/1994, S. 55f.
Rubrik : Aktuell; Vorstellung Software
Stichworte: Ab sofort Schmusekurs mit Microsoft; zu diesem Zeitpunkt
allein in Deutschland 700.000 verkaufte Novell DOS 7
Lizenzen
Bemerkung : (das war noch vor dem gro�en Preisrutsch...).
- "Peer-to-Peer Netz: Mini-Netz mit alten Rechnern (mit Novell DOS 7)"
PC-Welt, 12/1994, S. 315f.
Bemerkung : Beschreibt grob die Einrichtung eines PNW-Netzes.
---------------------------------------------------------------------------
IX.11. Interessante Web-Sites bez�glich Novell DOS: [97-04-21]
==============================================================
[Weitere Web-Sites bez�glich Novell DOS und Caldera OpenDOS finden
sich in Kapitel I.]
- "Novell DOS - Erste Erfahrungen" (Willibald Klein)
URL: http://www.rz.uni-sb.de/rzinfo19/novell.html
WWW-Artikel aus dem Magazin RZ-Info 19 (1994) der Stelle f�r
�ffentlichkeitsarbeit der Uni des Saarlandes; entspricht
weitestgehend meinen Erfahrungen. [05/1996]
- "Pflege eines PNW-Servers" (Willibald Klein, Bernhard Stumpf)
URL: http://www.rz.uni-sb.de/rzinfo20/rz20s491.html
WWW-Artikel aus dem Magazin RZ-Info 20 (1994) der Stelle f�r
�ffentlichkeitsarbeit der Uni des Saarlandes. [10/1996]
- "Multitasking and Networking build into Novell DOS 7" (Scott Fletcher)
URL: http://tcp.ca/May/NovellDOS7.html
WWW-Artikel, entspricht weitestgehend meinen Erfahrungen. [05/1996]
- "Novells Newest DOS" (Terje Mathisen)
URL: http://www.byte.com/art/9406/sec9/art7.htm
WWW-Dokument entspricht dem BYTE-Artikel 06/1994 in der Rubrik "Review"
und beschreibt eine Reihe der positiven und negativen Erfahrungen mit
einer - seltsamerweise trotz des Datums - offenbar sehr fr�hen US-
Ausgabe von Novell DOS 7 (wohl fast noch Beta-Stadium). [10/1996]
- "Voyager - Novell DOS 7" (Alexander Walz)
URL: http://www-users.informatik.rwth-aachen.de/~afw/nwdos7.html
Zusammenfassender WWW-Artikel �ber Geschichte und Funktionsumfang von
DR DOS und Novell DOS. [10/1996]
Ist derzeit nicht mehr im Angebot... [02/1997]
- "Digital Research - The untold story: The story behind the story"
URL: http://www.ctyme.com/dri.html
"The 07-21-91 Summary: How the Novell buyout of Digital Research
started"
URL: http://www.ctyme.com/dri1.html
"The NovOS spec: The original written proposal of NovOS to Novell"
URL: http://www.ctyme.com/dri2.html
"Letters to Ray Noorda about NovOS"
URL: http://www.ctyme.com/dri3.html
(Marc Perkel, Computer Tyme)
Verschiedene interessante Dokumente eines hemmungslosen Vision�rs
�ber die Hintergr�nde zu Novells Aufkauf von Digital Research
(1991) und �ber das, was aus "Novell DOS" noch alles h�tte werden
k�nnen...
Marc Perkel nimmt darin f�r sich in Anspruch, Novell von der Idee
einer ob seiner Features, Flexibilit�t und Zukunftssicherheit
konkurrenzlosen Alternative zu MS-DOS, MS Windows usw. begeistert
zu haben und die erste Spezifikation daf�r geliefert zu haben. Von
Digital Researchs DR DOS als Grundlage f�r dieses "NovOS" war dabei
zun�chst gar nicht die Rede...
Im weiterem Verlauf der Dinge sei er dann von Novell regelrecht
'ausgebootet' worden, was wohl auch der Beweggrund f�r die Ver-
�ffentlichung dieser Seiten war.
Gleichzeitig d�rfte dies auch eine der Quellen f�r die lange Zeit
anhaltenden Ger�chte gewesen sein, da� Novell ein eigenes Super-
Betriebssystem mit GUI etc. entwickeln wollte (aber wohl auch
vom 'Corsair'-Projekt und X/GEM angeheizt). [06/1996]
Vielleicht sind einige der besonders spitzen Bemerkungen mit der
�bernahme von DR DOS durch Caldera �berholt, aber urteilen Sie
selbst... [08/1996]
Mittlerweile sind diese provokaten Seiten leider wieder von
Internet verschwunden (vermutlich hat auch Marc Perkel die
j�ngsten Entwicklungen positiv eingesch�tzt); an den Hintergr�nden
besonders Interessierte k�nnen die Dateien auf Anfrage aber auch
noch von mir beziehen. [10/1996]
- "Concurrent Control, Inc. - Multiuser DOS 7 Gold"
URL: http://www.conctrls.com/gold.htm
URL: http://www.conctrls.com/f-why.htm
Diese Firma - ein ehemaliger Master VAR von DR Multiuser DOS -
vertreibt nach wie vor Multiuser DOS 7 Gold und CCI Concurrent DOS,
die auf DR Concurrent DOS und DR Multiuser DOS basieren. Derzeit
wird eine am 1997-02-10 freigegebene kostenlose Demo-Version von
Multiuser DOS 7.22 Gold zum Download angeboten. Interessanterweise
gehen dabei einige Novell-Copyrights bis ins Jahr 1996. [03/1997]
- "Logan Industries, Inc."
URL: http://www.lii.com/
Diese Firma vertreibt in den USA das Echtzeit-System IMS REAL/32 (seit
der Version 7.50+ der neue Name f�r das ehemalige IMS Multiuser DOS)
des englischen Entwicklers IMS, ebenfalls ein Abk�mmling der alten
DR Multiuser DOS Linie. Offenbar basiert das System zum Teil auch auf
Quellen fr�her Novell DOS-Ausgaben, etwa ist der IMSCDEX.EXE Treiber
ein Abk�mmling des NWCDEX.EXE v1.00. Interessant ist, da� das als
�u�erst stabil angesehene Multitasking-/Multiuser-System in der Lage
ist, neben normalen DOS-, DR DOS- und Multiuser DOS- alias CP/M-86-
Anwendungen auch mehrere Sessions von Windows 3.xx gleichzeitig zu
fahren, bei voller Anbindung an diverse Netze, wie z.B. NetWare und
Abk�mmlinge des alten DR Net. [03/1997]
- "Microsoft faces antitrust suit over DR DOS"
URL: http://biz.yahoo.com/bin/jump?/finance/96/07/24/msft_2.html
URL: http://www.online.reuters.com/.../jump
Reuters [08/1996]
- "Microsoft hit with antitrust suit" (Mike Ricciuti, 1996-07-24)
URL: http://www.cnet.com/Content/News/Files/???/cnet.clp
CNET Inc. [08/1996]
- "Noorda's new company acquires DR-DOS, sues Microsoft"
(Maria Seminerio & Charles Cooper)
URL: http://www.pcweek.com/news/0722/24esuit.html
URL: http://www.zdnet.com/plweb-cgi/pcweek/.../24esuit.html
PC WEEK, Ziff Davis Publishing [08/1996]
- Web-Server der Caldera Inc., Provo, Utah [08/1996-05/1997]
URL: http://www.caldera.com/
URL: http://www.caldera.com/dos/
URL: http://www.caldera.co.uk/
URL: http://caldera.co.uk/
Der Web-Server der Caldera Inc. ist insofern sehr interessant f�r
Novell DOS 7 Benutzer, als da� Caldera in 07/1996 alle Rechte an
der ehemaligen Digital Research Betriebssystempalette von Novell
�bernommen hat, u.a. zu dem Zweck, das Betriebssystem DR DOS (alias
Novell DOS) inklusive Personal NetWare, jedoch um Internet-F�hig-
keiten, TCP/IP und eventuell sogar ein GUI bereichert unter dem Namen
Caldera OpenDOS wieder auf den Markt zu bringen. Die englische Fassung
von Caldera OpenDOS 7.01 ist am 1997-02-03 freigegeben worden und
kann - f�r Ausbildungsst�tten, Studenten und Sch�ler kostenlos - auf
Calderas Web-Server bezogen werden kann. Allerdings entspricht diese
Fassung zu noch fast 100% dem Novell DOS 7, siehe Kapitel I.5.
Der Name ist auch gleich Programm, denn Caldera begann am 1997-04-21
mit der Pre-Release der Quellen des Caldera OpenDOS 7.01 Kernels
damit, nach und nach die Quelltexte von OpenDOS und nat�rlich
auch der Betriebssysteme CP/M, DOSPlus, DR DOS, DR PalmDOS,
DR Concurrent DOS, DR Multiuser DOS und Novell DOS (von GEM war
in diesem Zusammenhang bislang nicht die Rede) im Internet �ffentlich
zug�nglich machen (abgesehen von den Quelltexten der Zuk�ufe), um so
einer breiten Masse ein fundiertes, sicheres Betriebssystem-KnowHow
zu vermitteln und dadurch der weiteren Entwicklung von DOS-Programmen
eine solide Basis zu verschaffen (keine undokumentierten Details mehr;
nach dem alten Unix-Motto "Use the Source, Luke!" ist die bestm�gliche
Dokumentation der Quelltext).
Nat�rlich bleiben die Quelltexte auch weiterhin unter dem Copyright von
Caldera (ein wesentlicher Unterschied zu FreeDOS oder Linux, die unter
der GPL, der "GNU General Public License" stehen), k�nnen aber f�r
eigene kommerzielle Produkte lizensiert werden. Caldera will auch
mit dem FreeDOS-Team zusammenarbeiten.
Da� dieses fortschrittliche Konzept funktionieren kann, zeigt die
Entwicklung des FreeWare-Unix Linux, f�r das Caldera ihren CND (jetzt
COL) anbieten, nur zu gut. Bleibt zu hoffen, da� das Beispiel Schule
macht und eine generelle Trendwende in der Betriebssystementwicklung
einleitet.
Der DOS-Markt ist zwar kein zukunftsorientierter Massenmarkt mehr
(zumindest nicht bez�glich der 'Innovationsfreude' bei den bisherigen
DOS-Versionen), eine kleine Firma wie Caldera k�nnte aber auch in
Zukunft ganz gut davon leben, wenn erst einmal alle anderen DOS-
Hersteller ihre Entwicklung endg�ltig eingestellt haben (Microsoft
d�rfte kein Interesse mehr an einer Weiterentwicklung von MS-DOS
haben; und wenn, dann ist es *jetzt* zu sp�t; sie werden wohl kaum
die Quellen von MS-DOS & MS Windows zur freien Verf�gung stellen).
Anbetracht der Langlebigkeit l�ngst totgesagter Betriebssysteme
(man vergegenw�rtige sich beispielsweise einmal das starke Echo in
CP/M-Newsgroups!!!) und der bei Weitem nicht 'so' weit (wie oft
pauschal angenommenen) fortgeschrittenen globalen Durchdringung der
Gesellschaft mit Computern neuster Bauart (siehe Ost-Europa, Mittel-
Asien und Afrika) k�nnte sich bei weltweitem Vertrieb aus dem
horizontalen DOS-Markt ein lukrativer vertikaler Nischenmarkt auftun,
in dem durchaus noch langfristig Innovation m�glich ist. Die N�he zu
Unix (Linux) ist dabei nur eine m�gliche Entwicklungsrichtung.
In jedem Fall hat eine Fortentwicklung von DOS und die *sinnvolle*
Einbettung in moderne Betriebssystemkonzepte den unschlagbaren Vorteil,
da� das geistige Potential und der Erfahrungsschatz von vielen tausend
DOS-Profis und die Investitionen von Millionen DOS-Benutzern nicht
pl�tzlich wertlos werden (sog. Migration Path); ein Ansatz, den
zumindest ich mir schon seit Jahren sehnlichst gew�nscht habe...
Der Server enth�lt ausf�hrliche Infos bez�glich Calderas wiederauf-
gerollter Antitrust-Klage gegen Microsoft als Monopolisten, sowie
diesbez�gliche Pressemitteilungen und best�tigt viele der Fakten,
die ich auch aus vielen anderen Quellen erfahren habe und die sich -
was Betriebssystem-Interna angeht - auch mit meinen pers�nlichen
Erfahrungen decken.
###########################################################################
###########################################################################
Converted to HTML by TXT2HTML (�Thomas Antoni), 29.06.2011, 17:35:56 |