Why DOSLFN, what's that?
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
(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!
All these programs require an existing LFN-API to support LFN.
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.
- 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
(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
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
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.
- 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:
||[the driver itself]
||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!
||for Joliet CDROMs
- when no CD drive available
- when no (new) Joliet CDROMs are expected
||for Windows 3.x
||when using plain DOS or Windows 9x/Me
||for DOS 6 or DR-DOS
||when you use|
- MS-DOS 7
- LFN enabled "Commanders"
||for diskette access in non-DMA-able UMB memory
||almost always, please refer LOWDMA.TXT.
|*.PAS; *.C; *.ASM; *.DEF; MAKEFILE
- Why I have no long file names then typing dir?
- 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?
- 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
In case of 4DOS, you have to add a line into 4DOS.INI:
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
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".
- 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
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
Therefore it hides the LFN API of NTFSDOS.
Please load NTFSDOS after DOSLFN.
Back to the download page (short form)
email: Henrik Haftmann
Chemnitz, last change: 09.19.2011