Date: Tue, 27 Jun 2000 15:24:43 +0300 (IDT) From: Eli Zaretskii X-Sender: eliz AT is To: Jeff Williams cc: djgpp AT delorie DOT com Subject: Re: how does DJGPP check for LFN support? In-Reply-To: <200006261645.LAA25509@darwin.sfbr.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Reply-To: djgpp AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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?