Mail Archives: djgpp/2000/06/27/10:33:18
On Mon, 26 Jun 2000, Jeff Williams wrote:
> How does djgpp check for LFN support, and how does it decide to use
> short file names?
It calls function 71A0h of Int 21h. See the source file _use_lfn.c in
the DJGPP source distribution, for the details.
> Do all the INT 21/AX=0x71xx functions need to be supported, or just
> some critical few?
To be useful (see below), you need to support all of them, because
almost all of them are used by one or other library function. Once
the startup code determined that the LFN API is supported, it doesn't
expect some of the LFN calls to fail, so if this happens, applications
will mysteriously break.
> I thought I would implement all the
> TSR infrastructure first, and just reflect any INT 21/AX=0x71xx calls
> back to their SFN equivalents. Later I'll start adding the LFN support.
This will not be useful, IMHO. With such a partial support, you won't
be able to run anything but trivial programs. In particular, many
development tools (Make, Bash, Fileutils, etc.) will almost certainly
break by such a partial support.
LFN support is not only about long file names, it's about all the
advanced features to which the LFN API gives access. Enhanced file
time-stamps, open flags, directory search, conversion of short to long
file names, file-name case-preservation -- these are some of the
examples of the features the library relies upon when LFN is
supported.
In addition, some applications probe the LFN support on the
application level, and change their behavior accordingly. For
example, makeinfo will produce foo.info-1, foo.info-2, etc. instead of
foo.i1 and foo.i2. How can you support this if you just reflect the
calls to the legacy DOS calls?
- Raw text -