from:     Shane
to:       freedos-user
date:     Sun, Oct 26, 2014 at 12:10 AM
subject:  Re: Fwd: lfn tools for dos - including FAT21, 16, 32, etc

Rugxulo: LFN-EN was compiled with Microsoft Visual C++ version 1.51.
According to the documentation, it uses a copyrighted library to
handle virtual memory, but this can be commented out.

LFN-EN as written works under MS-DOS (Windows 98 DOS), but it does not
work with FAT32 volumes under FreeDOS.  Under FreeDOS, it handles
FAT12 and FAT16 volumes OK, but it misidentifies FAT32 volumes as
FAT12 and gives the error message "Ambiguous DPB!(50)" and is not able
to read the FAT32 volume.  I have a quick and dirty patch, but in my
humble opinion what's really needed is a better check for whether the
DOS is FAT-32 compatible and whether volume locking is supported.

When the program was written in 1999, you could safely say that only
MS-DOS had FAT32 support, and that MS-DOS has volume locking; so
that's all LFN-EN checks for.  LFN-EN only considers these cases:
Windows 95B/C and Windows 98: FAT32 compatible, supports volume
locking.  Windows 95A: Supports volume locking, no FAT-32.  MS-DOS
pre-Windows 95, or a non-Microsoft DOS: No volume locking, no FAT32.

Since about 2004 the picture has become more complex.  The current
build of FreeDOS is available with and without FAT32 support.  Many of
the DOSses that were around in 1999 now have at least one branch that
supports FAT32.  There are new flavors of DOS on the scene too -- DOS
for embedded systems, and DOS from Russia!

Does FreeDOS support volume locking as well? If I'm reading this page
right:

http://www.mail-archive.com/freedos-kernel@lists.sourceforge.net/
msg00271.html

FreeDOS supports volume locking -- the bugs were being worked out in
2004, so FreeDOS 1.0 (2006) or later should support volume locking and
FAT32.

What needs to be done now is that someone needs to change the decision
logic about whether FAT32 is available and whether volume locking is
supported.  Simply checking a couple of magic MS-DOS version numbers
and deeming everything else to be "PC-DOS" won't cut it today.

My patch takes utilities that work under MS-DOS (Windows 98 DOS) and
fail under FreeDOS, and turns them into utilities that work under
FreeDOS and fail under MS-DOS.  I made copies of all the utilities
that start with F for FreeDOS, so LCHK.EXE becomes FLCHK.EXE.  Then, I
caused these copies to check for the OEM byte of FD (FreeDOS) instead
of FF (MS-DOS) by using a hex editor to change one instance of 80 7E
F0 FF to 80 7E F0 FD.  So when I'm running FreeDOS I type FLDIR for a
directory; when I'm under Windows 98 DOS I type LDIR for a directory.
If you're modifying the source and re-compiling instead of using a hex
editor on the executable, you'd be modifying lfn.cpp to check whether
ver.oem is FD instead of FF.

This patch is dangerous, because FreeDOS is available with and without
FAT32 support.  Since I'm running the latest kernel with FAT32
support, it works on my computer.