Why DOSLFN, what's that?

History of long file names

With Windows95, Microsoft seems to have DOS modified to support long file names on every good old FAT file system.
For such file names, Microsoft created the abbrevation LFN.
LFNs do not appear automatically in your old programs; moreover, Microsoft re-invents the wheel and creates a new so-called LFN-API (Application Programmer Interface), which has to be accessed by newer versions of your favourite DOS software. Elsewhere, nothing will happen and you will see C:\PROGRA~1.
This was necessary (at least for GetCurDir and FindFirst/FindNext) due to buffer overflows, among other compatibility problems.
Rule of the thumb: DOS programs can only support LFNs if they are re-written since 1995!
For example:

Volkov Commander (only the Beta version - don't forget pressing Strg+N!)
Norton Commander 5.5 (I have never seen it)
PKZIP/PKUNZIP 2.50 (wants a DOS version number 7, see FAQ)
DOS Navigator (another NC clone, shareware)
4DOS (a COMMAND.COM replacement, shareware)
GetType - guesses file type from file header/content (Unix: file)
ZSNES - Nintendo emulator

All these programs require an existing LFN-API to support LFN.

About the problems

Long file names (e.g. C:\program files) only "exist" while Windows 9x is running in the back. With pure DOS, no LFN API seems to exist at all.
(More precisely, that LFN API is not part of DOS7, rather IFSMgr, a "Protected Mode DOS" which is a VxD running in the Windows95 system and replaces DOS7 almost completely.)

Therefore, above listed programme cannot show and handle LFN in pure DOS7 - a prevalent misconception!
This is especially cumbersome for backup programs, like PKZIP. For restoring Windows, LFNs are not necessary yet, but by far more convenient.

So, here comes DOSLFN and does Microsoft's homework.

DOSLFN is a TSR (terminate and stay resident) programs and creates the LFN API as compatible as it can, and accesses the FAT (or Joliet) medium sector-wise.

More (solved) problems

DOSLFN has to deal with an OEM↔Unicode conversion for support of umlauts and so forth. Now it works with all code pages, inclusive arabic and with DBCS (Double Byte Character Set) in Far East.

DOSLFN has built-in Euro currency sign support via code page 858. More work for DOS support has to be done.

DOSLFN runs with any DOS version (not only MS) - you can have LFN in every (e.g. free) DOS.

Frequently Asked Questions

What is the command-line syntax?

Simply call DOSLFN! It loads the matching Unicode table and calculates the necessary internal heap size taking some files into account.
Please load-high DOSLFN with LH DOSLFN into UMB memory.
Remove the driver by typing DOSLFN u.
NLSFUNC should be loaded before DOSLFN if necessary!

What files are necessary (e.g. on a boot disk), which of them can I safely delete?

Get your code page by calling CHCP. Then see the table below:

File	For what?	Delete?
DOSLFN.COM	[the driver itself]	never!
CP???UNI.TBL	depending on CHCP result (if you want non-ASCII characters)	all other files. If you put DOSLFN into the Volkov Commander directory (or use `DOSLFN /p=c:\vc`), VC and DOSLFN can share the Unicode table file!
MKLINK.EXE	for Joliet CDROMs	when no CD drive available when no (new) Joliet CDROMs are expected
LFNXLAT.386	for Windows 3.x	when using plain DOS or Windows 9x/Me
L.EXE	for DOS 6 or DR-DOS	when you use MS-DOS 7 4DOS LFN enabled "Commanders"
LOWDMA.COM; LOWDMA.SYS	for diskette access in non-DMA-able UMB memory	almost always, please refer LOWDMA.TXT.
*.TXT	[usage manual]	always
.PAS; .C; .ASM; .DEF; MAKEFILE	[source code]	always

Why I have no long file names then typing dir? (DOS 6)

DOS 6 (more exactly: its shell COMMAND.COM) doesn't support LFN. Look for a replacement shell. For example 4DOS or COMMAND.COM from Caldera OpenDOS. Or use MS-DOS 7 - its COMMAND.COM unfortunately doesn't run onto DOS 6.
Background: The LFN API is not an expansion of existing API, but a new API. DOS 6 doesn't know about it.

You may use l.exe, which should (later) executes all DOS commands like DOS 7.

Why some programs doesn't work although documentation says the contrary? (DOS 6)

Many programs query the DOS version number and activate its LFN support if number equals 7. For example PKZIP/PKUNZIP and GetType.

Please start such programs with the helper GiveVer.
In case of 4DOS, you have to add a line into 4DOS.INI: Win95LFN=YES.
Backdoor for PKZIP 2.50: Use the undocumented option /n+ to force LFN usage. Unfortunately, this switch is not available for PKUNZIP.

Why do LFNs not work while running Windows 3.11?

The reason is an activated 32bit disk access, and VCACHE(!) prevents any hard disk access. In this situation you can find that LFNs still work on diskette and CDROM.

Please switch off the 32bit disk access. (Control Panel, 386 enhanced)
As a compensation, install a DOS cache program (SmartDrive, HyperDisk ...)

But a couple of programs don't work even in DOS7, show garbage or crash when DOSLFN is loaded.

Such programs run in protected mode and (internally) use an old DOS-Extender who does not "translate" the LFN API.
Except replacing the DOS extender (how?), you can deliver an "already translated" protected mode API by starting Windows 3.x. Please start DOSLFN before Windows and the program in one DOS box.

DOSLFN inserts the virtual device driver LFNXLAT.386 into Windows' protected mode system.
Moreover, LFNXLAT.386 can translate the API for any LFN driver (not only DOSLFN).
To start Windows 3.x onto DOS 7, you have to patch the IO.SYS - thanks to Microsoft.

Not working programs may query whether Windows is running. For those I have no appropriate GiveVer.

Why xcopy doesn't work? (MS-DOS 7)

XCOPY.EXE has no LFN support at all! Instead, it runs XCOPY32.EXE if it detects a running Windows 9x. You need a replacement XCOPY.EXE. (Who writes it?) Maybe, you can use XCOPY32.EXE via an LFN enabled PE-Starter, z. B. WinEm, or a Borland one (???).

Better, you use a "Commander".

Hou beautiful could be a Windows 3.x with long file names!

The IMHO best suited program, Calmira, doesn't (yet) have LFN support.
But I'm working on an LFN "network driver" for LFN support in Windows File Manager, and a patch DLL modifying standerd File Open/Save dialogs.
Via LFNXLAT.386 there is (in Enhanced Mode) a protected mode API for all (newer, 16bit) Windows programs.
Best would be LFN support for Win32s programs! But I don't know where to start.

Ask your software developer for LFN updates.

No long file names on CDROM. MKLINK reports: "No valid Joliet descriptor found". What's wrong?

This CDROM has long ISO file names, no Joliet. (Even with Win9x all is uppercase and no non-ASCII characters.) DOSLFN doesn't support this variant; but an MSCDEX replacement is necessary too! There are some bugs in it.
An alternative CDROM driver shsucdx is now enabled to fully support such CDROMs - of course, with crippled file names.

You may copy this CDROM and create a Joliet tree. And don't forget to set the ISO part to "Level 1" (=DOS file name convention).
(Don't copy with CloneCD or "Copy CD" wizard of burner software; create a new CDROM image and put the files on it.)

On CDROM I have long directory names, but cannot change into some of them. What's wrong?

This CDROM has Joliet and long ISO directory names. These cannot be accessed by MSCDEX. You can try SHSUCDX instead. Please set you CDROM burner software to "ISO Level 1" next time!

When using NTFSDOS (for accessing Windows NT partitions) long file names disappear from NTFS-Partition(s) after loading DOSLFN.

DOSLFN serves a fallback mode for all non-FAT and non-Joliet-volumes. Therefore it hides the LFN API of NTFSDOS.

Please load NTFSDOS after DOSLFN.