Wozu DOSLFN, was ist das?

Geschichte der langen Dateinamen

Mit Windows95 brachte Microsoft ein DOS heraus, welches offenbar in der Lage war, auf dem betagten FAT-Dateisystem lange Dateinamen unterzubringen.
Für solcherart Dateinamen wurde von Microsoft die Abkürzung LFN (für "long filename") eingebürgert.
LFNs kommen nicht automatisch; Microsoft hat mit DOS7 eine neue Programmier-Schnittstelle, das LFN-API, eingeführt, auf die DOS-Programme erst zugreifen müssen, sonst bleibt alles beim alten, also C:\PROGRA~1.
Dies war nach eingehenden Tests mit vorhandener (Microsoft-)Software notwendig, ein Erweitern der vorhandenen Schnittstellen führte zu Abstürzen durch Pufferüberläufe.
Daraus folgt, dass DOS-Programme erst seit 1995 LFNs unterstützen können!
Zu bekannten Vertetern gehören:

Diese Programme setzen auf das Vorhandensein der LFN-API auf.

Problemdarstellung

Lange Dateinamen (z.B. C:\Programme) existieren nur solange Windows 9x läuft. Unter purem DOS existiert das LFN-API offenbar nicht.
(Genau genommen ist das LFN-API nämlich gar kein Bestandteil von DOS7, sondern von IFSMgr, dem Protected Mode DOS, welches während der Laufzeit von Windows95 komplett das DOS7 ersetzt.)

Somit ist es also auch für oben genannte Programme nicht möglich, unter DOS7 LFNs zu verarbeiten; ein weit verbreiteter Irrtum!
Das ist besonderlich für Programme hinderlich, die zum Backup dienen können, wie PKZIP. Denn um ein zerschossenes Windows zu restaurieren sind LFNs zwar nicht unbedingt nötig, aber ersparen viel Handarbeit.

Hier setzt DOSLFN an und liefert das LFN-API nach.

DOSLFN bildet die unter DOS fehlende Schnittstelle so gut es geht nach, und greift für die LFNs sektorweise auf das jeweilige Medium zu.

Übrigens

DOSLFN muss sich mit einer OEM↔Unicode-Konvertierung herumschlagen. Es funktioniert nunmehr mit allen Codeseiten, sogar mit in Fernost üblichen Zwei-Byte-Zeichensätzen (DBCS = Double Byte Character Set).

DOSLFN hat über die Codeseite 858 eine eingebaute Euro-Unterstützung. Weitere notwendige Anpassungen für DOS sind erforderlich.

DOSLFN läuft mit jeder DOS-Version (nicht nur MS) und verhilft so jedem DOS zu langen Dateinamen.

Häufig gestellte Fragen

Wie ist die Kommandozeilen-Syntax?

Rufen Sie einfach DOSLFN auf. Es lädt von selbst die richtige Unicode-Tabelle und berechnet die benötigte Heap-Größe automatisch anhand vorhandener Dateien.
Laden Sie DOSLFN mittels LH DOSLFN in den hohen Speicher (UMB).
Entladen wird das Programm mit DOSLFN u.
NLSFUNC sollte, wenn notwendig, vor DOSLFN geladen werden!

Welche Dateien brauche ich (auf einer Bootdiskette), welche kann ich löschen?

Ermitteln Sie Ihre Codeseite durch Aufruf von CHCP. Dann siehe Tabelle:

DateiWofür gebraucht?Löschen?
DOSLFN.COM [der Treiber] nie!
CP???UNI.TBL Je nach Ergebnis von CHCP
(sofern Umlaute/Sonderzeichen gebraucht werden) 		Alle anderen.
Bei Zusammenlegung von Volkov Commander und DOSLFN (etwa mittels DOSLFN /p=c:\vc) können sich VC und DOSLFN die Unicode-Tabelle teilen!
MKLINK.EXE für Joliet-CDs
  • wenn kein CD-Laufwerk vorhanden
  • wenn keine (neuen) Joliet-CDs einzulesen sind
LFNXLAT.386 für Windows 3.x bei purem DOS oder Windows 9x/Me
L.EXE für DOS 6 oder DR-DOS bei Verwendung von
  • MS-DOS 7
  • 4DOS
  • LFN-fähigen "Commandern"
LOWDMA.COM; LOWDMA.SYS für Diskettenzugriff in nicht-DMA-fähigen UMB fast immer, siehe LOWDMA.TXT.
*.TXT [Benutzungshinweise] immer
*.PAS; *.C; *.ASM; *.DEF; MAKEFILE [Quelltexte] immer

Warum erscheinen beim Kommando dir keine langen Dateinamen? (DOS 6)

DOS 6 (genauer: dessen Shell, die COMMAND.COM) unterstützt keine langen Dateinamen. Man sehe sich dazu nach einem Shell-Ersatz um. Etwa 4DOS oder die COMMAND.COM von Caldera OpenDOS. Oder man nimmt MS-DOS 7 - die COMMAND.COM läuft jedoch nicht auf DOS 6.
Hintergrund: Das LFN-API (Programmierschnittstelle) ist keine Erweiterung der klassischen API (wegen drohender Pufferüberläufe), sondern eine neue Schnittstelle. DOS 6 kann diese nicht kennen.

