--------------------------------------------------------------------------- MSDOSTIP.TXT - Tips für den Umgang mit MS-DOS 5.0 - 7 Copyright (C) 01/1994-05/1997 bei Matthias Paul Ubierstraße 28 D-50321 BRÜHL DEUTSCHLAND EMail : Letzte Änderung: 1997-05-01 -mp Ich übernehme keine Gewähr für die Richtigkeit der Informationen. Jegliche Haftung für Schäden etc. ist ausgeschlossen. Hinweise auf Fehler sowie auf weitere Tips und Tricks sind immer willkommen. Bitte beachten Sie README.1ST für weitere Bestimmungen. 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+). Für weitere Hinweise siehe auch NWDOS7UN.TXT, NWDOSTIP.TXT, DRDOS6UN.TXT, DRDOSTIP.TXT, BATTIPS.TXT u.a. --------------------------------------------------------------------------- Ü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 + bzw. +). 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 . 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. ---------------------------------------------------------------------------