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:
existierennur solange Windows 9x läuft. Unter purem DOS existiert das LFN-API offenbar nicht.
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.
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.
Datei | Wofür gebraucht? | Löschen? |
---|---|---|
DOSLFN.COM | [der Treiber] | nie! |
CP???UNI.TBL | Je nach Ergebnis von CHCP (sofern Umlaute/ | 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 |
|
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
|
LOWDMA.COM; LOWDMA.SYS | für Diskettenzugriff in nicht- | fast immer, siehe LOWDMA.TXT. |
*.TXT | [Benutzungshinweise] | immer |
*.PAS; *.C; *.ASM; *.DEF; MAKEFILE | [Quelltexte] | immer |
Benutzen Sie ersatzhalber das Programm l.exe, welches die Kommandos (eines Tages mit identischer Syntax) wie DOS 7 ausführt.
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.
Schalten Sie den 32-bit-Dateizugriff ab. (Systemsteuerung, 386 erweitert)
Als Ausgleich für den Performanceverlust installieren Sie einen DOS-Cache.
(SmartDrive, HyperDisk ...)
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.
Benutzen Sie "Commander" oder einen XCOPY-Ersatz. (Welchen?)
Fragen Sie bei den Software-Entwicklern nach LFN-fähigen Updates.
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!)
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. |
Brennen Sie beim nächsten Mal die CD ordentlich, mit ISO Level 1.
Laden Sie NTFSDOS nach DOSLFN.
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