For english text see middle of file

DOSLFN - Treiber fr lange Dateinamen unter nacktem DOS

Ansto:
Sicher htte ich dieses Programm seit etwa 1996 gebraucht, aber damals dachte
ich, irgendjemand wird's ja wohl schreiben. Also wartete ich, und wartete...
und fand erst 2000 ein halbwegs geeignetes Programm LFNDOS.EXE, geschrieben
1998.
Offenbar wurde jenes Programm fr die Win9x COMMAND.COM geschrieben,
denn mit dem Volkov Commander (VC) geht es nicht (man kann nicht in
Verzeichnisse mit langem Namen hineinwechseln), und es ist schrecklich langsam.
Auerdem will der Treiber gleich mal 64 KB Speicher haben - ist wohl alles
in C geschrieben. Aber ohne Quelltext besteht keine Verbesserungsmglichkeit.
Beim Anlegen von Verzeichnissen wird alles grundlos in Grobuchstaben
umgewandelt, man hat keine Mglichkeit, den Schlangen zu entkommen
(NameNumericTail=0), und, der Hammer, beim Umlaut-Test fiel das Programm
komplett durch! Unicode scheint immer noch ein Fremdwort zu sein.
Ich fand schlielich auch noch andere solche Programme, mit hnlichen
Effekten, so sie denn berhaupt liefen.
So mute ich also (mal wieder!) feststellen, dass Warten nicht lohnt,
und dass offenbar der Rest der Welt unfhig ist, richtig zu programmieren;-)
Und vielleicht schmen sie sich ihrer Quelltexte.

Der eigene Versuch:
Natrlich schreibt man ein solches Programm in Assembler und nur in Assembler.
Und da ich Borland Turbo Assembler habe, habe ich diesen genommen, und
verwende den IDEAL-Modus, um in den Genuss lokaler Strukturelemente
zu kommen und dem Rest der Welt (der offenbar nur MASM verwendet) ein kleines
Schnippchen zu schlagen.
Ich wollte natrlich in allen kritikwrdigen Punkten deutlich besser sein,
und auch noch CDFS (genauer: Joliet) untersttzen (da hat sich wohl noch
keiner herangetraut). Dann wre es ja auch "richtig" verwendbar.
Hauptaugenmerk liegt in der gnstigen Verwendbarkeit in Verbindung mit
dem Volkov Commander, den ich fr den besten Norton-Commander-Klon halte,
auch wenn da noch ein paar Sachen wirklich fehlen. Nachdem in der krzlich
erschienenen neuesten Version endlich Alt+F7 funktioniert, vermisse ich
nun noch einen NC-Link, mglichst auch noch via ECP (ca. 500KB/s).
Whrend der Programmierung nun stellte sich heraus, dass es doch nicht
ganz so einfach ist, die Funktionalitten so abzubilden, wie es Windows tut.
Also nun doch kein Wunder, dass man sich da so schwer tat. Von den einst
anvisierten 4KB resident bin ich schon wieder weit entfernt, und es
funktioniert beileibe noch vieles nicht. Beispielsweise ist die Funktion
von "cd .." klar, von "cd ..." merkwrdig und neuartig, aber nett,
und "cd ...." konsequent. Oder aber dass die COMMAND.COM ausgiebig von
der DOS-Funktion "Erweiterte Fehler-Information holen" Gebrauch macht,
um letztlich doch nur den Fehlerkode zu verwenden, erfordert andererseits
den Gebrauch der (lstigen) Umkehrfunktion zum Setzen des DOS-Fehlerkodes.
Die Implementation des Joliet-Zugriffs fhrte jedoch zur totalen Ausuferung.
Nicht nur, dass ich mittels Hilfsprogrammen gezwungen war, aus der drftigen
Information zu Joliet einen brauchbaren Zugriff hinzubekommen, musste
ein Problem gelst werden, worum, wie sich spter herausstellte, sich sogar
Windows 9x und Windows NT auf hnlichen, aber leicht anderen Wegen,
herumdrcken. Es geht um die Verbindung zweier an sich selbstndiger
Verzeichnis-Bume, ISO und Joliet. Windows verwendet nur den Joliet-Baum,
falls vorhanden, und "erfindet" neue, andere kurze DOS-Namen, als die im
ISO-Baum enthaltenen. Stellt sich die Frage nach "Querverbindungen".
Das Programm WinOnCD speichert freundlicherweise eine "link table" auf die
CD, die genau diesen Brckenschlag mglich macht, aber andere Brennprogramme
tun dies nicht. Das nachtrgliche Erstellen einer solchen Tabelle ist
aufwndig (will sagen: je nach Komplexitt der CD langsam) und im brigen
nicht immer mglich, bspw. bei leeren Verzeichnissen oder unterschiedlichen
Dateien zwischen ISO und Joliet (noch nicht beobachtet, aber mglich).
Drei Lsungswege standen deshalb offen, in Anbetracht der schwierigen Lage,
und dass man unter nachtem DOS nicht gerade als Diskjockey arbeiten wird:
* Dynamisches Anlegen der Link-Tabelle (noch greres TSR)
* Anlegen der Tabelle beim CD-Zugriff (u.U. reaktionstrges TSR)
* Bereitstellung der Tabelle durch ein externes Programm auf Festplatte
Wenn eine WinOnCD-gebrannte CD gefunden wird, entfallen diese Probleme.

