1. Geschichte der langen Dateinamen
2. Problemdarstellung
3. Übrigens
4. 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:

Datei	Wofü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.