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 :-). Eric ------------------------------------------------------------------------------ This SF.net email is sponsored by: High Quality Requirements in a Collaborative Environment. Download a free trial of Rational Requirements Composer Now! http://p.sf.net/sfu/www-ibm-com _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
