MSDOSTIP.TXT
Tipps für den Umgang mit MS-DOS 5.0 - 7
Copyright (C) 01/1994-05/1997 bei Matthias Paul
Letzte Änderung: 1997-05-01
Ich übernehme keine Gewähr für die Richtigkeit der Informationen.
Jegliche Haftung für Schäden etc. ist ausgeschlossen.
Die Mehrzahl dieser Hinweise bezieht sich auf MS-DOS 6.2x und MS-DOS 7.
Einige der Bemerkungen gelten auch für andere DOS-Versionen (ab 2.xx+).
---------------------------------------------------------------------------
Überblick:
==========
1. Label in Batchjobs
2. PATH-Befehl und Variable
3. Vergleiche in Batchjobs
4. Spezielle Umgebungsvariablen von MS-DOS
5. DBLSPACE-Festplattenkompressor-Workaround
6. Undokumentierter Befehl TRUENAME
7. Undokumentierter Parameter /MBR von FDISK
8. Hinweise zu DBLSPACE/DRVSPACE
9. CONFIG.SYS: Undokumentiertes und Unbekanntes zum Experimentieren
10. XCOPY/MCOPY von MS-DOS 3.2
11. Fehlverhalten von MS-DOS XCOPY
12. EMM386 und PCI-Mainboards
13. Neue interne Kommandos von MS-DOS 7.0 (Windows95)
14. Problem mit CALL in MS-DOS COMMAND.COM bei Batchjobs mit Umleitung
15. Undokumentierte Parameter externer Kommandos
16. Unveränderbare Volume-Labels mit LABEL
---------------------------------------------------------------------------
1. Label in Batchjobs: [96-09-25]
=================================
Der Batchprozessor von MS-DOS 6.2 unterscheidet Labels/Marken nur noch
anhand der ersten 8 Buchstaben. Bei MS-DOS 5.0 waren offenbar noch 10
Buchstaben möglich.
Hatte man vorher längere Labels verwendet, die sich in den ersten 8
Buchstaben nicht unterschieden, so kann dies nun dazu führen, daß sich
diese Batchjobs 'aufhängen', weil sie immer wieder die falschen Sprung-
ziele anspringen und so Endlosschleifen bilden (Abbruch mit <Ctrl>+<c>
bzw. <Ctrl>+<Break>).
Deshalb müssen Labels so gekürzt oder modifiziert werden, daß sie
sich innerhalb einer Batchdatei eindeutig in den den ersten 8 Buchstaben
unterscheiden!
---------------------------------------------------------------------------
2. PATH-Befehl und Variable: [96-11-29]
=======================================
Die Option /E, die mit der Version MS-DOS 6.0 für den Befehl PATH
eingeführt wurde, wurde mit MS-DOS 6.2 wieder aufgegeben. Die Option
mußte bei MS-DOS 6.0 gesetzt werden, um die PATH-Einstellung auch im
Environment (der Umgebung) repräsentiert zu haben. Vor MS-DOS 6.0 war
dies - genauso wie jetzt wieder - generell der Fall. Daher kann man
die Einstellung des Befehls PATH also auch über SET Path= und %Path%
ändern, was besonders dann praktisch ist, wenn man innerhalb der
AUTOEXEC.BAT die PATH-Liste nicht mit einem Schlag definiert, sondern
erst nach und nach ergänzt (weil dies weniger Umgebungsplatz für TSRs
kostet).
Will man die Maximallänge von PATH überschreiten, so kann man weniger
wichtige Pfade in APPEND aufnehmen (Verwendung von /E, um %Append% im
Environment zu repräsentieren, /X:on für erweiterte Funktionalität).
Mit APPEND /X:off und APPEND /X:on kann nun ein erweiterter Pfad aus-
und eingeschaltet werden. Allerdings ist dieses Verfahren mit Vorsicht
zu genießen, da manche Programme mit APPEND nicht sehr gut zurechtkommen
(das liegt an der *eigentlichen* Funktion dieses Befehls). Außerdem
schlägt APPEND bei MS-DOS mit unverschämten 9 KByte Basisspeicher zu
Buche.
Seit MS-DOS 6.0 gibt es noch eine andere Möglichkeit, die Maximallänge
von 128 Zeichen in PATH und APPEND zu überschreiten: Wie von DR DOS und
Novell DOS schon lange bekannt, ist es jetzt auch bei MS-DOS möglich,
Umgebungsvariablen bereits in CONFIG.SYS zu setzen. Dies geschieht
genauso wie in AUTOEXEC.BAT:
SET path=...
(Zumindest bei DR DOS 6.0, Novell DOS 7 und Caldera OpenDOS können diese
Zeilen bis zu 255 Zeichen lang sein.)
Allerdings ist eine Abfrage in CONFIG.SYS in der Form %Path% nicht
möglich, die Einträge werden gesammelt und erst beim Laden von
COMMAND.COM aufgebaut (d.h. vor AUTOEXEC.BAT, aber nach CONFIG.SYS).
---------------------------------------------------------------------------
3. Vergleiche in Batchjobs - Bug? (MS-DOS 6.2): [96-09-25]
==========================================================
Anscheinend hat der Batchprozessor in manchen (seltenen) Fällen
Probleme mit der korrekten Expandierung von Umgebungsvariablen
(evtl. nur, wenn diese Sonderzeichen enthalten???).
IF NOT ""=="%var%" GOTO label1
Wenn die Variable %var% mit bestimmten, nicht leeren Werten belegt
wurde, wurde trotzdem das label1 nicht angesprungen (Die Variable
enthielt nur mehrere mit Leerfeldern getrennte Worte). Paradoxerweise
funktionierte in diesem Fall aber die logisch gleiche Abfrage:
IF NOT "%var%"=="" GOTO label1
Allerdings kann man dann den Tip 3 aus BATTIPS.TXT nicht mehr pauschal
anwenden.
---------------------------------------------------------------------------
4. Spezielle Umgebungsvariablen von MS-DOS: [96-09-25]
======================================================
In den Variablen %DirCMD% (ab MS-DOS 6.0 dokumentiert, aber wohl auch
schon bei MS-DOS 5.0 vorhanden) und %CopyCMD% (ab MS-DOS 6.2) kann
jeweils für die Befehle DIR und COPY eine Voreinstellung für Aufruf-
parameter abgelegt werden, die dann nicht jedesmal angegeben werden
braucht. Außerdem wertet MS-DOS eine Variable %Temp% für ein Temporär-
verzeichnis aus. %ComSpec% enthält - wie gewohnt - den Pfad und Namen
des Kommandoprozessors. (Variablen wie %Prompt%, %Append%, %Path% sind
wohl allgemein bekannt und brauchen hier nicht weiter erläutert werden.)
Bei MS-DOS 7 (aus Windows95 alias Chicago) werden auch noch folgende
Variablen ausgewertet: %CmdLine% (bei COMMAND.COM), und offenbar auch
noch %Lang% und %LangSpec% (bei einigen externen Kommandos).
Die Variable %CmdLine% wird schon seit Ewigkeiten von 4DOS/NDOS benutzt,
ebenfalls um die Längen-Begrenzung der normalen Kommandozeile (die in
das PSP passen muß) zu umgehen. Offenbar wurde die Variable %CmdLine%
aber von einigen frühen Beta-Versionen von Windows95/Chicago noch
etwas anders gehandhabt als bei 4DOS: Dort wurde nur der überschüssige
Teil der Kommandozeile, der nicht mehr in das PSP paßt, in %CmdLine%
abgelegt. 4DOS legt jedoch den kompletten Aufruftext in %CmdLine% ab.
Die ausgelieferte Version von Windows95 ahmt glücklicherweise das
Verhalten von 4DOS nach.
Möchte eine Applikation Nutzen aus %CmdLine% ziehen, muß sie deshalb
beide Varianten - möglichst automatisch - in Betracht ziehen, und da
es im Rahmen der Verwendung der PSP-Kommandozeile noch eine ganze
Reihe anderer Besonderheiten gibt, läßt sich dies nicht mehr 100%ig
sicher lösen:
Der gleiche Speicherplatz wird teilweise auch vom zweiten FCB und von
der Default-DTA benutzt; außerdem gibt es große Unterschiede darin,
wie ein Kommandoprozessor mit Zeilen um 126 Zeichen und länger umgeht:
Die meisten Kommandoprozessoren setzen hinter die PSP-Kommandozeile
noch ein ASCII-13, Novell DOS 7 COMMAND.COM und 4DOS/NDOS auch noch
ein ASCII-0 (wohl nicht bei MS-DOS COMMAND.COM). Dies geschieht aller-
dings nicht, wenn die Zeile 125 und mehr Zeichen enthält. Bei Aufrufen
via INSTALL= fehlt wohl auch bei Novelll DOS das ASCII-0. MS-DOS 7
setzt bei überlangen Kommandozeilen das Längenbyte auf 127 und setzt
an diese Position ein ASCII-13 (d.h., das ASCII-13 steht dann also eine
Position zu früh), Borland Pascal 7.00 IDE setzt das ASCII-0 nicht (und
wohl auch nicht das ASCII-13 an Position 127), dafür aber ein ungültiges
Längenbyte 128...)
---------------------------------------------------------------------------
5. DOUBLESPACE Online-Festplattenkompressor - Workaround: [96-11-29]
====================================================================
In seltenen Fällen kann es vorkommen, daß DBLSPACE beim *ersten* Ein-
richten eines komprimierten Laufwerks während des automatisch erfolgten
Aufrufs der Sicherheitsfunktion SCANDISK abstürzt (nur Booten hilft).
(Dieses Verhalten wurde auf einem Phoenix-Turbo-XT mit V20+8087,
1 MByte RAM (!), HGC + VGA, 40 MByte MFM-Platte über Ontrack
DiskManager beobachtet, aber es ist nicht geklärt, ob das Phänomen
an dieser speziellen Konfiguration lag.)
Dies ist nur insofern nicht tragisch, als daß zu diesem Zeitpunkt
noch keine Daten konvertiert worden sind und die Plattenstruktur
noch intakt ist.
Allerdings ist es in diesem Fall normalerweise nicht möglich, DBLSPACE
einrichten, weil sich der Aufruf von SCANDISK nicht unterdrücken läßt.
Es gibt aber folgenden Trick:
a) Man überprüft *vor* dem DBLSPACE-Aufruf mit SCANDISK das betreffende
Laufwerk. Unbedingt *mit* Oberflächenanalyse, auch wenn's etwas
dauert! Danach kann man auf einen erneuten Aufruf innerhalb von
DBLSPACE verzichten; dieser wird nun durch folgenden Trick umgangen:
b) Man nennt die Datei SCANDISK.EXE in SCANDISK.___ um.
c) Man nimmt sich irgendein kleines .EXE-Utility, das keine Funktion
ausführt (oder zumindest 'so gut wie nichts macht'), kaum Speicher
verbraucht, und mit Errorlevel 0 zu DOS zurückkehrt.
d) Dieses Progrämmchen, ab nun DUMMY.EXE genannt, nennt man in
SCANDISK.EXE um.
e) Man ruft nun DBLSPACE auf und startet die Einrichtung.
Statt des Aufrufs für SCANDISK.EXE wird nun in Wirklichkeit das
kurze Utility DUMMY.EXE aufgerufen, das sofort mit der Meldung
'Alles ok' (ErrorLevel 0) zu DBLSPACE zurückkehrt.
Danach arbeitet DBLSPACE korrekt weiter.
f) Nach der Installation von DBLSPACE und dem Kompressionsvorgang kann
man SCANDISK.EXE wieder in DUMMY.EXE umbenennen und SCANDISK.___
wieder in SCANDISK.EXE.
g) Da dieser spezielle Installationsaufruf von DBLSPACE immer nur dann
geschieht, wenn ein neues komprimiertes Laufwerk installiert wird,
braucht man sich nur in solchen Fällen um SCANDISK 'kümmern'.
---------------------------------------------------------------------------
6. Undokumentierter Befehl: TRUENAME: [96-11-29]
================================================
MS-DOS 3.0+ (definitiv aber MS-DOS 4.0+) hat einen undokumentierten
Befehl TRUENAME, der weder in der Hilfe erläutert wird, noch über
TRUENAME /? seine Funktion preisgibt. TRUENAME wird auch von DR DOS 6.0
ab Update 1992, Novell DOS 7 Update 4??? und später, Caldera OpenDOS
sowie 4DOS/NDOS unterstützt.
Man kann ihm einen unvollständigen Dateinamen (auch mit Wildcards) als
Parameter übergeben; dieser wird dann entsprechend erweitert (z.B. auf
das aktuelle Verzeichnis oder auch auf eine ?-Maske) an der Standard-
Ausgabe ausgegeben. Dabei werden auch JOIN, SUBST, ASSIGN, sowie Netz-
laufwerke (MAPPINGS) einbezogen (sofern sie TRUENAME-Support haben).
Mehrfach verschachtelte Substitutionen können aber nicht immer aufge-
löst werden.
Dies kann man z.B. in Batchjobs verwenden, um einen Dateinamen explizit
auszugeben oder um - unter Zuhilfenahme der Umleitungsmöglichkeiten von
DOS - einen Dateinamen für die folgenden Arbeiten in anderen Verzeich-
nissen zu fixieren.
---------------------------------------------------------------------------
7. Undokumentierter Parameter von FDISK: [96-06-18]
===================================================
Das Kommando FDISK (MS-DOS 5.0 - 6.22) besitzt einen undokumentierten
Aufrufparameter, der in Problemfällen mit Festplatten eine große Hilfe
sein kann (Boot-Sektor defekt, z.B. aufgrund Virusbefall oder bei nagel-
neuer Boot-Festplatte).
FDISK /MBR
schreibt (ohne Rückfrage!!!) einen für das zu dem FDISK-Kommando ge-
hörige DOS-System gültigen neuen Master-Boot-Record auf die Platte
(und ermöglicht es damit in Problemfällen, wieder von der Platte zu
booten). Bitte nur anwenden, wenn das auf der Platte zu bootende
Betriebssystem mit der aufgerufenen FDISK-DOS-Version übereinstimmt.
Dies ist fast immer der Fall; es gibt aber Ausnahmen, wo unter Umständen
kein Erfolg erzielt wird oder sogar der Schaden noch größer wird! Daher
wirklich nur anwenden, wenn man genau weiß, was man macht!!!
Achtung: /MBR hebelt auch Boot-Manager wie Linux' LILO oder den OS/2
Boot-Manager (offenbar auch Windows95 Boot-Manager) und Disk-Manager
(für große Festplatten unter DOS auf Rechnern mit älteren BIOSen) aus.
Novell DOS 7 bietet diesen undokumentierten Parameter nicht, dafür aber
einen offiziellen Menüpunkt, der das Gleiche bewirkt, aber den alten
MBR sichert und auch wieder zurückschreiben kann.
MS-DOS 6.22 besitzt auch noch die folgenden undokumentierten Parameter:
/PRI /EXT /LOG /Q sowie die dokumentierte Option /STATUS. Zumindest
einige davon könnten verheerende Folgen haben, wenn man sie unachtsam
aufruft (bisher nicht getestet)!!! Siehe auch Kapitel 15.
MS-DOS 7 FDISK besitzt einen neuen Parameter /X für eine andere
Zugriffsmethode auf die Festplatte. Ob dieses FDISK auch noch /MBR
unterstützt, ist noch nicht geklärt.
---------------------------------------------------------------------------
8. DOUBLESPACE-Hinweis: [96-11-29]
==================================
Ab 03/1994 lieferte Microsoft zu MS-DOS 6.21 das Programm DBLSPACE
nicht mehr mit aus, weil die Firma einen Prozeß gegen STAC verloren
hat (es wurden Patentrechte des Algorithmus verletzt...). Allerdings
ist auch STAC nicht unbeschadet aus dem Kampf hervorgegangen (sie
hatten eine triviale, allerdings undokumentierte Kompressor-
Schnittstelle (das sog. Preload-API) von MS-DOS disassembliert und
in STACKER verwendet, um STACKER auf die gleiche Weise ins System
einbinden zu können, wie das auch DBLSPACE kann).
Die um DBLSPACE und einige Bugs erleichterte Version heißt 6.21,
seit 08/1994 gibt es allerdings eine Version 6.22: Microsoft bekam
durch einen Handel wieder die Erlaubnis 'DBLSPACE' zu verwenden: das
Programm heißt jetzt allerdings DRVSPACE (und ist bis auf minimale
Änderungen mit dem älteren DBLSPACE identisch).
---------------------------------------------------------------------------
9. CONFIG.SYS: Undokumentiertes und Unbekanntes zum Experimentieren:
=======================================================[97-05-01]===
In CONFIG.SYS werden neben den bekannten und dokumentierten Direktiven
auch die folgenden Direktiven akzeptiert (6.2-6.22):
COMMENT= Identisch mit REM (beides ab MS-DOS 4.00).
Bei Novell DOS 7 nicht vorhanden.
MULTITRACK=ON|OFF Default-Einstellung ist ON. Mit OFF werden bei beson-
deren Kompatibilitätsproblemen Laufwerkszugriffe für
jeden Track extra behandelt, was die Sache stark
verlangsamt.
Welche Probleme damit ausgeräumt werden, ist unbekannt
(bisher habe ich solche Probleme noch nie bemerkt). Ab
MS-DOS (nicht PC-DOS) 4.00 vorhanden, bei MS-DOS 6.xx
wieder undokumentiert.
Diese Direktive ist mit der undokumentierten DEBLOCK=
Direktive von Novell DOS 7 und Caldera OpenDOS ver-
gleichbar, allerdings kann dort zusätzlich noch eine
Startadresse für das Disk-De-Blocking angegeben
werden, ab der von Single-Sektor auf Multi-Sektor
Zugriff umgeschwenkt wird:
DEBLOCK=0000 entspricht wohl MULTITRACK=off und
DEBLOCK=FFFF entspricht MULTITRACK=on, die dazwischen-
liegenden Werte (und die alte Default-Einstellung A000
von Novell DOS 7) können mit MS-DOS nicht eingestellt
werden.
NUMLOCK=ON|OFF Wie bei Novell DOS 7 und Caldera OpenDOS, bei MS-DOS 7
dokumentiert.
SET= Eingeführt mit MS-DOS 6.0 (wie bei DR DOS 6.0+), bei
MS-DOS 7 dokumentiert.
Bereits belegte Variablen können mit SET name= auch
wieder gelöscht werden (dies funktioniert auch in
CONFIG.SYS, allerdings habe ich noch nicht untersucht,
wie dies intern verarbeitet wird).
Laut MS-DOS 7 CONFIG.TXT kann man eine Auflistung der
aktuellen Einstellungen bekommen, indem man SET ein-
tippt. Diese Möglichkeit besteht allerdings nur inner-
halb von Batchjobs und am Prompt, nicht aber während
der Bearbeitung von CONFIG.SYS (wie fälschlicherweise
in MS-DOS 7 CONFIG.TXT beschrieben wird).
Als Default-DOS-Verzeichnis wird nicht nur C:\DOS\, sondern auch
C:\MSDOS\ akzeptiert (ab MS-DOS 6.0) (was aus Homogenitätsgründen
vorzuziehen ist, wenn man neben MS-DOS noch andere DOS'e wie
Caldera OpenDOS (C:\OPENDOS\), Novell DOS 7 (C:\NWDOS\) oder
DR DOS (C:\DRDOS\) auf der Platte installiert hat). Sollte COMMAND.COM
nicht gefunden werden, so fragt die Version 6.22 nach einem Pfad zu
einem gültigen Kommandoprozessor (wie von Novell DOS 7 und Caldera
OpenDOS her bekannt).
Der Vollständigkeit halber sei erwähnt, daß sehr alte MS-DOS Versionen
noch einige andere Direktiven unterstützten:
SWITCHAR= char Nur MS-DOS/PC-DOS 2.xx, undokumentiert <'/'>.
(Parameter-Einleitungszeichen, heute bei
MS-DOS festverdrahtet auf '/', bei Novell DOS
und DR DOS aber per API nach wie vor ein-
stellbar.)
AVAILDEV= true | false Nur MS-DOS/PC-DOS 2.xx, undokumentiert <true>.
Gibt an, ob ein zusätzliches \DEV\ beliebigen
Gerätetreibern vorangestellt werden muß oder
nicht. Dabei bedeutet 'true', daß die Angabe
optional ist; bei 'false' muß \DEV\ vorange-
stellt werden. Heute ist diese Funktion nicht
mehr einstellbar, sondern immer auf laxes
Verhalten eingestellt (entspricht 'true').
Die Auswertung dieses bool'schen Parameters
arbeitete im Gegensatz zu allen anderen
(heutigen) derartigen Parametern nicht mit
den Argumenten 'ON'|'OFF', sondern untersuchte
lediglich den ersten Buchstaben des Arguments:
Ein 'F' stand dabei für 'false' und schaltete
AVAILDEV= ab.
STRING[S]= Nur MS-DOS 3.0, undokumentiert.
(Größe einer String-Ära, einer reservierten
Struktur im Hauptspeicher, deren Sinn mir bis
heute verborgen geblieben ist, siehe SYSVARS.
Laut Arne Schäpers hieß diese Direktive
STRINGS=, laut Ralf Brown STRING=.)
IFS= Nur MS-DOS 4.xx, wahrscheinlich undokumen-
tiert. (Installable File System)
CPSW= Nur MS-DOS 4.xx, wahrscheinlich undokumen-
tiert. (Codepage Switching???)
MS-DOS 7 kennt einige neue Optionen:
DOS=ENHANCED Chicago: DOS386.EXE wird geladen.
DOS=AUTO, NOAUTO Windows95: Auch in Kombination mit den bis-
herigen Schaltern UMB|NOUMB, HIGH|LOW. Mit
AUTO (Standard) werden die folgenden Treiber
automatisch geladen, auch wenn diese in
CONFIG.SYS nicht extra angegeben wurden:
HIMEM.SYS, (IFS?)LFSHLP.SYS, DBLBUFF.SYS,
SETVER.EXE. Außerdem werden alle der folgenden
'HIGH'-Direktiven automatisch angenommen,
auch wenn sie nicht explizit mit der Endung
'-HIGH' angegeben wurden.
Mit NOAUTO werden die obigen Treiber nicht in
Eigenregie geladen, was dazu führen kann,
daß Windows95 nicht mehr bootet, wenn die
Treiber nicht explizit angegeben werden.
Evtl. gibt es auch noch einen Wert "SINGLE",
der bei DOS angegegeben werden kann.
BUFFERSHIGH= Windows95: Wie BUFFERS=, aber hochgeladen
FCBSHIGH= Windows95: Wie FCBS=, aber hochgeladen
FILESHIGH= Chicago, Windows95:
Wie FILES=, aber hochgeladen
LASTDRIVEHIGH= Chicago, Windows95:
Wie LASTDRIVE=, aber hochgeladen.
Bis einschließlich MS-DOS 6.22 war die bis-
herige Default-Einstellung für LASTDRIVE=E für
fünf Laufwerke. Mit MS-DOS 7 wurde das Ver-
halten von Novell DOS 7 nachempfunden (und
sogar noch etwas konsequenter realisiert):
Hier sind schon während der Bearbeitung von
CONFIG.SYS 26 Laufwerke (A: .. Z:) vorhanden,
was eine Reihe Probleme beim Laden von DOS-
Umadressierern aus dem Weg räumt. Nur,
wenn diese Laufwerke nicht benötigt werden,
reduziert MS-DOS die Anzahl der Laufwerke
später wieder auf die minimal nötige Anzahl
bzw. den Wert von LASTDRIVE= (beim Vorbild
Novell DOS gilt dies genauso, allerdings wird
aus Kompatibilitätsgründen zunächst eine
kleinere Tabelle vorgetäuscht. Wer konnte zu
Zeiten von MS-DOS 6 schon ahnen, daß Microsoft
mit MS-DOS 7 nun selbst zu diesem Verfahren
übergehen würde...)
Außerdem kann nun auch bei MS-DOS 7 (undoku-
mentiert) eine Angabe LASTDRIVE=1..32 er-
folgen, um bis zu 32 Laufwerke bereitzu-
stellen. (frühe Ausgaben von Novell DOS 7
erlaubten nur 27..32). Und auch die bei
Novell DOS längst vorhandenen automatischen
Hochlade-Möglichkeiten für die CDS-Tabelle
findet sich nun bei MS-DOS 7 wieder...
STACKSHIGH= Windows95: Wie STACKS=, aber hochgeladen
INSTALLHIGH= Windows95: Wie von DR DOS 6.0/Novell DOS 7
bekannt, d.h. wie INSTALL=, nur zum Hochladen.
ACCDATE=drive1(+|-) [drive2(+|-)] ...
Windows95: Mit ACCDATE= wird bei MS-DOS 7 eine
Funktion wiederaufgegriffen, die schon bei
CP/M-Systemen vorhanden war (ACCESS/CREATE).
Für jedes Laufwerk kann mit Plus oder Minus
angegeben werden, ob der Last-Access-Timp-
stamp mit jedem Zugriff aktualisiert wird
oder nicht. Falls ja, so wird bei jedem
Datei-/Verzeichniszugriff das aktuelle Datum
in einem bisher reservierten Bereich der
Verzeichniseinträge eingetragen. Die Datei
muß nicht unbedingt modifiziert werden.
Dieser Timestamp kollidiert weder mit OS/2
Extended Attributes noch mit DR DOS,
DR Multiuser DOS, Novell DOS 7, FlexOS,
Concurrent DOS Paßwörtern, leider aber mit
DR DOS 6.0 Owner-IDs (gibt's bei Novell DOS 7
nicht mehr) und Novell DOS 7 DELWATCH, das
hier das Original-Datum einer Datei speichert,
nachdem sie gelöscht und in die Löschver-
folgung aufgenommen wurde. Diese Doppel-
nutzung ist recht trickreich und sollte
funktionieren, solange die eine Funktion
von der anderen 'weiß'. Inwieweit das zu-
trifft, habe ich bisher noch nicht überprüft.
Allerdings benutzt MS Windows95/MS-DOS 7
noch einige andere Einträge im reservierten
Bereich, die von DR DOS und Novell DOS in
völlig anderer Art und Weise verwendet werden
(besonders kritisch dürfte hier die Speicher-
ung des Zeitpunktes der Dateierzeugung sein).
Näheres ist aber noch nicht untersucht.
SWITCHES= /E[:nn] mit nn=48..1024
Windows95: Wird auf Paragraphen gerundet,
für Relokalisierung von EBOIS (EBIOS???).
Interessante Windows95/MS-DOS 7 MSDOS.SYS [Options] Direktiven:
LOGO= Windows95: undokumentiert (für Konfigurations-
datei MSDOS.SYS). Das Einfügen von LOGO=0 in
der [Options] Sektion unterdrückt das Start-
Logo.
Gleichzeitig werden die Meldungen, die die
DOS-Treiber während der Bearbeitung der
evtl. vorhandenen Dateien CONFIG.SYS und
AUTOEXEC.BAT ausgeben, wieder sichtbar.
Diese Treiber bilden das DOS-Gerüst, auf dem
Windows95 basiert.
BOOTGUI= Windows95: BOOTGUI=0 sorgt in Verbindung mit
LOGO=0 dafür, daß Windows95 beim Booten nicht
startet, sondern stattdessen sofort der
MS-DOS 7 Prompt erscheint. Man kann dann
später die grafische Oberfläche von
Windows95 - wie von älteren Windows-
Versionen gewohnt - mit WIN aufrufen.
Hinter der neuen Verpackung ist also
doch sehr viel beim alten geblieben...
Achtung: Die Datei MSDOS.SYS muß aus Kompatibilitätsgründen mit der
alten gleichnamigen Binärdatei weiterhin größer als 1 KByte sein,
notfalls muß man also Dummy-Einträge vornehmen.
COMMAND.COM kennt noch ein paar weitere undokumentierte Parameter,
deren Funktion aber noch nicht geklärt ist: /F /D
---------------------------------------------------------------------------
10. XCOPY/MCOPY von MS-DOS 3.2:
===============================
Schon reichlich veraltet ist folgender Hinweis:
Wenn man bei MS-DOS 3.2 (anscheinend nur bei dieser Version) den
externen Befehl XCOPY in MCOPY umbenennt (bzw. eine so betitelte
Kopie anfertigt), so fragt der Befehl in kritischen Situationen
nicht mehr nach, ob es sich bei einer Angabe um eine Datei oder
ein Verzeichnis handelt, sondern trifft eine automatische Auswahl
anhand der Schreibweise (damit besteht aber auch eine gewisse Gefahr).
source=dir -> target=dir
source=multiple file -> target=dir
source=...\ -> target=dir
---------------------------------------------------------------------------
11. Fehlverhalten von MS-DOS 6.xx XCOPY:
========================================
XCOPY verschluckt beim Kopieren ein Reihe Fehlermeldungen, die dazu
führen können, daß verschiedene Dateien (wo die Probleme auftauchen)
nicht kopiert werden. Da man als Benutzer keine direkte Rückmeldung
erhält, sollte man insbesondere in Netzen und unter Multitaskern
sehr genau die Statistikausgabe kontrollieren, die XCOPY vor seiner
Beendigung ausgibt.
---------------------------------------------------------------------------
12. EMM386 und PCI-Mainboards:
==============================
Die mit MS-DOS 6.22 ausgelieferte Version von EMM386 (vor 4.48) hat
verschiedentlich Probleme auf PCI-Rechnern (z.B. in Verbindung mit
SMC-Ethernet-Karten), aber auch während des LOGIN in ein Netz. Dies
liegt wohl u.a. daran, daß 32Bit-IO-Zugriffe oberhalb von 400h getrappt
werden.
Es gibt bei Microsoft ein Update (das aber in den ersten Versionen
auch 4.48 hieß, allerdings einen Timestamp von 6.22 aufweist). Außerdem
soll auch der EMM386-Treiber von MS-DOS 7 (aus MS Windows95) prima mit
MS-DOS 6.22 zusammenarbeiten und dieses Problem nicht haben.
---------------------------------------------------------------------------
13. Neue interne Kommandos von MS-DOS 7.0 (Windows95): [96-04-02]
=================================================================
LFNFOR [[=] ON | OFF] Aktiviert/Deaktiviert die Verwendung von langen
Dateinamen innerhalb von FOR-Befehlen. LFNFOR
ohne Parameter zeigt die aktuelle Einstellung
an. LFNFOR /H gibt Kurzhilfe aus.
Dieser Befehl ist evtl. undokumentiert, jeden-
falls wird er derzeit von 4DOS 5.51 und 5.52a
noch nicht nachgebildet.
LOCK/UNLOCK [drive] Erlaubt den direkten Festplattenzugriff durch
Anwendungsprogramme oder sperrt ihn. Dadurch
ist es auch unter einem Multitasker möglich,
Daten auf einem Laufwerk aus der Sicht eines
Tasks 'einzufrieren', so daß z.B. Festplatten-
pflegeprogramme arbeiten können. Wird auch von
4DOS 5.51(a)+ unterstützt.
Wichtig, damit die Stuktur der Long-Filenames
nicht zerstört wird, wenn eine nicht kompatible
Anwendung direkt auf die Platte zugreift.
---------------------------------------------------------------------------
14. Problem mit CALL in MS-DOS COMMAND.COM bei Batchjobs mit Umleitung:
==========================================================[96-08-20]===
Offenbar existiert ein versteckter Designfehler in der MS-DOS 6.2x
COMMAND.COM Behandung von Batchjobs, die aus anderen Batchjobs mit
Ausgabeumleitung aufgerufen werden. Dieser Fehler tritt offenbar nur
beim Aufruf via CALL auf und macht sich nur dann bemerkbar, wenn auch
noch SHARE geladen ist. Unter 4DOS/NDOS tritt dieser Fehler nicht auf;
unter Novell DOS 7 COMMAND.COM tritt dieses Problem nicht auf, es gibt
aber ein sehr ähnliches Problem (s.u.). Folgender (vereinfachter) Auszug
aus einem Batchjob soll das Problem verdeutlichen:
REM Das folgende "CALL" verursacht den späteren Fehler unter MS-DOS:
@CALL FIND "pattern" pattern.$$$ > %tmp%\result.$$$
REM Nun tritt bei MS-DOS COMMAND.COM+SHARE ein Share-Fehler auf:
IF "4"=="%@Eval[2 + 2]%" IF "0"=="%@FileSize[%tmp%\result.$$$,b]%" ...
... GOTO no_match
IF EXIST %tmp%\pattern.$$$ DEL %tmp%\pattern.$$$ > \dev\nul
IF EXIST %tmp%\result.$$$ COPY %tmp%\result.$$$ %tmp%\pattern.$$$ ...
... > \dev\nul
IF EXIST %tmp%\pattern.$$$ ECHO Suchmuster gefunden!
:no_match
IF EXIST %tmp%\pattern.$$$ DEL %tmp%\pattern.$$$ > \dev\nul
IF EXIST %tmp%\result.$$$ DEL %tmp%\result.$$$ > \dev\nul
Um zu verhindern, daß der Batchjob nicht fortgeführt wird, wenn das
externe Kommando FIND über einen Batchjob aufgerufen wird, wurde dem
FIND ein CALL vorangestellt (CALL kann auch zum Laden von .EXE oder .COM
Dateien benutzt werden, ist dort allerdings überflüssig). Offenbar
verheddert sich COMMAND.COM in dieser Situation mit der Ausgabeumleitung
in die Datei RESULT.$$$, denn der nachfolgende COPY-Befehl meldet eine
"Sharing violation", d.h. die Datei RESULT.$$$ ist offenbar noch nicht
geschlossen (obwohl ich kein offenes Datei-Handle finden konnte). Läßt
man das CALL ein paar Befehle vorher einfach weg (und wird FIND nicht
per Batchjob aufgerufen), so funktioniert alles wunderbar, aber wegen
der Möglichkeit, daß ein Batchjob FIND.BAT existiert, ist dies nicht
immer praktikabel.
Ein offenbar immer funktionierendes Workaround ist es, statt dem
CALL
ein
%ComSpec% /C
zu setzen (evtl. auch noch SwitChar einbauen). Vor dem %ComSpec% kann
man ausnahmsweise auf ein CALL verzichten, da %ComSpec% per se niemals
auf einen Batchjob, sondern immer auf eine binär ausführbare Datei zeigt
und damit die Behandlung des Batchjobs nicht unterbrochen wird. Wahr-
scheinlich funktioniert dieses Workaround deshalb, weil mit %ComSpec% /C
mit Sicherheit eine neue temporäre Kopie des Kommandoprozessors ge-
startet wird, und diese beim Beenden wieder den alten Zustand zurück-
setzt, wohingegen bei CALL i. allg. eine interne Schnittstelle bedient
wird.
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 Novell DOS COMMAND.COM, wenn auch unter leicht anderen Voraus-
setzungen (siehe NWDOSTIP.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.
Ein vollständiges Beispiel aus der Praxis findet sich im beiliegenden
Batchjob MEM.BAT.
---------------------------------------------------------------------------
15. Undokumentierte Parameter externer Kommandos: [96-08-20]
============================================================
Diese Rubrik ist brandneu und alles andere als vollständig.
MS-DOS/PC-DOS besitzt und besaß eine Vielzahl undokumentierter
Optionen für spezielle Anwendungsfälle.
Manche dieser Parameter waren nur in bestimmten DOS-Versionen verfügbar
(z.B. Version 4.xx), manche wurden erst lange nach der Implementation
dokumentiert, manche sind zwar weiterhin vorhanden, aber mittlerweile
wieder in der Versenkung der 'Undokumentation' verschwunden.
In dieser Rubrik werde ich in Zukunft alle undokumentierten Parameter
auflisten und beschreiben, die mir 'über den Weg kommen', aber da MS-DOS
*nicht* das von mir favorisierte DOS ist, möchte ich schon jetzt be-
zweifeln, daß mir hier ähnlich viel einfällt, wie etwa zu Novell DOS...
Außerdem gibt es auf SimTel einige Sammlungen, die zumindest für die
älteren DOS-Versionen 2.xx - 5.0 allerhand ans Licht bringen und auf-
grund des großen Verbreitungsgrades von MS-DOS/PC-DOS existiert sogar
Literatur, die speziell auf solche Tricks eingeht (was mich eben bewog,
diese Lücke auch für Novell DOS/DR DOS zu schließen). Auf einige un-
dokumentierte MS-DOS Parameter wird im Rahmen der Besprechung von
Novell DOS-Features auch in NWDOSTIP.TXT eingegangen; bisher sind
diese Informationen noch nicht hierhin übernommen worden.
ANSI.SYS dok: /K /R /X
undok: /L /S /SCREENSIZE
ATTRIB.EXE undok: /FILESIZE existieren seit MS-DOS 4.0+
/DATE existieren seit MS-DOS 4.0+
/TIME existieren seit MS-DOS 4.0+
/CODEPAGE /CP existierten bei MS-DOS 4.0,
aber nicht mehr bei MS-DOS 6.22:
Waren für OS/2 ähnliche Codeseiten-
Unterstützung als erweiterte Attribute
vorgesehen, wurde allerdings meines
Wissens niemals vollständig im Kernel
implementiert. Von Novell DOS 7 und
DR DOS nicht unterstützt, es gibt aber
Alternativen.
BACKUP.COM undok: /L /HP
/P Packen der Daten (nur mit dem RESTORE
der jeweiligen Version kompatibel)
DEFRAG.EXE undok: /Q
DOSKEY.COM undok: /APPEDIT Diese undokumentierten Optionen wurden
/COMMAND mit MS-DOS 7 (Windows95) eingeführt.
/PERMANENT Daneben kennt DOSKEY noch ein paar
/SCRSIZE weitere neue Optionen, die aber
/XHISTORY dokumentiert sind.
EDIT.COM siehe QBASIC.EXE
FDISK.COM undok: /MBR Schreibt neuen Master-Boot-Record
(siehe BATTIPS.TXT)
/PRI (MS-DOS 6.22) ??? Warnung: Ich habe
/EXT (MS-DOS 6.22) ??? diese Optionen bis-
/LOG (MS-DOS 6.22) ??? her nicht unter-
/Q (MS-DOS 6.22) ??? sucht, könnten
gefährlich sein!!!
dok: /STATUS (MS-DOS 6.22) Gibt eine Übersicht der
Partitionsdaten aus und beendet FDISK
wieder.
FORMAT.COM undok. und nur für Disketten:
/AUTOTEST "FORMAT in einem Rutsch" ohne lästige
Nachfragen (seit MS-DOS 4.00+, wohl
auch schon früher). Die Frage, ob eine
weitere Diskette formatiert werden
soll, wird übergangen.
/BACKUP Seit MS-DOS 4.00+, wie /AUTOTEST, fragt
allerdings noch nach Labelnamen und ob
weitere Disketten formatiert werden
sollen.
/SELECT Seit MS-DOS 4.00+, wie /AUTOTEST, fragt
allerdings nach dem Label und kehrt
ohne die Frage nach weiteren Disketten
zurück.
/H Nur MS-DOS 3.3: interner Aufruf durch
BACKUP
MS-DOS/PC-DOS/DR DOS 5.0+/Novell DOS 7:
Hilfeschirm
Novell DOS 7 FORMAT bietet eine
ähnliche undokumentierte Option namens
/QUIET an (siehe NWDOSTIP.TXT). Diese
Option entspricht wohl fast 1:1 MS-DOS
/AUTOTEST.
/O Nur altes MS-DOS 2.xx???:
Formatiert mit einem Disketten-Format
für MS-DOS 1.0.
HELP.COM siehe QBASIC.EXE
MEM.EXE undok. /A Nur MS-DOS: für Ausgabe der HMA-Nutzung
kollidiert mit dokumentierter DR DOS/
Novell DOS Option /A zur Anzeige der
Gesamt-Info. HMA-Infos erhält man
unter Novell DOS mit /F.
QBASIC.EXE undok. /EDCOM Diese beiden undokumentierten Parameter
/QHELP von MS-DOS 6.2x müssen in Großschrift
angegeben werden, ansonsten werden sie
nicht akzeptiert.
/EDCOM wird von EDIT.COM verwendet, das
nichts weiter macht, als den
QBASIC-Editor mit QBASIC /EDCOM
aufzurufen.
/QHELP wird von HELP.COM verwenden, das
nichts weiter macht, als den
QBASIC-Editor mit QBASIC /QHELP
aufzurufen.
SHARE undok. /NC Nur MS-DOS 4.00 und 4.01, lädt den
SHARE-Code nicht, sondern nur den Code
zur Unterstützung großer Laufwerke
---------------------------------------------------------------------------
16. Unveränderbare Volume-Labels mit LABEL: [96-10-23]
======================================================
In seltenen Fällen kann es vorkommen, daß Sie unter MS-DOS/PC-DOS ein
Disketten-Label nicht mehr verändern können (z.B. mit LABEL). Dies liegt
daran, daß das Medium vorher mit Hilfsprogrammen der Norton Utilities
formatiert oder nach einer Fehlerfunktion restauriert wurde. Die Norton
Utilities verwenden - im Gegensatz zu DOS - als abschließendes Füll-
zeichen im Volume-Label statt einem Leerfeld (ASCII-32) ein Null-Zeichen
(ASCII-0). MS-DOS/PC-DOS und einige andere Programmen (etwa ältere Ver-
sionen von PKZIP) kommen mit solchen Medien nicht zurecht, wenn sie
einen neuen Namen schreiben soll.
Abhilfe:
Medium neu formatieren (nicht mit den Norton Utilities) oder LABEL.COM
von Novell DOS 7 verwenden, das diese Probleme nicht aufweist.
---------------------------------------------------------------------------
Converted to HTML by TXT2HTML (©Thomas Antoni), 19.05.2011, 15:39:16
|