Hi Aitor,

> But then it wouldn't be compatible with the LFN that came with
> Windows9X and is used in the millions of USB devices or the like, nor
> with the applications that are LFN-aware (unless you'd like to rewrite
> the DOS LFN API descript.ion-based...

>> I think a descript.ion file based driver to support
>> long file names would be a fine idea indeed :-).
>> And it would avoid the ugly kludgy way in which MS
>> stores LFN spread over multiple directory entries.

Well actually that is what I meant - descript.ion is a classic
for some shells and file managers, but it is also a nice way to
store long file names in filesystem independent way and without
having to implement any kludgy patented VFAT style LFN storage.

With a driver showing the usual int 21 LFN interface to the apps
but using descript.ion instead of "LFN fragment direntry chains"
for the actual LFN storage, we can have more free, more open and
more portable long file names :-). On the down side, the driver
will not read or write VFAT LFNs for you, so if you want to let
Windows and DOS access the same drive, you would not share LFNs.

This includes USB drives and MP3 player devices and similar, but
not for example CD / DVD which use non-VFAT LFNs anyway for which
DOS uses separate drivers anyway...

In short: If you want VFAT then the only way to get it is to use
VFAT, but that might have licensing issues if you use DOS in your
embedded device. If you only want LFN, you can get it even in a
way that makes LFN DOS apps happy without having to touch VFAT
data structures, using a descript.ion based LFN API driver :-).


This SF.net email is sponsored by:
High Quality Requirements in a Collaborative Environment.
Download a free trial of Rational Requirements Composer Now!
Freedos-user mailing list

Reply via email to