Programmier-Umstnde:
Entwickelt wurde unter NT4, getestet mit SoftICE. Ist zwar etwas hart,
wegen der DOS-Box gleich den ganzen Rechner samt Netzkarte einzufrieren,
aber SoftICE ist eben auch kaum aus der Ruhe zu bringen (es sei denn, man
schiet damit die DOS-Box ab, dann kann man auch gleich das NT booten).
Zuerst wurden die Lesezugriffe implementiert. Noch war des TSR schn klein,
mit reichlich 3 KB resident. Dabei stellte sich heraus, dass der VC wie
auch bei den anderen LFN-Treibern sehr langsam wurde. Ursache sind viele
LFN<->SFN-Konvertierungen, die der VC auslst, und dass offenbar das DOS
nicht cachen will, wenn man (auch nur lesend) auf Diskette oder Platte
zugreift. Bei jeder Pfadkomponente musste das entsprechende Verzeichnis
durchsucht werden, und da lppert sich einiges zusammen. Die Verwendung
"undokumentierter" Felder im DTA bei FindFirst fiel aus, weil's dann nicht
mehr unter NT4 funktionieren wrde, und wohl auch bei anderen DOS-Exoten
wie OS/2-DOS oder Caldera. (Linux DOSEMU wird wohl nicht untersttzt.)
Das Problem gab's schon mal frher, und die Lsung nannte MS FASTOPEN.
Das war anfangs ein .SYS-Treiber (?), und spter fest eingebaut. Kurz und
gut, genauso etwas habe ich noch mit eingebaut (hlt die Verbindung
kurzer Name, langer Name und Startcluster), und der Geschwindigkeits-
vorteil ist so enorm, dass ich da das halbe Kilobyte extra gerne spendiere.
Wegen der von vornherein eingebauten FAT32-Untersttzung und wegen
vieler kleiner weiterer Annehmlichkeiten beim Programmieren habe ich
das Programm auf Mindestanspruch 386er festgelegt. So kann ich mit
32-bit-Registern hantieren, und das Segment-Register FS als "Quell-Segment"
verwenden. Geschwindigkeit und Kodegre profitieren davon.
Ansonsten arbeitet das Programm im Speichermodell TINY (CS=DS), wrde
jedoch im Speichermodell SMALL genauso effektiv arbeiten. Andere Modelle
wren hier schlichtweg Platzverschwendung.
Die Art der Adressierung von gepushten "Client-Registern" sollte jedem
sofort bekannt vorkommen, der schon mal VxDs programmiert hat: ist
eine wirklich schne Idee, und gar nicht so schwer.
Selbstverstndlich ist dieses Programm deinstallierbar (wie auch die
"Konkurrenz" LFNDOS), das ist ja heutzutage Standard, auer bei Microsoft.
Zwei Sprachen bietet das Programm ber eine Art String-Ressource.
Meldet das DOS den Lnderkode Deutschland, sterreich oder Schweiz, wird
automatisch Deutsch ausgegeben, sonst englisch. Bei Nichtgefallen dieser
Automatik gibt es einen Kommandozeilen-Schalter.
Bei der Implementierung des Schreibzugriffes kam ich jedoch vom Hundertsten
ins Tausendste: man muss das Verzeichnis einen oder sogar mehrere Cluster
verlngern, wenn der LFN-Eintrag nicht hineinpasst. (Ob die Konkurrenz
diesen Fall berhaupt beachtet, habe ich noch gar nicht getestet.)
DOS hat intern solche Routinen, die sowohl fr Dateien als auch fr
Verzeichnisse gut sind, aber leider fehlen dazu die dokumentierten Einsprnge.
Handarbeit ist angesagt, und da man soviel wie mglich Arbeit auf
andere(n Kode) abwlzen sollte, lse ich das Problem ber eine temporre
kreuzverbundene Datei im Wurzelverzeichnis. Zwei Pferdefe: da muss
im Wurzelverzeichnis noch ein Eintrag Platz sein - aber das bis zum Rand
zu fllen ist sowieso eine tickende Zeitbombe. Und falls diese Datei
irrtmlicherweise liegenbleibt, passiert der GAU, wenn man sie lscht.
(Also: NICHT lschen, stattdessen SCANDISK oder DISKEDIT starten!)

