For english text see middle of file For changes.log see end of file 旼컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿏OSLFN - Treiber f걊 lange Dateinamen unter nacktem DOS� 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 쿌nsto�: 읕컴컴컴 Sicher h꼝te 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 f걊 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. Au�erdem will der Treiber gleich mal 64 KB Speicher haben. Beim Anlegen von Verzeichnissen wird alles grundlos in Gro�buchstaben umgewandelt, man hat keine M봥lichkeit, 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 schlie�lich auch noch andere solche Programme, mit 꼑nlichen Effekten, so sie denn 갶erhaupt liefen. So mu�te ich also (mal wieder!) feststellen, dass Warten nicht lohnt, und dass offenbar der Rest der Welt unf꼑ig ist, richtig zu programmieren;-) Nebenbei, den Quelltext zu LFNDOS zu finden ist mit Netscape unm봥lich; nur mit Internet Explorer kommt man an die Seite mit dem Quelltext heran. Ergo: selbst das an sich kinderleichte HTML kann nicht jeder. 쿏er eigene Versuch: 읕컴컴컴컴컴컴컴컴컴 Nat걊lich 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 nat걊lich in allen kritikw걊digen Punkten deutlich besser sein, und auch noch CDFS (genauer: Joliet) unterst걎zen. Dann w꼛e es ja auch "richtig" verwendbar. Hauptaugenmerk liegt in der g걆stigen Verwendbarkeit in Verbindung mit dem Volkov Commander, den ich f걊 den besten Norton-Commander-Klon halte, auch wenn da noch ein paar Sachen wirklich fehlen. Nachdem in der k걊zlich erschienenen neuesten Version endlich Alt+F7 funktioniert, vermisse ich nun noch einen NC-Link, m봥lichst auch noch via ECP (ca. 500KB/s). W꼑rend der Programmierung nun stellte sich heraus, dass es doch nicht ganz so einfach ist, die Funktionalit꼝en 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 ..." merkw걊dig 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 (l꼜tigen) Umkehrfunktion zum Setzen des DOS-Fehlerkodes. Die Implementation des Joliet-Zugriffs f갿rte jedoch zur totalen Ausuferung. Nicht nur, dass ich mittels Hilfsprogrammen gezwungen war, aus der d걊ftigen Information zu Joliet einen brauchbaren Zugriff hinzubekommen, musste ein Problem gel봲t werden, worum, wie sich sp꼝er herausstellte, sich sogar Windows 9x und Windows NT auf 꼑nlichen, aber leicht anderen Wegen, herumdr갷ken. Es geht um die Verbindung zweier an sich selbst꼗diger Verzeichnis-B꼞me, 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 Br갷kenschlag m봥lich macht, aber andere Brennprogramme tun dies nicht. Das nachtr꼏liche Erstellen einer solchen Tabelle ist aufw꼗dig (will sagen: je nach Komplexit꼝 der CD langsam) und im 갶rigen nicht immer m봥lich, bspw. bei leeren Verzeichnissen oder unterschiedlichen Dateien zwischen ISO und Joliet (noch nicht beobachtet, aber m봥lich). Drei L봲ungswege 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 gr붳eres TSR) * Anlegen der Tabelle beim CD-Zugriff (u.U. reaktionstr꼏es TSR) * Bereitstellung der Tabelle durch ein externes Programm auf Festplatte Wenn eine WinOnCD-gebrannte CD gefunden wird, entfallen diese Probleme. 쿛rogrammier-Umst꼗de: 읕컴컴컴컴컴컴컴컴컴컴 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 schie�t damit die DOS-Box ab, dann kann man auch gleich das NT booten). Zuerst wurden die Lesezugriffe implementiert. Noch war des TSR sch봭 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 ausl봲t, 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 l꼙pert sich einiges zusammen. Die Verwendung "undokumentierter" Felder im DTA bei FindFirst fiel aus, weil's dann nicht mehr unter NT4 funktionieren w걊de, und wohl auch bei anderen DOS-Exoten wie OS/2-DOS oder Caldera. (Linux DOSEMU wird wohl nicht unterst걎zt.) Das Problem gab's schon mal fr갿er, und die L봲ung nannte MS FASTOPEN. Das war anfangs ein .SYS-Treiber (?), und sp꼝er fest eingebaut. Kurz und gut, genauso etwas habe ich noch mit eingebaut (h꼕t 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-Unterst걎zung 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 Kodegr붳e profitieren davon. Ansonsten arbeitet das Programm im Speichermodell TINY (CS=DS!=SS), w걊de jedoch im Speichermodell SMALL genauso effektiv arbeiten. Andere Modelle w꼛en 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 sch봭e Idee, und gar nicht so schwer. Selbstverst꼗dlich ist dieses Programm deinstallierbar (wie auch die "Konkurrenz" LFNDOS), das ist ja heutzutage Standard, au�er bei Microsoft. Zwei Sprachen bietet das Programm 갶er eine Art String-Ressource. Meldet das DOS den L꼗derkode Deutschland, 셲terreich 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 verl꼗gern, wenn der LFN-Eintrag nicht hineinpasst. (Ob die Konkurrenz diesen Fall 갶erhaupt beachtet, habe ich noch gar nicht getestet.) DOS hat intern solche Routinen, die sowohl f걊 Dateien als auch f걊 Verzeichnisse gut sind, aber leider fehlen dazu die dokumentierten Einspr걆ge. Handarbeit ist angesagt, und da man soviel wie m봥lich Arbeit auf andere(n Kode) abw꼕zen sollte, l봲e ich das Problem 갶er eine tempor꼛e kreuzverbundene Datei im Wurzelverzeichnis. Zwei Pferdef곢e: da muss im Wurzelverzeichnis noch ein Eintrag Platz sein - aber das bis zum Rand zu f걄len ist sowieso eine tickende Zeitbombe. Und falls diese Datei irrt걅licherweise liegenbleibt, passiert der GAU, wenn man sie l봲cht. (Also: NICHT l봲chen, stattdessen SCANDISK oder DISKEDIT starten!) 쿒etestet in folgenden Situationen: 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� * MS Windows NT 4 DOS-Box, FAT12- und FAT16-Laufwerk (aber man sollte doch besser zum NTLFN-Paket greifen, ist auch Freeware) * 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 쿐rkl꼛ung einiger Schalter: 읕컴컴컴컴컴컴컴컴컴컴컴컴컴 ~ Tilde: Normalerweise verh꼕t sich Windows9x wie folgt: * "Kurze" Dateinamen (d.h. 8.3-Form und keine unerlaubten Zeichen) komplett in Gro�buchstaben und ohne Umlaut bekommen 갶erhaupt 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 l꼜st sich (nicht unter NT) die Tilde-Einf갾ung 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 k걊zt. Nachteil: Es ist nicht nachtr꼏lich m봥lich, eine echte 8.3-Datei neu zu erstellen, wenn der Name passt, oder schlimmer noch, der Inhalt wird (ungewollt) gel봲cht, im Glauben, unter LFN adressieren zwei verschiedene Dateinamen zwei verschiedene Dateien. Also: ~- entspricht NameNumericTail=0 und ~+ dem Standard. t Tunneleffekt: Programme, speziell Text-Editoren f걊 DOS, die keine langen Dateinamen unterst걎zen, speichern, indem sie * eine Datei *.bak l봲chen * die Datei *.txt in *.bak umbenennen * die Datei *.txt neu erstellen. Damit w걊de der lange Dateiname der *.txt verloren gehen. Der "Tunneleffekt" sorgt daf걊, 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 "Ged꼊htnisschwund" nachweisen. Es wird (k걆ftig) getunnelt von * l봲chen (Datei) -> erstellen (Datei) * umbenennen (Datei) -> erstellen (Datei) Windows9x hat mehrere gleichzeitig arbeitende Speicher, die auch kompliziertere "Datei-Man봵er" und auch Verzeichnisse 갶erwachen; aus Aufwandsgr걆den wird es in DOSLFN bei maximal einem Tunnel bleiben. c Pr갽summen-Verkn걈fung: Normalerweise h꼕t Win9x die Verbindung zwischen LFN- und FCB-Eintrag 갶er eine Pr갽summe. Vorteil: robustere Verzeichnisse, L봲ch- und Erstellungs-Vorg꼗ge unter nacktem DOS f갿ren nicht zu "falschen" langen Namen. Nachteil: man kann den kurzen Namen nicht nach Gutd걆ken anders nennen als den langen. Sollte stets bei c+ bleiben! a Hier ist speziell f걊 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! z Standardm꾞ig arbeitet DOSLFN mit der Codeseite 437 (US-englisch), um die Umwandlung OEM<->Unicode durchzuf갿ren; das gen갾t auch f걊 die Verarbeitung der deutschen Umlaute. Man kann aber auch eine andere Codeseite zur Konvertierung laden, so z.B. cp850uni.tbl f걊 die (bl봡erweise) 갶lichere 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: F걊 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-Eintr꼏e unpassend und will sie l봲chen. Problem unter WindowsNT: Hier st봱t nur SCANDISK(?) Deshalb: Codeseite konstant lassen und in Deckung mit Windows bringen! DOSLFN kann noch nicht mit DBCS (chinesisch, japanisch u.a.) umgehen! F걆fzehn 쉇ersetzungs-Tabellen sind DOSLFN beigef갾t. l Sprache setzen: sollte nicht weiter erkl꼛ungsbed걊ftig sein... Ist DOSLFN resident, merkt es sich die Einstellung bis zum Herauswurf. m Heap-Gr붳e setzen; dieser wird f걊 FindFirst/FindNext, die CD-Link-Tabelle und sp꼝er f걊 Sektor-Puffer ben봳igt. TZ Zeitzonen-Variable: Unter UNIX und NT gang und g꼉e, 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 k봭nen drei weitere Buchstaben zur Festlegung der Sommerzeit- Regel folgen. Da diese sowieso sich st꼗dig 꼗dert und in der Standard- Implementierung mit regelm꾞iger Bosheit immer wieder nur f걊 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) schlie�lich 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 m걌ste, 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. 쿑unktioniert nicht oder noch nicht: 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 * allgemeine CD-Unterst걎zung (z.Z. nur f걊 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 * 쉇erpr갽ung der maximalen L꼗ge des qualifizierten Dateinamens (260) Noch schlimmer: * Allozieren von Clustern beim Verl꼗gern von Verzeichnissen * Erweitertes L봲chen mit Platzhalterzeichen * Umbenennen mit gleichem kurzen Dateinamen Unterst걎zt die Int21/AH=71-Schnittstelle gem꾞 Ralf-Brown-Liste, au�er folgende Punkte: * Funktionen mit SUBST, AL=AAh * Datei-Erstellung vom Server, AL=A9h * Handle-Information holen, AL=A6h * Laufwerk r갷ksetzen, AL=0Dh 쿛rogramme MK_TABLE, MKLINK und LOWDMA 읕컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 MK_TABLE konvertiert eine Unicode-Tabelle in ASCII-Form, wie man sie bei www.unicode.org herunterladen kann, in die Volkov-Commander-Form um. MKLINK (Name kann sich in Zukunft 꼗dern) generiert eine sog. "Joliet-Verzeichnis-Verbindungs-Tabelle" (Joliet Directory Link Table) f걊 jede gefundene Joliet-CD. Dazu durchsucht es s꼖tliche Laufwerke, und erstellt diese Tabelle nach einem mittelm꾞ig komplexen, rekursiven Verfahren, 갶er das ich bei der Entwicklung lange gegr갶elt habe. Als Dateinamen w꼑lt es die Datentr꼏er- Bezeichnung (Volume Label) mit der Endung .JLT. So kann man seine CD-Sammlung nacheinander einlesen und Tabellen generieren lassen. Die so gewonnenen kleinen Dateien k봭nen von einer sp꼝eren Version von DOSLFN eingelesen werden, um auch bei nicht mit WinOnCD erstellten Medien lange Dateinamen zu nutzen. Zur Zeit sind diese Dateien nutzlos. Auf der Kommandozeile kann man die Laufwerkssuche einschr꼗ken (besonders n걎lich bei CD-Wechsellaufwerken), und es gibt folgende Schalter: /f * CD auch dann einlesen, wenn Zieldatei bereits existiert * CD auch dann einlesen, wenn sie eine CeQuadrat WinOnCD Tabelle hat /v+ * Einlese-Operation mehrzeilig (als Tabelle) anzeigen /v- * Einlese-Operation nicht anzeigen /h * Hilfe (in englisch) anzeigen Die Angabe von zu durchsuchenden Laufwerken erfolgt durch einzelnstehende Buchstaben. LOWDMA: Siehe LOWDMA.TXT ---------------------------------------------------------------------------- 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! 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. 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. A reasonable good tool for this is ODI's LFN tools, but that's not a driver. Important at 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 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. THE SWITCHES EXPLAINED: ~ (tilde usage): By default, Win9x adds a "~1" designator to the alias of any long file name, "~2" if there is a clash, and so on. Therefore, these long file names in plain DOS cannot address the alias. This behaviour seems to be built in due to erraneous behaviour of some tested software. (I guess, it was some old Microsoft software.) For normal DOS & Win users, this is impractical. Plain DOS is able to "support" long names by automatically truncating them to 8.3 form. Unless name contains spaces or multiple dots, the same long name can address a file both with and without available LFNs. Users can maintain compatibility for some program configuration independently whether running {Win9x or DOSLFN} or not. You can switch off tilde usage in Win9x by adding following binary key: REGEDIT4 [HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\FileSystem] "NameNumericTail"=hex:00 Then you have to restart Windows. (Dont't forget to hold down the "shift" key when you confirm selecting "restart"; it is not necessary to reboot.) You may also refer the WWW with keyword "NameNumericTail". t (tunnel effect): This feature, built in Win9x file system, help long file names to survive when modifying files with a conventional (8.3) text editor or compareable tool. They replace files as follows: * delete a file .bak (if any) * rename the original file .txt to .bak * create a new file .txt With this sequence, the long file name will be lost forever. But with "tunnel effect" active, Win9x and DOSLFN will watch for delete-rename-create (DRC) sequences and "automagically" attach previously deleted long file name entries to newly created names, if the is the same. The DRC sequence above may also be truncated to DR, DC, RR, or RC, and works for directories too. As documented in MSDN CD, Win9x internal "tunnel info" is kept 15 seconds, however, I can't find any obliviousness. Also, tunneling in Win9x works in both "directions", it remembers the alias if an LFN aware program does the same procedure. Therefore, you cannot get rid of "~" in "PROGRA~1" if you just rename "Program Files" to "Programs" and back. (You can restart Windows between two renamings to get desired effect.) Furthermore, as required in a multi-tasked OS, Win9x has more than one "tunnel info", allowing two or more processes (Win16 or DOS programs) make such DRC sequences at the same time or interleaved in one process. For simplicity, DOSLFN will only support one "tunnel info". c (Checksum link): You should let this switch ON. With OFF, DOSLFN may be able to read a little damaged disk (e.g. with a Disk Editor), but it's outside of any specification. DOSLFN doesn't try to repair defective links. (Later, it may be possible to give a complete different short name for a long name, but SCANDISK finds that incorrect.) a Because Microsoft hates programmers, they doesn't had added support for long names on classic APIs like "open" (AH=3Dh), "creat" (AH=3Ch) and so forth. (Of course, support for FindFirst/FindNext isn't possible because programs expect max. 12-character file names. Similar GetCurDir, where programs expect max. 64 characters.) In a future version of DOSLFN, it will be supported (except someone replies this is not necessary) z DOSLFN must convert Unicode to local code page, and this is locale dependent. Because DOS (or NLSFUNC) has no such a table built-in, this table must be delivered to DOSLFN, if not 437. (At now, DOSLFN doesn't recognize the current code page automatically, and loads a table itself, so you have to do the homework.) Fifteen Unicode translation tables, e.g. for 437 (Standard IBM, for resetting purpose), 850 (Western Europe), 852 (Eastern Europe), 866 (cyrillic), and two for Greek are now bundled with DOSLFN. A code page can be loaded even while DOSLFN is resident. Most European users use umlauts very seldom (due to known problems with bad-coded software[*] around the world), therefore, a forgotten code table load is not critical. But if you see filenames with unexpected underlines, you should load the code table. (DOSLFN does simply convert non-convertible unicodes to "_", without any notification on now equal file names.) [*] Often, it is wicked Unix software (e.g. "tar") that kills umlauts. Unix is internally more a 7 bit OS rather than 32 bit, and this limitation is spreaded into world until recent (brain-dead UTF-7, MIME codings...) m DOSLFN needs an internal heap for storing data; mostly, for Find Handles. The size of this data area defaults to 5000 Bytes. This is very large, for later inclusion of sector buffers. Smaller values reduce the memory consumption of resident DOSLFN. This switch cannot be given while DOSLFN is resident; the memory may be in use. l DOSLFN is bilingual. If it detects a locale of Austria, Switzerland, or Germany, it defaults to German language, English otherwise. To override language defaulting, use "ld" for German or "le" for English. e.g. get english help in Austria with "doslfn -le -h" or "doslfn leh" (As you see, DOSLFN ignores switch prefixes and spaces. A trailing whitespace is only necessary for the z command.) While DOSLFN is resident, the language override is permanent. TZ This environment variable will be used later - to convert FAT time stamp to Win32 time format (an Int64 in 100ns steps past 1.1.1601). It must match to a scanf() template like "%c%c%c%g", meaning three (unused) letters, a float number (not in exponential form), and optional trailing letters. The float number expresses distance in hours from GMT (Greenwich). A daylight savings time (DST) cannot be used because of unknown calculation method for so many countries. If wanted so, DOSLFN must have knowledge for all DST rules in the past (and future) for given country, to convert file times according to its dates, not to current date (most programs seems to have this bug). Using American DST rule is not applicable, although most programs do so. Therefore, I suggest that users should set the TZ variable, e.g. for Central Europe: set TZ=MET-1 in Winter set TZ=MET-2 in Summer not using any DST info - but they have to change their AUTOEXEC.BAT twice a year. TZ is not necessary for converting CDFS to Win32 time format because dates on it contain information about time zone distance (a byte in 15min steps) for the country where the CD is created. However, to maintain equal world time, converting CDFS times to FAT time (as return value for almost all time functions), both TZ and CDFS time zone info must be put together to calculate correct FAT (=always local) time - so it's better to step internally through Win32 time format. ACTIONS: Action letters must stay at the end of a command line, because command line parsing ends there. The default action is to load DOSLFN or to activate and show a short message, saying that DOSLFN is already loaded and active. Unloading DOSLFN may fail if there is a TSR hooking Int21 above DOSLFN. If so, DOSLFN disables itself, but remains in memory until another action (like unloading or re-enabling). You have to unload this (or these) above TSR(s) first. If that's impossible (mostly: Microsoft shit), you have to "simply reboot your system". SOME NOTES ON IMPLEMENTATION: A big trouble to me is safe support for long names on CD. Because I want to build on top of MSCDEX, I have to make bridges between Joliet and ISO, and I found, there are no safe bridges! (WinOnCD burns such a Link Table, it's nice to me, but that isn't a standard.) Windows 9x and NT "invent" new short file names and don't use the ISO part of Joliet CDs at all, furthermore, these two systems have different rules. So, if you put a CD with long file names into a drive and look on it with an old DOS program, you'll find up to three different short names for a long name under bare DOS, Windows9x and WindowsNT. As ODI's LFN tools doesn't require MSCDEX (except for reading sectors), it has no problem with it, a driver should deliver right short names for the long ones, because MSCDEX should open the short ones. A future solution uses Link Tables on disk (e.g. hard disk), and a program that builds the list for each CD. Making this list is time-consuming, I have a simple program and a typical full backup CD available, and the task takes three minutes for parsing the directory structure. Maybe, a better program doesn't spend so much time, but reading of all directories IS time-consuming and a bad action for DOSLFN. DOSLFN would check the CD and load the appropriate table, or the user has to load the table as with Unicode conversion table. Another trouble are Write accesses and the consistency of sector buffers: I want to cache data, but a ShortName API may change disk content; so I have to discard all caches, at least for this drive, at every DOS directory write access, even the old FCB ones. This degrades DOSLFN's performance. To support as many DOS versions as possible (not only MS), I don't want to use undocumented internal DOS structures. CHECKED FUNCTIONAL UNDER: * MS Windows NT 4 DOS-Box, FAT12 and FAT16 drives (but you should take NTLFN package, also nice Freeware) * MS-DOS 6.2 * MS-DOS 7.10, FAT32 * DR-DOS 7, with a magneto-optical drive THAT DOESN'T YET WORK: * Support for all CDs (only some WinOnCD burned ones supported) * true Windows NT time format (but a conversion forth and back is built-in) * effect of Tunneling (see "t" switch) * LoSA (Long filenames on ShortName API, see "a" switch) * SUBSTed or JOINed drives * Checking of maximum length (260) of resulting file paths * DBCS code pages MORE SEVERE: * Allocating of clusters at directory enlargements * Extended Delete sub-function with wildcards * REName with same short file name THAT WILL PROBABLY NEVER WORK: * functions around SUBST, AL=AAh * file creation from server, AL=A9h * retrieve handle information, AL=A6h * reset drive, AL=0Dh PROGRAMS "MK_TABLE", "MKLINK", AND "LOWDMA": MK_TABLE converts a Unicode table (ASCII form), downloadable at www.unicode.org, into binary Volkov Commander form used by DOSLFN. MKLINK (name may change in future) creates "Joliet Directory Link Tables" for each Joliet CD found. By default, it scans all CD drives, and creates this table using a rather complex, recursive processing. MKLINK chooses file names derivated from CD's Volume Label, and appends .JLT, for each CD processed. Therefore one can scan in his CD collection and create tables for all. These tables will be used by a future version of DOSLFN to gain access to long file names on media not created by WinOnCD. Currently, these tables are useless. MKLINK accepts some command line parameters. There are following options: /f * force reading CD even when link table file is already present * force reading CD ignoring CeQuadrat WinOnCD Table /v+ * show reading process in multiple lines (as a table) /v- * don't show reading process /h * show help Selecting drives is done by typing single drive letter(s). LOWDMA: see LOWDMA.TXT ---------------------------------------------------------------------------- Change.LOG: (+ added, - bug-fixed * changed) Version 0.30 (01/01) Initial version Version 0.31 (04/01) + better support for Windows NT (now useless) + timeout solution for keeping data for removable media + Automatically locking volumes on DOS7 before Write access * twiddeling with PKZIP 2.50 support - no solution * ISR terminates with IRET instead of RETF 2, for work with single-stepping debuggers Version 0.32 (09/01) - works with internal devices like NUL,CON,LPT... * source code has option for setting InDOS flag + variable heap size supported; memory consumption of DOSLFN is up to user + built-in PRINTF-alike function (transient code part only) * changed output style for "Status" action + four code translation tables included with ZIP package - A little-bit deflamed readme file Version 0.32a (10/01) - erraneous root directory of some FAT32 drives (this bug was constantly reported but doesn't occur at me until now) - misbehaviour when DOSLFN started from FAT32 drive (this bug was programmed in at Version 0.32) + all available code translation tables included with ZIP package + MK_TABLE.C enhanced (was made at 0.32) and included * Version numbering with "a" indicates that there is another version 0.33 currently in development. This is more a bugfix release. Version 0.32b (10/01) - invalid AX on INT21/4E&4F, reported by claude.caillet@free.fr (Behaviour was not documented in Ralf Brown list 03/99) - some english text missing in DOSLFN.TXT (time zone, test conditions) reported by Wu Yongwei - CP850UNI.TBL was wrong, copied to CP858UNI.TBL (this was one containing the Euro sign, CP850 does not contain Euro. (by ) + MKLINK is added, although output link table file is useless yet Version 0.32c (11/01) - in some occations, *. doesn't work (e.g. failure on "copy *. tmp") - FindFirst of character devices does return error but should not (failure on "copy con xx"), both reported by wengierwu@sohu.com * reduced default heap size, CD sectors are not yet inside * size for internal Link Table expanded to 32 bits