Benutzen Sie ersatzhalber das Programm l.exe, welches die Kommandos (eines Tages mit identischer Syntax) wie DOS 7 ausführt.

Warum funktionieren einige Programme trotz angeblich eingebauter LFN-Unterstützung nicht? (DOS 6)

Viele Programme fragen die DOS-Version ab und aktivieren ihre LFN-Unterstützung erst ab Versionsnummer 7. Dazu gehören PKZIP/PKUNZIP und GetType.

Starten Sie solche Programme mit dem Programm GiveVer.
Im Falle 4DOS fügen Sie in der 4DOS.INI den Schalter Win95LFN=YES ein.
Hintertür für PKZIP 2.50: Benutzen Sie den undokumentierten Schalter /n+ zum LFN-Zwang. Bei PKUNZIP funktioniert dieser Schalter leider nicht.

Warum funktionieren LFNs nicht, solange Windows 3.11 läuft?

Der 32-bit-Dateizugriff ist aktiviert, und der zugehörige VCACHE unterbindet jegliche Festplattenzugriffe. In diesem Fall gibt es lange Dateinamen immerhin noch auf Diskette und CDROM.

Schalten Sie den 32-bit-Dateizugriff ab. (Systemsteuerung, 386 erweitert)
Als Ausgleich für den Performanceverlust installieren Sie einen DOS-Cache. (SmartDrive, HyperDisk ...)

Aber eine Reihe von Programmen funktionieren trotz DOS Version 7 nicht, zeigen Müll an oder stürzen ab.

Programme mit Fehlverhalten laufen im Protected Mode und verwenden einen DOS-Extender, der das LFN-API nicht umsetzt.
Neben der Möglichkeit, den DOS-Extender auszutauschen (wie auch immer) kann man mittels Windows 3.x eine Protected-Mode-API nachliefern. Dazu startet man DOSLFN vor Windows und das fragliche Programm in einer DOS-Box.

DOSLFN schiebt dem Windows den Virtuellen Gerätetreiber LFNXLAT.386 unter.
Übrigens, LFNXLAT.386 kann auch für jeden anderen LFN-Treiber (nicht nur DOSLFN) genutzt werden.
Um Windows 3.x auf DOS 7 zu starten, muss man in der Regel die IO.SYS patchen.

Nicht funktionierende Programme fragen womöglich, ob Windows läuft. Dafür gibt es zurzeit kein geeignetes GiveVer.

Warum funktioniert xcopy nicht? (MS-DOS 7)

