LFN -- C code to bring long filenames to 16-bit applications (c) 1995 Matt Ginzton, MaDdoG Software released 11/22/95 ============================================================ Overview ======== Microsoft's Windows 95 implements a nifty way to store long filenames on FAT volumes, and with this comes a slew of other improvements to the filesystem (ie, filespecs containing more than 1 * wildcard). However, only 32-bit applications automatically benefit from these improvements. The LFN module in this package attempts to remedy this by serving as a plug-in replacement for the dos.h you're probably already using, and providing LFN support to 16-bit applications with little more than a recompile. Programs built with the LFN module will continue to work as always under 16-bit Windows, but under Windows 95 will suddenly be able to see long filenames. Usage ===== (This assumes you're using MS Visual C/C++ 1.x; other compilers may differ.) 1. Wherever you're #include-ing , #include "lfn.h" instead. In many cases, ie where you're using constants such as _A_NORMAL that lfn.h doesn't duplicate, you may need to #include both. This won't cause any problems. 2. Change all calls to disk functions to the lfn equivalents; ie, _open becomes _lfn_open, and _getcwd becomes _lfn_getcwd. (Findfirst calls require a bit more work; see below Implementation Notes.) 3. Add lfn.c to your project. 4. Recompile and test! Implementation notes ==================== LFN.H (and the corresponding C module) was designed to serve as a nearly direct replacement for the DOS.H that comes with Microsoft Visual C/C++ 1.x. For the most part, you should be able to simply #include lfn.h instead of dos.h, and add lfn.c to your project, to benefit from long filenames. I don't know about other compilers. Not every function in dos.h has a counterpart in lfn.h, because I stopped once I had the functionality I needed. If you need mkdir, rmdir, etc, they should be easy to add. Existing code that uses findfirst will probably need a few changes. First, at the end if your findfirst/findnext loop, you'll need to call _lfn_findclose, since the 32-bit findfirst allocates a search handle that must later be freed. You'll also need to change declarations of _find_t structs to _lfnfind_t's. Second, your code will now be dealing with a _lfnfind_t struct, instead of a _find_t. If all you need is the name field, this still exists (don't try to copy it to a 13-byte buffer though!), but if you need other fields, you'll have to look in either the SFN member or the LFN member. (Even for files stored with long filenames, the information in the SFN member will always be valid, so to modify existing code the quickest way possible, just change references like find.attrib to find.SFN.attrib. And if you want to take advantage of the information stored with long filenames, that's possible too if the bIsLong member of the _lfn_find struct is TRUE.) I don't promise that anything lfn.c does is the most efficient way to attack the problem, but it does integrate well into existing code using dos.h that may run on 16-bit or 32-bit platforms. I also don't promise that lfn.c is bug-free, but it's working fine for me. If you find any bugs or make any other changes to the code that you think I should be aware of, please email me. If you have further questions, first look at the code, then ask me. Terms and conditions ==================== The LFN library is freeware, but if you like it (or if you don't!) please send feedback to one of the email addresses listed in the About... box. This code is supplied without any warranties, expressed or implied. Permission is granted to use and modify this code as long as attribution is given. Questions? Email mginzton@leland.stanford.edu, or via CompuServe, 75022,650.