Getestet in folgenden Situationen:
* MS Windows NT 4 DOS-Box, FAT12- und FAT16-Laufwerk
* MS-DOS 6.2
* MS-DOS 7.10, FAT32
* DR-DOS 7, magneto-optisches Laufwerk
jeweils mit Windows 9x COMMAND.COM (zum Start h#s GiveVer benutzen!) und
Volkov Commander 4.99.08, Schreibzugriffe sicherheitshalber nur auf Disketten

Erklrung einiger Schalter:
~ Tilde: Normalerweise verhlt sich Windows9x wie folgt:
  * "Kurze" Dateinamen (d.h. 8.3-Form und keine unerlaubten Zeichen) komplett
    in Grobuchstaben und ohne Umlaut bekommen berhaupt keinen LFN-Eintrag
  * "Kurze" Dateinamen mit Kleinbuchstaben oder Umlauten erhalten einen
    LFN-Eintrag; der (normale) FCB-Name bekommt keine Schlange (Tilde)
  * Alles andere bekommt einen eindeutigen FCB-Namen mit ~1, ~2 usw.,
    wobei als Extensions-Trenner der LETZTE Punkt gilt. Nur im LFN erlaubte
    Zeichen werden durch '_' ersetzt, mit der Ausnahme '.' und Leerzeichen,
    diese fallen ganz weg. NT setzt hinter die Tilde einen zweistelligen
    Buchstaben-Zahlen-Code, DOSLFN und 9x arbeiten mit fortlaufenden Zahlen.
  Mit dem Registry-Schalter NameNumericTail=0 lsst sich (nicht unter NT)
  die Tilde-Einfgung verhindern, falls der kurze Name noch eindeutig
  bleibt. Vorteil: man kann die Datei mit ihrem langen Namen auch noch
  unter DOS (ohne LFN-Treiber), nach einem (fatalen) Angriff alter
  Direktzugriffs-Software oder bei einem versauten System ansprechen,
  weil DOS intern auf 8.3 krzt.
  Nachteil: Es ist nicht nachtrglich mglich, eine echte 8.3-Datei neu
  zu erstellen, wenn der Name passt, oder schlimmer noch, der Inhalt wird
  (ungewollt) gelscht, im Glauben, unter LFN adressieren zwei verschiedene
  Dateinamen zwei verschiedene Dateien.
  Also: ~- entspricht NameNumericTail=0 und ~+ dem Standard.
t Tunneleffekt: Programme, speziell Text-Editoren fr DOS, die keine
  langen Dateinamen untersttzen, speichern, indem sie
  * eine Datei *.bak lschen
  * die Datei *.txt in *.bak umbenennen
  * die Datei *.txt neu erstellen.
  Damit wrde der lange Dateiname der *.txt verloren gehen.
  Der "Tunneleffekt" sorgt dafr, dass bei der Umbenennung der dem kurzen
  Namen zugeordnete lange Name gespeichert wird und beim Wieder-Erzeugen
  der kurzen Datei der lange Name mit etwas "Zauberei" wieder herangeheftet
  wird. Die Speicherzeit ist lt. Dokumentation auf 15 s begrenzt, eigene
  Tests konnten bei 9x keinerlei "Gedchtnisschwund" nachweisen.
  Es wird (knftig) getunnelt von
  * lschen (Datei) -> erstellen (Datei)
  * umbenennen (Datei) -> erstellen (Datei)
  Windows9x hat mehrere gleichzeitig arbeitende Speicher, die auch
  kompliziertere "Datei-Manver" und auch Verzeichnisse berwachen;
  aus Aufwandsgrnden wird es in DOSLFN bei maximal einem Tunnel bleiben.
c Prfsummen-Verknpfung: Normalerweise hlt Win9x die Verbindung
  zwischen LFN- und FCB-Eintrag ber eine Prfsumme. Vorteil:
  robustere Verzeichnisse, Lsch- und Erstellungs-Vorgnge unter nacktem
  DOS fhren nicht zu "falschen" langen Namen.
  Nachteil: man kann den kurzen Namen nicht nach Gutdnken anders nennen
  als den langen.
  Sollte stets bei c+ bleiben!
a Hier ist speziell fr Windows 3.1 die Aufwertung von _lopen und _lcreat
  bedacht worden; da mir aber kein DOS-Programm bekannt ist, das damit
  zurechtkommt, sollte es bei a- bleiben!
t Standardmig arbeitet DOSLFN mit der Codeseite 437 (US-englisch), um
  die Umwandlung OEM<->Unicode durchzufhren; das gengt auch fr die
  Verarbeitung der deutschen Umlaute. Man kann aber auch eine andere
  Codeseite zur Konvertierung laden, so z.B. cp850uni.tbl fr die (blderweise)
  blichere Codeseite 850, die einfach nur ein paar mehr akzentuierte
  Buchstaben hat (und sich deshalb besser mit dem Windows-Zeichensatz deckt),
  oder aber kyrillische Tabellen.
  Problem unter DOS: Fr die Anzeige der langen Dateinamen wird die momentan
  geladene Codeseite herangezogen, d.h. Umlaute, die in kyrillisch nicht
  enthalten sind, werden als '_' ausgegeben; rein kyrillische Namen unter
  437 sehen so aus: '_____ ____ ___.___'
  Problem unter Windows9x: Windows hat auf Anwender-Ebene praktisch kein
  Unicode, und auch der Explorer zeigt nur Zeichensalat an. SCANDISK
  findet solche LFN-Eintrge unpassend und will sie lschen.
  Problem unter WindowsNT: Hier strt nur SCANDISK(?)
  Deshalb: Codeseite konstant lassen und in Deckung mit Windows bringen!
  DOSLFN kann hier nicht mit DBCS (chinesisch, japanisch u.a.) umgehen!
l Sprache setzen: sollte nicht weiter erklrungsbedrftig sein...
  Ist DOSLFN resident, merkt es sich die Einstellung bis zum Herauswurf.
TZ Zeitzonen-Variable: Unter UNIX und NT gang und gbe, aber unter DOS und 95
  scheint sie niemand zu kennen, obwohl viele (C-)Programme diese ebenfalls
  implizit brauchen! Der Aufbau ist schlicht, dass nach 3 x-beliebigen
  Buchstaben, die den Namen der Zeitzone angeben, eine vorzeichenbehaftete
  Gleitkommazahl folgt, die die Verschiebung in Stunden zur UTC (oder GMT?)
  angibt. Danach knnen drei weitere Buchstaben zur Festlegung der Sommerzeit-
  Regel folgen. Da diese sowieso sich stndig ndert und in der Standard-
  Implementierung mit regelmiger Bosheit immer wieder nur fr Amerika gemacht
  wird (kotz!), ist von dieser Angabe abzuraten, sodass im Sommer "TZ=MET-2"
  und im Winter "TZ=MET-1" (in Mitteleuropa) angegeben werden sollte.
  [Genau genommen arbeitet die Angabe yyy=DST (daylight savings time
  =Sommerzeit) schlielich mit der Angabe xxx zusammen, um festzustellen,
  ob gerade Sommerzeit ist oder nicht. Ansonsten ist xxx belanglos.
  Nichtsdestotrotz bleibt uneindeutig, ob 2.30 Uhr in der bewussten Herbstnacht
  in Sommerzeit oder Winterzeit gemeint ist, sodass man diese Angabe eigentlich
  in einem solchen Fall immer dazuschreiben msste, etwa 2.30 Uhr MESZ!
  Auf der Festplatte jedenfalls steht diese Angabe nicht; auch die Zeitzone
  des Ortes des Speicherns der Datei fehlt.] DOSLFN verwendet TZ (noch) nicht.

Funktioniert nicht oder noch nicht:
* allgemeine CD-Untersttzung (z.Z. nur fr solche mit WinOnCD gebrannte)
* Uhrzeitangaben in Windows-NT-Zeit (100-ns-Schritte seit 1.1.1601),
  die FAT-Dateizeiten werden jedoch in eine stetig wachsende Zahl konvertiert
* Tunnel-Effekt
* Lange Dateinamen auf ShortName-API
* Funktion auf geSUBSTeten oder gar geJOINten Laufwerken
* hoppla: Rename (vergessen?)
* berprfung der maximalen Lnge des qualifizierten Dateinamens (260)

Untersttzt die Int21/AH=71-Schnittstelle gem Ralf-Brown-Liste, auer
folgende Punkte:
* Funktionen mit SUBST, AL=AAh
* Datei-Erstellung vom Server, AL=A9h
* Handle-Information holen, AL=A6h
* Laufwerk rcksetzen, AL=0Dh




APPROACH
Of course I needed such a program since 1996, but in mind that such a tool
is useful for everybody, I thought someone would write it. And so I was
idle and waiting, and last year I found some tools, e.g. LFNDOS.EXE,
written 1998, not so old as expected.
This program was written for functionality with Win9x COMMAND.COM,
and doesn't work with my favourite file manager, Volkov Commander.
(You cannot go into directories with a long name.) And that TSR is so
S_L_O_W, and, on the other hand, consumes 64 KB of memory, too much!
Seems to be written in C language, another common mistake today.
Without the source code, there is no chance to make enhancements and bugfixes.
This program cannot create files and directories with lower case letters
(Why??), there is no way to go away from snakes (tildes, according to
the registry key NameNumericTail=0), and, last not least, it doesn't
supports umlauts correctly. Have programmers ever heard the term Unicode?
Later I found similar programs, containing similar bugs or worse.
Programmers on the world are not capable to code correct and tiny,
and are ashamed to show her source code, that's my point of view now.

MY TRY:
Of course, such a program must be written in assembly language.
With the nice Turbo Assembler I used the not-so-commonly used IDEAL mode
to enable local structure components, among other advantages (e.g. speed).
This program is dedicated to not to have the bugs found in the ones as
stated above. And I would support long names on CD (Joliet), very useful
for restoring backups under plain DOS. There seems to be no one program
around the world that even marginally support this.
Important alt least to me is usefulness in conjunction with Volkov Commander,
the best Norton Commander clone I find. Among it supports long filenames,
it is much smaller and faster than the original, and has some nice features.
(Unfortunately, there are some disadvantages, like the missing hotkeys for
 directory sorting, or a computer link feature.)
While programming I must state that's not so easy to write a bullet-proof
driver with at most full functionality as I'm thougt at a glance.
No wonder that I found such one not earlier - and so hard to program.
At first, an objective was to consume as least as possible memory, around
4 KB. Now, I'm far, far away from this goal, and I'm happy with less than
12 KB. Compared with 64K this is good enough.
Another hurdle was understanding Windows9x long filename semantics. What
"cd .." should be, is commonly known, "cd ..." is new with 9x and changes
two directory levels up, "cd ...." three and so forth. (I was familiar with
the fact that the directory entries "." and ".." are not directly used by
DOS.) Or the way pattern matching with long filenames is done: some is
known from UNIX (like *1 matches all files ending with "1"), some is Win32
specific, like "*." that matches all files WITHOUT an extension.
And, an extension is defined as the part after the LAST dot not in a
chain of first dots. Or that's possible to create files with leading
spaces and/or dots, but trailing spaces and/or dots were truncated.
With "*." in mind, this is necessary, because there is no way to find files
with a dot at end. Therefore, filenames with spaces and dots alone are not
allowed, with the virtual exception of useless "." and ".." directory entries.
COMMAND.COM uses the DOS function Get Extended Error Information, and so I
had to use the unhandy complementary function to set this error code, to
put COMMAND.COM to work correctly.

..continued..