XCOPY.EXE hat keinerlei eingebaute LFN-Unterstützung; stattdessen startet dieses Programm in der Win95-DOS-Box das Win32-Programm XCOPY32.EXE. Da hilft nur ein Ersatz der XCOPY.EXE durch ein anderes Programm. (Wer schreibt's?) Alternativ der Start von XCOPY32.EXE über einen PE-Starter, z. B. WinEm, der dann auch erst auf LFN aufgebohrt werden muss.

Benutzen Sie "Commander" oder einen XCOPY-Ersatz. (Welchen?)

Wie schön wäre Windows 3.x mit langen Dateinamen!

Das beste dafür geeignete Programm, Calmira, hat leider (noch) keine LFN-Unterstützung.
Ich arbeite jedoch an einem LFN-"Netzwerktreiber", der wenigstens dem Datei-Manager lange Dateinamen spendiert, und an einer Patch-DLL, die solche im Datei-Öffnen- und -Speichern-Dialog anzeigt.
Via LFNXLAT.386 ist (zumindest für den Erweiterten Modus) eine Protected-Mode-Schnittstelle für alle Windows-Programme vorhanden.
Fraglich und zweifelsohne interessant wäre die Umsetzung auf Win32s.

Fragen Sie bei den Software-Entwicklern nach LFN-fähigen Updates.

Auf der CD sehe ich keine langen Dateinamen. MKLINK meldet: "No valid Joliet descriptor found". Was läuft hier falsch?

Diese CD hat lange ISO-Dateinamen und kein Joliet. (Unter Win9x betrachtet sind alles Großbuchstaben und nirgends Umlaute.) DOSLFN unterstützt diese Variante noch nicht; allerdings kann auch DOSLFN nicht verhindern, dass man in die langen Verzeichnisse nicht hineinwechseln kann. Da liegt der schwarze Peter bei MSCDEX; dieser Treiber müsste hierzu gepatcht werden. Denn Dateien mit langen Namen lassen sich öffnen.
Der alternative CD-ROM-Treiber shsucdx kann dagegen in lange Verzeichnisse hineinwechseln, aber keine langen Dateien öffnen.

Kopieren Sie die CD, indem Sie den Verzeichnisbaum als Joliet neu anlegen, und den ISO-Teil auf Level 1 stellen.
(Also nicht mit CloneCD oder dem "Copy CD"-Wizard gängiger Brennprogramme!)

DOSLFN ist geladen, mit MKLINK wurde eine .JLT-Datei erzeugt. Trotzdem gibt es auf der CD keine langen Dateinamen. Sie erscheinen erst nach Herauswurf und Neuladen von DOSLFN. Geht es auch ohne?

DOSLFN lädt die .JLT-Datei sofort beim Wechsel auf das CD-Medium. Es kann aber sein, dass dafür die vorberechnete Heap-Größe nicht ausreicht, etwa weil diese neue .JLT-Datei besonders groß ist. Das residente DOSLFN müsste bei einem Aufruf (bspw. mit /s = Status) in etwa melden: "Letzter Fehler: Zu wenig Speicher".

Geben Sie bei Erwartung solcher Situationen beim Start reichlich Heap-Speicher, bspw. doslfn /m=10000 (10 Kilobyte Heap).

Etwa 600 Bytes davon braucht DOSLFN für sich und die Unicode-Tabelle; Chinesen und Japaner müssen hier deutlich größere Werte (bspw. 20000) angeben.

Grundsätzlich haben alle TSR-Programme das Problem, Speicher nicht dynamisch vom Betriebssystem anfordern zu können, oder (was hier der Fall ist) dies zu einer starken Fragmentierung und obendrein einer schwierigen Verwaltung (nämlich mit FAR-Zeigern) führen würde.
Das Problem ist eben erst ab Windows 3.x gelöst, deutlich sichtbar an den riesigen DOS-Netzwerktreibern, die man unter Windows 3.11 "gar nicht brauchte" - sie waren als VxD ausgelagert und konnten dynamisch (auch riesige) Pufferspeicher von Windows beziehen.

Auf der CD erscheinen lange Verzeichnisnamen; jedoch kann ich in solche mit mehr als 8 Zeichen nicht hineinwechseln. Was ist falsch?

Diese CD hat zusätzlich lange ISO-Verzeichnisnamen. Diese können von MSCDEX nicht benutzt werden. MSCDEX müsste hierzu gepatcht werden; allerdings liegt Fehler eher bei demjenigen, der die CD zusammengestellt und den ISO-Level auf 2 (nicht DOS-kompatibel) gestellt hat.

Brennen Sie beim nächsten Mal die CD ordentlich, mit ISO Level 1.

Bei Verwendung von NTFSDOS (zum Zugriff auf Windows-NT-Partitionen) verschwinden die langen Dateinamen der NTFS-Partition(en) nach dem Laden von DOSLFN.

DOSLFN benutzt für alle Nicht-FAT und Nicht-Joliet-Laufwerke einen Rückfall-Modus, um für alle Laufwerke ein LFN-API bereit zu stellen. Damit überdeckt DOSLFN zurzeit das LFN-API von NTFSDOS.

Laden Sie NTFSDOS nach DOSLFN.

Ich habe das Zeichen ® (Registriertes Warenzeichen) in einem Dateinamen, sehe aber unter DOS nur _ (Unterstrich). Auch unter Windows 9x.

So ist dieses Verhalten kein Fehler von DOSLFN, sondern Zeichen der exakten Emulation des IfsMgr.
Sie verwenden vermutlich die DOS-Codeseite 437, die Standard-Kodeseite eines jeden IBM-kompatiblen PCs (genauer: der Grafikkarte). Diese Kodeseite enthält kein ®, und weder Windows noch DOSLFN können zaubern. Eigentlich müsste auch Scandisk über diesen Umstand meckern.

  • Verwenden Sie kein Zeichen, das nicht sowohl in Ihrer DOS- als auch in Ihrer Windows-Kodeseite enthalten ist! Somit müssen Sie auf ® verzichten.
    oder
  • Stellen Sie die DOS-Kodeseite (wieder) auf 850 oder 858; laden für die korrekte Zeichendarstellung die Zeichenbildtabelle mit mode con….
    Notfalls können Sie auch (zum verlustfreien Kopieren) folgendes tun:
  • Laden Sie absichtlich die falsche Umkodierungstabelle CP850UNI.TBL mit dem Schalter -z beim Start von DOSLFN.

Anwenderberichte

Der Hinweis in what_lfn.de.htm auf DR-DOS-COMMAND.COM ist super! Evtl. solltest Du zusätzlich die Version mit LFN Unterstützung nennen (eine rote DR-DOS 7-Schachtel steht hier seit 15 Jahren; die bleibt weiter ungeöffnet:). Diese COMMAND.COM aus DR-DOS funktioniert; vielleicht könntest Du den ausgekoppelten Kommandointerpreter auf Deine Seite stellen (3,2 MB für ein 66k-Binary zu laden ist mühsam). Ja, siehe Text.

Mit PC DOS verträgt sich die Caldera-COMMAND.COM prima; mit FreeDOS läuft sie wegen anderer Befehle (erkennt keine FDCONFIG.SYS) weniger gut. Eine FreeDOS-FreeCom-Version mit LFN-Unterstützung fand ich auch bei länger Suche nicht (v0.84pre2 [Jul 17, 2011...] ist überdies fehlerhaft bzw. wg. fehlendem LOADHIGH unbrauchbar; keine Downloadlinks zu Nachfolgern).

Dr. Torsten Kühn, per E-Mail, Dezember 2012