Mail Archives: djgpp/2011/09/10/12:50:04
> From: Juan Manuel Guerrero <juan DOT guerrero AT gmx DOT de>
> 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 <httpdjgpp/2011/08/30/18:59:04>
> 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
- Raw text -