X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f X-Recipient: djgpp AT delorie DOT com Date: Sat, 10 Sep 2011 19:47:42 +0300 From: Eli Zaretskii Subject: Re: Isues concerning the INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX) implementation. In-reply-to: <201109101340.47663.juan.guerrero@gmx.de> X-012-Sender: halo1 AT inter DOT net DOT il To: djgpp AT delorie DOT com Message-id: <83vct04a4x.fsf@gnu.org> References: <201109101340 DOT 47663 DOT juan DOT guerrero AT gmx DOT de> 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 > From: Juan Manuel Guerrero > Date: Sat, 10 Sep 2011 13:40:47 +0200 > > I have checked the repository and found that the following functions use the > INT 21 Windows95 - LONG FILENAME FUNCTIONS (0x71XX). Accoring to RBIL61, the > recommended way to proceed here is always to set CF before calling a 0x71XX > function, and after the function call has been performed to check that the > AX register does not contain 0x7100. If AX == 0x7100 the functionality is not > provided by the LFN API and the corresponding SFN API function shall be called. > > Not a single of the functions set CF before calling 0x71 functions. This can > produce serious malfunctions as has been seen with MSDOS 6.22 and DOSLFN 0.40e > in threat > Except for _use_lfn and lfnshort not a single function checks for AX != 0x7100. > This is certainly wrong and makes a lot of programs fail (e.g., gcc, gdb, grep). > Some of these functions call _use_lfn to decide if LFN support is available or > not, but _use_lfn only checks for 0x71a0 and this is certainly not enough to > decide if the required 0x71XX functions are really available or not. The assumption was that LFN functions are either all supported or not at all. If that assumption is not true, by and large, then many things will fall apart. > shall remove really remove a SFN file if > it does not find the LFN file because the LFN API function is not available? No! It should simply fail. If some environment supports 0x71a0, but does not support 0x7156, then it basically means LFN is not supported, and the user will have to disable LFN through the environment variable. The same goes for `_rename' and other basic functions that accept file names as their arguments, and make destructive changes to the filesystem. Functions that accept file descriptors, by contrast, could fall back on SFN functions where that makes sense, i.e., where some useful data can be still returned to the caller. > It would also be possible to improve _use_lfn() to check for _all_ 0x71XX > functions. That would make it painfully slow, which is not a good idea, because as I recall it is called internally by many library functions. Don't forget that calling any Int 21H function requires an expensive mode switch. It is better to add recovery to the few functions we found now to be not supported well by DOSLFN. Below are my suggestions for the functions you mentioned: libc/ansi/stdio/remove.c 0x713A, 0x7141 -- fail libc/ansi/stdio/_rename.c 0x7156 -- fail libc/dos/dir/findfirs.c 0x714e, 0x71a1 -- fail for 0x714e libc/dos/dir/findnext.c 0x714f, 0x71a1 -- fail for 0x714f libc/dos/dos/truename.c 0x7160 -- fall back on 0x6000 libc/dos/io/flushdc.c 0x710d -- fall back on BIOS DISK RESET libc/dos/io/_chmod.c 0x7143 -- fail libc/dos/io/_creat.c 0x716c -- fall back on SFN libc/dos/io/_creat_n.c 0x716c -- fall back on SFN libc/dos/io/_open.c 0x7143, 0x7160, 0x716c -- fall back on SFN libc/dos/lfn/lfnshort.c 0x7100, 0x71a8 -- fall back on SFN libc/dos/lfn/_use_lfn.c 0x7100, 0x71a0 -- return 0 libc/dos/process/dosexec.c 0x7160 -- ignore libc/posix/dirent/opendir.c 0x71a1 -- ignore libc/posix/sys/stat/fchmod.c 0x71a6 -- already handles this libc/posix/sys/stat/filelen.c 0x71A6 -- fall back on 0x42XX libc/posix/sys/stat/fixpath.c 0x7147, 0x7160, 0x713b -- fall back on 0x4700 libc/posix/sys/stat/fstat.c 0x71a6 -- already handles libc/posix/sys/stat/lfilelen.c 0x71A6 -- already handles libc/posix/sys/stat/mkdir.c 0x7139 -- fall back on 0x3900 libc/posix/unistd/chdir.c 0x713b -- fall back on 0x3b00 libc/posix/unistd/getcwd.c 0x7147 -- fall back on 0x4700 libc/posix/unistd/getcwd.c 0x7160 -- already handles libc/posix/unistd/rmdir.c 0x713a -- fail libc/posix/utime/utime.c 0x7143 -- only uses 0x7143 on NT/2K/XP